简介：《OSEK NM 253.pdf》是一份面向汽车电子软件工程师、AUTOSAR基础软件开发者及网络管理模块测试人员的权威规范文档，内容为OSEK/VDX网络管理概念与应用编程接口2.5.3版。文档系统阐述直接网络管理机制，包括节点监控、地址分配、数据交换基础设施、配置管理及网络故障检测与恢复等核心内容，有助于读者理解NM状态机、逻辑环通信和API调用逻辑，为开发符合AUTOSAR标准的NM模块提供直接参考。压缩包内仅含1个PDF文件，大小664KB，方便离线查阅与快速定位章节。目前已有542人学习下载，尤其适合正在研究AUTOSAR NM协议、需要对照原始标准排查实现细节的工程师。
1. 网络管理在车载 ECU 网络里的位置，远不止“活着”这么简单
在车载总线上，ECU 的“在线”和“被网络认为在线”是两件不同的事。OSEK/VDX NM 2.5.3 这份规范之所以至今仍被提及，主要是因为 AUTOSAR 的 CAN 网络管理（CAN NM）在架构上完全没有绕过它：AUTOSAR NM 的直接网络管理策略、NM 报文格式设计、节点监控与逻辑环思想，几乎都能在 OSEK NM 这套 2004 年的文档里找到原型。换句话说，理解了 OSEK NM Concept & API 2.5.3，再去看 AUTOSAR NM，等于手里有了底层的设计逻辑。
这套标准解决的核心问题有三个：节点如何互相感知存活（node monitoring）、整个网络何时可以集体休眠（operating mode management）、以及节点间如何交换少量网络管理数据（NM infrastructure for data exchange）。它提供了两种互相独立的监控机制——直接网络管理（Direct NM）和间接网络管理（Indirect NM）。Direct NM 靠专用的 NM 报文、用令牌在逻辑环上传，网络状态判定快但协议开销明显；Indirect NM 干脆不发明文，直接拿应用报文“活着”当作证据，实现简单但对应用层报文依赖极重。
这篇内容适合正在做 AUTOSAR NM 集成、在做 CAN 总线节点唤醒/休眠策略、或者在读 Vector/ETAS 生成的 NM 相关代码的人。它会把这个 PDF 里最核心的机制、算法和 API 拆开讲清楚，并把那些文档里没有明说的工程边界补出来：参数怎么配、状态机怎么跳、哪些环节最容易车规测试不过。
2. Direct NM 的逻辑环与令牌轮询：为什么它比“广播心跳”更“车规”
2.1 逻辑环不是物理环，是地址排序后的轮询链
Direct NM 的核心设计是逻辑环（logical ring）。物理拓扑可能是总线，但每个 NM 节点在配置阶段被分配一个静态的节点 ID（Node ID），所有 ID 按取模顺序排成一个环。每个节点只关心两件事：它的逻辑后继（logical successor）是谁，以及当前令牌应该轮到谁。
节点用令牌（Token）来声明自己“活着”。拿到令牌的节点有资格向外发送 NMPDU（Network Management Protocol Data Unit），发送完成后再把令牌传递给逻辑后继节点。这个过程在总线上的表现是：每个节点周期性发送 NM 报文，报文里包含源节点 ID 和目的节点 ID（目标通常是逻辑后继）。如果某个节点连续多次没有收到来自其前驱节点的报文，它会认定这个前驱已经失联，并将其从环上注销，同时把环上的地址窗口压缩，让后继节点接管该节点的槽位。
令牌传递和 OSEK 报文格式强相关。规范中定义了三种报文类型：Alive 报文（节点启动后立即广播，声明自己加入环）、Ring 报文（正常循环时的令牌传递载体）、LimpHome 报文（节点进入跛行模式时发送）。三种报文使用相同的 NMPDU 结构，通过报文中的 OpCode 区分类型。
下面是一个典型的 Direct NM 报文数据域结构，按 2.5.3 规范中的定义：
typedef struct { uint8_t OpCode; /* 0x01: Alive, 0x02: Ring, 0x03: LimpHome */ uint8_t NodeID; /* 本节点在环中的唯一 ID */ uint8_t LogicalRing; /* 环编号，多环网络中使用 */ uint8_t Data[8]; /* NM Data Field，应用层数据交换 */ } NMPDU_DirectNM;OpCode 区分了报文类型；NodeID 告诉接收方“这是谁发的”；LogicalRing 支持节点同时接入多个逻辑环；Data 字段直接对应到 API 中的Nm_SetData()/Nm_GetData()操作，最多 8 字节（CAN 场景）。这套字段排布与 AUTOSAR NM PDU 的设计几乎对应，AUTOSAR 只是把 OpCode 换成了 CBV（Control Bit Vector），把逻辑环的转移规则改成了按 ID 取模推进，基础思想高度一致。
2.2 令牌维护与节点失联判断：重复报文和超时参数的博弈
Direct NM 的节点失联判定依赖“连续收不到前驱的 Ring 报文”这个事实，实现上由收发计数器和 T_NM 定时器共同驱动。具体参数在规范 2.2.5 和 2.2.6 的例子里给出了计算逻辑：每个节点维护一个NMRepeatMessage计数器，每当发送一次 Ring 报文，该计数加一；每次收到逻辑前驱发来的 Ring 报文，则把计数清零。当计数达到配置的最大值NMImmediateNMTimeout（通常配置为总线发送周期乘以一个裕量系数），节点就判定前驱失联。
代码层面的处理逻辑一般长这样：
void NM_TimerExpired(void) { if (NMRepeatMessage >= NMImmediateNMTimeout) { /* 前驱连续超时，从逻辑环中移除前驱 */ NMRemoveFromRing(Nm_PredecessorNodeID); /* 更新本地环视图 */ NmLocalRingView &= ~(1 << Nm_PredecessorNodeID); /* 转发令牌给新的后继 */ NMPassToken(Nm_SuccessorNodeID); } else { NMRepeatMessage++; /* 重新发送相同 NMPDU，用于补偿总线上丢失的帧 */ NMSendNMPDU(Nm_PredecessorNodeID, Nm_SuccessorNodeID); } }这段代码先判断超时是否累计到阈值；超时则更新环视图并传递令牌；未超时则重发前驱的报文，这个重发机制解决的是 CAN 总线偶发丢帧导致的误判。NMImmediateNMTimeout的取值直接影响网络收敛速度：设太大会让节点失联后迟迟无法被发现，休眠流程拖着；设太小则总线瞬态错误就会被判定为节点掉线，导致环的频繁重构。工程上一般把NMImmediateNMTimeout设为 CAN 报文基本周期（如 100 ms）的 3~5 倍，具体值需要根据总线负载率和节点的睡眠策略做实测调整。
2.3 配置管理：环形视图的本地副本与全网一致性
每个节点内部维护一个环形视图（Ring View），用于记录它眼中哪些节点还在环上。规范把视图维护定义为 Config Management 的一个子功能。节点启动时通过 Alive 报文宣告加入环，环上所有节点收到 Alive 后把自己的环形位置也广播出去，最终每个节点都会在与环上节点信息交互后完全建立自己的逻辑环。
一致性靠 NM 数据回读来校验：节点发送 Ring 报文时，如果在收到对方报文后的规定时间窗内没有收到响应，则立刻做“环重构”操作。规范规定这个时间窗为 2 个NMImmediateNMTimeout周期。工程上，每收到一个 NMPDU 都要对报文的NodeID做合法性检查，检查失败时直接丢弃并且不参与环视图更新，避免非法节点地址把视图污染。
这种“每个节点都维护一份全网络的拓扑状态”的做法看起来笨重，但它的价值在于：任何一个节点的失联消息不需要全网广播，节点通过本地就能推导出整个网络的存活情况。这正是 Direct NM 能在超大规模总线网络中保持低广播开销的原因。
3. Indirect NM：不发专门报文，用应用消息当心跳
3.1 间接监控的原理：消息到了，节点就活着
Indirect NM 的思想非常简单：如果应用层正在周期性地发送报文，那就意味着发送该报文的节点是活的，不需要再设计单独的 NM 报文。这种监控方式完全借用了 OSEK COM 的周期性发送能力，NM 层只用监听“哪些报文过来了、哪些报文超时了”这两个事件。
节点侧需要配置一张“监控表”，表里记录了它需要监控的远程节点 ID 和与这个节点关联的报文集合。每当对应的报文通过 COM 层上抛到 NM 层时，NM 内部就把该节点的“最近活跃时间”刷新。
typedef struct { uint8_t RemoteNodeID; uint32_t MonitorMessageIDs[8]; uint16_t NMTimeoutMs; /* 该节点允许的最大静默时间 */ uint16_t NMTimeoutCounter; /* 当前累计的静默时间 */ } IndirectMonitorEntry; void NM_IndirectMonitor_OnMsgRx(uint32_t CanID) { for (uint8_t i = 0; i < Nm_MonitoredNodeCount; i++) { for (uint8_t j = 0; j < 8; j++) { if (MonitorTable[i].MonitorMessageIDs[j] == CanID) { MonitorTable[i].NMTimeoutCounter = 0; return; } } } }收到报文后首先遍历监控表；报文 ID 匹配成功则清零该节点的静默计数器；匹配失败则说明是无关报文，直接返回。这个设计的核心是监控粒度的选择：是监控每个节点所有报文，还是只监控每个节点的某类周期报文。对低功耗场景，一般只监控节点进入正常运行态后发出的周期性应用报文，因为这类报文在休眠状态下会停止发送，正好可以作为网络休眠的触发信号。
3.2 超时判定与时间窗配置：静默不等于掉线，掉线不等于睡眠
Indirect NM 的超时判定要考虑总线负载的波动。规范中把监控超时分为两个级别：NMMonitorTimeout用来判定某个节点是否失联；NMReducedMonitorTimeout则用于网络进入低功耗预备阶段的快速检测。
在算法上，间接 NM 的超时处理更简单：
void NM_IndirectMonitor_TimerTick(uint16_t tickMs) { for (uint8_t i = 0; i < Nm_MonitoredNodeCount; i++) { MonitorTable[i].NMTimeoutCounter += tickMs; if (MonitorTable[i].NMTimeoutCounter >= MonitorTable[i].NMTimeoutMs) { NM_ReportNodeFailure(MonitorTable[i].RemoteNodeID); MonitorTable[i].NMTimeoutCounter = 0; } } }每次 tick 都累加静默时间；某个节点超过阈值就上报节点故障。真正要小心的是：Indirect NM 中“某个节点没有发消息”和“某个节点请求休眠”是两种不同的事件。在 OSEK 的定义里，节点进入休眠前必须发送一个应用层的“准备休眠”标志（一般通过某一位或者专门的报文体现），如果节点没有发这个标志就直接静默，那才能判定为异常。所以间接监控表里应该把「报文是否周期发送」和「休眠请求标志位是否置位」分开记录，前者用于存活判定，后者用于休眠协调。
3.3 Direct 与 Indirect 的适用边界：什么时候选哪个
两种方法不是互斥的。Direct NM 适合对网络状态感知延迟敏感的场合，例如底盘域需要快速判断制动节点的在线状态；Indirect NM 适合总线负载率高或应用本身已经具备高频率周期报文的场合，例如动力总成域报文数量大、CAN 利用率高。
工程上一个常见策略是：动力域用 Indirect，底盘和车身域用 Direct，这样把总线负载和实时性的矛盾分开处理。如果整车对休眠电流有严格指标要求，Indirect NM 往往是更好的选择，因为节点在休眠时可以直接把收发器关掉，NM 层不依赖额外的唤醒帧来维持网络状态——所有状态都由应用报文描述，报文停了网络就静默了。
使用中的典型差异如下表：
| 比较项 | Direct NM | Indirect NM |
|---|---|---|
| 专用 NM 报文 | 需要，有额外总线负载 | 不需要，零额外负载 |
| 失联判定速度 | 快，由令牌环超时控制 | 慢，与应用报文周期强相关 |
| 启动与建环 | 需要专门的 Alive 流程 | 无建环过程 |
| 低功耗适配 | 需要特殊处理唤醒/休眠帧 | 天然适配，应用报文停止即可 |
| 典型应用域 | 底盘、车身 | 动力总成、ADAS |
| 实现复杂度 | 较高，涉及环维护 | 较低，只需监控表 |
选型时还要考虑 EcuM（ECU 状态管理）与 NM 的交互方式。AUTOSAR 中，NM 提供Nm_NetworkRequest()和Nm_NetworkRelease()给上层；OSEK 时代这样的接口也存在于第 4 章的 API 描述中。如果上层策略要支持多网络同时管理，Direct NM 更容易实现网络级的状态一致性，因为它的报文本身就携带环信息，便于判断“整个网络都空了”和“我这个节点外面全掉了”的区别。
4. NM 服务的 API 调用链：从系统生成到运行时的三个关键接口
4.1 System Generation 阶段的配置数据生成
OSEK NM 规范的第 4 章详细描述了系统生成（System Generation）相关的服务，这一套在 AUTOSAR 里对应的是 NmStack 的配置工具生成流程。概念上没有任何差别：开发阶段把网络节点数、每个节点的 Node ID、监控粒度、定时参数填进配置工具，工具生成Nm_Cfg.h和Nm_Cfg.c，编译时与 NM 算法代码静态链接。
一个最小化配置表的示例：
/* Nm_Cfg.h */ #define NM_NODE_ID (0x10u) #define NM_LOGICAL_RING (0x01u) #define NM_TPDU_CYCLE_MS (100u) #define NM_IMMEDIATE_TIMEOUT (300u) #define NM_REPEAT_MESSAGE_MAX (3u) #define NM_USE_DIRECT_NM (1u) #define NM_USE_INDIRECT_NM (0u)这里NM_TPDU_CYCLE_MS是 Ring 报文的基本发送周期，NM_IMMEDIATE_TIMEOUT是前驱超时阈值，NM_REPEAT_MESSAGE_MAX控制重发次数。这个配置文件是后续所有 API 调用的前提，Nm_Init会直接读取这些宏来初始化内部状态机。
4.2 Nm_Init 与网络请求/释放
Nm_Init()是 NM 层被 EcuM 调用的第一个函数，它负责初始化所有内部计数器和定时器。在实际项目中，Nm_Init()往往会从 Non-Volatile Memory 中读取上次的休眠模式（如果硬件 RTC 支持的话），以决定节点启动后是直接进入网络运行态、还是需要等待总线上的第一个唤醒帧。
Nm_NetworkRequest()和Nm_NetworkRelease()是整个 NM 行为的主入口。调用Nm_NetworkRequest()意味着本节点要主动参与网络通信；调用Nm_NetworkRelease()则代表本节点准备退出网络。以 Direct NM 为例，Nm_NetworkRelease()调用后，节点会停止发送 Ring 报文，但会保留一段时间监听总线上其他节点的报文，用来感知是否所有节点都释放了网络。
void App_DriveCycle_Start(void) { Nm_NetworkRequest(NM_CHANNEL_CAN0); /* NM 层开始广播 Alive 报文并建立逻辑环 */ } void App_KeyOff_Shutdown(void) { Nm_NetworkRelease(NM_CHANNEL_CAN0); /* NM 层停止 Ring 报文，等待其他节点也释放后整车进入睡眠 */ }4.3 数据交互接口：Set/Get 与 NM 数据字段
第 4.5.3 节定义了 Data Field Management 相关的服务。对很多不了解 OSEK NM 细节的人来说，最容易忽略的一点是：数据字段在 NM 报文里是周期性携带的，但 Set 操作并不立即触发一次报文发送。数据字段只在下一个周期报文发送时带上。所以如果应用要做快速数据交换，不能依赖 NM 数据字段，应该走 COM 的信号交互。
uint8_t wakeupReason = 0x01; Nm_SetData(NM_CHANNEL_CAN0, 0x00, &wakeupReason, 1); /* 只是写入本地缓冲，等到下一个 Ring 周期才会被封装进 NMPDU */Nm_GetData()则是把从 NMPDU 里解出来的数据拷贝给上层应用。使用时要注意：Nm_GetData()的返回值是“数据长度”，如果上层传入的 buffer 过小，函数会返回一个负值错误。规范里定义了NOK和OK的错误码，实际实现里还可以看到NM_E_INVALID_CHANNEL这样的扩展错误码。
4.4 状态回调函数：被动等待模式切换
上层订阅 NM 的事件，通过一组回调函数完成。最核心的是这三个：
Nm_BusSleepIndication()：网络即将睡眠，指示应用保存易失数据并停掉通信。Nm_NetworkMode()：网络已进入正常运行模式，应用可以开始全功能通信。Nm_PrepareBusSleepMode()：进入了可睡眠的准备模式，EcuM 在收到该回调后开始执行下电时序。
void Nm_BusSleepIndication(uint8_t channel) { /* 保存当前驾驶模式状态到 NVM */ App_StoreCurrentState_ToNvm(); /* 关闭非必要外设 */ App_PowerDownPeripherals(); }三条回调在时序上是分先后的：先是Nm_NetworkMode()，通知节点可以“说”了；然后总线静默，节点进入准备睡眠；最后Nm_BusSleepIndication()，通知节点可以“睡”了。工程调试时经常出现应用只实现了前两个回调、漏了最后一个，导致车子休眠后电流超标，原因是 ECU 的通信收发器永远没有进入 sleep 模式。
5. 集成排障与验证技巧：用示波器式思维看 NM 报文流
5.1 把 NM 报文按逻辑环推演画出来，比单看 Canoe Trace 更有效
做 OSEK NM 和 AUTOSAR NM 的调试，第一件事不是打开 Canoe 的 Trace 窗口，而是先在纸上把当前网络拓扑和逻辑环画出来：节点 ID 顺序、每个节点的前驱和后继、每个节点一次 Ring 发送后应该触发谁的回答。Trace 窗口只能告诉你报文发没发，画图才能告诉你这个环是否处于健康状态。
下面是一个排查 Direct NM 失联问题的实际检查流程，整理成表格：
| 现象 | 优先检查项 | 排查要点 |
|---|---|---|
| 某个节点总是掉线 | NM_IMMEDIATE_TIMEOUT的值是否偏小 | 观察 CAN 总线负载率是否超过 60%，过载会造成报文周期抖动 |
| 节点可以发 Ring 但从不收 Ring | 检查 Node ID 的配置是否与前驱节点一致冲突 | ID 重复会导致环视图持续被刷新而无法稳定 |
| 网络整体无法进入睡眠 | 检查是否有节点只请求网络释放、不停止发送报文 | 应用层必须保证释放后不再发周期消息，否则Nm_PrepareBusSleepMode永远无法被触发 |
| 唤醒正常但网络风暴 | 检查唤醒源设计，是否所有节点都配置了相同的唤醒源 | 不同唤醒源会造成部分节点进入睡眠、部分节点保持唤醒的状态分裂 |
5.2 报文周期抖动时怎么稳定判定失联
CAN 总线上 NM 报文的发送并不精确，因为仲裁机制可能把 NM 报文延后，尤其是总线负载率超过 80% 的极端情况。实际产品中，NM_IMMEDIATE_TIMEOUT建议设置成报文周期 T_NM 的 2~3 倍，而不是理想的 1 倍。NMRepeatMessage的重发逻辑是应对这个抖动的主力：每次前驱超时并不会立即触发状态变迁，而是先重发前驱的报文，等到重发次数也耗尽才判定节点失联。
重发逻辑的代码注释里必须写清楚一件事：这里的“重发前驱报文”使用的是本地缓存的前驱 NMPDU，而不是前驱节点的原始报文。因为 NM 层的报文在总线上一旦发出，物理上就没了，节点只能靠上层协议（比如 CAN Transport Protocol）做传输层确认。由于 NM 报文一般不用 TP，所以重发实际上是“重新构造内容相同的 NMPDU”，并不是原帧重发。
5.3 间接 NM 的调试锚点：监控表的状态输出
间接 NM 没有专门的 NM 报文，调试时最缺的就是“眼见为实”的依据。一般会在调试版里加一个诊断服务，可以用 UDS 0x22 DID 来读取每个被监控节点的静默计数值。下面这段是读取监控表单条目的参考实现：
uint8_t Nm_Diag_ReadMonitorStatus(uint8_t nodeIndex, uint16_t* timeoutCounter) { if (nodeIndex >= Nm_MonitoredNodeCount) { return 0x31; /* RequestOutOfRange */ } *timeoutCounter = MonitorTable[nodeIndex].NMTimeoutCounter; return 0x00; /* PositiveResponse */ }通过周期读取NMTimeoutCounter，可以看到这个值是锯齿波（节点周期发消息、计数器不断清零）还是持续升高到阈值后触发失联标志。如果是后者，需要判断是应用报文没有发送，还是报文 ID 根本没关联到监控表里。
5.4 复现和验证休眠唤醒流程的最后一公里
整车级别最容易出问题的是休眠和唤醒的往返过程。验证方法是：用 CANoe 做总线记录和发送测试，脚本模拟整车节点的休眠时序，先从总线静默开始，逐步向被测节点发送唤醒帧，观察被测节点的Nm_NetworkRequest()是否由 EcuM 正确触发、应用层是否恢复周期报文。同时把总线上的电压曲线用示波器记录下来，配合报文时间戳来证明“报文中断的时刻”和“经过网络管理协商后整车下电的时刻”之间的延时是否符合产品休眠电流测试要求。
当被测节点在NMPrepareBusSleepMode后出现异常唤醒，重点检查收发器的 INH 引脚——很多方案里 NM 层下电时序并不会自动控制 INH，需要Nm_BusSleepIndication回调里显式调用CanTrcv_DeSleep()。这个层级的关联性，是 OSEK/VDX NM 第 5 章强调 NM 对数据链路层有额外要求的主要原因：NM 的行为不只局限于自身的协议，它直接绑定了收发器的电源管理策略。
本文还有配套的精品资源，点击获取
