全國最多中醫師線上諮詢網站-台灣中醫網
發文 回覆 瀏覽次數:1360
推到 Plurk!
推到 Facebook!

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

 
happosai
高階會員


發表:93
回覆:228
積分:109
註冊:2002-09-15

發送簡訊給我
#1 引用回覆 回覆 發表時間:2012-08-01 01:00:46 IP:118.169.xxx.xxx 訂閱
作者: 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;
}
}


在一個idx0開始,直到小於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/位元錯誤,
也就是說,原本為0Bit突然變成了1,原本為1Bit突然變成了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有時候並不是一個好主意,
因為,0x000x01只相差一個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

happosai
高階會員


發表:93
回覆:228
積分:109
註冊:2002-09-15

發送簡訊給我
#2 引用回覆 回覆 發表時間:2012-08-01 01:05:14 IP:118.169.xxx.xxx 訂閱
aftcast
站務副站長


發表:81
回覆:1482
積分:1762
註冊:2002-11-21

發送簡訊給我
#3 引用回覆 回覆 發表時間:2012-08-01 16:17:10 IP:114.32.xxx.xxx 訂閱
尚未深入的去看裡面的文章,不過就您所貼出來的部份,我對於那樣的做法有不同的看法:

簡言之那些做法僅是以「軟」護「硬」而已。雖然經常有這樣的需要,但那多數都是硬體的人員太偷懶或是太高傲!

如果說為了那些極小的可能性,且原則上可經硬體保護的情形下的error,不該做那麼多餘的if 保護。if的保護很重要,但以上面的那情形而言,實有"杞人憂天"之"太過"。一來那樣的程式碼讓效能變差(如果處處都有危機的話),二來開發的時間變長!

軟與硬原本就是各有所專。許多那些系統錯誤都是硬體可解的,但硬體的人都不去解…此非正道! 比如雷擊,什麼被干擾… 硬的該做好硬的最佳化,最完善化。而軟體則也要做最佳化,最完善化,但軟的最完善應該是防止user輸入不該輸入的(人為),造成buffer overrun等,避免野指標等等的…但應該不含那種超級"過度"的防護。

此外,若程式因此而寫的極為複雜,那麼bug也相對的機率會更高,而維護的人員時間與金錢也要付出更大! 這樣的代價會不會反而更大?

以上我是個人對那篇文的想法。
------



蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan
編輯記錄
aftcast 重新編輯於 2012-08-01 02:23:05, 註解 無‧
aftcast
站務副站長


發表:81
回覆:1482
積分:1762
註冊:2002-11-21

發送簡訊給我
#4 引用回覆 回覆 發表時間:2012-08-01 17:05:56 IP:114.32.xxx.xxx 訂閱
 再補充一下:
在通訊中,網路的中、低層架構裡,有著error detection與error correction等保護。但這類的與那 system bit error,是不可相提並論!

如果說,連bit error都無法去用硬體來防,那麼用軟體一定會有效嗎? 以原例來說:

if (idx >= BUF_SIZE) {
do_something();

如果你的do_something的過程裡,再次的發生bit error的話,那你會有解嗎? (這是有很有可能的,因為硬體出錯的時候,往往會有至少幾個instructions都出問題,很難剛好僅一個memory裡的一個bit出事…

簡單講 ,若隨時都可能bit error,那麼不僅是在loop中要避,我看在非常多的地方都要避免了… 這種情形下,硬體的不可靠性根本也是軟體無法解的,或者說用很大的力氣僅可能解到極小的一部份!
------



蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan
scott123
中階會員


發表:19
回覆:66
積分:52
註冊:2011-08-11

發送簡訊給我
#5 引用回覆 回覆 發表時間:2012-08-07 18:28:24 IP:203.73.xxx.xxx 訂閱
我覺得不用那麼否定這篇文章的想法
它的標題也是標明如何強化
當然沒有一個軟體有100%測試無誤,絕不可能出錯
個人覺得應該要看什麼環境,什麼人用這一個產品
小朋友的玩具、手機、飛機、太空
什麼場合就做到什麼防護機制

電子雞,不用了吧
太空儀器,開玩笑,當然要做到最好

===================引 用 aftcast 文 章===================
尚未深入的去看裡面的文章,不過就您所貼出來的部份,我對於那樣的做法有不同的看法:

簡言之那些做法僅是以「軟」護「硬」而已。雖然經常有這樣的需要,但那多數都是硬體的人員太偷懶或是太高傲!

如果說為了那些極小的可能性,且原則上可經硬體保護的情形下的error,不該做那麼多餘的if 保護。if的保護很重要,但以上面的那情形而言,實有"杞人憂天"之"太過"。一來那樣的程式碼讓效能變差(如果處處都有危機的話),二來開發的時間變長!

軟與硬原本就是各有所專。許多那些系統錯誤都是硬體可解的,但硬體的人都不去解…此非正道! 比如雷擊,什麼被干擾… 硬的該做好硬的最佳化,最完善化。而軟體則也要做最佳化,最完善化,但軟的最完善應該是防止user輸入不該輸入的(人為),造成buffer overrun等,避免野指標等等的…但應該不含那種超級"過度"的防護。

此外,若程式因此而寫的極為複雜,那麼bug也相對的機率會更高,而維護的人員時間與金錢也要付出更大! 這樣的代價會不會反而更大?

以上我是個人對那篇文的想法。
leveon
資深會員


發表:29
回覆:386
積分:303
註冊:2012-02-12

發送簡訊給我
#6 引用回覆 回覆 發表時間:2012-08-08 16:35:53 IP:118.165.xxx.xxx 訂閱
這一篇 第一次看到是在ptt 好像還不少人參加討論~
我自己是認為 程式行為模式都跟發展背景有關
用大俠舉的通訊例子 以TCP/IP來說 IP是不穩定的 但TCP卻要求穩定
在一個不穩定的基礎 要去追求可靠 方法就只能靠不斷的糾錯 偵錯
所以有時候網路出包 網路還是會通 但是就是慢慢慢 慢到讓人起肖

這篇文章的某些論點 都是假設 身處在非常不穩定的環境
處處留下狀態副本 處處偵防 但是我不認為等意外發生時
這些副本派上用場 機器的運轉效果還會像正常情況一樣
應該是勉勉強強達到目的 就跟劉翔跛腳走到終點一樣
如果這也算是程式的預期目地
那就不枉程式師的一番努力吧 顆顆~~
happosai
高階會員


發表:93
回覆:228
積分:109
註冊:2002-09-15

發送簡訊給我
#7 引用回覆 回覆 發表時間:2012-08-09 02:01:46 IP:118.169.xxx.xxx 訂閱
這篇文章最後提到的Static allocation,小弟有一些實作經驗,野人獻曝一下:

godspeedlee.myweb.hinet.net/network_prog/0/
leveon
資深會員


發表:29
回覆:386
積分:303
註冊:2012-02-12

發送簡訊給我
#8 引用回覆 回覆 發表時間:2012-08-09 15:16:52 IP:118.165.xxx.xxx 訂閱
恭喜你在stackoverflow 破500 
恭喜 恭喜 ~~~



===================引 用 happosai 文 章===================
這篇文章最後提到的Static allocation,小弟有一些實作經驗,野人獻曝一下:

godspeedlee.myweb.hinet.net/network_prog/0/
系統時間:2017-10-23 12:24:34
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!