CAN网络管理

1、ECU唤醒、休眠、Reset

参考网址：嵌入式开发：如何理解ECU唤醒、休眠、Reset?

（1）ECU唤醒是网络唤醒的前提。

（2）网络休眠是因为节点不想参与通信，停发报文是其最直接的表现。ECU有电，网络也可能休眠。

（3）下电过程中，某些节点需要等网络休眠一段时间再进行ECU的Shutdown时序，这段时间内，ECU带电。

（4）只要有一个唤醒源触发，即可唤醒MCU，但是，如果MCU想下电，则必须检查每一个唤醒源，当所有的唤醒源都不再请求通信时，MCU才能执行下电流程。

（5）工程常见的下电检查：

                所有触发唤醒的硬线状态，即：KL15等硬线是否拉低（Off状态）；

                是否还有诊断请求；

                是否还有网络管理报文；

                是否还有上层用户通信请求等。

         当上述的所有请求都不满足时，程序开始执行MCU的下电流程。

（6）ECU≠节点。一个ECU可以包含多个节点Node。举例来说：一个ECU有3路CAN，2路Flexray，1路Ethernet，应该说该ECU有6个节点。也可以具体说，该ECU有3个CAN节点，2个Flexray节点，1个Ethernet节点。

• 节点唤醒≠网络唤醒。节点唤醒后，才有可能发生网络唤醒。

节点唤醒后，若有网络主动请求 或 网络有被动唤醒请求，才会发生网络唤醒。

（7）VCC：C=circuit表示电路的意思,即接入电路的电压

Vreg：voltageregulator regulator是电压调整，就是稳压器的意思

1.1 ECU唤醒（本质：给MCU供工作电压---SBC使能给MCU供工作电压---SBC使能方式：1、硬线使能SBC  2、收发器监听到特定报文使能SBC）

前提：SBC（System Basic Chip）、CAN Trcv均与Battery常连。

说ECU连KL30电，其实是给该ECU的SBC、收发器（监控电压）连KL30电，而不是MCU直连KL30电。

1、SBC给外围器件输出其所需的工作电压。器件除了正常工作电压以外，还有一些监控电压，eg：CAN Trcv会常连KL30（Battery），用于自身电压和总线扰动的监控。

2、MCU通过监控硬线电平、监控收发器的INH电平状态，知道此次ECU唤醒是由于硬线还是CAN报文。

SBC系统基础芯片（SBC，System Basis Chip）:

一种包含电源、通信、监控诊断、安全监控等特性以及GPIO的独立芯片。

汽车电子硬件设计中，电源、通信，包括一些监控（例如看门狗/复位/定时器），都是通过多个电路来实现的。这不仅增加了电路设计的难度，也不利于在可靠性、系统成本、PCB空间以及电路功耗等方面做出优化提高。使用了SBC之后，由于SBC内部高度集成了一个基本硬件系统模块的基础电路功能模块（电源和通信），因此使得外部电路得以大大的简化。这也就体现了SBC这类器件的强大优势，因此有了广泛的使用。

一、硬线唤醒ECU（唤醒ECU同时唤醒CAN网络）

别称：主动唤醒、本地唤醒

主动唤醒：来自模块内部对网络的请求。主动唤醒节点的网络管理报文必须先于应用报文发送。

    （理解：因为主动唤醒节点必须确保网段上ECU被唤醒了，此时他再发应用报文才有人收）

(1)  唤醒源：

和硬线相关的唤醒方式，如：

• KL15硬线（钥匙开关到ON档）、
• 硬件传感器信号（脚踢门、后备箱打开）

(2)  特点：

• 唤醒ECU同时直接唤醒网络

例子：KL15唤醒ECU

当KL15硬线使能以后，SBC的ENA Pin脚使能V_LDO_Com和V_LDO_uC电压输出，此时，CAN Trcv即可获取通信工作电压，一般是5V（Vcc）。同时，ECU获取3.3V或者5V电压，进而程序开始从复位向量位置运行，此时，ECU被唤醒。

提示：Trcv与KL30常连，监听总线。SBC输出给Trcv 5V通信电压。

有的SBC不仅仅受一个KL15硬线使能，还可能受其他硬线（Other Line）的使能。不管SBC受多少外部硬线作用，一般来说，这些硬线之间是或的关系。

二、 BUS唤醒ECU（唤醒ECU后，ECU判断是否为有效唤醒源，决定是否唤醒网络）

别称：远程唤醒、被动唤醒

被动唤醒：来自总线上其他模块对该模块的网络请求。被动唤醒的节点，发送网络管理报文和应用报文的先后顺序无特别要求。

(1)  唤醒源：

和总线信号相关的唤醒方式，如:

• 收到任何网络管理报文、
• 指定诊断报文、
• 包含KL15信号的应用报文（有些节点没有KL15硬线，而是网管转发包含KL15信号的应用报文唤醒）

若采用AUTOSAR直接网络管理：

ECU必须选择符合 ISO 11898-5 标准的高速 CAN 收发器。若ECU处于低功耗模式，仅在总线上出现符合ISO 11898-5标准定义的唤醒序列，且该 ECU成功接收到该网段定义的唤醒报文时才能够被总线唤醒。这里这条唤醒报文必须是该网段中 ECU 的网络管理报文。

(2)  特点：

• 如果收到远程唤醒源的唤醒请求，Transceiver会使能Vreg给uC供电，进而使得ECU唤醒，ECU唤醒后会进一步判断收到的远程唤醒源是否是有效的网络唤醒源，如果不是则ECU走下电流程，网络没有唤醒；如果是有效网络唤醒源，则唤醒网络。（FAW不会进一步判断是否为有效唤醒源，会直接唤醒网络）

CAN BUS中，收到一帧有效的网络管理报文或者总线出现了符合唤醒CAN Trcv的Wakeup Pattern时，CAN Trcv使能INH Pin脚，一般，Trcv的INH Pin脚与SBC的WAK Pin脚连接，进而使能V_LDO_Com和V_LDO_uC电压输出，此时，CAN Trcv即可获取工作电压，一般是5V（Vcc）。同时，ECU获取3.3V或者5V工作电压，程序开始从复位向量位置运行，此时，ECU被唤醒。

电路设计中，收发器的INH引脚需要与SBC的WAKE Pin连接或者μc的供电电路连接，进而给μc供电，唤醒MCU(此时并未唤醒NM)。MCU会进一步判断收到的远程唤醒源是否是有效的网络唤醒源，如果不是则ECU走下电流程，网络没有唤醒；如果是有效网络唤醒源，则唤醒网络。（FAW不会进一步判断是否为有效唤醒源，会直接唤醒网络）

如果一个节点使用多种或者多个同类型Trcv时，每个Trcv的INH与SBC WAK是并联关系，也就是说，任何一个Trcv的INH均可使能SBC，进而唤醒MCU。

1.2 ECU休眠

        对于不同功能的ECU，唤醒源的个数和方式会有所不同，eg：ECU1只能被总线唤醒（eg：网络管理报文），ECU2即可以被总线唤醒，也可以被KL15硬线唤醒。虽然，不同的ECU，唤醒源和唤醒个数会有所不同，但是，如果ECU想休眠，必须其对应的所有唤醒事件都不存在。

        之前提到过，EcuM的Phase中有SLEEP和OFF两种时序。如果ECU进入SLEEP Phase，ECU仍然被供电，此时，ECU会消耗一定的能量，以便于监控唤醒事件（eg：总线的NM Msg）；如果ECU进入OFF Phase，ECU被完全断电，完全不消耗能量。不管ECU进入SLEEP Phase还是OFF Phase，工程上，我们都习惯称之为"ECU休眠"。在ECU休眠期间，ECU不再执行主要功能，等待被唤醒。

1.3 ECU Reset

       ECU Reset更多的是在说软件程序的运行行为。Reset的类型有很多，这里我们聊聊工程中常说的"ECU Reset"。Reset发生时，不同于ECU休眠，此时，ECU仍然处于供电状态。Reset的动作会使得程序"重头再来"。

        对于Reset，有些是合理的，eg：诊断服务$10 02/82、$11 xx。有些是非预期的，eg：程序跑飞，没在规定时间"喂狗"等。但是，不管预期的Reset，还是非预期的Reset，均是想让程序回到最初状态，再来一遍。

2、汽车网络管理的意义和分类

2.1 网络管理的意义

（1）工作状态协同

          保证同一网段基于KL.30电工作（即钥匙在点火锁的OFF位置时仍然工作）的节点能够协同睡眠和唤醒，以实现各节点在需要通信时可以正常收发报文，在不需要工作的时候可以进入低功耗状态。

        网络管理的目的就是为了汽车上各个ECU节点能够同起同睡。

（2）信息交互协同

        可以根据NM报文状态判定特定ECU的运行状态，从而根据需求定义处理相应信息。

（3）省电

        做了网络管理的ECU，当整车下电到OFF档时，一段时间内没有操作车辆的话，所有这些ECU都会进入低功耗状态，此时每个ECU的电流非常小，几乎会小于2mA，整车静态功耗基本能控制在20mA左右，即使将车辆放置一个月，到时候也能正常启动。

2.2 网络管理的分类

        当汽车上的所有节点都处于休眠状态，这时候节点A被触发了唤醒机制（比如车子被车主踩下踏板------这个栗子也不知道合不合适，反正就是假设节点A是主动起来的）。现在的情况是：节点A主动唤醒了，但车子正常工作不能就一个节点A醒来干活啊，其它几十个节点还全部处于休眠状态，这可咋整？他需要其他节点协同工作。

        直接网络管理：节点醒了之后发NM报文，其他所有节点收到NM报文全都唤醒。（同起同睡）

节点A向外喊一声（发送网络管理报文）不就行了。就像大学宿舍那样，大家要么在睡觉，要么出去玩，而且格外团结，每次有人出去玩都会叫人其他人一起。好了，现在你想出去玩了，你要怎么让在睡觉的他们跟你一起出去？很简单，你只需要大声吼一句：“兄弟们，走了，出去耍”，然后宿舍所有人听到了就起床一起出去玩了（都唤醒了）

        间接网络管理：节点醒了之后发应用报文，其它节点就会上一下子电，然后跑到检测唤醒源代码，检测到不是有效唤醒，最后就会马上又休眠下去。

但是注意，节点A要是向外广播的不是网管报文而是别的报文呢？用上面那个栗子，就会是这样：你叫大家去玩，但是，你不是吼要出去玩，而是吼一句：“兄弟们！看我看我！我是个帅比！”。那么效果就是舍友已迅雷不及掩耳之势把你丢出去，然后马上回去继续睡大觉。所以，要是节点A广播应用报文出去，那么其它节点就会上一下子电，然后跑到检测唤醒源代码，检测到不是有效唤醒，最后就会马上又休眠下去。

例子：Autosar CAN开发05（Autosar的CanNM----网管报文在汽车上的作用、“同起同睡”）_嵌软小白呗的博客-CSDN博客

（1）直接网络管理

        使用专用的网络管理CAN报文做网络状态管理，通过网络上是否有专用的报文及报文的值来做整个网络的协同

（2）间接网络管理

        不设定专用的网络管理CAN报文而是通过ECU节点发送的应用报文的状态做网络协同

3、OSEK直接网络管理

 直接网络管理：节点醒了之后发NM报文，其他所有节点收到NM报文全都唤醒。（同起同睡）

节点A向外喊一声（发送网络管理报文）不就行了。就像大学宿舍那样，大家要么在睡觉，要么出去玩，而且格外团结，每次有人出去玩都会叫人其他人一起。好了，现在你想出去玩了，你要怎么让在睡觉的他们跟你一起出去？很简单，你只需要大声吼一句：“兄弟们，走了，出去耍”，然后宿舍所有人听到了就起床一起出去玩了（都唤醒了）。

🌹具体过程：

1）主动唤醒节点发Alive报文 ，（后继节点是自己）

2）其他ECU全部被动唤醒，都发Alive报文

       CAN总线上其它ECU节点收到网管报文后被动唤醒，并且也发出一帧Alive报文

3）ECU根据Alive报文更新自己的后继节点

       CAN总线上的节点在发出一帧Alive报文的同时还会接收来自总线其它节点的Alive报文。并且根据接收到的网管报文的报文ID，更新自己的后继节点

    当CAN总线上所有的ECU都发出一帧Alive报文后，同时每个ECU也都找到了自己的后继节点。

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

        发出首帧Alive报文的ECU的Ttyp定时器先计时完，然后发出第一帧Ring报文。

5）各个ECU按照 “Ttype”定时器开启条件和关闭条件，当计时完成就发出自己的Ring报文。

🌹想休眠：

1）当逻辑环中ECU都不需要工作后，会发出SleepInd位置位的报文，当最后一个不需要工作的ECU将SleepAck位置位后发出Ring报文（后继节点指向自身？且携带睡眠应答信息的Ring报文）

2）然后大家就都停发网管报文和应用报文，大家都进入NMTwbsNormal状态了。并等待TWaitBusSleep后进入NMBusSleep状态，大家都休眠了。
注：当处于NMTwbsNormal状态若检测到唤醒源主动唤醒或被动唤醒（被动唤醒即SleepInd不置位的网管报文），则重新进入NMReset状态，重新开始建环流程。

PS：Autosar网管则远远没这么复杂，它只需要检测总线是否有网管报文，有网管报文就保持唤醒，没网管报文则进入休眠，不需要检测网管报文的数据内容，当某个ECU出现异常的时候，其它ECU是不需要对应做任何操作的。

3.1 报文类型

Alive 、Ring、LimpHome

（1）Alive报文：      

        在ECU初始化完成后以及节点发现自己被跳过时发送Alive报文。

        其他节点接收到Alive报文后，会处理报文中携带的地址信息，来更新网络配置，标识出处于在线状态的节点，并判断在逻辑环中自己的后继节点。

（2）Ring报文：

        当节点接收到Ring报文后，更新网络配置，标识处于在线状态的节点，判断逻辑环中的后继节点。

        如果Ring报文的目标地址是本节点，则本节点经过TTyp时间后向后继节点发送Ring报文，发送Ring报文后在数据链路层返回发送确认之前，接收到一个Ring报文，节点将忽略该报文；

        如果目标地址不是本地节点，则判断自己是否被跳过，若被跳过，则发送Alive报文表明自己的存在。若未被跳过，则重置Tmax定时器，等待接收下一条报文。

（3）LimpHome报文：（不太明白）

    其中是否进入LimpHome状态，是通过NMtxcount、NMrxcount这两个NM错误计数器来判断的；

这两个参数的值由车企定义。一般来说，rx_limit = 4。tx_limit = 8。

当NMrxcount大于等于rx_limit或tx_limit大于等于NMtxcount，则认为ECU通信出现错误，NM状态进入NMLimpHome状态（即跛足状态）

处于LimpHome模式下的ECU周期发送LimpHome报文，LimpHome报文的周期是TError。接收到LimpHome报文后，接收节点更新网络配置，标识处于LimpHome状态的节点。

当系统处在NMLimpHome状态时，系统将会传输一个周期性的LimpHome消息。NM继续监听网络，以便确定消息传输是否已被恢复从而切换回NMNormal状态。

 1、两个NM错误计数器的具体计数过程

（1）进入NMRest状态：

        第一次进入Reset初始化时：将NMtxcount、NMrxcount计数器清零，

        之后从Normal进Reset时：将NMrxcount加1，在发送Alive报文后，将NMtxcount加1；

（2）进入NMNormal状态：

                ①接收到任何RingNM报文后，清空NMrxcounter

                ②成功发送Ring网管报文时，清空NMtxcounter

                ③有发送网管报文的请求时，NMtxcounter加1（注意在数据链路层拒绝发送报文时，重发报文时对NMtxcount计数器无影响）

如果要使NMrxcount计数器达到阈值进入LimpHome状态，则再进入Normal后总Tmax时间内没有接收到报文，而后重新进入NMReset状态，重复Reset中将NMrxcount计数器加1，在发送Alive报文后，将NMtxcount计数器加1过程；此过程一直重复，直至NMrxcount计数器达到阈值后进入LimpHome状态。

2、如何进入LimpHome状态：

--------------------------

例子：网络上只有一个NM节点：

ECU上电后，先尝试建立逻辑环，尝试5次后，依旧无法建立逻辑环，则ECU进入LimpHome状态，ECU按TError（一般是1000ms）的周期发送LimpHome位置“1”的报文。

Alive-Ring-Alive-Ring...多次后，则ECU进入Limphome。

--------------------------

a、当有主动请求（Active）或CAN总线上存在节点SleepInd不为1时，TX失败：

        情况A：当处于NMNORMAL状态出现TX失败

                ①当出现CAN总线上的Ring报文指向我们后，我们开启“TTyp”定时器，定时时间完成后，我们会请求发出网管报文但发送失败（NMtxcounter+1），并开启“TMax”定时器，由于我们没发出网管报文，导致其它ECU的“TMax”计时完成，我们的“TMax”计时也完成同时网管状态进入NMRESET状态。

                ②我们进入REST状态后请求发出Alive报文但发送不成功（NMtxcounter+1），并再次进入NMNORMAL状态。

                ③由于我们Alive报文发送不成功，CAN总线的逻辑环不会包含我们节点，因此，逻辑环会跳过我们，我们由于检测到被跳过，因此会请求发送Alive报文，但仍然发送失败（NMtxcounter+1）。

                ④不断循环步骤3，直到NMtxcounter等于txlimit。我们的NM状态进入LimpHome状态

        情况B：当处于NMRESET状态出现TX失败

                情况A中的除去①，剩下的②③④即是处于NMRESET状态出现TX失败的流程。

b、当有主动请求（Active）时，RX失败：（理解了）

        由于我们有主动请求，因此不会进入休眠。

        又由于无法接收报文，我们无法收到指向我们的Ring报文，“TMax”计时完成后，我们会进入RESET状态（NMrxcount+1），并发送Alive报文，然后进入NMNORMAL。

        不断循环上述情况，直到NMrxcount等于rxlimit。我们的NM状态进入LimpHome状态

c、当无主动请求（Passive）且CAN总线上所有节点SleepInd为1，TX失败：

        当我们无主动请求，且所有节点SleepInd为1时，逻辑环一定会出现某个节点SleepAck为1。由于txlimit为8，理论上来说，当这个NMtxcounter计数器还没到txlimit，我们节点就能接收到SleepAck为1的报文，则直接进入WaitBusSleep模式了。

d、当无主动请求（Passive）时，RX失败：

        ①由于无法接收到Ring报文，“TMax”计时完成后，我们会进入RESET状态（NMrxcount+1）

        ②在RESET状态发送Alive报文后，开启“TTyp”定时器，并进入NMNORMAL状态，“TTyp”定时器完成后，由于未收到其它节点的报文，因此我们认为总线上所有节点的SleepInd已置位，然后我们发送SleepAck报文，并进入WaitBusSleep模式。

        （无主动请求 且 接收到CAN总线上所有节点SleepInd都为1）

3、进入LimpHome状态后的动作

ECU不再申请加入逻辑环，即不再发送Alive报文和Ring报文。而是发送LimpHome报文。

🌹LimpHome报文的发送情况：

情况1、当有主动请求（Active）或  接收到CAN总线上存在节点SleepInd不为1时：

             LimpHome状态处于“NMLimpHome Active”子状态，并按照TError周期发送LimpHome报文

情况2、当无主动请求 且 接收到CAN总线上所有节点SleepInd都为1时:

             发送SleepInd置1的LimpHome报文，LimpHome状态从“NMLimpHomeActive”子状态跳至““NMLimpHomeActivePreSleep”子状态。发送完该报文同时开启“TMax”计时器，等待计时结束后网管状态进入NMTwbsLimpHome，等待TwaitBusSlee时间后进入BusSleep状态。

        （无主动请求且总线上也没有ring报文了）

        总结：处于limphome的节点无主动请求——>节点发SleepInd为1的limphome报文，同时开启Tmax计时器——>若Tmax时间内未收到总线上任何Ring报文->limphome节点休眠（等待TwaitBusSleep事件后进入休眠）

 情况3、当接收到SleepAck置1的网管报文

              直接进入NMTwbsLimpHome状态，等待TwaitBusSleep时间后进入BusSleep状态。

注：之所以分情况2、3：是因为处于limphome、alive状态的节点是没有SleepAck状态的

另外，当在NMTwbsLimpHome状态再次有主动请求或接收到CAN总线上存在节点SleepInd不为1时，则根据上述的情况1、2、3执行对应操作。

🌹limphome节点如何进入休眠：

法一：当无主动请求 且 接收到CAN总线上所有节点SleepInd都为1时        

        （即无主动请求且Tmax时间内总线上也没有ring报文了）

法二：接收到SleepAck置1的网管报文

具体对应上面的情况2、3

4、如何从LimpHome状态恢复

在LimpHome状态时，如果成功发送LimpHome报文且成功接收到网管报文后，网管状态则跳转至Reset状态。

3.2 定时器类型

OSEK NM 中定义了四种定时器

3.3 逻辑环机制

        处于逻辑环中的节点根据节点地址的大小顺序依次发送 Ring 报文，通过这种环状的通信机制，网段中的节点可以有效地进行节点信息交互。逻辑环的结构与网络拓扑或者节点的安装位置无关，只与事先分配的节点地址有关。

        在令牌传递的过程中，令牌会被网络中所有节点接收，但只有地址匹配的节点（即后继节点）会得到令牌。

例子：理解OSEK NM原理，看完这个就够了-CSDN博e

ECU并不知道房间里有多少瞎子。而且瞎子的数量会变化，因为随时可能有瞎子进来，或者逃跑。所以要Alive报号。

（1）Ttype（传铃的节点等Ttype后传铃铛给下家）100ms

每个节点报完号（alive）：就立刻拿出一个铃铛在手上，并启动Ttype闹钟。则最先报完号的节点闹钟最先响，他就会传铃铛给下家。

Ttype：当瞎子们有一个铃铛想往外扔的时候(这个铃铛一般是上家扔给他的，但也可以自己掏兜里的(只有第一个报号的瞎子可以把自己兜里的铃铛扔出来，详情见上一段))，他就把闹钟打开，定时到了再把铃铛扔给下家。ECU想传铃铛时（上家给的或者自己兜里的（只有第一个节点可以传自己兜里的）），这个ECU就把Ttype时间打开，到点了就传给下家。

此时其他人听到总线上已经有铃铛了，不管是否扔给自己，就把自己手里的铃铛收好，就等别人给他传铃铛了，Ttype闹钟也关掉。其他人就等铃铛传到手里后，再打开闹钟Ttype。这样的结果就是铃铛以Ttype间隔时间在瞎子们手上传递。

Ring报文指向的ECU需要开启TTyp计时器，等待计时器到时后就发出它的Ring报文。

当ECU接收到不指向自己的Ring报文的时候，会关闭TTyp定时器，因为Ring报文不指向它，所以下一个发Ring报文的ECU不是它，当然就不需要开启TTyp定时器了。

（2）Tmax（所有节点监听总线上ring报文超过Tmax未发，则该节点重新建环）260ms

为了防止有时候铃铛突然不见了（比如扔得不准，或者有瞎子突然跑掉了），每个瞎子都要启动自己的Tmax闹钟，所有人只要听到有人扔铃铛，这些人就要重新启动这个闹钟（收到铃铛的瞎子则会先关掉Tmax，等将手上的铃铛扔出去后再启动）。除了扔铃铛的ECU，其余ECU的Tmax闹钟是同步的，Tmax闹钟响的ECU被规定要重复建环的过程。

地主将Tmax设得比Ttype大不少，所以正常情况下，这个闹钟不会响。如果这个闹钟响了，就说明传递中的铃铛丢掉了。Tmax闹钟响的瞎子被规定要重复建环的过程（除了扔铃铛的瞎子，其余瞎子的Tmax闹钟是同步的，所以只要是铃铛丢了，大家就会自动重复一遍建环的过程，重新报Alive建环。）就是要报号，拿铃铛，设Ttype…

Tmax：两帧Ring报文之间最大的时间间隔

（3）Terror（limphome节点每过Terror报告自己状态）1s

Limphome：ECU接不到铃铛了(Rx error)，又或者扔不出铃铛了(Tx error)超过一定阈值。

该节点进入Limphome后：

1、该节点开另外一个闹钟Terror，每过Terror时间报告一下自己的状态。

2、对于其他的ECU来说，这个聋掉的瞎子就像是消失了一样，会被踢出环内。

3、听到铃响，尝试重新建环，发alive报文。

总结：

	接不到铃铛	扔不出铃铛
何时重新建环	听到铃响
何时休眠	自己的活结束	1、自己的活结束且又有ECU说可以睡了 2、外面没动静了(Tmax timeout)

（4）TwaitBusSleep（Sleep.Ack置为TRUE，所有节点等待此时间后网络休眠）5s

如果在进入等待睡眠状态后 TwaitBusSleep 时间内，网络中所有 ECU 没有监测到中断事件，将同步进入睡眠状态。若 ECU 监测到中断，则 ECU 重新发送 Alive 报文，重新建立逻辑环；

规定ECU只能在扔铃铛的时候可以通报一下自己是否可以睡眠(sleep indication)。

如果有一个结束工作的瞎子在自己的这个ring周期(从自己将铃铛扔出去开始到铃铛重新回到自己手上)内都没有听到有瞎子说不能睡眠(sleep indication is not set)，他就可以认为所有的瞎子都可以休息了，他在扔铃铛的同时就宣布大家可以休息(sleep acknowledge)。而其他的瞎子收到后就可以准备睡觉了。

节点进入睡眠状态的过程图：

发出Ring报文的第一个节点将Sleep.Ack置为TRUE，之后所有节点进入等待睡眠状态。

等待睡眠状态

停止传输Ring报文，启动TWaitBusSleep定时器，当TWaitBusSleep定时器到时，停止所有总线上的传输，并切换到NMBusSleep状态（ECU休眠（所有节点同时休眠））；等待睡眠过程中，它继续监听网络上的报文，任何网络管理报文被接收时，若其Sleep.Ind为FALSE，那么节点进入NMReset状态重新启动。

※特殊情况

(1)加入新节点/节点被跳过

该节点重新参与建环，该节点发alive报文，但此时因为已经有一个铃铛在传递中，所以这个瞎子不会扔出自己的铃铛。而报过号后，别的ECU也会重新计算自己的下家。

(2)网络节点丢失（超过Tmax）

此时上家传铃铛给下家时，下家因为网络节点丢失，不会继续传铃铛。铃铛丢失，所有ECU都重新报Alive建环。

当某个ECU突然退出逻辑环后，其它所有ECU的TTyp定时器都会关闭，但同时会开启“TMax”定时器，当定时器时间一到，CAN总线网络上每个正常节点都进入RESET状态，重新发送Alive报文，然后重复开始建环的动作。

3.4 数据场定义

Byte0：网络管理报文发送的目标地址。

在Alive状态时填充设备ID，但注意建环前表明身份还是靠监听CAN ID XX而不是Alive时的data[0]，在Ring状态时填充传递Token令牌的ID

Byte1：操作码

SleepInd位：即睡眠指示位，这个位的置位与其它ECU无关。当ECU自己没有主动工作请求后，在发出的网管报文中就把SleepInd置位。当ECU有主动工作请求时，在发出的网管报文中就把SleepInd取消置位。（睡眠指示位无论是在Alive、Ring、LimpHome报文都能置位）
 

Alive：0x02、0x06

Ring：0x01、0x05、0x03/0x07（Ring操作码均为单数）

Limphome：0x00、0x04

Byte2-7：由用户定义（比如可以填唤醒原因，用于问题分析等）

3.5 节点的状态

节点有三个状态：

NMAwake子状态：

两个核心服务（应用层）：

StartNM( )，

StopNM( )。

3.6 OSEK直接网管的状态图（还需仔细理解）

NMOff：网络管理关闭
NMOn：网络管理正在运行
NMShutDown：关闭网络管理的操作，此过程会清理一些在运行过程中产生的数据

NMOn状态下有两组并行的子状态，互不影响：

NMInit：主要是硬件初始化，此状态很短暂（初始）
NMAwake：一般情况下节点长期保持的状态，正常进行网络管理
NMBusSleep：睡眠状态，网络管理通信停止
NMActive：参与网络管理（初始）
NMPassive：节点不参与网络管理，但仍监视网络活动

NMAwake状态下也有三个子状态：

NMReset：软件初始化，发送alive报文
NMNormal：周期性发送或接受Ring报文，检测节点状态和网络配置的变化
NMLimpHome：节点非正常状态，不能正常发送/接收网络管理报文，尝试周期性发送跛行报文

一个节点从休眠到唤醒，再到休眠状态的跳转示意图如下：

     ①：Osek网管的完整简化状态图

  ② 从唤醒状态，到休眠状态，再到唤醒状态的过程状态图

 ECU发处Alive报文前后的OSEK NM状态跳变情况：

3.7 OSEK直接网络管理与Autosar直接网络管理对比

🌹Autosar直接网管简要介绍

在节点A有主动工作需求的整个过程中，节点A会一直向外发出NM报文，以使得其它节点一直处于唤醒状态，其它节点是不会发出网管报文的（被网管唤醒的节点在被唤醒的开始几秒会发出几帧NM报文，然后它就停发NM了）。当节点A主动工作需求结束后，它就停发网管了，此时若车上其它节点也没有主动工作需求，那么车上就没有节点向外发网管报文了，当车上的节点没有接收到网管报文一段时间后，就会进入休眠状态。

Autosar网管不需要检测网管报文的数据内容

共同点（※同时唤醒同时休眠）

1、都是基于状态机的网络管理。
2、都是协调网络中的节点同时进入休眠以及唤醒。
3、都分配了特定的网络管理报文在网络中进行网络管理，属于直接网络管理。
4、通常情况每个节点都有独有的节点ID（如0x1），与基础ID(如0x400)共同构成网络管理报文的ID（0x401）。
5、网络唤醒方式都相同，每个节点都可以由于自己需要通信而主动唤醒网络，也可以被网络中其它的节点唤醒。
 

区别点

（1）网络休眠->网络唤醒

        Osek网管：主动唤醒的节点先发出一帧Alive报文，其它各个节点接收到网管报文后被动唤醒，发出一帧Alive网管报文

        Autosar网管：主动唤醒的节点先发出网管报文（持续发出网管报文），其它节点接收到网管报文后被动唤醒，同时也发出网管报文（只发出几帧网管报文）。

 （2）网管唤醒后正常工作

      Osek网管：无论是主动唤醒节点还是被动唤醒节点，都要按照逻辑环机制发出Ring报文。

      Autosar网管：主动唤醒的节点持续按照周期发送网管报文，被动唤醒的节点不发送网管报文。

 （3）网络唤醒->网络休眠

       Osek网管：接收到Ring报文的SleepAck后所有节点马上进入预休眠状态，等待TwaitBusSleep时间后进入BusSleep状态。

        Autosar网管：总线不再出现网管报文后所有节点等待一段时间后进入预休眠状态，等待TwaitBusSleep时间后进入BusSleep状态。

（4）异常情况

        Osek网管：ECU有对应的LimpHome状态，及该状态下对应的动作。不论是加入某个新节点还是掉线某个节点，都会影响网络管理的状态，需要重新建环才能维持正常的网络管理。

        Autosar网管：由于ECU的休眠唤醒只于总线上是否有网管报文有关，因此某个ECU出现异常时，其它ECU不会有对应的处理机制，异常ECU本身也没有对应的网管机制

（5）网络管理逻辑不同

        Osek网管：需要建环，网络管理报文的发送必须按照逻辑环进行，只有得到“令牌”才能发送网络管理报文，因此需要一个稳定的逻辑环，网络管理才能正常进行，对网络的稳定性要求比较高。

        Autosar网管：不会受到其他节点状态的影响，节点状态的跳转只与自身需求和总线的状态有关，只需要监视总线状态即可，网络管理报文的发送是周期性的。

（6）网管报文格式不一样

        Osek网管：由于逻辑环的存在报文包含节点自身的ID和下一个发出网络管理报文的节点的ID，包含用于指示报文类型以及节点状态的数据，即操作码以及用户数据。

        Autosar网管：由于是广播发送的且不需要指定任何节点，所以报文只包含自身的ID，和少量的控制信息，即控制位向量，以及用户数据。 

控制位向量（CBV）：AUTOSAR网络管理PDU中的byte1（第二个byte），这个字节中包含重复消息请求信息，主动唤醒信息以及PN相关等表明节点进行网络管理的控制信息。

4、间接网络管理

        间接NM使用周期性的应用报文监控来决定连接到网络上的节点的状态，它不适用专用的网络管理报文。其节点状态分为发送者和接收者2种状态。其中发送者状态中又包含节点非静默和节点静默2种状态；接收者状态中包含节点在线和节点离线2种状态。另外还有2个扩展的节点状态， 即扩展的发送者状态和扩展的接收者状态。

        间接网络管理的配置将所有由NM决定的被监控节点的节点状态组成整体， 它有目标配置和扩展配置。

        为评估节点状态和网络状态，间接网络管理提供3种非专用的监控机制：1传输，2接收，3故障信号。传输和接收监控基于两种可能的超时检测机制：所有报文被全局超时TOB监控，每条报文被自身的专用的超时监控。

        间接网络管理没有节点地址的概念，它采用主从模式进行管理，即主机向从机询问从机网络状态，或命令从机睡眠等，而从机只向主机发送本地节点的网络状态的消息，而从机之间不互相做网络管理通信。

例如：主到从

在主机广播给从机的应用报文中预留了一个位，当这个位被置为1时，这个主机请求所有的从机进入NMBusSleep。