CANoe中关于NetworkHardwareConfiguration中设置参数的详解

帅气小胖子

已于 2025-05-19 23:11:28 修改

阅读量2.7k

点赞数 27

文章标签：车载系统

于 2024-04-16 13:21:34 首次发布

本文链接：https://blog.csdn.net/WE_BIG/article/details/137810146

版权

前提说明

25年5月13号，再次编写，完善一下整个NetworkHardwareConfiguration的整体介绍，

整个网络硬件配置，涉及选项也比较多，此外根据总线类型，CAN或者CAN_FD（CANFD又分为两种ISOCANFD, NONCANFD两种），CANxl几种，每种总线协议下Setup界面都是不同的。我们先从简单到复杂，最后介绍Setup界面

配置界面

我们选择 CAN_1的逻辑通道为例：

（步骤1）开启NetworkHardwareConfiguration界面，如下图

从图中可以看到，右侧按照逻辑通道（也就是CAN1....CAN4....这些值都是固定的）呈现一个树形

区域，单击展开按键，可以依次打开选项

（1）CAN1-CAN4，每一个大项又单独包含4和小选项，依次是

(*1)Setup 设置

【这也是最重要的，很多基本和重要功能都是在这里设置的，多说一句，如果只想掌握基本操作，CANoe工程能够运行，那么掌握Setup中的一些基本配置即可】

（*2）Acceptance Filter

（接收过滤器，在设置界面上设置那些报文可以通过）；

（*3）options

（若干配置项，主要是一些SSP设置和Txrq）；
(*4）

CANopenSetting 关于CANopenSetting的设置；简单来说CANopen是针对在机器人，轨道机动车，医疗设备等上应用的比较多！CANopen是一种应用层协议。

1、先从最简单的 Acceptance Filter 开始说起

这就是一个可以设置那些帧报文可以通过的设置，怎么说喃？这是在数据链路层就进行的一种筛选方式，和我们在Trace界面上通过ID筛选存在不同（这是属于应用层的一种筛选）。此外根据官方文档的解释，此处进行更改还会导致总线statics数据发生变化。

实例化的解释就是，如果在此界面设置只能通过3条帧报文，但是实际上总线上有30条报文在总线上发生，假如此时总线负载率=60%，但是此时VN1640显示的总线负载率只有=6%。这一点也是之前就声明了的，这是针对数据链路层的过滤器，而总线负载率也是通过数据链路层来统计的。

1.1 Acceptance Filter设置界面

可以看到，右侧界面存在两个设置区，一个是针对传统11bit帧报文，一种是针对拓展29bit帧报文。

我们只需要掌握一种配置即可，

从上到下
（*1）Block all 所有报文都不接收

（*2）ID，可以单击Select ID在选择DBC中以及定义的报文。前面还有一段11bit XXXX。。。构成的示意图。这里选择后，ID就直接变成了你选择ID二进制。

（*3）Code和Mask，这两个放在一起讲，

1、Code 代表期望接收的报文 ID 的特征码。

2、Mask 则定义了哪些位是需要匹配的。具体来说，Mask 中的每一位如果是 1，就表示对应的 Code 位必须与接收到的报文 ID 位匹配；如果是 0，就表示该位可以忽略，不进行匹配。

比如，假设 Code 设为 0x123(001 0010 0011)，Mask 设为 0x700。那么 Mask 的二进制是 01110000000，意味着只检查 ID 的高 3 位。接收到的报文 ID 高 3 位如果是 001（即 1），就会匹配，因为 0x123 的高 3 位是 001（假设 ID 是 11 位）。这样可以灵活过滤 ID。

即报文0x110，0x120，0x123等都可以通过，也就是报文ID最高位=1的报文都可以通过。

首先查看Mask，1表示要检查位，0表示不需要检查位。然后将需要Mask&（按位与）Code，得到一个值，只要报文的需要检查的位=Mask&（按位与）Code。

小结：总体来说比较复杂，实际作用不是很大，如果不感兴趣可以直接跳过。

2、Options（选项）

单击左侧树形导航图中的Options，得到如下界面

框选部分分为两个区域：“Channel-specific（通道设置）” 和 “CAN FD specific（CANFD设置）”。

2.1 先看 “Channel-specific” 下的选项：

“Activate TxRq”：激活发送请求。勾选后，设备会启用发送请求机制，允许主动触发数据发送，用于控制数据何时通过通道发送到总线上。（这里对发送请求机制做出了些许解释，但是还是很含糊不清，并没有解释发送请求机制的主要内容是什么？定时发送机制？）

[查阅相关资料后，这个选项是和Output函数相关

output()函数的行为：无论是否勾选 “Activate TxRq”，output()都能发送报文，但底层实现不同：
- 未勾选：CANoe 可能直接写入硬件发送缓冲区，绕过 TxRq 机制。
- 勾选：CANoe 会通过硬件的 TxRq 寄存器触发发送，更接近真实 ECU 的发送行为。实际影响：在大多数测试场景中，不勾选也能正常发送；但在模拟 ECU 通信或测试总线负载时，建议勾选以获得更真实的结果。
“Activate Tx failed notification”：激活发送失败通知。勾选后，发送失败时会通知，便于错误处理。

- 勾选 “Activate Tx failed notification” 后，发送失败时 Trace 窗口会显示错误信息。
- 未勾选时，outputEx()可能仍返回错误，但 Trace 窗口不会特别标注
Activate Tx failed notification” 的作用是：使 VN1640A 硬件在发送失败时设置状态标志。影响outputEx()的返回值，便于用户程序检测错误

2.2 再看 “CAN FD specific” 下的选项：

2.2.1）“Protocol exception support”：协议外事件支持

勾选后，设备会处理 CAN FD 协议中的异常情况，增强容错。

看下文的一段描述：

这里勾选，起到的作用就是，检测到 res = 1时，不会报错。

2.2.2 另外一个重要的概念：“总线整合状态”，

什么叫做 “总线整合状态”

“总线整合状态（bus integration state）” 可通俗理解为 CAN 节点的 “通信准备阶段”。当 CAN 节点刚启动协议操作、从总线关闭状态恢复，或检测到协议外状态（仅 CAN FD 或兼容节点）时，会进入该状态。在此状态下，节点会监听总线信号，调整自身发送和接收行为，就像车辆进入高速公路前观察路况、调整车速，确保后续通信顺畅。当节点检测到总线连续出现 11 个隐性位（即总线空闲），则认为 “路况畅通”，随即离开该状态，正式参与总线通信。

提炼与总结：

（*1）所谓“总线整合状态（bus integration state）”，是针对节点（Node而言的）；

（*2）“总线整合状态“ 是一种节点准备参与通信的一种阶段，只监听总线状态

2.2.3 另外一个重要的概念：“协议外事件”，

1）、什么是协议外事件

在 ISO 11898-1 标准中，“协议外事件” 是指接收节点检测到自身不支持，但符合规范定义的特定异常情况，这些事件旨在提高协议的向上（前向）兼容能力，是一种前瞻性容错机制，允许现有节点在无需修改硬件的条件下，容忍未来协议扩展带来的未知帧格式，降低网络升级复杂度。

解读：

2）、协议外事件的处理方式

3）、协议外事件处理实例

实例说明

实例1：CAN FD节点与传统CAN节点共存

场景：
CAN FD网络中存在一个传统CAN节点（此CAN节点仅支持经典帧格式，而其他节点则支持CAN_FD）。
协议外事件触发：
传统CAN节点作为接收节点时、收到CAN FD帧（符合ISO 11898-1标准但自身不支持），检测到以下特征：
- FD帧的FDF（FD Format）位为隐性（表示CAN FD格式）,但是CAN节点自身没有那么智能，在接收到CAN_FD帧报文时，传统CAN节点依次接收SOF+ID+RTR+IDE+r0。传统CAN协议中r0位一定要是显性，但是CAN_FD发出的却是FDF=01。如果此CAN节点，不支持协议外事件，就会报错，接收节点就会发出错误帧
- 数据段波特率提升至2 Mbps以上（传统CAN节点硬件不支持）。
处理方式：
传统CAN节点将此事件标记为“协议外事件”，忽略数据段内容，仅处理仲裁段（ID、DLC等），避免发送错误帧。总线通信正常进行，仅该传统CAN节点无法解析数据段。