写在前面：
入行一段时间了，基于个人理解整理一些东西，如有错误，欢迎各位大佬评论区指正！！！
0.为什么要有网络管理？
网络管理是一套标准化、分布式的网络状态协调机制，负责整车所有 ECU 的统一唤醒、协同休眠、网络状态监控与故障隔离，让不同厂商的 ECU 能按同一规则 "一起醒、一起睡、异常能识别"。用来实现整车的启动休眠，避免部分控制器持续工作导致整车亏电。
1.网络管理都有哪些方案
- OSEK NM（传统经典网络管理）
- AUTOSAR NM
- 静态网络管理 Static NM
- LIN 网络管理（LIN Bus NM）
- 以太网网络管理（Ethernet NM，AUTOSAR AP 主流）
对于MCU控制器，常用的NM方案为Autosar NM,也有一些控制器使用的是Osek NM和Lin网络管理。
2.Autosar NM原理
2.1AUTOSAR NM 整体架构定位
AUTOSAR NM 位于 COM 层之上、OS 及通信驱动之下 ，属于系统服务层 。核心本质：分布式协同式网络管理，所有 ECU 遵循同一套状态机、定时器、NM 帧规则，实现：统一唤醒、协同休眠、节点心跳监控、网络状态同步、故障检测、支持 PN 部分网络。
适用总线：CAN 为主，也适配 FlexRay、以太网。
AUTOSAR NM 分两大类：
- Direct NM 直接网络管理（独立 NM 报文）
- Indirect NM 间接网络管理（复用应用报文，无独立 NM 帧）
2.2核心基础概念
网络请求 Network Request
应用层需要通信时，向 NM 模块发起 Network Request（请求组网） ；无业务需求时，发起 Network Release（释放组网）。
只有所有 ECU 都 Release，网络才允许进入休眠。
NM 帧（NM PDU）
- Direct NM：每个 ECU 周期性单独发送专属 NM 帧 ，作为心跳 + 网络协商报文 。
作用：宣告节点在线、同步网络状态、携带休眠请求、故障标识。 - Indirect NM：无独立 NM 帧，复用本节点周期应用报文当作心跳，节省总线负载。
核心定时器
- T_NM_RepeatMessage：刚唤醒后，快速连发 NM 帧，快速建网同步
- T_NM_NormalOperation：正常工作态，周期发送 NM 帧心跳
- T_NM_WaitSleep：本节点已释放请求，等待其他节点释放的超时时间
- T_NM_WaitBusSleep：全网都释放后，等待收尾报文发送完成，再进入总线休眠
- T_NM_MsgCycle：NM 帧发送周期
- T_NM_MsgTimeout：接收 NM 帧超时阈值，超时判定节点离线
2.3 AUTOSAR NM 标准状态机（核心原理灵魂）
所有 ECU 统一跑这套状态，全网状态对齐，是协同休眠的基础。
2.3.1三大基础状态
- BSM Bus Sleep Mode 总线休眠态
- PBM Prepare Bus Sleep Mode 预休眠态
- NM Network Mode 网络工作态
BSM 总线休眠模式
- 总线无活动、ECU 进入低功耗模式
- 仅保留总线唤醒检测，关闭大部分外设与通信
- 可被：硬件唤醒、报文唤醒、诊断唤醒、本地唤醒 触发切出
NM 网络工作模式（细分 3 个子状态）
（1）Repeat Message 重复报文态
唤醒进入网络后，快速密集发送 NM 帧目的：快速通知全网我已上线，快速建立网络同步，避免刚唤醒通信丢包。
（2）Normal Operation 正常工作态
按固定周期发 NM 心跳帧；应用正常收发报文，网络持续保持唤醒。
（3）Ready Sleep 准备休眠态
本节点已无业务需求，主动释放网络请求 ；仍持续监听其他节点 NM 帧，等待全网都释放，不立刻休眠。
PBM 预休眠模式
全网所有 ECU 都进入 Ready Sleep 且定时器超时；进入 PBM：
- 完成最后应用报文、诊断报文收尾
- 保存关键数据
- 禁止再发起新的网络请求倒计时结束 → 统一切入 BSM 休眠。
2.4 Direct NM 工作原理（最常用，逐流程拆解）
流程 1：全网唤醒原理
- 任意 ECU 产生业务需求 / 被唤醒源触发
- 该 ECU 发起 Network Request
- 立刻从 BSM → NM 模式下的 Repeat Message 状态
- 高频发送 NM 帧
- 总线上其他 ECU 检测到 NM 帧 / 总线活动
- 依次从 BSM 唤醒，同步进入网络工作态
- 全网所有节点完成上线，进入 Normal Operation
原理核心：单点唤醒 → NM 帧广播 → 全网同步唤醒
流程 2：协同休眠原理
- 某 ECU 业务结束，调用 Network Release → 进入 Ready Sleep
- 仍周期发 NM 帧，告诉其他节点：我已准备休眠
- 所有 ECU 依次完成业务，全部进入 Ready Sleep
- 所有节点无 NM 网络请求，T_WaitSleep 超时
- 全网统一进入 PBM 预休眠
- T_WaitBusSleep 超时，收尾完成
- 所有 ECU 同时切入 BSM 总线低功耗休眠
关键原理：不是谁先没事谁先睡，必须全员同意、全员倒计时、全员同步休眠
流程 3：节点故障 / 离线检测原理
- 正常每个 ECU 周期发 NM 心跳帧
- 某 ECU 死机、掉电、总线故障，停止发 NM 帧
- 其他节点检测 NM 帧接收超时 > T_NM_MsgTimeout
- NM 模块判定节点丢失 / 网络故障
- 上报 DTC 故障码，通知应用层、诊断层做降级处理
2.5 Indirect NM 原理（间接网络管理）
核心原理
不定义独立 NM PDU ，直接复用节点自身周期性应用报文 充当 NM 心跳与网络在线标识。
- 无独立 NM 帧，降低 CAN 总线负载
- 状态机、定时器、休眠唤醒逻辑和 Direct NM 完全一致
- 判定节点在线：看周期应用报文是否按时收到
- 判定休眠：所有节点周期应用报文都停止 + 超时，进入预休眠
适用场景
低速 CAN、子网节点多、总线负载受限、简单外设网络。
缺点
无法像 Direct NM 那样在 NM 帧里携带休眠请求、节点状态、PN 掩码等扩展信息。
也有的项目某几个通道是间接网络管理模式，采用的方案是若其他直接网络管理的通道被唤醒，开启这几个通道的通讯，休眠时机也与直接网络管理的通道同步。而非通过周期性应用报文唤醒和休眠。
2.6 AUTOSAR PN 部分网络管理原理（进阶核心）
解决问题
不需要整网唤醒，只唤醒当前功能必需的 ECU / 子网，其余保持休眠，极致省电。
核心原理
- 定义 PN（Partial Network）逻辑通道，每个功能绑定一个 PN 掩码
- ECU 订阅对应 PN 掩码，只监听属于自己的 PN 唤醒报文
- 当触发某功能时，只发送对应PN 唤醒帧
- 只有匹配 PN 掩码的 ECU 被唤醒，不相关 ECU 继续休眠
- 网关负责跨子网 PN 路由，实现域内局部唤醒
架构关键点
- PN 网关：负责 PN 报文转发、子网隔离
- PN 掩码：位标识，标识哪个局部网络需要唤醒
- 仅新能源、智能座舱、域控架构必用
2.7 AUTOSAR NM 底层协作原理（模块交互）
- 应用层：发起 Network Request / Release
- NM 模块：状态机流转、定时器管理、NM 帧收发、全网状态协商
- COM 层：负责 NM PDU 的打包、解包、路由
- CAN IF / CAN Driver：总线收发、唤醒检测
- OS：提供定时任务、调度、超时回调
- DEM：接收 NM 检测到的节点离线故障，上报告警
2.8主动唤醒&被动唤醒
实际上CAN控制器唤醒MCU的代码部分已经在文章https://blog.csdn.net/weixin_44293445/article/details/145368803?spm=1001.2014.3001.5501
中做过部分介绍了。当控制器唤醒源有效时（KL15 On，CAN NM Rx等）会触发电源芯片给控制器上电，控制器会检查唤醒源来执行初始化，后进入上位介绍的NM状态机。
需要特殊介绍的是，对于CAN收发器常见的是无法通过硬件判断CAN报文是否是NM报文还是APP报文，所以如果控制器接收到报文后通常会先唤醒控制器，在控制器初始化后再检查唤醒源是否有效，若无效执行休眠的动作，否则进入Network Mode。即上文BusSleepMode->Network Mode的操作。
此时控制器会判断当前是主动唤醒还是被动唤醒，一般类似于KL15 ON认为是主动唤醒源，外部的NM报文认为是被动唤醒源。不同的唤醒源对应的NM状态切换以及是否唤醒全部网络都有差异。需要基于项目需求实现。
主动唤醒（Active Wake-up）
- 定义：由当前 ECU自身内部事件 / 条件触发，自主发起唤醒请求，同时唤醒自身及所在网络的其他节点，是网络唤醒的 "源头"。
- 触发源（本地事件）：KL15 点火信号、本地硬线触发（如门把手信号）、ECU 内部定时器、诊断请求、应用层主动发起的网络请求等。
- 核心特征：自发性、主导性，自身作为唤醒源，主动维持网络活跃。
被动唤醒（Passive Wake-up）
- 定义：由外部总线活动触发，ECU 被动响应总线上的唤醒信号，自身不主动发起唤醒，仅作为 "被唤醒节点" 加入已激活的网络。
- 触发源（总线事件）：其他 ECU 发送的 NM 报文、应用报文，或诊断工具发送的唤醒帧，需符合 ISO 11898-5 标准的唤醒序列。
- 核心特征：响应性、从属性，依赖主动唤醒节点，自身不主导网络状态。
| 对比维度 | 主动唤醒 | 被动唤醒 |
|---|---|---|
| 状态机流转 | 从 Bus Sleep（总线休眠态）直接进入 NM 模式的 Repeat Message（重复报文态），快速高频发送 NM 帧（如 10ms 周期连发 5 帧），快速同步全网状态后切换至 Normal Operation（正常工作态）。 | 从 Bus Sleep 被唤醒后，先进入 NM_PASSIVE（被动状态），仅监听总线，不主动发送 NM 帧；需收到主动唤醒节点的有效 NM 报文（含 Active Request 位 = 1）后，才逐步进入正常工作态。 |
| NM 报文权限 | 必须发送 NM 帧（独立 NM 帧或复用应用报文），作为心跳维持网络活跃，可发起网络请求、触发全网休眠协调。 | 被动唤醒初期不发送 NM 帧，仅响应应用报文；即使后续发送，也不主动发起网络请求，无法阻止全网休眠。 |
| 唤醒校验逻辑 | 由 ECU 自身的 EcuM 模块验证唤醒事件有效性，无需依赖外部节点，唤醒后直接启动通信栈初始化。 | 需通过 EcuM_CheckValidation () 校验：验证唤醒报文 ID、格式、来源节点合法性，校验通过后才完成上电初始化。 |
| 网络角色 | 唤醒源、网络协调者，负责唤醒其他节点，主导网络状态同步（唤醒 / 休眠）。 | 被唤醒节点、网络参与者，仅响应网络请求，不参与网络协调，依赖主动节点维持网络活跃。 |