Autosar CAN开发10（Autosar的CanNM报文开发Configurator------非PNC）

嵌软小白呗

已于 2023-12-29 11:30:24 修改

阅读量3.2k

点赞数 15

分类专栏： Autosar架构BSW层开发历程文章标签： autosar 汽车 mcu c语言

于 2022-10-19 23:10:12 首次发布

本文链接：https://blog.csdn.net/qq_41848098/article/details/127378527

版权

Autosar架构BSW层开发历程专栏收录该内容

24 篇文章 379 订阅

订阅专栏

前面写了一些关于网管报文的作用和状态机，在此基础上就容易理解网管报文具体如何开发了。

一、接收网管报文的ID范围

在总线上，网管报文的有效ID是有范围的（比如0x550-0x5FF），挂在总线上的ECU只有接收到ID在此范围内的网管报文才进行响应（唤醒或保持唤醒）。

在Vector工具链的Configurator配置工具中，网管报文接收范围的配置是在CANIF模块中配置的，如下图所示，网管报文的接收范围为0x580-0x5FF：

二、网管报文重要、关键的时间参数

Repeat Message Timer：状态机停留在Repeat Message状态的时间

NM-Timeout Timer：若超过该时间没接收到网管报文，网管状态就从Ready Sleep状态跳转到Prepear Bus Sleep状态

Wait BusSleep Timer：若超过该时间没检测到唤醒源，网管状态就从Prepear Bus Sleep状态跳转到Bus Sleep状态

如下图所示：

另外：

NM Message Cycle Time：网管报文发送的周期时间

Immediate NM Cycle Time：当被本地唤醒后，网管报文快发的周期时间

Immediate NM transmissions: 当被本地唤醒后，网管报文快发的次数

配置如下图所示：

三、其它配置项

1、网管报文的Source Node Identifier即Node ID（Nid）和Control Bit Vector（Cbv）

网管报文的Byte0和Byte1分别为Nid和Cbv，至于Byte0是Nid还是Cbv可以根据用户自己定义。目前我所接触到的项目，Byte0都是Nid，Byte1都是Cbv，如下图所示：

Nid：Source Node Identifier。顾名思义，ECU节点ID。如车企定义有效网管报文的ID范围为0x550-0x5FF，则发出0x550这帧网管的ECU的NodeID为0，发出0x551的NodeID为1，以此类推发出0x5FF的ECU的NodeID为175（或十六进制：0xAF）。

根据Autosar标准，NoteID在NM报文中占一整个字节（8个Bit）。

NoteID的在Configurator中的配置如下：

Cbv：Control Bit Vector。Cbv也占据一整个字节（8个Bit），具体每一个Bit的定义如下（这是Autosar标准，不能自己改变的）。

在这个Byte中，“Reserve”即保留，Autosar官方把这些bit作为保留位以后使用。

Bit0：该位为RepeatMessage请求位。当ECU发出的网管报文该位置1时，发出的ECU自身的网管状态要进入RepeatMessage状态。其它ECU接收到网管报文该位置1时也要进如RepeatMessage状态。

Bit4：主动唤醒标志位。即当ECU为主动唤醒时该位置1。

Bit6：当网管报文有PNC功能才会用到。

官方定义如下：

3、网管报文的Offset（CanNmMsgCycleOffset）

网管报文Offset的意义：当CAN总线上的所有ECU都处于休眠状态，此时若某个ECU主动唤醒并向总线发出网管报文，总线上的其它所有ECU接收到网管报文后也将被唤醒进入RepeatMessage状态，向外发出网管报文，若每个ECU同时向外发出网管报文，则会造成总线爆发，因此给每个ECU配置不同的网管Offset，就避免了这样的情况。

官方解释如下：