AUTOSAR中的Nm到底在干什么？为什么网络睡眠、网络唤醒全靠它？

作者昵称：CC持续攀登

3 次浏览

2026-7-8

编辑推荐:

文章主要解释了AUTOSAR中Nm（网络管理）的核心职责——它通过协调所有ECU的网络状态（唤醒、保持、睡眠），确保整车网络同步休眠和唤醒，并解释了网络睡不着、静态电流过高等问题的常见根源在于Nm状态机和Network Request管理，希望对你的学习有帮助。
本文来自于老司机的智驾工程笔记，由火龙果软件Alice编辑，推荐。

前言

你是否遇到过这样的情况？

整车已经锁车半小时，电流还是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是什么关系？

很多新人经常混淆。

实际上：

属于网络管理抽象层。

负责：

状态机管理
网络状态协调
通知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决定“整个网络什么时候醒、什么时候睡”。

3 次浏览