3. 交付物清单策划

在西门子PLC项目验收与工程交付中，交付物清单不是一张简单的“文件列表”，而是把整个自动化系统的设计意图、实现过程、运行约束和后期维护入口固化下来的结构化成果。如果交付物缺失或版本混乱，验收时往往表现为“程序能跑但说不清”，运维阶段则表现为“改一个点要翻三天资料”。因此，交付物策划的核心任务是：先识别项目全生命周期中谁在什么阶段需要什么信息，再把这些信息映射为可命名、可版本控制、可验证的具体文件。

交付物结构的四个层次

从工程实践看，一套完整的PLC项目交付物通常分为四个层次，它们之间不是并列关系，而是“源—映射—说明—操作”的递进关系。

第一层：工程源文件。以TIA Portal项目文件为核心，包括项目归档文件（.zap*）、PLC站组态、HMI/SCADA组态、网络与设备组态、库文件、工艺对象等。这一层是“可再编辑”的根，必须保证归档时包含所有引用库和硬件支持包版本信息。建议在项目归档前执行“项目→归档”并勾选“包含库”，同时记录TIA Portal版本号、项目语言、最后编译时间。

第二层：设计映射文件。包括电气原理图（EPLAN或CAD输出的PDF/DWG）、IO分配表、网络拓扑图、柜内布局图、端子接线表。这一层把程序中的符号与现场物理点对应起来，是调试和排障的“地图”。其中IO表是连接程序与图纸的关键索引，必须包含：通道地址、符号名、数据类型、信号方向、量程/单位、对应图纸页号、对应端子号、备注。

第三层：程序说明文件。包括程序结构说明、块注释、变量注释、关键逻辑说明、报警与联锁清单、参数设置表。程序注释不是“有就行”，而是要保证一个未参与项目的工程师能在不打开程序的情况下理解主要控制逻辑。建议对FC/FB块头部统一填写“功能描述、调用条件、输入输出、修改记录”四段注释。

第四层：操作与维护文件。包括操作手册、维护手册、故障处理指南、备件清单、培训记录。操作手册面向现场操作员，应包含正常启停步骤、画面导航、报警确认与复位、权限说明；维护手册面向电气工程师，应包含程序下载步骤、IP地址表、密码管理、备份恢复流程。

IO表：交付物中的“索引中枢”

在四层结构中，IO分配表是最容易被低估、却最影响交付质量的文件。它同时被电气图纸、PLC程序、HMI画面和现场接线引用，一旦地址或符号不一致，排障时就会出现“图纸上找得到、程序里搜不到”的尴尬。策划IO表时，建议按以下字段组织，并在项目初期就确定命名规则，而不是等到验收前再补。

以一台三相异步电机控制为例，若IO表中只写“M1运行反馈 %I0.3”，验收时无法判断该点是常开还是常闭、是否接入安全回路。完整写法应为：%I0.3 | M1_Run_FB | Bool | DI | — | EPLAN 12.3 | X1:24 | 接触器辅助常开，运行反馈。这样即使程序被他人接手，也能在30秒内定位到物理端子。

程序注释与操作手册的交付边界

程序注释和操作手册经常被混为一谈。程序注释面向“改程序的人”，操作手册面向“用设备的人”。程序注释应写在TIA Portal的块接口和网络标题中，随项目文件一起归档；操作手册则应独立成PDF，不依赖TIA Portal即可阅读。一个常见的交付缺陷是：操作手册里写“按下启动按钮，Q0.0输出”，但现场操作员根本不知道Q0.0是什么。正确的写法是“按下操作台绿色启动按钮SB1，主电机M1启动，运行指示灯HL1常亮”。

交付物清单的策划流程

策划交付物清单时，建议按以下顺序推进，而不是先列文件名再补内容。第一步，明确项目合同或技术协议中约定的交付范围，区分“必须交付”和“建议交付”。第二步，按上述四层结构建立目录骨架，每层下再按子系统或工位细分。第三步，为每份交付物指定责任人、完成节点和评审方式，例如IO表由电气设计完成、PLC工程师会签。第四步，在项目中期进行一次“交付物预检”，重点检查IO表与程序符号是否一致、图纸页号是否可追溯、操作手册是否覆盖所有操作模式。第五步，验收前冻结版本，生成交付物清单总表，由各方签字确认。

最后需要强调，交付物清单不是越厚越好，而是“每一份都有明确读者、明确用途、明确版本”。对于小型项目，四层结构可以压缩为三份核心文件：TIA Portal归档包、IO表与电气图纸合订本、操作维护手册。对于中大型项目，则应在四层基础上增加网络拓扑、安全评估、FAT/SAT记录和培训材料。策划时始终问自己一个问题：如果明天我离开项目，接手的人能否只靠这些文件完成一次程序修改或故障排查？如果答案是否定的，交付物结构就还需要补充。