文章分为三个部分来

简绍AUTOSAR的网络管理的优点或缺点

首先跟大家明确一个关键细节：AUTOSAR全称是AUTomotive Open System ARchitecture（汽车开放系统架构），写全称时必须严格按照这个格式，不能只把首字母大写，后面会反复用到，大家注意一下~​

先给大家讲明白核心基础：什么是网络管理？简单说，就是汽车总线上各个通讯节点之间，在“睡眠、唤醒、工作”这三种模式之间的切换和管理。再往深了理解，每个节点内部都有几种不同的状态机，它们的作用就是规范节点参与通讯时的行为，确保所有节点“各司其职、互不干扰”。​

咱们今天说的AUTOSAR NM，本质是一种“分布式直接网络管理”，这两个关键词拆开来，用大白话讲清楚：​

•

分布式：一条总线上的各个节点都是相互独立的，网络管理也一样——每个节点只管好自己，不直接去管控其他节点，不用“操心别人的事”。​

•

直接网络管理：说白了，网络管理的核心是“看帧办事”，直接根据网络管理帧（简称NM帧）里携带的信号，来判断该切换哪种模式、执行哪种操作，不用经过中间环节。

1：AUTOSAR NetworkManage概述：

1.1 网络管理可以分为以下三大模块

时序上如图所示：

图例解析 ：在黄色的repeatMessage部分，是NM报文以快速的周期发送5帧（5帧也是通过软件工具配置的参数值，快速周期也是配置的定时器）

节点处于不同模式下，对NM报文和Application报文的收发能力如下表所示：

1.2 不同状态下，NM报文与应用报文的收发规则

先明确两个标识：N=不能执行该操作；Y=可以执行该操作。另外提醒大家，咱们平时用到的诊断帧，在这里也属于应用报文（AppFrame），别搞混啦~

节点状态	NM报文发送（TX）	NM报文接收（RX）	应用报文发送（TX）	应用报文接收（RX）
重复消息状态（RMS）	Y	Y	Y	Y
正常运行状态（NOS）	Y	Y	Y	Y
准备睡眠状态（RSS）	N	Y	Y	Y
预睡眠模式（PSM）	N	Y	仅缓存未发完的报文可发送	N
总线睡眠模式（BSM）	N	Y	N	N

结合表格，给大家总结几个关键规则（记牢这些，基本能搞定大部分场景）：

• NM报文发送（TX）：只有在网络模式（NM模式）下的重复消息状态（RMS）和正常运行状态（NOS），节点才能发送NM报文；其他状态下，都不能发。

• NM报文接收（RX）：不管节点处于哪种状态，都必须能接收NM报文——说白了，就是节点在任何时候，都能被NM报文唤醒，这是硬性要求。

• 应用报文发送（TX）：大部分情况下，只有在NM模式下才能发；唯一的例外是：节点从NM模式切换到预睡眠模式（PSM）时，如果缓存器（TX buffer）里还有没发完的应用报文，那在PSM模式下，还能把这些缓存的报文发完。

• 应用报文接收（RX）：只有在NM模式下才能接收，其他模式下，都收不到应用报文。

1.3 常用模式和状态缩写（统一规范，避免混淆）

原文有些缩写对应不规范，这里统一整理，后续全文沿用这个标准：

• 网络模式（Network Mode）：简称NM，包含3个子状态，后面单独说；

• 预睡眠模式（Prepare Sleep Mode）：简写为PSM（全部大写），核心是停止应用报文的收发；

• 总线睡眠模式（Bus-Sleep Mode）：简写为BSM（全部大写），节点最低功耗状态；

重点：NM模式的3个子状态（核心中的核心）：

• 重复消息状态（Repeat Message State）：简写为RMS，NM报文以快速周期连续发送（比如5帧）；

• 正常运行状态（Normal Operation State）：简写为NOS，NM报文以较慢的周期发送，节点正常收发应用报文；

• 准备睡眠状态（Ready Sleep State）：简写为RSS，节点自身停止发送NM报文，但能接收其他节点的NM报文，应用报文的收发不受影响。

补充2个易混点，帮大家避坑：

• PSM和BSM的共性：两者都不能发送NM报文，也不能接收应用报文；区别是PSM可能残留未发完的应用报文，BSM是完全停止应用报文收发。

• RMS的关键：很多人会误以为RMS只能发NM报文，其实不是——RMS状态下，NM报文和应用报文都能正常收发，只是NM报文的发送周期更快、发送次数固定（比如5帧）。

（测试时可以根据：“发送应用报文，查看被测样件是否产生ACK应答”）

二、应用层调用的接口与节点状态

AUTOSAR NM节点内部，针对应用层的需求，有两个核心状态：请求状态和释放状态，逻辑很简单，用大白话讲：

• 当节点的应用层需要用总线通讯时（比如要发送诊断指令、传输传感器数据），就调用接口，让节点进入“请求状态”；

• 当应用层不需要通讯时，就调用接口，让节点进入“释放状态”。

这里有两个重点，原文表述不够清晰，修正后如下：

• 规范只做了一个硬性要求：节点初始化上电的时候，必须强制进入“释放状态”（released模式）；除此之外，什么时候切换到请求状态、什么时候切换到释放状态，没有统一规定，由主机厂的工程师根据项目需求，编写程序来判断。

• 别误解“释放状态”：节点处于释放状态，不代表总线就关闭了——因为总线上可能还有其他节点处于请求状态，正在使用总线。简单说，这个状态只代表“当前节点的应用层不需要通讯”，不代表“总线不能通讯”。

总结一下，记牢这两句就行：

• 节点上电初始化 → 默认进入释放状态；

• 应用层需要通讯 → 调用CanNm_NetworkRequest（请求接口）；应用层不需要通讯 → 调用CanNm_NetworkRelease（释放接口）；

• 释放状态下节点还能通讯 → 因为其他节点可能在请求总线。

三、网络管理帧的结构：

3.1、 规范中默认只定义了Byte0和Byte1

Byte0：代表的是，节点源地址（Source Node Identifier），是专门指，发送该NM帧的节点的源地址。（如该节点发出的NM帧ID=0x625，则此Byte0=0x25）

Byte1：包含的是一些控制信息和控制命令，具体命令如下：

Bit 0: Repeat Message Request

• 0: Repeat Message State not requested
• 1: Repeat Message State requested
  该位置1的时候表示当前节点请求所有节点进入报文重复阶段。（也就是接收这条网络唤醒报文的所有节点，都要进入报文重复阶段）

• Bit 3: NM Coordinator Sleep Bit

      0: Start of synchronized shutdown is not requested by main coordinator
      1: Start of synchronized shutdown is requested by main coordinator
      该位置1时表示主协调节点（发送节点）请求（接收NM帧的节点）开始进入同步休眠。即这个位置1后，发送NM的节点自身也会开启一个计时器,并且同步要求接收节点也开启计时器。两个节点在计时器计时结束以后，同步进入睡眠状态。

• Bit 4 Active Wakeup Bit（当节点被本地唤醒时，该bit=1）

      0: Node has not woken up the network (passive wakeup)，即当前节点收到网络管理报文，被其它节点唤醒。（即网络唤醒）
      1: Node has woken up the network (active Wakeup)，即当前节点主动唤醒网络（通过Request），亦称本地唤醒。

• 本地唤醒：如KL15唤醒，或按键唤醒，或者是定时自动唤醒

• Bit 6 Partial Network Information Bit (PNI)    Partial Network Information（PNI:子网网络管理信息位）

      0: NM PDU contains no Partial Network request information
      1: NM PDU contains Partial Network request information
      该位表示该条网络管理报文中是否包含部分网络激活信息。详细解释就是，被唤醒的节点，充当网关的作用，唤醒此网关时，需要同步唤醒网关下所处的另外一条CAN网络。又比如比如很多CAN总线上的节点，是充当了LIN网络主节点的作用。我们唤醒此节点时，也就是唤醒了LIN网络。这两个位是相关的请求位。

3.2  user data数据解析，唤醒源和保持源

一般情况下，userdata会分为  唤醒源，和保持源。此处一般可以由主机厂自行定义。我见过将唤醒源和保持源放在同一个字节上的（节点较少的网络拓扑结构），也见过将2,3,4字节作为唤醒源，5,6,7字节作为维持源的

3.2.1 先来了解什么是唤醒源和保持源

唤醒源：唤醒源，是指总线睡眠状态下（BSM）,到NM(正常模式下)，的唤醒方式，AUTOSAR中定义了，两种唤醒源

**1) 本地唤醒源

本地唤醒源：一般包含以下几种，KL15上电，本地按键，本地传感器，定时唤醒定时器（有些ECU会执行以下逻辑，即睡眠后，每间隔固定时间，会唤醒一次，检查有没有错误发生），

**2）远程唤醒源

远程唤醒，即NM报文唤醒，和诊断报文唤醒

四、网络节点之间的相互转换

模式切换规律：

分别以3个Mode为例，来讲解。其中NM有拆分为3个子状态 

1：BSM模式下，可以直接跳转至NM下的RMS状态，（记住这是BSM唯一能够跳转到的一种状态），从外在看，就是存在本地唤醒，或远程报文唤醒。从应用层看，就是存在通讯的需求

注意：BSM不能直接跳转到，除RMS状态外的任何一种状态。如果能跳转说明存在BUG

2:RMS子状态下，

RMS->NOS,即在相关定时器，结束定时时和其他条件符合时（后面补充哪些计时器和条件）。自动进入NOS阶段。

3：RMS->RSS,即在相关定时器，结束定时时和其他条件符合时，节点会进入RSS状态，自身网管报文停止发送，能接收其他网管报文，正常发送APP报文。

五、网络管理的时间参数和配置参数

5.1 时间参数

 **1)T_REPEAT_MESSAGE :计时器，在节点进入Repeat_Message_State后，就开始计时，计时时刻到后，就退出Repeat_Message_State状态，此段时间设置，与T_NM_ImmediateCycleTime和T_NM_MessageCycle和N_Immediate_TIME最好不要存在冲突，如N_Immediate_TIME次数设置为10，T_NM_ImmediateCycleTime=100，但是T_REPEAT_MESSAGE却设置为900ms，根本不能完成10次快发。

**2）T_NM_TIMEOUT：指节点在NM(注意：这里是指Normal Management )，该计时器会有一个时间重载值，进入NM之前，初始化程序中，就载入这个时间值。当节点进入NM时，就开始倒计时，当收到或自身发出网管报文时，该值会被重置。

此外，在RMS,和NOS状态下，如果T_NM_TIMEOUT超时，会自动重载，不影响以上两个状态进入和退出。

**3）T_STARIT_APPFrame，是指第一帧节点自身NM报文发出后，到第一帧APP报文，发出时刻的时间值。另外时间和初始化唤醒的时间之间的冲突，这里的初始化唤醒，是指报文中的信号发出有效值（比如，发出时刻下实际的发动机转速），故在实际完成初始化之前，报文中的信号可以发送初始默认值。

**4）T_Wait_BUS_Sleep  最后一帧APP报文停发的时间(进PBM状态),到总线进入睡眠BSM的时间，

2：表格里没有列举的一种时间，即在首诊NM报文发出后，必须在规定时间内，发出所有应用报文。

5.2 配置参数

六、详细状态跳转状态图

标号5和标号6处，可以知道,当维持源消失后，NOS和RSS之间的状态是属于立即切换。且发送模块应该注意，当节点从RMS状态下，切换到NOS，发送模块如果想 维持接收节点，处于RSS状态，而非切换到NOS，RMS应该把自身Repeat Message bit位置0。

节点处于BMS状态时，被被动远程唤醒（即报文唤醒）时，无论Repeat Message bit=1或=0，都会使得接收节点进入RMS状态，但是接收节点，要从NOS或RSS,进入RMS需要发送单元的 Repeat Message bit=1。

七、状态跳转中的函数调用

① 初始化与 CanNm_Init() 函数

节点上电（可以指KL30接电）或复位后，经初始化函数CanNm_Init()默认进入总线睡眠状态，在总线睡眠状态下应停发所有应用报文和网络管理报文，但要可以接收网络管理报文，以使得其它节点能够唤醒当前节点。

摘要：实际项目中，ECU上KL30常电后，就会执行一系列初始化函数，CanNm_Init()函数也会被调用。

② 进入网络模式  与  CanNm_PassiveStartup() 和 CanNm_NetworkRequest()
当节点收到了网络管理报文时，不是直接进入网络模式，而是上报应用层，应用层判断当前状态，允许的话会调用CanNm_PassiveStartup()函数，使节点进入网络模式。当节点自身想要进行网络通讯时，调用CanNm_NetworkRequest()使节点进入网络模式。前者是被动，后者是主动。后者发送的网络管理报文中CBV的Active Wakeup Bit位为1。

摘要：

CanNm_PassiveStartup  被动启动，指被其他节点的网管报文唤醒，也可以理解为NM报文为唤醒源

CanNm_NetworkRequest 主动请求，（主动唤醒的操作，如KL15上电，按键唤醒，触屏唤醒等）CBV的Active Wakeup Bit位为1。

2.1 网络模式下的 RMS

      节点进入网络模式后，默认进入重复报文阶段，启动定时器NM-Timeout（个人认为应该叫做超时计时器更容易理解），同时还要启动另外一个RepeatMessageTimer(状态维持计时器)

NM-Timeout用来记录网络管理报文是否超时，其超时时间为CanNmTimeoutTime，每收到或成功发送一帧网络管理报文，都应重启NM-Timeout。节点要开始周期发送网络管理报文。常规情况下，节点要先等待一个时间偏移量（CanNmMsgCycleOffset）后再发送第一帧网络管理报文，发送周期为CanNmMsgCycleTime，发送次数为CanNmRepeatMessageTime。

摘要：

努力搞明白NM-Timeout计时器，你就明白了整个Autosar网管了

CanNm_PassiveStartup  和CanNm_NetworkRequest函数调用成功后，都需要启动一个“超时计时器”，超时计时器需要配置一个参数，叫做“超时值”，当“计时器数值”>=“超时值时”，此时会根据另外一个计时器RepeatMessageTimer(状态维持计时器)，的结果来判断，如果此时状态维持计时器没超时，就会重置NM-Timeout计时器。

实例：RepeatMessageTimer超时值被配置为5秒，NM-Timeout值被配置为3秒。如果RMS状态下，维持源（KL15，其他节点的网管报文都没有），节点自身的网管报文因为bug而无法发出。则

在进入RMS状态，3s后NM-Timeout开始超时，此时RepeatMessageTimer还没有超时，此时会重置NM-Timeout，然后NM-Timeout会重新从0计时，当NM-Timeout计时到2s时，RepeatMessageTimer计时到5S，节点会根据自身此时有无网络通信需要，选择进入RSS或NOS状态。进入RSS状态和NOS状态下，NM-Timeout的状态也是不一样的

（1）RepeatMessageTimer超时后，检查没有“网络通信需要”，直接进入RSS状态，此时NM-Timeout不会被打断，继续在2S基础上，继续计时。当计时到3s后，会直接跳出RSS状态，进入PSM模式。

（2）RepeatMessageTimer超时后，检查存在“网络通信需要”，进入NOS状态，进入NOS状态后，NM-Timeout还会继续计时到3s，检查到还存在网络通信需要，则继续重置计时器。

小结：NM-Timeout超时后重置的条件存在2个，（1）RepeatMessageTimer未超时（2）RepeatMessageTimer超时后，检查是否存在“网络通信需要”存在通信需求就重置，不存在就不重置。

NM-Timeout超时且不重置后，必须跳转到PSM状态。任何状态下，节点接收到NM帧，或者自身发送出网管帧，都必须打开或重置或重新打开NM-Timeout计时器。

八、总线负载降低策略（Bus Load Reduction Mechanis）

        通常情况下，在常规运行阶段，所有节点都要发送网络管理报文，节点中有一个定时器CanNm Message Cycle Timer，每发送一帧网络管理报文，该定时器就重新装载CanNmMsgCycleTime的值，即网络管理报文的发送周期为CanNmMsgCycleTime。但其实只要有一个节点在发送报文，网络中所有节点就都可以保持在网络模式（RSS状态），多发的网络管理报文是对总线负载的浪费。

总线负载降低策略具体为：

当配置参数与CanNmBusLoadReductionEnabled为有效，且节点处于常规运行阶段时，进入总线负载降低模式，此时：

节点如果接收到了一帧网络管理报文，则应将定时器CanNm Message Cycle Timer重置为CanNmMsgReducedTime，而不是CanNmMsgCycleTime，CanNmMsgReducedTime 参数是一个小于 CanNmMsgCycleTime 且大于CanNmMsgCycleTime的一半( ½ CanNmMsgCycleTime)的时间值，且每个节点的CanNmMsgReducedTime 值不同。
节点如果发送了一帧网络管理报文，则还是将定时器CanNm Message Cycle Timer重置为CanNmMsgCycleTime。
这种策略的结果是：网络中只有CanNmMsgReducedTime 值最小的两个节点交替发送网络管理报文。

我们假设节点A的CanNmMsgReducedTime 最小，B次之，在某一时刻（某一个时刻，是什么时刻？什么情况下所有节点进入总线负载降低模式），网络上所有节点都进入了总线负载降低模式，此时

（1）某个节点X立即发送了一帧网络管理报文，之后X节点因为是发送节点，所以定时器CanNm Message Cycle Timer重置为CanNmMsgCycleTime（即节点X发送的NM报文不变） 。

（2）其余节点是接收节点（包括A和B节点），CanNm Message Cycle Timer重置为各自的CanNmMsgReducedTime，节点A的CanNmMsgReducedTime值最小（比目前总线上所有的NM报文周期都小），所以一段时间后率先发了一条网络管理报文，之后将CanNm Message Cycle Timer重置为CanNmMsgCycleTime，其余节点CanNm Message Cycle Timer再次重置为各自的CanNmMsgReducedTime，此时网络中节点B变成了CanNm Message Cycle Timer值最小的节点，一段时间后会发出一条网络管理报文，这又会使得节点A的CanNm Message Cycle Timer值变成最小，所以实现了网络中CanNmMsgReducedTime 值最小的两个节点交替发送网络管理报文，其余节点不发送网络管理报文。

      这里还有个重点，就是当条件满足时，所有节点都进入负载降低模式，当第一条NM报文发出后

所有节点的NM的周期都要重置！！

当最小的两个节点中某个节点进入准备睡眠阶段，不再发送网络管理报文了，那么CanNmMsgReducedTime 值略大的下一个节点会开始发送网络管理报文。

当网络中只有一个节点处于常规运行阶段时，网络管理报文的周期为CanNmMsgCycleTime。

九、AUTOSAR NM的优点与缺点

结合前面的所有内容，提炼AUTOSAR NM的核心优缺点，结合实际项目场景，不空谈理论：

8.1 核心优点

• 分布式管理，可靠性高：每个节点自主管理，不依赖单一主节点——即使某个节点故障，也不会影响整个总线的网络管理，降低了单点故障风险，适合汽车多节点通讯场景。

• 总线负载可控，节能降耗：通过“总线负载降低策略”，减少不必要的NM报文发送，降低总线负载；同时，节点可灵活进入睡眠模式（BSM），减少ECU功耗，符合汽车节能需求。

• 状态规则清晰，可配置性强：所有模式/状态的切换的规则、收发逻辑都有明确规范，且核心参数（发送次数、周期、超时时间等）可通过软件工具配置，适配不同车型、不同项目需求，通用性强。

• 唤醒机制灵活，兼容性好：支持本地唤醒和远程唤醒，且任何状态下都能接收NM报文，确保节点能及时响应通讯需求；同时，兼容诊断帧、应用帧，适配汽车复杂的通讯场景。

• 规范统一，便于协同开发：作为AUTOSAR架构的一部分，NM的规范统一，不同主机厂、不同供应商可基于同一规范开发，减少兼容性问题，提升开发效率。

8.2 核心缺点

• 参数配置复杂，门槛高：核心依赖时间参数和配置参数的匹配，参数设置不当（比如T_REPEAT_MESSAGE与快速发送次数冲突），会导致唤醒失败、状态切换异常，对工程师的专业能力要求高。

• 开发调试难度大：分布式管理导致故障定位困难——如果某个节点状态切换异常，需要逐一排查每个节点的参数配置、函数调用、报文收发，耗时耗力；且计时器的配合逻辑复杂，调试成本高。

• 资源占用较高：节点需要同时运行多个状态机、计时器，还要处理NM报文的收发和解析，对ECU的硬件资源（算力、存储）有一定要求，不适合低端、资源有限的ECU。

• 模式切换存在延迟风险：从BSM→RMS→NOS的切换，需要依赖计时器和报文交互，存在一定的延迟；如果参数配置不合理，延迟会加剧，可能影响实时通讯（比如紧急诊断指令的传输）。

• 兼容性依赖规范执行：虽然规范统一，但不同供应商对规范的执行细节可能存在差异，若某一节点未严格遵循规范（比如NM报文结构错误），会导致整个总线的网络管理异常，兼容性管控难度大。

十、总结（核心要点回顾）

1. AUTOSAR NM是“分布式直接网络管理”，节点自主管理，通过NM帧直接管控模式切换，核心是“状态机+计时器+参数配置”；

2. 关键规则：NM报文任何状态都能接收，仅RMS、NOS能发送；应用报文仅NM模式能收发（PSM缓存报文例外）；

3. 核心难点：状态切换规则、两个计时器（RepeatMessageTimer、NM-Timeout）的配合、参数配置不冲突；

4. 核心优势：可靠性高、负载可控、可配置性强；核心缺点：配置复杂、调试难度大、资源占用高。