，構(gòu)建智能駕駛安全基石)
1. 從“功能”到“安全”汽車電子系統(tǒng)的范式轉(zhuǎn)移如果你是一位汽車電子工程師或者正在關(guān)注智能駕駛、新能源汽車領(lǐng)域那么“功能安全”這個詞你大概率已經(jīng)聽到耳朵起繭了。但你真的理解它嗎它是不是就是“質(zhì)量好”、“不出故障”的同義詞今天我想從一個一線工程師的視角和你聊聊“汽車功能安全”到底是個什么東西它為什么能成為今天汽車行業(yè)尤其是智能電動汽車領(lǐng)域的“入場券”和“護城河”。簡單來說功能安全Functional Safety的核心不是讓系統(tǒng)“永遠不壞”而是當系統(tǒng)內(nèi)部發(fā)生隨機硬件故障或者軟件出現(xiàn)系統(tǒng)性缺陷時能夠確保系統(tǒng)不會因此導致人身傷害或重大財產(chǎn)損失。它處理的不是“功能是否強大”而是“功能失效時是否安全”。這是一個根本性的思維轉(zhuǎn)變從追求“功能實現(xiàn)”的確定性轉(zhuǎn)向管理“功能失效”的不確定性。當你的車機死機音樂停了這屬于功能問題但如果你的電子助力轉(zhuǎn)向EPS在高速行駛時突然失效或者制動系統(tǒng)誤觸發(fā)這就是功能安全問題。前者影響體驗后者關(guān)乎生死。這個概念的普及與汽車電子電氣架構(gòu)的復雜化直接相關(guān)。十年前一輛車可能有幾十個ECU電子控制單元各自為政今天一輛高端智能汽車的代碼量可能超過一億行ECU數(shù)量上百并且通過高速網(wǎng)絡深度耦合。任何一個節(jié)點的異常都可能通過復雜的信號交互被放大引發(fā)鏈式反應。功能安全就是為這套日益復雜的“神經(jīng)系統(tǒng)”建立一套完整的“免疫系統(tǒng)”和“應急預案”。它不是某個具體的技術(shù)而是一套貫穿產(chǎn)品全生命周期的工程體系和方法論。對于從業(yè)者而言理解功能安全不再是“加分項”而是“必備技能”。無論是做底層軟件、硬件設計、系統(tǒng)架構(gòu)還是測試驗證功能安全的思維都必須融入血液。2. ISO 26262功能安全的“憲法”與工程實踐框架談到汽車功能安全絕對繞不開ISO 26262標準。你可以把它理解為這個領(lǐng)域的“憲法”和“操作手冊”。它不是一個空洞的理論而是一套極其詳盡、可落地的工程開發(fā)流程指南。標準全稱是《道路車輛——功能安全》目前主流版本是2018年的第二版。2.1 核心思想V模型與安全生命周期ISO 26262的核心開發(fā)模型是廣為人知的“V模型”。但功能安全的V模型比普通的軟件開發(fā)V模型要“重”得多。它的左側(cè)是自上而下的“分解”過程從概念階段開始定義整車級別的安全目標然后逐級分配到系統(tǒng)、硬件和軟件。右側(cè)是自下而上的“集成與驗證”過程對硬件、軟件、系統(tǒng)進行測試最終驗證整車是否滿足了最初的安全目標。這個“V”的每一個環(huán)節(jié)都充滿了具體的要求和產(chǎn)出物。更重要的是“安全生命周期”的概念。功能安全不是開發(fā)后期“補”上去的而是從產(chǎn)品概念誕生之初就啟動一直持續(xù)到產(chǎn)品停產(chǎn)后的報廢處理。它包括了管理建立獨立的功能安全團隊明確職責進行安全活動評審和審計。開發(fā)涵蓋概念、系統(tǒng)、硬件、軟件各個層級的開發(fā)。生產(chǎn)、運維、服務與報廢確保量產(chǎn)一致性處理售后問題甚至指導報廢流程。我見過很多團隊初期最大的誤區(qū)就是把功能安全等同于“做一堆測試”或者“寫一堆文檔”。實際上它首先是一套管理流程確保安全相關(guān)的決策、設計和驗證活動被一個獨立的、有權(quán)威的體系所管理和追溯。沒有有效的管理再好的技術(shù)也無法保證安全。2.2 核心概念ASIL等級與安全目標這是ISO 26262中最具特色的部分。ASILAutomotive Safety Integrity Level汽車安全完整性等級是對一個功能或組件所需達到的安全保障程度的量化分級。它由三個因素決定嚴重度S潛在傷害的嚴重程度S0~S3。暴露率E危險駕駛場景發(fā)生的概率E1~E4?？煽匦訡駕駛員或其他涉險人員避免傷害的可能性C1~C3。通過一張評估表這三個參數(shù)組合起來最終確定ASIL等級QM質(zhì)量管理、A、B、C、D。其中ASIL D是最高等級要求最嚴苛。例如電動助力轉(zhuǎn)向系統(tǒng)失效可能導致車輛失控嚴重度高S3在高速場景下發(fā)生概率不低E4駕駛員難以控制C3那么它的安全目標“避免轉(zhuǎn)向助力非預期喪失”很可能就是ASIL D。安全目標Safety Goal就是針對每個危害Hazard所制定的、最高層級的安全要求。它必須是技術(shù)無關(guān)的、可驗證的頂層要求。比如“車輛不得非預期加速”就是一個安全目標。之后所有的技術(shù)方案無論是采用冗余的電機控制器還是增加獨立的監(jiān)控芯片都是為了實現(xiàn)這個安全目標。ASIL等級就“附著”在安全目標上并隨之向下游系統(tǒng)、硬件、軟件需求傳遞。這意味著一個被定義為ASIL D的軟件模塊其開發(fā)流程、代碼規(guī)范、測試覆蓋率的要求與一個QM等級的娛樂系統(tǒng)模塊是天壤之別。3. 技術(shù)實現(xiàn)基石硬件與軟件的安全機制理解了“憲法”標準和“目標”安全目標與ASIL下一步就是看如何用“磚瓦”技術(shù)把它建起來。這主要分為硬件和軟件兩個戰(zhàn)場。3.1 硬件安全機制冗余、診斷與監(jiān)控硬件隨機故障是物理規(guī)律無法完全避免。功能安全的策略是“假設它一定會發(fā)生并準備好應對措施”。核心手段包括1. 硬件架構(gòu)度量Hardware Architectural Metrics這是ISO 26262 Part 5中用于量化評估硬件隨機失效風險的數(shù)學工具。主要有兩個關(guān)鍵指標單點故障度量SPFM衡量架構(gòu)對單點故障一個故障直接導致安全目標違背的覆蓋程度。ASIL D要求通常 99%。潛伏故障度量LFM衡量架構(gòu)對潛伏故障一個故障發(fā)生了但未被檢測到與后續(xù)另一個故障組合導致危險的覆蓋程度。ASIL D要求通常 90%。如何達標核心就是冗余和診斷。冗余比如采用雙核鎖步Lockstep的微控制器。兩個核心執(zhí)行相同的指令實時比較輸出。一旦不一致立刻觸發(fā)安全狀態(tài)如關(guān)閉輸出。這是應對隨機位翻轉(zhuǎn)比如宇宙射線導致的軟錯誤的典型方案。診斷在非冗余的路徑上增加周期性或事件觸發(fā)的自檢。例如對ADC模數(shù)轉(zhuǎn)換器注入已知測試電壓檢查轉(zhuǎn)換結(jié)果是否在預期范圍內(nèi)對RAM進行March算法測試檢測存儲單元是否損壞對通信總線如CAN FD使用CRC校驗和應答超時機制。2. 安全監(jiān)控芯片Safety Monitor在一些高安全等級的應用中如電池管理主控、制動控制器除了主功能MCU還會增設一顆獨立的、更簡單的安全監(jiān)控MCU。它的唯一任務就是監(jiān)控主MCU的行為心跳信號是否正常關(guān)鍵輸出信號如PWM占空比是否在合理范圍內(nèi)一旦發(fā)現(xiàn)異常安全監(jiān)控MCU擁有更高的權(quán)限可以直接切斷功率回路或觸發(fā)備份方案。這種“二人原則”是確保系統(tǒng)失效安全的有效手段。3.2 軟件安全機制架構(gòu)與代碼層面的防御軟件不會“隨機”故障但會存在“系統(tǒng)性”缺陷如設計錯誤、編碼錯誤。功能安全在軟件層面的核心是“避免引入缺陷”和“防止缺陷傳播”。1. 安全軟件架構(gòu)內(nèi)存分區(qū)Memory Partitioning在支持MPU內(nèi)存保護單元或MMU內(nèi)存管理單元的MCU上將不同ASIL等級的軟件模塊甚至與非安全相關(guān)的模塊AUTOSAR中的BSW、應用層進行嚴格的內(nèi)存隔離。防止一個低安全等級模塊的跑飛代碼篡改高安全等級模塊的數(shù)據(jù)或代碼。時間分區(qū)Time Partitioning在實時操作系統(tǒng)如AUTOSAR OS、OSEK中為不同安全等級的任務分配固定的時間窗口和優(yōu)先級確保高安全等級任務的計算資源不被剝奪。健康監(jiān)控Health Monitoring軟件層面也需要實施監(jiān)控例如監(jiān)控任務執(zhí)行時間是否超時、棧溢出、邏輯監(jiān)控如檢查車輛速度信號與輪速信號是否邏輯自洽。2. 編碼規(guī)范與驗證ISO 26262 Part 6推薦使用像MISRA C/C這樣的編碼規(guī)范來規(guī)避語言本身的脆弱性可能帶來的風險。例如禁止使用遞歸、限制指針的使用、要求所有路徑都必須有返回值等。更重要的是驗證單元測試要達到極高的語句覆蓋SC和分支覆蓋DCASIL D通常要求100%的MC/DC修正條件/判定覆蓋這是一種更嚴格的邏輯覆蓋準則能有效發(fā)現(xiàn)條件判斷中的邏輯錯誤。靜態(tài)代碼分析使用工具如Polyspace, Coverity進行數(shù)據(jù)流分析、控制流分析提前發(fā)現(xiàn)潛在的運行時錯誤如除零、數(shù)組越界、空指針解引用。代碼審查針對安全相關(guān)的核心代碼進行基于 checklist 的同行評審。注意很多團隊認為用了AUTOSAR架構(gòu)就自動滿足了功能安全這是極大的誤解。AUTOSAR標準特別是Classic Platform提供了支持功能安全的基礎設施如操作系統(tǒng)、通信棧但如何配置和使用這些基礎設施來實現(xiàn)具體的安全目標并滿足ISO 26262各環(huán)節(jié)的要求完全是開發(fā)團隊的責任。AUTOSAR是“工具箱”ISO 26262是“施工標準和驗收規(guī)范”。4. 開發(fā)流程中的關(guān)鍵活動與常見“坑點”功能安全不是紙上談兵最終要落到每一天的開發(fā)活動中。以下幾個環(huán)節(jié)最容易出問題也是體現(xiàn)工程團隊功力的地方。4.1 危害分析與風險評估HARA這是所有安全工作的起點也是最容易“拍腦袋”的環(huán)節(jié)。HARA的目標是系統(tǒng)性地識別出所有可能的危害并評估其ASIL等級。常見的坑包括場景考慮不全只考慮了正常駕駛工況忽略了拖車、維修、充電等特殊場景。例如為高壓電池包做HARA時必須考慮維修人員手動斷開維修開關(guān)的瞬間是否存在電弧風險?？煽匦訡評估過于樂觀總假設駕駛員是“賽車手”能應對所有突發(fā)狀況。標準附錄中提供了可控性評估的指導需要結(jié)合具體危害和典型用戶群體如老年駕駛員來客觀評價。安全目標定義不精確安全目標必須是“可驗證的”、“技術(shù)無關(guān)的”。例如“提高制動可靠性”就不是一個好的安全目標“車輛在速度5km/h時駕駛員制動請求必須能在X秒內(nèi)使車輛減速度達到Y(jié) m/s2”則相對明確。實操建議組織跨部門的HARA研討會邀請系統(tǒng)、軟件、硬件、測試甚至售后服務的工程師一起進行頭腦風暴。使用FMEA失效模式與影響分析和HAZOP危險與可操作性分析等方法作為輔助工具。所有討論和決策必須有記錄并經(jīng)過評審。4.2 安全需求的定義與追溯安全需求是從安全目標層層分解下來的。這里最大的挑戰(zhàn)是保證需求的精確性和可追溯性。精確性需求要避免歧義?！跋到y(tǒng)應快速響應”是糟糕的需求“系統(tǒng)應在收到信號后10ms內(nèi)輸出響應且抖動不超過1ms”才是好的需求?？勺匪菪员仨毥陌踩繕?技術(shù)安全需求-系統(tǒng)需求-硬件/軟件需求的完整追溯鏈。當?shù)讓訙y試發(fā)現(xiàn)一個bug時要能追溯到它違反了哪條頂層安全目標。這通常需要借助專業(yè)的需求管理工具如DOORS, Polarion來實現(xiàn)。我經(jīng)歷過一個項目因為早期需求描述模糊“監(jiān)控電池溫度”導致硬件團隊設計了一個采樣頻率很低的溫度監(jiān)控電路而軟件團隊以為會有一個高速的監(jiān)控回路。直到集成測試時才發(fā)現(xiàn)對于熱失控這種快速演進的風險該監(jiān)控根本來不及反應。根源就在于需求沒有明確“監(jiān)控的響應時間”這個關(guān)鍵屬性。4.3 測試與驗證的深度功能安全的測試不只是“測功能”更是“測失效”。除了常規(guī)的功能測試必須重點進行故障注入測試。硬件故障注入模擬MCU引腳短路/開路、傳感器信號偏移、執(zhí)行器如電機堵轉(zhuǎn)等。軟件故障注入在代碼中模擬變量被篡改、消息丟失或延遲、服務調(diào)用失敗等。網(wǎng)絡故障注入模擬CAN總線錯誤幀、網(wǎng)絡負載激增、ECU節(jié)點掉線等。測試的目的是驗證你設計的所有安全機制如冗余、監(jiān)控是否真的能在故障發(fā)生時正確觸發(fā)并將系統(tǒng)帶入預定義的安全狀態(tài)如降功率、跛行、安全關(guān)閉。安全狀態(tài)的定義必須清晰且可達成例如“關(guān)閉驅(qū)動電機保持轉(zhuǎn)向助力點亮故障燈允許車輛靠邊滑行”。5. 新興挑戰(zhàn)SOTIF與預期功能安全隨著自動駕駛技術(shù)的發(fā)展我們發(fā)現(xiàn)即使系統(tǒng)毫無故障滿足了ISO 26262也可能因為性能局限、場景復雜或人為誤用而導致事故。這就是預期功能安全SOTIF, Safety Of The Intended Functionality由ISO 21448標準定義。SOTIF關(guān)注的是“沒有故障但依然不安全”的場景主要分為兩類已知不安全場景比如攝像頭在強逆光下致盲激光雷達在大雨中性能下降。對于這類場景需要通過改進傳感器融合算法、增加冗余傳感器如毫米波雷達來降低風險并定義其可接受的風險水平。未知不安全場景系統(tǒng)設計時未考慮到的“長尾”極端場景。比如一個訓練數(shù)據(jù)中從未出現(xiàn)過的、形狀奇異的障礙物。SOTIF的開發(fā)流程同樣包含場景識別、觸發(fā)條件分析、改進措施、驗證確認等環(huán)節(jié)。其驗證極度依賴海量的場景庫和仿真測試。與ISO 26262的確定性驗證不同SOTIF的驗證更像是一個統(tǒng)計學過程需要證明在考慮了已知和潛在未知場景后系統(tǒng)的風險已降至可接受范圍。這對工程團隊提出了全新挑戰(zhàn)需要構(gòu)建強大的數(shù)據(jù)采集車隊、高保真仿真環(huán)境、以及處理海量場景數(shù)據(jù)的工具鏈。SOTIF與ISO 26262不是替代關(guān)系而是互補關(guān)系。一個安全的自動駕駛系統(tǒng)必須同時滿足兩者要求。6. 功能安全文化比流程和工具更重要最后我想強調(diào)一點也是最容易被忽視的一點功能安全文化。再完美的流程再先進的工具如果執(zhí)行的人不理解、不認同最終都會流于形式變成“為了認證而做”的紙面文章。功能安全文化的核心是質(zhì)疑的態(tài)度對任何設計、任何假設都保持警惕。“這個傳感器萬一提供錯誤值怎么辦”“這兩路冗余電源如果同時掉電怎么辦”透明的溝通鼓勵工程師主動報告潛在的安全隱患而不是隱瞞或回避。建立無責備Blame-free的文化關(guān)注問題本身而非追究個人責任。持續(xù)的學習功能安全標準和技術(shù)都在演進。團隊需要定期復盤項目中的安全相關(guān)事件包括未遂事件將其轉(zhuǎn)化為經(jīng)驗教訓更新到流程和設計中。在我參與的項目中最成功的不是那些工具最貴的而是那些從項目經(jīng)理到普通工程師都能在日常討論中自然說出“這里需要考慮單點故障度量”、“那個需求的可追溯性需要加強”的團隊。功能安全最終要內(nèi)化為工程師的思維本能。汽車功能安全是一個龐大而精深的體系一篇短文只能觸及冰山一角。它融合了系統(tǒng)工程、硬件工程、軟件工程、質(zhì)量管理等多個學科。對于從業(yè)者而言深入理解它不僅能讓你設計出更可靠的產(chǎn)品更能讓你建立起一套應對復雜系統(tǒng)風險的嚴謹思維框架。這條路沒有捷徑需要的是對細節(jié)的執(zhí)著、對流程的尊重以及始終將人的安全置于首位的敬畏之心。 汽車功能安全：從ISO 26262標準到軟硬件實現(xiàn)，構(gòu)建智能駕駛安全基石
1. 從“功能”到“安全”汽車電子系統(tǒng)的范式轉(zhuǎn)移如果你是一位汽車電子工程師或者正在關(guān)注智能駕駛、新能源汽車領(lǐng)域那么“功能安全”這個詞你大概率已經(jīng)聽到耳朵起繭了。但你真的理解它嗎它是不是就是“質(zhì)量好”、“不出故障”的同義詞今天我想從一個一線工程師的視角和你聊聊“汽車功能安全”到底是個什么東西它為什么能成為今天汽車行業(yè)尤其是智能電動汽車領(lǐng)域的“入場券”和“護城河”。簡單來說功能安全Functional Safety的核心不是讓系統(tǒng)“永遠不壞”而是當系統(tǒng)內(nèi)部發(fā)生隨機硬件故障或者軟件出現(xiàn)系統(tǒng)性缺陷時能夠確保系統(tǒng)不會因此導致人身傷害或重大財產(chǎn)損失。它處理的不是“功能是否強大”而是“功能失效時是否安全”。這是一個根本性的思維轉(zhuǎn)變從追求“功能實現(xiàn)”的確定性轉(zhuǎn)向管理“功能失效”的不確定性。當你的車機死機音樂停了這屬于功能問題但如果你的電子助力轉(zhuǎn)向EPS在高速行駛時突然失效或者制動系統(tǒng)誤觸發(fā)這就是功能安全問題。前者影響體驗后者關(guān)乎生死。這個概念的普及與汽車電子電氣架構(gòu)的復雜化直接相關(guān)。十年前一輛車可能有幾十個ECU電子控制單元各自為政今天一輛高端智能汽車的代碼量可能超過一億行ECU數(shù)量上百并且通過高速網(wǎng)絡深度耦合。任何一個節(jié)點的異常都可能通過復雜的信號交互被放大引發(fā)鏈式反應。功能安全就是為這套日益復雜的“神經(jīng)系統(tǒng)”建立一套完整的“免疫系統(tǒng)”和“應急預案”。它不是某個具體的技術(shù)而是一套貫穿產(chǎn)品全生命周期的工程體系和方法論。對于從業(yè)者而言理解功能安全不再是“加分項”而是“必備技能”。無論是做底層軟件、硬件設計、系統(tǒng)架構(gòu)還是測試驗證功能安全的思維都必須融入血液。2. ISO 26262功能安全的“憲法”與工程實踐框架談到汽車功能安全絕對繞不開ISO 26262標準。你可以把它理解為這個領(lǐng)域的“憲法”和“操作手冊”。它不是一個空洞的理論而是一套極其詳盡、可落地的工程開發(fā)流程指南。標準全稱是《道路車輛——功能安全》目前主流版本是2018年的第二版。2.1 核心思想V模型與安全生命周期ISO 26262的核心開發(fā)模型是廣為人知的“V模型”。但功能安全的V模型比普通的軟件開發(fā)V模型要“重”得多。它的左側(cè)是自上而下的“分解”過程從概念階段開始定義整車級別的安全目標然后逐級分配到系統(tǒng)、硬件和軟件。右側(cè)是自下而上的“集成與驗證”過程對硬件、軟件、系統(tǒng)進行測試最終驗證整車是否滿足了最初的安全目標。這個“V”的每一個環(huán)節(jié)都充滿了具體的要求和產(chǎn)出物。更重要的是“安全生命周期”的概念。功能安全不是開發(fā)后期“補”上去的而是從產(chǎn)品概念誕生之初就啟動一直持續(xù)到產(chǎn)品停產(chǎn)后的報廢處理。它包括了管理建立獨立的功能安全團隊明確職責進行安全活動評審和審計。開發(fā)涵蓋概念、系統(tǒng)、硬件、軟件各個層級的開發(fā)。生產(chǎn)、運維、服務與報廢確保量產(chǎn)一致性處理售后問題甚至指導報廢流程。我見過很多團隊初期最大的誤區(qū)就是把功能安全等同于“做一堆測試”或者“寫一堆文檔”。實際上它首先是一套管理流程確保安全相關(guān)的決策、設計和驗證活動被一個獨立的、有權(quán)威的體系所管理和追溯。沒有有效的管理再好的技術(shù)也無法保證安全。2.2 核心概念ASIL等級與安全目標這是ISO 26262中最具特色的部分。ASILAutomotive Safety Integrity Level汽車安全完整性等級是對一個功能或組件所需達到的安全保障程度的量化分級。它由三個因素決定嚴重度S潛在傷害的嚴重程度S0~S3。暴露率E危險駕駛場景發(fā)生的概率E1~E4?？煽匦訡駕駛員或其他涉險人員避免傷害的可能性C1~C3。通過一張評估表這三個參數(shù)組合起來最終確定ASIL等級QM質(zhì)量管理、A、B、C、D。其中ASIL D是最高等級要求最嚴苛。例如電動助力轉(zhuǎn)向系統(tǒng)失效可能導致車輛失控嚴重度高S3在高速場景下發(fā)生概率不低E4駕駛員難以控制C3那么它的安全目標“避免轉(zhuǎn)向助力非預期喪失”很可能就是ASIL D。安全目標Safety Goal就是針對每個危害Hazard所制定的、最高層級的安全要求。它必須是技術(shù)無關(guān)的、可驗證的頂層要求。比如“車輛不得非預期加速”就是一個安全目標。之后所有的技術(shù)方案無論是采用冗余的電機控制器還是增加獨立的監(jiān)控芯片都是為了實現(xiàn)這個安全目標。ASIL等級就“附著”在安全目標上并隨之向下游系統(tǒng)、硬件、軟件需求傳遞。這意味著一個被定義為ASIL D的軟件模塊其開發(fā)流程、代碼規(guī)范、測試覆蓋率的要求與一個QM等級的娛樂系統(tǒng)模塊是天壤之別。3. 技術(shù)實現(xiàn)基石硬件與軟件的安全機制理解了“憲法”標準和“目標”安全目標與ASIL下一步就是看如何用“磚瓦”技術(shù)把它建起來。這主要分為硬件和軟件兩個戰(zhàn)場。3.1 硬件安全機制冗余、診斷與監(jiān)控硬件隨機故障是物理規(guī)律無法完全避免。功能安全的策略是“假設它一定會發(fā)生并準備好應對措施”。核心手段包括1. 硬件架構(gòu)度量Hardware Architectural Metrics這是ISO 26262 Part 5中用于量化評估硬件隨機失效風險的數(shù)學工具。主要有兩個關(guān)鍵指標單點故障度量SPFM衡量架構(gòu)對單點故障一個故障直接導致安全目標違背的覆蓋程度。ASIL D要求通常 99%。潛伏故障度量LFM衡量架構(gòu)對潛伏故障一個故障發(fā)生了但未被檢測到與后續(xù)另一個故障組合導致危險的覆蓋程度。ASIL D要求通常 90%。如何達標核心就是冗余和診斷。冗余比如采用雙核鎖步Lockstep的微控制器。兩個核心執(zhí)行相同的指令實時比較輸出。一旦不一致立刻觸發(fā)安全狀態(tài)如關(guān)閉輸出。這是應對隨機位翻轉(zhuǎn)比如宇宙射線導致的軟錯誤的典型方案。診斷在非冗余的路徑上增加周期性或事件觸發(fā)的自檢。例如對ADC模數(shù)轉(zhuǎn)換器注入已知測試電壓檢查轉(zhuǎn)換結(jié)果是否在預期范圍內(nèi)對RAM進行March算法測試檢測存儲單元是否損壞對通信總線如CAN FD使用CRC校驗和應答超時機制。2. 安全監(jiān)控芯片Safety Monitor在一些高安全等級的應用中如電池管理主控、制動控制器除了主功能MCU還會增設一顆獨立的、更簡單的安全監(jiān)控MCU。它的唯一任務就是監(jiān)控主MCU的行為心跳信號是否正常關(guān)鍵輸出信號如PWM占空比是否在合理范圍內(nèi)一旦發(fā)現(xiàn)異常安全監(jiān)控MCU擁有更高的權(quán)限可以直接切斷功率回路或觸發(fā)備份方案。這種“二人原則”是確保系統(tǒng)失效安全的有效手段。3.2 軟件安全機制架構(gòu)與代碼層面的防御軟件不會“隨機”故障但會存在“系統(tǒng)性”缺陷如設計錯誤、編碼錯誤。功能安全在軟件層面的核心是“避免引入缺陷”和“防止缺陷傳播”。1. 安全軟件架構(gòu)內(nèi)存分區(qū)Memory Partitioning在支持MPU內(nèi)存保護單元或MMU內(nèi)存管理單元的MCU上將不同ASIL等級的軟件模塊甚至與非安全相關(guān)的模塊AUTOSAR中的BSW、應用層進行嚴格的內(nèi)存隔離。防止一個低安全等級模塊的跑飛代碼篡改高安全等級模塊的數(shù)據(jù)或代碼。時間分區(qū)Time Partitioning在實時操作系統(tǒng)如AUTOSAR OS、OSEK中為不同安全等級的任務分配固定的時間窗口和優(yōu)先級確保高安全等級任務的計算資源不被剝奪。健康監(jiān)控Health Monitoring軟件層面也需要實施監(jiān)控例如監(jiān)控任務執(zhí)行時間是否超時、棧溢出、邏輯監(jiān)控如檢查車輛速度信號與輪速信號是否邏輯自洽。2. 編碼規(guī)范與驗證ISO 26262 Part 6推薦使用像MISRA C/C這樣的編碼規(guī)范來規(guī)避語言本身的脆弱性可能帶來的風險。例如禁止使用遞歸、限制指針的使用、要求所有路徑都必須有返回值等。更重要的是驗證單元測試要達到極高的語句覆蓋SC和分支覆蓋DCASIL D通常要求100%的MC/DC修正條件/判定覆蓋這是一種更嚴格的邏輯覆蓋準則能有效發(fā)現(xiàn)條件判斷中的邏輯錯誤。靜態(tài)代碼分析使用工具如Polyspace, Coverity進行數(shù)據(jù)流分析、控制流分析提前發(fā)現(xiàn)潛在的運行時錯誤如除零、數(shù)組越界、空指針解引用。代碼審查針對安全相關(guān)的核心代碼進行基于 checklist 的同行評審。注意很多團隊認為用了AUTOSAR架構(gòu)就自動滿足了功能安全這是極大的誤解。AUTOSAR標準特別是Classic Platform提供了支持功能安全的基礎設施如操作系統(tǒng)、通信棧但如何配置和使用這些基礎設施來實現(xiàn)具體的安全目標并滿足ISO 26262各環(huán)節(jié)的要求完全是開發(fā)團隊的責任。AUTOSAR是“工具箱”ISO 26262是“施工標準和驗收規(guī)范”。4. 開發(fā)流程中的關(guān)鍵活動與常見“坑點”功能安全不是紙上談兵最終要落到每一天的開發(fā)活動中。以下幾個環(huán)節(jié)最容易出問題也是體現(xiàn)工程團隊功力的地方。4.1 危害分析與風險評估HARA這是所有安全工作的起點也是最容易“拍腦袋”的環(huán)節(jié)。HARA的目標是系統(tǒng)性地識別出所有可能的危害并評估其ASIL等級。常見的坑包括場景考慮不全只考慮了正常駕駛工況忽略了拖車、維修、充電等特殊場景。例如為高壓電池包做HARA時必須考慮維修人員手動斷開維修開關(guān)的瞬間是否存在電弧風險?？煽匦訡評估過于樂觀總假設駕駛員是“賽車手”能應對所有突發(fā)狀況。標準附錄中提供了可控性評估的指導需要結(jié)合具體危害和典型用戶群體如老年駕駛員來客觀評價。安全目標定義不精確安全目標必須是“可驗證的”、“技術(shù)無關(guān)的”。例如“提高制動可靠性”就不是一個好的安全目標“車輛在速度5km/h時駕駛員制動請求必須能在X秒內(nèi)使車輛減速度達到Y(jié) m/s2”則相對明確。實操建議組織跨部門的HARA研討會邀請系統(tǒng)、軟件、硬件、測試甚至售后服務的工程師一起進行頭腦風暴。使用FMEA失效模式與影響分析和HAZOP危險與可操作性分析等方法作為輔助工具。所有討論和決策必須有記錄并經(jīng)過評審。4.2 安全需求的定義與追溯安全需求是從安全目標層層分解下來的。這里最大的挑戰(zhàn)是保證需求的精確性和可追溯性。精確性需求要避免歧義?！跋到y(tǒng)應快速響應”是糟糕的需求“系統(tǒng)應在收到信號后10ms內(nèi)輸出響應且抖動不超過1ms”才是好的需求?？勺匪菪员仨毥陌踩繕?技術(shù)安全需求-系統(tǒng)需求-硬件/軟件需求的完整追溯鏈。當?shù)讓訙y試發(fā)現(xiàn)一個bug時要能追溯到它違反了哪條頂層安全目標。這通常需要借助專業(yè)的需求管理工具如DOORS, Polarion來實現(xiàn)。我經(jīng)歷過一個項目因為早期需求描述模糊“監(jiān)控電池溫度”導致硬件團隊設計了一個采樣頻率很低的溫度監(jiān)控電路而軟件團隊以為會有一個高速的監(jiān)控回路。直到集成測試時才發(fā)現(xiàn)對于熱失控這種快速演進的風險該監(jiān)控根本來不及反應。根源就在于需求沒有明確“監(jiān)控的響應時間”這個關(guān)鍵屬性。4.3 測試與驗證的深度功能安全的測試不只是“測功能”更是“測失效”。除了常規(guī)的功能測試必須重點進行故障注入測試。硬件故障注入模擬MCU引腳短路/開路、傳感器信號偏移、執(zhí)行器如電機堵轉(zhuǎn)等。軟件故障注入在代碼中模擬變量被篡改、消息丟失或延遲、服務調(diào)用失敗等。網(wǎng)絡故障注入模擬CAN總線錯誤幀、網(wǎng)絡負載激增、ECU節(jié)點掉線等。測試的目的是驗證你設計的所有安全機制如冗余、監(jiān)控是否真的能在故障發(fā)生時正確觸發(fā)并將系統(tǒng)帶入預定義的安全狀態(tài)如降功率、跛行、安全關(guān)閉。安全狀態(tài)的定義必須清晰且可達成例如“關(guān)閉驅(qū)動電機保持轉(zhuǎn)向助力點亮故障燈允許車輛靠邊滑行”。5. 新興挑戰(zhàn)SOTIF與預期功能安全隨著自動駕駛技術(shù)的發(fā)展我們發(fā)現(xiàn)即使系統(tǒng)毫無故障滿足了ISO 26262也可能因為性能局限、場景復雜或人為誤用而導致事故。這就是預期功能安全SOTIF, Safety Of The Intended Functionality由ISO 21448標準定義。SOTIF關(guān)注的是“沒有故障但依然不安全”的場景主要分為兩類已知不安全場景比如攝像頭在強逆光下致盲激光雷達在大雨中性能下降。對于這類場景需要通過改進傳感器融合算法、增加冗余傳感器如毫米波雷達來降低風險并定義其可接受的風險水平。未知不安全場景系統(tǒng)設計時未考慮到的“長尾”極端場景。比如一個訓練數(shù)據(jù)中從未出現(xiàn)過的、形狀奇異的障礙物。SOTIF的開發(fā)流程同樣包含場景識別、觸發(fā)條件分析、改進措施、驗證確認等環(huán)節(jié)。其驗證極度依賴海量的場景庫和仿真測試。與ISO 26262的確定性驗證不同SOTIF的驗證更像是一個統(tǒng)計學過程需要證明在考慮了已知和潛在未知場景后系統(tǒng)的風險已降至可接受范圍。這對工程團隊提出了全新挑戰(zhàn)需要構(gòu)建強大的數(shù)據(jù)采集車隊、高保真仿真環(huán)境、以及處理海量場景數(shù)據(jù)的工具鏈。SOTIF與ISO 26262不是替代關(guān)系而是互補關(guān)系。一個安全的自動駕駛系統(tǒng)必須同時滿足兩者要求。6. 功能安全文化比流程和工具更重要最后我想強調(diào)一點也是最容易被忽視的一點功能安全文化。再完美的流程再先進的工具如果執(zhí)行的人不理解、不認同最終都會流于形式變成“為了認證而做”的紙面文章。功能安全文化的核心是質(zhì)疑的態(tài)度對任何設計、任何假設都保持警惕。“這個傳感器萬一提供錯誤值怎么辦”“這兩路冗余電源如果同時掉電怎么辦”透明的溝通鼓勵工程師主動報告潛在的安全隱患而不是隱瞞或回避。建立無責備Blame-free的文化關(guān)注問題本身而非追究個人責任。持續(xù)的學習功能安全標準和技術(shù)都在演進。團隊需要定期復盤項目中的安全相關(guān)事件包括未遂事件將其轉(zhuǎn)化為經(jīng)驗教訓更新到流程和設計中。在我參與的項目中最成功的不是那些工具最貴的而是那些從項目經(jīng)理到普通工程師都能在日常討論中自然說出“這里需要考慮單點故障度量”、“那個需求的可追溯性需要加強”的團隊。功能安全最終要內(nèi)化為工程師的思維本能。汽車功能安全是一個龐大而精深的體系一篇短文只能觸及冰山一角。它融合了系統(tǒng)工程、硬件工程、軟件工程、質(zhì)量管理等多個學科。對于從業(yè)者而言深入理解它不僅能讓你設計出更可靠的產(chǎn)品更能讓你建立起一套應對復雜系統(tǒng)風險的嚴謹思維框架。這條路沒有捷徑需要的是對細節(jié)的執(zhí)著、對流程的尊重以及始終將人的安全置于首位的敬畏之心。