前言
你是否遇到过这样的情况？
- 整车已经锁车半小时，电流还是300mA以上；
- ECU明明已经进入Ready Sleep，却迟迟睡不下去；
- 某个节点掉线后，全车网络状态异常；
- 网络刚进入睡眠，又莫名其妙被唤醒；
- ComM已经释放通信请求，但总线还是活跃状态；
最后排查半天发现：
问题根本不在ComM，也不在CanSM，而是在Nm。
在AUTOSAR网络管理体系中：
CanSM负责管理CAN控制器；
ComM负责管理通信权限；
而真正负责：
“网络什么时候醒、什么时候睡、谁通知大家一起睡”
的核心模块，就是Nm（Network Management）。
今天带大家彻底搞懂：
- Nm到底是什么
- Nm和CanNm是什么关系
- 网络为什么不能直接睡眠
- Network Request是什么
- Repeat Message State有什么用
- 为什么有的ECU永远睡不着
-
先理解一个问题
汽车为什么需要网络管理？
假设车上有：
- BCM
- TCU
- Gateway
- ADAS
- 仪表
共20多个ECU。
如果每个ECU都自行决定：
我要睡了
那么会出现：
ECU A已经睡眠
ECU B还在发报文
ECU C认为网络还活跃
整个网络状态将彻底混乱。
因此AUTOSAR设计了一套统一机制：
Network Management
简称：
Nm
它负责协调所有ECU：
什么时候工作
什么时候休眠
什么时候唤醒
可以简单理解：
ComM负责：
我要不要通信
Nm负责：
整个网络是否还活着
CanNm负责：
通过NM报文通知大家
-
Nm和CanNm是什么关系？
很多新人经常混淆。
实际上：
Nm
属于网络管理抽象层。
负责：
- 状态机管理
- 网络状态协调
- 通知ComM
CanNm
属于CAN网络管理实现。
负责：
- 发送NM报文
- 接收NM报文
- 维护超时计时器
关系如下：
Nm
│
├── CanNm
├── UdpNm
└── FrNm
不同总线使用不同实现。
CAN网络最常见：
CanNm
-
网络为什么不能直接睡眠？
很多人会想：
既然没有通信需求了，
为什么不直接：
Normal Operation
↓
Bus Sleep
？
原因很简单：
必须保证所有节点同步。
如果有一个ECU还在工作：
网络就不能睡。
因此AUTOSAR设计了多个过渡状态。
这就是经典的CanNm状态机。
Repeat Message State到底干什么？
这是很多面试必问。
网络刚被唤醒时：
所有ECU并不知道：
还有哪些节点在线
因此唤醒后：
进入：
Repeat Message State
在该状态：
周期发送NM报文。
作用：
告诉所有节点：
我醒了！
例如：
BCM发送NM
Gateway收到
ADAS收到
仪表收到
大家重新建立网络关系。
这就是解锁车辆时：
全车ECU被逐步唤醒的过程。
Normal Operation是什么？
这是正常工作状态。
特点：
✅ 周期发送NM报文
✅ 接收NM报文
✅ 正常通信
✅ ComM Full Communication
例如：
点火ON
车辆行驶
诊断进行中
通常都处于：
Normal Operation
Ready Sleep State是什么？
假设：
应用层释放通信请求。
ComM告诉Nm：
我不需要网络了
此时：
不能直接睡眠。
因为可能还有其他ECU需要通信。
于是进入：
Ready Sleep
含义：
我准备睡觉
但先观察一下
此时仍然监听NM报文。
Prepare Bus Sleep是什么？
如果Ready Sleep期间：
持续没有收到网络请求。
说明：
大家都准备睡了
进入：
Prepare Bus Sleep
开始关闭各种资源。
例如：
- 停止周期通信
- 关闭部分外设
- 保存运行数据
准备进入最终睡眠。
很多OEM会在这里增加各种超时配置。
Bus Sleep是什么？
最终休眠状态。
特点：
不发送NM
不发送业务报文
控制器停止
最低功耗
此时：
网络功耗最低。
也是整车锁车后的目标状态。
-
什么是Network Request？
这是理解Nm最关键的概念。
可以理解成：
谁还需要网络？
例如：
ADAS需要上传数据
TCU需要联网
UDS正在刷写
都会产生：
Network Request
只要存在请求：
网络必须保持唤醒。
-
为什么有的ECU永远睡不着？
这是项目里最常见的问题。
也是整车静态电流超标的主要原因。
原因1
Network Request没有释放
例如：
ComM一直保持Full
导致：
Nm一直认为有人需要网络
原因2
NM报文持续发送
例如配置错误：
NmMessageCycleTime
异常。
导致网络一直活跃。
原因3
诊断会话未退出
典型场景：
Programming Session
持续保持：
Network Request
原因4
OEM特殊策略
例如：
锁车后保持5分钟网络
用于OTA升级。
这时属于正常现象。
一句话记住：
ComM决定：
要不要通信
Nm决定：
网络是否活着
CanSM决定：
CAN怎么工作
-
项目调试经验
如果网络睡不着。
推荐排查顺序：
ComM User Request
↓
ComM State
↓
Nm State
↓
CanNm State
↓
NM报文
↓
CanSM
不要一上来就抓总线。
先看：
Nm当前状态
往往几分钟就能定位问题。
总结
Nm是AUTOSAR网络管理体系的核心。
它负责协调所有ECU：
- 网络唤醒
- 网络保持
- 网络睡眠
并通过CanNm报文让整个网络达成一致。
很多项目里的：
- ECU睡不着
- 静态电流超标
- 网络频繁唤醒
- 网络状态异常
最终根因都能追溯到Nm状态机和Network Request管理。
🚗 一句话总结：
ComM决定“我要不要通信”，CanSM决定“CAN怎么工作”，而Nm决定“整个网络什么时候醒、什么时候睡”。
👉下期预告
《AUTOSAR中的CanNm到底在干什么？NM报文里到底藏着什么秘密？》
带你彻底搞懂：
- NM PDU格式
- Control Bit Vector
- Repeat Message Request
- Node Detection
- Remote Sleep Indication
- 为什么一个NM报文就能唤醒整个网络
