手把手教程：如何在DaVinci中配置AUTOSAR网络管理-洪萨配资

手把手教程：如何在DaVinci中配置AUTOSAR网络管理

从一个“睡不着”的ECU说起

你有没有遇到过这样的场景？某天调试车载CAN网络，发现某个节点始终无法进入睡眠模式，整车静态电流居高不下。用CANoe抓包一看——原来是TPMS模块一直在发NM报文，而它明明没有通信任务。

深入排查后才发现：不是硬件问题，也不是应用逻辑错误，而是AUTOSAR网络管理（Network Management, NM）参数配错了。

这正是现代汽车电子开发中的典型痛点：随着ECU数量激增，电源管理不再只是“上电运行、断电关机”那么简单。如何让几十个节点协同休眠与唤醒？谁来决定整个网络的“作息时间”？

答案就是：AUTOSAR网络管理 + DaVinci工具链。

本文将带你完整走一遍在Vector DaVinci Developer 和 Configurator Pro 中配置 CAN NM 的实战流程，不只是“点哪里”，更要讲清楚“为什么这么点”。最终目标是：让你不仅能成功配置，还能快速定位并解决诸如“假唤醒”、“丢状态”、“进不了睡眠”等工程难题。

AUTOSAR网络管理到底管什么？

它不是一个协议，而是一套协同机制

很多人初学时容易误解：AUTOSAR NM = 发心跳报文。
其实远不止如此。

它的本质是：一套去中心化的分布式状态同步系统，让所有ECU对“当前网络是否活跃”达成共识，并据此统一行动——该醒一起醒，该睡一起睡。

想象一下会议室里的灯控系统：
- 没人说话时，大家默认会议结束，灯自动关闭；
- 有人发言，哪怕只是咳嗽一声，灯就亮起，所有人知道“还在开会”。

AUTOSAR NM 就是这个“咳嗽检测器”+“灯光控制器”的组合体。

状态机才是灵魂：别再死记硬背三状态了！

官方文档常把NM状态分为三种大类，但真正驱动行为的是其五阶段子状态机：

Bus Sleep Mode ↑↓ Prepare Bus Sleep Mode ↑↓ Ready Sleep State → Normal Operation State ← Repeat Message State

我们来拆解每个状态的实际意义：

状态	实际作用	关键动作
Repeat Message State (RMS)	刚唤醒时快速广播“我上线了！”	高频发送NM报文（如50ms一次），确保邻居收到
Normal Operation State (NOS)	正常运行期	按常规周期发NM（如200–500ms）维持在线
Ready Sleep State (RSS)	“我要睡了，最后确认下还有没人要说话”	停止主动请求，等待超时退出
Prepare Bus Sleep (PBSM)	进入低功耗前的过渡态	关闭非必要外设，准备MCU睡眠
Bus Sleep Mode (BSM)	真正的深度睡眠	CAN控制器保持监听，仅响应唤醒帧

⚠️ 注意：只有处于Network Mode下的节点才会发送NM报文。一旦进入Prepare或Bus Sleep，就不再发任何数据。

NM报文长什么样？别被PDU搞晕了

一个典型的NM PDU（Protocol Data Unit）在CAN总线上表现为这样一帧消息：

字段	内容	说明
CAN ID	`0x6A0`	可配置，通常为11位标准帧
DLC	8	固定长度
Byte 0	Node ID (e.g.,`0x15`)	当前节点唯一标识
Byte 1	CBV (Control Bit Vector)	包含`Repeat Message Request`等标志位
Bytes 2–7	User Data (可选)	自定义信息，如诊断状态、模式标志

其中最关键的是CBV字段，它决定了状态迁移逻辑：

Bit 0: Repeat Message Request—— 是否需要持续发送NM
Bit 1: PDU with Data—— 是否携带有效用户数据
Bit 2: Reserved
Bit 3: NM Timeout Time Active—— 超时监控是否启用

比如当某个节点调用Nm_NetworkRequest()，底层会自动设置Repeat Message Request = 1，触发进入RMS。

参数怎么设？一张表说清所有关键值

很多工程师照搬模板参数，结果出现“唤醒慢”或“睡不着”。根本原因是对各定时器之间的依赖关系理解不清。

以下是必须掌握的核心参数及其工程含义：

参数名	含义	推荐范围	设计要点
`NmMsgCycleTime`	NM报文最小发送间隔	100–300 ms	应小于接收方`NmTimeoutTime`
`NmRepeatMessageTime`	RMS期间发送周期	200–500 ms	太短增加负载，太长影响同步
`NmReadySleepTime`	RSS持续时间	1000–2000 ms	必须大于最长业务通信耗时
`NmTimeoutTime`	接收超时判定离线	≥ 2.5 ×`NmMsgCycleTime`	过短易误判噪声为失效
`NmImmediateNmCycleTime`	唤醒初期快速发送周期	20–50 ms	加速网络恢复，但最多发几次

📌黄金法则：
NmTimeoutTime > NmMsgCycleTime × 2
否则会导致节点频繁误判“邻居掉线”，反复重启NM流程。

举个例子：若你的NmMsgCycleTime=200ms，那么NmTimeoutTime至少应设为500ms以上，建议取600ms。

工具链实操：DaVinci Developer 建模全过程

第一步：画出系统的“骨架”

DaVinci Developer 是做系统级建模的地方。你可以把它看作是“画电路图”的阶段——还没写代码，先定义好谁和谁通信、用什么协议。

典型操作流程：

创建 System Description（.arxml文件）
添加两个ECU实例：
-BodyControlModule
-InfotainmentUnit
在 Communication 视图中添加NM Cluster
选择协议类型为CanNm
将上述ECU加入该Cluster成员列表
绑定到具体的 CAN Cluster（比如 CAN1）

✅ 这一步完成后，你就完成了：
- 定义了哪些ECU参与网络管理
- 明确了使用哪种NM协议（CanNm / FrNm / EthNm）
- 建立了物理网络与逻辑集群的映射

⚠️ 特别提醒：如果你有多个供电域（如仪表常电、车门受钥匙控制），可以创建多个NM Cluster，实现分区唤醒。

DaVinci Configurator Pro：CanNm模块精调指南

现在进入真正的“拧螺丝”环节 —— BSW（基础软件）配置。

DaVinci Configurator Pro 会读取你在Developer中生成的.arxml文件，然后让你逐项填充每个模块的具体参数。

Step 1：导入系统描述

打开 DaVinci Configurator Pro
导入由 Developer 导出的 ARXML 文件
工具自动识别出 NM Cluster 和关联 ECU

👉 此时你会看到类似这样的提示：“Detected 1 CanNm Channel on ECU ‘BCM’”

Step 2：实例化 CanNm 模块

在 Module Configuration 页面中找到CanNm模块，点击“Add Instance”。

你需要为每一个参与NM的CAN通道创建一个实例。例如：

CanNmInstance_0 → 对应 CanController0（即 CAN1）

然后绑定以下资源：
- 所属 ECU
- 使用的 CAN Controller
- 对应的 PduId（来自 PduR 配置）

Step 3：配置NM报文属性

这是最容易出错的一环！务必保证以下三项一致：

项目	配置位置
CAN ID (`0x6A0`)	CanNmChannel → CanNmPduId
DLC = 8	CanNmChannel → CanNmPduDlc
PduId映射	必须与 PduR 模块中的定义完全匹配

❌ 常见坑点：PduR里忘了把NM PDU路由到CanIf，导致报文发不出去。

✅ 解决方法：打开 PduR 配置页面，检查是否存在如下映射路径：

Nm → PduR → CanIf → CanDrv

Step 4：节点地址与用户数据设置

每个节点必须有一个唯一的Node Identifier（1字节，范围0x01–0x3F）。

.CanNmNodeIdentifier = 0x15,

这个ID会在NM报文的第一个字节发出，用于识别来源。

此外，你可以选择是否启用用户数据传输：

.CanNmUserDataEnabled = TRUE; .CanNmUserDatumPosition = 1; // 用户数据从第2个字节开始 .CanNmUserDataLength = 6; // 占用6个字节

应用场景举例：
- Byte 2: 当前诊断会话状态
- Byte 3: 是否允许睡眠
- Byte 4: 整车模式（ACC/ON/OFF）

这些信息可在其他节点通过回调函数获取，实现更智能的协同决策。

Step 5：状态机参数落地（ARXML示例）

<CanNmInstance> <CanNmRepeatMessageTime>300</CanNmRepeatMessageTime> <CanNmReadySleepTime>1500</CanNmReadySleepTime> <CanNmMsgCycleTime>200</CanNmMsgCycleTime> <CanNmTimeoutTime>600</CanNmTimeoutTime> <CanNmImmediateNmCycleTime>40</CanNmImmediateNmCycleTime> <CanNmMainFunctionPeriod>20</CanNmMainFunctionPeriod> </CanNmInstance>

注意：CanNmMainFunctionPeriod是指CanNm_MainFunction()被调用的周期，通常由操作系统任务调度决定，建议设为10–20ms。

代码层面发生了什么？

虽然大部分代码由工具自动生成，但了解底层结构有助于调试。

自动生成的配置结构体（C语言）

const CanNm_ChannelConfigType CanNm_ConfigRoot[] = { { .CanNmChannelId = 0, .CanNmPduId = 0x6A0, .CanNmPduDlc = 8, .CanNmNodeIdentifier = 0x15, .CanNmCbvPosition = 0xFF, // 不使用额外CBV偏移 .CanNmUserDatumPosition = 1, .CanNmUserDataLength = 6, .CanNmImmediateNmTransmissions = 3, // 唤醒时连发3次快NM .CanNmRepeatMessageTime = 300u, .CanNmReadySleepTime = 1500u, .CanNmMsgCycleTime = 200u, .CanNmTimeoutTime = 600u, .CanNmMainFunctionPeriod = 20u, } };

💡 关键点解释：
-.CanNmImmediateNmTransmissions = 3表示刚唤醒时连续以40ms间隔发送3次NM报文，加速网络同步。
- 主函数周期越短，状态机响应越及时，但CPU占用略升。

应用层如何请求网络接入？

当你想让某个ECU唤醒网络时，只需调用标准API：

void App_RequestNetwork(void) { Std_ReturnType ret; ret = Nm_NetworkRequest(&Nm_ConfigRoot[0]); if (E_OK != ret) { ErrorHandler(); } }

常见触发条件包括：
- 收到外部中断（如车门开关信号）
- 定时器到期（如胎压定时上报）
- UDS诊断请求到来

对应地，在完成任务后记得释放：

Nm_NetworkRelease(&Nm_ConfigRoot[0]);

否则系统永远不会进入睡眠！

实战案例：为什么我的节点“睡不着”？

场景还原

某车身控制模块（BCM）总是无法进入 Bus Sleep Mode，电流比预期高出2mA。

用CANoe监测发现：每隔约1.8秒，就会收到一次来自 BCM 的 NM 报文。

排查思路四步法

✅ Step 1：查应用层是否未释放

检查是否有Nm_NetworkRequest()调用了但没配对Nm_NetworkRelease()。

→ 查日志发现：LIN通信完成后忘记释放网络。

✅ 修复：补上Nm_NetworkRelease()。

✅ Step 2：查是否有外部干扰

即使本节点没请求，也可能因监听到别人发的NM而维持在线。

→ 用CANoe过滤只看 NM 报文（ID=0x6A0），发现确实有另一个节点（T-Box）每2秒发一次NM。

→ 继续查T-Box代码，发现其设置了周期性诊断心跳，且未开启“无业务时不发NM”策略。

✅ 优化：调整T-Box的NmReadySleepTime至3s，并确保诊断任务结束后立即释放。

✅ Step 3：查硬件唤醒能力

某些MCU支持“CAN总线唤醒”，但需手动使能引脚功能。

→ 查阅S32K144手册，确认CAN_RX引脚需配置为“Wake-up by CAN Frame”。

→ 查代码发现未调用EcuM_SetWakeupEvent()注册唤醒源。

✅ 修复：添加唤醒事件注册。

✅ Step 4：查主函数是否被正确调度

CanNm依赖定期调用CanNm_MainFunction()来推进状态机。

→ 检查OsTask配置，发现该函数未Hook到任何任务中。

✅ 修复：将其添加到10ms周期的任务回调中。

高阶设计建议：不只是“能跑通”

1. 节点地址分配策略

建议按重要性排序分配 Node ID：

范围	用途
`0x01–0x10`	关键节点（BCM、Gateway）
`0x11–0x20`	功能节点（AC、TPMS）
`0x21–0x3F`	临时/调试节点

好处：避免后期扩展时冲突；关键节点优先响应。

2. 冷启动行为要一致

首次上电时，所有节点应默认进入Repeat Message State，防止错过初始同步。

配置项：

.CanNmPassiveModeEnabled = FALSE; // 主动模式，允许发送NM

除非你是纯监听节点（如仪表盘），才启用 Passive Start-Up。

3. 诊断兼容性处理

在网络睡眠期间，仍需响应 UDS 唤醒（如$10切换会话）。

解决方案：
- 配置BswM模块监听EcuM_WakeUpReason
- 当检测到 CAN 唤醒帧时，触发Nm_NetworkRequest()
- 结合 Dem / Dcm 模块实现安全唤醒路径

4. 不要复用 NM PDU 做别的事！

曾有团队为了省一个CAN ID，把普通信号塞进NM报文Payload。

后果：CanNm模块误解析为“用户数据变更”，导致状态机跳转异常。

🚫 绝对禁止：
- 在NM报文中传输非NM相关数据
- 手动修改CBV字段
- 绕过Nm API 直接发NM帧

总结：你真的掌握了网络管理吗？

当你能回答以下问题时，才算真正吃透了AUTOSAR NM：

为什么设置了NmReadySleepTime=1500ms，实际退到睡眠却花了2.1秒？
→ 因为还要加上最后一次NM报文发送延迟 + 接收超时判断。
两个节点同时唤醒，会不会抢资源？
→ 不会。NM是去中心化的，谁先发都行，大家都会跟着同步。
能不能不让某个节点参与NM？
→ 可以。设为 Passive Mode 或不加入NM Cluster。
NM报文能不能走CAN FD？
→ 可以！AUTOSAR 4.3+ 支持 CanNm over CAN FD，只需配置DLC>8即可。

掌握这套技能的价值远不止于“会点工具”。它是你构建低功耗、高可靠车载网络系统的基石。

未来即便转向 Ethernet NM 或 SOME/IP，其核心思想——状态协同、资源共管、去中心化决策——依然适用。

所以，下次再遇到“ECU睡不着”的问题，别急着换硬件，先看看是不是NM配置出了问题。

如果你在项目中遇到特殊的网络管理挑战，欢迎留言交流，我们一起拆解真实案例。

手把手教程：如何在DaVinci中配置AUTOSAR网络管理