3. AUTOSAR网络管理（NM）核心原理：状态机与PDU结构
好，咱们今天来啃一块硬骨头——AUTOSAR网络管理的核心状态机。说实话，很多工程师做了好几年网关开发，对NM的理解还停留在“发报文、收报文”的层面。但你要真去调一个网络唤醒的bug，或者排查一个节点睡不死的故障，不懂状态机细节，那真是寸步难行。
我个人习惯把NM状态机看作一个“三室一厅”的结构。三个卧室就是三种模式，客厅就是状态切换的走廊。咱们一个一个来看。
3.1 三大模式：Network Mode / Prepare Bus-Sleep Mode / Bus-Sleep Mode
AUTOSAR NM把节点的工作状态切成了三大块。你想想看，一个ECU在车上，要么在干活（网络模式），要么准备睡觉（预休眠模式），要么已经睡了（休眠模式）。就这么简单。
| 模式 | 英文名称 | 核心行为 | 报文收发 |
|---|---|---|---|
| 网络模式 | Network Mode | 主动发送NM报文，保持总线通信 | 正常收发 |
| 预休眠模式 | Prepare Bus-Sleep Mode | 停止发送NM报文，等待超时 | 只收不发 |
| 休眠模式 | Bus-Sleep Mode | 总线静默，等待唤醒事件 | 完全静默 |
3.1.1 Network Mode（网络模式）
这是节点最活跃的状态。在这个模式下，ECU会周期性地发送NM PDU，告诉总线上其他节点“我还活着，还在干活”。
网络模式内部其实还分了两个子状态：
- Repeat Message State：刚唤醒或刚进入网络模式时，会快速连续发几轮NM报文，让其他节点尽快感知到自己的存在。我记得有个项目，客户抱怨网关唤醒后CAN总线老是丢第一帧报文，查到最后就是Repeat Message阶段的发送间隔配置得太短，总线负载瞬间冲高了。
- Normal Operation State：稳定工作状态，按正常周期（比如100ms）发送NM报文。
3.1.2 Prepare Bus-Sleep Mode（预休眠模式）
这个模式很有意思。节点明明想睡觉了，但还得再等一会儿。为什么？
说白了，就是给其他节点一个缓冲时间。你这边突然不发了，其他节点可能还在等你报文。如果直接睡过去，对方可能误判你出故障了。
预休眠模式的核心规则：
- 停止发送任何NM报文
- 仍然可以接收NM报文
- 如果收到其他节点的NM报文，立即跳回网络模式
- 等待一个固定的超时时间（NM-Timeout），超时后进入休眠模式
3.1.3 Bus-Sleep Mode（休眠模式）
节点彻底睡了。总线收发器进入低功耗模式，不发送任何报文，也不主动接收报文。但注意，这里有个关键点——唤醒源。
休眠模式下，节点必须能响应以下唤醒事件：
- 总线活动唤醒（比如CAN总线上出现显性电平）
- 本地唤醒（比如KL15点火信号、按键触发）
- 网络管理唤醒（收到特定的NM报文）
一旦检测到唤醒事件，节点就从Bus-Sleep Mode直接跳回Network Mode，重新开始发送NM报文。
3.2 NM状态机完整流转图
下面这张图，是我每次讲课都会画的。你把它记在脑子里，NM调试就成功了一半。
3.3 NM PDU结构
聊完状态机，咱们看看NM报文到底长什么样。AUTOSAR NM PDU的结构其实挺简洁的，但每个字段都有它的设计意图。
3.3.1 标准NM PDU格式
一个标准的AUTOSAR NM PDU，长度固定为8字节（CAN）或可变长度（CAN FD）。
| 字节偏移 | 字段名称 | 长度 | 说明 |
|---|---|---|---|
| 0 | Source Node Identifier | 1字节 | 发送节点的ID，用于标识报文来源 |
| 1 | Control Bit Vector | 1字节 | 控制位向量，包含NM标志位 |
| 2-7 | User Data | 6字节 | 用户自定义数据，可携带应用信息 |
Control Bit Vector这个字节，是NM报文的灵魂。它里面每一位都有特定含义：
- Bit 0 (NM-PDU-Request)：请求位。置1表示本节点请求保持网络活动。
- Bit 1 (NM-PDU-Acknowledge)：确认位。置1表示本节点确认收到请求。
- Bit 2 (NM-PDU-Wake-Up)：唤醒位。置1表示本节点刚被唤醒。
- Bit 3-7：保留位，留给OEM自定义使用。
3.3.2 我在项目中遇到的PDU问题
有一次，客户反馈网关在休眠后无法被远程唤醒。我们抓了总线日志，发现远程唤醒报文确实发出来了，但网关就是没反应。
查到最后，问题出在Control Bit Vector上。远程节点发的NM报文，Wake-Up位没有置1。网关的NM模块判断这不是一个有效的唤醒请求，直接忽略了。你想想看，就一个bit没置对，整个功能就废了。
所以我的建议是：调试NM问题时，第一步就是拿CAN工具抓报文，逐字节解析Control Bit Vector。别上来就怀疑硬件、怀疑驱动，很多时候就是软件配置或者报文格式的问题。
3.4 状态机与PDU的联动关系
状态机和PDU不是孤立的。它们之间的联动，才是NM工作的精髓。
| 状态 | PDU发送行为 | PDU接收行为 | 典型场景 |
|---|---|---|---|
| Network Mode | 周期发送，Control Bit Vector置位 | 正常接收，解析所有字段 | 车辆行驶中，所有ECU都在线 |
| Prepare Bus-Sleep | 停止发送 | 只接收，不响应 | 车辆熄火后，ECU准备休眠 |
| Bus-Sleep | 不发送 | 仅检测唤醒事件 | 车辆停放，ECU深度休眠 |
这里有个容易忽略的点：在Prepare Bus-Sleep模式下，节点虽然不发送NM报文，但它仍然在监听总线。一旦收到任何其他节点的NM报文（无论Control Bit Vector是什么值），它都会认为总线上还有活跃节点，然后跳回Network Mode。
嗯，这就是为什么我之前说预休眠超时时间不能太短。你刚进预休眠，隔壁节点发了一帧NM报文，你又得回去。如果这个节奏反复出现，节点永远睡不了。
3.5 小结
这一章的内容，说白了就是三件事：
- NM状态机有三个模式：Network、Prepare Bus-Sleep、Bus-Sleep。每个模式有明确的进入条件和行为。
- NM PDU由Source Node ID、Control Bit Vector和User Data组成。Control Bit Vector是控制信令的核心。
- 状态机和PDU是联动的。收到NM报文会触发状态回迁，停止发送会触发状态下沉。