1.范圍與基本術(shù)語

1.1.范圍

       本文聚焦智能駕駛AI SoC、異構(gòu)中央計(jì)算芯片和高性能域控制器計(jì)算平臺的功能安全論證問題。討論對象包括芯片內(nèi)部的CPU、GPU、NPU、ISP、DDR控制器、NoC、安全島、接口和軟件支撐棧，以及它們在安全相關(guān)計(jì)算路徑中的組合關(guān)系。

       本文不對任何具體企業(yè)或產(chǎn)品作出認(rèn)證結(jié)論，也不將“復(fù)雜"或“簡單"等同于“符合"或“不符合"。分析重點(diǎn)是說明：當(dāng)宣傳材料出現(xiàn)“ASIL D芯片"、“ASIL D AI計(jì)算平臺"等表述時(shí)，技術(shù)人員應(yīng)如何判斷結(jié)論邊界和證據(jù)充分性。

1.2.基本術(shù)語

表1  基本術(shù)語

2. ASIL D的對象、邊界與證據(jù)類型

2.1.ASIL首先屬于安全目標(biāo)和安全需求

       ISO 26262-3將相關(guān)項(xiàng)定義、危害分析與風(fēng)險(xiǎn)評估以及功能安全概念納入概念階段。由此形成的ASIL被分配給安全目標(biāo)，并逐級落實(shí)至系統(tǒng)、硬件和軟件安全需求[1]。因此，“產(chǎn)品達(dá)到ASIL D"必須被理解為一個(gè)有邊界的工程結(jié)論，而不是脫離應(yīng)用場景的固定標(biāo)簽。

2.2.對半導(dǎo)體產(chǎn)品應(yīng)特別說明SEooC假設(shè)

       ISO 26262-11提供半導(dǎo)體應(yīng)用指南，用于解釋ISO 26262其他部分如何應(yīng)用到半導(dǎo)體開發(fā)[1]。對通用AI SoC而言，最終整車架構(gòu)、外部傳感器、執(zhí)行器和降級策略可能尚未確定，因此通常需要以SEooC方式明確假設(shè)安全需求、使用模式、診斷測試間隔、外部安全機(jī)制和集成責(zé)任。

2.3.常見證據(jù)類型及其邊界

表2 常見證據(jù)類型

3.哪些對象相對容易形成ASIL D證據(jù)閉環(huán)

       “相對容易"僅表示安全邊界和證據(jù)規(guī)模相對容易控制，并不表示標(biāo)準(zhǔn)要求降低。通常具有以下特征：功能數(shù)量有限、狀態(tài)空間可控、安全狀態(tài)明確、診斷機(jī)制獨(dú)立、故障模式易于識別、測試結(jié)果具有確定性。

3.1.功能安全管理流程

       流程評價(jià)重點(diǎn)檢查組織職責(zé)、安全計(jì)劃、配置與變更管理、供應(yīng)商管理、確認(rèn)措施和獨(dú)立性。它證明企業(yè)“具備按照ASIL D要求開展項(xiàng)目的能力"，但不能證明企業(yè)的每一款產(chǎn)品均達(dá)到ASIL D。

3.2.功能單一且安全狀態(tài)明確的器件

       •外部看門狗、窗口看門狗和獨(dú)立時(shí)鐘監(jiān)控器；

       •電壓監(jiān)控、復(fù)位監(jiān)控和安全狀態(tài)控制器；

       •功能相對單一的電源管理或執(zhí)行器驅(qū)動(dòng)器；

       •邊界明確的安全通信監(jiān)控或故障收集模塊。

       這類產(chǎn)品仍需證明安全機(jī)制自身失效如何被檢測、獨(dú)立性是否充分、反應(yīng)時(shí)間是否滿足FTTI，以及故障輸出是否能夠進(jìn)入規(guī)定安全狀態(tài)。

3.3.復(fù)雜SoC中的獨(dú)立安全島

       安全島通常具有獨(dú)立CPU、受保護(hù)存儲、故障管理、看門狗和啟動(dòng)/周期自檢。由于其邊界清晰、狀態(tài)較少，證據(jù)規(guī)模通常低于主AI計(jì)算域。但“安全島按照ASIL D要求開發(fā)"、“安全島取得相應(yīng)范圍的認(rèn)證或評估"以及“整顆SoC取得ASIL D產(chǎn)品認(rèn)證"是三種不同結(jié)論。

3.4.使用假設(shè)充分的SEooC產(chǎn)品

       SEooC可以通過假設(shè)安全需求和外部安全機(jī)制合理分配供應(yīng)方與集成方責(zé)任。其可信度取決于Safety Manual是否明確、使用約束是否可驗(yàn)證、集成方是否執(zhí)行，以及假設(shè)是否在最終系統(tǒng)中得到確認(rèn)。

4.為什么復(fù)雜AI SoC的ASIL D論證更困難

4.1.安全相關(guān)路徑跨越多個(gè)硬件與軟件層級

       ISO 26262-5要求硬件開發(fā)覆蓋硬件安全需求、硬件設(shè)計(jì)、硬件架構(gòu)度量、隨機(jī)硬件失效導(dǎo)致安全目標(biāo)違背的評價(jià)以及硬件集成和驗(yàn)證[1]。對AI SoC而言，芯片內(nèi)部安全路徑可能依賴傳感器數(shù)據(jù)輸入接口、ISP、DMA、NoC、Cache、DDR、NPU、CPU、驅(qū)動(dòng)、運(yùn)行時(shí)以及安全相關(guān)輸出接口；在系統(tǒng)級論證中，還應(yīng)進(jìn)一步覆蓋外部傳感器、通信鏈路、執(zhí)行器和整車安全反應(yīng)。

圖2 AI SoC內(nèi)部安全相關(guān)計(jì)算路徑及系統(tǒng)邊界示意

4.2.安全邊界可能隨任務(wù)調(diào)度和資源分配動(dòng)態(tài)變化

       同一NPU、DDR或NoC可能在不同時(shí)間執(zhí)行安全任務(wù)和QM任務(wù)。安全論證不僅要證明空間隔離，還要證明時(shí)間、資源、數(shù)據(jù)和控制流隔離，防止非安全任務(wù)占用帶寬、破壞數(shù)據(jù)、阻塞安全任務(wù)或造成超時(shí)。

4.3.相關(guān)失效與共同原因失效更加突出

       共同電源、時(shí)鐘、復(fù)位、DDR、NoC、相同RTL/IP、編譯器或算子庫缺陷，可能導(dǎo)致兩條路徑發(fā)生依賴失效或共同系統(tǒng)性錯(cuò)誤，應(yīng)按照ISO 26262開展分析[1]。

       兩條路徑采用相同AI模型和訓(xùn)練數(shù)據(jù)時(shí)，還可能因模型能力邊界、數(shù)據(jù)覆蓋不足或相同輸出不足而同時(shí)產(chǎn)生錯(cuò)誤結(jié)果。這類風(fēng)險(xiǎn)不能簡單等同于隨機(jī)硬件依賴失效，還應(yīng)結(jié)合ISO 21448和ISO/PAS 8800進(jìn)行論證。

4.4.鎖步機(jī)制難以直接等比例復(fù)制到大型NPU

       傳統(tǒng)鎖步CPU具有明確的架構(gòu)狀態(tài)和確定執(zhí)行序列，可以進(jìn)行周期級或指令級比較。大型NPU采用大規(guī)模并行陣列、算子融合、量化計(jì)算和多級緩存，比較粒度、數(shù)值容差、局部故障定位和比較器保護(hù)都更加困難。

4.5.存儲、互聯(lián)和數(shù)據(jù)搬運(yùn)可能比MAC陣列更關(guān)鍵

       兩個(gè)正常NPU如果讀取同一份被破壞的模型權(quán)重，可能一致輸出錯(cuò)誤結(jié)果。安全路徑必須考慮SRAM/Cache/DDR的ECC、地址保護(hù)、DMA權(quán)限、NoC路由保護(hù)、端到端CRC、序號、新鮮度、時(shí)間戳以及錯(cuò)誤恢復(fù)。

4.6.故障注入的真實(shí)性與規(guī)模難以同時(shí)滿足

       AI加速器的故障空間巨大，不能簡單窮舉全部晶體管故障。工程上需要進(jìn)行故障抽象、分組、代表性選擇和統(tǒng)計(jì)抽樣。研究表明，應(yīng)用層與指令集層的故障注入可能得出不同的加固效果排序，說明注入抽象層級會實(shí)質(zhì)影響可靠性結(jié)論[4]。另一項(xiàng)研究指出，在現(xiàn)代大規(guī)模DNN上獲得充分統(tǒng)計(jì)置信度的傳統(tǒng)故障注入可能非常耗時(shí)，因此需要可解釋的半解析或加速方法[5]。

4.7.系統(tǒng)性失效不能通過ECC和雙路冗余自動(dòng)解決

       •安全需求或場景假設(shè)錯(cuò)誤；

       •RTL、第三方IP和接口設(shè)計(jì)缺陷；

       •編譯器、代碼生成器或算子庫錯(cuò)誤；

       •模型部署錯(cuò)誤、配置錯(cuò)誤、版本錯(cuò)誤：可作為系統(tǒng)性錯(cuò)誤；

       •模型泛化不足、訓(xùn)練數(shù)據(jù)覆蓋不足：應(yīng)歸入AI功能不足或SOTIF問題；

       •兩條冗余路徑繼承同一軟件或模型缺陷。

       因此，硬件隨機(jī)失效證據(jù)和系統(tǒng)性失效防控證據(jù)必須分別建立，再由完整Safety Case進(jìn)行匯總。

4.8.高級自動(dòng)駕駛可能要求fail-operational

       傳統(tǒng)控制器發(fā)生故障后可以直接關(guān)斷進(jìn)入安全狀態(tài)，而高速自動(dòng)駕駛直接關(guān)閉AI SoC可能增加風(fēng)險(xiǎn)。系統(tǒng)可能需要在有限的時(shí)間內(nèi)維持車道、減速、請求接管或執(zhí)行最小風(fēng)險(xiǎn)機(jī)動(dòng)。這會把論證對象從單顆芯片擴(kuò)展到傳感器、計(jì)算平臺、通信、底盤執(zhí)行器和整車降級策略。

4.9.ISO 26262不能單獨(dú)覆蓋AI功能不足

       ISO 21448將由功能規(guī)格不足或?qū)崿F(xiàn)性能不足引起的不合理風(fēng)險(xiǎn)納入SOTIF論證[2] 。ISO/PAS 8800適用于采用AI技術(shù)的安全相關(guān)車輛E/E系統(tǒng)，關(guān)注AI元素的輸出不足、系統(tǒng)性錯(cuò)誤和隨機(jī)硬件錯(cuò)誤，并提供用于構(gòu)建AI安全保障論證的安全相關(guān)屬性和工程指導(dǎo)[3] 。因此，AI芯片硬件路徑達(dá)到ASIL D不等于AI模型不會誤識別，也不等于智能駕駛功能在所有場景下均安全。

5.成本充分時(shí)，復(fù)雜安全運(yùn)算路徑能否做到ASIL D

       在安全概念明確、安全需求合理分配、SEooC假設(shè)得到確認(rèn)，并具備相應(yīng)的成本、面積、功耗、開發(fā)周期和驗(yàn)證資源的前提下，工程上可以將承擔(dān)ASIL D安全需求的完整計(jì)算路徑按照相應(yīng)完整性要求進(jìn)行設(shè)計(jì)、分析和驗(yàn)證。需要強(qiáng)調(diào)的是，資源投入是實(shí)現(xiàn)高完整性架構(gòu)的必要條件之一，但不能替代安全生命周期、獨(dú)立性論證和驗(yàn)證證據(jù)。

5.1. 明確安全相關(guān)資源清單

       •安全輸入接口、ISP和預(yù)處理模塊；

       •DMA、NoC、Cache、SRAM、DDR控制器及安全存儲區(qū)域；

       •NPU/GPU/CPU等計(jì)算資源；

       •操作系統(tǒng)、Hypervisor、驅(qū)動(dòng)、運(yùn)行時(shí)、編譯器和算子庫；

       •輸出接口、通信保護(hù)、執(zhí)行授權(quán)和安全反應(yīng)通路。

5.2. 建立端到端數(shù)據(jù)和控制保護(hù)

       •數(shù)據(jù)完整性碼、ECC和端到端CRC；

       •序號、時(shí)間戳、新鮮度和源/目標(biāo)標(biāo)識；

       •地址、訪問權(quán)限、內(nèi)存分區(qū)和寫保護(hù)；

       •執(zhí)行時(shí)間、資源使用和控制流監(jiān)控；

       •輸出范圍、變化率、物理可實(shí)現(xiàn)性和交叉合理性檢查。

5.3.控制共享資源與免于干擾

       當(dāng)安全任務(wù)與QM任務(wù)共享NPU、DDR或NoC時(shí)，需要證明QM任務(wù)不能覆蓋安全數(shù)據(jù)、阻塞安全任務(wù)、破壞時(shí)間確定性或跨分區(qū)傳播故障。若無法提供充分證據(jù)，最直接但成本更高的方案是為安全路徑配置專用計(jì)算、存儲、互聯(lián)或帶寬資源。

5.4.采用多樣化與獨(dú)立監(jiān)督，而非簡單復(fù)制

       雙NPU相同實(shí)現(xiàn)有助于檢測部分隨機(jī)硬件故障，但對共同設(shè)計(jì)錯(cuò)誤幫助有限。更可信的方案通常是“高性能AI主路徑＋獨(dú)立簡化安全監(jiān)督路徑"，監(jiān)督路徑重點(diǎn)執(zhí)行輸入有效性、時(shí)間監(jiān)控、軌跡/控制量合理性和故障降級決策。

5.5.建立分層故障注入與驗(yàn)證體系

       •在模型/應(yīng)用層識別敏感權(quán)重、激活和關(guān)鍵算子；

       •在指令集、軟件運(yùn)行時(shí)和驅(qū)動(dòng)層驗(yàn)證控制流、任務(wù)調(diào)度和異常處理；

       •在RTL/門級對安全機(jī)制和硬件故障傳播進(jìn)行代表性注入；

       •在樣片階段開展寄存器、存儲、時(shí)鐘、電源、通信和外部故障注入；

       •將每項(xiàng)診斷覆蓋率聲明追溯至實(shí)際測試或經(jīng)論證的等效證據(jù)。

5.6.構(gòu)建可審查的Safety Case

       成本可以購買更多冗余資源和測試算力，但不能替代安全生命周期。最終仍需用安全需求、設(shè)計(jì)、FMEA/FMEDA、DFA、故障注入、驗(yàn)證結(jié)果、Safety Manual和變更記錄構(gòu)成可審查的安全論證。

6.AI SoC ASIL D能力分層模型

圖3  AI SoC ASIL D能力分層模型（示例）

注：本圖未展開ASIL分解。采用分解架構(gòu)時(shí)，需另行證明分解后的需求分配、獨(dú)立性和依賴失效控制。

6.1.QM計(jì)算域

       QM計(jì)算域主要承載未分配安全需求的地圖可視化、調(diào)試功能、非安全相關(guān)AI任務(wù)及通用平臺服務(wù)。具體功能是否屬于QM，應(yīng)依據(jù)其所承擔(dān)的安全需求及失效影響確定，不能僅根據(jù)功能名稱分類。QM功能與ASIL D安全相關(guān)功能在同一SoC中共存，并不當(dāng)然構(gòu)成功能安全問題。關(guān)鍵在于通過架構(gòu)設(shè)計(jì)、資源分區(qū)和驗(yàn)證證據(jù)證明，QM計(jì)算域不會因共享資源競爭、訪問越界、錯(cuò)誤配置、異常任務(wù)調(diào)度或故障傳播，對ASIL D安全相關(guān)路徑造成不可接受的干擾。

       當(dāng)QM任務(wù)與安全相關(guān)任務(wù)共享CPU、NPU、GPU、NoC、DDR、Cache、DMA、中斷控制器或操作系統(tǒng)調(diào)度資源時(shí)，應(yīng)針對空間隔離、時(shí)間隔離、數(shù)據(jù)完整性、訪問控制和資源可用性開展分析與驗(yàn)證，證明QM域引發(fā)的干擾能夠被預(yù)防、隔離或檢測，并保證故障檢測、報(bào)告及芯片側(cè)安全反應(yīng)的總時(shí)間滿足系統(tǒng)分配給SoC或相關(guān)安全機(jī)制的時(shí)間預(yù)算。

6.2.ASIL D安全相關(guān)路徑

       ASIL D安全相關(guān)路徑應(yīng)覆蓋從安全相關(guān)輸入到安全相關(guān)輸出的完整功能鏈路，包括安全輸入、專用或受控互聯(lián)、安全存儲、安全計(jì)算、輸出檢查以及安全輸出等環(huán)節(jié)。

       路徑內(nèi)資源可以采用專用資源，也可以與QM功能或其他安全功能共享。但采用共享資源時(shí)，必須提供充分的免于干擾證據(jù)，并對共享電源、時(shí)鐘、存儲器、片上互聯(lián)、軟件棧、配置機(jī)制和第三方IP可能引發(fā)的相關(guān)失效進(jìn)行分析。

       ASIL D安全相關(guān)路徑的符合性不能僅依據(jù)NPU、CPU或某個(gè)局部計(jì)算模塊的能力作出判斷，而應(yīng)結(jié)合安全需求分配、硬件和軟件架構(gòu)、隨機(jī)硬件失效分析、系統(tǒng)性失效控制、故障注入驗(yàn)證、端到端數(shù)據(jù)保護(hù)及安全反應(yīng)機(jī)制，形成覆蓋完整路徑的功能安全證據(jù)鏈。

6.3.ASIL D安全監(jiān)督域/安全島

       安全監(jiān)督域或安全島用于對安全相關(guān)計(jì)算路徑實(shí)施故障檢測、故障收集、運(yùn)行狀態(tài)監(jiān)控和安全反應(yīng)管理，其典型功能可包括鎖步處理器、啟動(dòng)自檢、周期性自檢、看門狗、時(shí)鐘與電源監(jiān)控、存儲器保護(hù)、故障管理及安全狀態(tài)控制。

       當(dāng)關(guān)鍵監(jiān)控、故障控制或安全狀態(tài)管理需求分配至該監(jiān)督域時(shí)，相關(guān)硬件、軟件和支持資源應(yīng)按照所分配的ASIL開展開發(fā)、分析和驗(yàn)證。若采用ASIL分解，將安全要求分配至多個(gè)獨(dú)立要素，則應(yīng)提供需求分解、要素共存、充分獨(dú)立性及依賴失效分析證據(jù)。

       “安全島按ASIL D要求開發(fā)"“安全島取得相應(yīng)范圍的第三方認(rèn)證或評估"與“整顆SoC取得ASIL D產(chǎn)品認(rèn)證"屬于不同結(jié)論，不能相互替代。

7.傳統(tǒng)MCU與AI SoC功能安全難度對比

表3 傳統(tǒng)MCU與復(fù)雜AI SoC功能安全難度對比

8.廣電計(jì)量芯片功能安全智能測試平臺

8.1.平臺建設(shè)背景

       面對汽車芯片功能安全開發(fā)與測試中標(biāo)準(zhǔn)要求復(fù)雜、工程資料分散、需求與驗(yàn)證證據(jù)追溯不完整、硅前與硅后驗(yàn)證銜接不足以及專業(yè)人員資源有限等行業(yè)共性問題，單純增加人工雖然能夠擴(kuò)充項(xiàng)目處理能力，但通常伴隨成本上升、效率受限和跨項(xiàng)目判定尺度不一致等問題；依賴通用大模型，則可能產(chǎn)生表述完整但證據(jù)來源不清、判斷依據(jù)不足、結(jié)論不可復(fù)核的輸出。

       為解決上述問題，廣電計(jì)量推出汽車芯片功能安全智能測試平臺，采用“AI輔助分析、規(guī)則引擎校核、專家治理把關(guān)"的組合架構(gòu)。平臺通過對標(biāo)準(zhǔn)要求、機(jī)構(gòu)檢查規(guī)則、專家經(jīng)驗(yàn)和測試規(guī)范進(jìn)行結(jié)構(gòu)化管理，輔助完成安全需求解析、故障模式與安全機(jī)制關(guān)聯(lián)、測試方案生成、證據(jù)追溯和跨文檔一致性審查，旨在提升功能安全測試活動(dòng)的效率、可重復(fù)性和證據(jù)完整性，幫助企業(yè)建立可執(zhí)行、可驗(yàn)證、可追溯的測試閉環(huán)。

8.2.AI負(fù)責(zé)理解和輔助生成

       •解析規(guī)格書、安全需求、架構(gòu)、FMEA/FMEDA/FTA和Safety Manual；

       •提取模塊、接口、故障模式、安全機(jī)制、FTTI和外部假設(shè)；

       •識別跨文檔缺失、沖突、版本不一致和追溯斷點(diǎn)；

       •輔助生成測試場景、測試用例、腳本骨架和證據(jù)索引。

8.3.規(guī)則引擎負(fù)責(zé)約束和校核

       •標(biāo)準(zhǔn)條款、機(jī)構(gòu)檢查表和歷史項(xiàng)目問題規(guī)則化；

       •安全需求格式、故障分類和診斷覆蓋證據(jù)校核；

       •硅前/硅后測試判定準(zhǔn)則和追溯完整性檢查；

       •對不滿足前置條件的ASIL結(jié)論執(zhí)行預(yù)警或升級專家復(fù)核。

8.4.專家負(fù)責(zé)最終判斷和質(zhì)量門禁

       平臺不會把AI輸出直接作為第三方結(jié)論。安全需求合理性、故障分類、相關(guān)失效、診斷覆蓋、外部安全機(jī)制、測試充分性和變更影響仍由功能安全專家確認(rèn)。系統(tǒng)保留復(fù)核、修改、版本和審批軌跡。

9.平臺驅(qū)動(dòng)的證據(jù)閉環(huán)與輸出邊界

圖5  平臺驅(qū)動(dòng)的功能安全證據(jù)閉環(huán)

表4   功能安全測試平臺應(yīng)用場景

9.2.平臺可輸出的技術(shù)成果

       •功能安全文檔完整性和一致性檢查報(bào)告；

       •安全相關(guān)運(yùn)算路徑與共享資源分析結(jié)果；

       •FMEA/FMEDA與測試證據(jù)交叉檢查結(jié)果；

       •硅前故障注入方案、硅后功能安全測試方案和用例集；

       •需求追溯矩陣、安全機(jī)制覆蓋矩陣和問題清單；

       •測試執(zhí)行記錄、變更影響清單和第三方技術(shù)報(bào)告。

9.3.平臺明確不輸出的結(jié)論

       平臺真正的價(jià)值，不是讓報(bào)告“更像ASIL D"，而是更早發(fā)現(xiàn)哪些結(jié)論缺少足夠證據(jù)，并把分散的證據(jù)轉(zhuǎn)化為可追溯、可復(fù)核的安全論證。

       •不承諾“自動(dòng)通過ASIL D"；

       •不以AI輸出替代專家簽署和認(rèn)證機(jī)構(gòu)結(jié)論；

       •不承諾在幾周內(nèi)完成復(fù)雜SoC完整安全生命周期；

       •不將局部評估或測試結(jié)果擴(kuò)大為整顆SoC認(rèn)證；

       •不生成脫離產(chǎn)品版本、配置和使用假設(shè)的通用ASIL結(jié)論。

10.第三方技術(shù)評估建議

10.1.建議采用“五層證據(jù)模型"

表5   功能安全測試平臺五層證據(jù)模型

10.2.對復(fù)雜AI SoC建議增加的專項(xiàng)審查

       •明確安全相關(guān)計(jì)算路徑及所有依賴資源；

       •針對共享DDR、NoC、電源和時(shí)鐘開展相關(guān)失效分析；

       •檢查安全任務(wù)與QM任務(wù)的時(shí)間、空間和資源隔離；

       •區(qū)分隨機(jī)硬件故障、系統(tǒng)性失效和AI功能不足；

       •審查NPU比較粒度、數(shù)值容差和異常傳播機(jī)制；

       •對故障注入層級、代表性、抽樣置信度和覆蓋率聲明進(jìn)行獨(dú)立復(fù)核；

       •確認(rèn)故障后是fail-safe還是fail-operational，并驗(yàn)證最小風(fēng)險(xiǎn)策略；

       •核查產(chǎn)品版本、模型版本、算子庫和編譯器變更的影響分析。

11.結(jié)論

       AI芯片不是不能達(dá)到ASIL D。如果成本、功耗、面積、開發(fā)周期和驗(yàn)證資源均可接受，可以將承擔(dān)ASIL D安全需求的復(fù)雜運(yùn)算路徑按照ASIL D要求設(shè)計(jì)、分析和驗(yàn)證。

       困難不在于給NPU增加一個(gè)“安全標(biāo)簽"，而在于保護(hù)從安全輸入到安全輸出的完整鏈路，并證明共享資源不會干擾、冗余路徑足夠獨(dú)立、相關(guān)失效得到控制、診斷覆蓋有實(shí)際驗(yàn)證、系統(tǒng)性失效有生命周期措施。

       即使硬件計(jì)算路徑滿足ISO 26262，也不能把結(jié)論擴(kuò)大為AI在所有場景下不會誤識別。AI車輛系統(tǒng)還需要結(jié)合ISO 21448和ISO/PAS 8800建立預(yù)期功能安全和AI安全論證[2][3]。

對市場宣傳而言，流程能力、安全島、局部路徑和整顆SoC是不同對象；設(shè)計(jì)評估、技術(shù)報(bào)告和產(chǎn)品認(rèn)證也是不同證據(jù)。任何ASIL D結(jié)論都必須與對象、范圍、版本、假設(shè)和證據(jù)相匹配。

       廣電計(jì)量芯片功能安全智能測試平臺通過AI提高理解與生成效率，通過規(guī)則引擎守住標(biāo)準(zhǔn)和證據(jù)邊界，通過專家治理形成最終判斷，為復(fù)雜AI SoC建立可追溯、可復(fù)核、可持續(xù)維護(hù)的功能安全測試證據(jù)鏈。

參考文獻(xiàn)

[1] ISO 26262:2018, Road vehicles — Functional safety

[2] ISO 21448:2022, Road vehicles — Safety of the intended functionality

[3] ISO/PAS 8800:2024, Road vehicles — Safety and artificial intelligence

[4] Esposito G., Guerrero-Balaguera J.-D., Rodriguez Condia J. E., Sonza Reorda M. Evaluating Different Fault Injection Abstractions on the Assessment of DNN SW Hardening Strategies. 2024 IEEE 33rd Asian Test Symposium, pp. 1–6, DOI: 10.1109/ATS64447.2024.10915284.

[5] Ahmadilivani M. H., Raik J., Daneshtalab M., Jenihhin M. DeepVigor+: Scalable and Accurate Semi-Analytical Fault Resilience Analysis for Deep Neural Network, 2024