📚 课程目录第2章验收标准与交付物清单

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

在TwinCAT项目从开发走向量产交付的过程中，验收标准与交付物清单是双方对“项目是否完成”达成一致的唯一依据。如果验收标准模糊，客户可能认为“功能没做完”，而工程师认为“已经按需求实现了”，最终导致反复返工甚至项目延期。因此，本节的核心任务是：把模糊的“做完了”转化为可测量、可复现、可签署的验收条目，并明确每一项交付物的形态与验收依据。

一、FAT与SAT的分工与定位

FAT（Factory Acceptance Test，工厂验收测试）通常在系统集成商或设备制造商的现场进行，此时设备尚未发往最终产线，测试环境相对可控。FAT的重点是验证控制逻辑、HMI交互、安全功能、通信接口和报警处理是否符合技术协议。SAT（Site Acceptance Test，现场验收测试）则在设备安装到客户现场后进行，重点验证设备与现场实际I/O、上下游设备、网络环境、供电与接地等集成后的表现。两者不是重复劳动：FAT解决“逻辑对不对”，SAT解决“装到现场还能不能跑”。

制定验收标准时，建议采用“条件—动作—预期结果—判定依据”四要素结构。例如：

条目编号：FAT-IO-012
测试条件：将X轴伺服使能，手动模式下以10%速度点动正向
执行动作：按下HMI上的“X轴正向点动”按钮并保持2秒
预期结果：X轴以约10mm/s匀速正向移动，方向与坐标正方向一致，松开后立即停止
判定依据：HMI速度显示在9~11mm/s之间；实际位移方向与坐标系定义一致；停止后无过冲报警

这样的条目在验收会上不会产生歧义。相反，“X轴能正常点动”这种写法无法判定，因为“正常”没有量化边界。

二、验收标准的量化维度

TwinCAT项目的验收标准通常覆盖以下维度，每个维度都需要给出可测量的判据：

功能正确性：逻辑条件满足时输出是否正确，例如气缸到位信号触发后0.5s内夹紧阀得电。
时序与节拍：单周期时间、响应延迟、超时阈值，例如EtherCAT周期设为1ms时，从站响应抖动不超过±50μs。
精度与重复性：定位误差、重复定位精度，例如重复定位精度≤±0.05mm，连续10次测量极差≤0.08mm。
安全功能：急停响应时间、安全门开闭逻辑、STO触发后的停止距离，需符合风险评估中确定的PLd或SIL等级。
通信与诊断：EtherCAT拓扑识别、从站丢失报警、网络恢复后自动重连时间。
异常处理：断气、断电、传感器失效、通信中断时的降级策略与报警提示。
人机交互：HMI画面切换时间、报警确认与复位流程、权限分级是否生效。

这些维度不必全部出现在每一台设备上，但一旦出现在技术协议中，就必须在FAT/SAT中逐条对应测试用例。

三、交付物清单的构成

交付物不是“把工程文件夹拷给客户”那么简单。TwinCAT项目的交付物通常包括五类：

程序与工程源文件：PLC项目、HMI项目、运动控制配置、EtherCAT拓扑文件、库文件及版本说明。需明确是否交付源代码、是否允许客户二次修改。
文档：包括硬件配置清单、I/O分配表、网络拓扑图、软件架构说明、操作手册、维护手册、报警代码表。文档应与最终程序版本一致，不能停留在设计阶段。
备份：完整工程备份、PLC运行时备份、HMI配方与历史数据备份、EtherCAT从站ESI文件备份。备份需注明日期、版本号和恢复步骤。
许可证：TwinCAT授权文件、第三方库授权、HMI运行时授权、Windows系统授权。需明确授权类型（完整版/运行时版）、绑定硬件标识和有效期。
测试报告：FAT/SAT记录表、问题跟踪清单、偏差项与关闭状态、签字确认页。测试报告是验收依据的核心载体。

交付物清单应逐项标注“交付形式”（纸质/电子/加密狗）、“交付时间”（FAT前/SAT后）和“验收依据”（对应哪份测试报告或检查表）。

四、验收依据的闭环关系

验收依据不是单独一份文件，而是“技术协议→验收标准→测试用例→测试报告→偏差关闭”的闭环。技术协议中的每一条功能描述，都应能追溯到至少一条验收标准；每一条验收标准，都应能追溯到至少一个测试用例；每一个测试用例的执行结果，都应记录在测试报告中。如果测试中出现偏差，偏差项必须记录在问题跟踪清单中，明确责任方、修复期限和复测结果，关闭后才能签署验收。

五、验收标准与交付物的对应关系

交付物清单中的每一项，都应在验收标准中有对应的检查点。例如：程序源文件的验收依据是“功能测试用例全部通过且代码审查无严重问题”；文档的验收依据是“文档完整性检查表逐项打勾，且版本号与最终程序一致”；备份的验收依据是“在干净环境中执行一次恢复演练，系统能正常启动并运行”；许可证的验收依据是“授权文件与目标硬件标识匹配，无试用期倒计时”；测试报告的验收依据是“所有偏差项已关闭，双方签字确认”。

如果某一项交付物找不到对应的验收依据，说明验收标准不完整；如果某一条验收标准找不到对应的交付物，说明交付物清单有遗漏。两者必须双向覆盖。

六、实操建议与常见陷阱

在实际项目中，最容易出问题的不是技术本身，而是验收标准的粒度。建议在FAT前两周与客户逐条评审验收标准，把“正常”“稳定”“快速”等模糊词全部替换为数值或可观察状态。对于无法量化的项目，例如HMI布局美观度，可以约定“以双方确认的UI设计稿为准”，并将设计稿作为验收依据的附件。

另一个常见陷阱是交付物版本混乱。程序、文档、备份、测试报告必须使用统一的版本号规则，例如“项目号_日期_修订号”。FAT通过后，任何程序修改都必须重新触发相关测试用例，不能只改程序不更新测试报告。否则SAT时客户拿到的程序与FAT报告不一致，验收依据就失效了。

建议做法：在项目启动阶段就建立“验收标准—测试用例—交付物”三列对照表，每完成一项开发任务就更新对应行。FAT前用这张表做一次内部预验收，把能测的先测掉，把不能测的提前暴露出来，避免正式验收时才发现标准无法执行。

注意：许可证交付时务必确认授权类型与硬件绑定关系。TwinCAT授权通常与目标PC的硬件标识绑定，如果客户更换工控机或网卡，授权可能失效。交付时应提供授权恢复流程说明，并确认客户已获得对应的授权文件或加密狗。

总结来说，FAT/SAT验收标准的核心是“可测量、可复现、可签署”，交付物清单的核心是“完整、版本一致、可恢复”。两者通过测试报告和偏差关闭记录形成闭环，才能让TwinCAT项目从开发阶段平稳过渡到量产交付阶段。