4. 搭建首个故障注入工程

前几节我们已经理解了故障注入在车载网络验证中的定位，也认识了 CANoe 中与故障注入相关的基本对象。从这一节开始，我们要把认知落到工程上：从零搭建一个可以真正运行、并且具备故障注入能力的 CANoe 配置。这个工程将成为后续所有注入实验的“底座”，因此它的结构是否清晰、通道绑定是否正确、仿真节点与真实总线是否被合理混合，直接决定了后面能不能稳定复现故障场景。

本节的目标不是把 CANoe 所有功能都点一遍，而是围绕一个最小可用工程，把四件事做扎实：创建配置、添加网络节点、绑定硬件通道、建立仿真与真实总线的混合环境。下面按实际搭建顺序展开，并给出可直接参考的示例参数。

一、创建 CANoe 配置：先定网络与通道骨架

启动 CANoe 后选择 File → New → Configuration，会进入配置创建向导。向导里最关键的一步是选择总线类型与通道数量。对于本节示例，我们假设要验证一条 500 kbit/s 的高速 CAN 动力总成网络，因此选择 CAN，通道数设为 1，命名为 CAN1。如果后续要同时观察网关两侧，可以在这里直接增加通道，但首个工程建议保持单通道，降低变量。

创建完成后，CANoe 会自动生成一个 .cfg 配置文件，并在 Simulation Setup 视图中呈现一个空的网络画布。此时工程还没有任何节点，也没有绑定硬件，属于“空壳配置”。接下来所有工作都围绕这个空壳逐步填充。

二、添加网络节点：区分真实 ECU 与仿真节点

在 Simulation Setup 中右键画布，选择 Insert Network Node，可以添加节点。节点分为两类：一类是仿真节点，由 CANoe 内部用 CAPL 或 Panel 模拟；另一类是真实节点，对应物理 ECU，通过硬件通道接入。混合环境的核心，就是让这两类节点出现在同一张网络图上，并让它们共享同一条总线。

本节示例添加三个节点：

• EngineSim：仿真节点，模拟发动机 ECU，周期发送 EngineStatus 报文，ID 为 0x100，周期 100 ms，数据长度 8 字节。
• BrakeSim：仿真节点，模拟制动 ECU，发送 BrakeStatus，ID 为 0x101，周期 50 ms。
• GatewayReal：真实节点，代表通过硬件接入的网关 ECU，用于接收并转发上述报文。

添加节点后，需要为每个节点关联数据库。在节点属性中加载 .dbc 文件，这样报文和信号才能被正确解析。对于仿真节点，还要在节点下挂载 CAPL 程序或 Panel，用于产生报文；对于真实节点，则不需要 CAPL，它由物理 ECU 驱动。

三、绑定硬件通道：把逻辑网络接到物理接口

节点添加完成后，逻辑网络还停留在“纸面”上。要让仿真节点发出的报文真正出现在总线上，必须把网络绑定到硬件通道。操作路径是 Hardware → Network Hardware Configuration，在 CAN1 通道上选择实际使用的接口，例如 VN1640A 或 VN5610A，并设置波特率为 500 kbit/s，采样点保持默认 80%。

绑定完成后，Simulation Setup 中的网络会与硬件通道建立映射。此时如果连接真实 ECU 并上电，CANoe 的 Trace 窗口应该能看到真实报文；如果只运行仿真节点，也能看到仿真报文。两者同时存在，就构成了混合环境。

四、建立仿真与真实总线混合环境

混合环境的关键在于“同一总线、同一数据库、同一时间基准”。仿真节点和真实节点必须挂在同一个 CAN1 通道上，使用同一份 .dbc 解析报文，并且都由 CANoe 的同一个测量时钟驱动。这样在 Trace 窗口中，仿真报文和真实报文会按时间顺序交错显示，便于观察交互。

为了让混合环境可验证，建议在工程中加入一个简单的 CAPL 测试节点 Monitor，它不发送报文，只监听总线并统计 0x100 和 0x101 的周期偏差。示例逻辑如下：

variables {
  msTimer tEngine;
  msTimer tBrake;
}

on message 0x100 {
  setTimer(tEngine, 200);
}

on timer tEngine {
  write("EngineStatus 超时未收到，可能存在丢帧或节点离线");
}

on message 0x101 {
  setTimer(tBrake, 100);
}

on timer tBrake {
  write("BrakeStatus 超时未收到");
}

这段代码的作用是：只要在预期周期内没有收到对应报文，就输出告警。它本身不是故障注入，但它是混合环境的“健康检查”，能帮助我们在注入前确认基线是干净的。

五、工程结构总览

把上述四步串起来，整个工程的逻辑结构可以用下面这张图表示。图中左侧是仿真侧，右侧是真实侧，中间通过 CAN1 通道和硬件接口汇聚到同一条物理总线，Monitor 节点则横跨两侧进行监听。

六、启动测量与基线确认

点击 CANoe 工具栏的 Start 按钮开始测量。此时观察 Trace 窗口，应该能看到 0x100 和 0x101 以约 100 ms 和 50 ms 的周期稳定出现。如果真实 ECU 已上电，还会看到它发出的报文。用 Statistics 窗口查看总线负载，500 kbit/s 下若只有这几帧报文，负载通常低于 5%，属于干净基线。

基线确认的标准可以归纳为三条：报文周期偏差在 ±10% 以内、无错误帧、Monitor 节点不输出超时告警。满足这三条，说明混合环境已经稳定，可以进入下一步的故障注入配置。如果不满足，应先排查硬件连接、波特率和数据库匹配，而不是急着注入故障。

至此，首个故障注入工程的骨架已经搭好。它看起来简单，但包含了后续所有实验都依赖的四个基本要素：配置、节点、通道、混合环境。把这四步做对，后面的故障注入才有可靠的起点。