2. 验收依据与合同边界

HIL项目验收失败，很少是因为系统真的不能用，更多是因为“验收依据”本身没有对齐。技术协议、SOW、需求规格、企业标准四类文件往往由不同角色在不同阶段编写，措辞、颗粒度、责任边界各不相同。如果验收时直接拿需求规格逐条对照，很容易出现“需求写了但合同没约定”“合同约定了但需求没细化”“企业标准有要求但项目未纳入”三类争议。因此，验收工作的第一步不是测，而是把四类文件中的条款提取、对齐、转化为可验证的验收项。

四类依据文件的定位与提取重点

技术协议通常是甲乙双方签署的、最接近合同的技术附件，它规定系统组成、接口、性能指标和验收方式，是验收的“法律底线”。SOW（工作说明书）界定交付范围、里程碑、双方责任和不在范围内的内容，是验收的“边界线”。需求规格是工程实现层面的细化描述，包含功能、信号、模型、故障注入等具体行为，是验收的“技术细节源”。企业标准则是组织内部的测试规范、命名规范、文档模板和评审要求，是验收的“一致性基线”。

提取时建议按“可验证性”筛选：凡是能对应到具体信号、参数、工况、判据和观测点的条款，才进入验收项候选；凡是“应满足”“应友好”“应可靠”这类无量化判据的表述，必须回到技术协议或需求规格中寻找可量化替代，否则只能作为评审项而非验收项。

从条款到验收项：提取与转化方法

以一条典型技术协议条款为例：“HIL系统应能实时仿真电机控制器，仿真步长不大于100 μs，I/O延迟不大于50 μs。”这条可以直接转化为性能验收项：验收对象为电机控制器模型闭环仿真；输入为给定转速、扭矩指令和母线电压；观测点为模型计算步长和I/O往返延迟；判据为步长≤100 μs且延迟≤50 μs，连续运行10分钟无超时。这样的条款不需要再解释，验收时直接执行即可。

再看一条SOW条款：“乙方负责提供HIL台架硬件、实时仿真模型及基础测试用例，不包含被测ECU的标定与刷写。”这条界定了范围边界。验收时就要明确：硬件、模型、基础用例在范围内；ECU标定和刷写不在范围内，若甲方要求增加，必须走变更流程。如果验收时发现乙方未提供某类测试用例，先判断它是否属于“基础测试用例”的定义范围，而不是直接判定不合格。

需求规格中的条款往往更细，例如“当车速信号超过120 km/h时，模型应输出故障码P0AFA并限制扭矩至50%”。这类条款要提取为功能验收项，明确信号名、触发条件、预期输出和容差。企业标准则提供格式和一致性要求，例如“所有测试用例必须包含前置条件、步骤、预期结果和实际结果四列”，验收时检查测试报告是否满足该模板即可。

责任矩阵与变更控制

提取验收条款时，建议同步建立一张责任矩阵，明确每条验收项的“提出方、实现方、验证方、见证方”。例如，性能指标由甲方提出、乙方实现、双方共同验证、甲方见证；企业标准符合性由乙方自查、甲方抽查。责任不清是验收扯皮的主要根源，矩阵不需要复杂，但必须覆盖所有高风险条款。

变更控制的核心是“先书面、后执行”。任何超出技术协议或SOW范围的新增需求，都应先提交变更申请，说明变更内容、影响范围、对进度和成本的影响，经双方确认后再更新验收依据。验收时只对照最新版依据文件，避免用口头承诺或会议纪要作为验收判据。对于已经进入验收阶段才发现的范围争议，应暂停相关项，回到合同边界重新对齐，而不是先测再补依据。

可执行的验收条款提取检查表（示例）

以下检查表可直接用于项目验收准备阶段，逐条填写后形成验收项清单。表中参数为示例，实际项目应按技术协议和需求规格替换。

这张表的价值在于：每一条验收项都能追溯到具体依据文件，每一条都有明确的观测点和判据，验收时不需要再解释“这条到底怎么算通过”。当甲方提出新增要求时，先查表判断是否在现有依据范围内；若不在，则走变更流程，而不是直接插入验收执行。

总结来说，验收依据与合同边界的核心工作可以概括为三步：第一，从四类文件中提取所有可验证条款，按功能、性能、交付物分类；第二，为每条条款补齐对象、输入、观测点、判据和责任方五要素，形成验收项清单；第三，建立变更控制机制，确保验收执行时只对照最新版依据文件。做到这三点，验收阶段的大部分争议都可以在开始测试之前消除。