[心得] 如何強化嵌入式(系統)軟體可靠度
※ [本文轉錄自 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
推
04/13 22:22, , 1F
04/13 22:22, 1F
推
04/14 08:23, , 2F
04/14 08:23, 2F
推
04/25 14:05, , 3F
04/25 14:05, 3F