3. SIL仿真环境架构设计

SIL(Software-in-the-Loop)仿真环境的核心目标,是让真实的机载软件代码在宿主机上运行,并与被控对象模型、总线接口、调度器和数据记录模块协同工作,从而在不需要真实飞控计算机和飞机的前提下,验证软件功能、时序行为和回归一致性。因此,架构设计不是简单地把几个模块拼在一起,而是要明确各模块的职责边界、数据流向和时序约束。本节围绕五个组成部分展开,并给出实时性、确定性和可重复性的设计原则。

五个核心组成部分及其职责

被控对象模型是飞机、发动机、舵面、传感器等物理对象的数学表示。它接收机载软件输出的控制量(如舵面偏度、油门指令),按固定步长积分动力学方程,输出传感器测量值(如角速率、过载、气压高度)。模型通常以 C/C++ 或 Simulink 生成代码形式提供,接口需与真实传感器信号在量纲、范围、更新率上保持一致。例如某型无人机俯仰通道模型以 5 ms 步长运行,输出俯仰角速率范围 ±200 °/s,对应 ARINC 429 标签的量化精度。

机载软件是待测对象,即真实飞控软件的编译产物。在 SIL 中,它不运行于目标处理器,而是编译为宿主机可执行文件或动态库,通过桩函数(stub)替代硬件访问。关键设计是隔离硬件相关代码:将寄存器读写、中断服务、总线驱动替换为可注入的接口层,使软件逻辑本身保持不变。这样回归测试才能反映真实软件行为,而非测试替身的行为。

总线接口负责在模型与软件之间搬运数据,模拟 ARINC 429、CAN、AFDX 或 RS-422 等总线的帧格式、周期和校验。它需要实现三件事:按总线协议打包/解包数据、按周期触发收发、对丢帧和延迟进行可控注入。例如 ARINC 429 以 12.5 kbps 或 100 kbps 速率传输 32 位字,接口模块需按标签(Label)和源/目的标识(SDI)组织数据,并支持故障注入以验证软件的容错逻辑。

调度器决定各任务的执行顺序和时间基准。SIL 环境通常采用固定步长的主循环或实时操作系统仿真调度,将模型步进、软件任务、总线收发、数据记录按优先级和周期编排。调度器的精度直接影响仿真结果的可信度:若模型步进抖动过大,积分误差会累积,导致与目标机行为偏离。

数据记录模块在仿真过程中采集关键变量,包括软件内部状态、模型输出、总线帧、时间戳和事件标记。记录格式应便于回放和比对,通常采用二进制或 HDF5 存储,并附带元数据(步长、版本、配置)。回归测试时,将本次记录与基准记录按时间对齐后逐信号比对,判断是否通过。

SIL仿真环境架构与数据流 被控对象模型 飞机/发动机动力学 步长 5 ms 输出传感器量 机载软件 真实飞控代码 硬件接口桩替换 控制律/余度管理 总线接口 ARINC 429 / CAN / AFDX 帧打包/解包 · 周期收发 故障注入(丢帧/延迟) 调度器 固定步长主循环 任务优先级 · 时间基准 数据记录模块 信号/总线/时间戳采集 HDF5 存储 · 回放比对 传感器量 总线帧 控制指令 舵面/油门 触发节拍 采集 模型输出 总线数据 软件输出 调度节拍 数据采集

实时性设计:让仿真节拍跟上物理过程

实时性在 SIL 中有两层含义。第一层是仿真时间与物理时间的一致性:模型步长 5 ms,则每步计算必须在 5 ms 内完成,否则仿真会“跑得比真实时间慢”,导致软件看到的传感器更新率失真。第二层是任务响应延迟:从传感器数据到达软件,到控制指令发出,中间经过总线打包、调度排队、软件计算,总延迟应控制在可接受范围内。

实现上,通常采用以下措施:将模型和软件编译为同一进程内的动态库,避免进程间通信开销;总线接口使用内存队列而非网络套接字;调度器采用高精度定时器(如 Linux 的 clock_nanosleep 配合 CLOCK_MONOTONIC)驱动主循环。若单步计算超时,应记录超时事件并统计最大/平均耗时,作为仿真可信度的指标。例如某项目要求单步耗时不超过步长的 60%,即 5 ms 步长下单步不超过 3 ms,留出 40% 余量应对抖动。

确定性设计:相同输入必须得到相同输出

确定性意味着在相同初始条件和相同输入序列下,仿真结果逐位一致。这对回归测试至关重要:如果每次运行结果都有微小差异,就无法判断软件修改是否引入了真实缺陷。破坏确定性的常见因素包括:多线程竞争、未初始化内存、浮点运算顺序不一致、系统时间参与计算、随机数种子未固定。

设计对策是:调度器采用单线程固定顺序执行,任务按优先级和注册顺序排列,不依赖操作系统线程调度;所有随机数使用固定种子;浮点运算避免依赖编译器优化重排,必要时使用 -ffp-contract=off 等编译选项;数据记录中的时间戳使用仿真步计数而非墙钟时间。这样,同一版本软件和模型在相同配置下重复运行,记录文件应完全一致。

可重复性设计:配置、版本与回放

可重复性建立在确定性之上,但还要求环境本身可重建。需要做到三点:第一,所有配置参数(步长、总线周期、故障注入脚本、模型参数)以文本文件形式版本化管理,与软件版本绑定;第二,数据记录包含完整元数据,包括软件 commit ID、模型版本、配置哈希、编译选项;第三,提供回放模式,将记录的总线帧按原始时间戳重新注入软件,验证软件在相同输入下的输出是否与记录一致。

一个实用的回归测试流程是:基准运行产生 baseline.h5,修改软件后运行产生 candidate.h5,比对工具按信号逐点计算最大绝对误差和均方根误差。若所有信号误差为零或低于阈值(如 1e-6),判定通过;若某信号超差,则输出首次超差的时间点和数值,供定位。阈值设定需区分模拟量和离散量:模拟量允许浮点舍入级误差,离散量必须完全一致。

在 SIL 环境搭建初期,建议先跑通“模型→总线→软件→总线→模型”的闭环,确认数据能正确流转,再逐步加入故障注入和回归比对。闭环不通时,优先检查总线接口的量纲和更新率是否与模型、软件约定一致。

架构落地时的关键检查项

  • 模型步长与软件任务周期是否匹配?若软件以 10 ms 周期读取传感器,模型以 5 ms 更新,总线接口需做数据保持或抽取。
  • 总线接口的帧周期是否与真实总线一致?ARINC 429 的 100 kbps 下,32 位字传输约 0.32 ms,接口不应以更慢的周期发送。
  • 调度器是否记录每步实际耗时?最大耗时和超时次数应写入记录文件,作为仿真有效性的证据。
  • 数据记录是否覆盖所有回归比对信号?遗漏信号会导致回归盲区,建议在配置文件中显式列出信号清单。
  • 回放模式是否使用记录中的原始时间戳?若用当前时间重新调度,会引入额外抖动,破坏可重复性。

综上,SIL 仿真环境架构设计的本质,是在宿主机上重建一个“时间可控、数据可观测、结果可复现”的闭环系统。被控对象模型提供物理响应,机载软件提供控制逻辑,总线接口负责协议搬运,调度器维持时间秩序,数据记录模块留下证据链。实时性保证仿真跟得上物理过程,确定性保证相同输入相同输出,可重复性保证环境可重建、结果可回放。三者共同构成回归测试可信度的基础。