在上回講完功能安全的定義以后，"是什么" 和 "為什么" 的問題，我們已經搞懂了。接下來就要看看重點，"怎么樣" 的問題。

主機廠在研發(fā)一款汽車平臺的初期，會基于以往大量的工程和實際經驗，把整車的功能細分到不同的子系統里，比如車載娛樂系統，底盤和驅動系統，輔助駕駛和車身照明系統等等。

以下以被動安全輔助系統來舉例。

被動安全輔助系統，比如安全帶和安全氣囊就屬于被動安全系統的一部分。假如汽車在發(fā)生碰撞以后，安全帶會收緊，并且相應的安全氣囊會彈出。

當主機廠劃分子系統到安全氣囊控制器的時候，當然要描述一下，這個控制器的功能，是否是一個電子設備，這個控制器與其他控制子系統的接口，還有例如法律法規(guī)的要求，比如被動安全系統是法律要求。這是在引入功能安全以前已經現成有的東西。

當現在加上功能安全，我們考慮安全氣囊控制器的時候，主機廠會基于以往的經驗，比如這個控制器在以往出現過什么問題，具體的原因是什么？例如曾經最大的安全氣囊生產商高田就因為設計原因不得不召回而在日本申請破產。

基于這些對基礎功能的描述和以往故障的分析，主機廠通過對安全氣囊開發(fā)的范圍做出劃分和描述，這就是所謂的 ISO 在第三章 item 定義的要求。當然了，具體還有很多詳細的內容，此處不一一展開。

當有了這些item的功能要求和故障信息，主機廠會在內部進行評定審核，主要的任務是，去判斷當之前定義的item在不同工況出現不同故障的情況下，駕駛員和乘客是否受有威脅到人身安全的風險，以及去評定風險的等級。這就是頂頂有名的HARA (Harzard Analysis and Risk Assesment)

還是以安全氣囊舉例說明：

首先構想不同的使用情景：

汽車狀態(tài)：

停車

駐車

行駛 0-30km/h

行駛 >30km/h

路況信息：

濕滑

干燥

市區(qū)

高速

道路信息：

彎道

直行

以下舉例說明：

當安全氣囊控制器的指示功能出現故障的時候：

- 汽車以20km/h的速度行駛在干燥路面的市區(qū)時

- 汽車以100km/h的速度行駛在濕滑的高速公路時

當安全氣囊控制器的檢測功能出現故障的時候：

- 汽車以20km/h的速度行駛在干燥路面的市區(qū)時

- 汽車以100km/h的速度行駛在濕滑的高速公路時

當安全氣囊控制器出現故障自動彈出的時候：

- 汽車以20km/h的速度行駛在干燥路面的市區(qū)時

- 汽車以100km/h的速度行駛在濕滑的高速公路時

等等...(此處有成百上千行)

分別對下面三個因素進行量化分析：

- 對應故障發(fā)生事故的人員傷亡嚴重程度  --> S 代表severity

- 對應故障出現的頻率 --> E 代表Exposure

- 駕駛員是否能控制汽車  --> C 代表Controllablity

并按照下圖, 對號入座：1-3 代表不同的程度。進而得到相應風險 的ASIL 等級

最后取在不同情況下最高的ASIL等級為該產品研發(fā)時的功能安全要求等級。這個ASIL將伴隨安全氣囊供應商的整個研發(fā)以及售后流程，根據這個級別，將定義和劃分對應軟件，硬件等功能安全相關的工作。此處劃重點，以后慢慢講具體在供應商開發(fā)軟件時如何根據ASIL來做相應的工作。

根據不同的風險，與之對應的是新加的功能安全需求。也就是安全目標 (safety goal).

例如：

SG1：如果安全氣囊系統的檢測傳感器出現故障，駕駛員應該在汽車駕駛的過程中得到故障提醒。

SG2：在汽車行駛過程中，氣囊不能在無碰撞的情況下彈出

等...

可能你會發(fā)現，有的功能安全需求跟功能需求大相徑庭，這兩個需求有部分重疊的情況，但是功能安全側重于當出現故障，設備系統如何處理故障進而規(guī)避和降低對人造成的風險。而功能需求側重于如何實現具體的功能。實現功能是功能安全的基礎。所以往往在研發(fā)過程中，功能安全研發(fā)工作會比功能開發(fā)工作晚開始，比較繞口，請見諒?？梢院唵卫斫鉃椋谝徊綄崿F所有的功能，當部分功能與功能安全需求相關時，需要做額外的工作來保證此功能安全。

我們知道，汽車領域的需求，設計都要對應相應的測試結果。安全目標(safety goal) 對應的就是將來非常麻煩的并且需要獨立第三方評測的 safety case,這個我們以后文章會提到。

寫到這里，意猶未盡，下回再見吧。