4. HIL系统总体设计
Stellar域控（如Stellar P系列、Stellar E系列）是面向整车中央计算与区域控制的多核MCU/SoC，其HIL系统与传统的单ECU HIL有本质区别：被测对象不再是一个功能单一的控制器，而是同时承载动力、底盘、车身、网关等多域逻辑的“域级”节点。因此，HIL系统总体设计的第一步不是选机箱、选板卡，而是把“被测对象到底需要被验证什么”转化为可量化的仿真需求。
一、需求分析：从域控功能清单到HIL需求规格
需求分析的核心是把Stellar域控的功能安全目标、通信矩阵、I/O清单和诊断需求，翻译成HIL系统必须提供的仿真能力。建议按四个维度展开：
- 信号维度：统计域控所有输入/输出通道，区分模拟量、数字量、PWM、SENT、PSI5、CAN/CAN FD、LIN、以太网（100BASE-T1/1000BASE-T1）等类型，并标注每类通道的数量、电压范围、频率范围与精度要求。
- 实时性维度：确定最小仿真步长。例如电机控制类闭环要求步长≤100 μs，车身域可放宽到1 ms；Stellar多核间通信与锁步核监控的验证往往要求亚毫秒级同步。
- 故障注入维度：明确需要模拟的故障类型——对地短路、对电源短路、开路、信号漂移、CAN报文丢失/超时、CRC错误、总线关闭等，并给出每种故障的注入精度与恢复时间要求。
- 模型维度：确定被控对象模型的复杂度。例如增程器控制需要发动机、发电机、电池模型；区域控制需要车身负载模型、LIN从节点模型。模型复杂度直接决定实时仿真机的算力需求。
需求分析输出一份《HIL需求规格表》，至少包含：通道清单、步长、故障注入类型、模型接口、被测件接口定义。这份表是后续架构选型和板卡匹配的唯一依据，避免“先买设备再想怎么用”。
二、架构选型：集中式、分布式与混合式
面向Stellar域控的HIL架构通常有三种可选形态：
- 集中式架构：一台高性能实时仿真机通过多块I/O板卡直接连接域控的所有接口。优点是同步性好、布线集中、成本可控；缺点是单点故障风险高，扩展性受机箱槽位限制。
- 分布式架构：多台仿真机通过实时以太网（如EtherCAT、TSN）级联，各自负责一部分I/O和模型。优点是扩展灵活、算力可叠加；缺点是跨机同步复杂，网络延迟可能影响闭环精度。
- 混合式架构：核心闭环（如电机控制、锁步监控）放在一台主仿真机，非实时或低实时性部分（如车身负载、诊断模拟）放在从仿真机或信号调理箱。这是当前域控HIL较常见的选择。
选型判断可参考以下原则：若域控I/O通道数≤200且步长≥500 μs，优先集中式；若通道数超过400或需要多域独立扩展，考虑分布式；若同时存在高速闭环和大量低速负载，混合式更经济。架构确定后，需明确仿真机与域控之间的参考地、屏蔽层和隔离策略，避免地环路干扰。
三、实时仿真机与I/O板卡匹配原则
实时仿真机选型的核心是“算力匹配模型、槽位匹配板卡、同步匹配步长”。以Stellar域控为例，若模型包含多核任务调度、CAN FD通信和电机闭环，建议仿真机具备多核实时CPU（如Intel Xeon或等效）、硬件定时精度≤1 μs、支持IEEE 1588时间同步。I/O板卡匹配则遵循以下原则：
- 电气匹配：板卡输出/输入范围必须覆盖域控引脚电平。例如Stellar的ADC输入0–5 V，板卡模拟输出应支持0–5 V或0–10 V可调，且分辨率≥12 bit。
- 带宽匹配：PWM输出频率需覆盖域控采集范围。例如电机位置信号PWM频率可达20 kHz，板卡PWM输出应支持≥50 kHz更新率。
- 故障注入匹配：板卡需支持通道级继电器切换，实现开路、对地/对电源短路。若域控有SENT接口，需选用支持SENT协议的可编程数字板卡。
- 同步匹配：所有板卡应共享同一时钟源，确保多通道采样/输出同步误差小于步长的1/10。
四、匹配验证与常见问题
完成选型后，必须进行匹配验证。建议先做静态检查：逐通道核对板卡输出范围与域控输入范围，确认故障注入继电器触点容量满足域控引脚电流。再做动态检查：运行一个已知模型，用示波器测量板卡输出与域控采集之间的延迟，确认同步误差在步长1/10以内。
常见问题包括：PWM板卡更新率不足导致占空比失真；CAN FD板卡未配置正确采样点导致通信误码；故障注入继电器动作时间过长导致故障注入不真实。这些问题应在HIL系统集成前通过板卡自检和回路测试暴露，而不是等到域控功能测试时才排查。
总体而言，面向Stellar域控的HIL系统设计，本质上是把域控的“功能需求”和“安全需求”映射为“仿真能力”和“I/O能力”的过程。需求分析决定边界，架构选型决定形态，仿真机与板卡匹配决定精度。三者一致，HIL系统才能真正支撑域控的实时验证。