ARINC825机载CAN可靠性：位定时、仲裁与错误遏制

简介ARINC825-2007协议是面向航空电子、机载网络与CAN总线工程领域的技术标准文档适合飞机制造商、设备供应商、航空公司维修站以及从事机载通信设计、测试和适航评估的工程师查阅。文档围绕机载控制器局域网络CAN总线协议的通用标准化展开给出设备间数据交换的技术要求与实施边界并说明其出口管理属性、免责声明及自愿性标准定位可用于指导相关组件、系统和设备的测试、评估、安装与操作。资源包共1个PDF文件约1.96MB保留AEEC起草、ARINC出版的规范原文便于按条款核对定义与技术细节。已有295人学习读者可借此理解航空级CAN总线的兼容性要求、标准术语含义及供应商合规声明的边界为机载网络方案论证和资料查证提供依据。1. 机载 CAN 的难点不在波特率而在「谁在什么时候能说话」很多人第一次翻 ARINC825 会有点失望位定时、仲裁、CRC、错误帧几乎全是 CAN 2.0B 和高速 CAN 电气规范里的老熟人。真正值钱的地方是它把这套东西从「能跑就行」抬到了「可以被审查、可以被证明」网络先划域再接线29 位标识符按固定位段切分采样点位置和传播裕度要算出来错误计数器涨到什么程度节点必须停止发送健康状态多久广播一次、载荷里放什么。车上的 CAN 追求的是成本与灵活机上的 CAN 追求的是可验证的最坏情况。同一颗控制器放在两个场景里配置参数、裕度计算、故障处理逻辑几乎是两套东西。2. 物理层不是接线图位定时、端接与地偏移如何决定误码率物理层这一层最容易被当成「照着参考设计抄一遍」的活儿实际上它承担了整个协议的确定性底座。2.1 先划网络域再谈线和速率标准在第 2 章先讲网络域、跨域数据流、拓扑和协议架构然后才进物理层参数这个顺序并非随意安排。CAN 是共享介质、广播式、无交换机的总线任何一处电气故障、任何一个节点持续输出显性电平都会波及整个域内的所有通信。先划域本质是先定「故障域半径」——域内节点数量、线缆总长、支线长度、端接点位置、位速率都是互相牵制的变量脱离域边界去谈某个参数合不合格没有意义。域一旦定下来几个量就基本锁死了域内节点数决定总线负载电容和等效阻抗线缆总长决定单向传播延迟支线长度决定反射能量而这三者又共同决定位时间里能留多少传播段余量。所以物理层参数不是「查表抄一个」而是从域的几何结构反推出来的。跨域数据流是另一个容易被低估的点。域与域之间通过网关衔接网关做的不是简单转发两端位速率可能不同标识符分配空间各自独立数据格式分辨率、偏移、字节序也可能不一致。常见的实现思路是网关内部维护一张映射表把源域的标识符和周期重映射成目的域的形态并在速率不匹配时做缓冲和降采样。这里翻车的典型场景是直接透传——源域 10 ms 周期的事件帧进了目的域瞬间把目的域的带宽吃掉一大块。域边界上的网关更像是协议翻译器而不是路由器。2.2 一个位时间里塞了什么同步段、传播段与两个相位缓冲段CAN 的位时间不是一个方波周期而是被切成四段同步段固定 1 个时间份额、传播段、相位缓冲段 1、相位缓冲段 2。采样点落在相位缓冲段 1 结束的位置。这个结构存在的唯一理由是要在一个位时间内容纳「信号从发送节点出发、跑到最远节点、再跑回来」的往返延迟同时留出再同步的余量。传播段必须覆盖两倍的物理延迟收发器内部回环延迟加上线缆单向传播延迟再乘 2。原因在于仲裁期间一个节点发出显性位后必须在自己的采样点之前看到最远节点的电平状态否则两个节点会就「谁赢了仲裁」产生分歧进而导致位错误。这是 CAN 最硬的一条时序约束也是长线缆、多节点、慢收发器场景下最容易配错的地方。/* 以 500 kbit/s、CAN 时钟 8 MHz 为例的位定时配置 */ typedef struct { uint32_t prescaler; /* 分频8 MHz / 1 8 MHz 的时间份额时钟 */ uint32_t prop_seg; /* 传播段吸收收发器延迟 线缆传播 节点间相位差 */ uint32_t phase_seg1; /* 相位缓冲段 1采样点之前的再同步余量 */ uint32_t phase_seg2; /* 相位缓冲段 2采样点之后的再同步余量 */ uint32_t sjw; /* 再同步跳变宽度一次最多调整几个时间份额 */ } can_bit_timing_t; static const can_bit_timing_t arinc825_500k { .prescaler 1, /* 1 个时间份额 125 ns */ .prop_seg 8, /* 8 个时间份额 1.0 us覆盖最坏往返传播 */ .phase_seg1 4, /* 4 个时间份额 */ .phase_seg2 3, /* 3 个时间份额 */ .sjw 3 /* 不超过 phase_seg2工程上一般也不超过 4 */ }; /* 位时间 1 8 4 3 16 个时间份额 2 us对应 500 kbit/s * 采样点 (1 8 4) / 16 81.25% */这段配置里有三个参数值得单独说。prescaler决定时间份额的粒度粒度越细采样点位置越能精细调整但对时钟抖动更敏感prop_seg是唯一一个「必须按物理尺寸算」的参数节点越多、线越长它就越不能省sjw决定再同步时一次能纠正多少相位偏差上限受相位缓冲段 2 约束配大了会在强干扰下把采样点拽到危险位置。采样点位置是另一个常被忽略的量。车规场景里 75% 左右很常见机载长线缆和级联收发器会带来更大的累积抖动一般会把采样点往 80% 之后推。这不是玄学是抖动预算算出来的所有节点的振荡器容差、收发器延迟不对称、线缆传播差异叠加起来必须落在采样点之前的裕度里。2.3 端接与地偏移差分电压之外还有一条共模红线高速 CAN 的端接规则很朴素总线物理两端各一个 120 欧姆中间节点不允许再并端接支线尽量短。两个 120 欧姆并联后驱动器看到的是 60 欧姆负载这个值决定了显性电平的电流和差分幅度。多并一个端接负载阻抗掉到 40 欧姆差分幅度被压低、上升沿变缓、反射加剧通信距离和误码率一起变差。这类问题在台架上往往看不出来因为线短、节点少一上整机就原形毕露。地偏移是机载环境里更隐蔽的一条线。CAN 收发器看的是差分电压但它的输入级有一个有限的共模范围经典高速 CAN 器件大致在负几伏到正几伏这个量级。机上不同设备各自就近接地接地阻抗、回流路径、屏蔽层处理方式都不一样两个节点之间的地电位差可能远超台架上的想象。一旦共模电压把收发器推出线性区差分判决就会出错表现是零星的位错误和错误帧而不是干脆断链——这种「偶发、不可复现、换个位置就好」的故障最消耗联试时间。标准里把线缆特性、连接器与触点特性、安装与接地特性、网络端接、地偏移放在同一节讲逻辑就在这里它们不是五个独立参数而是一套共模与阻抗预算的不同侧面。2.4 dominant timeout 与未供电节点两条最容易被漏掉的硬件防线有一条故障模式在实验室里几乎不会出现但在整机上后果极重某个节点的收发器损坏持续往总线上输出显性电平。因为显性是「线与」的支配态整条总线会被永久拉低所有节点都无法发出哪怕一个隐性位通信彻底停摆。这类故障靠软件无法恢复只能靠收发器内部的显性超时保护检测到发送端连续输出显性超过设定时间就自动切断发送通路把总线释放出来。另一条是未供电节点。设备断电后如果它的总线引脚呈现低阻就会像一个负载一样挂在总线上把差分线拉死。合格的设计要求收发器在掉电时总线引脚呈高阻必要时还要串隔离电阻或加隔离器件。这一条在台架上几乎不会被测到因为台架上的设备都通着电。注意整机联试前务必做一次「断电节点挂总线」测试把每个节点单独断电后观察总线波形与错误计数这项测试能提前暴露大部分硬件层隐患。3. 数据链路层仲裁、滤波与错误遏制是怎么一起工作的数据链路层是 ARINC825 里技术密度最高的部分几乎所有联试问题最终都会归结到这里的某一条机制上。3.1 非破坏性仲裁的代价优先级是设计出来的不是碰运气CAN 的仲裁靠「线与」实现显性覆盖隐性标识符数值越小优先级越高冲突的节点在逐位比较中自动退出赢家继续发送且不损失时间——这就是「非破坏性」的含义。这套机制很优雅但代价明确优先级完全由标识符数值决定一旦分配下去低优先级报文的最坏响应时间就只能靠离线计算来保证。在机载场景里这意味着标识符分配本身就是一次设计活动。哪些参数是飞行控制回路里的、哪些是状态显示用的、哪些是维护数据必须在分配阶段就分层而不能等联试时发现某个参数更新抖动再回头改。事件型报文故障上报、离散量变化如果频率不受控很容易在短时间内占满仲裁窗口把周期型关键帧饿死。常见的工程做法是给事件帧加最小发送间隔并在带宽预算里为关键周期帧预留固定份额。参数类别优先级倾向发送方式分配时的约束控制回路反馈量高ID 数值小固定周期预留带宽最坏响应时间必须算设备状态与健康中固定周期周期可放宽但不能被饿死离散量与故障事件中高事件触发必须设最小发送间隔维护与诊断数据低事件或按需允许被延迟但要防累积3.2 验收滤波把 CPU 从中断风暴里捞出来总线上的每一帧对每个节点都是可见的但一个节点通常只关心其中很少一部分。如果所有帧都触发中断CPU 会被中断风暴淹没尤其在 500 kbit/s 满载时每秒上千帧的情况下。硬件验收滤波器解决的就是这个问题它在控制器内部对标识符做位掩码比较只有匹配的帧才进入接收 FIFO 并触发中断。/* 典型的掩码比较值滤波器mask 为 1 的位必须与 code 一致为 0 的位忽略 */ typedef struct { uint32_t code; /* 期望的标识符位型 */ uint32_t mask; /* 关心哪些位 */ } can_filter_t; /* 只想接收源地址字段等于 0x21 的报文其余位全部放行 */ static const can_filter_t filter_src_0x21 { .code (0x21u SRC_ADDR_SHIFT), .mask (0x1Fu SRC_ADDR_SHIFT) /* 假设源地址占 5 位 */ };这段代码的意义要结合标识符结构来读。掩码滤波能生效的前提是「想过滤的字段」在标识符里占据固定位段。ARINC825 把源地址、目的地址这类字段钉在固定位置正是为了让硬件滤波器可以按发送方或接收方做粗筛而不必把所有帧都搬进内存再软件判断。这也解释了为什么标识符结构一旦定下来就极难改动它同时约束了硬件滤波器配置、驱动层分发逻辑和上层软件的路由表。实际配置时还有个细节滤波器通常成组存在一组的 code 和 mask 是配对的改组配置前必须先让该组退出工作状态否则会出现短暂的「收错帧」窗口。这个窗口极短但在高负载总线上足以漏掉关键帧。3.3 五类错误识别错误帧为什么能被所有节点「同时」发出CAN 定义了五类错误位错误、位填充错误、CRC 错误、格式错误、应答错误。位错误是发送节点回读到的电平与自己发出的不一致位填充错误是连续五个相同电平之后第六位没有按规定反转CRC 错误是接收方算出的校验与帧内 CRC 字段不符格式错误是固定格式位段出现了非法电平应答错误是发送节点在应答槽没有收到任何节点的显性应答。这套机制的精妙之处在于「全局一致」任何检测到错误的节点都会在紧接着的位时间里发出错误标志而错误标志本身会破坏当前的位填充规则从而让所有其他节点也检测到错误并加入。最终结果是一次局部错误被放大成一次全网可见的、时间上对齐的错误事件出错帧被所有节点一致丢弃发送方自动重传。这就是 CAN 不需要逐帧确认却能保证数据一致性的底层原因。错误标志分两种形态错误主动节点发 6 个连续显性位错误被动节点发 6 个连续隐性位。后者不会破坏总线上的其他通信这是被动状态的设计意图——一个自身可靠性存疑的节点不应该再有权力去打断别人的正常通信。3.4 TEC/REC 与 bus-off一个节点什么时候必须不再发送每个节点维护两个计数器发送错误计数 TEC 和接收错误计数 REC。规则很简单也很有效发送出错 TEC 加 8接收出错 REC 加 1成功发送 TEC 减 1成功接收 REC 减 1有条件。计数器的值决定节点状态两者都低于 128 是错误主动任一达到 128 进入错误被动TEC 超过 255 则进入 bus-off——节点必须从总线上完全退出不再发送任何内容。/* 错误遏制状态机核心判断阈值取自 CAN 错误计数规则 */ typedef enum { ERR_ACTIVE, ERR_PASSIVE, BUS_OFF } node_state_t; static void can_error_update(node_ctx_t *n, int tec_delta, int rec_delta) { n-tec clamp(n-tec tec_delta, 0, 256); /* 上限截到 256 */ n-rec clamp(n-rec rec_delta, 0, 256); if (n-tec 256) { n-state BUS_OFF; /* 发送错误越界必须退出总线 */ n-bus_off_since now_ms(); /* 记录时刻供受控恢复使用 */ } else if (n-tec 128 || n-rec 128) { n-state ERR_PASSIVE; /* 只能发隐性错误标志不再干扰总线 */ } else { n-state ERR_ACTIVE; } }TEC 加 8 而 REC 加 1 的不对称设计体现了「谁的错谁承担」的思路发送方对总线的影响更大所以惩罚更重这样能更快把持续发送失败的节点隔离出去。进入被动状态的节点在发送完一帧后还必须额外等待一段挂起传输时间才有资格参与下一次仲裁进一步降低它对总线的干扰。bus-off 之后的恢复策略是这份规范里比较有工程智慧的一处。汽车领域常见做法是检测到总线空闲就自动恢复代价是一个存在硬件故障的节点会反复「复活—出错—再退出」把总线周期性搅乱。机载场景更倾向受控恢复延迟一段时间再尝试同时限制单位时间内的恢复次数超过阈值就锁定在 bus-off 并上报。/* 受控恢复延迟 次数上限避免抖动节点反复污染总线 */ #define BUS_OFF_RECOVERY_DELAY_MS 1000u #define BUS_OFF_MAX_RETRY 3u static void bus_off_recovery_tick(node_ctx_t *n, uint32_t now) { if (n-state ! BUS_OFF) return; if (now - n-bus_off_since BUS_OFF_RECOVERY_DELAY_MS) return; if (n-retry_count BUS_OFF_MAX_RETRY) { n-locked_out 1; /* 锁定并上报等待维护介入 */ return; } n-retry_count; can_controller_reset(n); /* 重新初始化并等待 128 次 11 位隐性 */ }4. 标识符与互操作ARINC825 真正「航空化」的那部分前面三章讲的是 CAN 的共性这一章讲的是 ARINC825 把通用 CAN 改造成航空可用协议时动的手脚。4.1 29 位 ID 的分段为什么源地址要放在固定位段通用 CAN 只规定标识符是 11 位或 29 位怎么用完全自由。自由带来的后果是每家供应商一套编码联试时先花两周对齐标识符含义。ARINC825 的核心动作之一就是把 29 位扩展标识符按语义切成若干固定字段功能或参数码、源节点地址、目的节点地址广播时用特定值表示并预留优先级相关位。字段示意承载内容固定的意义参数/消息码这个报文代表哪个物理量或功能让接收方能按参数索引而不是按发送方索引源地址谁发的支持硬件按发送方滤波目的地址发给谁或广播支持点对点与一对多两种通信模式优先级相关位影响仲裁次序保证关键参数的确定性字段宽度和精确位置以标准正文为准但设计逻辑是清晰的一旦这些字段的位置固定硬件滤波器、驱动层路由、上层参数表就可以三层解耦。硬件按源地址粗筛驱动按参数码分发应用层只认参数名。这种分层在节点数量上去之后价值极大——新增一个节点不需要改动其他节点的接收逻辑只要它发送的参数码在全局分配表里。# 按固定位段拆解 29 位标识符字段宽度为示意实际以标准正文为准 SRC_SHIFT, SRC_BITS 8, 5 DST_SHIFT, DST_BITS 13, 5 PARAM_SHIFT, PARAM_BITS 18, 11 def decode_can_id(can_id: int) - dict: return { src: (can_id SRC_SHIFT) ((1 SRC_BITS) - 1), dst: (can_id DST_SHIFT) ((1 DST_BITS) - 1), param: (can_id PARAM_SHIFT) ((1 PARAM_BITS) - 1), prio: can_id 0x1F, # 低位参与仲裁数值越小越优先 }这段代码在联试阶段非常实用抓包日志里全是十六进制标识符人眼根本看不出是哪个节点在发哪个参数先解一遍再打印排障效率完全不同。4.2 数据格式、轴系与符号约定把「正负号」写进标准数据载荷的互操作性问题是航空电子领域的老问题。同一个物理量不同供应商可能用不同的分辨率、不同的偏移量、不同的字节序甚至对正方向的定义都相反——俯仰角抬头为正还是低头为正横滚角左滚为正还是右滚为正这类约定不统一联试时看到的现象是「数值对但符号反」排查方向会一路跑偏到传感器上。标准用两件事解决它一是定义统一的数据格式包括编码类型、分辨率、偏移和无效值标记二是定义轴系与符号约定把「正方向朝哪」写进规范。它还按飞机功能和物理单位组织 profile把「这个参数用哪个单位、什么量程、什么精度」固定下来。常见的实现思路是在参数表里为每个参数写清单位、缩放因子、偏移、有效范围和无效值编码接收方先判断有效性再做缩放而不是拿到原始字节直接乘系数。这里有一条血泪经验无效值一定要显式定义并单独判断。用全 1 表示「数据不可用」是常见做法但如果接收方没做这个判断就会把无效值当成一个极大的合法数值送进控制回路后果比丢帧严重得多。4.3 周期节点健康状态把错误计数器从本地黑匣子搬上总线CAN 的 TEC 和 REC 本来是节点私有的只影响自己的状态机。总线出问题时维护人员能看到「错误帧变多」却无法回答「是谁在制造这些错误帧」。ARINC825 的做法是要求节点周期性地广播自身健康状态载荷里包含当前的 TEC、REC 值和节点状态机状态。这个设计看似平淡实际解决了一个非常实际的定位问题错误是全局可见的但错误源是局部的。把局部计数器搬到总线上之后任何接入总线的分析设备都能直接看到「某个节点的 TEC 在持续上涨」从而把排查范围从整条总线收缩到一个设备。这是把可观测性做进协议本身而不是依赖外挂的诊断工具。import struct def parse_node_health(payload: bytes) - dict: 周期健康状态载荷解析字段布局为示意实际以标准正文为准 tec, rec, state struct.unpack_from(BBB, payload, 0) return { tec: tec, # 发送错误计数持续上涨说明本节点发不出去 rec: rec, # 接收错误计数上涨说明本节点收不对 state: state, # 0错误主动 1错误被动 2bus-off healthy: state 0 and tec 64 and rec 64, }解读这份数据有个技巧TEC 涨而 REC 不涨问题多半在这个节点自己的发送通路收发器、端接、线序REC 涨而 TEC 不涨问题在它听到的总线质量别的节点在拉低信号或者地偏移两个都涨通常是物理层共性问题。这套判读方法比单纯看「错误帧计数」精确得多。5. 联试现场最常见的五个坑从现象倒推机制5.1 采样点按车规配长线缆上偶发位错误现象台架上一切正常装到整机上以后每隔几分钟出现一批错误帧位置随机节点不固定重启后消失。原因位定时沿用了车规模板采样点落在 75% 附近传播段只留了很小的余量。整机线缆长度和节点数量上来之后往返传播延迟超出了传播段覆盖范围最远节点在发送节点的采样点之后才把电平送回来仲裁阶段出现「两个节点都以为自己赢了」的情况回读电平不一致就报位错误。解决按实际线长和收发器延迟重新计算传播段把采样点推到 80% 以上同时确认再同步跳变宽度不超过相位缓冲段 2。改完之后要用示波器在总线最远端的节点上实测采样点位置而不是只看配置寄存器。5.2 多并了一个 120 欧姆波形幅度直接掉一半现象总线差分幅度明显偏低上升沿变缓通信距离缩短负载重的时候错误帧集中出现。原因某个节点的电路板上焊了板载端接电阻整机集成时没有跳开总线上出现了三个甚至更多端接点等效负载阻抗从 60 欧姆掉到 40 欧姆以下。解决明确规则——端接只保留物理两端中间节点一律断开板载电阻。集成检查清单里加一条「断电测总线电阻」两个端接点时测得的直流电阻应该在 60 欧姆左右明显偏低就说明多并了。5.3 某个节点一断电整条总线跟着瘫现象单独给某个设备断电整条总线通信中断重新上电后恢复正常。原因该设备的收发器在掉电状态下总线引脚不是高阻把差分线拉在某个固定电平上或者通过内部保护二极管形成低阻通路。这类问题在台架上测不出来因为台架上的设备都通着电。解决选型阶段确认收发器的掉电高阻特性必要时串隔离电阻或采用隔离型收发器。整机联试前把「逐个断电、观察总线」列为必做项每个节点都过一遍。5.4 bus-off 后无限自动重连总线周期性抽风现象总线每隔一段时间出现密集错误帧持续几百毫秒后恢复反复循环日志里能看到某个节点频繁进出 bus-off。原因节点配置成了检测到总线空闲就自动恢复。存在硬件隐患的节点每次恢复后短时间内再次出错TEC 迅速涨回 255再次退出每次进出都往总线上喷一批错误帧。解决改成受控恢复——延迟一段时间再尝试限制单位时间内的恢复次数超过阈值锁定并上报。同时把健康状态报文里的 TEC/REC 接进监控锁定节点后能直接定位到设备而不是靠拔线试。5.5 ID 随手分配低优先级周期帧被饿死现象某些参数的更新周期忽长忽短负载低的时候正常一旦有事件上报就出现明显抖动甚至丢帧。原因标识符分配时没做优先级规划事件帧拿到了数值更小的 ID。事件密集触发时事件帧在仲裁中持续获胜周期帧一直退让。CAN 的非破坏性仲裁只是「不浪费带宽」并不保证公平。解决按参数关键度分层分配标识符数值事件帧设置最小发送间隔并在设计阶段做一次最坏响应时间计算确认关键周期帧在满负载叠加事件风暴的情况下仍能满足周期要求。6. 设计取舍标准给的是边界验证方法才是落地的那一半把这份规范读透之后会发现它真正提供的是可审查的边界而不是现成的实现方案。仲裁、位定时、错误遏制这些机制在通用 CAN 里早就存在ARINC825 做的是把它们参数化、把裕度要求写清楚、把可观测性做进协议让「这套网络在最坏情况下仍然可控」变成一件可以被论证的事。由此产生几组必须自己权衡的取舍。确定性与灵活性固定标识符分段换来了硬件滤波和三层解耦代价是参数码分配表成为全局资源任何新增参数都要走协调流程这在快速迭代阶段会显得笨重。本地处理与全网可见把 TEC/REC 广播上总线提升了可诊断性代价是每个节点都要周期性占用带宽发送健康状态节点数多的时候这笔开销不能忽略。自动恢复与受控恢复前者可用性高后者可控性好机载场景通常选后者但这意味着必须配套设计一套锁定后的维护流程否则锁死的节点没人管。取舍点偏向灵活/可用偏向确定/可控机载常见选择标识符分配动态或局部自定义全局固定分段全局固定错误恢复立即自动恢复延迟 次数限制 锁定受控恢复健康状态按需查询周期广播周期广播数据格式各设备自定义统一单位、分辨率、符号统一验证方法上有三件事我建议固定下来一是位定时不要只靠配置工具算要在最远端实测采样点二是整机联试前做断电节点测试和多端接检查三是把健康状态报文接入长期记录事后回溯时能直接看到哪个节点的计数器在涨。这三件事覆盖了物理层、硬件集成层和协议层最常见的失效路径。说个自己的教训。早些年做一个模拟项目台架上一切正常装到整机上以后每隔十几分钟冒一批错误帧位置随机重装一遍就好过一阵又出现。当时把软件翻了个底朝天最后用示波器挂在总线最远端的节点上才看到采样点位置偏得太靠前传播延迟把余量吃干净了。从那以后我每次配位定时都强制走一遍「算传播段、定采样点、最远端实测」的流程哪怕配置工具给出的默认值看起来完全合理。希望帮到你。本文还有配套的精品资源点击获取