这几年eVTOL从一个冷门缩写变成了航空圈、汽车圈、资本圈共同的热词。我自己做了快十年汽车电子HIL测试最近两年明显感觉到一个变化越来越多eVTOL团队来找我们聊测试方案开口问的已经不是能不能测而是怎么用RCP和HIL把适航审定的证据链提前做出来。这个转变很有意思——说明行业终于意识到eVTOL航电系统的复杂度光靠真机试飞和单元测试是兜不住的基于RCP和HIL的在环验证已经从可选加分项变成了必答题。这篇连载的方案篇我专门聊eVTOL航电系统的RCPHIL工程实践。eVTOL很特殊它的航电架构既有航空出身的安全基因又有新能源汽车的电气化底子测试方法和工具链自然也要两套融合。下面我会把几个关键问题掰开揉碎讲清楚eVTOL航电到底要测哪些东西、RCP怎么帮你在没有真实硬件时把飞控算法跑起来、HIL台架怎么搭才能覆盖传感器、执行器和故障场景以及热管理这类常被忽视的子系统怎么纳入在环验证。如果你正在做eVTOL飞控、航电集成或适航取证支持或者是从汽车电子转型过来想了解空中交通工具这篇应该能帮你把从模型到台架的链路一次性捋顺。1. eVTOL航电和传统飞行器/汽车差在哪测试视角的三个核心差异1.1 执行器从十几个变成几十个冗余管理测试量级完全不同传统固定翼飞机的核心执行器数量有限主飞控面加增升装置不过十几个通道。eVTOL走的是分布式电推进DEP路线常见构型4到12个电机不等每个电机背后又挂着逆变器、电机控制器、转速传感器再加上倾转机构、舵面、起落架、舱门、刹车全机执行器数量轻松上到几十路。这个数量级的跃升不是简单的通道堆叠而是冗余管理策略彻底变了。传统飞机的余度管理是三余度表决双通道比较eVTOL则更像资源池调度——飞控要实时判断哪台电机掉了掉了一台之后剩余电机的推力怎么重分配转速指令怎么限幅倾转角度要不要跟着调整。这些逻辑光靠人工评审和单通道测试根本验不完必须在HIL台架上跑几千遍蒙特卡洛式的随机失效组合否则真机试飞时出一次问题的代价就太大了。我在实际项目里见过一个典型的失误某团队在仿真里只测了单电机失效没测单电机失效的同时倾转机构卡滞的组合场景。结果HIL上一跑控制律解算出一个极端转速指令直接把剩余电机的电流保护触发了整机动力跟着掉。这种组合失效场景正是eVTOL航电测试和传统航空、汽车最大的分水岭——你的测试用例设计必须覆盖多维度同时出错的稀疏矩阵。1.2 通信从ARINC 429到CAN FD一机多总线带来的时序难题eVTOL航电的通信架构是我见过最混血的。飞控与大气数据、惯导之间往往沿用航空惯用的ARINC 429或AFDX讲究的是确定性和隔离而电机控制器、电池管理系统BMS、热管理控制器这类电气化部件则大量继承汽车的车载总线基因CAN、CAN FD甚至车载以太网都有。问题就出在总线的时序协同上。ARINC 429是单向广播波特率低常见100kbps胜在稳定CAN FD波特率可以到2Mbps以上但存在总线仲裁、帧丢失、抖动。飞控算法同时要消化两类数据源如果台架上的总线仿真不同步、时序模拟不到位控制律在HIL上跑出来的表现和真机可能天差地别。我在搭建这类台架时有个习惯先画一张全机通信拓扑图把所有总线段、网关、采样率、消息周期标出来再决定板卡配置。ARINC 429通道用专用的航电总线板卡CAN FD用支持时间戳同步的CAN接口每一路消息的发送周期、初始相位、抖动范围都必须可配置。这一点上汽车HIL的CANoe经验可以直接搬过来但要注意把航空总线的调度表也纳入同一套实时时钟下不然跨总线时序分析就是一句空话。1.3 软件安全从DO-178C到ISO 26262一套系统两套语言的痛苦eVTOL的航电软件往往要同时面对两套安全认证语言航空侧的DO-178C机载软件适航审定标准和汽车侧的ISO 26262功能安全标准。飞控、导航属于航空安全关键功能要走DO-178C的A级或B级而电池管理、热管理这些更偏汽车基因的系统团队一开始往往用ISO 26262的ASIL等级来定义。这两套体系不是简单的等级对应关系。DO-178C更强调过程的完备性从需求到代码到测试的追溯性每一层都要有客观证据ISO 26262更强调危害分析和安全机制的落地比如故障注入、安全状态、FTTI故障容错时间间隔。我在评审过一个项目他们用ASIL D的开发流程去套DO-178C DAL A结果发现形式化验证、源码覆盖率分析的粒度都对不上返工了整整一轮。所以从测试方案设计的第一天起就要明确每个子系统按哪套标准取证。我的经验是HIL测试用例库的命名、追溯矩阵、覆盖度统计最好一开始就同时挂两套标签——一个DO-178C需求编号一个ISO 26262的安全机制ID。这样最后做适航审定资料包时不用再花三个月去补追溯表这也是RCPHIL连载方案里我一直强调测试即取证的原因。2. RCP快速原型算法不等硬件先让飞控逻辑在实时机上飞起来2.1 我为什么在eVTOL项目里强推RCP而不是直接上真机很多从传统航空背景出来的工程师对RCP有点陌生他们的习惯是先把硬件做出来再在真实目标机上调试软件。传统飞机的迭代周期可以等eVTOL的融资节奏和市场窗口等不了——但更重要的是eVTOL的控制算法本身还不够成熟。悬停模态、过渡模态、巡航模态、失效模态每个模态的控制律都需要大量调参。在真机上调参一次试飞的成本动辄几十万而且试飞科目还得排队等空域、等气象条件。RCP的思路是把控制算法先跑在实时仿真机上让算法直接通过IO接口连到真实传感器、真实执行器或者虚拟的被控对象模型相当于用算法替身提前上车。我在多个项目里验证过一个悬停到前飞的过渡控制律用RCP迭代调参每周可以完成十几轮试飞工况模拟而在真机上可能一个月只能飞两次。而且RCP很容易复现同一个工况——真机试飞很难保证两次飞行的风场完全一致RCP则可以精确回放这对对比调参前后的性能差异太重要了。2.2 从Simulink模型到实时目标机的三步走RCP的落地路径我一般按三步走每一步都有明确的验收标准。第一步是模型在环MIL把飞控算法做成Simulink模型被控对象也用六自由度气动模型代替先在纯软件环境里跑通逻辑。这一步的重点不是算得准而是把逻辑错误、索引越界、除法零这种低级问题先消灭掉。第二步是软件在环SIL把算法模型用Embedded Coder或类似的代码生成工具转成C代码跑在普通工控机上。这里要检查的是代码生成配置是否正确有没有不可靠的指针操作变量的字长、定点/浮点选择是否对应目标处理器。第三步才是RCP把生成的代码部署到实时目标机上。我常用的是Speedgoat或者dSPACE的MicroLabBox这类实时系统IO板卡按需选配。关键点是实时机的任务调度周期要设对——飞控内环一般做到500Hz到1kHz外环导航100Hz左右总线通信任务50Hz到200Hz每个任务都必须有独立的定时器不能互相阻塞。这三步走完之后算法在实时机上跑起来了接着就可以进入HIL环节。2.3 一个倾转过渡段的RCP验证实例倾转旋翼式eVTOL是RCP价值最明显的场景。飞机从垂直升力模式过渡到固定翼巡航模式倾转机构、电机推力、气动舵面三者必须同步协调过渡段的控制律涉及非线性强耦合稍有偏差就会出现掉高度、姿态振荡甚至PIO驾驶员诱发振荡。我在一个项目中用RCP把倾转过渡段算法跑在实时机上外接真实的倾转角度传感器和作动器控制盒但飞机本身是六自由度仿真模型。这样一来倾转执行器是实打实动的气动响应是模型算的控制律在这个半实物世界里接受检验。实测下来我们仅用两天就复现了原计划十次试飞才能发现的过渡段推力不匹配问题——模型显示过渡段前5秒掉高度1.8米而设计指标是1米以内。如果这个问题等到真机首飞才发现那就是一次高风险试飞科目。3. HIL台架三层设计传感器仿真、执行器负载与故障注入3.1 传感器层空速、惯导、GNSS怎么在板卡上造假HIL的核心思想是把真实设备接入一个逼真的虚拟世界。对eVTOL航电来说飞控计算机FCC是真实设备它看到的世界——大气数据、惯导姿态、GNSS位置——全部由实时仿真机生成并通过IO板卡喂给飞控。传感器仿真要注意三个细节。第一信号类型要匹配空速管和大气数据计算机ADC之间是模拟小信号毫伏级惯导往往走ARINC 429数字接口GNSS是串口或CAN每一种都要用对应的板卡不能拿一根线硬怼。第二信号要带噪声和偏差干净的完美数据在HIL里没有价值我习惯在仿真模型里叠加传感器偏置、漂移、量化误差这样才能验证飞控滤波器和控制律的鲁棒性。第三时间戳要对齐多传感器数据融合最怕时间不同步台架上的每条传感器数据都必须打上统一的仿真时钟戳否则卡尔曼滤波会输出错误姿态。这里还要提一个经验很多eVTOL用的IMU是从汽车行业转过来的MEMS器件数据输出噪声大、时延大。在HIL里一定要把这些器件的真实时延特性建模进去不然飞控在台架上跑得好好的一接真传感器就震荡。3.2 执行器层电机负载与倾转机构的功率级仿真执行器层是HIL里最重的部分。eVTOL的电机功率从几十千瓦到上百千瓦不等没法在台架上真的配一套同样的电机。工程上有两种做法信号级和功率级。信号级方案是用模拟电压/电流信号欺骗电机控制器让它以为自己在驱动电机。做法是实时机里跑电机数学模型算出当前工况下的反电动势、电流、转速信号再通过模拟量输出给逆变器控制接口。这个方案成本低、实施快适合控制逻辑验证但验证不了真实的功率电子开关特性。功率级方案则要用到功率级HILPower HIL把真实的逆变器和电机控制器接上用一套双向电源和电子负载来模拟电机的电气特性。eVTOL的高压母线可能是800V甚至更高功率级HIL的成本和复杂度呈指数上升但能真实验证逆变器的开关逻辑、电流保护、死区补偿这些信号级方案覆盖不到的东西。我的建议是分两步走控制律开发阶段用信号级HIL足够但涉及电机控制器固件验证、电驱动系统认证时必须上功率级。倾转机构如果用的是大功率伺服作动器同样存在信号级和功率级的选择逻辑相同不再赘述。3.3 故障注入让航电系统带伤飞行的测试艺术故障注入是HIL相对真机试飞最有优势的地方。在真机上主动制造故障——短接一根线、堵塞一个空速管——风险巨大而且很多故障状态不可恢复。HIL台架上的故障注入单元FIU可以安全、重复地制造任何故障让被测系统带伤飞行。我通常把eVTOL航电的故障注入分成四个层级电气层传感器信号开路、短路到电源、短路到地、线间短路总线层CAN帧丢失、CRC错误、数据位翻转、总线offARINC 429字错误、奇偶校验错误逻辑层信号卡滞在上一拍、信号超范围、信号跳变异常系统层上游系统失效比如BMS报告SOC跳变、热管理控制器报告冷却泵停转。每个层级都对应不同的验证目的电气层验证硬件接口保护电路和故障诊断硬件路径总线层验证通信协议栈的容错逻辑层验证飞控的应用层逻辑系统层验证整机级的安全降级策略。故障注入最容易忽略的是时间维度。我踩过的坑是只注入持久性故障没有注入瞬态故障比如持续200毫秒的CAN通信中断。后来验证发现飞控对200毫秒的瞬断毫不在意但对20毫秒的数据卡滞却会触发一次不必要的主备切换。这种微妙的时间敏感性只能在HIL上反复拉网式测试才能发现。4. eVTOL热管理子系统HIL联调航电测试里最容易被漏掉的对手4.1 热管理不是散热问题是能源问题eVTOL的热管理和汽车热管理表面看起来都是冷却泵、风扇、阀、换热器但底层逻辑完全不同。传统汽车热管理影响的是舒适性和排放eVTOL热管理直接影响续航和动力可用性——电池温度高了BMS会限流可用功率直线下降电机温度接近极限控制器会降额输出。而eVTOL的飞行剖面里起飞爬升阶段恰恰是功率需求最大的时候也是热负荷最高的时刻。如果热管理系统响应慢了半拍飞机在悬停阶段就可能遭遇动力降额这是安全关键问题。所以我把热管理看作一个和动力系统深度耦合的隐形子系统。它的控制器要实时读取电池温度、电机温度、环境温度、当前功率需求动态调节冷却液流量、风扇转速、阀开度甚至要预测未来一段时间的温升趋势提前开阀预冷。这个预测控制逻辑和飞控本身一样需要严格验证。在HIL台架上热管理控制器应该接入一整套虚拟的被控对象——电池热模型、电机热模型、冷却回路一维流体模型、冷凝器/蒸发器模型。关键是模型的动态特性要和真实部件匹配特别是时间常数。电池热模型的时间常数可能长达几分钟而目标温度控制环的时间常数只有几秒多时间尺度系统在实时仿真里很容易出现数值刚性需要特别注意求解器的选择和仿真步长的设置。4.2 热管理控制器从RCP到HIL的验证路径热管理控制器的开发节奏比飞控慢但同样适合RCPHIL的组合拳。我建议的路径是这样的先用RCP把热管理控制策略比如基于模型预测的电池预冷策略跑在实时机上虚拟的被控对象用简化的热网络模型。这时候验证重点是策略本身的合理性——预冷触发的时机准不准、降额和恢复的滞回区间合不合理。接下来进入HIL阶段把真实的热管理控制器如果是自研的话可能是一个域控制器里的一块接入台架用高保真的一维热流体模型替换简化模型再连上真实的传感器温度、压力、流量。此时验证重点从策略变成软硬件结合的可靠性——传感器的采样精度够不够、PWM调速信号有没有抖、CAN通信的报文周期有没有踩线。我特别推荐把热管理HIL和整机HIL联在一起跑而不是单独搭一套台架。这样可以在同一个仿真场景里同时验证单电机失效→功率重分配→电机负荷上升→温度升高→热管理开启预冷→整机功率重新分配这个完整链路。这种跨系统级的因果链测试是分散测试永远覆盖不了的。5. 从汽车ZCU到eVTOL域控架构复用能省什么、不能省什么5.1 汽车域控/区域控制器的家底确实能打近年来基于RCP的汽车ZCU区域控制器架构已经相当成熟。中央计算单元加若干区域控制器区域控制器把传感器、执行器的IO汇聚通过高速骨干总线车载以太网与中央大脑通信软件上走SOA服务化架构。这套思路对eVTOL太有吸引力了——线束减重、算力集中、软件可OTA升级、硬件可迭代。eVTOL正在快速吸收这套架构一个中央飞控计算单元加两到三个域控制器动力域、座舱域、热管理域域控制器之间用航空以太网或确定性网络互联。从测试的角度看这套架构带来的最大红利是基于RCP的汽车域控测试方案——包括CANoe的总线仿真、故障注入、自动化测试框架、CI/CD持续集成——大部分可以直接迁移过来不用从零发明轮子。具体来说我迁移过的汽车测试资产包括基于PXI系统的实时IO扩展、基于CANoe的剩余总线仿真、基于vTESTstudio的自动化测试序列、基于ASAM XIL标准的测试平台接口。这些工具的成熟度比纯航空工具高一个量级而且工程师好招。5.2 迁移到eVTOL航电的三个关键改法一个都不能省但是直接把汽车ZCU的HIL原封不动搬到eVTOL上会翻车。我总结三个必须改的地方。第一实时性预算完全不同。汽车车身控制的实时性要求是毫秒级甚至百毫秒级飞控内环是1kHz到2kHz的硬实时任务而且任务执行时间抖动必须控制在微秒级。汽车的LinuxSOA中间件那一套直接搬到飞控域必死。所以我在做架构规划时坚持把飞控计算做成独立的安全关键分区物理上或者逻辑上和其它域控制隔离。第二失效模式模型要重新建。汽车ZCU测试里的失效模式主要来自ISO 26262的硬件随机失效、通信干扰、用户误操作而eVTOL多了气动失效比如舵面卡滞、空气数据传感失效、动力失效电机停转、逆变器故障、结构失效倾转机构卡死这些航空特有的故障谱。我建议每一个域控的故障注入库都重写不要从汽车资产里硬套。第三安全等级的证据链要按航空规矩来。前面说过DO-178C和ISO 26262的差异这里再提醒一点域控里的飞控相关软件哪怕运行在同一颗SoC上也必须能够独立取证。HIL测试用例的分组、覆盖率统计、需求追溯都要能够从这个物理分区里单独抽出证据否则适航审查时你要把整个域控的证据全部交出去那工作量会非常痛苦。最后说几句实在话做了这么多年在环测试我最深的体会是方法本身没有多玄乎RCP就是让算法先跑起来HIL就是让硬件在一个可控的虚拟世界里接受折磨难的是把一个系统的所有边界条件想清楚。eVTOL比汽车多了一个维度——它真的会飞上去这个维度把所有隐患的代价都放大了。所以我对eVTOL团队的测试建议一直很简单尽早让航电系统在台架上摔打把故障一个接一个地注入进去记录每一次降级行为这些记录最后都会变成适航审定的底气。如果你正在规划自己的eVTOL航电测试台架欢迎按这篇的思路先做一轮差距分析——现有测试能覆盖哪些传感器、执行器、故障场景热管理有没有纳入在环域控的取证证据链能不能抽出来。从这三个问题入手比急着买设备划算得多。连载下一期我会聊聊海上的RCPHIL应用到时候再接着把这个话题拆开聊。