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