2. 产线PLC程序架构的基本概念

在产线自动化项目中，PLC程序往往从“能跑起来”开始，却在设备增加、工艺变更、人员更替之后迅速失控。根本原因通常不是指令写得不对，而是程序架构没有提前设计。程序架构是PLC程序在组织层面的骨架，它规定了程序由哪些部分组成、各部分如何分工、彼此通过什么接口交互、数据在哪里集中管理、变更时影响范围有多大。架构不直接决定某条指令能否执行，却决定了程序在三年后还能不能被安全地修改。

程序架构的定义与构成

产线PLC程序架构可以定义为：为满足产线控制需求，对程序模块、调用层次、数据组织、接口约定和运行调度方式所做的整体安排。它至少包含五个可观察的构成面：模块划分（有哪些程序块）、层次结构（谁调用谁）、数据组织（全局数据块、实例数据、接口参数如何分布）、接口约定（模块之间传递什么、以什么单位传递）、调度关系（主循环、中断、周期任务如何分配）。这五个面共同决定了程序的可读性、可测试性和可变更性。

模块化：把设备行为封装成可复用单元

模块化的核心不是“把程序拆小”，而是让每个模块承担一个明确、完整、可独立验证的职责。以一条典型装配产线为例，一台伺服压装机的控制逻辑可以封装为一个功能块 FB_PressStation，其内部包含使能、回零、压装、保压、返回、报警六个状态，对外只暴露启动、停止、复位、目标压力、目标位移、实际压力、实际位移、就绪、完成、故障等接口。这样，当产线增加第二台同型号压机时，只需再生成一个背景数据块实例，而不是复制粘贴数百行梯形图。

模块化的判断标准很实际：如果修改某台设备的节拍参数，不需要打开其它设备的程序；如果某台设备故障，可以单独禁用其模块而不影响整线扫描；如果同一类设备出现三次以上，就应该抽象为可复用功能块。反之，把整线逻辑写在一个 OB1 里，任何一处改动都可能牵动全局，这是架构失控的典型信号。

分层：从现场信号到产线协调

分层解决的是“不同抽象级别的逻辑不要混在一起”。产线PLC程序通常可分为四层：现场层处理传感器、执行器、安全信号；设备层实现单机动作序列与联锁；单元层协调多台设备的节拍、握手与物料流转；产线层负责配方、生产统计、与MES或上位机通信。分层的价值在于，现场层的变化（如更换传感器型号）不会波及产线层，产线层的排产调整也不需要重写设备动作。

耦合与内聚：架构质量的两个关键指标

内聚描述一个模块内部各元素的相关程度，耦合描述模块之间相互依赖的程度。好的架构追求“高内聚、低耦合”。高内聚意味着 FB_PressStation 内部的状态机、报警、参数计算都围绕压装这一件事；低耦合意味着它只通过明确定义的接口与外界交互，不直接读写其它设备的内部变量。

实际工程中，耦合最常见的恶化形式是“全局数据块滥用”。例如把所有设备的启动、停止、故障位都塞进一个 DB_Global，任何模块都可以随意读写。短期看很方便，长期看无法判断某个位被谁修改、何时修改。更合理的做法是：每个设备功能块拥有自己的背景数据块，跨设备共享的数据通过专门的接口数据块传递，并明确读写权限。可以用一个简单的关系判断：如果删除某个模块后，需要修改超过三个其它模块才能编译通过，说明耦合已经偏高。

架构质量属性

评价产线PLC程序架构，不能只看“能不能运行”，而应关注以下质量属性：可读性——新工程师能否在半天内理解某台设备的控制流程；可测试性——能否在不连接实际设备的情况下，通过仿真信号验证单机逻辑；可变更性——增加一个工位或修改节拍时，改动是否局限在少数模块；可复用性——同类设备能否通过实例化快速部署；可诊断性——故障发生时能否快速定位到具体模块和具体状态。这些属性之间可能存在权衡，例如过度分层会增加调用层级，降低扫描效率，因此需要根据产线规模和节拍要求做取舍。

产线设备对象映射

架构设计最终要落到“物理设备如何映射为程序对象”。推荐的映射规则是：一台具有独立动作能力的物理设备，对应一个功能块类型和一个背景数据块实例；设备的每个传感器和执行器，对应到该实例的输入输出接口；设备之间的物料交接，对应到单元层的握手功能块。以一条包含上料机、压装机、检测机、下料机的产线为例，可以建立如下映射关系：

这种映射方式带来一个直接好处：当压装机需要更换为另一型号时，只需替换 FB_PressStation 的内部实现或新建一个功能块类型，单元层和产线层的握手逻辑保持不变。反之，如果程序按“输入点—输出点”平铺编写，更换设备就意味着重新梳理大量地址，风险极高。

需要强调的是，架构没有唯一正确答案。一条只有三台设备、节拍宽松的小产线，可能不需要严格四层划分；而一条包含数十个工位、多品种混产、与MES深度集成的产线，如果缺少清晰架构，维护成本会迅速超过开发成本。判断架构是否合适的标准，是它能否让变更变得可预测、可控制、可验证。