幾個(gè)月前有個(gè)做底盤域控制器的朋友找我聊天說他們準(zhǔn)備過ISO 26262的ASIL D認(rèn)證老板覺得只要花錢買個(gè)工具鏈、請咨詢公司來輔導(dǎo)然后埋頭寫一年文檔就能搞定。我當(dāng)時(shí)沒直接反駁但他走之后我一直在想這個(gè)行業(yè)里對ASIL(Automotive Safety Integrity Level汽車安全完整性等級)的誤解真的太普遍了。很多人把它當(dāng)成一個(gè)評分體系以為把D級當(dāng)成“最高要求”然后照著最嚴(yán)的條款堆就行了但實(shí)際上ASIL的本質(zhì)是一套風(fēng)險(xiǎn)管理決策的工程化表達(dá)你如果理解不了它背后是怎么運(yùn)作的做出來的功能安全大概率是花架子。這篇東西我不打算跟你逐條翻譯ISO 26262的標(biāo)準(zhǔn)條文那些去找中文版PDF都能看到。我想做的是把ASIL到底是什么、怎么算出來、怎么在實(shí)際項(xiàng)目中落下去、以及最常見的坑在哪里一條線拆開來講明白。說得再直白一點(diǎn)這篇文章是寫給那些需要在真實(shí)項(xiàng)目里搞定功能安全而不是僅僅想“過個(gè)審核”的人。1. 認(rèn)識ASIL之前先搞懂ISO 26262到底在管什么在很多人的印象里ISO 26262是一個(gè)“安全標(biāo)準(zhǔn)”或者說一套“文檔模板要求”。這個(gè)理解不算全錯(cuò)但它會讓你抓不住重點(diǎn)。ISO 26262全名是《道路車輛 功能安全》它管的不是車輛本身安不安全而是車輛上電子電氣系統(tǒng)在出現(xiàn)故障的時(shí)候能不能把風(fēng)險(xiǎn)控制在一個(gè)可接受的范圍內(nèi)。你可以把功能安全理解成給系統(tǒng)加一套“兜底機(jī)制”。一個(gè)控制器正常工作時(shí)當(dāng)然沒問題但如果傳感器短路了、執(zhí)行器卡住了、信號被干擾了這個(gè)系統(tǒng)應(yīng)該怎么樣ISO 26262管的就是這類場景——它在逼你回答當(dāng)東西壞了的時(shí)候系統(tǒng)是變得更危險(xiǎn)了還是依然安全這里就牽扯到一個(gè)非常核心的概念安全是系統(tǒng)性的屬性不是一個(gè)單獨(dú)的功能。你做的不是一個(gè)“安全功能”你是在讓一個(gè)可能出故障的功能在故障時(shí)依然不會把人置于危險(xiǎn)境地。這個(gè)思維轉(zhuǎn)變很重要因?yàn)楹芏嗳硕剂?xí)慣說我做了個(gè)“安全模塊”但這個(gè)安全模塊本身也會壞誰來兜它1.1 ISO 26262的框架結(jié)構(gòu)從V模型到全生命周期覆蓋ISO 26262從架構(gòu)上覆蓋了從概念階段、系統(tǒng)開發(fā)、硬件開發(fā)、軟件開發(fā)到生產(chǎn)、運(yùn)行、報(bào)廢的全生命周期。理論上講它管的不是某一塊電路板或者某一段代碼而是整個(gè)安全生命周期里所有跟“風(fēng)險(xiǎn)”相關(guān)的活動。行業(yè)里討論最多的通常是第二部分——功能安全管理第三部分——概念階段第四部分——系統(tǒng)級開發(fā)第五部分——硬件級開發(fā)第六部分——軟件級開發(fā)。這套結(jié)構(gòu)外形上很像傳統(tǒng)的V模型開發(fā)流程左邊是需求分解右邊是集成驗(yàn)證中間掛著各種追溯性要求。所以你會看到很多公司落地功能安全的時(shí)候第一反應(yīng)就是改造研發(fā)流程把V模型和現(xiàn)有的敏捷開發(fā)揉在一起。但這里我要說一句可能得罪人的話流程是手段不是目的。ISO 26262真正想要的不是一個(gè)完美的V模型而是讓每一項(xiàng)安全相關(guān)的決策都有依據(jù)、有記錄、可追溯。你哪怕用敏捷開發(fā)只要能在每個(gè)迭代里保證安全相關(guān)活動閉環(huán)了在合規(guī)性上完全有可能。反過來如果你嚴(yán)格按照V模型做了一年但安全目標(biāo)是怎么來的都說不清楚那你的流程就是純擺設(shè)。1.2 規(guī)范等級并不是“分?jǐn)?shù)”而是風(fēng)險(xiǎn)容忍度的邊界那時(shí)候我剛開始接觸ISO 26262的時(shí)候也犯過錯(cuò)誤以為ASIL D就是“要求都拉到最高”所有東西都按最嚴(yán)的來。后來被一個(gè)老前輩點(diǎn)醒ASIL不是分?jǐn)?shù)是風(fēng)險(xiǎn)容忍度。它表達(dá)的是——出于社會對“多大風(fēng)險(xiǎn)算可接受”的共識這個(gè)功能需要做到多完善才能被允許裝車。這個(gè)理解上的差異會給項(xiàng)目帶來完全不同的做法。把ASIL當(dāng)分?jǐn)?shù)的人做設(shè)計(jì)的時(shí)候會瘋狂堆冗余什么都上雙通道什么都要最高診斷覆蓋率最后成本翻倍、性能下降、交付延期。把ASIL當(dāng)風(fēng)險(xiǎn)邊界的人會先問這個(gè)功能失效了會造成多嚴(yán)重的后果這種后果發(fā)生的可能性有多大駕駛員能不能在幾秒鐘內(nèi)接管回答完這三個(gè)問題之后ASIL等級自然就出來了后續(xù)的技術(shù)方案要圍繞“把風(fēng)險(xiǎn)壓到這條線以下”來設(shè)計(jì)而不是追求表面上的復(fù)雜度。2. ASIL等級的本質(zhì)一套把“風(fēng)險(xiǎn)”翻譯成“工程要求”的機(jī)制這章節(jié)就是這篇文章的核心主題了。我跟不少人聊過大家普遍能背出ASIL A、B、C、D四個(gè)等級也知道D最高但問到“為什么我的系統(tǒng)是ASIL B而不是ASIL D”的時(shí)候就說不清楚了。說不清楚的原因就是——沒有理解ASIL等級的本質(zhì)是一套翻譯機(jī)制。你可以這樣理解ASIL是連接“事故場景”和“工程要求”的橋梁。事故場景是社會語言、日常語言比如“車子在高速上轉(zhuǎn)向助力突然沒了”工程要求是技術(shù)語言比如“轉(zhuǎn)向扭矩傳感器的診斷覆蓋率要達(dá)到90%以上故障響應(yīng)時(shí)間要小于100ms”。這兩者之間差了十萬八千里ASIL就是那個(gè)把前者翻譯成后者的轉(zhuǎn)換器。2.1 風(fēng)險(xiǎn)三要素嚴(yán)重度、暴露率、可控性具體是怎么翻譯的ISO 26262給了三個(gè)維度參數(shù)英文含義等級范圍嚴(yán)重度Severity失效后果對人員傷害的程度S0~S3S3代表危及生命暴露率Exposure車輛處于危險(xiǎn)場景的頻率/時(shí)長E0~E4E4代表幾乎每次行駛都暴露可控性Controllability駕駛員或其他人員能否通過及時(shí)干預(yù)避免傷害C0~C3C3代表幾乎無法控制這三個(gè)參數(shù)組合查表就能得到對應(yīng)等級。但請注意這可不是簡單的打分然后查表背后每一個(gè)參數(shù)的定義和判定邏輯都值得深挖。嚴(yán)重度S——看的是對“人”的傷害不是對車的損壞。一個(gè)功能失效導(dǎo)致車子撞墻車撞爛了人沒事嚴(yán)重度就不會特別高但如果導(dǎo)致乘員被甩出車外那就是S3。這里有個(gè)常見的爭論點(diǎn)是否要考慮碰撞速度ISO 26262的標(biāo)準(zhǔn)解釋是嚴(yán)重度評估要考慮合理的預(yù)期場景但不能無限上綱上線。比如你在評估車門鎖的功能安全非要說如果高速行駛中車門打開導(dǎo)致乘員甩出嚴(yán)重度很高這就屬于不合理的場景假設(shè)。工程判斷在這里非常重要。暴露率E——指的是車輛或人員處于危險(xiǎn)場景中的概率。比如安全氣囊相關(guān)系統(tǒng)只有當(dāng)碰撞發(fā)生時(shí)才用到但碰撞是個(gè)低概率事件所以E等級的判定就會相對低。相反如果是一個(gè)剎車系統(tǒng)每次行駛都在用那么失效場景的暴露率就會非常高。要注意的是這里評估的不是“失效發(fā)生的概率”而是“場景出現(xiàn)的概率”。失效的概率跟硬件失效率掛鉤是在硬件層面通過FMEDA來計(jì)算的跟這里的E不是一個(gè)概念。這個(gè)區(qū)分特別多人搞混。可控性C——評估的是駕駛員能不能在失效發(fā)生后通過合理反應(yīng)避免傷害。比如轉(zhuǎn)向助力失效雖然方向盤突然變沉但駕駛員使勁還是能轉(zhuǎn)動方向盤的這就有一定的可控性。而如果是剎車完全失效駕駛員踩踏板毫無反應(yīng)那可控性就很低接近C3?？煽匦赃@個(gè)維度是最容易引起爭議的因?yàn)樗婕暗綄θ艘虻募僭O(shè)。ISO 26262在定義可控性的時(shí)候特別強(qiáng)調(diào)要按照“普通駕駛員在典型場景下的反應(yīng)能力”來評估不能假設(shè)每個(gè)人都是賽車手也不能假設(shè)所有人遇到危險(xiǎn)都會發(fā)呆。2.2 組合邏輯與查表一個(gè)實(shí)例帶你算一遍三個(gè)參數(shù)各自量化之后就要組合運(yùn)算了。這里用表格來展示ISO 26262第三部分中定義的組合關(guān)系(具體定義可見ISO 26262-3:2018的表4)嚴(yán)重度S暴露率E可控性CASIL等級S1E1C1QMS2E2C1QMS2E3C2ASIL BS3E2C2ASIL BS3E3C3ASIL DS3E4C3ASIL DS2E4C2ASIL C乍一看這個(gè)表很細(xì)但其實(shí)邏輯非常清晰任何單一維度到達(dá)最高級別都不足以單獨(dú)決定ASIL D只有三個(gè)因素都足夠嚴(yán)重時(shí)才能達(dá)到最高等級。這就是ASIL作為風(fēng)險(xiǎn)管理的本質(zhì)——它平衡的不是單一風(fēng)險(xiǎn)源而是整個(gè)場景的綜合風(fēng)險(xiǎn)水平。舉一個(gè)實(shí)戰(zhàn)例子。假設(shè)在做電動助力轉(zhuǎn)向系統(tǒng)EPS的安全分析。轉(zhuǎn)向助力失效——電機(jī)不輸出扭矩導(dǎo)致方向盤突然變沉。駕駛員在低速時(shí)可以輕松克服阻力完成轉(zhuǎn)向但在高速行駛中突然失去助力會讓人措手不及可能造成車輛偏離車道。嚴(yán)重度呢如果車輛偏出車道撞上對向來車或路側(cè)障礙物可能導(dǎo)致嚴(yán)重傷害甚至死亡所以是S3。暴露率呢EPS在每次駕駛中都持續(xù)工作高速行駛是常見工況所以危險(xiǎn)場景的暴露率很高E3甚至E4?？煽匦阅仉m然方向盤變沉但駕駛員通常還能施加力量控制方向所以C2或C3看具體場景假設(shè)。如果取S3、E3、C2對照標(biāo)準(zhǔn)表格最保守的取值會到ASIL C或者更高取S3、E4、C3就是ASIL D。這就是為什么行業(yè)里普遍把EPS當(dāng)作ASIL D系統(tǒng)來開發(fā)——當(dāng)然企業(yè)也可以通過合理的安全機(jī)制和場景定義來論證到ASIL C但前提是你的分析必須站得住腳。分析邏輯合理、文檔記錄完整審核員才會認(rèn)可你的等級定義。2.3 QM等級的意義不代表不做事而是不需要按ASIL流程執(zhí)行很多人初次接觸ASIL會忽略QM這個(gè)等級。QM是Quality Management的縮寫意思是“按照普通的質(zhì)量管理體系來管理即可”。言下之意就是功能失效后對人的風(fēng)險(xiǎn)足夠低不必要用功能安全那套專門的流程來管控常規(guī)的IATF 16949、APQP那一套就夠了。但注意QM不代表你可以不分析。判斷某個(gè)功能屬不屬于QM本身就是分析的結(jié)果。我看過一些團(tuán)隊(duì)把所有非核心功能都打成QM然后什么安全活動都不做這就過頭了。正確的做法是把每一項(xiàng)功能都做一遍初步危害分析確認(rèn)風(fēng)險(xiǎn)確實(shí)低到不需要功能安全流程介入才能標(biāo)注為QM。這個(gè)初步分析本身要留痕否則審核的時(shí)候被抽查到你說這個(gè)功能是QM的審核員問你怎么論證的拿不出記錄就很被動。3. 從等級到工程實(shí)踐ASIL D需求是怎么落到硬件和代碼里的ASIL等級定完之后難點(diǎn)才真正開始。概念階段定出了安全目標(biāo)(Safety Goal)然后要把安全目標(biāo)分解成功能安全需求(FSR)再分解成技術(shù)安全需求(TSR)最后落到硬件和軟件的設(shè)計(jì)里。這個(gè)過程里有幾個(gè)行業(yè)公認(rèn)的關(guān)鍵操作我逐個(gè)拆開講。3.1 安全目標(biāo)的制定與ASIL分解安全目標(biāo)描述了系統(tǒng)層面要避免的危害事件。比如“避免EPS在行駛過程中非預(yù)期失去助力”。這個(gè)安全目標(biāo)本身帶有ASIL等級然后會被分解到各個(gè)子系統(tǒng)或組成部分。分解的邏輯是這樣的如果整個(gè)系統(tǒng)承擔(dān)一個(gè)ASIL D的安全目標(biāo)但是可以通過兩個(gè)相互獨(dú)立的功能共同實(shí)現(xiàn)這個(gè)目標(biāo)其中每個(gè)功能能獨(dú)立地把風(fēng)險(xiǎn)降到足夠低那么分解之后的每個(gè)功能可以分配低一些的等級。經(jīng)典案例剎車系統(tǒng)。如果安全目標(biāo)是“確保車輛能夠按駕駛員意圖減速”整個(gè)系統(tǒng)是ASIL D。拆分成兩個(gè)獨(dú)立通道——液壓制動通道和線控制動通道——在架構(gòu)上相互獨(dú)立那么每個(gè)通道可以被定義為ASIL C(D)。這個(gè)括號里的D代表分解前的原始等級C是分解后該通道承擔(dān)的等級。兩個(gè)C加在一起搭配獨(dú)立性論證才能證明整體仍然滿足D的要求。這里最關(guān)鍵的就是獨(dú)立性論證。你要拿出證據(jù)證明兩個(gè)通道之間不存在共因失效比如不能共用一個(gè)電源、不能共用一個(gè)傳感器、不能共用一段代碼。如果兩個(gè)通道用的是同一個(gè)MCU那它們之間的獨(dú)立性就大打折扣。我看過不少團(tuán)隊(duì)在做ASIL分解的時(shí)候畫了一個(gè)很漂亮的架構(gòu)圖兩個(gè)冗余通道看起來獨(dú)立結(jié)果往下看細(xì)節(jié)——兩個(gè)通道共享同一個(gè)時(shí)鐘源這獨(dú)立性就得重新討論了。3.2 硬件層面失效率指標(biāo)與FMEDA硬件層面的功能安全工作核心圍繞兩個(gè)東西隨機(jī)硬件失效的量化分析和安全機(jī)制的診斷覆蓋率。量化分析的標(biāo)準(zhǔn)工具是FMEDA(Failure Mode Effects and Diagnostic Analysis)。這個(gè)工具會枚舉一個(gè)硬件組件的每一種失效模式(比如電阻開路、短路、漂移)評估每一種失效模式對安全目標(biāo)的影響以及系統(tǒng)里的診斷機(jī)制(比如電壓監(jiān)控、看門狗、CRC校驗(yàn))能覆蓋多少比例的失效。ISO 26262-5給出了隨機(jī)硬件失效的量化目標(biāo)行業(yè)里大家習(xí)慣用PMHF(Probabilistic Metric for random Hardware Failures隨機(jī)硬件失效概率度量)來評估ASIL等級單條安全目標(biāo)的PMHF目標(biāo)值A(chǔ)SIL A 10?? / 小時(shí)ASIL B 10?? / 小時(shí)ASIL C 10?? / 小時(shí)ASIL D 10?? / 小時(shí)這個(gè)指標(biāo)的分量在于——10??每小時(shí)是什么概念平均下來是每1億小時(shí)才允許出現(xiàn)一次危險(xiǎn)失效。一條安全目標(biāo)在整車生命周期里大概要撐過1萬小時(shí)的運(yùn)行時(shí)間這意味著你要把危險(xiǎn)失效的概率壓到極其微小的水平。實(shí)現(xiàn)這個(gè)目標(biāo)主要靠兩樣?xùn)|西一是選用失效率足夠低的元器件二是設(shè)計(jì)足夠強(qiáng)的診斷覆蓋率。只靠前者會非常燒錢因?yàn)槟愕糜糜詈郊壔蛘咛厥夂Y選的器件聰明做法是靠后者用合理的安全機(jī)制去識別故障在故障導(dǎo)致危險(xiǎn)之前讓系統(tǒng)進(jìn)入安全狀態(tài)。比如用雙通道比較、用自檢邏輯、用外部監(jiān)控芯片——這些都是提高診斷覆蓋率的常規(guī)手段比單純堆器件等級劃算得多。3.3 軟件層面ASIL對架構(gòu)和代碼的要求軟件方面的ASIL要求不像硬件那樣有明確的量化數(shù)字更多是過程要求和架構(gòu)要求。過程部分包括需求的追溯性管理、驗(yàn)證活動覆蓋度、代碼規(guī)范的符合性(比如MISRA C)、靜態(tài)分析工具的引入、單元測試的覆蓋率要求等。架構(gòu)方面的核心是自由度干擾(Freedom From Interference)。這個(gè)概念說的是如果一個(gè)系統(tǒng)里既有ASIL D的軟件組件又有QM的軟件組件那么QM的組件不能以任何方式干擾到ASIL D組件的運(yùn)行。典型的干擾路徑包括內(nèi)存破壞(通過指針操作踩了別人的內(nèi)存)、時(shí)序干擾(搶占了CPU資源)、信息交換干擾(通過共享變量傳遞了錯(cuò)誤數(shù)據(jù))。解決這個(gè)問題常用手段包括在MCU層面啟用MPU(內(nèi)存保護(hù)單元)做地址隔離在AUTOSAR架構(gòu)里對ASIL D組件和QM組件分配不同的OS-Application用E2E(End-to-End)保護(hù)機(jī)制確?？缃M件通信的完整性。這些都是實(shí)際項(xiàng)目中可以直接下手的方案。3.4 工具鏈的置信度你以為你用了個(gè)好工具就夠了工具鏈?zhǔn)琼?xiàng)目里非常容易踩坑但被嚴(yán)重低估的環(huán)節(jié)。ISO 26262-8里對工具進(jìn)行了分類如果某個(gè)工具出了問題會導(dǎo)致安全相關(guān)的輸出被錯(cuò)誤地認(rèn)為正確那么這個(gè)工具就需要被評估和認(rèn)證。比如你的編譯器如果編譯器本身有bug生成了錯(cuò)誤的機(jī)器代碼而你沒有發(fā)現(xiàn)那就直接威脅到安全目標(biāo)了。所以編譯器、靜態(tài)分析工具、單元測試工具、代碼覆蓋率工具這些環(huán)節(jié)都要做工具置信度評估。行業(yè)通用做法是選用已經(jīng)通過TüV等機(jī)構(gòu)認(rèn)證的工具同時(shí)對工具的使用環(huán)境進(jìn)行限定。認(rèn)證不是一勞永逸的事——你必須在項(xiàng)目里按照認(rèn)證時(shí)假定的方式來使用這個(gè)工具如果用法超出了認(rèn)證范圍那認(rèn)證就失效了。4. 項(xiàng)目實(shí)操中的ASIL落地的四大經(jīng)典痛點(diǎn)與我的處理經(jīng)驗(yàn)整個(gè)項(xiàng)目做下來我總結(jié)了幾個(gè)反復(fù)出現(xiàn)的痛點(diǎn)。這些東西在ISO 26262原文里你找不到因?yàn)闆]有哪一條標(biāo)準(zhǔn)會告訴你“這種情況下團(tuán)隊(duì)會犯什么錯(cuò)誤”。但這恰恰是工程實(shí)踐里真正的價(jià)值所在。4.1 ASIL分解被當(dāng)成“降級工具”亂用我剛?cè)胄械臅r(shí)候在一個(gè)項(xiàng)目里看見團(tuán)隊(duì)把Safety Goal定為ASIL D然后靠ASIL分解把每個(gè)子系統(tǒng)都拆成ASIL B整個(gè)系統(tǒng)設(shè)計(jì)難度驟降看起來很“聰明”。但審核的時(shí)候被問到一個(gè)問題兩個(gè)ASIL B的子系統(tǒng)之間的獨(dú)立性證據(jù)在哪里如果節(jié)點(diǎn)A和節(jié)點(diǎn)B之間的通信鏈路是共享總線這條鏈路失效可能導(dǎo)致兩邊同時(shí)收不到正確的數(shù)據(jù)——那整個(gè)系統(tǒng)是否還滿足ASIL D最后這個(gè)項(xiàng)目的分解被審核員打了回來因?yàn)橥ㄐ沛溌返莫?dú)立性論證做不出來。后來我們學(xué)到的經(jīng)驗(yàn)是ASIL分解不是算術(shù)題不能說“兩個(gè)B加起來等于D”。你要仔細(xì)檢查所有共享資源——電源、時(shí)鐘、通信總線、內(nèi)存區(qū)域、甚至開發(fā)工具(同一個(gè)編譯器會不會給兩邊都編出同樣的錯(cuò))——只要有任何一條共享鏈路被失效事件一桿子捅穿分解就站不住腳。實(shí)操建議是做分解之前把這些共享資源列表先做出來規(guī)劃好哪些可以用共享機(jī)制(比如通過診斷來提高共享鏈路的完整性)哪些必須物理隔離。這個(gè)列表應(yīng)該在架構(gòu)設(shè)計(jì)階段就納入考量而不是等審核發(fā)現(xiàn)了才補(bǔ)救。補(bǔ)的代價(jià)非常高昂通常得改架構(gòu)甚至重寫部分軟件。4.2 安全目標(biāo)和場景假設(shè)被“拍腦袋”定下來安全概念階段最常見的錯(cuò)誤就是把安全場景想得太粗。之前帶過一個(gè)團(tuán)隊(duì)做抬頭顯示HUD的安全分析安全目標(biāo)寫得很簡單“避免顯示錯(cuò)誤信息”。但你往下增加細(xì)節(jié)的時(shí)候就得問了——所謂“錯(cuò)誤信息”是指什么數(shù)字顯示錯(cuò)了顯示位置偏移了還是直接不顯示了這些不同的失效形態(tài)帶來的風(fēng)險(xiǎn)等級完全不同。顯示數(shù)字211結(jié)果顯成277可能只是讓駕駛員有點(diǎn)困惑但如果把導(dǎo)航轉(zhuǎn)彎指示提前了100米顯示會誘導(dǎo)駕駛員提前變道這在高速上可能釀成事故。做場景分析的時(shí)候團(tuán)隊(duì)經(jīng)常非常粗線條把整個(gè)HUD系統(tǒng)籠統(tǒng)地當(dāng)一個(gè)整體來評S、E、C最后定了個(gè)ASIL A。我建議的做法是在概念階段就要對每一種功能路徑細(xì)分開來做分析不能把一個(gè)多功能系統(tǒng)的所有功能都用一個(gè)等級蓋住。這是標(biāo)準(zhǔn)的Part 3要求但執(zhí)行中的顆粒度差別非常大。有意思的是根據(jù)工況和功能的敏感度不同HUD的兩個(gè)功能路徑可能評出完全不同的ASIL等級——一個(gè)ASIL A一個(gè)QM。這就是為什么安全分析永遠(yuǎn)不能太快拍板場景建模做得越細(xì)后面的設(shè)計(jì)才越有的放矢。4.3 硬件FMEDA變成了“PPT表演”FMEDA是硬件功能安全的重頭戲但也是注水最嚴(yán)重的環(huán)節(jié)。我做安全分析的時(shí)候見過不少所謂“FMEDA報(bào)告”里面的失效率數(shù)據(jù)居然是憑經(jīng)驗(yàn)估的——沒有參考SN 29500或IEC 62380這些標(biāo)準(zhǔn)數(shù)據(jù)源沒有考慮工作溫度、電壓應(yīng)力這些降額條件甚至有些數(shù)據(jù)直接從別的項(xiàng)目復(fù)制過來。這種報(bào)告在文檔評審里可能蒙混過關(guān)但一旦到了硬件失效計(jì)數(shù)或者現(xiàn)場失效分析的環(huán)節(jié)就會原形畢露。真正扎實(shí)的FMEDA是有數(shù)據(jù)依據(jù)的。每個(gè)元器件的失效率要標(biāo)明引用來源工作應(yīng)力要按實(shí)際電路條件來算安全機(jī)制要跟原理圖一一對應(yīng)。做這個(gè)工作很枯燥但它是硬件安全case的地基。地基如果歪了上面蓋的房子再漂亮也住不了人。另外一個(gè)容易忽視的點(diǎn)是安全機(jī)制本身的失效率也要算進(jìn)去。你加了一個(gè)電壓監(jiān)控芯片來檢測主芯片的電源故障但這個(gè)監(jiān)控芯片自己也有失效率它的失效會導(dǎo)致診斷功能丟失。ISO 26262要求把“安全機(jī)制失效”的影響也納入量化分析。很多FMEDA軟件可以自動把這個(gè)算進(jìn)去但如果你用Excel自己算這塊經(jīng)常被漏掉。4.4 文檔和證據(jù)的“事后補(bǔ)建”與留痕問題功能安全工作里面最有挑戰(zhàn)性的事情之一是它天然傾向于“事后補(bǔ)建”。很多團(tuán)隊(duì)的習(xí)慣是開發(fā)的時(shí)候先不按功能安全流程走等到要交付審核了再集中補(bǔ)文檔把設(shè)計(jì)記錄倒推出來。這種做法在行業(yè)里有一個(gè)不太好聽但很真實(shí)的名字——考古。考古出來的功能安全文檔有一個(gè)致命弱點(diǎn)經(jīng)不起追問。審核員隨便問你一個(gè)變更為什么是這樣你翻半天找不出依據(jù)因?yàn)楫?dāng)時(shí)沒記錄。ISO 26262真正要求的是在開發(fā)過程中同步產(chǎn)生記錄通過配置管理把需求和設(shè)計(jì)的演進(jìn)過程留存下來。這就要求團(tuán)隊(duì)在流程上做調(diào)整——從研發(fā)的立項(xiàng)開始就要在工具鏈中建立需求條目、建立安全檔案、用版本控制管理每一次變更。我自己有一個(gè)習(xí)慣在項(xiàng)目啟動的時(shí)候就跟項(xiàng)目經(jīng)理把“安全檔案邊界”畫清楚。哪些工作產(chǎn)品屬于功能安全檔案需要接受配置管理和變更控制哪些技術(shù)決策需要會議紀(jì)要來留證據(jù)哪些驗(yàn)證活動的記錄要保存多久。這些事情越早定項(xiàng)目后期越省事。否則到了整車型式認(rèn)證或者SOP前的安全評審你會被成千上萬條待補(bǔ)的記錄淹沒。5. 組織能力對ASIL落地的隱性影響這個(gè)點(diǎn)很多人沒意識到說來有點(diǎn)反直覺功能安全最大的瓶頸未必是技術(shù)難度而是組織能力。做ISO 26262項(xiàng)目跟做普通項(xiàng)目最大的區(qū)別在于它對協(xié)作的紀(jì)律性要求非常高。5.1 功能安全工程師不是“寫文檔的”而是“風(fēng)險(xiǎn)翻譯官”很多公司在招功能安全工程師的時(shí)候招聘JD上寫著“負(fù)責(zé)編寫功能安全文檔”“跟蹤功能安全活動”。這種定位從一開始就錯(cuò)了。一個(gè)合格的功能安全工程師真正做的事情是跟系統(tǒng)架構(gòu)師吵架——吵這個(gè)架構(gòu)冗余夠不夠跟硬件工程師爭論——爭這個(gè)失效模式的診斷覆蓋率數(shù)據(jù)來源是否可靠跟項(xiàng)目經(jīng)理談判——談哪個(gè)功能的安全驗(yàn)證周期不夠需要加時(shí)間。安全工程師不是文檔生產(chǎn)機(jī)器而是組織里的風(fēng)險(xiǎn)翻譯官。他要把從概念階段定義的風(fēng)險(xiǎn)翻譯成架構(gòu)層面的方案、硬件層面的指標(biāo)、軟件層面的機(jī)制、測試層面的用例。如果團(tuán)隊(duì)里安全工程師被當(dāng)成寫手來用那么整個(gè)項(xiàng)目的功能安全一定做不深。5.2 安全文化的構(gòu)建比流程工具更重要最后我想聊一個(gè)稍微虛一點(diǎn)但非常根本的話題安全文化。功能安全做得好不好最終會體現(xiàn)在每個(gè)人做決策時(shí)的優(yōu)先級上。一個(gè)做軟件的工程師在寫代碼的時(shí)候發(fā)現(xiàn)可以給診斷模塊加一個(gè)邊界檢查但會讓自己的接口復(fù)雜度變高工期多兩天——他會不會主動說這件事一個(gè)做測試的工程師跑完了安全測試用例發(fā)現(xiàn)有一個(gè)輸入組合沒有覆蓋到但用例已經(jīng)完成95%了他會選擇補(bǔ)上還是直接報(bào)完成安全文化好的團(tuán)隊(duì)這些問題的答案都是前者。安全文化差的團(tuán)隊(duì)無論你把流程設(shè)計(jì)得多完善總會有人找到繞過流程的捷徑。這個(gè)觀點(diǎn)在我跟不少同行的交流中都得到過印證——功能安全到了最后拼的不是工具和流程而是整個(gè)團(tuán)隊(duì)對“安全”這件事的信仰和習(xí)慣。6. 常見問題速查與個(gè)人經(jīng)驗(yàn)總結(jié)這部分把我在項(xiàng)目中實(shí)際遇到的、有代表性的問題做成一個(gè)速查列表適合放在手邊項(xiàng)目不同階段翻出來對照一下。問題我的處理思路關(guān)鍵避坑點(diǎn)安全目標(biāo)定的ASIL等級過高/過低回到場景分析逐條檢查S/E/C的取值依據(jù)嚴(yán)重度評估要結(jié)合真實(shí)碰撞場景不可純理論假設(shè)分解后的安全需求沒有獨(dú)立性的證據(jù)在架構(gòu)設(shè)計(jì)階段就梳理共享資源清單建立隔離機(jī)制通信鏈路和電源是最大風(fēng)險(xiǎn)點(diǎn)優(yōu)先排查硬件失效率數(shù)據(jù)來源不透明統(tǒng)一引用標(biāo)準(zhǔn)數(shù)據(jù)源每個(gè)器件標(biāo)注引用編號和計(jì)算條件不要用“工程經(jīng)驗(yàn)值”代替數(shù)據(jù)源審核時(shí)會翻車軟件診斷覆蓋率怎么定義才合理結(jié)合安全機(jī)制設(shè)計(jì)和故障注入測試結(jié)果反推覆蓋率診斷覆蓋率不是越高越好要兼顧誤報(bào)率和成本工具證書過期的廠商要不要換看證書適用范圍和項(xiàng)目需求匹配程度匹配度不夠就得換不要只看證書logo要看認(rèn)證范圍cover不cover你的用法安全文檔晚于開發(fā)活動生成在項(xiàng)目啟動時(shí)定義好安全檔案邊界和評審節(jié)點(diǎn)事后補(bǔ)文檔的效率極低且質(zhì)量無法保證MBD建模工具生成的代碼要不要單獨(dú)測要尤其是模型到代碼的轉(zhuǎn)換工具本身的置信度要評估工具認(rèn)證有效但集成測試不能省芯片本身沒有功能安全等級證書優(yōu)先選帶FMEDA和安全手冊的芯片沒有這些基礎(chǔ)的器件硬要用審核必然卡關(guān)我個(gè)人在實(shí)際操作中的體會是功能安全項(xiàng)目能不能做順很多時(shí)候取決于第一個(gè)概念階段的會議開得質(zhì)量高不高。那個(gè)會上如果能把安全目標(biāo)寫清楚、把場景邊界劃清楚、把三個(gè)維度的評級依據(jù)討論透后面所有部門的工作都會輕松非常多。而如果概念階段草草了事后面每一個(gè)環(huán)節(jié)都會被反復(fù)拉扯。最后再分享一個(gè)小技巧是你做安全分析會經(jīng)常用到但容易被忽略的把所有安全假設(shè)集中管理。我說的不僅僅是文檔而是建一個(gè)專門的、唯一的“安全假設(shè)登記冊”。每一條安全目標(biāo)依賴的假設(shè)——比如“駕駛員能在2秒內(nèi)接管”“系統(tǒng)在外部溫度低于-40度時(shí)不上電”——都要編號、存檔、并在后續(xù)所有設(shè)計(jì)活動里引用。這么做的好處是當(dāng)項(xiàng)目后期某個(gè)假設(shè)被推翻的時(shí)候(這是經(jīng)常發(fā)生的事比如客戶提出了新的使用場景)你只需要在登記冊里改一條記錄然后去查所有關(guān)聯(lián)的設(shè)計(jì)和驗(yàn)證活動而不是在幾十份文檔里翻來翻去。安全假設(shè)是有生命周期的它們不只是寫在文檔里的靜態(tài)文字而是所有技術(shù)決策的起點(diǎn)。把這個(gè)起點(diǎn)管理好整個(gè)安全case就像一棵根系扎實(shí)的樹任你上面怎么長它都不會倒。