1. 课程导入与测试对象界定
在整车电子电气架构从分布式 ECU 向域集中、中央计算演进的过程中，网关（Gateway）始终是连接不同总线网段、不同通信协议、不同速率等级的关键节点。它既要完成报文的路由转发，又要在 CAN、CAN FD、LIN、FlexRay、以太网等异构网络之间做协议转换与信号映射，还要在多网段并发通信时保证时序、带宽与安全策略的一致性。本课程围绕“如何用 CANoe 对网关与多总线系统做工程化测试”展开，本章先界定学习目标、核心概念与整体框架，明确后续 29 章要反复操作的测试对象。
一、学习目标：从“会用 CANoe”到“能测网关”
CANoe 本身是一个集仿真、测量、诊断、标定于一体的总线开发与测试工具。但会打开工程、会看 Trace 窗口，并不等于能测网关。本课程的学习目标分为三层：
- 概念层：理解网关路由表、协议转换、信号映射、多总线协同、残余总线仿真（RBS）等术语的准确含义，能区分“透传”“路由”“转换”“聚合”四类行为的差异。
- 操作层：能在 CANoe 中建立多通道工程，配置 CAN/CAN FD/LIN/以太网通道，加载 DBC/ARXML/Fibex 数据库，编写 CAPL 或使用 Panel 构造激励，采集并解析跨网段报文。
- 工程层：能针对网关设计测试用例，覆盖路由正确性、时延、丢帧、错误帧处理、总线负载、休眠唤醒、诊断路由等场景，并依据测量数据判定通过或失败。
这三层目标对应不同的验收方式：概念层用判断题和术语辨析检验；操作层用“能否在 10 分钟内搭出一个双通道 CAN 路由测试环境”检验；工程层用一份完整的测试报告检验。后续章节会逐步把这三层目标落到具体操作上。
二、核心概念：网关到底在做什么
网关最本质的工作可以概括为“收—判—转—发”四个动作。以一条来自动力 CAN 的报文为例：网关从 CAN1 通道接收帧，根据报文 ID 查路由表，判断该报文是否需要转发到 CAN2 或以太网；若需要，则按目标网段的帧格式重新封装（例如 CAN 经典帧转 CAN FD 帧，或 CAN 信号打包进以太网 SOME/IP 报文），最后从目标通道发出。整个过程涉及四个关键概念：
- 路由表（Routing Table）：定义“哪些 ID 从哪个通道来、到哪个通道去、以什么周期或触发条件转发”。它是网关测试的第一份输入文件，通常以 ARXML 或 Excel 形式给出。
- 协议转换（Protocol Conversion）：不同总线帧格式、位速率、数据长度不同，网关需要做帧级或信号级转换。CAN 经典帧最多 8 字节，CAN FD 最多 64 字节，以太网帧则更大，转换时可能发生信号拆分或合并。
- 信号映射（Signal Mapping）：同一物理量在不同网段可能由不同信号承载，网关需要按映射关系搬运并做必要的缩放、偏移、字节序转换。
- 多总线协同（Multi-bus Coordination）：多个网段同时通信时，网关的转发时延、缓冲区深度、优先级仲裁会相互影响，测试必须覆盖并发场景。
三、整体框架：本课程的知识地图
本课程按“对象界定—环境搭建—单网段验证—跨网段路由—协议转换—多总线协同—异常与诊断—复盘”推进。下图给出课程的整体知识地图与测试对象之间的关系，后续章节将沿这张图逐层展开。
四、测试对象界定：先分清“测什么”
很多初学者拿到一个网关项目后，第一反应是打开 CANoe 就开始发报文，结果测了半天不知道测的是哪条路由。因此本章必须先把测试对象界定清楚。一个典型的网关测试对象可以拆成六类：
| 测试对象 | 典型输入 | 观察点 | 判定依据 |
|---|---|---|---|
| 路由表 | ARXML / Excel 路由矩阵 | 源通道 ID、目标通道 ID、周期 | 每条路由均能正确转发 |
| 协议转换 | CAN 经典帧、CAN FD 帧、以太网帧 | 帧格式、DLC、数据长度 | 转换后数据语义一致 |
| 信号映射 | DBC 信号定义、缩放偏移 | 物理值、字节序 | 映射前后物理值一致 |
| 多总线协同 | 多通道并发激励 | 转发时延、丢帧、负载 | 时延≤阈值、无丢帧 |
| 诊断路由 | UDS 请求（0x22/0x2E 等） | 响应码、响应时间 | 正响应正确、负响应码合理 |
| 休眠唤醒 | NM 报文、唤醒源 | 网络状态、唤醒时间 | 按规范进入/退出休眠 |
这张表是后续章节的“索引”。第 2～6 章会围绕路由表与工程搭建展开；第 7～12 章聚焦单网段与跨网段路由；第 13～18 章处理协议转换与信号映射；第 19～24 章进入多总线并发、时延与负载；第 25～29 章覆盖诊断、休眠唤醒与异常处理；第 30 章做综合复盘。每一章都会回到这张表，明确“本章测的是哪一行”。
五、一个最小可运行的示例：双通道 CAN 路由
为了让大家在课程一开始就有一个可触摸的对象，这里给出一个最小示例。假设网关有 CAN1（500 kbps）和 CAN2（500 kbps）两个通道，路由表规定：CAN1 上 ID 为 0x123、周期 20 ms 的报文，需转发到 CAN2，转发周期保持 20 ms，数据场原样透传。用 CANoe 验证时，关键配置如下：
// 通道配置（示例）
CAN1: 500 kbps, 采样点 80%
CAN2: 500 kbps, 采样点 80%
// 路由表（示例）
Source: CAN1, ID=0x123, DLC=8, Cycle=20ms
Target: CAN2, ID=0x123, DLC=8, Cycle=20ms
Action: PassThrough
// CAPL 激励片段（示例）
on timer tSend {
message 0x123 msg;
msg.dlc = 8;
msg.byte(0) = 0x11;
msg.byte(1) = 0x22;
output(msg); // 从 CAN1 发出
setTimer(tSend, 20);
}
运行后，在 CANoe Trace 窗口中同时打开 CAN1 和 CAN2 两个通道，应能看到 CAN1 上每 20 ms 出现一帧 0x123，CAN2 上也在相近时刻出现一帧 0x123，且数据场一致。若 CAN2 上没有出现，或出现但周期明显偏离 20 ms，则说明路由未生效或时延超标。这个示例虽然简单，却已经包含了“激励—路由—观察—判定”的完整闭环，后续复杂场景都是在这个骨架上叠加协议转换、多通道并发和异常注入。
六、学习建议与常见误区
最后给出三条学习建议。第一，先读路由表再开 CANoe。路由表是测试的“需求文档”，不读路由表就发报文，等于没有验收标准。第二，先单通道后多通道。单通道都收不到报文时，不要急着加通道，先确认波特率、终端电阻、通道映射是否正确。第三，先功能后性能。路由能不能通是功能问题，时延和丢帧是性能问题，顺序颠倒会浪费大量时间。