在嵌入式系統(tǒng)中，有很多失敗的機會。在簡單的系統(tǒng)中，故障通常會導(dǎo)致它們無法正常工作。在復(fù)雜系統(tǒng)中，故障可能以更微妙的方式表現(xiàn)出來。

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

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

本質(zhì)上，嵌入式系統(tǒng)有四個可能的故障區(qū)域：

中央處理器

外圍設(shè)備

記憶

軟件

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

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

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

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

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

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

陷入循環(huán)（無響應(yīng)）

數(shù)據(jù)/代碼損壞

（1） 最常見的原因?qū)嶋H上是某種硬件問題，軟件正在等待永遠不會出現(xiàn)的響應(yīng)。這仍然是一個軟件錯誤，因為超時總是謹(jǐn)慎的。解決此類故障的最佳方法是使用某種看門狗設(shè)施。如果未收到軟件的定期響應(yīng)，這通常是重置系統(tǒng)的硬件。專用任務(wù)可能在多線程應(yīng)用程序中執(zhí)行相同類型的工作。

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

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

最重要的是，每個嵌入式系統(tǒng)都是不同的，這就是讓這個行業(yè)的工作變得有趣的原因。結(jié)果是每個設(shè)備的自檢都不同，對發(fā)現(xiàn)故障的響應(yīng)也同樣可變。唯一不變的因素是失敗的可能性以及許多開發(fā)人員對這種可能性的否認(rèn)。

審核編輯：郭婷