CanNm 配置与主动唤醒、被动唤醒全链路开发指南

我先联网检索 CanNm 配置与主动 / 被动唤醒的最新多信源资料，并核对相关技能要求。

我再核对一下本地是否存在购物清单相关技能，并补充检索 CanNm 关键配置参数与唤醒时序细节。

CanNm 的配置核心，就是先把节点在总线上的身份、报文节奏、超时定时器、快发策略和唤醒位开关一组组对齐，再沿着 "唤醒源 → EcuM/ComM → Nm → CanNm → CanIf → 收发器" 这条链路把主动唤醒和被动唤醒两条路径分别打通。主动唤醒是本节点内部有需求（点火、硬线、传感器、应用请求等），由上层主动请求网络，进入重复报文状态时会快速连发 NM 帧，并在 CBV 里把 Active Wakeup Bit 置 1，明确声明 "是我叫醒的网络"；被动唤醒是本节点本来在睡眠，总线上先来了其他 ECU 的 NM 报文，节点收到后被拉起参与网络，只做参与者，不置主动唤醒位，也不走快发突发。两条路径最后落到同一个 CanNm 状态机里，差异主要集中在入口 API、首帧发送时机、是否带主动唤醒位、以及有没有持续的本地网络请求这四件事上。开发时先确认本项目属于本地唤醒、网络唤醒还是本地加网络唤醒的节点类型，再把同一 NM 集群内各节点的超时类参数配成一致，最后按主动、被动两条链路逐条核对接口调用、定时器和报文位定义，就能把唤醒全链路跑通。

一、先搞清楚 CanNm 在链路里处于什么位置

CanNm 是 CAN 总线上的 BSW 模块，向上对接网络管理接口 Nm（再往上是 ComM、EcuM、BswM 和应用层），向下对接 CanIf，再往下是 CAN 收发器（CanTrcv）。它采用分布式直接网络管理策略：每个节点只根据自己收到和发出的 NM PDU 来决定状态，通过周期性广播 NM 报文，告诉集群里其他节点 "我还需要保持网络"。

上层（应用、BswM、ComM）通过网络请求 / 释放接口来要求或放弃总线通信。
CanNm 维护一套状态机，协调网络从正常运行到总线睡眠的过渡，保证集群内节点尽量同睡同醒。
收发器负责硬件层面的唤醒监测：普通收发器对总线电平或任意报文敏感，支持特定帧唤醒的收发器（如带 PNC / 特定帧过滤的型号）只在收到匹配 NM 帧时才唤醒 MCU。

二、CanNm 状态机与两条唤醒路径的落点

CanNm 对外有三个工作模式：总线睡眠模式（Bus-Sleep Mode）、网络模式（Network Mode）、准备总线睡眠模式（Prepare Bus-Sleep Mode）。网络模式内部又分三个子状态：重复报文状态（Repeat Message State, RMS）、正常运行状态（Normal Operation State, NOS）、准备睡眠状态（Ready Sleep State, RSS）。

状态 / 模式	行为要点	发送 NM 报文	接收 NM 报文
Bus-Sleep Mode	低功耗睡眠，只保留唤醒监测	否	否（靠收发器监测）
Prepare Bus-Sleep Mode	清空发送队列、做下电准备，等待静默期结束	否	是
Repeat Message State	上线宣告期，保证新上线节点被其他节点发现	是	是
Normal Operation State	本地持续请求网络，周期发送 NM 维持集群活跃	是	是
Ready Sleep State	已释放网络，停发 NM，继续监听他人报文	否	是

无论主动还是被动，从 Bus-Sleep 或 Prepare Bus-Sleep 进入网络模式时，默认先进入 RMS；RMS 超时后，仍有本地请求就进 NOS，没有本地请求就进 RSS；RSS 超时后进 Prepare Bus-Sleep，再经过 Wait Bus Sleep 静默期回到 Bus-Sleep。

三、主动唤醒全链路怎么配、怎么走

3.1 触发条件

主动唤醒的唤醒源来自节点自身内部，常见包括 KL15 硬线、本地传感器、RTC 定时唤醒、按钮操作，或者应用层 / BswM 明确提出的通信需求。这类唤醒对应上层的主动网络请求。

3.2 软件调用链路

本地唤醒源动作触发，SBC / 收发器上电唤醒 MCU，EcuM 通过唤醒事件通知上层。
ComM 把对应通道置为全通信模式，形成主动请求（Active Request）。
Nm 接口向下调用 CanNm_NetworkRequest（对应 Nm_NetworkRequest），建立持续存在的网络请求。
CanNm 从 Bus-Sleep 或 Prepare Bus-Sleep 进入 RMS：
若使能了主动唤醒位开关，在 CBV 的 Active Wakeup Bit（bit4）置 1，离开网络模式时清零。
按配置先进入快发子状态：用 ImmediateNmCycleTime 周期连发 ImmediateNmTransmissions 次 NM 帧，让网络尽快被叫醒。
首帧可以被压到尽量早发送，必要时配合 CanIf 的报文调度 / 过滤配置，保证 NM 帧优先上总线。
快发次数用完后，恢复正常 MsgCycleTime 周期；RMS 超时后本地仍持有请求，进入 NOS 持续周期发送，不断重置本节点和邻居的超时定时器。
通信需求结束后调用 CanNm_NetworkRelease 释放网络，依次进入 RSS、Prepare Bus-Sleep、Bus-Sleep。

3.3 主动路径关键配置

配置参数	作用	配置关注点
CanNmNodeId	本节点在集群内的唯一源标识	与 NM 报文 Byte0、通信矩阵一致
CanNmActiveWakeupBitEnabled	是否在主动唤醒帧中置 Active Wakeup Bit	需要追踪 "谁叫醒网络" 时打开
CanNmImmediateNmTransmissions	RMS 阶段快发 NM 帧的次数	次数过多会增加总线负载，按唤醒速度要求定
CanNmImmediateNmCycleTime	快发阶段 NM 帧周期	明显短于正常周期，用于快速宣告上线
CanNmMsgCycleTime	NOS/RMS 正常阶段 NM 报文周期	集群内各节点保持一致量级
CanNmMsgCycleOffset	首帧 NM 的延迟偏移，错开多节点同时突发	主动路径一般取 0 或很小，被动路径用来分摊负载
CanNmRepeatMessageTime	RMS 停留时长	保证最小活跃时间和节点可被发现
CanNmTimeoutTime	NM 静默超时阈值	与集群内其他节点对齐，需覆盖足够多的 NM 周期
CanNmWaitBusSleepTime	Prepare Bus-Sleep 静默时长	给队列清空和下电留足时间

四、被动唤醒全链路怎么配、怎么走

4.1 触发条件

被动唤醒的唤醒源来自外部网络：节点处于睡眠时，收发器监测到总线报文（特定帧或任意帧，取决于收发器能力），MCU 被唤醒，随后在总线上收到其他节点发出的 NM PDU。节点本身并没有先提出通信需求。

4.2 软件调用链路

收发器监测到总线活动并唤醒 MCU，CanTrcv/CanIf 把唤醒事件上报。
CanNm_RxIndication 收到其他节点的 NM PDU，重启超时定时器。
通过 Nm_NetworkStartIndication 通知 ComM 网络有启动迹象，由 ComM 判断是否参与。
调用 CanNm_PassiveStartUp（对应 Nm_PassiveStartUp）进入 RMS；该接口在网络模式下重复调用会被拒绝并返回错误。
被动路径不建立本地网络请求：
不置 Active Wakeup Bit，报文语义是 "参与者" 而不是 "唤醒源"。
不设置 Immediate 快发计数，首帧按配置的 MsgCycleOffset 延迟后排队发送，期间应用报文可能先于本节点 NM 帧发出。
RMS 超时后，如果始终没有本地请求，进入 RSS；RSS 收不到新的 NM 报文、超时后进入 Prepare Bus-Sleep，最终回到 Bus-Sleep。

4.3 被动路径需要特别注意的配置

CanNmPassiveModeEnabled：配置为被动模式的节点只接收 NM PDU、不周期发送，不能主动发起集群启动，只能被其他节点叫醒；同一 ECU 的所有网络上该配置需要统一，避免行为不一致。
CanNmMsgCycleOffset：被动节点用它错开首帧时刻，避免多个被同时唤醒的节点在同一瞬间爆发发送。
超时参数与主动节点保持一致：被动节点要靠监听他人 NM 报文来推迟睡眠，TimeoutTime 过短会导致还没等邻居报文到达就提前睡回。
收发器特定帧过滤：若启用特定帧唤醒，要在收发器侧配好匹配的 NM ID 和数据过滤，避免被无关应用报文反复吵醒；不支持特定帧过滤时，节点会出现 "睡醒交替" 的现象，需要在软件侧做唤醒可靠性检查，检查失败就不进入网络模式。

五、主动唤醒与被动唤醒逐项对比

对比维度	主动唤醒（NetworkRequest）	被动唤醒（PassiveStartUp）
唤醒来源	本地内部需求：硬线、传感器、定时、应用请求	外部网络：总线收到其他 ECU 的 NM 报文
入口接口	CanNm_NetworkRequest / Nm_NetworkRequest	CanNm_PassiveStartUp / Nm_PassiveStartUp
是否建立持续网络请求	是，请求持有期间一直维持网络	否，只是参与当前网络
Active Wakeup Bit	使能开关打开时置 1	不置位
快发 Immediate 突发	使用 ImmediateNmTransmissions + ImmediateNmCycleTime	不进入快发突发
首帧 NM 时机	尽量早，可成为苏醒后最早的帧之一	按 MsgCycleOffset 延迟后发送
RMS 之后走向	有请求 → NOS 持续保持	无请求 → RSS，等待超时睡回
典型语义	"我叫醒了网络，我需要一直在线"	"网络已经醒了，我先参与一下"

需要强调一点：不能用 "苏醒后第一帧是 NM 还是应用帧" 来反推主动还是被动。两条路径都会进 RMS、都会发 NM 帧，首帧先后是仲裁、偏移配置和报文调度共同作用的结果；真正可靠的判据是看 NM 帧 Byte0 的源节点号和 Byte1 CBV 里的 Active Wakeup Bit。

六、配置落地步骤与核对清单

6.1 配置步骤

梳理节点类型：仅本地唤醒、仅网络唤醒、本地加网络唤醒，还是 KL15 类供电唤醒，确定硬件唤醒源和收发器能力。
分配集群与节点：确认本节点属于哪个 NM 集群、CanNmNodeId、NM PDU 的 ID、长度和 CBV 位置。
标定时间参数：按总线负载、唤醒速度和睡眠功耗要求，依次定 MsgCycleTime、MsgCycleOffset、RepeatMessageTime、TimeoutTime、WaitBusSleepTime、ImmediateNmCycleTime、ImmediateNmTransmissions。
开关功能位：按项目需要使能主动唤醒位、被动模式、总线负载降低、部分网络（PN）、用户数据、节点检测等特性。
对齐集群参数：同一集群内所有节点的超时类参数必须一致，避免有的节点过早睡眠、有的节点被意外挂住。
联调验证：抓总线 NM 帧，核对源节点号、CBV 各位、快发帧数、周期偏移，以及主动 / 被动两条链路的状态跳转和睡眠时序。

6.2 上线前核对清单

本节点主动唤醒时，NM 帧 Active Wakeup Bit 是否按预期置位并在退出网络模式后清零。
被动唤醒时，节点是否只走 PassiveStartUp，没有遗留 Immediate 计数或主动请求状态。
首帧偏移在多节点同时被唤醒时是否会造成总线突发。
TimeoutTime 是否留足时钟偏差余量，通常要能覆盖多个正常 NM 周期，避免健康网络里被误判超时。
被动模式节点是否在所有网络上配置一致，是否存在本该只听不发的节点在周期发送 NM。
收发器唤醒过滤与 CanNm 的 PNC / 特定帧配置是否匹配，静态电流和误唤醒是否达标。
诊断场景下 DisableCommunication / EnableCommunication 之后，NM 发送与恢复逻辑是否正确。

七、常见定位思路

想确认 "谁叫醒了网络"：解析 NM PDU，Byte0 看源节点号，Byte1 看 Active Wakeup Bit，而不是看总线上谁的帧先出现。
节点醒了又很快睡回：查它是否只走了被动启动、没有本地网络请求，RMS 超时后是否直接进了 RSS；再核对 TimeoutTime 是否过短。
本该发送 NM 的节点却超时：故障往往在上游，检查它的 NM PDU 是否根本没送到 CanIf，导致超时定时器得不到重置。
多个节点同时上线造成总线冲击：调大 MsgCycleOffset 做节点间错开，或评估总线负载降低策略。

整体来看，CanNm 配置并不是单独拧几个定时器，而是把节点身份、报文节奏、唤醒位和状态机策略绑定在一起；主动唤醒链路要解决 "快速宣告并持续保持"，被动唤醒链路要解决 "被拉起参与但不越权叫醒"，两条链路在配置和接口上对齐之后，再配合收发器唤醒策略和整车通信矩阵验证，全链路的唤醒与睡眠行为才是确定、可追溯的。

【相关 FAQ】

问题 1：CanNm 主动唤醒和被动唤醒在软件入口上怎么区分？

回答 1：CanNm 主动唤醒走 CanNm_NetworkRequest（上层对应 Nm_NetworkRequest），由本地需求建立持续网络请求；CanNm 被动唤醒走 CanNm_PassiveStartUp，是收到总线 NM PDU 后经 NetworkStartIndication 由 ComM 判断参与。区分时不要看首帧是谁，而要看入口接口、是否持有本地请求，以及 NM 帧里 Active Wakeup Bit 是否置位。

问题 2：CanNm 被动唤醒时，为什么第一帧 NM 不是立刻发出去？

回答 2：被动唤醒路径不设置 Immediate 快发计数，首帧按配置的 CanNmMsgCycleOffset 延迟后排队发送，目的是错开多个被同时唤醒节点的发送时刻、分摊总线负载；而 CanNm 主动唤醒路径会把首帧尽量提前，必要时进入快发突发。被动节点在偏移期内应用报文可能先于本节点 NM 帧发出，这属于配置和时序产物，不代表被动判断出错。

问题 3：CanNm 的 Active Wakeup Bit 在主动唤醒时什么时候置位、什么时候清零？

回答 3：当 CanNmActiveWakeupBitEnabled 打开，且节点由网络请求从 Bus-Sleep 或 Prepare Bus-Sleep 进入网络模式时，CanNm 会在 CBV 的 Active Wakeup Bit 置 1，表示本节点主动叫醒了网络；离开网络模式后该位清零。被动唤醒调用 PassiveStartUp 不置该位，报文只表示本节点是参与者。

问题 4：CanNm 配成被动模式（Passive Mode）以后，还能不能主动唤醒整个网络？

回答 4：不能。CanNmPassiveModeEnabled 打开后，节点只接收 NM PDU、不周期发送，无法主动发起集群启动，只能在其他节点先唤醒网络后被带入；要注意同一 ECU 所有网络上的被动模式配置需要保持一致。需要主动叫醒网络的节点不能配成纯被动模式。

问题 5：CanNm 超时参数配得太小，主动唤醒和被动唤醒节点受到的影响一样吗？

回答 5：影响不完全一样。超时参数过小，被动节点更容易因为还没等到邻居 NM 报文就超时，提前回到睡眠；主动节点在持有请求、周期发送 NM 期间超时定时器会被发送动作重置，通常不会在活跃期被误超时，但若上游报文根本没送到 CanIf，同样会出现异常超时。TimeoutTime 需要覆盖足够多的 NM 周期以容忍各节点时钟偏差，且集群内参数要统一。

【参考资料】

[2026-11-13]（主动唤醒与被动唤醒：CanNm 的分界不在第一帧）CSDN 博客

[2026-06-13]（Autosar 网络管理笔记：被动唤醒和主动请求时 Nm 报文发送的差异）CSDN 博客

[2025-12-30]（AUTOSAR CanNm 详解：CAN 网络管理模块的完整指南）火龙果 UML

[2024-11-27]（Specification of CAN Network Management R24-11）AUTOSAR

[2024-08-29]（从整车层级到零部件层级的网络管理开发）火龙果 UML

[2024-08-25]（Autosar 通信入门系列 07：CanNM 状态机切换详解）CSDN 博客

[2024-05-16]（AUTOSAR 基础之 Can Network Management）牛喀网

[2022-05-11]（AUTOSAR 和 OSEK 关系及网络管理比较）电子工程专辑

【免责声明】

本文基于公开的 AUTOSAR 规范与公开技术资料整理，仅用于技术学习和开发参考。文中涉及的参数名称、取值、CBV 位定义和接口行为，可能随 AUTOSAR 版本、BSW 厂商实现和项目配置不同而存在差异；实际开发请以项目所用 BSW 版本的 SWS 文档、生成代码头文件、通信矩阵及原厂规范为准。文中示例时序和数值用于说明机制，不代表任何量产项目的既定结论，也不构成对唤醒成功率、功耗或总线负载的保证，因直接照搬本文内容导致的开发问题需由项目团队自行验证并承担相应责任。

本文来自作者[硅域巡守]投稿，不代表环球科技潮立场，如若转载，请注明出处：https://www.zennew.com/kjyw/202611/1341.html