“SASETalk”是磐時(shí)打造的深度訪談欄目，通過與企業(yè)內(nèi)資深技術(shù)專家對話，記錄他們親歷的技術(shù)歷程與行業(yè)觀察，從個(gè)人視角解讀行業(yè)發(fā)展變遷，共同探討未來技術(shù)趨勢與工程師成長路徑。

本期嘉賓PROFILE

王茁軒

功能安全工程師

3年芯片功能安全經(jīng)驗(yàn)

熟悉ISO26262、IEC62380、IEC61709、SN29500；擁有ASIL D產(chǎn)品開發(fā)經(jīng)驗(yàn)；熟知芯片開發(fā)驗(yàn)證封裝測試流程，熟練掌握SEooC，硬件（系統(tǒng)）架構(gòu)設(shè)計(jì)，HSR，安全分析（HW/SYS-FMEA，DFA，F(xiàn)TA），F(xiàn)MEDA等方法和相關(guān)工具的應(yīng)用。擁有FSPA汽車功能安全職業(yè)證書。

01

安全意識的“第一課”

您行業(yè)初印象：從車輛工程專業(yè)畢業(yè)時(shí)，功能安全對你而言是課本上的概念還是清晰的職業(yè)方向？入職后接觸的第一個(gè)具體任務(wù)與你最初的想象有何不同？

功能安全是我在求職過程中才了解到的概念，之前也學(xué)習(xí)過汽車的主動(dòng)、被動(dòng)安全設(shè)計(jì)，所以功能安全更像是一個(gè)既熟悉又陌生的邊界線。在車輛工程的本科課程中，我們更多學(xué)習(xí)的是汽車的正向功能——發(fā)動(dòng)機(jī)如何工作、底盤如何操控、CAN總線如何通信。雖然當(dāng)時(shí)也接觸了ISO 26262或者一些可靠性工程的基礎(chǔ)知識，但在畢業(yè)時(shí)，功能安全確實(shí)還停留在書本里一個(gè)“章節(jié)”或“名詞解釋”的層面。它被簡單地理解為“不要出故障”，或者直接等同于“雙系統(tǒng)冗余”，并沒有形成一個(gè)完整的職業(yè)畫像。

真正讓我覺得這可能是一個(gè)清晰方向，是在畢業(yè)設(shè)計(jì)期間接觸到一些關(guān)于線控轉(zhuǎn)向的論文時(shí)。我突然意識到，隨著電子電氣系統(tǒng)越來越復(fù)雜，軟件代碼越來越多，傳統(tǒng)機(jī)械的物理失效已經(jīng)不是唯一的風(fēng)險(xiǎn)了，“系統(tǒng)性失效”和“未知的未知風(fēng)險(xiǎn)”開始成為難題。當(dāng)時(shí)隱約覺得，這背后一定有一套嚴(yán)密的邏輯和規(guī)則去約束這些看不見的風(fēng)險(xiǎn)，而這套規(guī)則或許就是未來汽車行業(yè)的基石。所以，它不是一蹴而就的清晰職業(yè)路標(biāo)，但確實(shí)是讓我覺得非常值得探索的那條林間小路。

入職后，我接到的第一個(gè)任務(wù)是針對一個(gè)組合定位導(dǎo)航系統(tǒng)的電源模塊進(jìn)行FMEDA分析。我最初的想象中，這應(yīng)該是一個(gè)非?！八钡墓ぷ鳎耗玫皆韴D，翻著標(biāo)準(zhǔn)，對著清單一個(gè)一個(gè)元器件打勾，計(jì)算它們的失效率，然后套公式，最后得出一個(gè)漂亮的數(shù)字。感覺就像是拿著標(biāo)準(zhǔn)答案去核對作業(yè)。然而，當(dāng)我真正上手去做的時(shí)候，發(fā)現(xiàn)了三個(gè)巨大的反差：

從理想主義到拉鋸戰(zhàn)：我本以為FMEDA只是關(guān)于技術(shù)的計(jì)算，但實(shí)際上我意識到，功能安全首先是關(guān)于溝通的藝術(shù)。因?yàn)橛布こ處熢O(shè)計(jì)的電路未必有冗余，我在計(jì)算單點(diǎn)故障度量時(shí)發(fā)現(xiàn)某個(gè)電容失效會導(dǎo)致系統(tǒng)直接偏離安全目標(biāo)。我需要拿著數(shù)據(jù)和架構(gòu)去和硬件工程師辯論：是改電路，還是加診斷，或者接受風(fēng)險(xiǎn)？這和我最初想的一個(gè)人悶頭做分析完全不同。

從靜態(tài)計(jì)算到動(dòng)態(tài)迭代：想象中的分析是線性的，但實(shí)際的FMEDA是一個(gè)反復(fù)迭代的過程。設(shè)計(jì)變一下，診斷覆蓋率就要重新算；甚至發(fā)現(xiàn)某個(gè)失效模式其實(shí)可以被軟件里的看門狗覆蓋，這又需要和軟件功能安全工程師確認(rèn)窗口時(shí)間。這個(gè)任務(wù)就像一個(gè)巨大的拼圖，需要不停地協(xié)調(diào)、確認(rèn)、更新，遠(yuǎn)沒有課本上那個(gè)例題那么干凈利落。

對數(shù)字的敬畏感：起初看失效率數(shù)據(jù)，覺得就是個(gè)冷冰冰的數(shù)字。但真正在做FMEDA時(shí)，當(dāng)把一個(gè)μC的失效率分?jǐn)偟礁鱾€(gè)模塊，再聯(lián)系到它萬一失效會讓方向盤失去助力時(shí)，我真正理解了這幾個(gè)小數(shù)點(diǎn)后面的數(shù)字，背后對應(yīng)的是實(shí)實(shí)在在的風(fēng)險(xiǎn)和責(zé)任。這讓我對這份工作的嚴(yán)謹(jǐn)性有了全新的敬畏。

快速學(xué)習(xí)的關(guān)鍵：在三年內(nèi)，你從協(xié)助文檔編寫到主導(dǎo)芯片級ASIL D認(rèn)證，這種快速跨越的秘訣是什么？有沒有一個(gè)時(shí)刻或項(xiàng)目讓你突然對功能安全有了“頓悟”般的理解？

剛開始協(xié)助編寫文檔時(shí)，很多人可能會陷入一個(gè)誤區(qū)：覺得功能安全就是填表格、畫流程圖、套模板。但我當(dāng)時(shí)做了一件比較“笨”的事：每當(dāng)我接手一份前輩的文檔（比如FSC技術(shù)安全概念或硬件安全需求規(guī)格書），我都會反向推導(dǎo)——“這個(gè)安全機(jī)制為什么要在這里？如果刪掉它，底層的故障會怎么蔓延？”我把寫文檔的過程，變成了模擬系統(tǒng)失效的過程。這讓我在早期就建立了一個(gè)寶貴的資產(chǎn)：失效模式的案例庫。當(dāng)后來主導(dǎo)芯片級認(rèn)證時(shí)，我面對的雖然是一個(gè)復(fù)雜的SoC，但里面的邏輯模塊（比如鎖步核、ECC保護(hù)、內(nèi)存保護(hù)單元）的失效邏輯，其實(shí)在系統(tǒng)級已經(jīng)有了原型。功能安全不是孤島，我花了很多時(shí)間去“偷師”架構(gòu)師和硬件工程師的知識。當(dāng)我在做FMEDA時(shí)，我不只看失效率，我會追問硬件工程師：“這個(gè)電壓監(jiān)控的閾值為什么設(shè)在這里？”當(dāng)理解了物理設(shè)計(jì)的邊界，我寫出來的安全機(jī)制才是可落地的，而不是空中樓閣。這種翻譯能力——把安全需求翻譯成工程師聽得懂的工程語言，是建立信任和推動(dòng)項(xiàng)目的關(guān)鍵。

說到頓悟，它發(fā)生在主導(dǎo)第一個(gè)芯片級ASIL D認(rèn)證項(xiàng)目的中期評審階段。當(dāng)時(shí)我們正在開發(fā)一款I(lǐng)MU芯片，按照標(biāo)準(zhǔn)，我們需要證明它對于系統(tǒng)級的ASIL D要求是夠用的。在分析片上存儲器的保護(hù)機(jī)制時(shí)，我對著幾百頁的芯片手冊和數(shù)據(jù)流圖，突然產(chǎn)生了一個(gè)思維的飛躍。那一刻，我沒有再把這個(gè)芯片看作是一個(gè)復(fù)雜的、由邏輯門和硅材料構(gòu)成的物理實(shí)體，而是把它看作是一個(gè)信息流處理的管道。我意識到，所謂芯片功能安全，本質(zhì)上就是確保這個(gè)“管道”在處理任何數(shù)據(jù)（無論是指令還是信號）時(shí)，一旦發(fā)生信息被篡改、延遲或丟失（即故障），必須有且只有一條清晰的路徑去發(fā)現(xiàn)它、遏制它、或者優(yōu)雅地過渡到安全狀態(tài)。在此之前，我看功能安全是看“文檔完整性”、看“診斷覆蓋率”、看“指標(biāo)計(jì)算”。在此之后，我看功能安全是看“架構(gòu)的脆弱性”、看“隔離的清晰度”。標(biāo)準(zhǔn)里的指標(biāo)（SPFM，LFM，PMHF）不再是終點(diǎn)，而變成了驗(yàn)證信號鏈路是否被忠實(shí)執(zhí)行的檢查手段。

02

與最高安全等級“過招”

挑戰(zhàn)ASIL D：從負(fù)責(zé)產(chǎn)品的功能安全，到深入慣導(dǎo)芯片本身進(jìn)行ASIL D開發(fā)，這其中的技術(shù)挑戰(zhàn)發(fā)生了怎樣的本質(zhì)變化？最讓你“燒腦”的部分是什么？

在模組層級，我們討論的失效往往是比較宏觀的，如“CAN總線通信丟失”、“電機(jī)輸出軸卡死”、“電源供電中斷”。這些失效模式通常有對應(yīng)的機(jī)械或電氣現(xiàn)象，我們可以通過相對直接的診斷手段（如看門狗、回讀校驗(yàn)、電壓監(jiān)控）來覆蓋。而芯片層級的挑戰(zhàn)在于，你面對的不再是一個(gè)功能模塊，而是一塊充滿了晶體管、邏輯門和布線的硅片。如“寄存器內(nèi)的一個(gè)bit位發(fā)生了翻轉(zhuǎn)”，或者是“因?yàn)橄噜徑饘倬€之間的耦合電容導(dǎo)致信號串?dāng)_”。在魔族上我們可以在產(chǎn)品上布置各種測試點(diǎn)，用萬用表、示波器去測量。而對于芯片，一旦芯片封裝好，里面的節(jié)點(diǎn)對于外界來說幾乎是一個(gè)黑盒。你無法把探針伸進(jìn)納米級的工藝節(jié)點(diǎn)里去測量某個(gè)特定觸發(fā)器的狀態(tài)。

讓我燒腦的核心，是在芯片微架構(gòu)層面，對時(shí)間、面積、功耗與安全進(jìn)行的極致權(quán)衡。在模組級如果覺得不夠安全，可以放兩個(gè)MCU，做雙通道比對。這在成本、空間和功耗上雖然代價(jià)不小，但在系統(tǒng)層面是相對簡單的解決方案。而在芯片里，你要在指甲蓋大小的面積上，在毫瓦級的功耗預(yù)算內(nèi)，實(shí)現(xiàn)ASIL D級別的診斷覆蓋率。以慣導(dǎo)芯片為例： 它的核心是MEMS傳感器和模擬前端。要診斷MEMS結(jié)構(gòu)是否損壞，你不能加一個(gè)一模一樣的備份MEMS。你需要設(shè)計(jì)巧妙的內(nèi)置自檢結(jié)構(gòu)，通過施加靜電力來模擬加速度，看讀出電路的響應(yīng)是否正常。這個(gè)自檢不能影響正常工作，還要能檢測出特定的失效模式。

工具與流程的實(shí)踐者：對于一名年輕工程師，如何避免被繁雜的文檔和工具淹沒，而真正抓住功能安全工程的核心主線？

被文檔淹沒的根本原因，往往是我們把文檔當(dāng)成了目標(biāo)，而不是手段。功能安全唯一的起點(diǎn)是“風(fēng)險(xiǎn)”和“最壞情況”。也就是ISO 26262里定義的那個(gè)東西——安全目標(biāo)。每當(dāng)我接手一個(gè)新項(xiàng)目，面對一堆待產(chǎn)的文檔時(shí)，我會強(qiáng)迫自己停下來，只問一個(gè)問題：如果這個(gè)東西壞了，會發(fā)生什么最可怕的事情？（比如車輛失控、無法轉(zhuǎn)向、非預(yù)期加速）。然后，我再逆推回來：為了防止這個(gè)最壞情況，我需要做什么？我需要定義安全狀態(tài)（比如切斷動(dòng)力）。為了進(jìn)入安全狀態(tài)我們就可以開始設(shè)計(jì)監(jiān)控機(jī)制及其驗(yàn)證方法。最后自然會形成文檔。當(dāng)你腦子里始終懸著那把“達(dá)摩克利斯之劍”時(shí)，你就會自動(dòng)過濾掉那些與風(fēng)險(xiǎn)控制無關(guān)的細(xì)枝末節(jié)。文檔不再是負(fù)擔(dān)，而是你為了保護(hù)系統(tǒng)安全所構(gòu)建的證據(jù)鏈。

03

讀懂客戶的“潛臺詞”

從應(yīng)審到前瞻設(shè)計(jì)；在與客戶（尤其是OEM）交流時(shí)，他們除了標(biāo)準(zhǔn)符合性之外，最關(guān)心什么？這些經(jīng)驗(yàn)如何反過來影響芯片層級的設(shè)計(jì)思路？

在我接觸的國內(nèi)外客戶中，能通過評審僅是基本的入場券，他們更多關(guān)心的是你的產(chǎn)品是否真的可靠、有效。比如有客戶關(guān)注你的安全診斷機(jī)制的透明度，產(chǎn)品需清晰追溯內(nèi)部異常情況，還要明確監(jiān)控機(jī)制的原理。另有客戶對產(chǎn)品假設(shè)的運(yùn)行環(huán)境或外部措施有限制，這就需要你對產(chǎn)品的假設(shè)不能過于嚴(yán)格，你的安全狀態(tài)設(shè)計(jì)不能過于復(fù)雜，你的接口不能過多。還有客戶對產(chǎn)品的誤報(bào)警率比較在意，因?yàn)樾枰诋a(chǎn)品保證安全的同時(shí)，可用性也同樣重要，畢竟不能提供一個(gè)頻繁進(jìn)入安全狀態(tài)的產(chǎn)品，否則會導(dǎo)致大量客訴。

這就需要我們功能安全工程師在開發(fā)過程中，不能僅作為一個(gè)ISO 26262的專家，更要成為一個(gè)理解汽車商業(yè)邏輯、系統(tǒng)集成痛點(diǎn)和用戶體驗(yàn)價(jià)值的系統(tǒng)架構(gòu)師。我們的設(shè)計(jì)目標(biāo)，不再只是通過ASIL認(rèn)證，而是幫助OEM造出更可靠、更易用、更能贏得消費(fèi)者信任的汽車。當(dāng)芯片內(nèi)部的安全機(jī)制能夠直接回應(yīng)OEM對于責(zé)任、可用性、易用性的關(guān)切時(shí)，功能安全就真正從合規(guī)成本轉(zhuǎn)變?yōu)榱水a(chǎn)品競爭力。

04

進(jìn)化

用展望未來角色

對于同樣想在三五年內(nèi)快速成長的年輕功能安全工程師而言，你認(rèn)為最應(yīng)該深耕的一兩個(gè)技術(shù)領(lǐng)域是什么？最需要避免的“彎路”又是什么？

如果只能深耕一個(gè)技術(shù)領(lǐng)域，我會選擇 “系統(tǒng)架構(gòu)設(shè)計(jì)”。原因在于，功能安全工程師很容易陷入極端：對ISO 26262的條款倒背如流，但看電路圖如同看天書，和硬件、軟件工程師溝通時(shí)缺乏共同語言；或者是深陷于某個(gè)具體模塊的FMEDA或者軟件診斷的細(xì)節(jié)，卻忘了這個(gè)模塊在整個(gè)車?yán)锸歉墒裁吹模坏┦l(fā)什么后果。所以，在三到五年的成長期，你需要建立“端到端”的視野。這意味著你要能看懂從傳感器輸入（感知）-> 決策算法（處理）-> 執(zhí)行器動(dòng)作（控制）的完整信號鏈。抓住 FMEA和 FTA這兩個(gè)工具。不要把它們僅僅當(dāng)作合規(guī)文檔，而是當(dāng)作理解系統(tǒng)的手術(shù)刀。通過做FMEA，你會逼著自己去問：“這個(gè)CAN信號如果延遲了會怎樣？這個(gè)電壓如果漂移了軟件能識別嗎？”這個(gè)過程會讓你比系統(tǒng)工程師更懂系統(tǒng)，比軟件工程師更懂安全機(jī)制的必要性。

說到彎路，我覺得最可惜的一種情況是：把平臺的能力，錯(cuò)當(dāng)成自己的能力。很多人入行后，看到行業(yè)里自動(dòng)駕駛火了就追L3/L4，看到AI芯片火了就去研究NPU的安全。這本身沒錯(cuò)，但如果基礎(chǔ)還沒打牢，很容易變成“空中樓閣”。比如，直接去挑戰(zhàn)一個(gè)復(fù)雜的AI芯片的ASIL D認(rèn)證，如果連最基礎(chǔ)的鎖步CPU是如何工作的、內(nèi)存ECC的單比特糾錯(cuò)雙比特檢錯(cuò)機(jī)制到底怎么在硬件層面實(shí)現(xiàn)都沒搞懂，那么在評審會上，面對硬件專家和架構(gòu)師的提問，可能會很難應(yīng)對。另外，功能安全確實(shí)涉及很多流程，但如果你在三五年內(nèi)，把自己的核心競爭力定義成會走流程、會寫文檔，那可能會比較被動(dòng)。因?yàn)榱鞒炭梢员籄I輔助，可以被模板化，但對失效機(jī)理的深刻理解，對系統(tǒng)復(fù)雜性的洞察，是機(jī)器很難替代的。

你選擇加入磐時(shí)，是希望如何實(shí)現(xiàn)自己的下一個(gè)職業(yè)目標(biāo)？期待為解決行業(yè)的哪些痛點(diǎn)貢獻(xiàn)力量？

選擇加入磐時(shí)，對我來說不僅僅是換一份工作，更像是一次從運(yùn)動(dòng)員到教練員兼戰(zhàn)術(shù)分析師的轉(zhuǎn)變。我希望在這里，既能拓寬自己技術(shù)視野的廣度，又能錘煉解決深層次問題的能力。我希望利用磐時(shí)的平臺優(yōu)勢，接觸到不同客戶、不同領(lǐng)域（從傳統(tǒng)的動(dòng)力底盤，到新興的自動(dòng)駕駛、智能座艙，甚至是跨行業(yè)的工業(yè)控制）的項(xiàng)目。每一個(gè)新項(xiàng)目都是一次快速學(xué)習(xí)的機(jī)會。我的目標(biāo)是在未來幾年中，積累起覆蓋多個(gè)技術(shù)領(lǐng)域的安全模式庫。當(dāng)客戶遇到一個(gè)棘手的失效問題時(shí)，我能迅速從腦海里調(diào)取出之前在類似場景下驗(yàn)證過的解決方案。

在幾年的工作中，我觀察到行業(yè)里普遍存在幾個(gè)痛點(diǎn)。比如在很多企業(yè)內(nèi)部，功能安全團(tuán)隊(duì)和研發(fā)團(tuán)隊(duì)是割裂的。安全工程師在造文檔，研發(fā)工程師在搞開發(fā)，到最后項(xiàng)目評審時(shí)，才發(fā)現(xiàn)安全需求無法落地，或者安全機(jī)制影響了功能性能，導(dǎo)致大量返工。我希望利用磐時(shí)獨(dú)立的第三方視角，充當(dāng)一個(gè) 翻譯者和融合者。我們不只帶來標(biāo)準(zhǔn)，更帶來業(yè)界最佳實(shí)踐。通過早期的安全概念介入，幫助客戶在架構(gòu)設(shè)計(jì)階段就把安全內(nèi)生進(jìn)去，讓研發(fā)團(tuán)隊(duì)覺得安全是幫手，而不是“對手”。另外，很多企業(yè)的安全經(jīng)驗(yàn)沉淀在個(gè)別的資深工程師腦子里，一旦人員流動(dòng)，經(jīng)驗(yàn)就斷了。而且不同項(xiàng)目組之間的失敗教訓(xùn)和成功經(jīng)驗(yàn)很難共享。磐時(shí)作為第三方，有機(jī)會接觸大量不同類型的項(xiàng)目。我們內(nèi)部積累的失效案例庫、最佳實(shí)踐模式、以及各種踩坑教訓(xùn)，其實(shí)是我們能給客戶帶來的最大附加值之一。我希望能把這些跨行業(yè)的、跨領(lǐng)域的經(jīng)驗(yàn)，系統(tǒng)化地整理和提煉，然后反哺給我們的客戶，幫助他們站在我們的肩膀上，看得更遠(yuǎn)，少走彎路。