2. 实时仿真环境需求分析

搭建HIL（Hardware-in-the-Loop）实时仿真环境，第一步不是买设备、装软件，而是把“这个平台到底要满足什么”讲清楚。需求分析做不扎实，后面选实时机、配IO板卡、接总线时就会反复返工。本节从飞控被控对象、传感器、执行机构、总线接口四个维度出发，梳理HIL平台的功能需求、性能需求与接口需求，并形成一份可落地的需求规格清单。

一、先明确HIL平台在回路中的位置

飞控HIL仿真的基本结构是：真实飞控计算机运行飞控软件，仿真机运行被控对象模型（飞机六自由度动力学、气动、发动机、大气环境等），两者通过IO与总线接口交换信号。飞控输出的舵面指令、油门指令经接口进入仿真机，驱动模型解算；模型解算出的姿态、角速率、位置、速度、气压、空速等信号再经接口回送给飞控。飞控“以为”自己在飞真飞机，实际被控对象是实时模型。

因此，需求分析的核心问题是：哪些信号必须真实、哪些可以仿真、以什么速率和精度交换、接口形式是什么。下面这张图给出了HIL平台的需求分解结构，把被控对象、传感器、执行机构、总线接口与三类需求对应起来。

二、被控对象需求：模型要“像”到什么程度

被控对象模型是HIL仿真的“虚拟飞机”。需求上要回答三件事：模型包含哪些状态、以什么步长解算、精度如何验证。

以某型固定翼无人机为例，模型至少应包含六自由度刚体动力学、气动力与力矩、发动机推力、大气环境（密度、温度、风）以及起落架/地面约束。状态量包括三轴位置、速度、姿态角、角速率、迎角、侧滑角等。模型步长通常取1～5 ms，与飞控主控制周期匹配；若飞控周期为10 ms，模型步长取2 ms可保证一个控制周期内至少解算5次，避免数值耦合误差。

精度验证不能只看“曲线好看”。常用做法是：把同一组舵面激励输入分别给模型和参考数据（风洞/试飞/高置信度离线模型），对比姿态角、角速率的时域响应，要求稳态误差小于2%、峰值误差小于5%（示例指标，实际按型号要求确定）。

三、传感器需求：仿真什么、以什么形式给

飞控依赖的传感器通常包括IMU（三轴角速率、三轴加速度）、气压高度、空速、攻角/侧滑角、磁航向、GPS。HIL中这些信号由模型解算后“伪造”出来，但必须模拟真实传感器的关键特性：

• 量程与分辨率：角速率±300 °/s、加速度±10 g、气压高度0～12000 m，分辨率按飞控AD采样位数反推。
• 更新率：IMU通常100～400 Hz，气压/空速50 Hz，GPS 5～10 Hz，需与飞控采集周期匹配。
• 噪声与延迟：可叠加高斯白噪声、偏置、量化误差，并可配置传输延迟，用于验证飞控滤波与鲁棒性。
• 接口形式：模拟量、RS422、CAN或ARINC429，取决于真实传感器与飞控的连接方式。

这里有一个容易忽略的点：传感器仿真信号的参考坐标系必须与飞控内部定义一致。例如角速率通常定义在机体系（x前、y右、z下），若模型输出使用地面系，必须明确转换关系并在文档中标注，否则联调时会出现“符号反了”的典型问题。

四、执行机构需求：指令采集与反馈仿真

执行机构侧的需求分两半：一半是采集飞控输出的舵机/油门指令，另一半是把舵面偏度、发动机状态等反馈量仿真回送给飞控。

采集侧要明确：指令是PWM、模拟电压还是总线数字量；PWM的频率与占空比范围（如50 Hz、1～2 ms）；模拟量范围（如0～5 V对应-25°～+25°）。仿真侧要模拟舵机的限幅、速率限制、死区与卡滞，并支持故障注入，例如“升降舵卡死在+5°”“副翼失效”。这些故障注入能力是HIL平台区别于纯数字仿真的关键价值。

五、总线接口需求：把信号清单变成通道清单

接口需求是最容易“拍脑袋”的部分。正确做法是先列信号清单，再统计通道。信号清单至少包含：信号名、方向、类型、量程、更新率、接口形式、连接器针脚。下面给出一份示例清单（参数为教学示例，实际按型号确定）：

统计后得到通道需求：AI约8路、AO约12路、DI/DO约16路、ARINC429收发各2通道、RS422 2通道、CAN 1通道。再叠加20%余量，就是选IO板卡的依据。

六、性能需求：实时性指标怎么写才可验证

性能需求必须可测量。建议至少包含：

• 实时步长：模型解算周期≤5 ms，超时次数为0。
• 抖动：周期抖动≤1 ms（可用实时机自带统计或示波器测IO翻转）。
• IO延迟：从飞控输出到模型输入≤2 ms，从模型输出到飞控输入≤2 ms。
• 连续运行：≥4 h无丢帧、无通信错误。
• 数据记录：全通道≥1 kHz采样，记录不丢点。

七、需求规格清单的落地形式

把上述内容整理成一份需求规格清单，建议按“功能—性能—接口”三类分节，每条需求带编号、描述、验证方法。例如：

REQ-F-001 平台应能实时解算六自由度飞行动力学模型，步长≤5 ms
          验证方法：实时机统计超时次数，连续运行4 h为0
REQ-P-001 模型解算周期抖动≤1 ms
          验证方法：IO翻转+示波器测量，或实时机内置统计
REQ-I-001 平台应提供不少于8路AI、12路AO、16路DI/DO
          验证方法：通道清点+回环测试
REQ-I-002 平台应支持ARINC429收发各2通道，速率100 kbps
          验证方法：协议分析仪抓包核对标签与数据

这份清单不是一次写完就冻结的。随着联调推进，可能发现某路传感器实际是CAN而非RS422，或某舵机指令需要额外隔离。需求清单应保持版本管理，每次变更记录原因和影响范围。需求分析的价值不在于文档多厚，而在于让后续选型、接线、调试都有据可依，减少“接上再说”的返工。