功能安全中的軟體隔離（一）

說到功能安全繞不開的一個話題是ASIL分解。而軟體隔離就是出於不同ASIL 等級要求提出的。先說說ASIL分解吧。為了降低軟硬體的開發難度，功能安全提供了ASIL分解的思路，為什麼要做ASIL分解呢？個人總結從軟硬體兩方面說：

1，硬體上說，能達到ASIL C要求的晶元要求，要麼沒有，要麼貴（很多廠家都聲稱自己的晶元做到了ASIL C或者ASIL D，但是如果要求完整的認證材料或是按ISO26262標準去摳細節，例如是否有符合要求的FMEDA等，就達不到要求）。系統降級可以降低硬體要求，同時降低成本（也有可能增加，因為冗餘設計）

2，軟體上說，就是為了降低開發難度。功能安全的軟體開發，有個分水嶺，就是ASIL C。當軟體開發從ASIL B跨到ASIL C的要求，就是一個質的跨越了。假設我們只選擇實現ISO26262的「++」號（強烈建議）的內容（知名車廠會要求一個「+」也要實現，不實現需要給出理由），則在ASIL C與ASIL B相比有兩個難度較高的要求

一是防禦性編程，二是程序流監控。這兩個概念在傳統的嵌入式編程中較少被提到，雖然我們平時編寫軟體時多多少少有做到一部分內容，防禦性編程例如使用while循環時使用阻塞處理，可跳出循環，防止數組越界，防止除0，關鍵數據備份等。程序流監控如果使用看門狗的話，也實現了一部分。但如果嚴格執行起來，會增加很多的編程難度。例如程序流監控，需要監控各個模塊的調用順序，要有在線檢測的能力。防禦性編程也是永無止境的，增加了很多代碼量。除此之外對於編碼規則和測試的要求也是高出很多，具體參照ISO 26262-PART6可看，或後面有時間的時候再展開說說。

在ISO 26262的PART9中有詳細介紹，下圖是標準中推薦的ASIL分解方法

ASIL分解需要注意的點，在這抄一下從別處引用的內容：

ASIL 分解的一個最重要的要求就是獨立性，如果不能滿足獨立性要求的話，冗餘單元要按照原來的ASIL等級開發。所謂的獨立性就冗餘單元之間不應發生從屬失效（Dependent Failure），從屬失效分為共因失效（Common Cause Failure）和級聯失效（Cascading Failure） 兩種。共因失效是指兩個單元因為共同的原因失效，比如軟體複製冗餘，冗餘單元會因為同一個軟體bug導致兩者都失效，為了避免該共因失效，我們採用多種軟體設計方法。級聯失效是指一個單元失效導致另一個單元的失效，比如一個軟體組件的功能出現故障，寫入另一個軟體組件RAM中，導致另一個軟體組件的功能失效，為了控制該級聯失效，我們採用內存管理單元，可以探測到非法寫入RAM的情況。

ASIL分解是看起來簡單，但真正操作起來會變得很複雜的活，涉及到RAM,FLASH的隔離，TASK的分配，各種獨立性分析，安全分析，不勝繁瑣。

看來本篇只能介紹下背景了，受限於本人碼字水平太差，寫著寫著就跑題，見諒。最近也忙到不行，偶爾插空總結一下，就暫時先這樣吧。

推薦閱讀：