上回更新到主機廠在內部做危險分析和風險評估(HARA), 進而定義了安全目標（Safety Goal), 這篇會基于安全目標繼續(xù)進行下去。

主機廠引入了下一個階段的工作，名字叫“功能安全概念” （functional safety concept）中文概念比較難理解，這是一個concept，但是中文的定義是“概念”，個人認為翻譯的不是很好。我寧愿把它當做一個 “構想” 或者 “實施的方法”，這個過程主要是為了通過之前定義的安全目標，來確定具體的功能安全需求。并將它們初步的分配到設計架構中，以滿足實現(xiàn)功能安全的終極目標，讓“所有的風險都變得可以接受”，（absense of unresonable risk）忘記的話，回頭看看第二篇文章。到底啥玩意是功能安全-3

這里有個非常重要的實踐經驗，就是在這個階段，主機廠或者部分一級供應商要把實現(xiàn)基礎功能的需求和功能安全需求分開。這樣不僅能在未來的工作中，節(jié)省大量的人力和時間，也可以讓整個功能安全架構顯得清晰和有條理。

還是拿我們的安全氣囊舉例吧

具體在零件層面 （componet level）的功能要求有

• 檢測汽車是否碰撞功能

• 讀取汽車當前狀態(tài)功能

• 安全氣囊彈出功能等....

• 
  

而安全功能需求譬如有：

• 安全氣囊控制器自檢功能和失效緩解功能，以及故障顯示提醒功能

• 安全狀態(tài)轉換功能 （比如：在判斷無碰撞但是彈出觸發(fā)的時候，安全氣囊保持不彈出狀態(tài)（safe state））

• 故障容錯機制 （比如四個加速度傳感器中有一個出現(xiàn)故障）和仲裁機制等....

以上需求，如有雷同，純屬巧合，我沒做過關于汽車安全氣囊的工作，可能會有錯誤，但是此處的目的是為了說明如何理解功能安全的具體步驟，大伙看的話就圖一樂呵就行。

通過這一個"概念" 階段, 在分析完不同的功能目標(safety goal) 并且細分到功能需求和功能安全需求之后，大概如下圖所示：

功能安全需求會帶著自身的安全等級屬性分配到不同的子系統(tǒng)中。而這里的功能安全需求不同于普通的功能需求，有很多特殊的地方，ISO在功能安全需求的來源和功能安全需求的分配上，有一定的建議和要求。

比如對功能安全需求來源的要求有：

• 應該從功能安全目標和安全狀態(tài)來獲得。

• 每一個功能安全目標都必須有一個或多個相應的功能安全需求。

• 在起草和定義每個功能安全需求時都要有以下屬性：操作模式，故障容錯時間間隔，安全狀態(tài)，功能冗余，急停操作間隔等

在功能安全的分配上：

• 如果子系統(tǒng)繼承了多個功能安全目標，以最高的ASIL等級為該子系統(tǒng)的安全等級，并且相應的信息需要繼續(xù)傳承到該子系統(tǒng)的下屬子系統(tǒng)。

• 如果要分解功能安全等級要求，需要按照 26262-9 第五條款的要求

• 等其他很無聊并且很枯燥的要求。

如果你能看到這里，說明你對功能安全情有獨鐘。希望你堅持看這個系列，因為后面會更沒意思。

開玩笑的，大概理解下這個概念階段之后，下一篇就可以具體到功能安全的實現(xiàn)上，就會有趣的多。

后會有期，不見不散。