功能安全需要應對隨機故障和系統(tǒng)故障。軟件只有系統(tǒng)故障，因為軟件沒有隨機故障，因為如果出現(xiàn)相同的情況，軟件故障通常每次都以相同的方式導致系統(tǒng)故障。達到更高安全水平的一種方法是實施雙通道系統(tǒng)，每個通道中都有不同的軟件。具有相同軟件的冗余通道會將軟件作為單點故障。如果兩個通道具有不同的軟件，那么爭論是它們不太可能同時以相同的方式失敗，從而允許更高的SIL索賠。聽起來不錯，但有問題嗎？讓我們在博客中更深入地或盡可能深入地了解。

首先，讓我們看一下IEC 61508中提供了哪些指導，然后看看文獻中提供了哪些指導以及一些基于多樣性的設計模式。

在IEC 61508-3：2010中，以下子條款涵蓋了這一點

圖 1 - IEC 61508-3 的相關摘錄

看看IEC 61508-2：2010子條款7.4.3說SC（系統(tǒng)能力）最多只能提高一個級別。因此，例如，如果兩個軟件的SIL聲明為SIL 1，那么組合最多為SIL 2。我想最多只允許增加一個的限制是存在的，因為將這兩個項目結合起來的人不知道各個開發(fā)的細節(jié)，也許可能存在一些隱藏的常見原因故障，例如使用的工具。如果從頭開始開發(fā)這兩個軟件，你可能會做得更好。

IEC 61508-3 附錄 A 中的表格提供了一些指導，表 A.2 提供了不同架構的四種替代版本，表 A.10 要求對軟件進行 CCF（常見原因故障）分析，此措施建議在 SIL 2 中，強烈建議用于更高的 SIL。

圖 2 - IEC 61508-3：2010 摘錄

但是開發(fā)各種軟件有多難。Philip Koopman在他的優(yōu)秀著作“更好的嵌入式系統(tǒng)軟件”第26.3.3節(jié)中對這個話題有一個很好的評論。在本節(jié)中，他指出，實現(xiàn)真正多樣化的軟件確實很困難，但很容易獲得一定程度的多樣性。他指出，量化所實現(xiàn)的多樣性也很難，這并不奇怪，因為硬件CCF分析在標準中有更多的指導，仍然更多的是工程判斷而不是科學。Philip Koopman進一步警告說，“許多人（包括我們）認為，如果你的時間和資源有限，你最好制作一個真正好的軟件版本，而不是試圖制作兩個獨立的版本，而這兩個版本本身就沒有那么好。兩個版本中可能會有太多相同的錯誤。

我看了看是否有任何研究來支持這一觀點。我看到的關于這個主題最有趣的筆記是下面顯示的，他們給 27 名學生提供了一個規(guī)范，并要求他們編寫軟件來實現(xiàn)它，然后檢查有多少不同的軟件以同樣的方式失敗。它確實支持了編寫各種軟件確實很難的觀點。

圖3 - 關于不同軟件價值的有趣實驗論文

然后是HSE數(shù)據(jù)，它們顯示了編碼階段（設計和實現(xiàn)）中很少的錯誤，這表明除非規(guī)范具有多樣性，否則您不會獲得很多好處。

圖4 - 系統(tǒng)因HSE而失敗的原因

為波音777開發(fā)電傳飛行軟件的團隊似乎已經采用了三種不同的軟件，開發(fā)了三種不同的規(guī)格，使用三個不同的開發(fā)團隊，他們不應該相互交談，運行在三臺不同的（不同的）計算機上控制飛機。然后，當其中一個產出與其他產出不一致時，使用選民來選擇行動方案。

航天飛機使用了一種類似的架構，使用五臺計算機，四臺相同，一臺不同。各種微型計算機上的軟件也多種多樣。

基于多樣性的功能安全軟件的一種設計模式是N版本編程，它使用根據(jù)同一組需求開發(fā)的不同代碼的多個版本，并對其輸出進行投票。

圖 5 - N 版本編程模式的繪制（安全關鍵型嵌入式系統(tǒng)的設計模式）)

如果我們將上述內容視為可靠性框圖，那么投票者是CCF來源的明顯弱點，除非投票者是超可靠的，否則從高值N中獲得的好處將是有限的。

讓我們將多樣化的軟件方法與一些替代方案進行比較。雙核鎖步微控制器不實現(xiàn)軟件分集，而是一種硬件安全機制，因為兩個內核將運行相同的軟件。相比之下，軟件鎖步/軟件 RMT 與逐周期鎖步不同，可以實現(xiàn)軟件多樣性，但比時鐘逐周期鎖步方法檢測差異的時間更長。軟件鎖步可以在不同的處理器上運行，甚至可以在單個處理器的冗余線程上運行，并在選定的觀察點比較它們的輸出。

即使您實施了各種軟件，用于生產軟件的工具呢？這些也可能是常見原因故障的根源，但如果在CCF中考慮到這一點并選擇了不同的工具，或者選擇的工具以滿足整體安全功能的SIL要求，或者您使用適合組合元件SIL的工具，您可能很高興。

審核編輯：郭婷