3. 车载网络基础

好，咱们今天来啃一块硬骨头——AUTOSAR 网络管理的状态机。说实话，这玩意儿是车载网络通信的“交通警察”。车上的 ECU 什么时候该睡觉，什么时候该醒着，什么时候该准备一下再睡，全靠它管。

我刚开始接触 AUTOSAR 时，觉得状态机不就是几个圈圈箭头嘛。后来在项目里被总线“假死”问题折腾了两周，才明白每个状态切换背后都是血泪教训。今天我把这些状态掰开揉碎了讲给你听。

3.1 状态机全景图：三个大状态，五个小状态

AUTOSAR NM 的状态机，说白了就三个大阶段：Bus-Sleep Mode（总线休眠）、Prepare Bus-Sleep Mode（准备休眠）、Network Mode（网络模式）。其中 Network Mode 又拆成三个子状态。

我习惯用一张图来记，你看下面这个 SVG 结构：

AUTOSAR NM 状态机全景图 Bus-Sleep Mode 总线休眠 Prepare Bus-Sleep 准备休眠 Network Mode（网络模式） Repeat Message 重复报文状态 Normal Operation 正常运行状态 Ready Sleep 准备睡眠状态 NM 网络请求 超时无请求 收到 NM 报文 重复结束 NM 静默超时 收到 NM 报文 Ready Sleep 超时 说明：实线箭头表示主动切换，虚线框表示 Network Mode 内部子状态

嗯，这张图你最好存下来。每次调试 NM 问题，我都是对着这张图找状态的。

3.2 Bus-Sleep Mode：ECU 的“深度睡眠”

Bus-Sleep Mode 是什么？就是 ECU 在总线上完全“闭嘴”的状态。不发送任何 NM 报文，也不处理应用报文。说白了，就是省电模式。

但这里有个关键点：ECU 的 CAN 收发器可能还在监听总线。为什么？因为要能被人叫醒啊。你想想看，如果收发器也断电了，那这个 ECU 就彻底失联了。

进入 Bus-Sleep Mode 的条件：

  • ECU 上电初始化完成后，默认进入 Bus-Sleep Mode
  • 从 Prepare Bus-Sleep Mode 超时无网络请求后进入
  • 从 Ready Sleep State 超时后，经过 Prepare 阶段再进入

我在一个项目中遇到过这样的坑：某个 ECU 在 Bus-Sleep Mode 下，收发器配置成了“只听模式”，结果总线上的唤醒报文它收到了，但没产生中断。后来查了三天才发现是收发器寄存器配错了。所以啊，休眠不是断电，是“待机”。

3.3 Prepare Bus-Sleep Mode：最后的告别

这个状态很有意思。它是个过渡态，持续时间很短。ECU 在这里做什么？

  • 停止发送 NM 报文：告诉其他 ECU “我要睡了”
  • 等待一个超时时间：通常是 NM 报文发送周期的 1-2 倍
  • 监听总线：如果这期间收到其他 ECU 的 NM 报文，立刻回到 Network Mode

我个人的理解是：这就像你准备关灯睡觉前，先问一句“还有人要说话吗？”没人回应，你就关灯。有人喊“等等”，你就继续开灯。

避坑指南：

我曾经在配置 Prepare Bus-Sleep 超时时间时，设得太短（只有 10ms）。结果 ECU 刚准备睡，总线上另一个节点发了个报文，它没来得及响应就直接睡了。后来那个节点一直等不到回应，整个网络都卡住了。建议这个超时时间至少设为 50ms 以上。

3.4 Network Mode 的三个子状态

Network Mode 是 ECU 正常工作的状态。它里面又分三个小状态，每个都有明确的任务。

3.4.1 Repeat Message State：刚醒来的“广播”

ECU 从休眠中醒来，或者刚上电，第一件事就是进入 Repeat Message State。在这个状态里，ECU 会连续发送 NM 报文，告诉全网：“我醒了，我在这里”。

这个状态有几个特点：

  • 发送次数固定：通常配置为 2-5 次重复发送
  • 发送间隔固定：一般是 NM 报文周期的 1/2 或 1/4
  • 必须完整执行：即使收到其他节点的 NM 报文，也要发完指定次数

为什么要这样设计？你想想看，如果 ECU 刚醒来只发一个报文，万一总线冲突没发出去，其他节点就不知道它醒了。多发几次，可靠性就上来了。

注意：

Repeat Message State 的发送次数不是越多越好。我见过一个项目配了 10 次重复，结果总线负载率直接飙到 80%。正常 2-3 次就够了。

3.4.2 Normal Operation State：正常工作模式

这是 ECU 最“舒服”的状态。在 Normal Operation State 下：

  • ECU 按正常周期发送 NM 报文（比如每 100ms 发一次）
  • ECU 正常收发应用报文
  • ECU 持续监听总线上的 NM 报文

这个状态会一直持续，直到满足两个条件之一：

  1. NM 静默超时：ECU 自己不再需要网络，并且总线上也收不到其他节点的 NM 报文，持续一段时间后进入 Ready Sleep State
  2. 收到网络请求：应用层告诉 NM “我还要用网络”，继续留在 Normal Operation

这里有个细节：NM 静默超时时间通常配置为 2-3 个 NM 报文周期。比如周期是 100ms，超时时间就是 200-300ms。为什么？因为要容忍偶尔丢一两个报文。

3.4.3 Ready Sleep State：准备入睡的“犹豫期”

Ready Sleep State 是个“准休眠”状态。ECU 已经不再发送 NM 报文了，但还在监听总线。如果这期间收到任何 NM 报文，立刻回到 Normal Operation State。

这个状态的设计初衷是什么？我个人的理解是：给 ECU 一个反悔的机会。比如某个 ECU 想睡了，但另一个 ECU 突然说“我还有数据要发”，那它就能立刻醒过来。

状态 发送 NM 报文 监听总线 超时后去向
Repeat Message 是（高频重复） 是 → Normal Operation
Normal Operation 是（正常周期） 是 → Ready Sleep
Ready Sleep 否 是 → Prepare Bus-Sleep

Ready Sleep 的超时时间怎么配？我建议设为 NM 报文周期的 1-2 倍。太短了容易误判，太长了浪费功耗。

一个典型的 NM 状态切换流程：

  1. ECU 上电 → Bus-Sleep Mode
  2. 应用层请求网络 → Prepare Bus-Sleep → Repeat Message State（发 3 次 NM 报文）
  3. 重复结束 → Normal Operation State（正常通信）
  4. 应用层释放网络，总线静默 200ms → Ready Sleep State
  5. Ready Sleep 超时 100ms 无 NM 报文 → Prepare Bus-Sleep Mode
  6. Prepare 超时 50ms 无请求 → Bus-Sleep Mode

3.5 状态切换的“潜规则”

讲完每个状态，我再补充几个实际项目中容易踩的坑：

  • 状态切换不能跳级：比如从 Bus-Sleep 不能直接跳到 Ready Sleep，必须经过 Prepare 和 Repeat Message。这是规范强制的。
  • NM 报文优先级要高：我习惯把 NM 报文的 CAN ID 设得比应用报文高，这样即使总线负载高，NM 报文也能优先通过。
  • 超时时间要留余量：晶振误差、总线延迟都会影响计时。我曾经把超时时间设得刚刚好，结果低温环境下 ECU 频繁误判，后来加了 20% 的余量就稳了。

调试小技巧：

用 CAN 工具抓总线报文时，重点关注 NM 报文的发送间隔和重复次数。如果发现某个 ECU 的 NM 报文间隔忽大忽小，大概率是它的状态机跑飞了。我遇到过两次，都是因为中断优先级配置不当导致的。

好了，AUTOSAR NM 状态机的基本框架就是这样。每个状态都有它存在的理由，不是随便画出来的。你把这些状态切换的逻辑理清了，车载网络管理这块就算入门了。

← 上一章 📖 返回目录 下一章 →