上回更新到主機(jī)廠在內(nèi)部做危險(xiǎn)分析和風(fēng)險(xiǎn)評估(HARA), 進(jìn)而定義了安全目標(biāo)（Safety Goal), 這篇會基于安全目標(biāo)繼續(xù)進(jìn)行下去。

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

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

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

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

• 檢測汽車是否碰撞功能

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

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

• 
  

而安全功能需求譬如有：

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

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

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

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

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

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

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

• 應(yīng)該從功能安全目標(biāo)和安全狀態(tài)來獲得。

• 每一個(gè)功能安全目標(biāo)都必須有一個(gè)或多個(gè)相應(yīng)的功能安全需求。

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

在功能安全的分配上：

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

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

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

如果你能看到這里，說明你對功能安全情有獨(dú)鐘。希望你堅(jiān)持看這個(gè)系列，因?yàn)楹竺鏁?strong>更沒意思。

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

后會有期，不見不散。