一文讲懂Autosar网络管理

一、引言

随着汽车电子架构向智能化、网联化演进，整车 ECU 数量从几十增长到上百，CAN、LIN、Ethernet 等总线交织成复杂网络。如何协调多节点通信、实现"按需唤醒、及时休眠"以降低静态功耗、保障网络可靠性？AUTOSAR 网络管理（Network Management，NM）正是解决这些问题的核心技术。

本文将从核心概念、状态机原理、报文机制、架构分层到工程实践，系统性地讲透 AUTOSAR NM，帮助你建立完整的技术认知。

二、AUTOSAR 网络管理是什么？

2.1 本质：去中心化的网络协调协议

AUTOSAR NM 是一套标准化的、去中心化的（peer-to-peer）网络协调协议。它通过统一的 NM 消息和状态机，管理总线上各 ECU 的网络状态（唤醒 / 通信 / 休眠），确保：

• 需要通信时：相关节点快速唤醒，总线正常传输
• 无需通信时：所有节点集体休眠，静态电流降至 μA 级
• 出现故障时：及时检测并记录，避免单节点异常拖累整个网络

2.2 与传统私有网络管理的区别

2.3 核心术语

三、NM 状态机：核心中的核心

AUTOSAR NM 状态机是整个协议的灵魂。它以CAN NM为典型（Ethernet UdpNm 类似），包含以下状态：

3.1 状态总览

唤醒事件 │ ▼ ┌──────────────┐ ┌─────────────────────────────────────────┐ │ │ │ Network Mode │ │ Bus-Sleep │────→│ │ │ Mode │ │ ┌─────────────────┐ │ │ │ │ │ Repeat Message │ │ │ (总线休眠) │ │ │ State │ │ │ │ │ └────────┬────────┘ │ └──────────────┘ │ │ 超时/收到NM消息 │ ▲ │ ▼ │ │ │ ┌─────────────────┐ │ │ │ │ Normal Operation│ │ │ │ │ State │ │ │ │ └────────┬────────┘ │ │ │ │ 所有节点释放网络请求 │ │ │ ▼ │ │ │ ┌─────────────────┐ │ │ │ │ Ready Sleep │ │ │ │ │ State │ │ │ │ └────────┬────────┘ │ │ └───────────┼─────────────────────────────┘ │ │ NmTimeoutTime 超时 │ ▼ │ ┌─────────────────────┐ │ │ Prepare Bus-Sleep │ │ │ Mode │ │ │ (等待WaitBusSleepTime)│ │ └──────────┬──────────┘ │ │ NmWaitBusSleepTime 超时 └────────────────────────┘

3.2 各状态详解

① Bus-Sleep Mode（总线休眠）

• 含义：总线处于低功耗状态，无通信活动。
• ECU 行为：仅保留唤醒检测功能（如 CAN Transceiver 的 Wake-up 检测），应用层停止运行，电流降至 μA 级。
• 退出条件：检测到唤醒事件（本地或远程）。

② Network Mode — Repeat Message State（重复消息状态）

• 含义：节点刚被唤醒，需要立即告知网络"我已上线"。
• ECU 行为：
  • 发送 NM 消息，不带Sleep Indication Bit（即 CBV bit0 = 0）
  • 无论自身是否有通信需求，都先发送若干 NM 消息
• 退出条件：经过NmRepeatMessageTime超时，或收到其他节点的 NM 消息后转入 Normal Operation State。
• 设计意图：确保唤醒事件能快速传播到整个网络，让所有节点知晓。

③ Network Mode — Normal Operation State（正常操作状态）

• 含义：节点正常工作，根据是否有网络请求决定是否发送 NM 消息。
• ECU 行为：
  • 持有网络请求时（应用层调用了Nm_NetworkRequest()）：周期性发送 NM 消息（周期 =NmMsgCycleTime，如 100ms），CBV bit0 = 0（未准备好休眠）
  • 无网络请求时：转入 Ready Sleep State
• 退出条件：应用层调用Nm_NetworkRelease()释放网络请求。

④ Network Mode — Ready Sleep State（准备休眠状态）

• 含义：该节点已无通信需求，准备好进入休眠。
• ECU 行为：
  • 发送带Sleep Indication Bit = 1的 NM 消息（告知其他节点"我准备好了"）
  • 或停止发送 NM 消息（取决于 OEM 配置）
  • 继续监听总线上的 NM 消息
• 退出条件：
  • 若收到其他节点的非 Sleep Indication NM 消息（说明有节点重新请求网络）→ 回到 Normal Operation State
  • 若NmTimeoutTime超时且未收到任何 NM 消息 → 进入 Prepare Bus-Sleep Mode

⑤ Prepare Bus-Sleep Mode（准备总线休眠）

• 含义：所有节点均已释放网络请求，总线即将进入休眠。
• ECU 行为：
  • 停止发送 NM 消息
  • 等待NmWaitBusSleepTime（确保总线上最后一个 NM 消息传输完毕）
  • 若在此期间收到任何 NM 消息或唤醒事件 → 回到 Network Mode
• 退出条件：NmWaitBusSleepTime超时 → 进入 Bus-Sleep Mode。

3.3 关键理解：去中心化 + 超时驱动

⚠️核心要点：AUTOSAR NM 是完全去中心化的。没有"主节点"或"牵头 ECU"。每个节点独立运行同一套状态机，通过超时机制和Sleep Indication Bit实现集体同步休眠。

睡眠流程的本质：

1. 所有节点的应用层完成各自任务 2. 各节点依次调用 Nm_NetworkRelease() 3. 各节点进入 Ready Sleep State 4. 总线上不再有非 Sleep Indication 的 NM 消息 5. 各节点的 NmTimeoutTime 超时 → 集体进入 Prepare Bus-Sleep 6. NmWaitBusSleepTime 超时 → 集体进入 Bus-Sleep

没有"请求-确认"握手，没有"牵头 ECU"，没有"确认休眠帧"。

四、NM 报文（NM PDU）格式

4.1 CAN NM PDU 结构

CAN NM 消息通常为 8 字节（经典 CAN）或最长 64 字节（CAN FD）：

┌──────────┬──────────┬────────────────────────────────┐ │ Byte 0 │ Byte 1 │ Byte 2 ~ Byte 7 │ │ Source ID│ CBV │ User Data (可选) │ └──────────┴──────────┴────────────────────────────────┘

4.2 CBV 关键位

4.3 NM 消息 ID

• NM 消息的 CAN ID 由 OEM 在通信矩阵（DBC/ARXML）中定义
• 没有固定范围限制，可以是任何合法 CAN ID
• 通常 OEM 会规划一段连续 ID 用于 NM（如 0x500~0x5FF），但这不是协议要求

4.4 Ethernet NM（UdpNm）

Ethernet 网络使用UdpNm模块，NM 消息封装在UDP 报文中：

• 目的地址：NM 多播地址（如 224.0.0.x）
• 端口：OEM 定义的 UDP 端口
• Payload：与 CAN NM 类似的 Source ID + CBV + User Data 结构
• 支持 Partial Networking 唤醒

⚠️注意：DoIP（ISO 13400）是诊断协议，与网络管理无关，不要混淆。

五、关键配置参数

📌 这些参数通过 AUTOSAR 工具链（如 Vector DaVinci Configurator、EB tresos）在 ARXML 中配置，不在 DBC 文件中。

六、AUTOSAR 软件架构中的 NM

6.1 分层架构

┌─────────────────────────────────────────────────────────┐ │ 应用层 (ASW / SWC) │ │ 决定何时需要/释放网络（如：用户按下解锁键 → 请求网络） │ └───────────────────────────┬─────────────────────────────┘ │ RTE 接口 ▼ ┌─────────────────────────────────────────────────────────┐ │ RTE (Runtime Environment) │ │ 标准化接口隔离（如 Rte_Call_Xx_Nm_NetworkRequest()） │ └───────────────────────────┬─────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────┐ │ BSW - Services Layer │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Nm (Generic NM) — 通用 NM 接口层 │ │ │ └─────────────────────────────────────────────────┘ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ CanNm / UdpNm / LinNm — 总线特定 NM 实现 │ │ │ └─────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ BSW - ECU Abstraction Layer │ │ ┌─────────────────────────────────────────────────┐ │ │ │ CanIf (CAN Interface) / EthIf │ │ │ └─────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ BSW - MCAL (Microcontroller Abstraction) │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Can Driver / Eth Driver │ │ │ └─────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────┤ │ Hardware │ │ CAN Transceiver / Ethernet PHY / LIN Transceiver │ └─────────────────────────────────────────────────────────┘

6.2 NM 消息发送路径

Nm Module → PduR (PDU Router) → CanIf → Can Driver → Can Transceiver → 物理总线

NM 模块不直接调用 CAN Driver，中间经过 PduR 路由和 CanIf 抽象层。

6.3 NM 核心 API

6.4 与其他 BSW 模块的交互

七、典型工作流程

7.1 唤醒流程

[用户按下遥控解锁键] │ ▼ BCM 检测到本地唤醒源（GPIO 中断） │ ▼ BCM 的 EcuM 从 Bus-Sleep 唤醒 → 初始化 BSW → NM 进入 Repeat Message State │ ▼ BCM 发送 NM 消息（Sleep Indication Bit = 0） │ ▼ 总线上的其他 ECU（仪表、PEPS等）通过 CAN Transceiver 检测到总线活动 │ ▼ 各 ECU 被远程唤醒 → 各自 NM 进入 Repeat Message State │ ▼ 需要通信的节点调用 Nm_NetworkRequest()，进入 Normal Operation State 不需要通信的节点不请求网络，直接进入 Ready Sleep State

7.2 休眠流程

[车辆熄火，所有应用任务完成] │ ▼ 各 SWC 依次调用 Nm_NetworkRelease()（如仪表保存完数据、ESP 完成自检） │ ▼ 各节点进入 Ready Sleep State，NM 消息中 Sleep Indication Bit = 1 （或停止发送 NM 消息） │ ▼ 总线上不再有 Sleep Indication Bit = 0 的 NM 消息 │ ▼ 各节点的 NmTimeoutTime 超时 │ ▼ 所有节点进入 Prepare Bus-Sleep Mode │ ▼ NmWaitBusSleepTime 超时（确保最后一个 NM 消息传输完毕） │ ▼ 所有节点进入 Bus-Sleep Mode │ ▼ EcuM 执行 ECU 关电（关闭不需要保持的电源域） CAN Transceiver 进入 Standby 模式（仅保留唤醒检测） │ ▼ 静态电流降至 μA 级 ✅

7.3 通信故障检测

正常情况： ECU_A 每 100ms 发送 NM 消息 → ECU_B 的 NM 模块持续收到 异常情况（ECU_A 突然掉电）： ECU_B 超过 NmTimeoutTime（如 500ms）未收到 ECU_A 的 NM 消息 │ ▼ Nm 模块上报 Bus Error Event → 通知 DEM │ ▼ DEM 记录对应 DTC（如 U0100: Lost Communication with ECM） │ ▼ 应用层根据 DTC 执行降级策略

⚠️注意：NM 的超时检测能发现"节点停止发送 NM 消息"，但不处理物理层故障（如 CAN_H/CAN_L 短路）。物理层故障由 CAN 控制器的硬件错误检测机制（Bus-Off）处理。

八、不同总线的 NM 差异

LIN NM 的特殊性

LIN 网络是主从结构，NM 机制与 CAN 有本质不同：

• Master 节点负责轮询和网络状态管理
• Slave 节点不主动发送 NM 消息，仅响应 Master 的调度
• 睡眠由 Master 发送特定的诊断帧（0x3C）触发
• 不适用 CAN NM 的对等状态机

九、工程实践：设计与配置

9.1 需求分析

9.2 参数配置（以 Vector DaVinci 为例）

NmGeneral: NmMsgCycleTime = 100 ms NmTimeoutTime = 1000 ms NmRepeatMessageTime = 500 ms NmWaitBusSleepTime = 3000 ms NmMsgCycleOffset = 20 ms (避免多节点同时发送) NmChannel: NmChannelId = 0 NmBusType = CAN NmNode: NmNodeId = 5 (本节点 Source ID) NmPduId = NmPdu_BCM NmPduCbvPosition = 1 (CBV 在 Byte 1) NmPduLength = 8

9.3 集成要点

9.4 测试验证

十、常见问题与避坑指南

10.1 无法进入 Bus-Sleep（最常见）

原因：某个 SWC 调用了Nm_NetworkRequest()但忘记Nm_NetworkRelease()。

排查：

• 通过Nm_GetState()或诊断服务读取 NM 状态
• 检查是否仍处于 Normal Operation State
• 使用 CANoe 观察 NM 消息的 Sleep Indication Bit 是否为 0

10.2 休眠后被意外唤醒

原因：

• CAN 总线上有残余报文（如某个 ECU 未完全休眠）
• Transceiver 灵敏度设置过高，电磁干扰触发误唤醒
• 唤醒引脚悬空导致误触发

10.3 多总线协调问题

场景：ECU 同时连接 CAN 和 Ethernet，CAN 侧已准备休眠但 Ethernet 侧仍有通信需求。

解决：使用Nm Coordination（NmSync）模块，确保所有通道同步进入/退出休眠。

10.4 Partial Networking 注意事项

Partial Networking（部分网络唤醒）允许 ECU 在总线上有非目标报文时保持休眠，仅响应特定唤醒帧：

• 需要 CAN Transceiver 硬件支持（如 TJA1145、TCAN1044）
• NM 模块需配置唤醒帧过滤器
• 需确保唤醒帧 ID 不与正常应用报文冲突

十一、安全与网络安全

11.1 功能安全（ISO 26262）

• NM 模块通常要求达到ASIL B级别
• 关键要求：NM 超时检测必须在安全时间内完成，避免通信故障导致功能丧失
• 需进行 FMEA 分析：如"NM 模块卡死在 Normal Operation State 导致无法休眠"

11.2 网络安全（ISO/SAE 21434）

⚠️注意：实际工程中通常使用SecOC（MAC 认证）而非对 NM 帧整体加密。NM PDU 仅 8 字节且不含敏感用户数据，认证（确保来源合法）比加密更合适。

十二、未来趋势

12.1 多总线融合管理

中央计算架构下，域控制器同时管理 CAN / LIN / Ethernet 子网。NM Coordination 模块将承担更复杂的跨总线同步职责，实现"一次唤醒，多域协同；一次休眠，全域静默"。

12.2 智能化动态策略

• 根据用户习惯预测唤醒需求（如每天 8:00 用车，7:55 预唤醒座舱 ECU）
• 根据车辆状态动态调整 NM 消息周期（高速行驶缩短周期提高检测速度，停车后延长周期降低总线负载）

12.3 以太网 TSN + NM 融合

Time-Sensitive Networking（TSN）为 Ethernet 提供确定性通信保障。未来 UdpNm 可能与 TSN 调度机制深度结合，实现更精确的网络状态管理和唤醒时序控制。

12.4 整车级电源管理与 NM 联动

NM 状态将与整车电源管理（Power Management）更紧密耦合：

• NM 进入 Bus-Sleep → 触发 ECU 电源域关断
• 部分 ECU 支持"NM 休眠但保持部分功能"（如防盗模块保持射频监听）

十三、总结

AUTOSAR NM 不是"单一模块"，而是一套从协议规范到软件实现到整车集成的完整体系。理解状态机的每一步转换、掌握超时参数的配置逻辑、避开工程实践中的常见陷阱，才能真正驾驭整车网络管理。

📚参考资料：

• AUTOSAR SWS_CANNM（CAN Network Management）
• AUTOSAR SWS_UDPNM（UDP Network Management）
• AUTOSAR SWS_LINNM（LIN Network Management）
• AUTOSAR SWS_NM (Generic NM Interface)
• AUTOSAR SWS_EcuM（ECU State Manager）
• ISO 11898（CAN 物理层）/ ISO 13400（DoIP，仅诊断参考）
• Vector AUTOSAR Network Management 技术白皮书

如果这篇文章对你有帮助，欢迎点赞、收藏、转发！有具体的 NM 配置问题或调试经验，欢迎在评论区交流讨论。🚗🔧