3. 功能安全与信息安全标准在TI平台上的落地
在TI智能汽车计算平台上做验证与量产交付，功能安全与信息安全不是两张独立的检查表，而是同一套硬件与软件证据链的两个侧面。ISO 26262 关注的是“系统失效与随机硬件失效是否被控制在可接受范围内”，ISO 21434 关注的是“资产是否被未授权访问、篡改或泄露”，AEC-Q100 则回答“器件本身在车规环境下是否可靠”。三者最终都要落到TI安全手册、安全分析报告、FMEDA 与安全机制在验证活动中的映射关系上。
一、ASIL等级如何决定验证深度
ISO 26262 按危害事件的严重度（S）、暴露率（E）和可控性（C）确定 ASIL A 至 D。以TI TDA4VM 这类ADAS域控制器为例，若某功能是“前向碰撞预警的制动请求输出”，严重度可能为 S3，暴露率为 E4，可控性为 C3，查表可得 ASIL D。ASIL 等级直接决定：硬件随机失效度量目标（SPFM、LFM）、诊断覆盖率要求、安全机制数量与验证独立性。
在TI平台上，ASIL D 通常要求 SPFM ≥ 99%、LFM ≥ 90%（针对 ASIL D 的典型目标值，具体以项目安全目标为准）。验证时不能只测“功能是否正常”，而要证明“安全机制在故障注入下是否按预期响应”。例如对锁步核（Lockstep）的验证，需要注入比较器失配、时钟漂移、ECC 单比特/双比特错误，观察错误信号是否在规定 FTTI（故障容忍时间间隔）内触发。
二、AEC-Q100与TI安全手册的衔接
AEC-Q100 是器件级车规认证，规定了温度等级（Grade 0~3）、HTOL、ELFR、EMC 等试验。它证明“器件在车规环境下能工作”，但不等于“器件失效时系统安全”。TI 安全手册（Safety Manual）则给出器件内部安全机制清单、假设条件（Assumptions of Use, AoU）和失效模式分布。验证工程师必须把 AEC-Q100 的试验结论与安全手册中的 FMEDA 数据对齐：AEC-Q100 提供失效率基础（如 FIT 值），FMEDA 把这些失效率按模块、按失效模式分配到具体安全机制上。
关键衔接点：AEC-Q100 的 Grade 等级决定环境温度范围，而 TI 安全手册中的 FIT 值通常基于特定温度与置信度。若整车环境温度超出假设，必须重新评估失效率，不能直接套用手册数值。
三、FMEDA与安全机制的映射关系
FMEDA（失效模式、影响与诊断分析）是连接“硬件失效”与“安全机制”的桥梁。在TI平台上，FMEDA 通常以模块为单位展开，每个模块列出：失效模式、失效率（FIT）、安全机制、诊断覆盖率（DC）、残余失效率。验证活动的核心任务，就是逐条确认 FMEDA 中声明的诊断覆盖率是否真实可达。
下面这张图展示了从 ASIL 目标到 FMEDA 再到验证活动的映射链路，以及 ISO 21434 信息安全资产如何叠加在同一硬件上。
四、安全机制在验证中的具体映射
以 TDA4VM 的 MCU 域为例，常见安全机制与验证方法的映射如下：
| 安全机制 | 覆盖失效模式 | 验证方法 | 观察点 |
|---|---|---|---|
| 双核锁步（Lockstep） | CPU 瞬态/永久故障 | 比较器失配注入、时钟偏移注入 | ESM 错误标志、复位响应时间 |
| ECC（SRAM/Flash） | 存储单元单/双比特翻转 | 通过调试接口注入位翻转 | ECC 纠错计数、不可纠正错误中断 |
| CRC 校验 | 通信数据损坏 | 篡改 CAN/Ethernet 帧载荷 | CRC 错误计数、报文丢弃 |
| 看门狗（WDT） | 程序跑飞、死锁 | 停止喂狗、注入死循环 | 复位时间、复位原因寄存器 |
| HSM 安全启动 | 固件篡改、未授权镜像 | 签名错误镜像加载、回滚攻击 | 启动拒绝、安全日志 |
验证时，每个安全机制都要回答三个问题：故障是否被检测到？检测时间是否小于 FTTI？检测后系统是否进入安全状态？例如锁步比较器失配后，ESM 应在微秒级触发，MCU 进入安全状态并通知 SoC。若实测响应时间超过 FTTI，则 FMEDA 中声明的 DC 不成立，必须调整安全机制或重新评估 ASIL 分解。
五、ISO 21434 在TI平台上的叠加验证
ISO 21434 要求对资产进行威胁分析与风险评估（TARA）。在TI平台上，典型资产包括：安全启动公钥、SecOC 密钥、诊断服务权限、OTA 更新包。验证活动包括：密钥是否存储在 HSM 受保护区域、SecOC 新鲜度值是否可重放、诊断服务是否需解锁等级、OTA 包签名是否强制校验。
信息安全验证与功能安全验证共享同一套硬件资源，但关注点不同。功能安全关心“失效是否被检测”，信息安全关心“攻击是否被阻止”。例如 HSM 安全启动，功能安全视角看“启动失败是否进入安全状态”，信息安全视角看“未签名镜像是否被拒绝”。两者都需要在验证报告中留下可追溯的证据。
实操建议：建立一张“安全机制-验证用例-证据”追溯矩阵。每一行对应 FMEDA 中的一条失效模式或 TARA 中的一个威胁场景，列出验证用例编号、注入方法、预期响应、实测结果、证据文件路径。这张矩阵是安全分析报告的核心输入，也是量产交付审核时最常被检查的文档。
六、安全分析报告的验证闭环
安全分析报告不是一次性文档，而是随验证活动迭代更新的活文档。在TI平台验证中，建议按以下顺序闭环：
- 从 TI 安全手册提取安全机制清单与 AoU，确认项目使用条件是否满足。
- 基于 AEC-Q100 FIT 数据与 FMEDA 计算 SPFM/LFM，判断是否满足 ASIL 目标。
- 针对每条安全机制设计故障注入用例，实测诊断覆盖率。
- 将实测 DC 回填 FMEDA，若低于声明值，触发安全机制改进或 ASIL 重新分解。
- 将 ISO 21434 的 TARA 结果与功能安全验证结果合并，形成统一安全案例（Safety Case）。
最终交付的安全分析报告应包含：安全目标、FMEDA 摘要、安全机制验证结果、信息安全验证结果、残余风险说明、以及未关闭项的跟踪计划。只有这张报告与验证证据一致，TI 平台的功能安全与信息安全落地才算真正闭环。