CANoe仿真测试工具踩坑实录：通道映射失败与CDC报文配置全流程

实测Vector CANoe 12.0 SP4的是本人, 踩过两个大坑, 一个是通道映射失败致使仿真没有输出, 另一个是CDC报文循环发送频率失控, 新手依照下面步骤一步步去操作, 便能够轻松躲开这类常见问题。

第一步：正确建立CAN通道与仿真节点的映射关系

开启CANoe之后, 首先轻点菜单栏之中的Simulation -> Simulation Setup, 弹出的窗口之内你会瞧见左侧存在着硬件通道列表, 它的右侧是仿真节点区域。众多新手一开始就将CAPL脚本径直拖入节点, 最终居然发觉仿真开始运行起来了, 然而Trace窗口里却什么都不存在。

按下鼠标右键, 点击右侧那块空白的区域, 从中选择 Insert CAN Network项目, 随后对着新建立的网络进行双击操作, 于Network Properties窗口里面, 把Channel Mapping参数设置成为CAN 1。跟着, 将你所撰写好的CAPL脚本节点, 拖拽至这个网络之下, 要保证节点图标之上出现绿色链接标识。

【新手避坑】

常常出现的报错情况呈现为: “Node has no bus connection”, 而其中最为关键的缘由在于, 节点并未和物理通道进行绑定。得以解决的办法是, 于节点之上右键点击, 接着选择Configuration, 再选择Bus System, 而后确认是否勾选了CAN 1, 然后点击Assign。要是不进行这一个步骤, 节点就好比是悬浮于空中, 始终都无法收到总线消息。

第二步：配置CDC报文发送频率与关键参数

于Simulation Setup之中, 双击你的CAPL节点, 继而弹出Node Configuration窗口, 接着切换至Buses选项卡, 随后寻找CAN 1之下的CDC (Cyclic Data Configuration)。

轻点 Add 按钮, 填好你依喜好自行定义的 CAN ID, 像 那种 0x123 的样子。而后于 Cycle Time 字段当中输入 10 , 其单位为毫秒, 这所表达的意思是每间隔 10ms 就会发出一次。在此处存在着这样一个关键参数的最优推荐值, 对于通常的ECU仿真情况而言, Cycle Time设置成为50ms是最为安全的, 它既能够满足实时性方面的要求, 又不会由于发送速度过分快而将总线占满从而造成丢帧。

【新手避坑】

常常出现的报错情况是, 总线负载率在瞬间就飙升到90%以上, 其缘由在于，你把Cycle Time设置得太短, 像1ms或者5ms这样短。CANoe会竭尽全力按照这个周期去发送, 然而硬件底层有可能跟不上, 进而致使消息发生堆积。解决的办法是, 先设置成100ms, 借助CANoe自带的CAN Statistics窗口来观察负载率, 然后再逐渐把它调低, 直至寻到那个平衡点。

第三步：处理高频完整报错“Bus off”与一站式解决流程

处于你在进行跑仿真这个行为的时候, 突然之间弹出了 “CAN Bus: Bus off” 这样的错误, Trace窗里面呈现出满屏幕都是红色报错帧的状况, 如此情形属于是最令人崩溃的状况当中的一种了。

完整的报错现象当中, 控制器的节点, 是由于发送错误的次数, 超过了255次, 硬件从而自动地进入到Bus off状态, 进而停止了所有的通信。

一站式解决流程：

1. 起始于Simulation Setup里, 停下当下正在进行的仿真, 以右键点击你的CAPL节点, 接着选择Configuration, 再点选Error Frame Generation, 务必要求Error Frame Rate处于0%的状态。

2. 随后, 核查一下你那CDC配置当中, CAN ID同其他节点有无冲突情况。就好比你手动设定为0x123, 然而总线上的DBC文件里同样定义了这个相同的ID, 如此便致使两个节点同时发送相同ID, 进而引发仲裁失败。

3. 终于, 于CAN Statistics窗口里头, 去查看Transmit Error Counter以及Receive Error Counter, 要是前者持续地增长, 这表明是发送侧出现的问题, 将节点Transceiver Type调整成为High-Speed模式, 通常来讲是能够解决的。

针对于两种实操方案展开对比: 其中方案A乃是通过手动方式去修改CDC的Cycle Time, 此适合于简单的仿真情况；而方案B则是直接于CAPL脚本里借助output()函数依据需求来发送消息, 这适合复杂逻辑的场景。要是仅仅是运行周期报文, 那么选择方案A会更加省事；要是需要依据条件动态地发送消息, 选择方案B会更为灵活。我给出建议, 新手应当先将方案A运行成功, 而后再去尝试方案B, 否则容易把时序弄乱。

这个方法, 对于那种纯粹进行软件仿真, 也就是没有连接真实硬件的情况, 是完全适用的。但是, 如果你的项目, 需要进行硬件在环测试, 并且, ECU本身有着严格的时序要求, 那么在上述配置当中, CDC的Cycle Time必然得与ECU的标定参数严格对齐才行, 不然的话, 就会触发ECU的看门狗超时。可供替代的方案是, 直接运用CAPL脚本当中的on timer事件来促使发送行为, 从而避开硬件层面的时序差值。