ARINC 825机载CAN总线：物理层、标识符与错误处理解析

简介：ARINC825-2007协议文档面向航空电子、机载设备及机载网络测试验证人员，提供航空器内部CAN总线通信的通用标准化依据，可用于设备互联设计、测试评估与合规性参考。压缩包内仅含1个PDF文件，大小约1.96MB，保留标准原文的完整版式与条款结构，便于检索和引用。文档由AEEC起草、ARINC出版，正文覆盖机载CAN总线技术要求、适用范围、出口管理说明与免责声明，并明确“应当/必须”等措辞不改变其自愿性标准定位，也不强制设备供应商实施。已有295人学习，适合需要核对原文条款、梳理机载CAN网络设计边界或开展标准预研的工程师与院校读者。读者可据此定位通用标准化范围、责任边界及使用限制，为系统集成和测试文档编写提供可追溯依据。

1. ARINC 825-2007 是什么：给飞机里的设备定一套“讲同一种话”的规则

一架飞机里塞满了几十上百个电子设备，来自不同厂家，各自说着自己的“方言”。要让大气数据计算机、舱门传感器、燃油泵控制器这些互不相识的部件在毫秒级互相通报状态，光有一根线不够，还得有一套大家都认的说话规则。ARINC 825-2007 就是这套规则——它把汽车上早就用熟的 CAN 总线拿过来，针对机载环境重新立了一遍规矩：电气参数要多稳、报文怎么编号、数据用什么单位、出错之后怎么自己退出而不拖垮全网。这份标准 2007 年 11 月 15 日发布，起草方是航空电子工程领域的行业委员会，属于自愿性标准。搞懂它，你就明白了飞机内部那些“小设备之间”的数据是怎么稳稳当当地跑起来的。

2. 为什么天上飞的 CAN 需要一份专门的统一规定

2.1 汽车上跑得好好的 CAN，搬到飞机上为什么要另立规矩

CAN 总线在汽车上已经用了几十年，成本低、抗干扰、多节点共享一根线，听起来挺美。但汽车的用法和飞机的用法，底层诉求差得很远。

汽车线束短，最长也就几米，整车寿命十几年，坏了靠边停。飞机的线缆要从机头拉到机尾，几十米起步，一根总线穿过机身、机翼、发动机吊挂这些电磁环境复杂的地方；飞机服役周期动辄二三十年，维修记录要能追溯到具体批次；更关键的是，飞机上某个设备通信出问题，不会“靠边停”，所以设计时必须在最坏情况下还能保证关键功能不断。

这些差异落到工程上，就变成了对物理层的额外要求：收发器得能扛更宽的共模电压范围，要有显性超时保护，避免某个节点故障后一直占用总线；未上电的节点不能把总线拉成显性，否则整条网络瘫痪；接地的电位差要控制，因为机身各处的地电位并不一致。这些在汽车标准里或者可以不写，或者写得宽松，但机载场景下必须逐条写清楚，否则不同厂家的设备接在一起就会出问题。

打个比方：CAN 协议本身是一套语法，规定了句子怎么组、标点怎么打；而 ARINC 825 是在这套语法之上，补了一本“行业用语规范”——哪些词能用、同一个词在不同设备里意思必须一致、说话音量多大合适、话筒坏了怎么办。语法人人都会，规范才是能互换、能维修的前提。

2.2 一份标准真正要解决的四件事：互换、隔离、分配、验收

把整份标准读下来，会发现它反复围绕四个现实问题打转。

第一是互换性。同一位置的设备，A 厂家的坏了换成 B 厂家的，插上就能用，不用改线、不用改软件。要做到这一点，连接器引脚定义、电气参数、数据格式、单位、符号方向必须完全一致。标准里专门规定了数据格式、物理单位和轴定义与符号约定，就是为了防止“同样是俯仰角，一个用度一个用弧度，一个抬头为正一个低头为正”这种灾难。

第二是故障隔离。一个节点出问题，不能把整条总线拖下水。CAN 协议本身有这个机制：错误计数器累积到一定程度，节点先进入错误被动状态，再严重就进入总线关闭状态，自动退出总线。标准把这条路径的进入条件、退出方式、计数器如何监控都写清楚了，还要求节点周期性广播自己的健康状态，让系统层能提前发现问题。

第三是标识分配。CAN 报文靠标识符区分内容，29 位扩展帧理论上能编出五亿多种组合，但如果每个厂家自己随便定，接在一起就是一片混乱。标准定义了标识符的结构，把 29 位切成若干字段，分别承载“谁发的”“干什么用的”“发给谁”这类信息，让接收方能用硬件滤波器直接筛出自己关心的报文，不必占用 CPU 逐条判断。

第四是验收口径。一个设备声称“符合标准”，怎么验证？标准里大量使用 shall 和 must 这类词，把要求写成可逐条核对的条款，测试时一条条过，比“大概能用”靠谱得多。当然，这些词本身并不改变标准的自愿性质，也不意味着设备厂家必须采用——它只是说，如果你宣称符合，那就得符合这些条款。

2.3 网络域怎么划：把“谁跟谁说话”先画清楚

标准在系统概述部分先做了件事：描述网络域和跨域数据流。这不是画着玩的，而是在动手布线之前，先把通信关系捋清楚。

机载系统通常按功能分域，比如飞行控制相关的算一块，发动机相关的一块，客舱设备又是一块。每个域内部用一条 CAN 总线，域和域之间通过网关转发。这样划分的好处是：域内流量可控，故障影响范围有限，某个域的总线出问题不至于让整架飞机的电子系统都失联。

数据流的方向也要提前想好。哪些报文是周期性的状态广播，哪些是事件触发的，哪些需要跨域转发，转发时的延迟预算多少，这些都会反过来影响总线负载率的计算。一条 500 kbit/s 的总线，如果一堆节点都在高频发报文，负载率冲到 70% 以上，剩下的余量就不够应付突发，延迟会变得不可预测。

拓扑上，标准采用的是总线型结构，所有节点挂在一条主干上，两端做终端匹配。这种结构简单、成本低、易于扩展，但缺点也明显：主干断了，整条总线就废了。所以布线时对线缆的走向、固定、屏蔽都有要求，标准里在线缆特性、连接器/触点特性、安装与接地特性几节专门交代了这些细节。

3. 拆开看：这套标准里的物理层与数据链路层到底规定了什么

3.1 物理层：收发器、终端、接地偏移这些“看不见的坑”

物理层是最容易被忽视、又最容易出问题的地方。软件写得再漂亮，一对差分线接错终端，整条总线就废了。

标准在物理层部分先规定了节点特性，包括电磁防护要求和收发器要求。收发器的电气参数必须落在给定范围内，否则不同厂家的收发器接在一起时，电平判读会出现歧义——A 厂家认为这是显性，B 厂家认为是隐性，仲裁结果就不可预测了。

显性超时保护是机载 CAN 特有的一个设计。CAN 总线的显性电平优先，正常情况下这是好事，但假如某个节点的收发器卡在显性状态，整条总线会被它一直占着，所有通信停摆。所以收发器需要内置一个超时机制：检测到显性状态持续超过一定时间，自动退出，把总线让出来。这相当于给每个节点装了个断路器。

未上电节点的处理同样关键。设备断电时，收发器的输出级如果呈现低阻，就会把差分线拉偏，影响整条总线。标准要求这类节点在未供电时呈现高阻态，不干扰其他节点通信。这个细节在汽车上不那么苛刻，因为车上的设备基本同开同关；飞机上很多设备是分系统供电的，一部分关着、一部分开着的情况很常见。

网络终端和接地偏移是另外两个坑。总线两端需要终端匹配来吸收信号反射，具体接法标准里有规定；而接地偏移指的是不同节点之间的地电位差，飞机上长距离走线，这个差值可能达到几伏，超出收发器共模范围就会导致误码。所以安装和接地特性一节对搭接电阻、屏蔽层接地方式都有明确要求。

控制器这一侧，标准规定了总线速率、位编码/解码和位定时。位定时参数决定了采样点位置，采样点选得不对，长线传输时信号边沿的抖动就会采样出错。举个具体例子，给定位时钟和目标速率，要算出各段的时间份额：

# 位定时参数估算：把时钟分频后切成若干时间份额 clk_hz = 8_000_000 # 控制器时钟频率，实际取值看芯片手册 bit_rate = 500_000 # 目标位速率，单位 bit/s tq_total = clk_hz // bit_rate # 一个位时间里包含多少个时钟周期 prescaler = 4 # 预分频系数，从可选范围里挑 tq_per_bit = tq_total // prescaler # 每个位时间切成多少个时间份额 sample_point = 0.8 # 采样点位置，通常取 75%~87.5% # 采样点落在第几个时间份额之后 sample_seg = int(tq_per_bit * sample_point) print(f"每位 {tq_per_bit} 个 tq，采样点在第 {sample_seg} 个 tq 处")

这段代码只做参数估算，真正配寄存器时还要按芯片的分段规则（同步段、传播段、相位缓冲段）去分摊。参数的含义是：预分频决定每个时间份额多长，采样点位置决定控制器在一位信号的哪个位置读电平。采样点太靠前，信号还没稳定；太靠后，留给相位再同步的余量不够。长线缆传输延迟大，采样点就要往后挪一点。

3.2 数据链路层：帧、仲裁与硬件验收滤波

数据链路层规定的是报文怎么组织、谁先发、谁该收。

帧类型分四种：数据帧负责携带载荷，错误帧用来向全网通报检测到错误，远程帧用于请求数据，过载帧表示接收方还没准备好。日常通信绝大多数是数据帧。

数据帧里最关键的字段是标识符。CAN 有标准和扩展两种，标准帧 11 位，扩展帧 29 位。标准采用的是扩展帧，因为 29 位才有足够的空间切成多个有语义的字段。

仲裁机制是 CAN 的核心特色。多个节点同时想发报文时，靠标识符逐位比较，显性位压过隐性位，标识符数值小的优先。这个过程不破坏任何报文，输的那个节点自动退让，等总线空闲再重发。标识符数值的大小，实际上就代表了报文的优先级——所以标识符分配时，安全关键、实时性强的报文要分到数值更小的段里。

硬件验收滤波则是效率的关键。控制器的滤波器可以设置成只接收符合特定标识符模式的报文，不符合的直接在硬件层丢弃，不产生中断、不占用 CPU。假如总线负载是每秒几千帧，而某个节点只关心其中几十帧，没有滤波的话 CPU 会被中断淹没。

标准里的错误识别部分列了五类错误：位错误、位填充错误、CRC 错误、格式错误、确认错误。位填充是为了保证同步——发送方连续发出五个相同电平后必须插入一个相反电平；接收方如果看到六个相同电平，就知道出错了。CRC 错误是校验和不匹配，格式错误是帧结构不符合固定格式，确认错误是发送方在确认位时段没有收到任何接收方的显性应答。

3.3 错误处理与总线关闭：CAN 自带的“熔断机制”

CAN 的容错设计，核心是每个节点都维护两个计数器：发送错误计数器 TEC 和接收错误计数器 REC。发送出错，TEC 增加；接收出错，REC 增加；成功收发一次，计数减少。这个设计让偶发干扰不会立刻把节点踢下线，但持续出错的节点会被逐步隔离。

状态机大致分三段：错误主动、错误被动、总线关闭。错误主动状态下，节点检测到错误会主动发错误帧，把错误通报给全网；进入错误被动后，它仍然能收发，但发错误帧时只能发被动的错误标志，影响力被削弱；一旦 TEC 超过 255，节点进入总线关闭，完全停止收发，等系统层决定要不要恢复。

# 节点状态判定：依据 TEC / REC 的当前值 def node_state(tec: int, rec: int) -> str: if tec > 255: # 发送错误累计过重，主动退出总线 return "bus-off" if tec > 127 or rec > 127: # 仍可通信，但错误帧的影响力已被削弱 return "error-passive" return "error-active" # 示例：发送侧持续出错，接收侧正常 print(node_state(tec=140, rec=10)) # error-passive print(node_state(tec=260, rec=10)) # bus-off

参数说明：TEC 是发送错误计数器，REC 是接收错误计数器，两者的阈值由协议规定。上面的 127 和 255 是分界点，不是可随意调整的配置项。总线关闭之后，标准建议的恢复方式有两种：一种是硬件自动恢复，等总线空闲一段时间后重新接入；另一种是软件干预，由系统层确认故障原因已经排除再恢复。前者响应快，后者更可控。机载系统一般倾向于后者，因为一个反复出错又自动重连的节点，会让故障排查变得非常困难。

标准还要求对计数器进行监控，并且把 TEC、REC 的当前值放进周期性的节点健康状态报文里广播出去。这个做法很聪明：系统层不用等到节点彻底掉线才发现问题，而是能看着计数器的变化趋势提前介入。这相当于给人做体检，不是等倒下了才送医，而是看指标漂移就调整生活方式。

4. ARINC 825 的标识符结构与通信模型：谁能说话、说给谁听

4.1 一对多与点对点：CAN 上的两种说话方式

CAN 总线天然支持“一对多”的广播式通信：一个节点发出报文，总线上所有节点都能收到，谁需要谁就取走。这种方式适合状态广播——比如大气数据计算机每隔几十毫秒把当前的高度、空速、气压高度发一遍，需要的设备自己监听。

但有些通信是一对一的，比如某个控制器要给特定的执行机构下发指令，不希望其他节点误收。这在 CAN 上通过标识符的定向字段实现：接收方的硬件滤波器只放行目标地址匹配的报文，其他报文在硬件层就被丢弃。所以物理上还是一条广播总线，逻辑上却能切出多条独立的通信通道，标准里把这叫做逻辑通信通道。

这种设计的妙处在于省线。如果每个点对点连接都要独立走线，飞机上的线束会重得离谱。用一条总线加逻辑通道，既减少了线缆数量和重量，又保留了通信的灵活性——新增一个监听节点，只要滤波器配对，不用改布线。

4.2 29 位标识符被拆成了什么

标准花了不小的篇幅定义 CAN 标识符结构，这是它能“通用化”的关键之一。

29 位看着不少，但要同时表达“这条报文来自哪个系统”“属于哪类功能”“发给谁”“报文序号是多少”，其实并不宽裕。标准把这些位切成若干字段，每个字段负责一个维度。具体的位宽划分在文档的标识符结构一节里有明确的表，这里不逐一列数字，重要的是理解划分的思路。

举个通俗的例子：这就像快递面单。面单上有收件人、寄件人、单号、物品类别，各占一块固定区域。分拣员不需要读懂整张面单，只看收件人那一段就能决定往哪个格口扔。CAN 控制器也一样，它只看标识符里对应的那几位，就能决定收还是不收。

这种“按字段读”的方式带来两个好处。第一是滤波效率高，硬件比对几个位就行；第二是可扩展，新增一类功能时，只要往功能字段里分配一个新编码，不需要动整体结构。

标准还定义了逻辑通信通道的概念：同一个功能字段值，可以对应一组收发关系，形成一条虚拟通道。这样上层软件看到的是一组通道，而不是一堆零散的报文 ID，抽象层次清晰很多。

4.3 数据格式、单位与符号：最容易翻车的地方

互操作性这一节，是整份标准里最“接地气”的部分，因为这里规定的不是通信机制，而是数据的含义。

CAN 一帧数据帧最多携带 8 字节载荷，怎么把这 8 个字节解释成有意义的物理量，必须事先约定。标准规定了数据格式，包括整数和浮点数的编码方式、字节序、有符号数的表示方法。这些看起来是细枝末节，但两个厂家如果字节序理解相反，收到的高度值可能是个荒谬的数字，而且不会报错——协议层完全正常，只是数据是错的。这类问题最难查。

物理单位的规定同样关键。高度用英尺还是米，速度用节还是千米每小时，角度用度还是弧度，压力用帕还是磅每平方英寸。航空业历史上混用过英制和国际单位制，标准必须挑一套并明确写下来，否则跨系统数据交换时就得靠人肉换算，而人肉换算就是错误之源。

轴定义与符号约定是航空特有的坑。飞机的俯仰、滚转、偏航，哪个方向为正，不同厂家、不同机型可能有不同习惯。如果两个设备对“抬头为正”的理解相反，飞控系统收到的姿态数据就是反的。这种事在地面测试时可能因为飞机是平的而看不出来，一上天就暴露。所以标准明确规定坐标轴的定义和正负号约定，把这类隐患提前消灭。

配置文件和飞机功能这两节，则是把这些约定落到具体功能类别上，给每类功能一套推荐的参数集合。设备厂家按功能类别去实现，航空公司采购时按类别去选型，双方的沟通成本就降下来了。

5. 容易混淆的几个概念：别把 ARINC 825 和这些搞混

5.1 把 ARINC 825 等同于 CAN 2.0B

易混点：看到标准里满篇都是帧、仲裁、错误计数器，就觉得它就是 CAN 协议的另一个名字。

为什么容易混：标准的通信内核确实完全建立在 CAN 之上，数据链路层的机制几乎照搬，所以读起来非常像一份 CAN 协议说明书。

怎么区分：CAN 2.0B 定义的是“怎么把比特可靠地从 A 点送到 B 点”，它不关心你送的是什么、用什么单位、标识符怎么分配。ARINC 825 在这之上加了大量行业约定：标识符字段怎么切、健康状态报文长什么样、物理单位用哪套、轴的正方向朝哪边、收发器在未供电时呈现什么状态。可以把 CAN 看作发动机，ARINC 825 是把它装进飞机之后必须补齐的那一整套适配规范。只懂 CAN 不懂这套约定，接上飞机也跑不通。

5.2 以为它是来替代老式点对点总线的

易混点：新标准出来了，是不是老的单向、点对点数据总线就该淘汰了？

为什么容易混：技术演进通常是新的替代旧的，所以很容易顺手推出这个结论。

怎么区分：两者解决的是不同层面的问题。老式点对点总线是单向广播，一个发送端对一条线、一个或多个接收端，结构清晰、确定性极高，几十年来在安全关键链路上验证充分。CAN 这类多主总线胜在布线少、节点多、双向通信灵活，但仲裁带来的延迟不确定性是客观存在的。实际机型上往往是多种总线并存，各自负责擅长的部分：需要极确定、极简单的地方留给点对点方案，节点多、报文短、交互频繁的地方用 CAN 总线。标准本身也没说要取代谁，它只是给“用 CAN 的地方”定了一套统一规矩。

5.3 看到 shall / must 就当成强制法规

易混点：文档里那么多 must 和 shall，是不是意味着必须执行，不然就是违规？

为什么容易混：日常语境里 shall 就是“必须”，而且标准的行文非常像法规。

怎么区分：文档里专门有一节解释“shall 的使用”，明确说明这些词不改变标准的自愿性质。标准是行业共识的书面化，不是法律法规。厂家可以选择不采用这套标准，做自己的方案；但如果它宣称自己的产品符合该标准，那就得符合那些标了 must 或 shall 的条款。所以这些词的约束力是有条件的：不宣称符合，就不受约束；宣称符合，就得逐条兑现。另外，任何设备供应商都没有义务必须把标准里的某个元素做进产品，这一点文档写得很清楚。

5.4 把标识符 ID 当成设备地址

易混点：既然标识符能区分来源和去向，那它不就是设备的地址吗？

为什么容易混：网络协议里 ID 常常等同于地址，直觉上很容易套用。

怎么区分：CAN 的标识符标识的是“报文内容”，不是“设备身份”。同一条报文，可能被多个节点同时接收和使用；同一个节点，也会发出标识符完全不同的多种报文。标识符里的来源字段确实能表明是谁发的，但它的主要作用在于让接收方判断“这条报文我要不要”，而不是“这条报文是不是发给我的”。这也是为什么标准要花力气把 29 位切成多个字段：地址只是其中一小段，功能、通道这些信息同样要编码进去。把 ID 当纯地址用，会浪费掉大部分编码空间，也做不出高效的硬件滤波。

5.5 以为速率越高、通信越可靠

易混点：1 Mbit/s 肯定比 125 kbit/s 好，数据传得快，实时性自然强。

为什么容易混：速率和性能直觉上正相关，数字大的看着就厉害。

怎么区分：CAN 的位速率和总线长度是互相制约的。速率越高，单位时间内信号跑过的距离越短，允许的最大总线长度就越小。机身上一条贯穿几十米的总线，硬上高码率，信号边沿到了末端已经变形，采样点再准也读不出正确电平。另外，高码率意味着每个位的时间窗口更窄，对时钟容差、线缆延迟、节点间相位再同步能力的要求都更严。选速率的原则是够用就好：先算清楚这条总线上最坏情况的负载率和最大允许延迟，再回头挑一个留有余量的档位。盲目追高，最后往往是通信时好时坏，查起来毫无头绪。

6. 什么时候该用它，什么时候别硬套

判断要不要用这套标准，本质上是在问三个问题：你的设备多不多、报文短不短、对确定性的要求到什么程度。

先说适合的场景。机载设备数量多、单个设备要传的信息量小（几字节的状态量、指令量）、通信模式以周期性广播为主、需要不同厂家设备互换，这几种情况凑在一起，CAN 总线加 ARINC 825 的组合就很合适。典型的例子是一组传感器和执行机构挂在同一条总线上，彼此共享状态，某个设备坏了不影响其他设备继续工作，健康状态还能被系统层实时看见。

再说别硬套的情况。如果你要传的是一张图片、一段日志、一份配置文件，CAN 的 8 字节载荷会让你切片切到怀疑人生，帧数一多，总线负载立刻爆表，实时报文被挤得没地方待。如果你做的是延迟上界要求极严的控制回路，仲裁的“输者退让重发”机制虽然公平，但最坏情况下的等待时间需要严格推算，推不准就别用它扛关键链路。还有一种常见情况是拿它做板内短距离通信——两三个芯片之间几十厘米的连线，用 CAN 属于杀鸡用牛刀，成本和复杂度都不划算。

真到了要落地的时候，有几个动作建议提前做。第一，先把标识符分配表拉出来，按重要性排序，安全关键的报文分到数值小的段，别等到后期才发现优先级反了，改一次全表重来。第二，把总线负载率算到最坏情况，把所有节点的最大发送频率叠起来算，留出至少三成余量。第三，健康状态报文一定要实现，TEC 和 REC 的实时值比任何事后日志都管用，故障复现时能直接看出是哪个节点在拖后腿。第四，单位和符号约定在接口文档里写死，白纸黑字，不要口头确认。

我早年参与过一个模拟项目X，几个模块挂在同一条总线上，前期测试一切正常，装到整机上之后时不时丢帧。查了两周才发现，某个节点的收发器在断电状态下没有呈现高阻，把差分线拉偏了一点点，通电的节点勉强能通信，但误码率上去了，错误计数器慢慢累积，跑几个小时就进错误被动。当时如果一开始就把未供电节点的行为纳入测试用例，这个坑根本不用踩。从那以后我每次做总线相关的方案，都强制先把物理层的边界条件过一遍——断电、短路、终端缺失、地电位差，一个一个对着标准条款核。这些检查枯燥，但它们比任何调试技巧都省时间。

这份标准文档里完整的章节结构、参数表和条款定义，都在那份资料里，需要的时候翻出来对着查，比凭记忆猜要靠谱得多。希望帮到你。

本文还有配套的精品资源，点击获取