3. 交付物体系设计
在 ctrlX AUTOMATION 项目验收交付中，最容易引发争议的往往不是“系统能不能跑”，而是“哪些东西算交付、哪些不算”。如果交付边界没有在合同或验收方案中写清楚，客户会默认“现场看到的一切都应交付”，而集成商则可能认为“只交付合同清单里的硬件和程序”。这种认知差会在验收阶段集中爆发，导致尾款拖延、责任推诿甚至返工。因此，交付物体系设计的核心任务，是把项目成果拆成可清点、可核对、可签收的若干类别，并为每一类明确“交什么、以什么形式交、交到哪一步为止”。
ctrlX AUTOMATION 的交付物通常可以归为七类：硬件清单、软件授权、工程源文件、HMI/Web 面板、文档包、备件与工具包，以及贯穿其中的版本与介质管理。它们不是简单的文件罗列，而是对应不同的验收动作：硬件要核对型号与序列号，授权要核对授权码与绑定设备，源文件要核对可编译性与完整性，面板要核对可访问性与功能覆盖，文档要核对版本与语言，备件要核对数量与存储条件。下面这张图给出了七类交付物与验收动作之间的对应关系，可作为边界设计的总体参照。
硬件清单的交付边界，关键不在“列了多少行”，而在“每一行是否可追溯到实物”。一份可验收的硬件清单至少应包含：设备名称、ctrlX 订货号、序列号、数量、安装位置（柜号/工位号）、固件版本、随附附件。以 ctrlX CORE X3 为例，清单中应写明其订货号、MAC 地址、当前 ctrlX OS 版本，以及是否已插入存储卡。验收时按柜号逐台核对铭牌与清单，上电后通过 ctrlX OS 的“设备信息”页面确认固件版本与清单一致。若清单只写“ctrlX CORE 一台”，验收就无法判断是否被替换或降配，边界等于没有划清。
软件授权是边界争议的高发区。ctrlX AUTOMATION 的授权通常分为三类：ctrlX OS 平台自带的基础功能、按应用购买的 ctrlX OS 应用授权（如运动控制、OPC UA、可视化等）、以及工程侧软件授权（如 ctrlX WORKS 及相关选件）。交付边界要明确到“授权码、绑定设备、授权数量、有效期、是否可转移”。验收动作是：在目标设备上激活授权，确认应用功能可用且无试用倒计时；同时核对授权数量与合同一致。如果合同约定“含一年订阅”，就必须在交付清单中写明到期日，否则客户会默认永久授权。建议在清单中增加一列“授权类型”，区分永久、订阅、试用，避免口头承诺。
工程源文件的交付边界，核心是“可编译、可追溯、可维护”。交付内容通常包括：PLC 程序（含库文件与版本）、运动配置、安全配置、通信配置（EtherCAT、OPC UA、Profinet 等）、HMI 工程、Web 面板工程、变量表与注释。验收时不能只看文件是否存在，而应做一次离线编译：在干净的工程环境中打开归档，确认无缺失库、无路径错误、编译通过。同时比对现场运行版本与交付版本是否一致，建议用版本号或校验值锁定。若源文件缺少注释或变量表，客户后续维护成本会大幅上升，这类问题应在交付边界中明确“注释完整”作为验收条件。
HMI/Web 面板的交付边界，要区分“画面文件”和“运行入口”。交付物应包括画面工程源文件、报警列表、趋势配置、用户权限表，以及 Web 面板的访问地址、端口、账号策略。验收时逐画面点检：主画面、手动画面、报警画面、趋势画面、参数设置画面是否都能打开并响应；用不同权限账号登录，确认操作权限与合同一致。对于 Web 面板，还要确认浏览器兼容性与访问路径，避免客户在验收现场才发现只能用特定浏览器。若面板中嵌入了第三方组件或字体，也应在边界中说明是否随附授权。
文档包的边界，重点在“版本、语言、完整性”。典型文档包包括：电气原理图、网络拓扑图、I/O 分配表、设备手册、操作说明、维护手册、故障代码表、验收报告模板。验收时先核对目录，再抽页审阅，确认图纸版本与现场一致、语言为客户要求语言。文档包最容易出现的问题是“图纸是旧版”，因此建议在交付清单中为每份文档标注版本号和日期，并在验收时与现场实物比对关键回路。文档包不要求把所有内容都重写一遍，但必须保证客户能据此完成日常操作和基本排障。
备件与工具包的边界，要明确“数量、规格、存储条件、使用权限”。备件通常包括：保险丝、端子、继电器、存储卡、风扇、电池等易损件；工具包包括：专用下载线、调试工具、加密狗、标定工具。验收时按清单清点实物，确认规格与合同一致，并登记入库。对于有存储条件要求的备件（如电池、存储卡），应在边界中写明存储温度和防静电要求。工具包若涉及授权或密码，应一并交付并登记，避免客户在需要时无法使用。
最后，版本与介质管理是贯穿七类交付物的“粘合剂”。建议在交付时生成一份《交付物总清单》，为每类交付物分配唯一编号，记录名称、版本、数量、介质形式、校验值、签收人。介质建议使用带写保护的 U 盘或加密包，并保留一份归档副本。验收时逐项签收，任何未列入清单的“口头承诺”都不作为交付依据。这样做的目的不是增加流程，而是让交付边界在验收前就变成可核对的清单，减少现场争议，让尾款回收和项目关闭更顺畅。