ASIL D 不止一纸报告：复杂 AI SoC 的 ASIL D 挑战、路径与证据体系

1.范围与基本术语

1.1.范围

       本文聚焦智能驾驶AI SoC、异构中央计算芯片和高性能域控制器计算平台的功能安全论证问题。讨论对象包括芯片内部的CPU、GPU、NPU、ISP、DDR控制器、NoC、安全岛、接口和软件支撑栈，以及它们在安全相关计算路径中的组合关系。

       本文不对任何具体企业或产品作出认证结论，也不将“复杂"或“简单"等同于“符合"或“不符合"。分析重点是说明：当宣传材料出现“ASIL D芯片"、“ASIL D AI计算平台"等表述时，技术人员应如何判断结论边界和证据充分性。

1.2.基本术语

表1  基本术语

2. ASIL D的对象、边界与证据类型

2.1.ASIL首先属于安全目标和安全需求

       ISO 26262-3将相关项定义、危害分析与风险评估以及功能安全概念纳入概念阶段。由此形成的ASIL被分配给安全目标，并逐级落实至系统、硬件和软件安全需求[1]。因此，“产品达到ASIL D"必须被理解为一个有边界的工程结论，而不是脱离应用场景的固定标签。

2.2.对半导体产品应特别说明SEooC假设

       ISO 26262-11提供半导体应用指南，用于解释ISO 26262其他部分如何应用到半导体开发[1]。对通用AI SoC而言，最终整车架构、外部传感器、执行器和降级策略可能尚未确定，因此通常需要以SEooC方式明确假设安全需求、使用模式、诊断测试间隔、外部安全机制和集成责任。

2.3.常见证据类型及其边界

表2 常见证据类型

3.哪些对象相对容易形成ASIL D证据闭环

       “相对容易"仅表示安全边界和证据规模相对容易控制，并不表示标准要求降低。通常具有以下特征：功能数量有限、状态空间可控、安全状态明确、诊断机制独立、故障模式易于识别、测试结果具有确定性。

3.1.功能安全管理流程

       流程评价重点检查组织职责、安全计划、配置与变更管理、供应商管理、确认措施和独立性。它证明企业“具备按照ASIL D要求开展项目的能力"，但不能证明企业的每一款产品均达到ASIL D。

3.2.功能单一且安全状态明确的器件

       •外部看门狗、窗口看门狗和独立时钟监控器；

       •电压监控、复位监控和安全状态控制器；

       •功能相对单一的电源管理或执行器驱动器；

       •边界明确的安全通信监控或故障收集模块。

       这类产品仍需证明安全机制自身失效如何被检测、独立性是否充分、反应时间是否满足FTTI，以及故障输出是否能够进入规定安全状态。

3.3.复杂SoC中的独立安全岛

       安全岛通常具有独立CPU、受保护存储、故障管理、看门狗和启动/周期自检。由于其边界清晰、状态较少，证据规模通常低于主AI计算域。但“安全岛按照ASIL D要求开发"、“安全岛取得相应范围的认证或评估"以及“整颗SoC取得ASIL D产品认证"是三种不同结论。

3.4.使用假设充分的SEooC产品

       SEooC可以通过假设安全需求和外部安全机制合理分配供应方与集成方责任。其可信度取决于Safety Manual是否明确、使用约束是否可验证、集成方是否执行，以及假设是否在最终系统中得到确认。

4.为什么复杂AI SoC的ASIL D论证更困难

4.1.安全相关路径跨越多个硬件与软件层级

       ISO 26262-5要求硬件开发覆盖硬件安全需求、硬件设计、硬件架构度量、随机硬件失效导致安全目标违背的评价以及硬件集成和验证[1]。对AI SoC而言，芯片内部安全路径可能依赖传感器数据输入接口、ISP、DMA、NoC、Cache、DDR、NPU、CPU、驱动、运行时以及安全相关输出接口；在系统级论证中，还应进一步覆盖外部传感器、通信链路、执行器和整车安全反应。

图2 AI SoC内部安全相关计算路径及系统边界示意

4.2.安全边界可能随任务调度和资源分配动态变化

       同一NPU、DDR或NoC可能在不同时间执行安全任务和QM任务。安全论证不仅要证明空间隔离，还要证明时间、资源、数据和控制流隔离，防止非安全任务占用带宽、破坏数据、阻塞安全任务或造成超时。

4.3.相关失效与共同原因失效更加突出

       共同电源、时钟、复位、DDR、NoC、相同RTL/IP、编译器或算子库缺陷，可能导致两条路径发生依赖失效或共同系统性错误，应按照ISO 26262开展分析[1]。

       两条路径采用相同AI模型和训练数据时，还可能因模型能力边界、数据覆盖不足或相同输出不足而同时产生错误结果。这类风险不能简单等同于随机硬件依赖失效，还应结合ISO 21448和ISO/PAS 8800进行论证。

4.4.锁步机制难以直接等比例复制到大型NPU

       传统锁步CPU具有明确的架构状态和确定执行序列，可以进行周期级或指令级比较。大型NPU采用大规模并行阵列、算子融合、量化计算和多级缓存，比较粒度、数值容差、局部故障定位和比较器保护都更加困难。

4.5.存储、互联和数据搬运可能比MAC阵列更关键

       两个正常NPU如果读取同一份被破坏的模型权重，可能一致输出错误结果。安全路径必须考虑SRAM/Cache/DDR的ECC、地址保护、DMA权限、NoC路由保护、端到端CRC、序号、新鲜度、时间戳以及错误恢复。

4.6.故障注入的真实性与规模难以同时满足

       AI加速器的故障空间巨大，不能简单穷举全部晶体管故障。工程上需要进行故障抽象、分组、代表性选择和统计抽样。研究表明，应用层与指令集层的故障注入可能得出不同的加固效果排序，说明注入抽象层级会实质影响可靠性结论[4]。另一项研究指出，在现代大规模DNN上获得充分统计置信度的传统故障注入可能非常耗时，因此需要可解释的半解析或加速方法[5]。

4.7.系统性失效不能通过ECC和双路冗余自动解决

       •安全需求或场景假设错误；

       •RTL、第三方IP和接口设计缺陷；

       •编译器、代码生成器或算子库错误；

       •模型部署错误、配置错误、版本错误：可作为系统性错误；

       •模型泛化不足、训练数据覆盖不足：应归入AI功能不足或SOTIF问题；

       •两条冗余路径继承同一软件或模型缺陷。

       因此，硬件随机失效证据和系统性失效防控证据必须分别建立，再由完整Safety Case进行汇总。

4.8.高级自动驾驶可能要求fail-operational

       传统控制器发生故障后可以直接关断进入安全状态，而高速自动驾驶直接关闭AI SoC可能增加风险。系统可能需要在有限的时间内维持车道、减速、请求接管或执行最小风险机动。这会把论证对象从单颗芯片扩展到传感器、计算平台、通信、底盘执行器和整车降级策略。

4.9.ISO 26262不能单独覆盖AI功能不足

       ISO 21448将由功能规格不足或实现性能不足引起的不合理风险纳入SOTIF论证[2] 。ISO/PAS 8800适用于采用AI技术的安全相关车辆E/E系统，关注AI元素的输出不足、系统性错误和随机硬件错误，并提供用于构建AI安全保障论证的安全相关属性和工程指导[3] 。因此，AI芯片硬件路径达到ASIL D不等于AI模型不会误识别，也不等于智能驾驶功能在所有场景下均安全。

5.成本充分时，复杂安全运算路径能否做到ASIL D

       在安全概念明确、安全需求合理分配、SEooC假设得到确认，并具备相应的成本、面积、功耗、开发周期和验证资源的前提下，工程上可以将承担ASIL D安全需求的完整计算路径按照相应完整性要求进行设计、分析和验证。需要强调的是，资源投入是实现高完整性架构的必要条件之一，但不能替代安全生命周期、独立性论证和验证证据。

5.1. 明确安全相关资源清单

       •安全输入接口、ISP和预处理模块；

       •DMA、NoC、Cache、SRAM、DDR控制器及安全存储区域；

       •NPU/GPU/CPU等计算资源；

       •操作系统、Hypervisor、驱动、运行时、编译器和算子库；

       •输出接口、通信保护、执行授权和安全反应通路。

5.2. 建立端到端数据和控制保护

       •数据完整性码、ECC和端到端CRC；

       •序号、时间戳、新鲜度和源/目标标识；

       •地址、访问权限、内存分区和写保护；

       •执行时间、资源使用和控制流监控；

       •输出范围、变化率、物理可实现性和交叉合理性检查。

5.3.控制共享资源与免于干扰

       当安全任务与QM任务共享NPU、DDR或NoC时，需要证明QM任务不能覆盖安全数据、阻塞安全任务、破坏时间确定性或跨分区传播故障。若无法提供充分证据，最直接但成本更高的方案是为安全路径配置专用计算、存储、互联或带宽资源。

5.4.采用多样化与独立监督，而非简单复制

       双NPU相同实现有助于检测部分随机硬件故障，但对共同设计错误帮助有限。更可信的方案通常是“高性能AI主路径＋独立简化安全监督路径"，监督路径重点执行输入有效性、时间监控、轨迹/控制量合理性和故障降级决策。

5.5.建立分层故障注入与验证体系

       •在模型/应用层识别敏感权重、激活和关键算子；

       •在指令集、软件运行时和驱动层验证控制流、任务调度和异常处理；

       •在RTL/门级对安全机制和硬件故障传播进行代表性注入；

       •在样片阶段开展寄存器、存储、时钟、电源、通信和外部故障注入；

       •将每项诊断覆盖率声明追溯至实际测试或经论证的等效证据。

5.6.构建可审查的Safety Case

       成本可以购买更多冗余资源和测试算力，但不能替代安全生命周期。最终仍需用安全需求、设计、FMEA/FMEDA、DFA、故障注入、验证结果、Safety Manual和变更记录构成可审查的安全论证。

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

图3  AI SoC ASIL D能力分层模型（示例）

注：本图未展开ASIL分解。采用分解架构时，需另行证明分解后的需求分配、独立性和依赖失效控制。

6.1.QM计算域

       QM计算域主要承载未分配安全需求的地图可视化、调试功能、非安全相关AI任务及通用平台服务。具体功能是否属于QM，应依据其所承担的安全需求及失效影响确定，不能仅根据功能名称分类。QM功能与ASIL D安全相关功能在同一SoC中共存，并不当然构成功能安全问题。关键在于通过架构设计、资源分区和验证证据证明，QM计算域不会因共享资源竞争、访问越界、错误配置、异常任务调度或故障传播，对ASIL D安全相关路径造成不可接受的干扰。

       当QM任务与安全相关任务共享CPU、NPU、GPU、NoC、DDR、Cache、DMA、中断控制器或操作系统调度资源时，应针对空间隔离、时间隔离、数据完整性、访问控制和资源可用性开展分析与验证，证明QM域引发的干扰能够被预防、隔离或检测，并保证故障检测、报告及芯片侧安全反应的总时间满足系统分配给SoC或相关安全机制的时间预算。

6.2.ASIL D安全相关路径

       ASIL D安全相关路径应覆盖从安全相关输入到安全相关输出的完整功能链路，包括安全输入、专用或受控互联、安全存储、安全计算、输出检查以及安全输出等环节。

       路径内资源可以采用专用资源，也可以与QM功能或其他安全功能共享。但采用共享资源时，必须提供充分的免于干扰证据，并对共享电源、时钟、存储器、片上互联、软件栈、配置机制和第三方IP可能引发的相关失效进行分析。

       ASIL D安全相关路径的符合性不能仅依据NPU、CPU或某个局部计算模块的能力作出判断，而应结合安全需求分配、硬件和软件架构、随机硬件失效分析、系统性失效控制、故障注入验证、端到端数据保护及安全反应机制，形成覆盖完整路径的功能安全证据链。

6.3.ASIL D安全监督域/安全岛

       安全监督域或安全岛用于对安全相关计算路径实施故障检测、故障收集、运行状态监控和安全反应管理，其典型功能可包括锁步处理器、启动自检、周期性自检、看门狗、时钟与电源监控、存储器保护、故障管理及安全状态控制。

       当关键监控、故障控制或安全状态管理需求分配至该监督域时，相关硬件、软件和支持资源应按照所分配的ASIL开展开发、分析和验证。若采用ASIL分解，将安全要求分配至多个独立要素，则应提供需求分解、要素共存、充分独立性及依赖失效分析证据。

       “安全岛按ASIL D要求开发"“安全岛取得相应范围的第三方认证或评估"与“整颗SoC取得ASIL D产品认证"属于不同结论，不能相互替代。

7.传统MCU与AI SoC功能安全难度对比

表3 传统MCU与复杂AI SoC功能安全难度对比

8.广电计量芯片功能安全智能测试平台

8.1.平台建设背景

       面对汽车芯片功能安全开发与测试中标准要求复杂、工程资料分散、需求与验证证据追溯不完整、硅前与硅后验证衔接不足以及专业人员资源有限等行业共性问题，单纯增加人工虽然能够扩充项目处理能力，但通常伴随成本上升、效率受限和跨项目判定尺度不一致等问题；依赖通用大模型，则可能产生表述完整但证据来源不清、判断依据不足、结论不可复核的输出。

       为解决上述问题，广电计量推出汽车芯片功能安全智能测试平台，采用“AI辅助分析、规则引擎校核、专家治理把关"的组合架构。平台通过对标准要求、机构检查规则、专家经验和测试规范进行结构化管理，辅助完成安全需求解析、故障模式与安全机制关联、测试方案生成、证据追溯和跨文档一致性审查，旨在提升功能安全测试活动的效率、可重复性和证据完整性，帮助企业建立可执行、可验证、可追溯的测试闭环。

8.2.AI负责理解和辅助生成

       •解析规格书、安全需求、架构、FMEA/FMEDA/FTA和Safety Manual；

       •提取模块、接口、故障模式、安全机制、FTTI和外部假设；

       •识别跨文档缺失、冲突、版本不一致和追溯断点；

       •辅助生成测试场景、测试用例、脚本骨架和证据索引。

8.3.规则引擎负责约束和校核

       •标准条款、机构检查表和历史项目问题规则化；

       •安全需求格式、故障分类和诊断覆盖证据校核；

       •硅前/硅后测试判定准则和追溯完整性检查；

       •对不满足前置条件的ASIL结论执行预警或升级专家复核。

8.4.专家负责最终判断和质量门禁

       平台不会把AI输出直接作为第三方结论。安全需求合理性、故障分类、相关失效、诊断覆盖、外部安全机制、测试充分性和变更影响仍由功能安全专家确认。系统保留复核、修改、版本和审批轨迹。

9.平台驱动的证据闭环与输出边界

图5  平台驱动的功能安全证据闭环

表4   功能安全测试平台应用场景

9.2.平台可输出的技术成果

       •功能安全文档完整性和一致性检查报告；

       •安全相关运算路径与共享资源分析结果；

       •FMEA/FMEDA与测试证据交叉检查结果；

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

       •需求追溯矩阵、安全机制覆盖矩阵和问题清单；

       •测试执行记录、变更影响清单和第三方技术报告。

9.3.平台明确不输出的结论

       平台真正的价值，不是让报告“更像ASIL D"，而是更早发现哪些结论缺少足够证据，并把分散的证据转化为可追溯、可复核的安全论证。

       •不承诺“自动通过ASIL D"；

       •不以AI输出替代专家签署和认证机构结论；

       •不承诺在几周内完成复杂SoC完整安全生命周期；

       •不将局部评估或测试结果扩大为整颗SoC认证；

       •不生成脱离产品版本、配置和使用假设的通用ASIL结论。

10.第三方技术评估建议

10.1.建议采用“五层证据模型"

表5   功能安全测试平台五层证据模型

10.2.对复杂AI SoC建议增加的专项审查

       •明确安全相关计算路径及所有依赖资源；

       •针对共享DDR、NoC、电源和时钟开展相关失效分析；

       •检查安全任务与QM任务的时间、空间和资源隔离；

       •区分随机硬件故障、系统性失效和AI功能不足；

       •审查NPU比较粒度、数值容差和异常传播机制；

       •对故障注入层级、代表性、抽样置信度和覆盖率声明进行独立复核；

       •确认故障后是fail-safe还是fail-operational，并验证最小风险策略；

       •核查产品版本、模型版本、算子库和编译器变更的影响分析。

11.结论

       AI芯片不是不能达到ASIL D。如果成本、功耗、面积、开发周期和验证资源均可接受，可以将承担ASIL D安全需求的复杂运算路径按照ASIL D要求设计、分析和验证。

       困难不在于给NPU增加一个“安全标签"，而在于保护从安全输入到安全输出的完整链路，并证明共享资源不会干扰、冗余路径足够独立、相关失效得到控制、诊断覆盖有实际验证、系统性失效有生命周期措施。

       即使硬件计算路径满足ISO 26262，也不能把结论扩大为AI在所有场景下不会误识别。AI车辆系统还需要结合ISO 21448和ISO/PAS 8800建立预期功能安全和AI安全论证[2][3]。

对市场宣传而言，流程能力、安全岛、局部路径和整颗SoC是不同对象；设计评估、技术报告和产品认证也是不同证据。任何ASIL D结论都必须与对象、范围、版本、假设和证据相匹配。

       广电计量芯片功能安全智能测试平台通过AI提高理解与生成效率，通过规则引擎守住标准和证据边界，通过专家治理形成最终判断，为复杂AI SoC建立可追溯、可复核、可持续维护的功能安全测试证据链。

参考文献

[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