1. 课程导入与工程全景

在 NVIDIA DRIVE 这类高算力自动驾驶计算平台上，车载以太网已经不只是“把几个 ECU 连起来”的通信总线，而是承载感知数据回传、域控间协同、诊断刷写、时间同步与安全通信的骨干网络。一旦链路、交换机、PHY、TSN 调度或上层协议栈出现异常，表现往往不是简单的“断网”，而是丢帧、时延抖动、时间同步漂移、报文乱序、VLAN 隔离失效，甚至触发功能降级。故障注入工程的价值，正是在可控、可复现、可度量的条件下，把这些异常“提前制造出来”，验证系统是否按设计进入安全状态、是否可诊断、是否可恢复。

本课程面向的读者是车载网络测试工程师、域控软件验证工程师、功能安全与网络安全工程师，以及需要搭建 HIL/台架测试环境的系统集成人员。课程不把故障注入当作“打流工具的使用说明”，而是把它放进一条从需求到验证的端到端工作流中：先明确被测对象与安全目标，再设计故障模型与注入点，然后搭建注入环境、执行用例、采集证据，最后形成可评审的验证结论。

目标：从“能注入”到“能判定”

故障注入的第一层目标是可控地制造异常。在 NVIDIA DRIVE 平台上，这意味着要能对指定以太网端口、指定 VLAN、指定优先级或指定五元组的流量施加影响，而不是笼统地“把网线拔了”。第二层目标是可观测：注入前后，链路状态、PHY 寄存器、交换机统计、PTP 偏移、Socket 错误码、应用层心跳与诊断事件都要有对应的采集手段。第三层目标是可判定：每个用例都必须有明确的通过/失败准则，例如“链路闪断 100 ms 内，ADAS 域控应在 200 ms 内上报 LINK_DOWN 诊断事件，且不产生非预期制动请求”。

因此，本课程反复强调一个工程原则：没有判定准则的注入等于制造噪声。注入工具再强，如果无法把异常与系统响应关联起来，就无法支撑安全合规评审。

范围：注什么、在哪注、不注什么

从网络层次看，本课程覆盖物理层、数据链路层、网络与传输层、以及与应用相关的协议层。物理层包括线缆开路/短路、连接器接触不良、PHY 供电跌落、链路闪断；数据链路层包括帧丢失、帧重复、帧损坏、MAC 地址欺骗、VLAN 标签篡改；网络与传输层包括 IP 分片异常、TTL 异常、UDP/TCP 校验和错误、端口不可达、TCP 窗口异常；协议层则关注 SOME/IP、DoIP、gPTP、TSN 门控调度等车载以太网典型协议的异常行为。

注入点通常分布在三处：链路中间（通过 TAP 或故障注入交换机串入）、端点主机（在 DRIVE 侧或对端 ECU 侧用软件注入）、交换机内部（利用可管理交换机的 ACL、镜像、风暴抑制与端口配置）。三者的可注入故障类型、时间精度和可观测性差异很大，选点时必须结合被测对象和判定准则。

范围之外的内容同样需要明确：本课程不涉及无线电干扰、不涉及对量产车辆的实际道路攻击、不涉及未经授权的第三方系统渗透。所有注入活动都应在台架、HIL 或授权测试环境中进行，并遵守项目既定的安全合规边界。

交付物：让验证结果可被评审

故障注入工程的交付物不是“跑过一遍”的口头结论，而是一组可追溯的证据。典型交付物包括：故障注入测试计划（说明被测对象、范围、注入点、判定准则）、故障模型库（每个故障的参数化定义）、注入脚本与交换机配置、用例执行记录、原始抓包与系统日志、判定结论与缺陷单，以及最终面向功能安全/网络安全评审的证据包。

这里有一个容易被忽视的细节：证据必须带时间基准。车载以太网中，gPTP 时间同步、TSN 门控、应用层超时都依赖时间。如果注入时刻、抓包时间戳、诊断事件时间戳不在同一时间基准上，就无法判断“是注入导致了降级，还是降级恰好发生在注入附近”。建议在台架中统一使用 gPTP 域或至少统一到同一台采集主机的时间源，并在用例记录中保存注入触发时刻的绝对时间。

安全合规边界：先划红线，再谈技术

故障注入本质上是在“制造故障”，因此必须明确边界。第一，环境边界：只在台架、HIL 或项目授权的测试环境中执行，禁止对量产车辆、公共道路车辆或未授权第三方系统注入。第二，强度边界：注入参数要限幅，例如链路闪断时长、电压跌落幅度、风暴注入速率，都不能超过硬件和线束的耐受范围，避免造成不可逆损伤。第三，操作边界：注入前备份交换机与端点配置，注入后恢复链路与配置；异常（如冒烟、过热、持续总线错误）立即中止并回滚。第四，记录边界：记录操作人、时间、注入参数、环境状态，确保任何一次注入都可追溯。

端到端工作流：从需求到验证的闭环

把上述内容串起来，就得到本课程贯穿始终的端到端工作流：从功能安全与网络安全需求出发，提取安全目标与降级策略；据此设计故障模型，明确每种故障的参数、注入点和持续时间；选择注入手段并搭建环境；执行用例并同步采集链路、协议、应用与诊断四类观测数据；按判定准则给出通过/失败结论；最后归档证据并驱动缺陷修复与回归。

这条工作流的关键在于双向可追溯：向前，每个用例都能追溯到一条安全需求或诊断要求；向后，每个失败结论都能落到具体的注入参数、观测数据和证据文件。只有这样，故障注入才从“测试活动”升级为“工程验证能力”。

一个可参考的用例记录字段示例

为了让读者在后续章节中能直接落地，这里给出一份用例记录的最小字段示例。字段不求多，但必须能支撑复现与判定：

需要说明的是，表中的参数（100 ms、3 次、200 ms）属于教学示例，实际项目中应根据需求文档、安全分析和硬件规格确定，不能直接照搬。

本章小结与后续衔接