東西斷了。事情出錯了。不太禮貌的綽號是：****發生。不管你用什么詞，我們生活在一個不完美的世界里，這是一個事實。在嵌入式系統中，有很多失敗的機會。在簡單的系統中，故障通常會導致它們無法正常工作。在復雜系統中，故障可能以更微妙的方式表現出來。

嵌入式系統是“智能的”，因此很明顯可以利用這種智能來檢測即將發生的問題和已經發生的問題，并可能減輕故障的影響。

這種內置故障控制的常用術語是“自我測試”。這是一個很大的主題，很可能已被許多會議論文所涵蓋，細節可能會寫滿一本書。但在這里，我只想考慮關鍵問題。

本質上，嵌入式系統有四個可能的故障區域：

中央處理器

外圍設備

記憶

軟件

CPU 的故障非常罕見，但當然也不是未知數。部分故障不太可能發生，因此預期的情況是無法運行代碼，因此沒有機會解決故障。由于電子元件的故障最常發生在上電時，CPU 故障很可能表現為完全死機的設備。在多 CPU 設計中這是另一回事，當一個 CPU 可以監視另一個 CPU 的活動并更優雅地報告故障時。

當然，內存是一個關鍵的系統組件，現代設備有很多。失敗遠非未知。可能由雜散的亞原子粒子引起的瞬態故障可能導致設備無法解釋且無法重現的崩潰。真的沒有什么可以解決這種可能性的。更可能檢測到硬/永久性故障。

內存可以通過兩種方式進行測試：上電時（這是最有可能發生故障的時候），在任何有用的數據存儲在其中之前，或者在運行中，如果有空閑的 CPU 時間可用。如果可以容忍短暫的啟動延遲，那么在它包含任何數據之前進行全面的內存測試是否值得。通常的測試稱為“移動位”，其中內存被清除，每個位依次寫入一個，并且每隔一個位檢查以確保它是零。“移動零點”測試應用了相同的想法。

動態測試自然不那么全面，因為實時數據不會被破壞。唯一真正的選擇是通過寫入和讀取一系列模式來測試每個字節/字，同時禁用中斷。

外圍設備種類繁多，并且可能會失敗是許多有趣的方式。但是，我可以提供的一般性建議很少。自測試代碼可以檢查設備是否對其地址做出響應，如果不這樣做則表明發生了不好的事情。否則，某些設備可能具有“環回”模式，可以檢查基本的發送/接收功能。除此之外，需要由設備功能知識驅動的創造力來實施任何自我測試。

如果軟件失敗，那是因為它的設計或實現出現了錯誤。與硬件不同，無錯誤的軟件（如果它甚至存在的話）不會隨著時間的推移而變壞。軟件故障大致分為兩類：

陷入循環（無響應）

數據/代碼損壞

（1） 最常見的原因實際上是某種硬件問題，軟件正在等待永遠不會出現的響應。這仍然是一個軟件錯誤，因為超時總是謹慎的。解決此類故障的最佳方法是使用某種看門狗設施。如果未收到軟件的定期響應，這通常是重置系統的硬件。專用任務可能在多線程應用程序中執行相同類型的工作。

指針錯誤是 （2） 的可能原因，完全隨機的內存損壞很難檢測和診斷。幸運的是，一個常見的錯誤是使用空指針或完全無效的指針。由于這會導致陷阱（軟件中斷），因此預防措施是確保實施陷阱處理程序。另一個流行的錯誤是堆棧或數組等內存區域溢出。這可以通過在任一端使用“警戒詞”并監控它們的訪問來解決。

仍然存在一個重要的未解決問題。一旦檢測到故障或即將發生的故障，您能做些什么呢？這完全取決于系統的性質。在某些情況下，尤其是深度嵌入式系統，系統重置是唯一明智的做法。記錄故障以供以后分析可能是可能的。對于其他系統，可以建議用戶并可能確定要采取的行動。另一種可能性是設備“打電話回家”或使用網絡連接向用戶/供應商/開發人員發送有關故障的信息。

最重要的是，每個嵌入式系統都是不同的，這就是讓這個行業的工作變得有趣的原因。結果是每個設備的自檢都不同，對發現故障的響應也同樣可變。唯一不變的因素是失敗的可能性以及許多開發人員對這種可能性的否認。

審核編輯：郭婷