扫码关注，了解更多
在线留言
全国服务热钱
400-8299-000
加载中...
在嵌入式系统开发领域，硬件在环（Hardware-in-the-Loop，简称HIL）测试已经成为验证控制器软件可靠性的标准手段。然而，许多团队在搭建HIL测试系统时，常常面临国外软件授权费用高昂、本地化技术支持不足、系统扩展灵活性差等痛点。尤其是当项目需要快速迭代、跨部门协作时，一套能够提供从建模、仿真到测试全流程支持的国产化平台，其价值愈发凸显。本文将系统性地介绍硬件在环测试系统的集成开发流程，涵盖架构设计、实时仿真配置、通信接口配置、模型部署等关键环节，为需要搭建或升级HIL测试能力的团队提供可落地的参考指南。
硬件在环测试是一种将真实控制器（ECU）接入仿真环境中进行闭环测试的技术。仿真环境通常由实时计算机、IO接口板卡、电源管理模块和上位机软件组成，控制器在测试过程中感受到的信号与真实物理环境几乎一致，从而能够在实验室条件下完成功能验证、故障注入、边界条件测试等验证工作，而无需等待实车或真实被控对象的到位。
一个完整的HIL测试系统通常包含三个核心层级：上位机层、实时仿真层和被测对象层。上位机层负责测试用例管理、监控界面开发、数据记录与分析；实时仿真层运行被控对象的仿真模型，以确定性的时间步长输出仿真结果；被测对象层即真实的控制器硬件，通过IO接口与仿真层连接。
在典型的航空电子系统测试场景中，HIL系统需要模拟飞机各子系统的行为，包括航电设备接口、飞控系统信号、导航数据等。实时仿真层需要支持1553B、ARINC429等航空总线协议的实时通信，确保仿真信号与真实航电设备的数据格式完全一致。这种高精度、高实时性的仿真能力，是HIL测试系统区别于纯软件仿真（如MIL、SIL）的核心优势。
HIL测试系统的核心挑战在于实时性。被测控制器对输入信号的响应有严格的时间要求，仿真系统必须在确定的时延范围内完成模型计算和IO输出，否则将导致测试结果失真甚至控制器误判。通常，HIL系统的实时性要求在1毫秒甚至100微秒级别，这对硬件平台的计算能力和软件架构都提出了极高要求。
在多板卡协同的测试场景中，时间同步机制尤为重要。例如，当测试一个同时通过CAN总线和1553B总线与外部通信的控制器时，CAN消息和1553B消息的时间戳必须保持一致，否则会导致数据一致性问题。优秀的HIL系统通常采用统一的时间基准源，通过硬件触发电缆或软件同步方式，确保所有板卡在同一时间基准下工作。
搭建一套HIL测试系统，需要综合考虑被测对象的接口类型、仿真精度要求、预算约束和后期扩展需求。本章将从实时计算机、IO板卡、信号调理模块和配套软件四个维度，详细分析选型要点。
实时计算平台是HIL系统的“大脑”，负责运行被控对象的仿真模型。传统的实时计算平台多采用专用实时操作系统（如VxWorks、QNX）或基于FPGA的专用硬件。近年来，随着x86平台性能和确定性实时扩展（如Linux PREEMPT_RT）的提升，基于工业级x86服务器的解决方案因其性价比高、生态丰富、扩展灵活而受到越来越多的关注。
选型时需要重点关注以下参数：CPU主频与核心数（决定模型计算并行度）、内存容量与带宽（影响大数据量模型的处理能力）、实时性指标（中断延迟、调度抖动）、PCIe扩展能力（决定可挂载的板卡数量）。对于需要同时运行多个复杂模型的测试场景，建议选择多核CPU并合理分配核的用途，将实时任务与系统管理任务隔离到不同的CPU核心。
IO接口板卡是连接仿真环境与被测控制器的桥梁。常见的IO类型包括模拟量输入输出、数字量输入输出、 PWM输入输出、计数器/编码器接口、通信总线接口（CAN、FlexRay、1553B、ARINC429、RS232/422/485、以太网等）。
在板卡选型时，需要首先梳理被测控制器的所有接口信号，编制详细的IO清单。以一个典型的飞控系统HIL测试为例，可能需要配置AI板卡（采集飞控传感器的模拟信号）、DI/DO板卡（开关量信号）、CAN板卡（与飞控计算机的CAN总线通信）、1553B板卡（与航电系统的1553B总线通信）。部分高端应用还需要配置ARINC429板卡（航空标准总线）、反射内存卡（多机实时数据共享）等。
真实被控对象与仿真系统之间的信号并非直接相连，需要经过信号调理电路的转换。信号调理的主要功能包括：电平转换（如将仿真系统的TTL电平转换为被测控制器的24V电平）、功率放大（如驱动大电流负载）、阻抗匹配、故障注入（模拟短路、开路等故障状态）。
对于需要模拟传感器信号的测试场景，如模拟IMU、加速度计、压力传感器等，还需要配置传感器负载板，模拟传感器在大电流或高负载条件下的行为，确保控制器能够正确驱动这些传感器负载。
HIL测试系统的软件平台通常由三个层次组成：底层驱动层、实时运行层和应用开发层。底层驱动层负责与板卡硬件交互；实时运行层负责任务调度、时间管理、数据记录等核心功能；应用开发层提供测试用例开发、监控界面设计、数据分析等工具。一个优秀的国产HIL软件平台，如凯云ETest/SimuRTS，提供了从建模、仿真到测试的全流程支持，能够显著降低HIL系统的开发门槛。
完整的HIL测试软件平台通常包含以下核心模块：模型编辑与编译模块（支持Simulink模型导入和自动代码生成）、实时内核模块（负责任务调度和时间管理）、IO驱动模块（统一管理各类板卡的驱动）、通信协议栈模块（支持CAN、1553B、ARINC429等协议）、测试管理模块（测试用例编排和执行）、数据采集与回放模块（记录测试数据用于事后分析）。
在软件架构设计上，建议选择采用分层架构的平台，不同层次之间通过标准接口通信，便于后续的模块替换和功能扩展。例如，当需要更换某型号的1553B板卡时，只需修改IO驱动层，而无需改动上层的测试用例和监控界面。
实时内核是保证HIL系统确定性的核心组件。配置实时内核时，需要设置合适的调度策略（固定优先级、时间片轮转等）、设置任务周期（如1ms、2ms、5ms等）、配置中断与任务的优先级映射。以一个多速率系统为例，可能需要配置高速任务（1ms周期，用于实时性要求高的控制算法）和低速任务（10ms周期，用于逻辑判断和状态监控），通过实时内核的多速率调度机制统一协调。
在配置过程中，需要特别注意任务间的资源竞争问题。当多个任务同时访问共享资源（如内存、总线）时，需要使用信号量、互斥锁等同步机制避免数据不一致。此外，还应设置看门狗监控，当某个任务响应超时时自动触发错误处理流程，保护被测控制器免受异常信号的影响。
在HIL测试中，通信接口配置是最能体现系统能力差异的环节。不同的总线协议有不同的配置参数和时序要求，本章将重点介绍CAN、1553B和ARINC429三种常见接口的配置方法。
CAN（Controller Area Network）总线是一种广泛应用于汽车和工业控制领域的串行通信协议。在HIL测试中，CAN接口主要用于模拟车载网络的通信节点，测试控制器的CAN报文收发能力。
CAN接口配置的主要参数包括：波特率（常用125kbps、250kbps、500kbps、1Mbps等）、采样点（通常设为87.5%或87.75%）、位定时参数（PROP_SEG、PHASE_SEG1、PHASE_SEG2）、验收过滤器配置。以凯云ETest平台为例，其CAN驱动模块提供了图形化的配置界面，可以直观地设置波特率、验收码、屏蔽码等参数，无需编写底层寄存器代码。
在测试场景中，还需要配置CAN报文的发送策略：周期发送（如每100ms发送一帧固定ID的报文）或事件触发发送（如当仿真模型中的某个变量超过阈值时发送报文）。通过灵活配置发送策略，可以模拟真实CAN网络中的各种通信场景。
1553B是航空电子领域广泛使用的军用数据总线标准，尽管其名字带有“军用”字样，但在民用航空、航天器地面测试、科研实验等领域也有大量应用。在HIL测试中配置1553B接口时，需要深入理解其协议规范。
1553B总线配置的核心概念包括：总线控制器（BC，Bus Controller）、远程终端（RT，Remote Terminal）和总线监视器（BM，Bus Monitor）。在HIL测试场景中，仿真系统通常作为BC或RT角色存在，模拟航电系统中的其他设备与被测控制器通信。
一个典型的1553B配置示例：假设被测控制器作为RT，仿真系统作为BC。需要配置的参数包括：RT地址、subaddress（子地址）、消息格式（BC-to-RT、RT-to-BC或Mode Code）、数据字长度等。以某型飞控计算机的1553B接口为例，其ICD文档规定：飞控计算机的RT地址为5，接收命令使用subaddress 10（10个字），发送状态使用subaddress 15（1个字）。在ETest平台中，只需将这些参数填入1553B配置界面，即可完成接口配置。
ARINC429是另一种广泛应用于民航飞机的串行数据总线标准，与1553B相比，它采用点到点的通信方式，无需总线仲裁机制。在HIL测试中配置ARINC429时，需要关注标号（Label）、SDI（Source/Destination Identifier）、数据格式等参数。
ARINC429配置的主要参数包括：波特率（通常为12.5kbps或100kbps）、标号过滤、奇偶校验设置、数据字解析规则。以某型大气数据计算机的ARINC429输出为例，其ICD文档规定：标号#215表示气压高度，每秒更新20次，数据格式为BNR（二进制编码数值）。在仿真系统中，需要将仿真模型计算出的气压高度值，按照ARINC429的字格式编码后发送。
被控对象的仿真模型是HIL测试的核心。工程师通常在MATLAB/Simulink环境中使用框图方式建立被控对象模型，如飞机动力学模型、发动机模型、传感器模型等。将Simulink模型部署到实时仿真平台并运行，是HIL系统集成的关键步骤。
在将Simulink模型部署到实时平台之前，需要进行一系列准备工作。首先，确保模型中使用了与目标平台兼容的模块库，如使用定点运算替代浮点运算以提高执行效率，使用裸机调度替代Simulink默认调度以减少系统开销。其次，需要设置模型参数，包括离散化步长（通常与HIL系统的任务周期一致）、Solver类型（建议使用固定步长Solver）、代码生成选项（如优化等级、内存布局等）。
使用Embedded Coder或Simulink Coder生成代码时，建议开启“Real-Time Model Requirements”检查，确保生成的代码满足实时性要求。生成的代码通常包括模型初始化函数、模型步骤函数和模型终止函数，这些函数需要集成到实时平台的应用程序中。
代码生成后，需要将模型中的输入输出端口与实际的IO通道建立映射关系。这一步骤通常通过图形化的信号映射工具完成。以ETest平台为例，可以在配置界面中直接选择模型变量与板卡通道的对应关系，如将模型的"u_ai_ch1"端口绑定到AI板卡的第1通道，将模型的"y_can_tx"端口绑定到CAN板卡的发送缓冲区。
信号绑定完成后，还需要配置信号的缩放关系。实际物理量（如电压、压力、温度）与数字量（如ADC原始值、CAN报文数据）之间通常存在线性或非线性关系。例如，某压力传感器的量程为0-10bar，输出电压为0-10V，在模型中需要将0-10V的ADC采样值转换为0-10bar的压力值。这一缩放参数可以在信号绑定界面中直接配置，无需修改模型代码。
完成以上配置后，HIL系统已经具备了运行的基础条件。然而，系统集成是一个迭代优化的过程，需要通过调试逐步完善。本章将分享一些实用的调试技巧和常见问题排查方法。
在首次运行之前，建议先进行通信连接验证。以CAN总线为例，可以使用CANoe或Peak等CAN分析仪监听总线，确认仿真系统发送的报文格式正确、时序符合预期。对于1553B和ARINC429总线，可以使用相应的总线分析仪或内嵌的监视功能，验证消息内容和时序关系。
在验证过程中，建议采用逐步递增的方式：先验证单个通道的正确性，再验证多通道协同的正确性，最后验证完整测试场景的功能正确性。这种方式可以快速定位问题范围，避免在复杂场景中大海捞针。
实时性是HIL系统的生命线。当出现模型计算超时时，可以从以下角度排查和优化：检查模型计算量是否超出CPU能力（可通过性能分析工具定位热点函数）、优化模型算法（减少复杂计算、使用查表法替代实时计算）、调整任务优先级（确保实时任务优先于非实时任务）、优化内存分配策略（使用预分配内存替代动态分配）。
对于追求极致实时性的场景，可以考虑将部分计算密集型模块部署到FPGA上执行，利用FPGA的硬件并行能力分担CPU的负载。凯云SimuRTS平台支持FPGA联合仿真功能，可以在不影响模型可维护性的前提下，将关键算法加速到亚微秒级别。
完成系统集成后，就可以开始开发测试用例了。测试用例的设计应遵循测试覆盖度原则，覆盖正常工况、边界条件、异常工况等多种场景。建议采用脚本化方式管理测试用例，便于回归测试和批量执行。
以一个飞控系统的HIL测试为例，测试用例可能包括：传感器故障注入测试（模拟IMU数据异常）、总线通信故障测试（模拟CAN/1553B总线掉线）、模式切换测试（验证飞控计算机在自动模式和手动模式之间的切换逻辑）、性能边界测试（验证控制律在极端条件下的稳定性）。通过自动化测试框架，可以定期执行这些测试用例，持续监控飞控软件的质量状态。
硬件在环测试系统的集成开发是一项系统工程，涉及硬件选型、软件架构、通信协议、模型部署等多个技术领域。本文从架构设计出发，逐步深入到配置细节和调试实战，为读者勾勒了HIL系统集成的完整技术路线图。
随着国产嵌入式系统产业的快速发展，对自主可控的HIL测试平台需求日益迫切。一套好的HIL平台不仅要具备与国际品牌相当的实时性和接口能力，还需要在本地化服务、定制化开发、成本控制等方面建立优势。凯云ETest/SimuRTS作为成熟的国产HIL解决方案，已经在多个行业的嵌入式测试场景中得到了验证，能够为不同领域的客户提供从方案咨询、系统搭建到培训支持的一站式服务。
如果想第一时间拿到凯云ETest/SimuRTS的免费试用名额或行业方案资料，欢迎直接联系我们的测试工程师团队！