1、引言
汽車上電子/電氣系統（E/E）數量不斷的增加，一些高端豪華轎車上有多達70多個ECU（Electronic Control Unit電子控制單元），其中安全氣囊系統、制動系統、底盤控制系統、發動機控制系統以及線控系統等都是安全相關係統。當系統出現故障的時候，系統必須轉入安全狀態或者轉換到降級模式，避免系統功能失效而導致人員傷亡。失效可能是由於規範錯誤(比如安全需求不完整)、人爲原因的錯誤(比如：軟件bug)、環境的影響( 比如：電磁干擾)等等原因引起的。爲了實現汽車上電子/電氣系統的功能安全設計，道路車輛功能安全標準 ISO 26262[1]於2011年正式發佈，爲開發汽車安全相關係統提供了指南，該標準的基礎是適用於任何行業的電子/電氣/可編程電子系統的功能安全標準IEC 61508[2]。
ISO 26262標準中對系統做功能安全設計時，前期重要的一個步驟是對系統進行危害分析和風險評估，識別出系統的危害並且對危害的風險等級——ASIL等級（Automotive Safety Integration Level，汽車安全完整性等級）進行評估。ASIL有四個等級，分別爲A，B，C，D，其中A是最低的等級，D是最高的等級。然後，針對每種危害確定至少一個安全目標，安全目標是系統高級別的安全需求，由安全目標導出系統級別的安全需求，再將安全需求分配到硬件和軟件。ASIL等級決定了對系統安全性的要求，ASIL等級越高，對系統的安全性要求越高，爲實現安全付出的代價越高，意味着硬件的診斷覆蓋率越高，開發流程越嚴格，相應的開發成本增加、開發週期延長，技術要求嚴格。ISO 26262中提出了在滿足安全目標的前提下降低ASIL等級的方法——ASIL分解，這樣可以解決上述開發中的難點。
本文首先介紹了ISO 26262標準中的危害分析和風險評估階段中的ASIL等級確定方法，然後介紹了ASIL分解的原則，並輔以實例進行說明。
2、危害分析和風險評估
依據ISO 26262標準進行功能安全設計時，首先識別系統的功能，並分析其所有可能的功能故障（Malfunction），可採用的分析方法有HAZOP，FMEA、頭腦風暴等。如果在系統開發的各個階段發現在本階段沒有識別出來的故障，都要回到這個階段，進行更新。
功能故障在特定的駕駛場景下，纔會造成傷亡事件，比如近光燈系統，其中一個功能故障就是燈非預期熄滅，如果在漆黑的夜晚行駛在山路上，駕駛員看不清道路狀況，可能會掉入懸崖，造成車毀人亡；如果此功能故障發生在白天就不會產生任何的影響。所以進行功能故障分析後，要進行情景分析，識別與此故障相關的駕駛情景，比如：高速公路超車、車庫停車等。分析駕駛情景建議從公路類型：比如國道、城市道路、鄉村道路等；路面情況：比如溼滑路面、冰雪路面、乾燥路面；車輛狀態：比如轉向、 超車、制動、加速等；環境條件：比如：風雪交加、夜晚、隧道燈；交通狀況：擁堵、順暢、紅綠燈等；人員情況：不如乘客、路人等幾個方面去考慮。
功能故障和駕駛場景的組合叫做危害事件（hazard event）， 危害事件確定後，根據三個因子——嚴重度（Severity）、暴露率（Exposure）和可控性（Controllability）評估危害事件的風險級別——ASIL等級。其中嚴重度是指對駕駛員、乘員、或者行人等涉險人員的傷害程度；暴露率是指人員暴露在系統的失效能夠造成危害的場景中的概率；可控性是指駕駛員或其他涉險人員能夠避免事故或傷害的可能性。這三個因子的分類在表1中給出。
表1、嚴重度、暴露率、可控性分類
ASIL等級的確定基於這三個影響因子，表2中給出了ASIL的確定方法，其中D代表最高等級， A代表最低等級，QM表示質量管理（Quality Management），表示按照質量管理體系開發系統或功能就足夠了，不用考慮任何安全相關的設計。確定了危害的ASIL等級後，爲每個危害確定至少一個安全目標，作爲功能和技術安全需求的基礎。
表2、ASIL等級確定
下面以EPB（Electrical Park Brake）系統爲例介紹如何進行危害分析和風險評估。
EPB較傳統的駐車制動器，除了駐車功能，還有動態起步輔助功能、緊急制動功能以及自動駐車功能等。這裏我們以駐車功能爲例，當駐車時，駕駛員通過按鈕或其它方式發出制動請求，EPB系統在汽車的後輪上施加制動力，以防止車非預期滑行。該系統的危害有：非預期制動失效、非預期制動啓動。相同的危害在不同的場景下的風險是不一樣的，所以我們要對不同的駕駛場景進行分析。爲了簡化問題，這裏我們僅對”非預期制動失效”這種功能故障進行風險評估。表3給出了EPB風險評估表，在該表中我們考慮的駕駛場景是車停在斜坡上，駕駛員不在車上。如果駕駛員在車上的話，駕駛員可通過踩剎車控制汽車滑行，可控性增加，那麼所評估的ASIL等級會比表中的ASIL D低，但是對於同一個安全目標，如果評估的ASIL等級不同的話，要選擇ASIL等級高的那個。
表3、EPB風險評估
通過以上分析，得出EPB系統的安全目標爲：防止制動失效，ASIL等級爲D。
3、ASIL分解原則
通過上節介紹的危害分析和風險評估，我們得出系統的安全目標和相應的ASIL等級，從安全目標可以推導出開發階段的安全需求，安全需求繼承安全目標的ASIL等級。如果一個安全需求分解爲兩個冗餘的安全需求，那麼原來的安全需求的ASIL等級可以分解到兩個冗餘的安全需求上。因爲只有當兩個安全需求同時不滿足時，才導致系統的失效，所以冗餘安全需求的ASIL等級可以比原始的安全需求的ASIL等級低。ISO 26262標準的第9章給出了ASIL分解的原則，如圖1所示。
分解後的ASIL等級後面括號裏是指明原始需求的ASIL等級，比如ASIL D等級分解爲ASIL C(D)和ASILA(D)等，因爲集成和需求的驗證仍然依據其原始的ASIL等級。ASIL 分解可以在安全生命週期的多個階段進行，比如功能安全概念、系統設計、硬件設計、軟件設計階段。而且ASIL等級可以分多次進行，比如ASIL D等級分爲ASIL C(D)和ASILA(D)，ASIL C(D)還可以繼續分解爲 ASIL B(D)和ASIL A(D )。
但是ASIL 分解的一個重要要求就是獨立性，如果不能滿足獨立性要求的話，冗餘單元要按照原來的ASIL等級開發。所謂的獨立性就冗餘單元之間不應發生從屬失效（Dependent Failure），從屬失效分爲共因失效（Common Cause Failure）和級聯失效(Cascading Failure) 兩種。共因失效是指兩個單元因爲共同的原因失效，比如軟件複製冗餘，冗餘單元會因爲同一個軟件bug導致兩者都失效，爲了避免該共因失效，我們採用多種軟件設計方法。級聯失效是指一個單元失效導致另一個單元的失效，比如一個軟件組件的功能出現故障，寫入另一個軟件組件RAM中，導致另一個軟件組件的功能失效，爲了控制該級聯失效，我們採用內存管理單元，可以探測到非法寫入RAM的情況。
圖1、ASIL分解原理圖
下面以一個例子介紹ASIL 分解的過程。
假設功能F，其輸入信號爲S1，S2，S3，這三個信號分別測量不同的物理量，是相互獨立的，經過ECU內部的邏輯運算後，發送觸發信息給執行器Actuator，功能F的架構示意圖如圖2所示。假設經過危害分析和風險評估後，功能F的ASIL等級爲ASIL D，安全目標爲避免非預期觸發執行器。那麼功能F的各個部分繼承ASIL等級，即傳感器、ECU、執行器都需要按照ASIL D 等級開發，如圖3所示。
圖2、功能F架構示意圖
圖3、ASIL等級在功能F架構上的分配圖
經過進一步的分析發現，當速度V>閾值時，非預期觸發執行器，才能造成危險。那麼我們在功能F的架構中，加入一個安全機制，安全機制的功能是當檢測到速度V大於閾值時，不允許觸發執行器。那麼功能F的架構變爲如圖4所示。
圖4、加入安全機制後的架構
功能F和安全機制是冗餘安全需求，同時來滿足安全目標，因此可以將功能F原來的ASIL等級在這兩個需求上進行分解，分解爲ASIL D(D)和QM(D)，分解後的ASIL等級如圖5所示。
圖5、ASIL分解後架構示意圖
原來的傳感器S1、S2、S3按照QM開發，速度傳感器按照ASIL D開發，ECU裏面的軟件，原來的邏輯按QM開發，安全機制的邏輯按照ASIL D開發，不同ASIL等級的軟件存在於一個ECU內，爲了保證軟件之間的獨立性，保證兩者之間不相互影響，需要考慮內存保護機制，合適的調度屬性來保證存儲空間和CPU時間的獨立性，這樣會增加軟件開發的很多成本。那麼我們進一步採取硬件上的分離來保證獨立性，我們選擇一個成本很低的簡單的芯片（比如PGA, Programmable Gate Array）來運行安全機制中的軟件（如圖6所示）。需要注意的是PGA要使用獨立的電源和時鐘。
圖6、改進的ASIL分解後架構示意圖
經過分解後，按照ASIL D開發的功能邏輯簡單，使得開發變得簡單，整體成本也得以降低。
4、結論
本文以EPB爲例介紹了ISO 26262標準中安全目標及其ASIL等級確定的方法，安全目標的ASIL等級被開發階段安全需求繼承，如果安全需求的ASIL等級高，那麼需要進行ASIL分解以降低ASIL等級，本文以實例介紹了ASIL分解的原則和步驟。ASIL分解並沒有在ISO 26262中被強制要求執行，但是我們可以通過對系統進行分析、進而對系統架構進行調整，實現ASIL分解，可以解決因ASIL等級高而帶來的開發成本、開發週期和技術要求等方面的問題。