2. 通信故障注入工程目标与安全需求
在AURIX通信故障注入工程中，最容易出现的误区是“为了注入而注入”：能造出CRC错误、丢帧、延迟，却说不清这些故障对应哪条安全需求、由哪个ECU机制负责检测、检测结果又该满足什么指标。要让故障注入成为可辩护的工程活动，必须先把三层关系对齐：ISO 26262给出的安全需求与完整性等级、AUTOSAR定义的通信服务与保护机制、ECU内部实际实现的硬件/软件安全机制，最后才是故障注入用例。故障注入不是起点，而是验证这条映射链是否闭合的手段。
一、三层安全需求到故障注入的映射逻辑
ISO 26262从危害分析出发，为每个安全目标分配ASIL等级，再导出功能安全需求（FSR）和技术安全需求（TSR）。通信相关的TSR通常表述为“在通信链路发生数据损坏、丢失、重复、乱序、延迟时，系统应在规定时间内进入安全状态”。AUTOSAR则把这些需求落到具体机制上：E2E Protection负责端到端数据完整性，COM模块负责信号打包与超时监控，PDU Router负责路由与网关转发，CanIf/CanDrv负责控制器与驱动层收发，而AURIX的CAN节点、DMA、SMU、看门狗等硬件资源提供底层支撑。
故障注入的目标，就是针对这些机制制造“它们本应能处理的异常”，然后观察机制是否按预期响应。因此，一个合格的故障注入用例必须能回答四个问题：注入什么故障（对应哪类通信失效）、注入到哪一层（总线、控制器、驱动、COM、E2E）、哪个机制应该检测到、检测后的预期行为与时间指标是什么。缺少任何一项，用例都无法与安全需求建立可追溯关系。
二、AUTOSAR E2E Protection与故障注入的对应关系
E2E Protection是通信安全中最核心的机制，它通过在PDU中附加CRC、序列计数器（Counter）和DataID来对抗通信失效。不同E2E Profile覆盖的故障类型不同，故障注入用例必须按Profile能力设计。例如E2E Profile 1使用4位CRC和4位计数器，能检测数据损坏和部分丢失，但对重复帧的检测能力有限；Profile 5使用16位或32位CRC、32位计数器，并支持DataID，可检测损坏、丢失、重复、乱序和延迟。若安全需求要求覆盖“重复帧”和“乱序”，却选用Profile 1，则无论注入多少用例都无法通过验证——这是映射关系中最常见的错配。
在AURIX TC3xx上做E2E故障注入时，典型做法是在发送端与接收端之间插入一个“篡改点”。若使用CAN总线，可通过Vector VN系列或AURIX自身作为网关节点，在PDU层修改数据字节、CRC字段或Counter值。例如，针对Profile 5的16位CRC，注入用例可设计为：保持DataID和Counter不变，仅翻转数据区某一位，预期接收端E2E检查返回E2E_P05STATUS_ERROR，COM层将该信号标记为无效，应用层在超时窗口内进入降级。若接收端未报错，则说明CRC计算范围或DataID配置存在缺陷。
三、ECU安全机制与故障注入的层次对应
故障注入的“注入点”决定了它能验证哪一层机制。在总线物理层注入位错误，主要验证CAN控制器的错误计数与总线关闭恢复；在CanIf层丢弃报文，验证COM超时监控与E2E丢失检测；在COM层篡改信号值，验证应用层范围检查与E2E数据校验；在PDU Router层制造路由错误，验证网关的转发完整性与超时处理。若把总线层故障注入结果直接当作E2E机制验证结论，就会产生“机制未被真正激励”的假通过。
以AURIX的MultiCAN+节点为例，当总线持续出现位错误时，节点的Tx Error Counter递增，达到128进入Error Passive，达到256进入Bus Off。此时若ECU安全机制配置了Bus Off恢复策略，应在规定时间内尝试恢复或向SMU报告。故障注入用例应记录：注入起始时刻、错误计数器变化、Bus Off进入时刻、恢复时刻、SMU报警时刻。这些时间戳与安全需求中的FTTI（故障容忍时间间隔）对比，才能判断机制是否满足ASIL等级要求。
四、从安全需求到故障注入用例的映射表
下表给出一个可参考的映射示例，用于把TSR、AUTOSAR机制、AURIX实现和注入用例串起来。表中参数为教学示例，实际项目需按具体安全分析和配置填写。
| TSR 示例 | ASIL | AUTOSAR 机制 | AURIX 实现 | 故障注入用例 | 预期响应与判据 |
|---|---|---|---|---|---|
| 通信数据损坏须在 20 ms 内被检测 | D | E2E Profile 5，16 位 CRC | MultiCAN+ 接收中断 + E2E 库 | 翻转数据区 1 bit，保持 Counter/DataID 不变 | E2E 返回 ERROR，信号无效，应用层 20 ms 内降级 |
| 报文丢失须被检测并触发替代值 | D | COM 超时监控 + E2E 丢失检测 | DMA 接收超时中断 | 在 CanIf 层丢弃连续 3 帧 | COM 超时标志置位，应用层使用替代值并记录 Dem 事件 |
| 重复帧不得导致错误控制 | C | E2E Profile 5 Counter 检查 | 软件 Counter 比较 | 重放上一帧，Counter 不递增 | E2E 返回 REPEATED，帧被丢弃，不更新信号 |
| 总线 Bus Off 后须进入安全状态 | D | CanIf 控制器模式管理 | MultiCAN+ 错误计数器 + SMU | 持续注入位错误直至 Bus Off | Bus Off 后 50 ms 内 SMU 报警，系统进入降级 |
五、工程落地要点
建立映射关系时，建议以TSR为行、以AUTOSAR机制和AURIX实现为列，形成可追溯矩阵。每个故障注入用例必须绑定至少一条TSR和一个被测机制，并明确注入点、注入量、观测点和判据。对于ASIL D的通信安全需求，注入用例还应覆盖“机制自身失效”的场景，例如E2E校验函数被跳过、Counter比较被旁路，验证安全机制不会静默失效。
综上，ISO 26262提供“为什么做”和“做到什么程度”，AUTOSAR提供“用什么机制做”，AURIX ECU提供“机制实际在哪里实现”，故障注入则回答“机制是否真的有效”。四者通过可追溯映射表连接，才能让通信故障注入从零散测试升级为可辩护的安全验证活动。