2. 交付物清单与验收标准

在 Simulink 模型化开发项目中，交付物清单与验收标准是项目验收的“合同附件”。它把“模型做完了”这种模糊表述，转化为可逐项核对、可量化判定、可追溯版本的工程基线。本节围绕四类核心交付物——模型、代码、文档、测试报告——说明各自应包含什么、验收时看什么指标、以及如何用交付基线锁定版本。

一、四类核心交付物的构成

模型交付物不只是 .slx 文件本身，而是一组可复现的模型资产：顶层模型与子系统模型、模型引用关系、数据字典（.sldd）、参数脚本（.m）、以及模型配置集（Configuration Set）。验收时要确认模型能在干净环境中打开、编译、仿真，且不依赖开发者本机路径。

代码交付物指由模型生成的嵌入式 C 代码及其配套文件：模型生成的 .c/.h、代码生成报告（Code Generation Report）、A2L 标定文件、以及编译链接所需的 makefile 或工程文件。若采用手写代码与生成代码混合，还需明确接口层代码的归属。

文档交付物包括需求规格说明、模型架构说明、接口定义文档、详细设计说明、以及用户手册。文档的关键在于与模型版本一致，而不是单独存在。

测试报告交付物包括 MIL/SIL/PIL/HIL 各阶段的测试用例、测试结果、覆盖率报告和缺陷记录。测试报告必须能回答“测了什么、怎么测、结果如何、是否通过”。

二、可量化验收准则的制定方法

验收准则必须可测量、可复现、有阈值。以模型检查为例，不能写“模型规范”，而应写“通过 Simulink Check 中 MAAB 规则集，违规项不超过 5 条，且无未连接端口、无代数环、无重复命名冲突”。阈值来源可以是企业规范、行业标准（如 ISO 26262 对模型的要求）或项目历史数据。

代码验收方面，典型量化指标包括：MISRA C:2012 强制规则违规数为 0，建议规则违规不超过 5 条；编译零错误、零警告；生成代码与模型接口一致，函数原型、数据类型、标定量地址均与 A2L 文件匹配。这些指标应在代码生成后自动跑一遍静态检查工具，把结果附在测试报告中。

文档验收的核心是追溯性。需求规格中的每一条需求，都应在模型中找到对应实现，并在测试用例中找到对应验证。可以用需求管理工具（如 DOORS、Polarion）导出追溯矩阵，验收时检查“需求→模型→测试”三列是否全部有对应项，覆盖率应为 100%。

测试报告的量化指标包括：需求覆盖率 100%、判定覆盖率（Decision Coverage）≥ 90%、MC/DC 覆盖率按项目安全等级要求（如 ASIL C 要求 100%）。测试用例应包含正常工况、边界工况和故障注入工况，每条用例有明确的输入激励、预期输出和实际输出对比。

三、交付基线的建立与锁定

交付基线是项目在某一时间点冻结的、经过验收的交付物集合。建立基线时，需要把模型、代码、文档、测试报告统一打上版本标签，并记录每个文件的校验和。例如，在 Git 中执行：

git tag -a release_v1.0 -m "交付基线 V1.0：模型+代码+文档+测试报告"
git push origin release_v1.0

基线锁定后，任何修改都必须走变更流程：提出变更申请、评估影响范围、更新相关交付物、重新跑回归测试、生成新版本基线。这样做的目的是保证“交付的是什么，验收的就是什么”，避免出现模型改了但文档没改、代码重新生成但测试报告还是旧版的情况。

四、验收流程与常见问题

验收通常分三步：自检、预验收、正式验收。自检由开发人员按清单逐项核对；预验收由测试人员独立复现关键指标；正式验收由质量或客户代表抽查并签署结论。每一步都应留下记录，形成可追溯的验收证据链。

常见问题包括：模型依赖本机路径导致无法复现、代码生成配置与文档不一致、测试覆盖率统计口径不统一、基线标签打错分支。解决这些问题的根本办法是把验收准则前置到开发过程中，而不是等到最后才检查。例如，在模型提交时自动跑 MAAB 检查，在代码生成时自动跑 MISRA 检查，在测试执行后自动生成覆盖率报告，这样验收时只需核对报告即可。

总结来说，交付物清单解决“交什么”，验收标准解决“怎么判”，交付基线解决“以哪个版本为准”。三者结合，才能让 Simulink 模型化开发项目的交付从“凭感觉”走向“凭证据”。