4. 验收标准与合同符合性
在WAGO自动化项目的验收交付阶段，最容易引发争议的问题往往不是“系统能不能跑”，而是“系统是否按合同和技术协议的要求交付”。技术协议、功能规格书、招投标文件、会议纪要、变更单等文档中散落着大量功能点、性能指标、接口要求和边界条件，如果验收时仅凭记忆或零散检查，极易遗漏关键条款，导致验收结论缺乏说服力。因此，本节的核心任务是建立一份可追溯验收矩阵，把合同与技术协议中的每一条要求，逐项映射到WAGO控制器的实际配置、程序实现和测试证据上。
一、验收矩阵的本质：需求—实现—证据的三向追溯
可追溯验收矩阵不是简单的检查表，而是一张“需求—实现—证据”的三向追溯网。它的每一行代表一条可独立判定的验收要求，每一列则记录该要求的来源、WAGO侧的实现载体、验证方法和判定结果。具体来说，矩阵至少应包含以下字段：
- 需求编号：来自技术协议或功能规格书的唯一标识，便于引用和追溯。
- 需求描述：用可判定的语言复述要求，避免“运行稳定”“操作方便”等模糊表述。
- 来源文件与条款号：明确该要求出自哪份文件的哪一条，防止后期扯皮。
- WAGO实现载体：对应到具体的硬件模块、I/O通道、程序功能块、变量名或HMI画面。
- 验证方法：检查、测试、演示、测量或文件审查。
- 判定标准：量化或可观察的通过条件。
- 证据编号：测试记录、截图、日志、测量报告或程序段编号。
- 结论：符合、部分符合、不符合、不适用。
这张矩阵的价值在于：任何一条验收结论都能沿着“合同条款→WAGO配置→测试证据”的路径反向追溯，任何一处变更也能正向评估影响范围。
二、从文档到矩阵：逐条对照的实际做法
实际项目中，技术协议和功能规格书往往由不同角色编写，条款粒度不一。建议先做一次需求条目化：把“系统应具备手动/自动切换功能”拆成“手动模式可强制输出”“自动模式按PID调节”“切换过程无扰”等可独立判定的条目。然后按以下顺序逐条对照：
- 硬件配置对照：核对WAGO控制器型号、电源模块、I/O模块数量与类型、通信模块、总线终端等是否与技术协议中的配置清单一致。例如协议要求“16路DI、16路DO、8路AI”，实际配置为750-430（8DI）×2、750-530（8DO）×2、750-455（4AI）×2，则数量与型号均需逐项确认。
- I/O点表对照：将功能规格书中的测点清单与WAGO实际通道分配表逐点比对，确认信号类型、量程、报警限值、滤波时间等参数一致。
- 程序功能对照：把功能规格书中的控制逻辑、联锁条件、时序要求，映射到WAGO CODESYS程序中的功能块、变量和任务周期。例如“急停后所有输出在200ms内切断”，需在程序中找到对应的安全逻辑和输出刷新周期。
- 通信与接口对照：核对Modbus TCP、PROFINET、OPC UA等通信协议的从站地址、寄存器映射、数据格式、心跳与超时参数是否与协议要求一致。
- HMI与上位对照：确认画面数量、报警分级、趋势记录、用户权限等是否覆盖规格书要求。
对照过程中，建议使用“三色标记法”：绿色表示已确认符合，黄色表示待验证或存在偏差，红色表示不符合或缺失。黄色和红色条目必须进入整改或澄清流程，不能带入最终验收。
三、可追溯验收矩阵的结构示意
下图展示了一个典型的验收矩阵追溯关系：左侧是合同与技术协议中的需求条目，中间是WAGO侧的实现载体，右侧是验证证据与判定结论。箭头表示追溯方向，便于快速定位每条需求的实现与证据。
四、判定标准与偏差处理
逐条对照时，判定标准必须事先明确。常见的判定方式包括：
- 检查：通过目视或文件审查确认配置与协议一致，如模块型号、接线端子标识。
- 测试：通过实际输入信号或模拟量，观察WAGO输出和HMI显示是否符合预期，如DI点触发后DO动作、AI超限报警。
- 演示：由操作人员按规格书场景操作，确认功能完整，如手动/自动切换、报警确认与复位。
- 测量：使用万用表、示波器或软件工具测量响应时间、通信周期、精度等指标。
对于“部分符合”或“不符合”的条目，不能简单标注后搁置，而应记录偏差描述、责任方、整改措施和复验结论。例如，技术协议要求“模拟量输入精度±0.1%”，实测为±0.3%，则需分析是模块选型、接线屏蔽还是滤波参数问题，整改后重新测量并更新证据编号。所有偏差的关闭状态必须可追溯，避免验收时出现“口头承诺已整改”但无记录的情况。
五、验收矩阵的交付与使用
最终交付的验收矩阵通常以电子表格形式呈现，按需求编号排序，并附上证据文件的索引。验收会议上，双方逐行确认结论，对“符合”条目快速通过，对“部分符合”和“不符合”条目重点讨论整改与复验安排。矩阵的每一行都应能回答三个问题：合同要求是什么？WAGO是怎么做的？凭什么说做到了？只有这三个问题都有明确答案，验收结论才具备合同符合性意义上的可追溯性。
此外，矩阵还应与变更管理联动。任何设计变更、程序修改或硬件替换，都应在矩阵中更新对应行的实现载体和证据编号，并评估是否影响其他关联条目。这样，验收矩阵不仅是一份静态检查表，更是贯穿项目交付全过程的需求追溯基线。