HiL测试系统总体架构

一套 HiL 系统真正难的地方，不是把设备堆进机柜，而是把需求翻译成可执行的资源。

先看输入。功能规范描述的是整车或控制器的行为，测例描述的是预期结果，信号清单则决定这些东西怎么落地。做系统设计时，我会先把需求拆成三类：必须由真实控制器完成的行为，必须由模型模拟的对象，以及必须观察的中间量。

再看输出。HiL 的输出不是“能跑”，而是可解释、可复现的证据：每次执行能被追溯到软件版本、模型版本、参数集、脚本版本和台架资源。

一套典型的 HiL 可以分成五层。

第一层是控制对象层。电池、电机、传动、驾驶员和环境模型负责模拟被测件看到的世界。模型不一定追求全物理保真，但必须在测试关心的量上准确。

第二层是信号与通信层。模拟量、数字量、PWM、电阻仿真、CAN、LIN 和以太网共同组成输入输出通道。每一路通道都要有量程、精度、采样率和故障注入方式。

第三层是实时平台层。实时机负责模型计算和 I/O 调度。需要关注的话题包括任务周期、分核、延迟、抖动和实时操作系统版本。

第四层是测试执行层。用例、脚本、自动化框架和报告系统把人的意图变成可重复的序列。

第五层是资产与流程层。信号清单、针脚表、版本台账、验收记录和复盘文档决定台架是不是可维护。

做资源预算时，我会给模拟量、数字量和通信通道留足够余量。项目中期出现新观测点几乎是常态。没有余量，最后就会用临时飞线解决问题，而临时方案往往不会进入图纸。

系统架构评审至少要回答五个问题：被测件边界在哪里，模型边界在哪里，哪些信号必须真实，哪些可以仿真，失败时如何冻结现场。

HiL 的价值不是替代实车，而是把复杂问题搬到可观测、可重复、可控制的环境里。系统架构的每一层都应该服务于这个目标。