2. CANoe工程环境搭建
在上一节中我们已经明确了多总线网关测试的整体目标：需要在一个CANoe工程中同时观察CAN、LIN、FlexRay三条总线的报文与信号，并通过网关节点验证跨总线路由行为。本节要完成的是把这个目标落地为一个可运行、可保存、可复用的初始工程。整个过程围绕四件事展开：硬件配置决定CANoe认识哪些物理通道，通道映射决定逻辑网络与物理通道如何对应，数据库导入决定报文和信号如何被解析，仿真节点创建决定谁来产生和响应总线流量。四者顺序不能随意颠倒，因为后一步往往依赖前一步的对象已经存在。
一、硬件配置：让CANoe识别真实接口
打开CANoe后，首先进入 Hardware → Network Hardware Configuration。这里的关键不是“点一遍按钮”，而是把实际使用的接口设备与通道数量对应清楚。假设本节示例使用一台VN5640（4路CAN/CAN FD + 2路LIN）和一台VN7572（FlexRay），那么配置目标如下：
- CAN通道：CAN1、CAN2 分配给动力与网关主干，CAN3、CAN4 预留给后续扩展；
- LIN通道：LIN1 分配给车身从节点，LIN2 暂不启用；
- FlexRay通道：FlexRay A、FlexRay B 双通道，波特率10 Mbps，冷启动节点由网关兼任。
配置时要注意两点。第一，通道编号是物理编号，与后面逻辑网络名称无关，不要因为“CAN1听起来像第一条总线”就默认它一定对应某个网络。第二，FlexRay必须明确A/B双通道的通信周期参数，例如示例中设置周期为5 ms、静态槽64个、静态段长度约3 ms，这些参数会直接影响后续数据库导入时的通信控制器配置。若硬件配置中的通道数量少于数据库要求，导入时会直接报错，因此建议先配硬件、再导数据库。
Test 或查看设备状态灯，确认通道处于Active状态；未激活的通道在Simulation Setup中会显示为灰色，无法绑定节点。二、通道映射：把逻辑网络接到物理通道
硬件配置解决“有哪些口”，通道映射解决“哪个网络走哪个口”。在CANoe中通过 Network → Network Configuration 或工程向导中的Channel Mapping完成。映射的核心对象是逻辑通道（Network）与物理通道（Hardware Channel）的绑定关系。示例映射如下：
| 逻辑网络 | 总线类型 | 物理通道 | 用途 |
|---|---|---|---|
| CAN_Powertrain | CAN | CAN1 | 发动机、变速箱报文 |
| CAN_Gateway | CAN | CAN2 | 网关主干与诊断 |
| LIN_Body | LIN | LIN1 | 车门、雨刮从节点 |
| FlexRay_Chassis | FlexRay | FR_A / FR_B | 底盘与安全域 |
映射完成后，CANoe的Simulation Setup中会出现对应的总线连线。此时如果某条总线没有节点，它仍然存在，只是没有流量。通道映射一旦确定，后续所有节点、数据库、测试用例都挂在这条逻辑网络上，因此建议在工程初期就把命名固定下来，避免后期改名导致引用失效。
三、网络数据库导入：让报文变成可读信号
数据库是CANoe理解总线的“字典”。CAN使用.dbc，LIN使用.ldf，FlexRay使用.fibex或.xml。导入路径为 Simulation → Simulation Setup → Databases，也可以直接拖拽到对应总线上。导入时要注意数据库与逻辑网络的绑定：CAN_Powertrain应绑定动力CAN数据库，LIN_Body绑定LIN数据库，FlexRay_Chassis绑定FlexRay数据库。
以示例动力CAN数据库为例，其中包含报文EngineStatus，ID为0x1A0，DLC为8，周期20 ms，信号包括EngineSpeed（0.25 rpm/bit，偏移0）、CoolantTemp（1 ℃/bit，偏移-40）。导入后，在Trace窗口中该报文不再显示为原始十六进制，而是展开为可读信号。若导入后信号显示为Unknown，通常说明数据库未绑定到当前通道，或报文ID与数据库定义不一致。
示例：EngineStatus (0x1A0, 20 ms)
EngineSpeed : start=0 len=16 factor=0.25 offset=0 unit=rpm
CoolantTemp : start=16 len=8 factor=1 offset=-40 unit=degC
EngineState : start=24 len=2 values: 0=Off 1=Cranking 2=Running 3=Fault四、仿真节点创建：让总线“动起来”
数据库导入后，总线上仍然没有报文，因为还没有节点发送。仿真节点分为两类：仿真节点（Simulated Node）由CANoe内部CAPL或Panel产生报文；真实节点通过硬件接口接入。本节先创建仿真节点，用于在没有真实ECU的情况下验证网关路由。
在Simulation Setup中右键对应总线，选择Insert Network Node，然后为其绑定CAPL程序。示例创建三个节点：
Sim_Engine：挂在CAN_Powertrain，周期20 ms发送EngineStatus，EngineSpeed在800~3500 rpm之间变化；Sim_Door：挂在LIN_Body，作为LIN从节点响应主节点轮询，返回车门状态；Gateway_ECU：同时挂在CAN_Gateway与FlexRay_Chassis，负责把CAN上的EngineStatus路由到FlexRay，并把FlexRay的底盘状态回传CAN。
创建节点后，需要为每个节点指定CAPL文件并编译。编译通过后，节点图标由灰色变为彩色，表示已激活。此时点击Start，Trace窗口应能看到EngineStatus以20 ms周期出现，LIN总线上出现轮询帧，FlexRay总线上出现网关转发的报文。若某条总线始终无报文，按“硬件通道是否Active → 通道映射是否正确 → 数据库是否绑定 → 节点是否编译并激活”的顺序排查。
五、工程保存与初始验证
完成上述四步后，使用File → Save Configuration As保存为Gateway_MultiBus_Base.cfg。建议同时保存一份.cfg的副本作为“干净基线”，后续做破坏性测试时可以快速回退。初始验证不需要复杂用例，只需确认三件事：
- Trace窗口中CAN_Powertrain上
0x1A0以20 ms周期出现，EngineSpeed数值在合理范围内变化； - LIN_Body上能看到主节点轮询帧和Sim_Door的响应帧，响应帧中车门状态信号可解析；
- FlexRay_Chassis上能看到Gateway_ECU转发的报文，且报文周期与CAN侧一致或按网关策略变化。
如果第3条不成立，优先检查Gateway_ECU的CAPL中是否对EngineStatus做了output()或frOutput()调用，以及FlexRay数据库中的帧ID与CAPL中使用的ID是否一致。很多“网关不转发”的问题，根源并不在网关逻辑，而在通道映射或数据库绑定阶段就已经埋下。把本节四步做扎实，后续的网关路由测试、总线负载测试和故障注入才有可靠的起点。