一位資深功能安全工程師給你的入行建議

近年來ISO 26262越來越被汽車行業所接受，國內外各大主流汽車企業陸續將ISO 26262中定義的需求融入自己的研發體系和流程中。與此同時，各大主流車企也紛紛在開發體系中獨立出了功能安全的專職崗位。高缺口、高福利、高發展使得功能安全工程師崗位也成了很多汽車從業者的一個優先級比較高的考慮對象。

而相比系統工程師、軟件工程師、硬件工程師、測試工程師等這些在汽車研發體系中已經非常成熟的崗位，論發展年頭，功能安全工程師這一新興的崗位著實屬于“小弟”。因此，很多工程師朋友在考慮這個崗位時，不免心生很多疑問。

基于此，該系列文章試圖結合工作經驗和見聞，從以下幾個方面對功能安全工程師這一崗位進行一個比較全面的介紹，希望能為有意向從事功能安全的同行朋友提供一些有價值的參考。

• 什么是功能安全？

• 功能安全如何在企業落地？

• 功能安全經理的工作定義

• 主機廠和供應商功能安全合作

• 系統/軟件/硬件功能安全工程師的工作日常

• 功能安全的前景及一些建議

一、什么是功能安全？

在這里僅從功能安全的定義出發，幫助建立對功能安全的淺顯易懂的初印象。

ISO 26262對功能安全的定義為：

Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.

國標GB/T 34590對這一定義的翻譯為：

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

從定義展開強調幾個關鍵詞。

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

功能安全要討論的對象是E/E架構設計，因此機械/液壓/化學等設計都不在ISO 26262的研究范圍。換句話說，功能安全只是產品安全的一部分。

2.“hazard”，危害

危害有很多類型，如人身傷害或者財產損失等等。功能安全里的危害僅僅指因為E/E系統的故障行為而引起的對駕駛員或者路人或周邊車輛內人員（注意：不僅僅是駕駛員）造成的健康傷害。換句話說，功能安全開發目的是避免傷人，而不是避免你的損傷你的豪車，也不是避免你的豪車被偷。

3.“unreasonable”，不合理的

就像世界上沒有永動機一樣，世界上也沒有100%安全的系統，因此功能安全追求的是將風險控制在合理的范圍內，或者說可被接受的范圍內。如下圖所示。

判定風險是否可被接受，需要從兩個維度去衡量：危害的嚴重性和危害發生的頻率。舉例來說，飛機失事幾乎無人生還，但是正因為飛機失事的概率非常低，所以飛機依然是最重要和最受歡迎的交通工具之一。如果汽車上的空調開關出現故障的頻率比較高，但故障只會影響駕駛員或乘客舒適性體驗，不會造成人員受傷，你很可能等到下個月去4S店時才想起來維修它；但是，如果你的車突然在高速上自動加速，估計你馬上停在緊急帶棄車而逃，喊著要退車了，因為這種原本可以通過設計規避的故障是不可接受的。這也正是功能安全開發期望避免的故障。

在此補充一下，圖中提到兩個維度，危害的嚴重度和危害發生的頻率。對功能安全有一些了解的朋友可能會疑惑 ：不是有三個參數評價，S（severity 嚴重度），E（Exposure 曝光度），C（controllability 可控度）來定義ASIL等級嗎？

其實不沖突，圖中的第二個維度頻率綜合了E值和C值。怎么理解呢？因為“頻率”指的是危害發生的頻率，而“曝光度”指的是場景的曝光度。駕駛員的可控度是可以將高曝光度的場景下造成危害的頻率降低的。舉例來說，開高速的場景在日常生活中曝光度比較高，但是如果高速時發生意外加速，有些情況下通過駕駛員的制動干預是可以避免危害的，因此降低了危害發生的頻率。

二、功能安全如何在企業落地？

由于ISO 26262的覆蓋范圍非常廣，對整車完整生命周期都進行了功能安全的指導，除了我們熟知的V模型開發過程外，就連生產和報廢階段都考慮在內；再加上各個企業開發流程中存在的的差異性，所有針對“功能安全如何在企業落地”這一問題，很難進行全面的回答。在這里僅談兩點功能安全落地的先決條件。

1.1. 安全文化

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

• 成本和進度總是優先于安全和質量，還是安全是最高優先級？

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

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

• 
  

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

1.2. 人員配置

針對這一點，不同的企業也有一些出入，但是，功能安全開發比較成熟的企業間至少有一點是能達成一致的，那就是不可能是由一個功能安全開發工程師同時負責系統/軟件/硬件所有的功能安全開發。就算有這種萬里挑一的全才，也得考慮如此龐大的工作量會不會把人才趕跑了。

一個完善的功能安全開發團隊通常定義三個角色：

• 系統功能安全工程師

• 軟件功能安全工程師

• 硬件功能安全工程師

對于后兩個角色，如果是開發一個全新的產品，由于工作量大，人員配置比較充足的企業會獨立于軟/硬件開發工程師之外再指派兩個工程師擔任；如果是基于企業已經量產的產品，根據不同客戶的需求做修改，由于工作量相對減少很多，那么軟/硬件功能安全工程師通常由軟/硬件開發工程師兼任。但是不論是開發全新產品還是基于已有產品修改，系統功能安全工程師一般是專門的崗位。在很多企業系統功能安全工程師也稱為功能安全經理，負責統籌協調整個產品的功能安全開發工作。

三、功能安全經理的工作定義

也正是由于上文提到的原因，市場上功能安全崗位的招聘絕大多數都是系統功能安全工程師，也就是功能安全經理。這里從網上分別選擇一個較為典型的OEM和供應商的招聘信息，由此來窺見一些功能安全經理的工作內容。

主機廠和供應商對功能安全經理的職責定義側重點有一些不同，這也是主機廠和供應商之間的合作模式決定的。

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

四、主機廠和供應商功能安全合作

• 明確主機廠和供應商在開發過程中各自的責任范圍

• 明確供應商提交給主機廠的的遞交物內容

• 明確供應商提供給主機廠的遞交物形式（如文檔或者現場展示）

• 明確主機廠對供應商功能安全開發階段評估的方式（如評估次數和具體內容）

開發的報價依據，所以在項目報價階段就需要完成DIA。這里順便提一句，主機廠和供應商間簽訂DIA是一個漫長的談判過程，原因是主機廠和供應商各自打的算盤正好是對立的：主機廠希望在預算范圍內盡可能要求供應商提供更多的遞交物；而供應商則出于保密考慮盡可能拒絕客戶的遞交物要求。在DIA的談判過程中，理論上供應商的整個項目團隊都需要參與其中。功能安全經理起到協調作用，負責對主機廠解釋功能安全開發流程，對內部解釋DIA各項條目的含義；各個環節的開發人員需要基于功能安全經理的解釋確定他所涉及的條目能否滿足主機廠要求以及如何滿足；項目經理則負責最終拍板，拍板的依據則主要考量開發經費和開發資源的對等性。當主機廠和供應商明確了功能安全的合作范圍和內容之后，功能安全開發工作將由雙方的功能安全經理作為接口來統籌和協調，保障功能安全需求在主機廠和供應商之間被正確傳遞與執行。同時，對于主機廠或供應商各自內部的功能安全開發來說，正如前面提到，功能安全經理通常也就是系統功能安全工程師，他將作為系統層的接口協調系統與軟硬件團隊的功能安全工作，保證系統層和軟/硬件層功能安全需求的互相傳遞和執行。功能安全開發過程交流示意圖RT.05

五、系統/軟件/硬件功能安全工程師的日常工作

• 系統功能安全工程師

• 軟件功能安全工程師

• 硬件功能安全工程師

當功能安全是基于base來開發時，不管是對主機廠或供應商來說，這三個角色并不需要定義三個獨立的工程師來做，這未免太奢侈，實際上也沒必要。通常軟/硬件功能安全工程師由軟/硬件工程師兼任。對軟件功能安全開發而言，在軟件開發流程完善和開發工具滿足要求的前提下，在軟件設計和驗證過程中，功能安全需求和功能需求無需過分區別對待，有很多公司的軟件開發流程本身就能保證符合ISO 26262中ASIL D的要求。因此功能安全對軟件工程師增加的工作量主要體現在需求分析和輸出文檔，包括：

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

• 對輸入信號提安全需求；

• 滿足系統層或客戶的文檔需求。

• 為系統安全工程師提供FTA分析需要的硬件component失效率數據（FMEDA）；

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

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

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

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

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

• 協助內部功能安全驗證，如創建整車test case和測試結果評估

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

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

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

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

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

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

• 作為客戶功能安全團隊和功能安全審核團隊的接口

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

一般來說，生產和報廢階段的功能安全活動不在系統功能安全工程師的職責范圍內。比如生產階段的功能安全通常是由工廠經理來執行，執行的依據則是已經包含了功能安全需求的生產流程。當產品release后交到工廠，就意味著功能安全工程師的工作完成了。相信大家可以看出，功能安全經理這個崗位對工程師的專業素質要求也很高，原則上需要有足夠的軟/硬件開發經驗，這樣才能勝任上到客戶或供應商，下到軟硬件工程師的交流工作。但是目前鑒于功能安全在企業還比較新，這方面的能力要求有適當放寬。在這里也糾正一些同行對系統功能安全工作的誤解。認為既然不用寫代碼，也不用畫板子，那功能安全經理就只剩下流程和文檔工作了。這話被功能安全經理聽到他會傷心的，仿佛當年不被女神認可的感覺又回來了。誠然，功能安全的落地需要流程和文檔來保證，但是功能安全開發的核心卻是技術層面的東西而非流程。而功能安全的技術核心，體現在概念設計/系統分析/系統驗證階段對功能安全開發方法論的運用。

五、功能安全的前景及一些建議

就目前的現狀來看，隨著ADAS功能的普及和自動駕駛研究的熱門，功能安全越來越被重視，市場需求量很大。獵頭在挖人時開出的價碼往往非常誘人。與此同時，目前國內功能安全做的成熟的企業不多，尚處于邊做邊摸索的階段，所以目前挖人時并不很挑剔，對系統/軟/硬件開發經驗的要求有放寬。相對于本土OEM，外企或者合資Tier1的know-how更高，比如博世，大陸，聯電等等。合資OEM中泛亞的功能安全團隊已經很成熟，因此在和這些供應商合作時很強勢也有底氣；而本土OEM在和這些供應商合作的同時也抱著花錢學習怎么做功能安全的目的。換句話說，OEM的態度從“你覺得怎么做？”到“我要你這么做！”還有些距離。但是，這種狀況在將來一定會得到改變，因為本土主流的幾家OEM的功能安全團隊在以肉眼可見的速度壯大，大家越來越舍得在功能安全開發上投入成本（好多外國專家也因此體會到了社會主義高薪的誘惑力）。可以預見的是，自動駕駛的驅動會加速功能安全的落地，這會大大加速行業整體水平的提高。屆時，國內市場對功能安全工程師的專業素養的要求也會越來越高；另一方面，ISO 26262在自動駕駛開發中的局限性也日益凸顯，由此也催生了新的標準SOTIF的誕生，功能安全工程師需要掌握的知識越來越多。正應了那句話：學無止境。最后，考慮到市場上功能安全崗位的招聘絕大多數都是系統功能安全工程師，也就是功能安全經理，在說了這么多后，想給正在考慮這個崗位的工程師羅列幾條個人建議，一家之言，僅供參考。

（1） 首先，一定要明確功能安全是一個技術崗位而不是流程管理的崗位。既然是技術崗位，那么都對軟/硬件開發經驗有一定的要求。

（2） 如果你已經有軟件和硬件開發經驗，那么你已經有很好的技術功底，功能安全隊伍很需要你這樣的全才，做功能安全的上限也很高。

（3） 如果你只做過軟件或者只做過硬件開發，依然能夠從事功能安全開發。一方面畢竟軟硬件都懂的全才很少，另一方面如前面提到，功能安全經理的工作內容聚焦在系統層，懂一些軟/硬件開發的基本內容也可以把工作完成。但是建議在工作中多留心彌補自己不足的部分。

（4） 如果你既沒有軟件開發經驗也沒有硬件開發經驗，如果單考慮薪水的話，機會擺在面前也可以把握。但是個人建議先找軟件開發相關的崗位積累開發經驗，否則可能在對內對外的溝通中不免有紙上談兵之嫌而難以服眾，而且在功能安全領域的職業發展后期容易遇到瓶頸。

（5） 如果有選擇的話，最好去功能安全團隊成熟的大公司做功能安全，比如上面提到的這些公司。這些公司的功能安全開發早已落地，也積累了很多自己的理解和經驗，這對于一個小白來說無疑是站在巨人的肩膀上學習。而小公司可能還苦于如何把功能安全納入開發流程，去了可能就是自己摸索著鉆研和天書一樣的ISO 26262標準，很難高效地提高自己的能力。