📚 课程目录第4章 HIL测试资产分类与元模型

4. HIL测试资产分类与元模型

在HIL量产验收项目中，真正决定长期维护成本的往往不是台架硬件，而是测试资产的组织方式。一个典型的动力域HIL项目，台架上有实时仿真机、I/O板卡、故障注入单元、负载箱和被测ECU，但支撑这些硬件运转的，是模型、信号、参数、标定、故障注入配置、测试用例、测试序列和测试报告模板这八类资产。如果它们以“文件堆”的形式散落在不同工程师的目录里，那么每次车型改款、软件刷写或台架迁移，都会带来大量重复劳动和隐性错误。资产化定义的核心，就是把这八类对象从“文件”提升为“有身份、有属性、有关系”的工程对象。

八类资产的资产化定义

资产化定义要求每类资产具备唯一标识、版本、责任人、适用车型/项目、状态和依赖关系。以下按对象逐一说明其关键属性。

模型资产：包括被控对象模型（如电机、电池、变速箱）和环境模型（如驾驶员、道路、温度）。关键属性有模型类型（Simulink/AMEsim/GT）、接口信号清单、采样步长、编译产物路径、适用软件版本。模型资产的核心是“接口契约”——它对外暴露哪些输入输出信号，这决定了它能否被测试用例复用。

信号资产：信号是HIL中最细粒度的连接对象。每个信号应有名称、方向（ECU→HIL或HIL→ECU）、数据类型、物理量纲、量程、默认值、所属模型或I/O通道。信号资产的价值在于消除“同名不同义”和“同义不同名”的混乱。例如，MotSpd_rpm与EngineSpeed若指向同一物理量，必须在元模型中建立映射关系。

参数资产：参数是模型或测试中可调整的常量，如电机转动惯量、电池内阻、环境温度。参数资产需记录名称、单位、默认值、取值范围、所属模型、是否可标定。参数与信号的区别在于：信号是运行时变化的量，参数是配置时设定的量。

标定资产：标定是参数在特定车型或工况下的取值集合。一个标定资产通常包含标定文件（如DCM、A2L、PAR）、适用ECU软件版本、标定日期和标定工程师。标定资产与参数资产的关系是“实例与定义”的关系。

故障注入配置资产：这是HIL测试区别于纯仿真测试的关键。故障注入配置定义了对哪些信号、以何种方式（开路、短路到地、短路到电源、信号偏移、信号冻结）、在什么时序条件下注入故障。关键属性包括目标信号、故障类型、注入起止时间、恢复条件、安全限值。故障注入配置必须与信号资产强绑定，否则无法自动执行。

测试用例资产：测试用例是“一个可独立判定通过/失败的最小测试单元”。它应包含用例ID、测试目标、前置条件、激励信号序列、预期响应、判定准则（如容差、持续时间）、关联需求ID。测试用例是资产化程度要求最高的对象，因为它直接决定验收结论。

测试序列资产：测试序列是测试用例的有序集合，通常对应一个测试场景或一个验收项。它定义用例的执行顺序、依赖关系、并行/串行策略、失败处理策略（继续或中止）。测试序列资产的关键属性是执行顺序和用例版本锁定。

测试报告模板资产：报告模板定义测试结果的呈现结构，包括封面信息、测试环境描述、用例执行汇总、失败详情、曲线截图位置、结论页。模板资产化后，不同项目可以复用同一套报告结构，只需替换数据源。

关系建模：从文件堆到资产网络

八类资产不是孤立的，它们之间存在明确的依赖和引用关系。上图展示了核心关系链：模型通过接口信号清单暴露信号；信号被故障注入配置绑定为目标；参数被标定实例化；故障注入配置被测试用例引用；测试用例被测试序列组合编排；测试序列的结果填充到报告模板。此外，标定资产通过软件版本对标定版本形成约束，影响测试用例的预期响应判定。

关系建模的关键在于“引用而非拷贝”。例如，测试用例不应内嵌信号定义，而应通过信号ID引用信号资产。当信号量程或默认值变更时，所有引用该信号的测试用例自动感知变更。同样，测试序列不应拷贝测试用例的步骤，而应通过用例ID和版本号锁定引用。这样，当某个测试用例更新时，测试序列可以明确知道哪些用例版本发生了变化，从而决定是否重新执行。

元模型落地：资产库的字段设计

将上述定义落地，需要为每类资产设计最小字段集。以下给出一个可参考的资产库字段设计示例（以信号和测试用例为例）：

信号资产表（Signal）
  signal_id       : 唯一标识，如 SIG_MOT_SPD
  signal_name     : 物理名称，如 电机转速
  direction       : ECU2HIL / HIL2ECU
  data_type       : uint16 / float32 / boolean
  unit            : rpm / Nm / degC
  range_min       : 0
  range_max       : 12000
  default_value   : 0
  io_channel      : AI01 / CAN0x123
  model_ref       : 所属模型ID
  fault_inject_ref: 关联故障注入配置ID列表

测试用例资产表（TestCase）
  case_id         : 唯一标识，如 TC_MOT_OVERSPD_001
  case_name       : 电机超速保护测试
  requirement_id  : REQ_MOT_SAFE_012
  pre_condition   : 电机温度25°C，档位D
  stimulus_ref    : 激励信号序列引用
  expected_ref    : 预期响应引用
  tolerance       : ±50 rpm
  duration_ms     : 2000
  fault_inject_ref: 关联故障注入配置ID
  calibration_ref : 适用标定版本
  sequence_ref    : 所属测试序列ID

这种字段设计的核心思想是：每个资产都有唯一ID，资产之间通过ID引用，而不是通过文件路径或名称引用。这样，当资产被移动、重命名或版本升级时，引用关系不会断裂。在dSPACE工具链中，这种元模型通常通过AutomationDesk的资产库、SYNECT的需求与测试管理，或自定义的资产数据库来实现。

资产化带来的实际收益

以一个实际场景说明：某车型HIL项目需要从A样切换到B样，ECU软件版本从V1.2升级到V2.0。如果资产未资产化，工程师需要手动检查每个测试用例是否受软件变更影响，逐一更新信号映射和标定文件。如果资产已按上述元模型组织，则只需更新标定资产的软件版本约束，系统即可自动筛选出受影响的测试用例和测试序列，并标记需要重新执行的用例。测试报告模板则自动引用新的标定版本和软件版本，生成可追溯的验收报告。

资产化不是一次性工作，而是持续治理过程。建议在项目启动阶段就建立资产库的最小字段集，并在每次车型改款、软件升级或台架迁移时，同步更新资产关系和版本约束。资产库的价值随项目数量增加而指数级增长。

总结来说，HIL测试资产的元模型不是学术概念，而是解决“测试资产散、乱、重复”问题的工程手段。八类资产各有其身份和属性，通过引用关系形成资产网络。模型暴露信号，信号绑定故障注入，参数实例化为标定，故障注入被测试用例引用，测试用例被测试序列编排，最终结果填充报告模板。理解并落地这套元模型，是HIL量产验收从“人治”走向“资产治理”的关键一步。