3. HIL系统交付物清单设计

HIL系统验收中最容易被低估的工作，不是跑通一个测试用例，而是把“交付了什么”说清楚。一套典型的dSPACE HIL系统，硬件上可能包含实时仿真机、I/O板卡、故障注入单元、负载箱、线束与机柜；软件上包含实时操作系统、ConfigurationDesk、ControlDesk、AutomationDesk等；模型上包含被控对象模型、传感器模型、执行器模型与故障模型；此外还有标定数据、验收文档、工具链脚本、许可证和备件。如果这些对象没有统一的分类、版本和归属规则，验收会上就会出现“这台机器算谁的”“这个模型是哪个版本”“许可证到期后谁续费”之类的争议。因此，交付物清单设计的核心不是罗列物品，而是建立一套可核对、可追溯、可交接的分类与归属体系。

一、按交付物类型建立八类主目录

建议将全部交付物归入八个主类，每类再按“对象—版本—归属”三个维度展开。八类分别是：硬件、软件、模型、标定、文档、工具链、许可证、备件与培训材料。分类时遵循一个原则：同一物理对象只出现在一个主类中，避免重复计数。例如实时仿真机本体归入硬件，其上的实时操作系统归入软件，运行在其中的被控对象模型归入模型，模型使用的参数集归入标定。

每一类交付物都需要记录三个关键字段：版本标识、归属方、验收状态。版本标识建议采用“名称+版本号+日期+校验值”的形式，例如模型版本可写为 PlantModel_v2.3.1_20240612_SHA256:9f3c…；归属方要区分供应商、集成商、整车厂/主机厂、第三方，并明确知识产权与后续修改权；验收状态分为“已交付待验”“已验收”“有条件验收”“未交付”四种，便于在验收会上逐项过堂。

二、版本与归属的判定规则

版本管理最容易出问题的地方是“模型与标定不同步”。例如被控对象模型升级到v2.3.1后，若标定数据仍停留在v2.2对应的参数集，HIL测试结果就会与实车不一致。因此建议在清单中增加“版本绑定关系”一列，明确模型版本与标定版本、软件版本之间的兼容矩阵。归属判定则建议采用“谁开发、谁持有、谁维护”的三问法：开发方持有著作权，使用方持有使用权，维护方承担后续升级责任。对于供应商提供的加密模型，还需单独记录解密密钥的保管方与交付方式。

三、交付物清单的结构化示例

下面给出一份可直接参考的清单字段设计。字段包括：编号、类别、名称、版本标识、归属方、存放位置、验收状态、备注。实际使用时可按项目规模裁剪，但建议保留“版本标识”和“归属方”两列，它们是后续争议最多的字段。

上表仅为字段示例，实际项目中每一类还可继续细分。例如“模型”可拆为被控对象模型、传感器模型、执行器模型、故障模型、环境模型；“文档”可拆为硬件手册、软件手册、模型说明、测试规范、验收报告、培训教材。拆分粒度以“能否独立验收”为准：如果一个对象可以单独判定合格与否，就应单独列一行。

四、交付物之间的依赖关系

清单不仅要列对象，还要表达对象之间的依赖。例如模型依赖软件版本，标定依赖模型版本，测试脚本依赖模型接口，许可证依赖软件模块。下图用关系图表达八类交付物之间的主要依赖方向，帮助在验收时判断“先验什么、后验什么”。

图中箭头表示验收依赖：硬件和软件是模型运行的前提，模型是标定的前提，工具链依赖模型接口，文档记录上述全部对象，许可证决定软件能否合法运行，备件保障硬件可维护，培训材料则让使用方具备独立操作能力。验收时按此顺序推进，可以避免“模型还没验收就急着验标定”的返工。

五、实操中的三个易错点

第一，许可证归属不清。浮动许可证常由供应商代购，到期后主机厂若未及时续费，整个HIL台架将无法启动。建议在清单中单独记录许可证的持有方、到期日、续费责任方和续费预算归属。

第二，备件与硬件的版本错配。备件板卡若与在用板卡固件版本不一致，替换后可能无法被ConfigurationDesk识别。建议备件清单中记录固件版本，并在验收时实际插拔验证一次。

第三，培训材料与当前版本脱节。培训视频若基于旧版ControlDesk录制，操作路径可能已变化。建议培训材料版本与软件版本绑定，并在软件升级时同步更新。

综上，HIL系统交付物清单设计的实质，是把“硬件、软件、模型、标定、文档、工具链、许可证、备件与培训材料”这八类对象，用统一的版本标识和归属规则固定下来，并用依赖关系图明确验收顺序。做到这一点，验收会才能从“扯皮会”变成“核对会”，交付也才能真正落地。