1. 课程导入与HIL系统全景

飞控软件的验证有一个绕不开的矛盾:真实的飞行试验风险高、成本大、空域受限,而纯数字仿真又无法暴露传感器噪声、总线抖动、执行机构延迟等物理世界的问题。硬件在环(Hardware-in-the-Loop,HIL)仿真正是为解决这一矛盾而生的中间路径——把真实的飞控计算机接入仿真环境,让它在"看起来像真飞机"的电气与信号条件下运行,从而在实验室里完成大部分闭环验证。

但HIL一旦引入真实硬件,时间就不再是仿真软件内部可以随意拉伸的变量。飞控计算机按自己的晶振节拍运行,仿真机按自己的步长推进模型,传感器与执行机构通过总线、AD/DA、PWM等物理通道交换数据,每一段都带来延迟。当这些延迟累积到一定程度,闭环系统的相位裕度被侵蚀,原本稳定的控制律可能在HIL中表现出振荡甚至发散;更麻烦的是,这种发散未必是飞控本身的问题,而可能只是同步机制没做好。因此,实时同步与延迟分析不是HIL的附属话题,而是决定HIL结果是否可信的前提。

本课程的学习目标

完成本课程后,应当具备三方面能力。第一是建模能力:能够把一条HIL回路拆解为若干延迟环节,给出每个环节的量级估计,并写出总的延迟预算。第二是测量能力:能够用示波器、总线时间戳、GPIO打点等手段,实际测出从模型输出到飞控响应、从飞控输出到模型接收的端到端延迟,而不是只依赖手册标称值。第三是诊断与调优能力:当HIL出现周期抖动、数据丢帧、闭环特性异常时,能够判断问题出在时钟同步、调度策略、通信协议还是模型步长,并给出可验证的修改方案。

核心术语约定

为避免后续章节歧义,先统一几个关键术语。以下定义在全文及所有图示中保持一致。

  • 实时(Real-Time):指系统在规定的截止时间内完成计算与I/O的能力,分为硬实时(超时即失败)与软实时(超时导致性能下降)。飞控内环通常要求硬实时。
  • 步长(Step Size):仿真模型每推进一步所代表的物理时间,例如1 ms。步长决定了模型侧的时间分辨率。
  • 抖动(Jitter):实际周期与标称周期之间的偏差。抖动是延迟分析中最容易被忽视、却对控制品质影响很大的量。
  • 端到端延迟(End-to-End Latency):从某一物理量在模型中被计算出来,到飞控据此产生的新指令重新作用于模型所经历的总时间。
  • 时间戳对齐(Timestamp Alignment):不同设备使用各自时钟时,通过统一时基把事件映射到同一时间轴上的过程。
延迟与抖动要分开看:一个平均延迟10 ms但抖动极小的回路,往往比平均延迟5 ms但抖动达±3 ms的回路更容易稳定。控制律设计对确定性的敏感度,常常高于对绝对延迟的敏感度。

典型飞控HIL架构

一个典型的飞控HIL系统由四类角色构成。最上层是仿真主机,运行飞行动力学模型、大气模型、传感器模型与执行机构模型,通常以固定步长实时推进。中间是实时目标机或实时内核,负责保证模型以确定节拍运行,并通过I/O板卡与外部硬件交互。第三是真实飞控计算机,即被测对象,它运行真实的飞控软件,通过总线或模拟通道接收传感器数据、输出舵机指令。第四是信号调理与接口层,包括AD/DA转换、PWM收发、ARINC 429/CAN/RS-422等总线接口,以及必要的电平转换与隔离。

这四类角色之间的数据流是双向闭环的:模型算出角速度与加速度,经D/A或总线送给飞控;飞控解算控制律,输出舵面偏度,经A/D或总线回送模型;模型据此更新气动力与力矩,进入下一步。整个环路的周期由最慢的一环决定,而延迟则由每一环累加。

飞控HIL闭环架构与延迟环节 仿真主机 飞行动力学模型 大气/传感器/作动模型 步长 1 ms(示例) 实时目标机 / I/O 实时内核调度 AD/DA、PWM、总线卡 时间戳对齐 真实飞控计算机 飞控软件(被测对象) 控制律解算 周期 5 ms(示例) 信号调理与接口层 电平转换 / 隔离 / 滤波 总线协议收发 模型输出 传感器信号 舵面指令 作动反馈 延迟环节分解(示例量级,非实测) 模型计算 ~0.3 ms D/A 转换 ~0.1 ms 总线传输 ~0.5 ms 飞控解算 ~2 ms 抖动 ±0.4 ms

图中标注的数值均为教学示例量级,用于说明各环节的相对大小,不代表任何具体型号的实测结果。可以看到,飞控解算本身往往占据延迟的大头,而通信与转换环节虽然单次不大,却最容易引入抖动。

延迟问题在飞控验证中的位置

延迟对飞控验证的影响体现在三个层面。第一是稳定性层面:控制律的相位裕度是按真实飞机的延迟特性设计的,如果HIL回路额外引入了未建模的延迟,闭环相位进一步滞后,就可能把原本稳定的系统推到临界点附近。第二是保真度层面:HIL的目的是替代部分飞行试验,如果延迟失真,那么HIL中"通过"的结论就不能外推到真实飞行。第三是故障复现层面:许多飞控异常与时间相关,例如总线周期抖动导致的采样错位、任务超时导致的控制输出滞后,这些只有在同步机制被正确建模和测量时才可能复现。

因此,在HIL工程实践中,延迟分析通常与功能测试同步开展,而不是等到问题出现再补做。一个可操作的做法是:在HIL系统集成完成后,先做一轮"空载延迟标定"——不接入飞控,仅测量模型输出到I/O输出、I/O输入到模型接收的单向延迟;再接入飞控,测量完整闭环的端到端延迟;最后在不同步长、不同总线负载下重复测量,得到延迟与抖动的分布。这三组数据构成了后续所有HIL试验的可信度基线。

不要把"系统能跑起来、曲线看起来正常"当作HIL可用的判据。缺少延迟标定的HIL结果,在出现异常时无法区分是飞控缺陷还是仿真环境缺陷,排查成本会成倍上升。

本课程的组织方式

后续内容将沿着"时间"这条主线展开:先建立实时系统与时钟同步的基本概念,再逐层分析模型侧、通信侧、飞控侧的延迟来源与测量方法,然后进入同步机制的设计与调优,最后通过若干典型故障案例,把延迟分析落到具体的排查动作上。每一节都会给出可复现的测量思路或参数示例,帮助把概念转化为工程判断力。