3. 机载总线时序分析基础

机载总线上的“时间”并不是一个抽象概念,而是由一组可测量、可约束、可验证的物理量共同定义的。要判断一条航电总线是否满足任务需求,必须先把时序、延迟、抖动、确定性、实时性这几个术语拆开理解,再通过端到端时延预算把它们串成一条可核算的链路。本节围绕这些基础概念展开,并给出时序约束的分类方法。

一、时序、延迟与抖动:三个不同层次的量

时序(Timing)描述的是事件在时间轴上的先后与间隔关系,例如发送端在 t=0 发出帧、接收端在 t=Δ 收到、接收端在 t=Δ+δ 完成校验。它回答的是“谁先谁后、间隔多少”。延迟(Latency)是时序中的一个具体差值,通常指从源端某个参考点(如应用层提交数据)到目的端对应参考点(如应用层可用数据)所经历的时间,单位是微秒或毫秒。抖动(Jitter)则是延迟或周期的波动量,描述同一类事件多次发生时其时间间隔的离散程度。

三者关系可以用一个简单例子说明:某航电总线周期帧标称周期 T=10 ms,实测第 n 帧到达间隔为 10.02 ms,第 n+1 帧为 9.97 ms,则周期抖动约为 ±30 μs;而该帧从发送到接收的延迟若为 180 μs,则延迟是均值意义上的量,抖动是围绕该均值的波动。工程上常用峰峰值抖动、均方根抖动和最大抖动三种表述,必须明确是哪一种,否则数值不可比。

二、确定性与实时性:从“快”到“可预测”

确定性(Determinism)指系统在最坏情况下仍能给出有界、可预测的时序结果。它不要求每次都最快,而要求“最坏情况有上界”。实时性(Real-time)则强调任务必须在截止时间(Deadline)前完成,分为硬实时、软实时和固实时。机载飞控、作动器等属于硬实时,错过截止时间可能导致功能失效;座舱显示刷新等可归为软实时。

需要特别区分:高吞吐不等于确定性,低平均延迟也不等于实时性。一条总线可能平均延迟只有 50 μs,但在冲突突发时延迟飙升至 5 ms,那么它就不具备确定性,也无法支撑硬实时任务。因此时序分析的核心不是看平均值,而是看最坏情况执行时间(WCET)与最坏情况响应时间(WCRT)。

三、端到端时延预算:把链路拆成可核算的段

端到端时延预算(End-to-End Latency Budget)是把总时延指标分解到链路上每一段的方法。以一条典型的“传感器→总线→处理机→总线→作动器”链路为例,总预算若为 2 ms,可按下列方式分配(示例参数,仅用于说明方法):

链路环节典型贡献示例预算主要影响因素
传感器采样与封装采样周期 + 处理200 μs采样率、滤波阶数
源端协议栈与排队封装 + 等待发送窗口150 μs优先级、队列深度
总线传输帧长 / 速率 + 仲裁300 μs波特率、帧长、冲突
目的端接收与解包校验 + 中断 + 拷贝200 μs中断延迟、DMA
处理机计算算法执行600 μsCPU 负载、WCET
回程总线与作动同上链路550 μs与去程类似

把各段预算相加得到 2.0 ms,与总指标对齐。若某段实测超预算,就需要在该段定位原因,而不是笼统地“优化总线”。预算表的价值在于:它把“端到端 2 ms”这种不可直接操作的指标,转化为每一段可测量、可归因、可整改的目标。

四、时序约束的分类

时序约束可按约束对象和约束性质分类。按对象可分为:周期约束(如周期帧必须每 10 ms 发出)、延迟约束(如端到端不超过 2 ms)、抖动约束(如周期抖动不超过 ±50 μs)、顺序约束(如 A 事件必须先于 B 事件)。按性质可分为:硬约束(违反即失败,如飞控指令截止时间)、软约束(违反可降级,如日志上报)、派生约束(由上层指标分解得到,如某段总线预算 300 μs)。

实际工程中,约束之间会相互影响。例如提高某条消息优先级可降低其延迟,但可能增大低优先级消息的抖动;缩短周期可降低延迟,却会抬高总线负载,进而恶化最坏情况响应时间。因此时序约束不是孤立条目,而是一组需要联合求解的边界条件。

做时序分析时,先明确参照点:延迟从“应用层提交”算起,还是从“物理层首比特发出”算起?参照点不同,同一链路的数值可能相差数百微秒。全文与图示必须统一参照约定。
端到端时延预算分解与抖动示意(示例参数) 传感器 采样+封装 源端协议栈 排队+发送 总线传输 帧长/仲裁 目的端接收 校验+中断 处理机计算 WCET 作动器 执行 200 μs 150 μs 300 μs 200 μs 600 μs 550 μs t=0 t=2.0 ms 标称到达 ±30 μs 抖动窗口 时序约束分类 周期约束 每 10 ms 发出 延迟约束 端到端 ≤ 2 ms 抖动约束 周期抖动 ≤ ±50 μs 顺序约束 A 先于 B 硬约束:违反即失败 飞控指令截止时间 软约束:可降级 日志上报 派生约束:上层分解 某段预算 300 μs

五、从概念到可执行的分析动作

把上述概念落到工程上,时序分析通常按以下顺序推进。第一步,确定参照点与测量点:明确延迟从应用层提交算起,还是从物理层首比特发出算起,并在发送端和接收端各设置一个可观测的时间戳点。第二步,建立预算表:把端到端指标分解到采样、协议栈、总线、接收、计算、回程各段,每段给出预算值和测量方法。第三步,采集最坏情况而非平均值:连续记录至少数千帧的延迟与周期,统计最大值、峰峰值抖动和超预算次数。第四步,归因与整改:若某段超预算,先判断是排队、仲裁、中断还是计算导致,再针对性调整优先级、队列深度、帧长或任务调度。

以某型机载总线为例(示例假设):周期帧标称 10 ms,实测最大周期 10.08 ms,峰峰值抖动 80 μs,超过 ±50 μs 的抖动约束。排查发现源端协议栈在高优先级突发时排队时间从 20 μs 升至 120 μs,导致发送时刻后移。整改方式是为该周期帧预留独立发送窗口,并将低优先级突发消息的队列深度从 32 降到 8,使排队时间回落到 30 μs 以内,抖动随之收敛到 ±35 μs。这个过程说明:抖动问题往往不在总线本身,而在源端的排队与调度策略。

不要把平均延迟当作实时性依据。硬实时判断必须使用最坏情况响应时间(WCRT),并确认其小于截止时间。平均值再低,只要最坏情况越界,系统就不满足硬实时要求。