由于其不可測試性，因此無法證明軟件的安全性，而是在過去使用相對簡單的邏輯，使用安全繼電器等實現。

然而，鑒于軟件為系統帶來的靈活性和強大功能，它在安全方面的使用是不可避免的。隨著IEC 61508-3等新標準的出現，設計人員可以通過遵循過去已被證明可以提供安全軟件的一組技術來證明他們的軟件足夠安全。

圖2 - 軟件的強大功能

使軟件與硬件不同的因素包括：

軟件不會錄制，所以通常沒有硬性截止日期（換句話說，“一個項目如何遲到一年——一次一天”——布魯克斯·勞）

功能可以在發布后添加 - “他們查看了該軟件并發現它很好。但他們必須有這個功能......“——歸功于麥考密克·

軟件幾乎可以做任何事情，并且經常被要求 - “靈活性的詛咒”

軟件在硬件上運行

雖然軟件不會磨損，也不會像硬件那樣出現隨機故障，但它可能包含系統錯誤。系統誤差是只能通過設計更改（即更改代碼）來消除的錯誤。系統誤差始終存在，但僅在出現一組特定條件時才暴露出來。硬件可靠性使用傳統的可靠性方法，并基于概率。您可以嘗試對軟件使用概率，但軟件失敗的概率為 1;當出現暴露錯誤的適當條件時。

每 1，000 LOC（代碼行）的錯誤數估計值各不相同，但對于良好的代碼，估計值通常在 1 到 10 EPTLOC（每千行代碼的錯誤）范圍內。Addison-Wesley的《軟件評估、基準和最佳實踐》一書給出了各種CMM（能力成熟度模型）級別的數字，如1-7級EPTLOC，2-6級EPTLOC，3級-5 EPTLOC，4級-2 EPTLOC，5級-1 EPTLOC。而其他數據源給出的辦公應用程序每 1，000 行代碼的速率值為 7，工業應用程序為 2，航天飛機應用程序為 0.1。所有這些都顯示了使軟件安全的挑戰。

“軟件安全入門”一書描述了5種類型的軟件錯誤，并估計60%的錯誤與規范和設計有關，40%與編碼有關。

規范錯誤 – 某些功能被省略，因為它沒有記錄在需求中

設計錯誤 – 使用不正確的算法，缺乏自檢......

編碼錯誤 – 無限循環、語法錯誤....

硬件引起的錯誤 – 例如閃存中的位翻轉更改指令

接口錯誤 – 與軟件硬件接口相關的問題

那么，安全標準怎么說。他們提倡一組方法和過程，旨在減少在代碼中引入未檢測到的錯誤的機會。下面的生命周期模型是由IEC 61508：2010倡導的，我將在以后的博客中回到它。這個過程是整體的，從需求到架構到設計，最終到編碼，驗證和確認步驟與每個階段相匹配。

圖 3 - 符合 IEC 61508-3：2010 的軟件 V 型號

通常，與非安全領域倡導的良好軟件開發實踐相比，功能安全標準倡導的流程是嚴格的。

主要差距與以下方面有關

獨立安全評估

刀具認證

與特定類型的分析相關的非常具體的安全要求，例如需要進行故障樹分析或FMEDA

而諸如此類的任務

配置管理

軟件規劃

編碼

功能測試

被標準的非安全高質量開發流程很好地覆蓋。

無論您正在開發的領域如何，都值得一讀的軟件標準的功能安全性包括

IEC 61508-3：2010 – 軟件共識標準的主要非部門特定功能安全

D0-178C – 航空電子軟件安全標準

EN 50128 – 鐵路軟件標準

ISO 26262-6：2011 – 汽車功能安全軟件標準

IEC 62304 – 醫療設備軟件

IEC 60880 – 核軟件安全

UL 1998 – 家用電器軟件的美國標準

雖然上述每個標準的最終域都不同，但每個標準的意圖是相同的，并且在一個標準中描述不好的內容在另一個標準中通常描述得更好。

審核編輯：郭婷