嵌入式軟件應用場合、硬件平臺及操作系統的多樣性，使嵌入式軟件在各種不同條件下可能出現未知、不可預測的狀況，即其潛在風險往往比通用PC機的軟件要高。由于嵌入式軟件應用場合特殊，往往在無人值守的情況下運行，高可靠性和安全性自然成為嵌入式系統的重要指標。

在設計初期排查各種可能的風險，投入較低并可獲得高回報。最終的產品質量也可以得到很好的控制。下面借鑒安全管理學思想，列舉一些生活實例說明嵌入式軟件設計的安全理念。

1 圍墻問題

學校修筑圍墻，有一個問題——到底需要的高度是多少?過低，很容易翻越圍墻進出，起不到圍墻的屏障作用；過高，翻越的人滑落容易傷亡，這也不是修筑圍墻的初衷。程序設計中的程序運行異常好比非法進出校園。一方面需要防止程序異常，這就類似修了圍墻。但另一方面也需要注意圍墻高度：圍墻過高，輕易不出問題，但一出就是大問題。比如數據通信傳輸程序，加入CRC冗余校驗。如果數據傳輸出現校驗錯誤，CRC冗余校驗可能恢復錯誤的數據。但是如果在設計測試初期就使用CRC校驗，并且程序中沒有警告信息，就有可能將錯誤延續到產品發布階段。產品到現場出問題那就嚴重了。還有一個例子，看門狗程序是為了程序異常時自動重啟恢復系統。如果在程序測試期間就使用看門狗，同樣會屏蔽測試期間的程序跑飛、死機等問題，是不利于發現程序缺陷的。

2 修褲腳問題

給孩子買了條褲子，試穿后發現褲子長了些，于是很精確地測量出需要截去10 cm。問題出現了，媽媽動手改好了之后，奶奶也給改短了10 cm，接下來的情景可想而知。這就是溝通問題，某成員在對某對象實施某行為的時候沒有留下任何標記，使得其他成員未得到準確信息，帶來下一步行為的失誤。

程序設計中同樣也有類似問題。比如某進程對一個臨界資源進行訪問，并且沒有任何標記，如果另一進程也訪問該資源就會造成資源訪問的沖突。通過信號量互斥保護就可以解決這一問題。另一個例子是在內存申請和釋放方面。比如函數funA（）調用funB（），在funA（）或funB（）中動態申請一段內存空間，并且將指向該內存的指針傳給另一函數，在funA（）或funB（）中都可以釋放內存。但是一定注意，需要溝通在哪個函數里進行，尤其當這兩個函數分別由兩個人完成的時候。不能出現兩個函數都釋放該內存或都不釋放該內存的情況。

3 優勢和不足

兩個游人出行，一個帶傘，另一個不帶傘。那天下了大雨，結果回來時帶傘的人被淋得全身濕透，而不帶傘的反而未被淋濕。原因何在?因為帶傘的人認為自己帶了傘不用躲雨，不知不覺就濕透了；不帶傘的知道在雨中幾秒鐘就能全身濕透，所以一直注意在亭子下躲雨。

程序設計中何嘗不是如此?對認為不容易出問題的代碼設計投入不足，測試工作少，對易出問題的代碼投入大量精力，嚴加測試，最后的結果反而是容易出問題的代碼質量更高。這就是設計人員常常遇到的情況——能想到的錯誤都解決了，想不到的錯誤都出現了。另外一個例子是：對于RS232串口通信，考慮到通信傳輸距離、外界干擾等問題，采用了數據校驗和錯誤重發機制；對于I2C、SPI總線往往是短距離、同一電路板的芯片訪問，都沒有任何數據校驗措施。結果有可能是RS232串口數據總是正確的，I2C、SPI總線的數據受不合理的布線及電磁干擾影響反而出現錯誤。因此對于嵌入式系統，需要根據實際的現場情況定制程序設計，而不是因為大多數人都這么做，或以前都這么做。

4 警告和避錯

電線桿上有特別亮麗的幾個字，某行人好奇，爬上電線桿一看，四個大字：“油漆未干”?？梢娺@個告示性文字反而害苦了這位行人。如果換一種方式，將電線桿周圍容易被人接觸到的地方圍上一圈，就能很好地避免路人接觸。當然這里還需要考慮成本和效用的平衡。

嵌入式系統往往不需要人員值守就能正常工作，因此依靠警告、報錯不能解決所有問題。你可以想象在駕駛飛機時，導航屏幕出現類似Windows系統的“內存空間不足，請關閉部分程序”警告的情形是多么可笑。在設計這一類程序的時候，應該考慮程序如何能自動解決一些異常情況，即使有些情況下必須進行人機交互，也應該考慮這時程序是否可以自動采取一些保護措施。比如數據讀取異常報錯，可以考慮用一個默認的數據；通信連接不上報錯則需要檢測通信是否恢復正常。

以上從幾個生活實例用類比的方式說明了嵌入式軟件設計需要注意的一些問題，當然僅僅注意這幾點對保證嵌入式軟件的質量是遠遠不夠的。文章的目的是通過幾個易懂的實例強調設計安全意識以及軟件產品質量意識的重要性。