Alex2016-05-19 12:58:47

ISO26262不是一本教招式的武功圖譜，而是一套武功心法口訣。

所以，它語言清楚卻又晦澀。清楚的是你每個字都能看懂，晦澀的是你看懂了也不知道怎麼做。

比如，它說了功能安全經理有幾個職責，其中一條是提高團隊成員的安全意識……這TM是個什麼鬼……

ISO26262自稱提供了全生命週期的安全模型，涉及系統，設計，開發，測試，生產，執行與維護，過程支援等方方面面，建議先從一處入手。如果題主的本職工作是軟體或硬體開發，可以先從AK-EGAS組織的safety monitoring concept入手。

信口開河2017-09-01 14:39:33

前言：

最近研究26262功能安全一段時間，感覺看ISO 26262 標準那從一到十的共十篇文件，無論中文版還是英文版都讓我直犯困，渾身無力。baidu資料也比較少，難道就沒有些簡單易懂的資料分享麼，？？？？不過功夫不負有心人，我去馬雲爸爸的某寶上淘了些培訓資料，TUV、恆潤啊、SGS、IKV的培訓資料都看了，才算是入了門，我就簡單的表達一下自己的一些看法建議。請求板磚·········

1。

先了解大背景，功能安全這個概念的形成與發展

功能安全概念的形成起源於上個世紀。19世紀70年代到80年代，在世界範圍內，尤其是石油化工領域中一些大型專案的生產過程中，多次發生爆炸事故或者嚴重的汙染物洩漏事情。當時業內專家透過系列而系統的分析手段，明確了事故發生的主要原因是因為相關安全控制系統安全功能失效導致的，而造成這些失效的直接原因中，由於電子、電氣、可程式設計邏輯控制器產品自身安全功能不完善導致系統失效的比重是非常大的。

為了提高電子、電氣、可程式設計邏輯控制器產品的安全效能，從1989年開始，世界範圍內的業內專家，對產品安全性設計技術非常重視，並且計劃將電子、電氣及可程式設計電子安全控制系統相關的技術發展為一套成熟的安全設計技術標準。1993年，在包含TÜV SÜD技術專家的專家技術團隊的不斷努力下，誕生了DIN V VDE 0801標準。之後隨著更多業內專家的參與和積極努力，國際電工委員會終於在1998年的時候，正式頒佈了IEC61508（功能安全基礎標準）標準的第一版，並在2010年正式頒佈了該標準的第二版。

到目前為止，除功能安全的基礎標準IEC61508之外，其他相關領域的功能安全系列標準也已經頒佈並得到大量的應用。如專門針對過程控制行業的IEC61511標準，專門針對工廠自動化領域的IEC62061和ISO13849-1標準，專門針對鐵路訊號控制領域的EN5012X系列標準，專門針對核電領域的IEC61513標準…當然，這其中也包含針對道路車輛功能安全領域的專用標準ISO26262。

ISO26262是從電子、電氣及可程式設計器件功能安全基本標準IEC61508派生出來的，ISO26262標準主要定位在汽車行業中特定的電氣器件、電子裝置、可程式設計電子器件等專門用於汽車控制領域的部件和系統，它旨在提高汽車電子、電氣產品功能安全效能。另外此前路人皆知的“踏板門”、“剎車門”等事件，其實和功能安全都有很大的關聯度。

ISO26226標準的核心價值在於，它可以透過系統的功能安全研發管理流程，以及針對汽車電子控制系統硬體和軟體的系統化驗證和確認方法，保證電子系統的安全功能在面對各種嚴酷條件時不失效，從而保證駕乘人員以及路人的安全。對於汽車廠商而言，貫徹執行ISO26262標準不僅可以提高安全效能，提升產品內在價值，也可以最大程度的控制因為電子部件可靠性問題導致的整車召回風險，避免品牌形象受損，避免蒙受較大的經濟損失。

ISO26262標準在今年剛剛正式頒佈，雖然世界範圍內，暫時沒有出現官方層面的強制執行要求，但該標準的執行，將減少因為電子器件失效造成的交通事故和降低潛在召回風險，所以目前國際大型車企非常重視ISO26262標準的應用和推廣。

2、功能安全被定義為：

根據ISO26262，

“Absence of unreasonable risk due to hazards caused by malfunctioning

behavior of E/E systems。”

所以綜合一下、按通俗的理解而言，功能安全就是指汽車即便出現了故障，這個故障也是可控的，不會出現“玩脫了”的情況。實現功能安全是汽車設計的主要目標，也是評價汽車設計的重要標準。

3、ISO/DIS 26262 – 安全生命週期模型

做汽車電控的功能安全，主要是在26262 的4 5 6章節

4、對一些基礎概念的深度理解

工程上的Failure, Error和Fault三者之間區別與聯絡？（IEC 61508和ISO 26262）

Fault的定義

：可能導致系統或功能

失效

的異常條件（

Abnormal condition

that can cause an element or an item

to

fail

。），可譯為

“故障”

。

Error的定義

：計算、觀察或測量

值或條件

，與真實、規定或理論上正確的

值或條件

之間的差異（Discrepancy between a computed， observed or

measured value or condition and the true， specified， or theoretically correct

value or condition。），可譯為

“錯誤”

。Error是能夠導致系統出現Failure的

系統內部狀態

。

Failure的定義

：當一個系統不能執行所要求的功能時，即為Failure，可譯為

“失效”

。（Termination of the ability of an element or an item to

perform a function as required。）

三者關係分析：

· 由於人類試圖透過上述3個基本術語來覆蓋所有現實中的失效場景，所以就有

“Fault

->

Error -> Failure”

。即，

故障發生了，會導致錯誤，錯誤有可能造成系統功能的減弱或喪失

。

· 當Fault是另外一個元件/系統的失效時，則有Failure （Fault） ->

Error

-> Failure

；當將Fault說成是某元件狀態Error時，則有Error （Fault） ->

Error

-> Failure

。

· 事實上，這是一種遞迴迴圈的關係，遞迴關係要成立必須有一個明確的結束條件，這個條件就是要找出Root Cause，否則將無法完成一個失效分析。

風險評估模型

等級評估

。

………………。

先寫到這裡，Mark 一下，研究好了再來補。。。

5、直接看標準確實很枯燥無味，應很多私信要求就發個福利連結，某寶你懂得，為了汽車安全馬雲爸爸確實做了貢獻很大

知乎使用者2017-09-07 03:43:29

資訊共享：

免去某寶

ISO26262，2018 英文原版 Road vehicles Functional safety

連結：

https：//

pan。baidu。com/s/1TEt1AR

p58VtDcKNpxXlx9A

提取碼：mk4r

ISO26262對應的中文版國標是GB/T34590，

連結：

https：//

pan。baidu。com/s/1dLlwZu

M7qMfo5o9noiNJLw

提取碼：x6jx

斷想2018-08-12 15:03:32

大部分人說的都是技術，我來談談行業現狀以及發展前景。

ISO26262是2011年年底正式頒佈的，國內真正做汽車功能安全，也就是從那個時候開始，我接觸過的人裡，最早的那批人都是從萊茵、南德出身的。

他們之前就做過軌道交通的功能安全，對於他們而言，ISO26262這套標準流程只不過是IEC61508的縮簡版，流程體系遷移到汽車上相對容易。

不過，功能安全不僅僅是對於流程體系的瞭解，還需要對於產品開發有一定了解。對於早先從軌道交通功能安全轉到汽車方向上的人來說，也並非輕輕鬆鬆。

相比與汽車功能安全的剛剛起步，軌道交通領域的功能安全已經比較成熟了，發展前景整體來看不如汽車市場。

國內目前汽車功能安全方向專職從業人員預估不超過500人（純屬預估），有人開玩笑說做這個的人屬於大熊貓。

團隊規模比較大且技術實力比較強的，當屬外資供應商：博世，法雷奧，聯電，海拉等。主機廠裡技術實力比較強的應該是泛亞，聽說有接近30人的團隊。

長城，吉利，上汽也有團隊。長城從國外找了一批老外來主導這個，據說比較厲害，但老外下面的工程師大多經驗尚淺。吉利大概只有10幾人專職這個方向，軟硬體都外包給了供應商，內部人員面對供應商時的話語權比較低。上汽內部有自己的團隊，雖然不大，但他們有捷能和聯電。

現狀是供應商比主機廠做的好，但主機廠已經慢慢開始重視功能安全，如果出現一些與功能安全相關的交通事故將會有效加速這個程序。

未來5到10年功能安全發展肯定是上升趨勢，企業大量需要這個方向的人才，但功能安全行業有一個悖論，就是等功能安全在企業的地位足夠高，內部安全流程相對完善的時候，企業對於專職功能安全人員的需求量會下降。

功能安全是產品開發加ISO26262，現在大部分企業更看重大家對ISO26262的理解，比較能夠接受不同產品之間的轉換，但如若10年後不想面臨工作難尋的境況，一定不能忘記鑽研產品本身。

歡迎評論區討論！

建了一個功能安全的微信群，便於大家交流，有想法的可以私信，拉你進群！

小青的風箏2020-04-11 20:10:06

寫在前面

作為一名功能安全工程師，剛從事這份工作時瀏覽這個問題還帶著很多入門前的疑惑，如今再次瀏覽時，自認為可以根據自己的工作經驗輸出一些淺見了。藉著回答這個問題也希望能拋磚引玉，和各位前輩們做進一步探討。

根據我的經驗，探索某一事物的過程也是否定自己認知的過程，所以只能說現在的回答代表自己當前的理解，後續如果有新理解會更新這個答案。

本文試圖回答以下問題：

什麼是功能安全？

功能安全在企業怎麼落地？

功能安全工程師的工作內容

入門時如何對待ISO 26262文件？

功能安全工程師的前景

/*************** 分割線 ***************/

什麼是功能安全（Functional Safety）？

在這裡先引用ISO 26262和GB/T 34590中的定義，從定義展開強調幾個關鍵詞。

ISO 26262：absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems。

GB/T 34590：不存在由電子電氣系統的功能異常表現引起的危害而導致不合理的風險。

“E/E system”，電子電器架構

功能安全要討論的物件是E/E架構設計，因此機械/液壓/化學等設計都不在ISO 26262的研究範圍。

2。 “hazard”，危害

危害有很多型別，如人身傷害或者財產損失等等。功能安全裡的危害僅僅指對

駕駛員或者路人或周邊車輛內人員

（注意：不僅僅是駕駛員）造成的健康傷害。換句話說，功能安全開發目的是避免傷人，而不是避免你的損傷你的豪車，也不是避免你的豪車被偷。

3。 “unreasonable”，不合理的

即“不可被接受的”。就像世界上沒有永動機一樣，世界上也沒有100%安全的系統，因此功能安全追求的是將危害控制在可被接受的範圍。而是否可被接受，需要從兩個維度去衡量：危害的嚴重性和危害發生的頻率。舉例來說，飛機失事幾乎無人生還，但是正因為飛機失事的機率非常低，所以不影響它成為最重要的交通工具之一；電動車窗發生卡滯故障的頻率比較高，但是故障不會讓人受傷，因此很多司機甚至只有等到下個月去4S店時才想起來維修它。但是，如果你的車突然在高速上自動加速，估計你馬上停在緊急帶，驚魂未定便馬上打電話給4S店罵娘了，因為這種原本可以透過設計規避的故障是不可接受的。這也正是功能安全開發期望避免的故障。

補充一下，這裡提到兩個維度，危害的嚴重度和危害發生的頻率。對功能安全有了解的朋友可能會疑惑 ：不是有三個引數評價，S（severity 嚴重度），E（Exposure 曝光度），C（controllability 可控度）嗎？

其實不衝突，第二個維度頻率綜合了E值和C值。怎麼理解呢？“頻率”指的是

危害發生的頻率

，而“曝光度”指的是

場景的曝光度

。駕駛員的可控度是可以將高曝光度的場景下造成危害的頻率降低的。舉例來說，開高速的場景在日常生活中曝光度比較高，但是如果高速時發生意外加速，有些情況下透過駕駛員的制動干預是可以避免危害的，因此降低了危害發生的頻率。

功能安全怎麼在企業落地？

這個問題很大，無法進行全面的回答。一個原因是各個公司間的差異性，二是ISO 26262的範圍太廣，對整車完整生命週期都進行了功能安全的指導，除了我們熟知的V模型開發過程外，就連生產和報廢階段都考慮在內。在這裡僅僅談幾點認識。

安全文化（safety culture）。

這個詞初一聽很虛，感覺像是喊口號。實際上安全文化體現在很多看得見的方面，比如：

成本和進度總是優先於安全和質量，還是安全是最高優先順序？

是否確保了與功能安全相關的決策責任是可追溯的？

在所有層面（管理/開發/驗證/稽核）執行是否有明確的、可追蹤的和受控的流程？

安全文化體現在公司的開發流程中。優秀的安全文化一定意味著企業有非常完善的開發流程。否則功能安全只是空中樓閣，落地無從談起。同時，完善的流程也意味著要增加相應的崗位和工程師們的工作量，甚至是升級開發工具，開發成本也隨之上升。

在這裡強調一點，企業一定是將ISO 26262中對功能安全的需求融入公司已有的開發流程，而不是單獨為功能安全開發制定一套開發流程。換句話說，功能安全需求是功能需求的一部分，和其他功能需求一樣用同一套的開發流程來實現。

2。 人員配置。

首先說明，幾乎不可能是由一個功能安全開發工程師同時負責系統/軟體/硬體所有的功能安全開發，就算有這種萬里挑一的全才，也得考慮如此龐大的工作量會不會把人才趕跑了。

一個完善的開發團隊中通常定義三個角色：

系統功能安全工程師

軟體功能安全工程師

硬體功能安全工程師

每個人負責下圖中的一個V模型開發活動。

需要說明，這裡的“系統”指的是某個E/E產品，比如轉向控制系統EPS，穩定性控制系統ESP，電機控制系統MCU等。

功能安全工程師角色分工

不管對主機廠還是供應商，在一個客戶專案中，很少說要從零開始開發一個全新的產品，一般都是基於現有的產品作為base進行開發，以滿足新的專案需求，功能安全也是如此。圍繞專案需求與base不同的部分進行功能安全開發，識別不同點的活動稱作FSIA（functional safety impact analysis）。當功能安全是基於base來開發時，不管是對主機廠或供應商來說，這三個角色並不需要定義三個獨立的工程師來做，這未免太奢侈，實際上也沒必要。通常軟/硬體功能安全工程師由軟/硬體工程師兼任。

對軟體功能安全開發而言，在軟體開發流程完善和開發工具滿足要求的前提下，在軟體設計和驗證過程中，功能安全需求和功能需求無需過分區別對待，有很多公司的軟體開發流程本身就能保證符合ISO 26262中ASIL D的要求。因此功能安全對軟體工程師增加的工作量主要體現在需求分析和輸出文件，包括：

對系統層分配下來的安全需求進行可行性分析

對輸入訊號提安全需求

滿足系統層或客戶的文件需求

對硬體功能安全開發而言，通常一款硬體的設計週期很長，而且設計好後很多年不會更新，所以幾乎不會在客戶專案中重新開發硬體。基於此，專案中硬體功能安全開發就可以完全沿用base既有的開發，功能安全對硬體工程師增加的工作量主要是：

為系統安全工程師提供FTA分析需要的硬體component失效率資料（FMEDA）

滿足系統層或客戶的文件需求（如ECU FMEA分析報告）

只有系統功能安全開發需要定義一個專門的崗位，有些公司也稱為“功能安全經理（product safety manager， PSM）”。主機廠和供應商對功能安全經理的職責定義側重點有一些不同，這也是主機廠和供應商之間的合作模式決定的。主機廠側重於定義需求並分配給供應商，供應商則側重於實現需求。

主機廠端功能安全經理

的工作職責一般包括但不限於：

計劃和協調系統安全開發活動

進行HARA分析，並結合HARA分析和系統架構定義功能安全概念（functional safety concept）和技術安全概念（technical safety concept）

將安全需求分配給對應的子系統，或者說分配給子系統的供應商

負責協調子系統相互之間的功能安全需求的傳遞與澄清

協助功能安全驗證，比如建立整車test case和測試結果評估

對子系統功能安全開發進行稽核

供應商端功能安全經理

的工作職責一般包括但不限於：

計劃和協調系統安全開發活動

基於HARA分析，根據安全需求和系統架構定義功能安全概念（functional safety concept）和技術安全概念（technical safety concept），對系統架構設計提出要求或建議

將安全需求分配給對應的軟體工程師（和硬體工程師）

完成系統功能安全設計的定量分析和定性分析，通常分別使用FTA和FMEA

協助功能安全驗證，比如建立整車test case和測試結果評估

作為客戶功能安全團隊和功能安全稽核團隊的介面

對軟/硬體工程師提供功能安全開發建議和指導

一般來說，生產和報廢階段的功能安全活動不在系統功能安全工程師的職責範圍內。比如生產階段的功能安全通常是由plant manager（工廠經理）來執行，執行的依據則是已經包含了功能安全需求的生產流程。當產品release後交到工廠，就意味著功能安全工程師的工作完成了。

相信大家可以理解，為什麼系統層的功能安全開發需要專門的人負責了，因為工作量實在有點大。尤其是現階段國內功能安全開發的理念和方法論還沒有到深入人心的程度，如果遇到客戶不懂，軟硬體工程師也不懂，那麼光是對外交流和對內溝通就需要花大量的時間。如果一個專案足夠大，客戶新需求足夠多，可能不止一個系統功能安全工程師。

於此同時，功能安全經理這個崗位對工程師的專業素質要求也很高，原則上需要有足夠的軟/硬體開發經驗，這樣才能勝任上到客戶或供應商，下到軟硬體工程師的交流工作。但是目前鑑於功能安全在企業還比較新，這方面的能力要求有適當放寬。

在這裡也糾正一些同行對系統功能安全工作的誤解。

認為既然不用寫程式碼，也不用畫板子，那功能安全經理就只剩下流程和文件工作了。這話被功能安全經理聽到他會傷心的，彷彿當年不被女神認可的感覺又回來了。誠然，功能安全的落地需要流程和文件來保證，但是功能安全開發的核心卻是技術層面的東西而非流程。而功能安全的技術核心，體現在概念設計/系統分析/系統驗證階段對功能安全開發方法論的運用。

如何對待ISO 26262

上面提到“方法論”，一說到方法論，這玩意兒一聽就很抽象，這也無外乎我們初看ISO 26262的時候不知所云，昏昏欲睡，完全不像看一個軟體開發手冊那樣即看即用。但個人認為ISO 26262的精髓恰恰是在對這個方法論的解釋。

因此，個人認為，入門時可以這樣對待ISO 26262文件：

首先不要期待脫離實操就看懂ISO 26262。最好的方法是有專案練手，在做專案的過程中體會ISO 26262中的需求。

2。 如果你是功能安全經理，那沒什麼說的，除了第7部分，其他部分都需要熟悉。

但還是那句話，必須結合專案開發過程和公司的開發流程來理解ISO 26262。多問自己：流程中XX為什麼這樣規定？對應ISO 26262哪條需求？

3。 如果你是軟/硬體開發工程師兼任功能安全工作，那麼重點關注第3（概念）/5（硬體）/6（軟體）部分，另外還有第9部分對的ASIL等級分解的說明。

基於這些內容如果你能夠回答下面的問題，那麼我覺得你至少知道自己在做什麼和為什麼這麼做了，這樣一來，在和別人交流的過程會更加專業和順暢。

什麼是safety goal？

如何做Hazard analysis and risk assessment？

ASIL 等級怎麼評定？

ASIL 等級達不到要求用什麼方法解決？

功能安全工程師的前景

就我目前的所見所聞來看，目前隨著ADAS功能的普及和自動駕駛研究的熱門，功能安全越來越被重視，市場需求量很大。獵頭在挖人時開出的價碼往往非常誘人。與此同時，目前國內功能安全做的成熟的企業不多，尚處於邊做邊摸索的階段，所以目前挖人時並不很挑剔，對系統/軟/硬體開發經驗的要求有放寬。

就我個人感覺而言，相對於本土OEM，外企或者合資Tier1的know-how更高，比如博世，大陸，聯電等等。合資OEM中泛亞的功能安全團隊已經很成熟，因此在和這些供應商合作時很強勢也有底氣；而本土OEM在和這些供應商合作的同時也抱著花錢學習怎麼做功能安全的目的。換句話說，OEM的態度從“你覺得怎麼做？”到“我要你這麼做！”還有些距離。但是，這種狀況在將來一定會得到改變，因為本土主流的幾家OEM的功能安全團隊在以肉眼可見的速度壯大，大家越來越捨得在功能安全開發上投入成本（好多外國專家也因此體會到了社會主義高薪的誘惑力）。可以預見的是，自動駕駛的驅動會加速功能安全的落地，這會大大加速行業整體水平的提高。屆時，國內市場對功能安全工程師的專業素養的要求也會越來越高；另一方面，ISO 26262在自動駕駛開發中的侷限性也日益凸顯，由此也催生了新的標準SOTIF的誕生，功能安全工程師需要掌握的知識越來越多。

正應了那句話：學無止境。

（寫完吐槽一句，在知乎認真答題太費時了！因為考慮到這裡前輩和大神很多，全程有種給領導回郵件時的如履薄冰之感，原本以為一個小時搞定的寫了三個多小時。由此也真的很佩服在知乎上持續輸出專業答案的前輩們）