聊聊IoT設備的自我測試
東西壞了，事情也出了差錯。 簡單的說就是 XX發生了。 不管用什么詞，事實上我們都生活在一個不***的世界里。 在嵌入式系統中，有很多失敗的可能。 在簡單的系統中，失敗通常導致它們不工作。 在復雜的系統中，失敗可能以更微妙的方式表現出來。
嵌入式系統引入了"智能"，所以顯而易見的是，這種智能可以用來檢測即將發生的問題和已經發生的問題，并可能減輕失敗的影響。
這種內置故障控制的通常術語是"自我測試"。這是一個很有可能被許多會議所討論的大問題，細節可能會寫滿一本書。 但在這里，只考慮一下關鍵問題。
從本質上講，嵌入式系統中有四個可能出現的故障領域:
- CPU 中央處理器
- Peripherals 外圍設備
- Memory 內存
- Software 軟件
一個 CPU 的失敗是相當罕見的，但是，當然，不是未知的。部分失敗是不可能的，所以預期的情況是無法運行代碼，所以沒機會解決失敗。由于電子元件的故障通常發生在電源上，CPU 故障很可能會以一個完全死機的形式出現。在多 CPU 設計中，這是一個不同的問題，當一個 CPU 可以監視另一個 CPU 的活動并且更優雅地報告失敗。
內存是一個關鍵的系統組件，當然，現代設備中有很多的內存。失敗也是未知的。 一個暫時的故障，可能是由一個雜散粒子引起的，可能會導致無法解釋的、無法生成的裝置崩潰。真的沒有什么辦法可以解決這種可能性。 一個嚴重的或者***性的失敗更容易被發現。
內存可以通過兩種方式進行測試: 如果CPU有閑置時間的話，在加電的時候（在任何有用的數據存儲在存儲在內存之前），或者在動態運行中。如果一個簡短的啟動延遲可以被容忍的話，要考慮是否需要一個全面的內存檢測。 通常的測試被稱為"動態測試"，在這種方法中，內存被清除，每個位都被寫入，每個位都被檢查，以確保它是零。
動態測試自然沒有那么全面，因為實時數據不可能被損壞。唯一真正的選擇是通過編寫和讀取一系列模式來測試每個字節，而中斷是禁用的。
外圍設備多種多樣，可能會失敗，這里有許多有趣的方法。 然而，能提供的一般性建議很少。自測代碼可以檢查設備對其地址的響應，因為如果沒有這樣做，就意味著發生了不好的事情。否則，一些設備可能有一個"循環回路"模式，能夠檢查基本的發送/接收功能。除此之外，任何自我測試都需要創造力，這種創造力是基于對設備功能的理解。
如果軟件失敗了，那是因為它的設計或實現出錯了。與硬件不同，無錯誤軟件(如果存在的話)不會隨著時間的推移而變壞。 軟件故障可分為兩大類:
（1）陷入一個循環(無反應)
（2）數據/代碼腐爛
最常見的原因(1)實際上是某種硬件問題，導致軟件正在等待一個永遠不會出現的響應。 這仍然是一個軟件錯誤，因為超時總是謹慎的。解決這種問題的***方法就是使用某種watchdog設施。如果沒有收到軟件的定期響應，通常要硬件重置系統。一個專用的任務可能在多線程應用程序中做同樣的工作。
指針錯誤是導致(2)隨機內存損壞的可能原因，很難對其進行檢測和診斷。幸運的是，一個常見的錯誤是使用無效的指針。由于這會導致一個軟件中斷，預防措施是確保相應處理程序的實現。 另一個普遍的錯誤是像堆棧或數組這樣的內存區域的溢出。 這個問題可以通過在兩端使用保護檢查或監測其訪問情況加以解決。
還有一個重要的未決問題。 一旦發現失敗或即將發生失敗，能做些什么呢？ 這完全取決于系統的性質。 在某些情況下，特別是深度嵌入式系統，系統重置是唯一合理的做法。在后面的分析中記錄失敗是一種可能。 對于其他系統，用戶可能會被建議或者決定要采取的行動。 另一種可能性是，設備使用網絡連接向用戶/供應商/開發人員發送有關故障的信息。
自我測試的底線對每一個嵌入式系統都是不同的，這使得這個行業的工作變得有趣。結果是，每個設備的自我測試都是不同的，對發現故障的反應也是可變的。 唯一不變的因素是失敗的可能性，以及許多開發人員對這種可能性的否定。
【本文來自51CTO專欄作者“老曹”的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
