一、引言在 AUTOSAR 架构统一汽车电子软件之前OSEK/VDX是车载嵌入式系统的事实标准。而其中的OSEK 网络管理NM更是整车休眠唤醒、节点监控的基石——从 2000 年代至今大量量产车型仍在使用 OSEK NM 或其变体。即便在 AUTOSAR 时代理解 OSEK NM 依然至关重要AUTOSAR NM 的设计思想直接继承自 OSEK NM大量存量项目的维护、升级仍需 OSEK NM 知识逻辑环、令牌传递等机制是理解车载网络管理的底层思维模型本文将从 OSEK/VDX 标准体系讲起深入剖析直接网络管理的逻辑环机制、NM 报文、状态机、休眠唤醒流程并与 AUTOSAR NM 进行对比帮助读者建立完整的技术认知。二、OSEK/VDX 标准体系概述2.1 什么是 OSEK/VDXOSEKOffene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug是德语汽车电子开放系统及其接口的缩写由德国汽车工业协会VDA主导发起。VDXVehicle Distributed Executive是法国发起的汽车分布式执行标准后并入 OSEK 体系。OSEK/VDX 标准由三大组件构成组件说明OSEK OS实时操作系统规范静态配置、固定优先级抢占调度OSEK COM通信子系统规范信号/消息的打包、路由、滤波OSEK NM网络管理规范节点状态管理、休眠唤醒、故障检测2.2 OSEK NM 的定位OSEK NM 的核心使命管理总线上所有 ECU 的运行状态唤醒/通信/休眠实现按需通信、集体休眠同时监控节点健康状态。它解决三个关键问题节能车辆熄火后协调所有 ECU 进入低功耗模式静态电流降至 μA 级唤醒管理检测到唤醒事件后协调相关 ECU 快速恢复通信节点监控检测节点离线/故障支持故障容错LimpHome 模式2.3 直接 NM vs 间接 NMOSEK NM 规范定义了两种网络管理方式特性直接网络管理Direct NM间接网络管理Indirect NM监控方式通过专用 NM 报文监控节点状态通过应用报文间接推断节点状态逻辑环✅ 有核心机制❌ 无NM 报文Alive / Ring / LimpHome无专用 NM 报文总线负载较高需额外 NM 报文较低复用应用报文故障检测精度高专用机制较低依赖应用报文周期适用场景需要精确休眠唤醒管理的网络总线负载敏感、节点少的简单网络 实际工程中直接网络管理是绝对主流。本文后续内容均围绕直接 NM 展开。三、核心机制逻辑环Logical Ring3.1 什么是逻辑环逻辑环是 OSEK 直接 NM 最核心的拓扑抽象模型。它不是物理环形连接而是通过软件定义的、按节点地址顺序循环传递令牌的逻辑结构。核心规则每个参与 NM 的节点被分配一个唯一的节点地址Node Address建议范围 0~255所有节点按地址从小到大排序形成一个逻辑环地址最小的节点是地址最大节点的后继形成闭环每个节点知道自己的逻辑后继Logical Successor——即环中下一个节点3.2 逻辑环示意假设网络中有 4 个节点地址分别为 1、3、7、12Node 1 ╱ ╲ ╱ ╲ Node 12 Node 3 ╲ ╱ ╲ ╱ Node 7令牌传递顺序Node 1 → Node 3 → Node 7 → Node 12 → Node 1 → ...Node 1 的逻辑后继 Node 3Node 3 的逻辑后继 Node 7Node 7 的逻辑后继 Node 12Node 12 的逻辑后继 Node 1回绕3.3 令牌传递机制逻辑环通过Ring 消息实现令牌传递Node 1 发送 Ring 消息目标 Node 3 → Node 3 收到后发送 Ring 消息目标 Node 7 → Node 7 收到后发送 Ring 消息目标 Node 12 → Node 12 收到后发送 Ring 消息目标 Node 1 → 循环继续...这就像击鼓传花——令牌Ring 消息沿逻辑环依次传递每个节点收到令牌后传给下一个节点。如果某个节点掉线未在规定时间内传递令牌NM 会检测到并触发重建环。3.4 逻辑环 vs AUTOSAR NM 的对等模型对比OSEK NM逻辑环AUTOSAR NM对等广播拓扑模型环形有前驱/后继全连接peer-to-peer通信方式点对点发给后继广播发给所有节点节点监控监控后继节点是否响应监控所有节点的心跳复杂度较高需维护环结构较低无需维护拓扑故障恢复需重建环自动超时即可四、NM 报文NM PDU格式4.1 NM PDU 结构OSEK NM 报文NMPDU通常为8 字节经典 CAN结构如下┌──────────┬──────────┬──────────┬──────────────────────────┐ │ Byte 0 │ Byte 1 │ Byte 2 │ Byte 3 ~ Byte 7 │ │ Source │ Target │ OpCode │ NM Data / User Data │ │ Node ID │ Node ID │ (操作码) │ (可选) │ └──────────┴──────────┴──────────┴──────────────────────────┘字段字节说明Source Node IDByte 0发送该 NM 报文的节点地址Target Node IDByte 1目标节点地址Ring 消息为后继节点Alive/LimpHome 为广播OpCode操作码Byte 2标识报文类型和子功能NM DataByte 3~7可选数据如节点配置信息、用户数据4.2 三种 NM 报文类型① Alive 报文项目说明用途节点声明我在线请求加入逻辑环发送时机节点刚唤醒/上电时NMReset 状态目标地址广播所有节点或特定节点OpCodeAlive可携带子类型AliveRequest / AliveResponse典型场景ECU 上电后发送 Alive 报文告知网络我已就绪请把我加入逻辑环。环中现有节点收到后重新计算逻辑后继关系。② Ring 报文项目说明用途逻辑环中的令牌传递发送时机正常运行时按逻辑环顺序传递目标地址本节点的逻辑后继点对点OpCodeRing典型场景正常通信时Node A 发送 Ring 消息给 Node B后继Node B 收到后再发给 Node C依次循环。③ LimpHome 报文项目说明用途节点声明我发生故障进入跛行模式发送时机节点检测到自身严重故障时目标地址广播OpCodeLimpHome典型场景某 ECU 的通信控制器故障无法正常参与逻辑环但仍能发送报文。此时发送 LimpHome 报文告知网络我还在但功能受限。4.3 OpCode 详解OpCode 是 NM PDU 中最关键的字段定义了报文的具体行为OpCode名称说明AliveAlive Request请求加入逻辑环Alive 响应Alive Response确认加入逻辑环RingRing令牌传递Ring SleepIndRing with Sleep Indication令牌传递 请求休眠Ring SleepAckRing with Sleep Acknowledge令牌传递 确认休眠LimpHomeLimpHome进入跛行模式WakeUpWakeUp唤醒请求4.4 NM 报文的 CAN IDNM 报文的 CAN ID 由 OEM 在通信矩阵中定义通常每个节点有一个专属的 NM 报文 ID与节点地址关联例如Node 1 的 NM 报文 ID 0x501Node 2 的 NM 报文 ID 0x502也有 OEM 使用统一的 NM 报文 ID通过 Source ID 字段区分五、状态机OSEK NM 的灵魂OSEK NM 状态机是多层嵌套的比 AUTOSAR NM 更复杂。理解状态机的层次结构是掌握 OSEK NM 的关键。5.1 第一层全局状态┌──────────┐ StartNM() ┌──────────┐ StopNM() ┌──────────────┐ │ NMOff │ ──────────────→ │ NMOn │ ──────────────→ │ NMShutDown │ │(NM关闭) │ │(NM运行中) │ │(NM关闭中) │ └──────────┘ └──────────┘ └──────┬───────┘ ▲ │ └──────────────────────────────────────────────────────────┘ 清理完成状态说明NMOffNM 模块未运行系统复位后的初始状态NMOnNM 模块正在运行管理网络状态NMShutDown正在关闭 NM清理运行数据完成后回到 NMOff核心 APIStartNM()启动 NM进入 NMOnStopNM()停止 NM进入 NMShutDown → NMOff5.2 第二层NMOn 的子状态两组并行NMOn 状态下有两组并行的子状态机互不影响第一组唤醒/休眠状态┌──────────┐ ┌──────────────┐ │ NMInit │ ──初始化完成──→ │ NMAwake │ │(初始化) │ │ (唤醒状态) │ └──────────┘ └──────┬───────┘ │ 所有节点同意休眠 │ ▼ ┌──────────────┐ │ NMBusSleep │ │ (总线休眠) │ └──────────────┘状态说明NMInitNM 初始化配置参数准备进入工作状态NMAwake总线处于唤醒状态节点参与 NM 通信NMBusSleep总线进入休眠所有节点停止 NM 通信ECU 进入低功耗第二组参与/静默状态┌──────────────┐ SilentNM() ┌──────────────┐ │ NMActive │ ──────────────→ │ NMPassive │ │(参与逻辑环) │ │(静默监听) │ └──────────────┘ └──────────────┘ ▲ │ │ TalkNM() │ └─────────────────────────────────┘状态说明NMActive节点积极参与逻辑环发送/接收 NM 报文NMPassive节点不参与逻辑环不发送 Ring 消息但仍监听总线核心 APISilentNM()节点进入 NMPassive我不想说话了但我还在听TalkNM()节点回到 NMActive我要重新参与通信⚠️重要NMPassive ≠ NMBusSleep。NMPassive 的节点仍然醒着只是不参与逻辑环NMBusSleep 的节点是真正休眠了。5.3 第三层NMAwake 的子状态NMAwake 是 OSEK NM 最复杂的部分包含三个子状态┌─────────────────────────────────────────────────────────────┐ │ NMAwake │ │ │ │ ┌───────────┐ 建环成功 ┌────────────┐ │ │ │ NMReset │ ────────────→ │ NMNormal │ │ │ │(复位/建环) │ │(正常通信) │ │ │ └───────────┘ └─────┬──────┘ │ │ ▲ │ │ │ │ 连续多次超时 │ │ │ │ │ │ │ ▼ │ │ │ ┌──────────────┐ │ │ └────────────────── │ NMLimpHome │ │ │ 恢复/重新建环 │(跛行模式) │ │ │ └──────────────┘ │ └─────────────────────────────────────────────────────────────┘① NMReset复位/建环状态触发条件节点上电、唤醒、或逻辑环断裂需要重建行为发送Alive 报文声明自身存在等待其他节点的响应计算逻辑后继Logical Successor建立或加入逻辑环退出条件成功加入逻辑环 → 进入 NMNormal② NMNormal正常通信状态触发条件逻辑环建立成功行为按逻辑环顺序发送/接收Ring 报文监控逻辑后继是否按时响应若所有节点都无通信需求开始休眠协商退出条件连续多次未收到后继的 Ring 报文 → 进入 NMLimpHome所有节点同意休眠 → 进入 NMBusSleep③ NMLimpHome跛行模式触发条件节点检测到严重通信故障如连续多次超时行为发送LimpHome 报文告知网络自身故障尝试恢复通信重新建环若恢复成功 → 回到 NMReset → NMNormal若持续失败 → 节点标记为故障不再参与逻辑环设计意图即使节点部分故障仍能通过 LimpHome 报文维持最低限度的网络存在感5.4 状态机完整层次图NMOff │ │ StartNM() ▼ NMOn ├── 第一组并行 │ NMInit → NMAwake ↔ NMBusSleep │ │ │ ├── NMReset │ ├── NMNormal │ └── NMLimpHome │ └── 第二组并行 NMActive ↔ NMPassive │ │ StopNM() ▼ NMShutDown → NMOff六、休眠与唤醒机制6.1 休眠流程OSEK NM 的休眠机制基于逻辑环上的 Sleep Indication / Sleep AcknowledgeStep 1: 某节点无通信需求 → 在 Ring 报文中设置 Sleep Indication 标志 → 含义我准备休眠了 Step 2: Ring 报文沿逻辑环传递 → 每个节点收到后若自身也无通信需求 → 在 Ring 报文中设置 Sleep Acknowledge 标志 → 含义我也同意休眠 Step 3: 当 Ring 报文绕环一周所有节点都设置了 Sleep Acknowledge → 所有节点确认全网无通信需求 Step 4: 经过 T_WBSWait Bus Sleep时间 → 确保总线上最后一个 NM 报文传输完毕 Step 5: 所有节点进入 NMBusSleep → ECU 关闭不需要保持的电源域 → CAN Transceiver 进入 Standby仅保留唤醒检测 → 静态电流降至 μA 级关键理解休眠确认是搭便车式的——Sleep Indication/Acknowledge 标志搭载在正常的 Ring 报文中随着令牌绕环传递。不需要额外的休眠请求帧或确认帧。6.2 唤醒流程Step 1: 唤醒事件发生 → 本地唤醒点火信号、按键、定时器 → 远程唤醒总线上出现报文活动CAN Transceiver 检测到 Step 2: 被唤醒的节点调用 StartNM() → NM 从 NMOff → NMOn → NMInit → NMAwake Step 3: 节点进入 NMReset 状态 → 发送 Alive 报文 → 等待其他节点响应 Step 4: 其他节点被总线活动唤醒 → 各自进入 NMReset → 发送 Alive 报文 Step 5: 所有节点完成建环 → 进入 NMNormal → 正常通信恢复6.3 唤醒源分类唤醒源类型示例说明本地唤醒点火开关、车门按键、定时器ECU 自身的 GPIO 中断触发远程唤醒总线活动其他 ECU 发送报文CAN Transceiver 检测到总线电平变化远程唤醒专用唤醒帧特定 ID 的唤醒报文部分 OEM 定义专用唤醒帧七、关键时间参数OSEK NM 的行为由一组时间参数控制这些参数通常存储在非易失性存储器中参数名称说明典型值T_TypTypical NM Timeout正常 Ring 报文接收超时时间50~200 msT_MaxMaximum NM Timeout最大超时时间超过则判定节点离线T_Typ 的 2~5 倍T_ErrError Timeout错误恢复超时OEM 定义T_WBSWait Bus Sleep进入 BusSleep 前的等待时间1~5 sT_Rx_LimtReceive Limit接收超时计数上限3~5 次T_Tx_LimtTransmit Limit发送重试上限OEM 定义RepeatMessageCount重复消息计数NMReset 状态下 Alive 报文发送次数3~10 次参数间的关系正常通信 Ring 报文周期 T_Typ正常接收间隔 超时检测 若超过 T_Typ 未收到 Ring → 启动重传 若超过 T_Max 未收到 Ring → 判定后继节点离线 → 触发重建环 休眠等待 所有节点 SleepAck 后 → 等待 T_WBS → 进入 BusSleep八、逻辑环的维护与故障处理8.1 节点加入逻辑环新节点上电 → 发送 Alive 报文广播 → 现有节点收到后重新计算逻辑后继 → 例如原环为 1→3→7→1 → 新节点 5 加入后1→3→5→7→1 → 各节点更新自己的逻辑后继8.2 节点退出逻辑环节点调用 SilentNM() → 进入 NMPassive → 不再发送 Ring 报文 → 前驱节点检测到超时 → 前驱节点跳过该节点直接联系后继的后继 → 例如原环 1→3→5→7→1节点 5 退出 → 新环1→3→7→18.3 节点故障Skipped 检测Node 3 发送 Ring 给 Node 5后继 → 超过 T_Typ 未收到 Node 5 的响应 → Node 3 重发 Ring重试 → 连续 T_Rx_Limt 次未收到 → Node 3 判定 Node 5 离线 → Node 3 跳过 Node 5直接向 Node 7 发送 Ring → 逻辑环重建...→3→7→... → 记录故障信息可上报诊断8.4 LimpHome 模式节点检测到自身通信控制器故障 → 无法正常参与逻辑环 → 但仍能发送报文 → 发送 LimpHome 报文广播 → 其他节点知晓该节点处于故障状态 → 逻辑环中跳过该节点 → 该节点尝试恢复 → 成功则重新建环九、NM 配置管理9.1 节点配置数据每个 OSEK NM 节点需配置以下信息配置项说明Node Address本节点的唯一地址0~255NM Parameter BlockT_Typ、T_Max、T_WBS 等时间参数Logical Successor逻辑后继节点地址运行时动态计算NM Message ID本节点 NM 报文对应的 CAN IDNetwork Status当前网络状态编码9.2 逻辑后继计算算法逻辑后继的计算规则收集所有在线节点的地址按地址升序排列本节点的后继 排序中紧邻的下一个节点若本节点是最大地址则后继 最小地址节点回绕示例在线节点{1, 3, 7, 12}Node 3 的后继 7Node 12 的后继 1回绕9.3 网关节点的特殊处理网关节点连接多条总线在每条总线上有不同的节点地址CAN 1 CAN 2 ┌──────────────┐ ┌──────────────┐ │ Node 1,3,7,12│ │ Node 2,5,8 │ └──────┬───────┘ └──────┬───────┘ │ │ └────── Gateway ────────┘ (CAN1: Addr12) (CAN2: Addr5)网关在每条总线上独立参与逻辑环地址可以不同。十、OSEK NM 与 AUTOSAR NM 对比对比维度OSEK NMAUTOSAR NM拓扑模型逻辑环Token Ring对等广播Peer-to-PeerNM 报文Alive / Ring / LimpHome3种统一 NM PDU含 CBV通信方式点对点发给后继广播发给所有节点休眠机制Ring 报文携带 SleepInd/SleepAck 绕环传递Sleep Indication Bit 超时机制唤醒机制Alive 报文建环Repeat Message State故障处理LimpHome 模式 环重建超时检测 DTC 记录状态机复杂度高多层嵌套中分层但较简洁总线负载较高Ring 报文绕环传递较低各节点独立广播扩展性节点数受环维护复杂度限制较好广播方式天然支持多节点适用总线主要 CANCAN / CAN FD / LIN / Ethernet / FlexRay标准状态已冻结不再更新持续演进典型应用存量车型、传统 OEM新车型、AUTOSAR 平台为什么 AUTOSAR NM 取代了 OSEK NM逻辑环维护复杂节点频繁上下线时环的重建开销大扩展性差节点数增加时Ring 报文绕环一周的延迟增大不支持新总线OSEK NM 主要为 CAN 设计难以适配 Ethernet故障恢复慢环断裂后需要完整的重建流程AUTOSAR 生态统一AUTOSAR 提供了完整的 BSW 栈NM 只是其中一环十一、工程实践11.1 典型项目中的 OSEK NM 配置/* OSEK NM 配置示例伪代码 */ /* 节点基本配置 */ #define NM_NODE_ADDRESS 5 /* 本节点地址 */ #define NM_CHANNEL_COUNT 1 /* NM 通道数 */ /* 时间参数 */ #define NM_T_TYP 100 /* 典型超时: 100ms */ #define NM_T_MAX 500 /* 最大超时: 500ms */ #define NM_T_WBS 3000 /* 等待总线休眠: 3s */ #define NM_T_ERR 200 /* 错误超时: 200ms */ /* 报文配置 */ #define NM_MESSAGE_ID 0x505 /* 本节点 NM 报文 CAN ID */ #define NM_PDU_LENGTH 8 /* NM PDU 长度: 8 字节 */ /* 重试参数 */ #define NM_RX_LIMT 3 /* 接收超时上限: 3次 */ #define NM_TX_LIMT 3 /* 发送重试上限: 3次 */ #define NM_REPEAT_MESSAGE_CNT 5 /* Alive 报文重复次数 */11.2 应用层接口/* 应用层常用 NM API */ /* 请求网络我需要通信 */ NMRequest(NM_CHANNEL_0); /* 释放网络我不再需要通信 */ NMRelease(NM_CHANNEL_0); /* 进入静默模式不参与逻辑环但监听 */ SilentNM(NM_CHANNEL_0); /* 恢复参与逻辑环 */ TalkNM(NM_CHANNEL_0); /* 查询 NM 状态 */ NMStatusType status; NMGetStatus(NM_CHANNEL_0, status); /* 启动/停止 NM */ StartNM(NM_CHANNEL_0); StopNM(NM_CHANNEL_0);11.3 与诊断的交互在需要刷写 ECU 时通常需要先让目标 ECU 退出逻辑环1. 诊断仪发送 10 02进入编程会话 2. 目标 ECU 调用 SilentNM() → 退出逻辑环 3. 目标 ECU 停止发送 Ring 报文 4. 其他节点检测到超时重建逻辑环跳过目标 ECU 5. 执行刷写操作 6. 刷写完成后ECU 复位 7. ECU 重新上电 → StartNM() → Alive → 重新加入逻辑环11.4 测试验证测试项方法工具建环测试逐个上电节点观察 Alive/Ring 报文序列CANoe OSEK NM 插件休眠测试所有节点释放网络观察 SleepInd/Ack 传递CANoe 电流探头唤醒测试模拟唤醒源观察 Alive 报文和建环过程CANoe 信号发生器节点离线测试突然断开某节点观察环重建过程CANoe 故障注入LimpHome 测试模拟通信故障观察 LimpHome 报文CANoe静态电流测试BusSleep 后测量 ECU 电流示波器 电流探头多节点并发唤醒同时唤醒多个节点观察建环竞争CANoe 自动化脚本十二、常见问题与避坑指南12.1 逻辑环断裂现象某节点突然断电Ring 报文无法传递到后继。处理前驱节点超时后跳过故障节点向后继的后继发送 Ring。注意若多个节点同时掉电可能导致环分裂为多段。此时需要 Alive 报文重建整个环。12.2 休眠失败常见原因某节点忘记调用NMRelease()一直持有网络请求Ring 报文中 SleepInd 标志被某节点覆盖该节点仍有通信需求T_WBS 设置过短总线上还有残余报文排查方法用 CANoe 抓取 Ring 报文检查 SleepInd/SleepAck 标志确认所有节点都已调用 NMRelease()检查 T_WBS 是否足够12.3 唤醒后建环失败常见原因Alive 报文发送次数不足RepeatMessageCount 太小多节点同时发送 Alive产生总线冲突节点地址配置错误导致逻辑后继计算异常12.4 NMPassive 与 NMBusSleep 混淆NMPassive节点醒着但不参与逻辑环不发送 Ring仍监听总线NMBusSleep节点真正休眠ECU 低功耗仅保留唤醒检测这是初学者最容易混淆的概念。NMPassive 是沉默的观察者NMBusSleep 是睡着了。12.5 与 AUTOSAR NM 的网关兼容在混合网络中部分 ECU 用 OSEK NM部分用 AUTOSAR NM网关需要实现协议转换OSEK 侧维护逻辑环处理 Alive/Ring/LimpHomeAUTOSAR 侧维护对等广播处理 NM PDU网关在两侧独立运行各自的 NM 状态机十三、OSEK NM 的历史地位与未来13.1 历史贡献2000~2015 年OSEK NM 是车载网络管理的事实标准广泛应用于大众、宝马、奔驰、丰田等 OEM定义了网络管理的基本范式节点监控、休眠唤醒、故障容错为 AUTOSAR NM 的设计奠定了理论基础13.2 当前状态OSEK/VDX 标准已冻结不再更新新项目普遍采用 AUTOSAR NM但大量存量车型仍在使用 OSEK NM部分 OEM 在 AUTOSAR 框架下保留了 OSEK NM 的变体实现13.3 学习价值即便在 AUTOSAR 时代学习 OSEK NM 仍有重要价值理解逻辑环/令牌传递有助于理解分布式系统的基本模式存量项目维护、售后诊断仍需 OSEK NM 知识AUTOSAR NM 的很多设计决策是对 OSEK NM 缺陷的改进理解前者才能理解后者十四、总结要点内容标准体系OSEK/VDX OSEK OS OSEK COM OSEK NM核心机制逻辑环Logical Ring 令牌传递Ring 消息NM 报文Alive建环/ Ring令牌传递/ LimpHome故障状态机三层嵌套NMOff/NMOn/NMShutDown → NMAwake/NMBusSleep → NMReset/NMNormal/NMLimpHome休眠机制Ring 报文携带 SleepInd/SleepAck 绕环传递全员确认后休眠唤醒机制唤醒事件 → Alive 报文 → 重建逻辑环故障处理超时检测 → 跳过故障节点 → 重建环 / LimpHome关键参数T_Typ / T_Max / T_WBS / Rx_Limt与 AUTOSAR 区别逻辑环 vs 对等广播点对点 vs 广播复杂 vs 简洁当前状态标准已冻结新项目用 AUTOSAR NM存量项目仍需维护OSEK NM 是汽车网络管理的经典教科书。它的逻辑环机制虽然比 AUTOSAR NM 更复杂但其中蕴含的分布式协调、故障容错、状态机设计思想至今仍是嵌入式网络工程师的必修课。参考资料OSEK/VDX Network Management Specification V2.5.3OSEK/VDX Operating System Specification V2.2.3AUTOSAR SWS_CANNM对比参考Vector AUTOSAR/OSEK Network Management 技术文档各 OEM 网络管理规范大众 TL、宝马 GS 等如果这篇文章对你有帮助欢迎点赞、收藏、转发有 OSEK NM 调试经验或疑问欢迎在评论区交流讨论。