4. 联合HIL系统架构

三电控制器联合HIL(Hardware-in-the-Loop)系统,是把整车控制器(VCU)、电机控制器(MCU)、电池管理系统(BMS)三块真实控制器接入同一套实时仿真环境,由实时仿真机运行车辆动力学、电机模型、电池模型与高压电气模型,从而在台架上复现整车级的三电协同行为。与单控制器HIL相比,联合HIL的核心难点不在单个模型精度,而在于拓扑连接、信号接口、通信协议与同步机制四件事必须同时成立,否则会出现“单看每个控制器都正常,联起来就报错”的典型问题。

一、拓扑结构:三层实时网络与真实控制器闭环

联合HIL的典型拓扑可分为三层。第一层是实时仿真层,由实时仿真机(如dSPACE SCALEXIO、NI PXI、ETAS LABCAR等)承担,运行车辆纵向动力学、永磁同步电机FOC模型、电池等效电路模型(如二阶RC)、高压继电器与预充电路模型。第二层是真实控制器层,VCU、MCU、BMS三块控制器通过其真实低压线束接口接入,MCU通常还带真实功率模块或等效负载。第三层是信号调理与故障注入层,包括模拟量板卡、数字量板卡、PWM采集与输出、电阻/电压故障注入单元、CAN/LIN/以太网接口卡。

拓扑上,三电控制器之间既有硬线信号(如VCU给MCU的使能、MCU给VCU的转速脉冲、BMS给VCU的碰撞/绝缘报警),也有总线信号(VCU与MCU、VCU与BMS之间的CAN/CAN FD报文)。联合HIL必须同时复现这两类连接:硬线由IO板卡直连或经故障注入单元转接,总线由仿真机上的总线接口卡模拟“其余节点”,使真实控制器看到完整的网络环境。

三电控制器联合HIL系统拓扑 实时仿真层(实时仿真机) 车辆动力学模型 车速 / 扭矩 / 坡度 电机FOC模型 电流 / 转速 / 温度 电池二阶RC模型 SOC / 电压 / 内阻 高压继电器/预充模型 接触器 / 绝缘 / 碰撞 信号调理与故障注入层 模拟量IO板卡 数字量/PWM板卡 电阻/电压故障注入 CAN/CAN FD接口卡 LIN / 以太网接口卡 真实控制器层(被测件) VCU 整车控制器 扭矩请求 / 使能 / 挡位 MCU 电机控制器 三相电流 / 转速 / 温度 BMS 电池管理系统 SOC / 电压 / 绝缘 / 继电器 CAN FD CAN 同步机制:PTP / 硬件触发 / 全局时钟

二、信号接口:硬线、总线与模型接口的映射

联合HIL的信号接口设计,本质是建立一张“真实控制器引脚—仿真机IO—模型变量”的三方映射表。硬线接口包括:VCU到MCU的使能/扭矩请求PWM、MCU到VCU的转速脉冲与故障反馈、BMS到VCU的继电器状态与绝缘报警、碰撞信号等。这些信号在仿真机侧由模拟量输出、数字量输入、PWM采集/输出板卡承担,采样周期通常为1 ms或更小。

总线接口则更复杂。VCU与MCU之间通常走CAN FD,承载扭矩指令、电机转速、电流、温度、故障码等;VCU与BMS之间走CAN,承载SOC、单体电压、继电器控制、充电状态等;部分车型还用LIN连接水泵、风扇等辅助执行器,用100BASE-T1以太网承载诊断、标定或大数据量监控。仿真机需要配置对应的总线接口卡,并在模型侧实现“剩余节点”的报文收发逻辑。

接口映射示例(节选):

信号名           方向        物理接口        仿真侧资源        模型变量
VCU_MCU_Enable   VCU→MCU    数字量/PWM       DO 0.1           mcu_enable
MCU_Speed        MCU→VCU    频率量/PWM       DI 0.3           mcu_speed_rpm
BMS_SOC          BMS→VCU    CAN 0x355        CAN1 CH0         bms_soc
VCU_TorqueReq    VCU→MCU    CAN FD 0x120     CANFD1 CH0       vcu_torque_req
BMS_Insulation   BMS→VCU    硬线/模拟量      AI 0.2           bms_insulation

三、通信协议:CAN/CAN FD、LIN与以太网的分工

三电联合HIL中,协议选择不是随意的,而是由信号带宽、实时性和功能安全要求共同决定。CAN FD在VCU-MCU链路中逐渐成为主流,因为电机扭矩控制需要更高的报文密度和更大的数据场(最高64字节),同时保留CAN的仲裁与错误检测机制。传统CAN仍广泛用于VCU-BMS链路,因为BMS报文以周期性状态量为主,带宽需求相对可控。LIN用于低速辅助设备,成本低但速率仅20 kbps,适合水泵、风扇等非安全关键节点。以太网则用于诊断、标定、数据记录和OTA场景,带宽高但需要额外的PHY与交换机配置。

协议 典型链路 速率 数据场 联合HIL关注点
CAN VCU-BMS、VCU-辅助节点 500 kbps 8字节 报文周期、超时、总线负载
CAN FD VCU-MCU 2~5 Mbps 最高64字节 仲裁段/数据段波特率切换、CRC
LIN VCU-水泵/风扇 20 kbps 8字节 主从调度、休眠唤醒
以太网 诊断/标定/记录 100 Mbps 帧长可变 时间同步、丢包、交换机延迟

四、同步机制:让三块控制器“看到同一个时刻”

联合HIL最容易被忽视、却最容易导致联调失败的是同步。三块控制器各自有独立晶振和任务周期,仿真机也有自己的实时步长。如果不同步,会出现VCU已经发出扭矩请求,但MCU模型还在上一周期、BMS模型还在更早周期的现象,表现为扭矩响应滞后、SOC跳变、故障误报。

常用同步手段有三类。第一类是全局时钟同步,由仿真机提供统一时基,所有IO板卡和总线接口卡在同一时刻采样/更新,典型步长1 ms或0.5 ms。第二类是硬件触发同步,用同步脉冲线将仿真机与控制器任务周期对齐,确保控制器在固定相位读取输入。第三类是PTP/IEEE 1588时间同步,主要用于以太网节点和分布式仿真机之间的时间对齐,精度可达亚微秒级。工程上通常组合使用:仿真机内部用全局时钟,控制器侧用硬件触发,以太网侧用PTP。

同步检查清单:

  • 仿真步长是否小于控制器任务周期的一半?
  • CAN FD报文是否在模型步长边界统一发送?
  • 硬线PWM采集是否与模型步长同相?
  • 以太网PTP主时钟是否稳定,交换机是否支持透明时钟?
  • 三块控制器的看门狗与超时阈值是否与仿真步长匹配?

五、案例与误区复盘

某项目在联合HIL联调时,VCU报“MCU通信超时”,但单独测MCU HIL时一切正常。排查发现:VCU-MCU的CAN FD报文由仿真机模型发送,模型步长为2 ms,而VCU的CAN FD接收超时阈值为5 ms;当仿真机负载升高时,报文发送被延迟到6 ms以上,触发超时。解决方法是把CAN FD发送任务放到更高优先级的中断中,并将模型步长降到1 ms,同时把超时阈值放宽到10 ms。这个案例说明:联合HIL的通信协议配置必须与实时调度策略一起设计,不能只改模型或只改控制器参数。

另一个常见误区是把“总线能通”等同于“同步正确”。实际上,CAN报文能收到,不代表时间戳一致;硬线电平能读到,不代表采样相位对齐。联合HIL验收时,应专门做同步测试:用同一激励同时触发三块控制器,观察各自响应的时间差,要求控制在允许的抖动范围内。只有拓扑、接口、协议、同步四者同时闭环,三电联合HIL才能真正复现整车级行为,为后续故障注入和功能安全测试提供可信基础。