目录
1. 概述
为什么车上的控制器需要做网络管理？
因为在目前的整车电子电器架构下，整车的部分ECU是需要一直供电，从整车下线到车辆报废，它都一直在工作，想想你的使用情况就明白了，你在任何时候按下遥控寻车，你的车都能作出反应，这是因为ECU它是一直在工作的。既然ECU一直在工作，它就需要耗电呀，咱们车上就一个蓄电池（商用车是两个），如果你长时间不开车，车上的ECU一直在费电，时间长了，你的车是不是就启动不了了。
所以为了规避这个问题，整车厂都给常电供电的ECU都加入了网络管理的功能，比如OSEKNM或者是AutosarNM。做了网络管理的ECU，当整车下电到OFF档时，一段时间内没有操作车辆的话，所有这些ECU都会进入低功耗状态，此时每个ECU的电流非常小，几乎会小于2mA，整车静态功耗基本能控制在20mA左右，即使将车辆放置一个月，到时候也能正常启动，这就是网络管理的作用。
2. 状态机
OSEKNM分为3个主要状态，分别为Reset状态、Normal状态、Limphome状态。ECU刚上电时，处于Reset状态，当它其他ECU建立好逻辑环之后（OSEKNM的核心就是逻辑环），进入Normal状态状态，如果该ECU有故障或总线有故障，ECU进入Limphome状态。
2.1 逻辑环
直接网络管理（以下简称为NM）通过发送和接收两种类型的消息来建立逻辑环：Alive message和Ring message。其中，Alive message是一个节点要加入逻辑环时要发送的消息，Ring message是网络正常工作时的环消息，是从一个节点传递给下一个节点，依次在逻辑环中传递，以表示网络中的节点正常工作。当某一节点功能不正常时，就会周期性的向网络中发送LimpHome message。
Alive在100ms内随机相应，而Ring是以100ms的时间间隔发送的。
逻辑环的建立通过一种发送“令牌（Token）”的方式来进行，按标识符由小到大的顺序进行传递，最初发送Alive message的节点（或者标识符优先级高的节点）成为逻辑环中的第一个发送节点，消息都是以广播的方式发送的，这就使得每个节点发送的消息，其他节点都可以监测到，以确定自己是否为上一个发送节点的后继节点，并更新节点的运行状态等。
2.2 报文帧结构
NM报文帧的结构构成可分为三部分，即CAN ID、报文帧数据场第一个字节及第二个字节（以下简称data[0]和data[1]）
- OSEK网络管理报文CAN ID ：一般为4XX，其中XX就是设备的网络ID
- data[0]：在Alive状态时填充设备ID，但注意建环前表明身份还是靠监听CAN ID XX而不是Alive时的data[0]，在Ring状态时填充传递Token令牌的ID
- data[1]：表明当前节点状态，其各个位具体参数如下
-
- 0x01 Alive（上线）
- 0x02 Ring（建环）
- 0x04 LimpHome（跛足，网络无人响应无法建环）
- 0x10 SleepIndicatio（休眠申请）
- 0x20 SleepAcknowledege（应答申请）
- 以上命令可以组合比如建环中想申请休眠就是0x12
2.3 正常上线建环
在所有参与建环的ECU在建环初期，发出报文数据的第一字节都是自己的ID，第二字节都是0x01，即协议里讲的发出指向自身的Alive报文，每个ECU都发完Alive报文之后，就建立起来逻辑环了。
如下表所示，前三帧报文进行上线Alive，而在后三帧报文中，ECU 00指向了ECU 07，ECU 07指向了ECU 09，形成一个封闭的逻辑环，且第二字节都是Ring置1的Ring报文。
| CAN ID | Time interval | Frame |
| 400 | 0.000 | 00 01 00 00 00 00 00 00 |
| 407 | 0.012 | 07 01 00 00 00 00 00 00 |
| 409 | 0.019 | 09 01 00 00 00 00 00 00 |
| 400 | 0.069 | 07 02 00 00 00 00 00 00 |
| 407 | 0.100 | 09 02 00 00 00 00 00 00 |
| 409 | 0.100 | 00 02 00 00 00 00 00 00 |
2.4 跛行状态
在网络上只有一个NM节点的情况下，ECU上电后，先尝试建立逻辑环，尝试5次后，依旧无法建立逻辑环，则ECU进入LimpHome状态，ECU按TError（一般是1000ms）的周期发送LimpHome位置“1”的报文，从下表可以看出，LimpHome报文的第一字节指向自己，第二字节为0x04。
| CAN ID | Time interval | Frame |
| 4EE | 0.251 | EE 01 00 00 00 00 00 00 |
| 4EE | 0.100 | EE 02 00 00 00 00 00 00 |
| 4EE | 0250 | EE 01 00 00 00 00 00 00 |
| 4EE | 0.100 | EE 02 00 00 00 00 00 00 |
| 4EE | 0.250 | EE 01 00 00 00 00 00 00 |
| 4EE | 0.100 | EE 02 00 00 00 00 00 00 |
| 4EE | 0.250 | EE 01 00 00 00 00 00 00 |
| 4EE | 0.100 | EE 02 00 00 00 00 00 00 |
| 4EE | 0.250 | EE 01 00 00 00 00 00 00 |
| 4EE | 0.100 | EE 02 00 00 00 00 00 00 |
| 4EE | 1.000 | EE 04 00 00 00 00 00 00 |
| 4EE | 1.000 | EE 04 00 00 00 00 00 00 |
2.5 休眠状态
OSEK网络管理的休眠过程，当我们下到 OFF 档时，控制器满足了休眠条件，就会发出睡眠指示位 (Sleep.Ind) 置 1 的 Ring 报文，即的第二字节数据为 0x12 的报文，当所有节点都满足休眠条件，发出 0x12 的报文后，最后一个休眠节点的下一个节点，就会发出睡眠应答位 (Sleep.Ack) 置 1 的 Ring 报文。
- 当轮到自己发言0x12表明休眠申请后，只需处理3种状态：
- Token未到自己（即下轮发言未轮到自己）时监听到休眠应答（其他节点发22或32）则进入休眠等待（1.5s）
- Token未到自己时监听到有节点不想休眠发02，则退出休眠申请状态，轮到自己时重新发起
- Token到自己时监听并检查所有节点都发出过休眠申请，则自己发32广播集体休眠，进入休眠等待（1.5s）
- 发出0x32应答命令后1.5s内有任何报文，则退出休眠申请
下表展示了00、07、09节点的上线，再到建环，建环完成后，00节点发出0x12休眠申请，07节点也发出休眠申请，但09节点不想休眠，发出0x02Ring继续建环；这时00继续发送休眠申请，07发送休眠申请，09也准备好了并发送了休眠申请，00节点最后发出0x32命令广播进入休眠等待。
| CAN ID | Time interval | Frame |
| 400 | 0.000 | 00 01 00 00 00 00 00 00 |
| 407 | 0.012 | 07 01 00 00 00 00 00 00 |
| 409 | 0.019 | 09 01 00 00 00 00 00 00 |
| 400 | 0.069 | 07 02 00 00 00 00 00 00 |
| 407 | 0.100 | 09 02 00 00 00 00 00 00 |
| 409 | 0.100 | 00 02 00 00 00 00 00 00 |
| 400 | 0.100 | 07 12 00 00 00 00 00 00 |
| 407 | 0.100 | 09 12 00 00 00 00 00 00 |
| 409 | 0.100 | 00 02 00 00 00 00 00 00 |
| 400 | 0.100 | 07 12 00 00 00 00 00 00 |
| 407 | 0.100 | 09 12 00 00 00 00 00 00 |
| 409 | 0.100 | 00 12 00 00 00 00 00 00 |
| 400 | 0.100 | 07 32 00 00 00 00 00 00 |
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
