[心得] 如何強化嵌入式(系統)軟體可靠度

看板LinuxDev作者JohnLinq (林約翰)時間16年前 (2009/04/12 00:28)推噓3(3推 0噓 0→)

留言3則, 3人參與討論串1/1

※ [本文轉錄自 Programming 看板] 作者: JohnLinq (林約翰) 看板: Programming 標題: [心得] 如何強化嵌入式(系統)軟體可靠度時間: Sun Apr 12 00:23:14 2009 我在KEIL的官方論壇，看到一篇關於「如何強化嵌入式(系統)軟體可靠度」的文章，我個人覺得蠻有參考價值的，所以.希望能夠把這篇文章介紹給大家。 KEIL官方論壇的討論串在此： http://www.keil.com/forum/docs/thread14537.asp 這個討論串起源於其他雜七雜八的閒聊，而後由Per Westermark所發起， Per Westermark是一位來自瑞典的嵌入式系統專家，也是KEIL官方論壇的主要貢獻者(解答問題的人)之一。或許是有感於，從事嵌入式系統開發的人越來越多，對於嵌入式系統「品質與可靠度」的關注，卻越來越少，所以，Per Westermark才會公開發表以下這篇文章。 Some concepts for hardening embedded software Copyright (c) Per Westermark, 2009 http://iapetus.neab.net/download/8dc2ac48-635ac1a9/hardening.html Per Westermark表示，關於系統開發的流程、方法論、規範標準等等，大家都可以找到各式各樣的豐富資料，但是，在實際進行軟體開發的時候，應該注意哪些關鍵，卻很少有人提及；所以，Per Westermark給大家提供了21項建議，而這些建議，所著眼的，並不是如何寫出洗練的程式碼，也並不是如何減少Bug的出現， Per Westermark的建議，是實在地告訴我們，當一個系統出錯的時候，軟體應該如何處理；至少，對於鄙陋如我而言， Per Westermark的建議，讓我能夠以截然不同的角度，看到全新的視野。 uint16_t buf[BUF_SIZE]; unsigned idx; for (idx = 0; idx < BUF_SIZE; idx++) { ... if (idx >= BUF_SIZE) { do_something(); } else { buf[idx] = new_data; } } 在一個idx由0開始，直到小於BUF_SIZE為止的迴圈裡，寫下if (idx >= BUF_SIZE) then do_something()的代碼，看來似乎是相當地外行？其實不然。 uint16_t buf[BUF_SIZE]; unsigned idx; for (idx = 0; idx < BUF_SIZE; idx++) { ... if (idx >= BUF_SIZE) { // loop variable has for some reason been corrupted. Take proper // action. perform_corrective_action(); } else { buf[idx] = new_data; } } 嵌入式系統的應用領域非常廣泛，從太空梭、彈道飛彈、戰鬥機、民航機、汽機車，到數位機上盒都有可能。在以下這串雜七雜八的閒聊裡，提到了一些例子： http://www.keil.com/forum/docs/thread14479.asp (這個討論串很長，更糟的是很亂。) 姑且把所有的系統錯誤都稱為Bit Error/位元錯誤，也就是說，原本為0的Bit突然變成了1，原本為1的Bit突然變成了0； Bit Error可能因為各式各樣的原因而發生，或許是因為系統瑕疵，或許是因為旁邊有高壓電塔，或許是因為被雷打到，或許是因為一隻黑貓剛好走過去。也或許，因為這個嵌入式系統用在電子作戰，它必須干擾敵方的系統，並且不被敵方干擾；也或許，因為這個嵌入式系統用在吃角子老虎，剛好有人想要作弊，剛好有人想要破台。當Bit Error發生的時候，軟體應該怎麼做？ 1. Duplicated data 重要的「設定值」與「狀態值」應該擁有一份能夠自我備援的副本。 2. Checksummed data 「設定值」與「很少變動的資料」，應該具備「自我偵錯/糾錯」的能力。 3. Recomputed variables 系統閒置時，重新計算「重要的變數」。 4. Refreshing of I/O configuration and state 系統閒置時，重新寫入重要的「設定值」。 5. Cross-correlation of time from multiple sources 系統應該具備偵測能力，以評估「時間/時鐘的來源」是否可靠。 6. Age-tracking of sensor data 系統應該具備偵測能力，以評估「感測器所傳回的數值」是否可靠。 7. Explicit range checking 對於「資料區域的位址上/下限」，應該明確的定義並且加以偵測，以確保資料區域不被損毀。 8. Stack highwater marks Stack應該擁有清楚的識別Pattern，讓系統能夠對Stack進行保護，以確保Stack不被損毀。 9. Corruption fingerprinting 資料儲存區應該填入Magic value，讓系統能夠進行資料損毀的偵測。 10. Magic values/hamming distance for states 以數值來表示狀態的時候，相鄰的兩個狀態值應該具備充分的區別性，以防止錯誤。所以，0表示FALSE、非0表示TRUE，有時候並不是一個好主意，因為，0x00與0x01只相差一個Bit。 11. Trend analysis of repairs/resends/… 系統應該具備「故障傾向」的偵測能力，比如說：電壓逐步下降，Error Rate逐步上升。 12. Interrupt lockup detection 對於可預期的系統事件，系統應該加以偵測，一旦事件應產生而未產生，則表示故障。 13. Interrupt loop detection 對於可預期的系統事件，系統應該加以偵測，一旦事件應結束而未結束，則表示故障。 14. Processor load supervision 15. Hardware watchdog 16. Inter-thread software watchdogs 17. Avoiding infinite loops 18. Checksummed firmware 19. Duplicated firmwares 20. Wear-leveling of flash and EEPROM 21. Static allocation Per Westermark期待能夠與有興趣於此的人士交流，有任何意見請到 KEIL官方論壇的相關討論串留言： http://www.keil.com/forum/docs/thread14537.asp (KEIL的官方論壇相當地自由開放，無須註冊就可以發表留言。) (雖然它希望你以Real Name署名，但是它並不強制。) -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.232.210.60 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.232.210.60