OSEK 网络管理之认识NM报文

OSEK 网络管理之认识NM报文

前言

关于OESK网络管理睡眠的文章有很多， 大多只有文字的介绍。笔者是汽车测试人员， 认为真实的log分析会更有利于初学者理解。 如有问题， 欢迎指正。

1. 网络管理协议数据单元（NM Protocol Data Unit）结构

所有的网络管理报文都包含协议数据单元（NM protocol data unit, 即NMPDU)，NMPDU 包含了网络管理的相关信息。如下图：

1.1 Source

 源头是发送节点的网络地址。如图发送节点的地址为400+4F;

1.2 Destination

destination字段包含逻辑后继者的NM地址。 如果没有逻辑后继着， Destination就是该节点自己的地址；如图目的地址是400+20；

1.3OpCode

有几种基础的NM报文类型：
*Alive message
Alive报文有以下三种使用情形：
1）开始阶段：如果一个ECU需要和其他ECU通讯或者接受到其他ECU的通讯请求， 该ECU会发送一个alive报文来注册到逻辑环。

2）正常阶段：如果一个ECU发现它在逻辑环中被跳过了， 它会重新发送alive报文以注册到逻辑环。
3）错误情况：如果一个ECU发现了其他ECU出现错误（在T[max]时间内没有收到ring报文）， 那么该ECU会发送一个alive报文来重新发起逻辑环。
*Ring message
在正常情况下，ECUs 会根据OSEK标准周期地发送ring报文。

*Limp home message
在出现错误的情况下ECU 会进入到跛行模式。

OpCode 的定义如下图：

DBC里信号定义如下：

总结： NM 报文类型有如下几种

2. NM报文长度

NM报文的长度定义为８Byte。

3. 数据位（Data Byte）

NM 报文的Byte3 ~Byte8 是用来表示网络相关的信息， 不表示应用数据。
当网络处于清醒状态时，网络中的每个ECU都应随时支持用户数据服务 。
供应商会提供特定的ECU用户数据， 一般包含以下2种：
*应用报文清醒原因(wakeup reason)

ECU会发送被唤醒的原因。被CAN通讯唤醒的ECU会发送唤醒原因：被网络唤醒;
被应用程序唤醒的ECU会发送唤醒原因: 为什么会被应用唤醒;
该bit大多数由OEM定义。
*CAN保持唤醒原因(reason keeping CAN bus awake)
ECU 会在跛行报文或者Ring报文上发送阻止ECU睡眠的原因。ECU会发送保持CAN网络唤醒的清醒状态的原因直到ECU把Sleep.Ind 位置1。
该bit大多数由OEM定义。

4. NM CAN ID

CAN ID = base address + node address. 基础址是0x400。 节点地址是0x00~0x3F .CAN ID 在这个区间的报文都会被其他ECU视为网络管理报文并执行正确的动作。每一个ECU有它独一的NM CANID.

5. ECU与网络之间的编码

NMPDU和CAN报文的转换如下图所示。 该转换由每个ECU内部的NM模块完成。

6. 总结

该文主要介绍了OSEK 网络管理报文的结构和常见的报文类型， 为下面了解网络管理功能打基础。