飞行安全这个东西外行看是试飞员的胆量和驾驶舱里的一堆仪表内行知道真正决定一架飞机能不能安全落地的是出厂之前在地面试验室里反反复复跑过的那些仿真测试。这些年飞控系统越发复杂从传统增稳到自动避障、编队协同算法越来越多试飞成本又高得吓人纯数字仿真已经没法让人放心了。团队自研的飞控半实物实时仿真测试平台就是在这种背景下陆续搭建起来的。这篇东西我不打算写成产品宣传稿就实打实聊聊这套半实物仿真测试平台怎么设计、怎么落地、踩过哪些坑以及它在整个航空研发链条里的真实位置。1. 飞行安全的第一道防线半实物仿真测试为什么非做不可1.1 飞控系统复杂度正在快速超出纯软件仿真可验证的范围大概十年前给无人机做飞控测试步骤还很直观先建个数学模型在电脑里把控制律跑通接着上真机试飞。当时的飞行任务相对简单控制通道不多试飞风险也可控。现在完全不是一回事了飞控软件动辄几十万行代码传感器融合、故障诊断、冗余管理、自动避障、多机协同一个比一个复杂。更关键的是飞控计算机是实实在在的硬件它的CPU算力、总线通信时序、看门狗机制、掉电保护这些特性是纯数字仿真里根本模拟不出来的。纯数字仿真也就是常说的模型在回路MIL和软件在回路SIL能验证的是控制逻辑对不对。但飞机是一个物理系统信号要通过真实的总线、真实的电连接、真实的舵机驱动电路才能起作用。很多故障恰恰发生在这些物理环节上——比如一条总线受到电磁干扰、一个传感器信号发生时延、一个舵机在高温下响应变慢。这些在纯软件环境里要么被理想化掉要么根本没法注入。1.2 半实物仿真和纯数字仿真之间差了一个真实世界所谓半实物仿真行业里叫HILHardware-in-the-Loop核心做法是把真实的飞控计算机接入闭环回路让它以为自己正连着真实的传感器、舵机、飞机机体飞行。真实的那个部分就是飞控计算机虚拟的部分是其他一切外部环境。听起来简单做起来难点全在让飞控计算机分辨不出来这句话上。仿真机必须在固定的时间步长里解算出飞机当前的姿态、位置、速度再模拟出传感器应该返回的电信号通过真实的接口送给飞控。飞控输出的舵面指令仿真机要实时换算成气动力矩更新飞机状态。整个闭环的实时性必须严格保证误差稍微跑偏飞控就会产生误判测试结果就是废的。这套平台要解决的核心问题用一句话概括把真实试飞中才可能暴露的问题尽可能提前到地面试验室阶段暴露出来。1.3 它在整个航空研发流程里的位置航空产品研发有一个典型的V字流程从需求分解、方案设计一路到部件验证、系统集成验证。半实物仿真测试位于系统集成验证阶段是连接设计定型和真机首飞的关键闸口。过了这关飞控软件才敢上真机过不了就得回到设计阶段去改。平台的实际价值体现在三方面一是缩短试飞周期许多风险科目在地面先跑熟二是降低试飞成本减少架次损耗三是兜住安全底线那些试飞中根本不敢做的极限工况比如单侧舵面卡死、传感器完全失效在实验室里可以反复做。这也是标题里筑牢研发防线的真实含义。2. 平台总体架构拆解从实时仿真机到信号接口的完整链路2.1 硬件在环的基本拓扑整套平台由四个核心部分组成实时仿真机、飞控计算机、信号接口适配单元、上位机监控终端。实时仿真机是整个平台的心脏负责运行飞机六自由度动力学模型、传感器模型、舵机执行机构模型、大气环境模型同时还要承担故障注入任务。它必须满足两个硬指标确定性实时调度和极低的通信抖动。飞控计算机就是被测对象它运行着真实装机使用的飞控软件完全不知道自己面前是个仿真环境。信号接口适配单元负责把仿真机的数字计算结果转换成飞控计算机能够识别的真实物理信号同时把飞控输出信号采集回来。上位机监控终端是工程师的操作界面用于搭建试验场景、设置故障、实时监控波形、管理测试报告。这次搭建的平台还专门添了一个负载模拟柜用来模拟舵机在真实飞行中承受的气动铰链力矩这一点对验证飞控对舵系统的驱动能力特别关键下文会展开说。2.2 实时仿真机与模型环境的选型思路实时仿真机我们先后对比过两种路线。一种是通用工控机加实时操作系统方案优点是价格友好、开发效率高适合模型量不太大、步长要求不极端苛刻的场景另一种是FPGA加嵌入式处理器方案能跑微秒级步长时间确定性更好但开发工作量明显偏大。从我们跑过的任务来看飞机六自由度模型加舵机动态模型在通用实时机平台上跑1毫秒步长是完全可行的。只有当任务涉及高频弹性模态仿真、或者需要对多台飞控进行同步联试时才需要考虑FPGA方案。这个取舍用生活化的话讲就是你要是每天只在市区代步买台家用车就够了硬上跑车除了费油没别的好处。平台选型的关键永远是把需求吃透量体裁衣。模型环境方面动力学模型我们自研传感器模型和舵机模型先用商用模型库做原型验证之后再逐步用实测数据替换。这个思路值得参考——全自研起步慢全外购后期会受制于人混合路线最稳妥。2.3 信号接口适配单元一个极其关键却容易被低估的环节很多团队第一次搭HIL平台注意力全放在实时仿真机上结果死磕接口转换时才发现这才是大头。飞控计算机对外接口往往包括模拟量采集、离散量输入输出、PWM驱动、串口、以及航空常用的总线通信接口种类多、时序要求各不相同。信号接口适配单元要解决三件事。第一是电平匹配飞控输入输出信号的电平范围、驱动能力跟仿真机的通讯板卡未必一致直接硬接轻则信号失真重则烧板卡第二是隔离航空系统特别讲究电气隔离试验室里共地问题往往造成莫名的信号毛刺排查起来极其费劲第三是故障注入的物理通道比如模拟传感器信号开路、对地短路、信号偏移都要在适配单元这一层预留切换电路。这套方案实施时我们的做法是单独配了一个接口配线柜每一路信号的走向、衰减系数、隔离措施都在配线图上标注清楚。可能有人觉得多此一举但等测试用例跑到几百上千条的时候遇到异常能迅速定位到具体通道会感谢当初这个决策。平台链路可以用下面这个表格来概括各部分职责组成部件核心职责容易忽略的细节实时仿真机解算飞机模型、环境模型、舵机模型实时任务调度优先级设置中断负载控制飞控计算机被测对象运行真实飞控软件需要专用测试接口导出内部变量信号接口适配单元电平转换、隔离、故障注入通道标定精度、绝缘耐压、屏蔽接地负载模拟柜模拟舵面气动铰链力矩动态响应带宽力矩梯度准确性上位机监控终端测试场景管理、数据监控自动化测试脚本框架的易用性3. 硬核细节实时性、同步性与故障注入的实现经验3.1 实时步长选择定多小才算够半实物仿真里最基础的问题就是仿真步长取多少。步长太大模型的动力学响应失实飞控算出来的一堆参数没有意义步长太小实时机算力跟不上模型算不完就是超时超时意味着这一帧数据必须废弃测试就不是连续可信的。我们的工程经验如下。整机刚体动力学加气动数据插值用10ms步长在慢速飞行段勉强够看但一旦涉及增稳控制律的高带宽环节数据明显失真。降到1ms步长飞行力学和大部分控制律都能覆盖到位。舵机这一类高频执行机构纯粹用软件模型跑1kHz往往还是不够真实特别是要验证舵面振荡这类动态过程时我们倾向于在模型层面用更高阶次来拟合或者把执行机构模型放到FPGA上单独加速。具体做法上我们给平台设计了多速率调度结构模型解算按1ms主步长运行舵机模型按更细的子步长在内部积分推进数据采集按需抽取。这类设计带来的复杂度不小但换来的是该细的地方细、该快的地方快。3.2 时间同步与数据落盘最容易被忽视的坑点HIL平台一旦开始跑实时仿真机和飞控之间就在不停交换数据。最怕出现的情况是飞控发出一条指令仿真机因为调度延迟晚了几毫秒才响应虽然系统没崩但时序已经不是真实飞行中的时序了。拿游戏来类比就是画面渲染帧率跟不上看起来整体没大问题但微操的手感全变了。解决思路是建立统一的时基所有环节的数据都带硬件时间戳。仿真机侧每毫秒产生一个同步脉冲飞控侧通过外部中断感知这个时基数据采集系统以相同时基采样。这样事后分析数据时每一帧都能对齐到绝对时间轴谁先谁后一目了然。数据落盘同样讲究。以前我们试过所有数据都通过网络传到上位机保存结果量一大就开始丢包后来改成采集系统本地硬盘直写加实时波形转发两条路并行的方案。直写保证完整转发保证可看两不耽误。做HIL测试的人常说数据就是证据如果连证据都不完整后面问题定位基本靠猜。3.3 故障注入的三种做法与适用场景故障注入是HIL平台区别于普通仿真系统的重要能力也是飞行安全测试落到实处的关键手段。根据注入位置不同我们经常用的有三类。第一类是信号级故障注入在信号适配单元里通过继电器或电子开关对传感器信号做开路、短路、对地、偏移、叠加噪声等操作。这类故障最接近真实线路故障适合验证飞控的传感器容错和重构逻辑。第二类是总线级故障注入在通信链路上人为丢帧、错序、篡改数据、拉长帧间隔用来考验飞控对通信异常的检测能力。第三类是模型级故障注入直接修改仿真模型内部参数比如让某个舵面卡死在某个角度、气动参数跳变、发动机推力骤降等这类故障往往用于验证飞行边界情况下的控制策略。三类故障各有分工。信号级和总线级负责硬故障验证模型级负责软故障和危险工况模拟。完整的测试大纲应该把三类故障组合起来交叉覆盖。我们最早只做了信号级注入后来某次测试才意识到总线丢帧这种故障若是光靠改信号模拟压根复现不了这才补齐了总线级故障注入模块。3.4 数据回放与问题复现测试的价值一半在事后很多测试现场发现异常工程师第一反应是盯着屏幕看波形实际上效率极低。我们的习惯是先把完整数据落盘等用例跑完再回到上位机做数据回放和分析。回放的核心能力是支持任意时间窗口缩放配合参数曲线对比、事件标记、故障注入时间点的叠加显示一条时间线上的因果链会非常清晰。某次排查一个舵机振荡问题夜里连续跑了十几轮都没捕捉到规律后来把故障注入时刻和飞控内部状态变量叠加在同一时间轴上回放才看出振荡总是在注入后约1.2秒才出现而且跟某个特定的总线帧序号强相关。这种时间对齐参数关联的分析方式在半实物仿真里远比单看某一通道的曲线有效。4. 一次典型任务的完整过程极限飞行包线验证实战4.1 任务背景与测试大纲设计去年年中我们配合某项目团队对一款小型固定翼无人机做全飞行包线HIL验证。这款无人机的设计任务剖面覆盖低速大攻角爬升、高速俯冲改出、大侧滑航向保持等多段工况里面有不少风险科目真机试飞代价大但控制律更新之后再不验证心里又没底。测试大纲设计是整个任务里最见功力的部分。我们没有简单按飞行阶段划用例而是先对飞行包线做了一个网格化划分把空速、高度、攻角、侧滑角划分成关键状态点再针对每个状态点组合出典型机动指令和故障预案。这么一轮下来用例数量从最初规划的六十多条扩张到两百多条虽然工作量大了但包线覆盖的完整性高了很多。航空测试不是比谁跑得快而是比谁覆盖得全。4.2 从模型准备到测试执行的标准流程测试正式执行前有一条完整的准备链路。第一步是模型标定把气动数据表、发动机推力曲线、舵机机电参数装进仿真机并跟历史试飞数据做比对确认模型输出的配平状态、动态响应在可接受误差范围内。这一步没做扎实后面测试结论的置信度就无从谈起。第二步是飞控状态确认包括飞控软件版本号、编译时间、参数表版本都要记录归档这属于测试溯源的基本功。第三步是自动化测试脚本准备我们基于Python封装了一套测试用例库可以按大纲批量编排用例、注入故障、判读结果。到了测试执行阶段基本是自动化跑批加人工盯盘遇到异常再人工介入分析。这套流程用代码片段来示意的话故障注入控制在脚本里大致是这样一个结构# 故障注入与恢复流程示意 def run_case(case_name, fault_point, duration): start_flight(case_name) # 启动飞行剖面 wait_for_condition(平飞建立) # 等待稳点建立 inject_fault(fault_point) # 在指定时刻注入故障 monitor_response(duration) # 监控响应直至设定时长 recover_fault() # 恢复故障 evaluate_metrics() # 判读控制品质指标 save_report(case_name) # 保存测试报告4.3 测试中发现的真实问题舵机高温滞后引发的振荡整个包线验证跑到大约三分之一时有一个算例的结果引起了注意。在连续三次重复实验中某段机动结束后飞控记录的副翼指令出现了周期约为0.8秒的持续振荡幅值虽然不大但完全没有收敛迹象。最初我们怀疑是故障注入模块的干扰后来把故障注入时间点对齐发现振荡每次都出现在注入后1秒左右并且跟舵机模型输出的力矩响应延迟存在强关联。进一步比对数据后确认问题根源是舵机模型里阻尼系数设成了固定值。真实舵机在长时间工作后温度升高润滑特性变化响应滞后明显增大而模型里的固定阻尼完全没反映这个趋势导致飞控-舵机回路在特定频段上相位裕度不足振荡就此激发。这个案例很有代表性。半实物仿真平台的模型精度往往直接决定测试结论的可靠度。后来我们给舵机模型补上了温度相关的参数曲线再跑同样的用例振荡消失控制品质恢复正常真机试飞时也没有再出现同类问题。4.4 结果判定与测试报告沉淀每次用例结束我们按预先定义的指标判据自动生成判定结果。像短周期阻尼比、指令响应时延、稳态误差这类关键指标阈值在大纲阶段就和设计团队对齐过脚本自动比对超限自动标红人工复核后归档。这比事后逐条人工翻数据要高效得多也避免了主观判断带来的不一致。测试报告不只是罗列通过/不通过每一条未通过项都要关联到对应的故障场景、模型设置、数据曲线。我们内部叫一用例一案一报告这些报告最终汇总成平台的模型修订建议反馈给设计团队。可以说整个HIL测试环节真正沉淀到团队资产里的就是这份数据和经验来回迭代的闭环。5. 平台搭建、运维与长期演进的实践经验5.1 自研还是外购真实场景下的选型反思关于半实物仿真平台市场上不是没有成熟产品外购的优势很明显交付周期短、售后有保障、功能现成。但我们最终走了自研路线核心原因有两个。一是被测飞控的接口和通信协议比较特殊外购平台要适配往往需要额外定制开发成本并不低二是后续迭代测试场景时自研平台可以从底层灵活调整模型调度和注入逻辑。自研的代价也相当明显。信号接口适配单元里一堆细节问题比如线缆屏蔽、接地拓扑、电平转换芯片选型都只能自己一点点试错。如果团队没有足够的硬件功底建议还是先外购核心实时仿真机把接口适配和测试管理自己做两条腿走路更稳。5.2 搭平台时最容易踩的坑首先平台刚建起来时我们犯过一个低级错误——把所有测试用例一股脑都放到首次跑批里执行结果模型初始化瞬态没有等稳定就开始采集数据导致前几秒的数据全部不可用。后来我们给每个用例加了一个进入稳态判定的前置条件这个小小的改动让数据有效率高了很多。其次接口通道标定容易被忽略。模拟量通道的零点和增益会随温度和器件老化漂移如果长期不做校准测试数据的可信度会悄悄下降。我们的对策是每年固定做一次全通道标定用标准信号源逐点扫描记录发现偏差及时修正。这套工作听起来枯燥但它是平台自身质量保障的基本盘。再一个坑是关于自动化测试的预期管理。自动化脚本能解放人力但前提是测试大纲已经稳定下来需要人的判断来做机动规划和故障设计的阶段强行自动化反而会限制测试深度。我们内部的原则是探索性测试用例必须人工设计回归性测试尽量自动化。5.3 平台的扩展方向多机联试与虚实结合HIL平台的价值并不会止步于单一飞控验证。我们正在推进的一个方向是多机半实物联试把两到三套飞控计算机同时接入仿真环境模拟编队飞行时的相对位置、通信链路和数据交互验证协同控制逻辑。这个场景在真实试飞里组织难度极高但在半实物平台上只需扩展仿真机算力和通信接口就能搭起来。另外一个有意思的方向是虚实结合。把真机试飞中采集到的传感器数据、舵面数据导入平台用真实数据驱动仿真场景让飞控在真实环境里重新跑一遍软件版本以此验证软件升级是否存在回归风险。这套做法能构建一个从试飞数据到仿真验证的闭环对机队持续适航有直接帮助。5.4 一点个人建议这几年的平台建设和使用过程最深的体会是半实物仿真平台本质上不是一个设备采购项目而是一个持续积累的测试体系。设备只是载体真正有价值的是围绕平台沉淀下来的测试用例、模型校准数据、故障案例库和测试方法论。如果你正准备启动类似平台我的建议是从一个小而完整的闭环开始一台实时仿真机、一套可靠的接口适配、一条完整的主飞行剖面先把能跑、可信、能复现这三件事做扎实再逐层扩展。不要一上来就追求设备齐装满员平台的可信度靠的是每个环节的精心标定和验证这些工作急不得也省不得。