2. dSPACE HIL系统架构与CI接入点

在把夜间回归测试接入dSPACE HIL之前，必须先回答一个工程问题：这套台架里，哪些对象可以被程序自动控制，哪些信号可以被程序自动读取，哪些环节只能人工介入。只有把系统架构和可自动化接口梳理清楚，CI流水线才有稳定的落点。本节围绕实时仿真机、I/O板卡、故障注入单元、被测ECU、上位机与网络拓扑展开，重点识别可自动化控制的接口与信号。

一、台架物理与逻辑架构

一套典型的dSPACE HIL台架由五类核心对象构成。第一类是实时仿真机，例如SCALEXIO或DS1006系列，它运行被控对象模型（Plant Model），以固定步长（常见1 ms、0.5 ms甚至100 μs）解算车辆动力学、电机、电池等模型，并通过I/O板卡与真实ECU交换信号。第二类是I/O板卡，包括模拟量输入/输出（DS2202等）、数字量输入/输出（DS2302等）、PWM与频率采集板卡、CAN/CAN FD与LIN通信板卡（DS4302、DS4340等）。第三类是故障注入单元（FIU），通过继电器矩阵或半导体开关在ECU引脚与仿真机之间制造开路、对地短路、对电源短路、引脚间短路等故障。第四类是被测ECU，它接收传感器信号、输出执行器驱动，是测试的真正对象。第五类是上位机，运行ControlDesk、AutomationDesk、ConfigurationDesk等工具，负责模型下载、实验控制、测量记录与自动化脚本执行。

逻辑上，这五类对象形成一条闭环信号链：仿真机解算模型 → I/O板卡输出模拟/数字信号 → FIU按需注入故障 → ECU接收并响应 → ECU输出驱动信号 → I/O板卡采集 → 仿真机读入模型 → 模型状态更新。上位机则旁路在这条链上，负责配置、监控与自动化控制。理解这条链的方向，是识别CI接入点的前提。

二、可自动化控制的接口与信号

从CI角度，台架上的接口可分为三类：可完全自动化、可半自动化、仅人工。可完全自动化的接口是夜间回归的主力。

模型与实验控制接口。dSPACE提供AutomationDesk的COM/API接口，以及ControlDesk的Python/COM自动化接口。CI脚本可以通过这些接口完成：下载编译后的模型到实时仿真机、启动/停止实验、设置模型参数（如车速、温度、电池SOC初始值）、读取测量变量。例如，在AutomationDesk中，一个测试序列可以调用XIL API或DSAPI，通过Experiment.Start()、Parameter.SetValue()、Measurement.Read()等操作完成闭环。这些接口是CI接入的第一落点。

I/O信号读写接口。通过XIL API的MAPort（Measurement and Automation Port），CI脚本可以按信号名直接读写I/O板卡上的物理量。例如，读取AI_ThrottlePos得到油门踏板电压，写入AO_BrakePressure模拟制动压力。对于CAN信号，可通过CANPort发送和接收报文，例如发送0x123报文模拟车速，接收0x2A0报文读取ECU状态。这些接口使测试用例可以完全由脚本驱动，无需人工拨动开关或旋钮。

故障注入控制接口。FIU通常由dSPACE的FIU模块或第三方继电器矩阵控制。通过XIL API的FIUPort，CI脚本可以按通道使能/禁用故障，例如FIU.SetFault("ECU_Pin12", FaultType.Open)。故障注入的时序精度取决于FIU的响应时间，通常在毫秒级，需要在测试用例中预留稳定时间。

网络与远程触发接口。上位机与实时仿真机之间通常通过以太网连接，CI服务器可以通过SSH、VNC或dSPACE的远程API触发测试。对于夜间回归，常见做法是CI服务器在预定时间通过命令行调用AutomationDesk的--run参数执行测试序列，测试完成后将结果（如MDF、CSV、HTML报告）上传到制品库。

三、CI接入点的选择与约束

并非所有接口都适合直接接入CI。选择接入点时需考虑三个约束：实时性、稳定性和可观测性。实时性要求接口的响应时间不影响模型解算步长；稳定性要求接口在长时间运行中不丢包、不超时；可观测性要求接口能返回明确的成功/失败状态，便于CI判断。

例如，模型下载接口适合接入CI，因为它是幂等的、可重试的；而故障注入接口需要谨慎，因为故障注入可能触发ECU的保护逻辑，导致ECU进入不可恢复状态，需要在测试用例中设计复位流程。CAN信号读写接口适合接入CI，但需注意总线负载率，避免因CI脚本高频发送报文导致总线拥塞。

四、一个可参考的CI接入清单

这张清单的核心逻辑是：CI只控制那些“可重复、可复位、可观测”的接口。对于ECU本身，CI不直接控制，而是通过总线或引脚观测其响应。对于FIU，CI可以控制，但必须配套复位流程，确保每次故障注入后ECU回到正常状态，否则后续测试用例会相互污染。

五、网络拓扑对CI的影响

网络拓扑决定了CI服务器与台架的连接方式。常见拓扑有两种：一是CI服务器直接通过以太网连接上位机，由上位机再连接实时仿真机；二是CI服务器通过实时网直接连接仿真机。前者部署简单，但上位机成为单点；后者延迟更低，但需要CI服务器具备实时网卡和相应驱动。夜间回归通常采用第一种，因为上位机已经具备完整的工具链和许可证，CI服务器只需触发上位机上的AutomationDesk即可。

无论哪种拓扑，都需要保证CI服务器与台架之间的网络稳定。建议为CI流量划分独立VLAN，避免与办公网争抢带宽。同时，在CI脚本中设置合理的超时和重试，例如模型下载超时设为120秒，实验启动超时设为30秒，测量读取超时设为10秒。这些阈值应根据实际台架性能调整，并在首次接入时通过手动测试验证。

总结来说，dSPACE HIL台架的CI接入点集中在实时仿真机的模型控制、I/O板卡的信号读写、FIU的故障使能以及上位机的测试触发上。被测ECU是观测对象而非控制对象。把这些接口按“可自动化程度”分类，并配套超时、重试和复位策略，夜间回归才能稳定运行。