2. AUTOSAR基础

好,我们正式开始啃 AUTOSAR 网络管理的核心概念。

这四个词——节点(Node)、集群(Cluster)、网络状态(Network State)、PDU——是整个 NM 模块的基石。你后面写的所有代码、配的所有参数,都是在跟这四个东西打交道。

我个人习惯,先把它们拆开讲透,再串起来看关系。

2.1 节点(Node)——网络上的“人”

节点,说白了就是 一个 ECU。在 AUTOSAR 语境下,一个 Node 就是一个运行着 NM 模块的电子控制单元。

每个节点都有一个唯一的标识,叫 Node ID。这个 ID 在同一个 Cluster 里不能重复。我见过有人把 Node ID 配成一样的,结果网络上一堆“同名”的 ECU 在打架,总线直接瘫痪。嗯,那场面挺尴尬的。

Node 的核心职责:
  • 发送自己的 NM 报文(告诉别人“我还活着”)
  • 接收并处理其他节点的 NM 报文
  • 根据网络状态决定自己该睡还是该醒

每个节点内部,NM 模块会维护一个 节点状态机。这个状态机决定了节点当前的行为。后面我们会专门讲状态机,这里先记住:一个节点就是一个独立的行为主体。

2.2 集群(Cluster)——网络上的“圈子”

一个 Cluster 就是一组 需要协同睡眠/唤醒的节点集合。

为什么要有 Cluster?你想想看,一辆车上可能有几十个 ECU。有些 ECU 是跟动力相关的,必须时刻在线;有些是跟舒适相关的,可以在你锁车后睡觉。你不能让动力域的 ECU 跟着舒适域一起睡,对吧?

所以,AUTOSAR 把网络划分成多个 Cluster。每个 Cluster 内部独立进行网络管理。不同 Cluster 之间互不干扰。

特性 说明
Cluster ID 集群的唯一标识,用于区分不同的 NM 域
成员节点 属于该 Cluster 的所有 Node 列表
通信介质 CAN、FlexRay、Ethernet 等
NM 报文 ID 每个 Cluster 有专用的 NM 报文 ID 范围
我的经验: 在项目初期,Cluster 的划分一定要跟系统架构师反复确认。我曾经遇到一个项目,把网关和车身域放在同一个 Cluster 里,结果网关一睡,整个车身域都失联了。后来不得不重新划分 Cluster,改了一堆配置表。

2.3 网络状态(Network State)——节点的“清醒程度”

网络状态,描述的是 一个节点当前在网络中的活跃程度。

AUTOSAR NM 定义了三种基本状态:

  • Network Mode(网络模式):节点完全清醒,可以收发应用报文和 NM 报文。
  • Prepare Bus-Sleep Mode(预休眠模式):节点准备睡觉,但还在监听总线,防止有人叫它。
  • Bus-Sleep Mode(总线休眠模式):节点已经睡了,几乎不消耗功率,只等唤醒事件。

这三种状态之间怎么跳转?靠的是 NM 报文 和 定时器。

注意: 很多初学者以为“休眠”就是完全断电。不是的。Bus-Sleep Mode 下,节点的 NM 模块仍然在监听唤醒信号(比如总线上的特定电平变化或唤醒帧)。只是应用层不工作了。

我举个例子。你锁车离开,车上的舒适域 ECU 开始进入 Prepare Bus-Sleep。如果 2 秒内没有收到任何 NM 报文,它们就安心地睡过去了。但如果你突然用钥匙解锁,总线上的唤醒信号会立刻把它们全部叫醒。

2.4 PDU(Packet Data Unit)——网络上的“消息信封”

PDU,全称 Packet Data Unit。在 AUTOSAR 里,它是 数据在通信栈中传递的最小单元。

你可以把 PDU 想象成一个信封。信封上写着收件人地址(PDU ID),里面装着信的内容(数据)。NM 模块发送和接收的,就是这种“信封”。

NM 相关的 PDU 主要有两种:

  1. NM PDU:专门用于网络管理的报文。里面包含源节点 ID、控制位向量(比如“我要睡觉了”的标志)等。
  2. Application PDU:应用数据报文。NM 模块不关心它的内容,只关心它是否存在(有应用 PDU 在发,说明节点还在忙,不能睡)。
NM PDU 的典型结构:
Byte 0:    源节点 ID (Node ID)
Byte 1:    控制位向量 (Control Bit Vector)
  Bit 0:    Repeat Message Request
  Bit 1:    Sleep Indication
  Bit 2-7:  保留
Byte 2-7:  用户数据 (User Data, 可选)

这里有个坑。控制位向量里的 Sleep Indication 位,是节点告诉别人“我想睡了”。但注意,这只是个请求。其他节点如果还在忙,可以忽略这个请求,继续发自己的 NM 报文。只有所有节点都同意睡了,网络才能真正进入 Bus-Sleep。

我曾经在调试一个项目时,发现网络总是无法进入休眠。抓了总线日志一看,有个节点的 Sleep Indication 位一直没置起来。查了半天,原来是那个节点的应用层有个定时器没关,导致 NM 模块认为“还有事要做”,所以一直不发睡眠请求。嗯,这种问题排查起来最费时间。

2.5 四个概念的关系

好了,四个概念都讲完了。它们之间是什么关系?

我画了一张图,帮你理清思路。

AUTOSAR NM 核心概念关系图 Cluster(集群) Node A ID: 0x01 Node B ID: 0x02 Node C ID: 0x03 总线(CAN / FlexRay / Ethernet) Network Mode (清醒) Prepare Bus-Sleep (准备睡) Bus-Sleep Mode (休眠) PDU:节点通过总线发送/接收 NM PDU,驱动网络状态转换 每个节点独立维护自己的网络状态,但通过 NM 报文协同

从这张图你可以看到:

  • Cluster 是容器,里面装着多个 Node。
  • 每个 Node 有自己的 Network State,状态之间可以转换。
  • PDU 是节点之间沟通的载体,节点通过发送和接收 NM PDU 来协调彼此的状态。

记住一句话:NM 的本质,就是一群节点通过 PDU 交换信息,共同维护一个 Cluster 内的网络状态。

一个小练习: 你可以试着在纸上画一个 Cluster,里面放 3 个节点。然后模拟一下:当 Node A 想睡觉时,它发送的 NM PDU 里 Sleep Indication 位会置 1。Node B 和 Node C 收到后,如果自己也没事了,就会回复同样的标志。当所有节点都同意后,整个 Cluster 进入 Bus-Sleep。这个过程,就是 NM 的核心逻辑。

好了,核心概念就讲到这里。这四个概念会贯穿整个课程,后面每一章都会用到。你先把它们理解透,后面学状态机、定时器、配置工具的时候,就会觉得顺很多。