CAN通讯系列补充篇：OSEK NM是什么10

hudaren43

本文经CSDN博主- 嵌软小白呗允许转发，感谢支持！分享了几篇作者关于AutoSAR NM相关内容后，本文接着了解OSEK NM，OSEK NM也是汽车ECU常用的网络管理方法，后续对两者做个比较，以此可以更清晰地了解网络管理。本文将在原文基础上稍作修改，欢迎关注作者。
原文链接：全面详细讲解OSEK直接网络管理，并对比Autosar网管。
搞了两年的AutoSAR，用到的网络管理都是AutoSAR网络管理，虽然偶尔有听到或看到OSEK网络管理，但是一直没机会具体进行开发和测试。最近有机会具体接触和开发到，弄完之后感受就是：还是AutoSAR的网络管理好用，OSEK Nm状态比Autosar Nm复杂一点，而且OSEK Nm不好测试。为了弄清楚OSEK Nm, 本文以逻辑环为理解OSEK网管的切入点，展开详细地介绍，本文内容安排如下：1 前言2 OSEK NM的逻辑环和网管报文3 开始：逻辑环是怎么建立的？

步骤1：主动唤醒的节点发出Alive报文步骤2：被动唤醒的节点发出Alive报文步骤3：接收到Alive报文，ECU更新逻辑环中自己的后继节点步骤4：ECU发处Alive报文前后的OSEK NM状态跳变情况步骤5：CAN总线上发出第一帧Alive报文的ECU节点等待“TTyp”时间后，发出第一帧Ring报文，其它节点按照逻辑顺序发出Ring报文

步骤6：逻辑环建立完成

4 结束：如果所有ECU都不需要工作了，如何结束逻辑环进入休眠？5 小结1 前言据我目前所知，网络管理有OSEK网络管理和AutoSAR网络管理。OSEK网络管理具体又分为OSEK直接网络管理和OSEK间接网络管理；AutoSAR网络管理只有AutoSAR直接网络管理。

直接网络管理：简单来说就是通过网管报文实现网络管理间接网络管理：简单来说就是通过应用报文实现网络管理（间接网络管理没有网管报文）

而在汽车电子领域，网络管理的目的就是为了汽车上各个ECU节点能够同起同睡，本文讲的是OSEK直接网络，将同时对比Autosar网络管理。另外，再科普文中需要提前理解的概念：网管报文和ECU地址。

网管报文：所谓网管报文，就是一段范围ID的报文，OSEK网络管理定义0x400-0x4FF的报文为网管报文。ECU地址：若网管报文ID范围为0x400-0x4FF，则基地址为0x400，ECU地址为0x00-0xFF，如BMS节点的ECU地址为0x08。

刚开始接触OSEK网管的时候，各种网上学习，然后看到好多文章在讲什么令牌啊、什么逻辑环啊，而状态机图还是不常见的那些状态机图，对于我这个小白来说实在是太难受了，这么抽象理解半天没搞懂。后面经过实战，发现以逻辑环为理解OSEK网管的切入点比较好。2 OSEK NM的逻辑环和网管报文接下来就以此角度，我们先来看下各个ECU节点都处于唤醒状态并且处于稳定正常工作的情况，如下所示：


所谓的OSEK NM的逻辑环，其实就是上面图中那个东西：每个ECU按照逻辑顺序依次发出网管报文，并且报文的Byte0数据指向下个节点地址。从上面的报文可以看到，当前网络上有6个ECU节点，节点地址分别是：0x01，0x02，0x04，0x06，0x08，0x10，并且已经建立了逻辑环，另外我们称这些报文为Ring报文。接下来，我们从上面所示的逻辑环为学习OSEK NM的突破口，引出一系列问题，然后逐一解答，就很容易理解OSEK网管了。1、（开始）这个逻辑环是怎么建立的？2、（运行过程）逻辑环运行过程中，有一个新的ECU节点加入怎么处理？3、（运行过程）逻辑环运行过程中，有一个ECU节点异常退出怎么处理？4、（结束）如果所有ECU都不需要工作了，如何结束逻辑环进入休眠？在我看来，OSEK网管机制无非就这4种情况，我觉得把这4个问题解答完，整个OSEK直接网管就清晰明了了。注：考虑篇幅长度原因，2和3将在下篇文章介绍。
在此之前，我们先看下OSEK网管报文的字节数据定义：

Source ID：该报文的ID。

Dest.ID（Byte0）：目的地址，即指向的下一个ECU地址。

OpCode（Byte1）：

Bit0 为 Alive 报文标志位；

Bit1 为 Ring 报文标志位；

Bit2 为 LimpHome 报文标志位；

Bit3、Bit6、Bit7 预留，设置为“0”；

Bit4 代表 Sleep.Ind，即节点的睡眠指示位；

Bit5 代表 Sleep.Ack，即节点 Ring 报文的睡眠确认位；

其实这个也很好记，8个Bit，从低到高是按报文发出的时间顺序的：

列出表格如下：

DataFiled（Byte2-7）：数据内容与网络管理无关，数据内容由用户定义（比如可以填唤醒原因，用于问题分析等）。

另外，OSEK 网管机制中需要用到下面的时间参数需要先贴出来，大家有个印象即可，暂时不需要理解，下面讲解时用到的时候就明白了。


3 开始：逻辑环是怎么建立的？建立逻辑环，又涉及到整个ECU网络的同起同睡、主动唤醒和被动唤醒了，如果对这些概念不理解的朋友可以看下前面文章。步骤1：主动唤醒的节点发出Alive报文好了，现在整个CAN网络的所有ECU都处于休眠状态。假设ECU_A（节点地址为0x408）有主动工作请求并且主动唤醒了，然后ECU_A会向CAN总线发出一帧网管报文，由于此时逻辑环还未建立，因此发出的这帧网管报文我们称之为Alive报文。

Byte1：0x01，指示该报文为Alive报文。Byte0：0x08，由于该报文为Alive报文，因此该报文是指向自己的（0x408）。

步骤2：被动唤醒的节点发出Alive报文当主动唤醒的ECU节点发出首帧CAN总线上的Alive网管报文后，CAN总线上其它ECU节点收到网管报文后被动唤醒，并且也发出一帧Alive报文，如下图所示：


步骤3：接收到Alive报文，ECU更新逻辑环中自己的后继节点

关于这个步骤，只知道每个需要更新自己的后继节点就好了， 如何具体更新的算法，大家有兴趣的就看下。CAN总线上的节点在发出一帧Alive报文的同时还会接收来自总线其它节点的Alive报文，并且根据接收到的网管报文的报文ID，更新自己的后继节点，具体逻辑如下图所示：

其中：

R：Receiver为接收到网管报文的ECU（可理解为自己）S：Source为发送网管报文的ECU（可理解为发网管报文过来的ECU）L：Log.successor为接收到网管报文的ECU的当前后继ECU（可理解为当前自己的后继ECU）

更新自己后继节点的算法流程图如下：



当L = S的时候，就说明自己的后继节点（即L）需要更新为发送该网管报文的ECU节点（即S）。用第一行举个例子：



假设Source-ECU发出的报文ID为0x400，Log.successor-ECU地址为0x01，Receiver-ECU的地址为0x0F。当Source-ECU没有发出网管报文时，Receiver-ECU为逻辑环中地址最大的ECU节点，因此它的后继节点为地址最低的节点：0x01。现在Source-ECU发出了网管报文0x400，因此Receiver-ECU的后继节点就不是0x01而是0x00，如下所示：




图中其它行也是一样的理解。每个ECU节点按照这种后继节点的更新机制，当CAN总线上所有的ECU都发出一帧Alive报文后，同时每个ECU也都找到了自己的后继节点。
步骤4：ECU发处Alive报文前后的OSEK NM状态跳变情况



步骤5：CAN总线上发出第一帧Alive报文的ECU节点等待“TTyp”时间后，发出第一帧Ring报文，其它节点按照逻辑顺序发出Ring报文。

先看下"TTyp"定时器，即两帧Ring报文的时间间隔。定义如下：

再看看“Ttyp”定时器何时开启何时关闭及定时器到时动作，如下图所示：


从上表可知，TTyp定时器的使用其实就是实现了使得各个节点按照逻辑顺序依次发出Ring报文的功能，如一开始的那张图，可知TTyp定时器就是100ms。


而CAN总线发出的第一帧Ring报文从何而来？

其实跟上述 “TTyp”定时器开启的情况① 有关：每个ECU发出Alive报文后都会开启自己的TTyp定时器。由于大家的TTyp定时器的时间都是一样的，因此当然是发出首帧Alive报文的ECU的Ttyp定时器先计时完，然后发出第一帧Ring报文。如下：

Byte1：0x02，指示该报文为Ring报文。
Byte0：0x10，指示该报文指向的下个地址为0x10的ECU，如下所示：

步骤6：逻辑环建立完成

各个ECU按照 “TTyp”定时器开启条件和关闭条件，当计时完成就发出自己的Ring报文。至此！整个逻辑环就建完了。各个ECU按部就班发出Ring报文就好了，正如本篇文章开头的图片所示：  


在建立逻辑环的过程中，涉及到两个重要的网管状态：NMRESET和NMNORMAL。这两个状态实际上做了许多事情，如下图所示，大家可以仔细看看。

4 结束：如果所有ECU都不需要工作了，如何结束逻辑环进入休眠？

再看回OSEK网管报文的帧结构：


其中，

Bit4，SleepInd位：即睡眠指示位，这个位的置位与其它ECU无关。

当ECU没有主动工作请求后，在发出的网管报文中把SleepInd置位。当ECU有主动工作请求时，在发出的网管报文中把SleepInd清零。（睡眠指示位无论是在Alive、Ring、LimpHome报文都能置位）

Bit5，SleepAck位：即睡眠应答位，这个位的置位与其它ECU有关。逻辑环中每个ECU在发出Ring报文前，都会首先检查一遍逻辑环中其它ECU的SleepInd位是否都已置位，并且自己无主动请求，则将发出的Ring报文的SleepAck位置位，其它ECU检测到网管报文的SleepAck位置位后，则进入NMWaitBusSleep状态。（睡眠应答位只在Ring置位）

因此，当逻辑环中ECU都不需要工作后，会发出SleepInd位置位的报文，当最后一个不需要工作的ECU将SleepAck位置位后发出Ring报文，然后大家就都停放网管报文和应用报文，大家都进入NMTwbsNormal状态了。并等待TWaitBusSleep后进入NMBusSleep状态，大家都休眠了。流程如下图所示：

另外，当处于NMTwbsNormal状态若检测到唤醒源主动唤醒或被动唤醒（被动唤醒即SleepInd不置位的网管报文），则重新进入NMReset状态，重新开始建环流程。
5 小结到这里为止，就是处于正常情况下（所有ECU的Rx和Tx都正常）的OSEK网管从唤醒，到建环，再到完成建环，到最后整个网络休眠的整个流程。但是由于OSEK网管的逻辑环机制，导致当某些ECU出现异常情况的时候，出现异常的ECU和其它ECU必须有相对应的措施。而Autosar网管则没这么复杂，它只需要检测总线是否有网管报文，有网管报文就保持唤醒，没网管报文则进入休眠，不需要检测网管报文的数据内容，当某个ECU出现异常的时候，其它ECU是不需要对应做任何操作的。好了，上述讲完OSEK网管的正常工况，下篇文章开始讲OSEK网管的异常工况，欢迎关注下篇文章。