【導(dǎo)讀】硬件叱咤江湖，軟件通過控制硬件來統(tǒng)治江湖。如今，有電子的地方就有嵌入式軟件，有電子故障的地方，也就有嵌入式軟件設(shè)計(jì)缺陷的影子。我們今天就把軟件所容易犯的錯(cuò)誤和規(guī)避的方法一一羅列，并給出應(yīng)對之法。
嵌入式軟件的最大特點(diǎn)是以控制為主，軟硬結(jié)合的較多，功能性的操作較多，模塊相互間調(diào)用的較多，外部工作環(huán)境復(fù)雜容易受到干擾或干擾別的設(shè)備，且執(zhí)行錯(cuò)誤的后果不僅僅是數(shù)據(jù)錯(cuò)誤而是有可能導(dǎo)致不可估量的災(zāi)難，所以總結(jié)起來，嵌入式軟件可靠性設(shè)計(jì)需注意的問題有四個(gè)方面：
1、軟件接口
先說軟件接口中容易出問題的地方和編程人員容易犯的錯(cuò)誤。
軟件接口調(diào)用一般會有數(shù)據(jù)的賦值，賦值變量的數(shù)據(jù)類型可能會存在強(qiáng)制的數(shù)據(jù)轉(zhuǎn)換；需加以檢查。如果為了防范出問題的話，可以添加對數(shù)據(jù)范圍和數(shù)據(jù)類型的檢查。
賦值數(shù)據(jù)的數(shù)量不對路，多了少了的都不好，會出現(xiàn)意外的賦值結(jié)果，不過還好，這項(xiàng)錯(cuò)誤比較好檢查。
軟件編程中，會有對某一功能操作代碼的復(fù)用，比如對某個(gè)端口的數(shù)據(jù)檢查和控制，在整個(gè)程序中只會發(fā)生兩次，為了圖省事，可能就直接把該段代碼直接插入實(shí)際程序模塊中去了，這樣，在源程序代碼中，就出現(xiàn)了兩段完全相同，完成相同功能，只是服務(wù)于不同模塊的代碼，按道理來說，這樣設(shè)計(jì)其實(shí)也沒啥問題，是的，你沒錯(cuò)，但你的行為會使別人無意中犯錯(cuò)。有人會說了，我這樣寫代碼怎么就算引誘呢？原因是程序可能會升級，你這幾行代碼在實(shí)際應(yīng)用過程中也不能保證是盡善盡美的，發(fā)現(xiàn)不完善的地方后，勢必會修改，如果你還能想得起來，可能不會遺漏，如果修改此代碼的是別的人，改了一個(gè)地方，別的地方?jīng)]改，是不是還留著隱患？那如何做呢？方法不難，把這段功能單獨(dú)做成一個(gè)模塊即可，對此端口的讀取和控制賦值均由此獨(dú)立模塊完成，如果數(shù)據(jù)的正確性影響大的話，還需要對端口數(shù)據(jù)的正確性進(jìn)行檢查和判斷。嵌入式軟件可靠性編程方法的四個(gè)目的是防錯(cuò)、判錯(cuò)、糾錯(cuò)、容錯(cuò)。對端口數(shù)據(jù)的判斷屬于判錯(cuò)的內(nèi)容。
2、軟硬件接
硬件，對外的執(zhí)行都靠它來實(shí)現(xiàn)，一旦出現(xiàn)問題，執(zhí)行后的后果就不可控了，但如何注意呢？
對讀進(jìn)來的硬件接口的數(shù)據(jù)要判斷其真?zhèn)危?/div>
Temp — tmp；
對輸出的數(shù)據(jù)的執(zhí)行效果要檢測；
對輸出的數(shù)據(jù)的可能后果要進(jìn)行預(yù)防性設(shè)計(jì)，數(shù)據(jù)輸出的過程，我們從設(shè)計(jì)上要做一個(gè)分析，分析的思路是一般容易局限在穩(wěn)態(tài)過程，忽視了過渡過程。舉例說明，比如我們控制一個(gè)支路的供電，從軟件控制來說，直接給繼電器一個(gè)啟動信號，讓開狀態(tài)的觸點(diǎn)閉合就可以了，非“關(guān)”即“開”，是受控繼電器的兩個(gè)穩(wěn)態(tài)狀態(tài)，但事實(shí)上，在從開到閉合的過程中，支路供電的電壓并不是一個(gè)簡單0V—24V（24V為示例而已）的跳變狀態(tài)，而是一個(gè)抖動，有沖擊信號的過程，這種情況在硬件上的防護(hù)是必不可少的，但在軟件上也不是可以事不關(guān)己、高高掛起的。
另外在邏輯上，宜將容易被干擾和容易產(chǎn)生的干擾控制動作從時(shí)序上控制好，予以分開隔離。比如，控制繼電器的過程是容易產(chǎn)生抖動尖峰脈沖而干擾數(shù)據(jù)總線和控制信號總線的，這時(shí)候從控制上，不宜同時(shí)實(shí)施數(shù)據(jù)的發(fā)送和接收工作，不宜作出其他的控制動作，惹不起咱躲得起，躲過這一陣干擾的時(shí)候總可以了吧？
3、軟件代碼
軟件的可靠性是隨著時(shí)間的推移，可靠性逐漸增加的，這一點(diǎn)區(qū)別于電子可靠性、機(jī)械可靠性。電子可靠性服從指數(shù)分布，在整個(gè)生命周期內(nèi)，其失效率為一個(gè)常數(shù)；機(jī)械可靠性因?yàn)槟p、腐蝕、運(yùn)動等因素的存在，隨時(shí)間推移可靠度會下降。因此也就有了軟件可靠性設(shè)計(jì)的一個(gè)特定規(guī)律和注意事項(xiàng)。
既然需要通過時(shí)間推移，通過不斷改進(jìn)，軟件可靠性得到提升。那么軟件的可維護(hù)性就是一個(gè)大問題了。這也是為什么軟件工程管理方面特別關(guān)注軟件文檔、注釋的原因了。但做這些要求的人只是人云亦云，并不理解如此做法的真正動機(jī)。至于注釋如何去做、變量如何命名、軟件配置管理如何操作，這里面既有很常規(guī)的方法，也有一些我們司空見慣然而是錯(cuò)誤的做法。信手舉上幾個(gè)值得注意的細(xì)節(jié)供參考。
變量定義時(shí)宜將變量類型的變量名程中體現(xiàn)于其中；如AD_result_int、Cal_result_float等。這樣為的好檢查，防止數(shù)據(jù)類型的強(qiáng)制轉(zhuǎn)換或強(qiáng)制賦值時(shí)出現(xiàn)數(shù)據(jù)類型的錯(cuò)誤；
注釋要充分；
代碼的布局風(fēng)格宜統(tǒng)一，便于閱讀查找；
不可出現(xiàn)非受控的default流程，所有數(shù)值和變量，不論是調(diào)用函數(shù)時(shí)賦予的、讀取接口讀進(jìn)來的、還是中間變量計(jì)算出來的，在應(yīng)用前都宜作數(shù)據(jù)有效性的判斷，并對判定的所有可能結(jié)果均做受控的對應(yīng)處理。
關(guān)于軟件可維護(hù)性編程方法方面的文章資料在網(wǎng)上是鋪天蓋地，不予贅述，綜合采用之即可。很多文章把軟件可維護(hù)性編程規(guī)范推薦做成企業(yè)的嵌入式軟件可靠性設(shè)計(jì)規(guī)范，實(shí)在是有點(diǎn)以偏概全，有失偏頗的。
軟件代碼在執(zhí)行中容易出現(xiàn)的下一個(gè)問題是跑飛，程序指針受到干擾，跳轉(zhuǎn)到了一個(gè)非受控位置，執(zhí)行了不該執(zhí)行的代碼。如果執(zhí)行了不該執(zhí)行的代碼，如果在程序中加入了足夠的變量判斷、讀值判斷、狀態(tài)檢測判斷等，那倒還好了，后果也不會太嚴(yán)重，甚至最終還是可能自己跑回來的。但有一種跑飛是比較可怕的，一般我們在ROM中存放的程序目標(biāo)代碼是1-3字節(jié)的指令，就是最多3條字段的目標(biāo)碼組成了執(zhí)行動作，如果程序指針跑飛到了某個(gè)3字節(jié)指令的第2個(gè)字節(jié)上的時(shí)候，執(zhí)行的后果是什么，可就真的沒人知道了，即使在程序上作了足夠的數(shù)據(jù)判錯(cuò)、邏輯跳轉(zhuǎn)的防范措施，結(jié)果也不會好。而且ROM一般是不可能全部都被程序代碼填滿的，總有富余空間，富余空間中的默認(rèn)內(nèi)容是啥，這些默認(rèn)字節(jié)是否也會導(dǎo)致一些操作呢？單片機(jī)中的默認(rèn)空間是0FFH，DSP的我沒查過，大家有興趣查一下，跳到這些字段里，也是容易出麻煩的。
好了，不再羅嗦，直接給出解決方法吧，就是每隔一段程序代碼或控制區(qū)域，就人為放置上幾個(gè)NOP指令，在NOP指令后放置一個(gè)長跳轉(zhuǎn)的ERR處理程序。注意NOP最少放置3個(gè)，這樣任何的跑飛最多只能占用2個(gè)NOP，第三個(gè)NOP一樣還是能把程序代碼揪回來，揪回來后就執(zhí)行ERR處理程序。
如果碰到安全性、可靠性等級要求比較高的程序，推薦的處理方法可以采用熱備份的處理方法，即用兩段代碼同時(shí)執(zhí)行同一個(gè)功能，執(zhí)行的結(jié)果進(jìn)行對比，如果一致則放行通過，如果結(jié)果不一致，怎么處理就看個(gè)人。
安全性和可靠性的編程細(xì)節(jié)注意事項(xiàng)還有很多，窺一斑難見全豹。
4、數(shù)據(jù)、變量
變量的定義是為的避免各種混淆，同一程序內(nèi)數(shù)據(jù)和數(shù)據(jù)的混淆、不同人讀程序時(shí)對變量理解上出現(xiàn)的二義性、視覺效果上容易出現(xiàn)的錯(cuò)誤（字母的“o”和數(shù)字的“0”，字母的“l”和數(shù)字的“1”）。這里要遵循一個(gè)“要么相同，要么迥異”的基本規(guī)則，這條規(guī)則在很多的領(lǐng)域都有應(yīng)用。在結(jié)構(gòu)的防呆性設(shè)計(jì)上，接插件的選型也是如此，如果一個(gè)乳白色和一個(gè)淺灰色的同類接插件，最好的選擇是有很直觀的視覺差異或結(jié)構(gòu)的差異，或者干脆就是相同的，相同須基于一個(gè)前提，互換性要好。
用顯意的符號來命名變量和語句標(biāo)號。標(biāo)識符的命名有明確含義，且是完整單詞或易理解的縮寫。短單詞通過去掉“元音”形成縮寫；長單詞取頭幾個(gè)字母形成縮寫；一些單詞有公認(rèn)的縮寫。如：
Temp — tmp；
Flag — flg；
Statistic — stat；
Increment — inc；
Message — msg。
特殊約定或縮寫，要有注釋說明。在源文件開始處，對使用的縮寫或約定注釋說明。自己特有的命名風(fēng)格，要自始至終保持一致。對于變量命名，禁止取單個(gè)字符（如i、j、k...）；含義+變量類型、數(shù)據(jù)類型等，i、j、k作局部循環(huán)變量是允許的，但容易混淆的字母慎用。如int Liv_Width，L代表局部變量（Local）（g全局變量Global）、i代表數(shù)據(jù)類型（Interger）、 v代表 變量（Variable）（c常量Const）、Width代表變量的含義，這種命名方式可防止局部變量與全局變量重名。
禁用易混淆的標(biāo)識符（R1和Rl，DO和D0等）來表示不同的變量、文件名和語句標(biāo)號。
除了編譯開關(guān)/頭文件等特殊應(yīng)用，避免使用_EXAMPLE_TEST_之類以下劃線開始和結(jié)尾的定義。
全局變量是戰(zhàn)略性資源，它決定了模塊和模塊間的耦合度，需在項(xiàng)目上提升到一個(gè)足夠高的高度，慎用全局變量，不得不用的時(shí)候，要單獨(dú)為每一個(gè)全局變量編寫?yīng)毩⒌牟僮髂K或函數(shù)，在修改全局變量的時(shí)候，要檢查是否有別的函數(shù)在調(diào)用它并且需要此數(shù)值保持穩(wěn)定。
對變量代表某個(gè)特定含義的時(shí)候，盡量不要僅僅用位來代表什么，比如用某變量的第零位代表某個(gè)狀態(tài)（0000 0001，其中僅用1代表某個(gè)內(nèi)容，這樣01H、03H、05H… 會有很多個(gè)組合都能代表這個(gè)狀態(tài)）；位容易受干擾被修改，信息出現(xiàn)錯(cuò)誤的幾率大很多。
也不要用00H、FFH等數(shù)據(jù)代表，就像我們面試一群人一樣，第一個(gè)被面試人和最后一個(gè)被面試人容易被記住，00H和FFH亦然，系統(tǒng)默認(rèn)狀態(tài)是00和FF的時(shí)候較多，他們?nèi)菀妆粡?fù)位或置位成這類數(shù)值。推薦以四位的二進(jìn)制碼的某個(gè)中間值為狀態(tài)變量，如1001。
變量數(shù)據(jù)在應(yīng)用之前宜作數(shù)據(jù)類型和數(shù)值范圍的判斷；
數(shù)據(jù)在存儲過程中也容易出現(xiàn)問題，EEPROM、RAM等都有過類似的案例。數(shù)據(jù)出錯(cuò)時(shí)避免不了的，解決的辦法是學(xué)花旗銀行等美國金融企業(yè)，之所以在9.11后他們能很快恢復(fù)業(yè)務(wù)，基本沒有數(shù)據(jù)方面的損失，原因何在？因?yàn)樗麄冇挟惖厝轂?zāi)數(shù)據(jù)備份系統(tǒng)，知里面有兩個(gè)關(guān)鍵詞，異地、備份。我們的信息也同樣，首先選擇存在不同的介質(zhì)中、或相同的介質(zhì)但迥異的存放環(huán)境和位置下，雙重備份的結(jié)局是兩邊不一致的時(shí)候，數(shù)據(jù)被懷疑并拒絕反映執(zhí)行，但嵌入式軟件很多時(shí)候是要靠數(shù)據(jù)來推動執(zhí)行機(jī)構(gòu)的，即使發(fā)現(xiàn)數(shù)據(jù)有問題也不允許行政不作為，這種情況下，作為我們也很難辦，2個(gè)不同的數(shù)據(jù)，有明顯問題的還好排除，都在有限范圍內(nèi)可如何判定哈？這種時(shí)候沒辦法只好三備份，少數(shù)服從多數(shù)是唯一的選擇了。石頭剪刀布的方式不好用，葛優(yōu)的分歧終端機(jī)也不適用，就只好選擇這種最原始最有效的辦法了，唯一需要注意的是數(shù)據(jù)宜存放于三種不同的備份環(huán)境下。
以上僅就嵌入式軟件可靠性的關(guān)注方面分了幾大類，進(jìn)行了基本的描述，實(shí)際應(yīng)用中，需要關(guān)注的點(diǎn)還有很多很多，如果是準(zhǔn)備自行制定設(shè)計(jì)規(guī)范的話，以上的思路應(yīng)該也可以給與一些啟迪了。
