4. 程序架构设计原则

PLC程序架构设计是自动化工程项目从“能跑”走向“好用、好改、好维护”的分水岭。许多工程师在编写单机设备程序时，习惯将全部逻辑堆叠在一个OB1或Main函数中，初期调试尚可应付，但一旦设备增加工位、更换工艺或出现故障，程序的可读性和修改成本便急剧恶化。本章围绕模块化、分层化、可复用性、可维护性与安全性五大核心原则展开，结合西门子TIA Portal与Codesys环境下的工程实践，给出可落地的架构设计方法与判断标准。

上图展示了五大原则之间的支撑关系：模块化是基础，分层化是骨架，可复用性是效率来源，可维护性是长期保障，安全性则是底线约束。实际项目中，这五者并非孤立存在，而是相互交织、彼此促进。例如，良好的模块化设计天然提升了可复用性；清晰的分层结构则直接降低了维护成本。下面逐一展开论述。

4.1 模块化设计：从“一坨代码”到“乐高积木”

核心原理

模块化是将复杂控制系统拆分为若干独立、完整、可交互的功能单元。每个模块封装特定的功能逻辑，对外提供明确的接口（输入参数、输出参数、全局变量访问点），内部实现细节对外部隐藏。在PLC编程中，模块化的最小载体是函数（FC）和函数块（FB），更大粒度的载体是程序组织单元（POU）和库文件。模块化的本质是“高内聚、低耦合”——模块内部元素紧密关联，模块之间仅通过接口通信，减少全局变量的滥用。

判断方法与操作流程

判断一个程序是否模块化，可以从三个维度审视：独立性（修改一个模块不影响其他模块）、完整性（每个模块完成一个明确的功能）、可替换性（模块可被同类实现替换）。操作流程上，建议按以下步骤推进：

1. 功能分解：将设备按工艺段或物理单元拆分，例如上料、加工、检测、下料。
2. 接口定义：明确每个模块的输入输出变量，尽量使用临时变量和局部变量，减少全局变量。
3. FB封装：对重复使用的逻辑（如电机启停、阀门控制、PID调节）封装为FB，带背景数据块。
4. 接口测试：单独验证每个模块的输入输出行为，确保模块独立运行正确。

案例拆解：多工位转盘机的模块化改造

某汽车零部件装配线有一台8工位转盘机，原程序将所有工位的动作逻辑写在OB1中，共约3000行梯形图。每次调整某个工位的传感器延时，工程师需要在线搜索“T37”“T38”等定时器编号，极易改错。改造方案如下：

• 将每个工位独立封装为FB（如FB_Station_1、FB_Station_2……），每个FB内部包含该工位的传感器、气缸、电机控制逻辑。
• 定义统一的接口：i_bStart（启动命令）、i_bPartPresent（工件检测）、q_bCylinderOut（气缸伸出）、q_bCylinderIn（气缸缩回）、q_bCycleDone（工位完成）。
• OB1中仅调用8个FB实例，并处理工位间的互锁逻辑。

改造后，调整某个工位的时序只需打开对应的FB，修改内部定时器参数，不影响其他工位。调试时间从原来的2天缩短到4小时，且新员工接手时能快速定位问题。

常见误区与总结

• 误区一：把模块化等同于“多建几个FC”。如果FC之间通过大量全局变量耦合，仍然不是真正的模块化。
• 误区二：模块粒度过细。每个气缸动作都建一个FB，导致调用关系复杂，反而降低可读性。
• 误区三：忽略模块的“自诊断”能力。好的模块应能反馈自身状态（运行中、故障、空闲），方便上层监控。

4.2 分层化设计：设备、工艺、管理三层架构

核心原理

分层化是将程序按职责划分为不同层级，每层只依赖下层提供的服务，不跨层调用。典型的PLC程序分层模型为：设备层（直接操作I/O、驱动、传感器）、工艺层（实现工序流程、顺序控制、联锁逻辑）、管理层（配方管理、生产统计、模式切换、HMI通信）。分层化的核心价值在于：当设备层硬件更换时，只需修改设备层程序，工艺层和管理层不受影响；当工艺调整时，只需修改工艺层逻辑。

判断方法与操作流程

判断分层是否合理，可以检查数据流向：是否所有数据都从设备层→工艺层→管理层单向流动？是否存在工艺层直接读写I/O地址的情况？是否存在管理层直接控制单个气缸的情况？操作流程建议：

1. 梳理I/O清单：将物理输入输出映射到设备层FB的接口变量。
2. 定义工艺步骤：在工艺层使用顺序功能图（SFC）或状态机描述工序。
3. 建立管理接口：管理层通过工艺层提供的命令接口（如“启动自动运行”“暂停”“切换配方”）下发指令，不直接操作设备。

案例拆解：包装线分层化重构

某食品包装线包含送膜、制袋、充填、封口、切断五个工艺段。原程序将HMI上的“自动/手动”切换按钮直接控制每个气缸的电磁阀输出，导致手动调试时容易误触发自动流程。重构后：

• 设备层：FB_Conveyor、FB_Sealer、FB_Cutter等，每个FB封装对应的电机、气缸、传感器控制，提供i_bManualCmd和i_bAutoCmd两个命令入口。
• 工艺层：FB_PackagingProcess使用SFC实现“送膜→制袋→充填→封口→切断”的顺序流程，每个步骤调用设备层FB的自动命令接口。
• 管理层：HMI通过DB块中的命令字（如CMD_START、CMD_STOP、CMD_RESET）与工艺层交互，不再直接访问设备层变量。

重构后，操作员在手动模式下只能逐个操作设备层FB，自动模式下由工艺层统一调度，彻底消除了模式切换时的逻辑冲突。

常见误区与总结

• 误区一：分层变成“多层皮”，每层只是简单转发变量，没有实际逻辑处理，反而增加扫描周期。
• 误区二：工艺层直接调用设备层FB的物理输出点，绕过设备层的联锁保护。
• 误区三：管理层与设备层之间建立直接通信（如HMI直接写Q地址），破坏分层结构。

4.3 可复用性设计：一次编写，多次使用

核心原理

可复用性是指程序组件能够在不同项目、不同设备、不同工艺中重复使用，无需修改或仅需少量参数调整。实现可复用性的关键手段包括：参数化设计（将设备参数如电机额定电流、气缸行程时间作为FB输入参数）、库文件管理（将通用FB放入库，支持版本更新）、标准化接口（遵循PLCopen等标准定义运动控制、PID等接口）。可复用性直接降低新项目的开发周期和测试成本。

判断方法与操作流程

判断一个FB是否具备可复用性，可以问三个问题：换一台不同功率的电机，这个FB需要改代码吗？换一个不同厂家的HMI，通信接口需要重写吗？换一个不同工艺顺序，控制逻辑需要复制粘贴吗？操作流程：

1. 提取通用逻辑：分析多个项目中重复出现的功能（如星三角启动、变频器控制、模拟量滤波）。
2. 参数化改造：将设备特定参数（I/O地址、量程、时间常数）全部改为FB输入参数或背景DB中的变量。
3. 建立库文件：在TIA Portal或Codesys中创建库项目，将FB、FC、数据类型、全局常量打包发布。
4. 编写使用文档：每个库组件附带接口说明、时序图、示例代码。

案例拆解：通用电机控制FB的复用

某设备商同时生产三种机型：A型（单速电机）、B型（双速电机）、C型（变频电机）。原方案为每种机型编写独立的电机控制程序，维护三套代码。现设计一个通用FB_MotorControl：

• 输入参数：i_eMotorType（枚举：单速/双速/变频）、i_rSpeedSetpoint（速度设定值）、i_bStartCmd、i_bStopCmd。
• 输出参数：q_bRunning、q_bFault、q_rActualSpeed。
• 内部逻辑：根据电机类型选择不同的控制分支，但对外接口完全一致。

新项目D型（伺服电机）需要增加时，只需在FB内部增加一个分支，不影响已有调用。该FB在三个项目中累计复用超过50次，每次复用节省约2人天的调试时间。

常见误区与总结

• 误区一：过度追求复用，将差异很大的设备强行统一到一个FB中，导致FB内部充满IF-ELSE分支，难以阅读。
• 误区二：库文件没有版本管理，更新后旧项目无法追溯。
• 误区三：忽略复用组件的“使用说明”，导致其他工程师误用参数。

4.4 可维护性设计：让程序“自解释”

核心原理

可维护性是指程序在交付后，能够被原开发人员或其他工程师高效地理解、修改、扩展和排障。可维护性不是单一技术，而是贯穿命名规范、注释体系、结构化编程、诊断功能、文档同步等多方面的综合工程素养。PLC程序的生命周期往往长达10-20年，而开发人员的流动率很高，可维护性直接决定了设备在生命周期内的总拥有成本。

判断方法与操作流程

可维护性评估可以从“新人接手时间”来衡量：一个完全不了解该项目的工程师，需要多长时间才能定位并修复一个中等复杂度的故障？如果超过1天，说明可维护性不足。提升可维护性的操作流程：

1. 制定命名规范：如全局变量前缀g_、FB实例前缀inst_、输入参数前缀i_、输出参数前缀q_、静态变量前缀s_。
2. 建立注释模板：每个FB头部必须包含功能描述、作者、日期、版本、修改记录；每个关键逻辑段必须有行注释。
3. 添加诊断功能：在设备层FB中增加故障检测（如电机过载、气缸超时、传感器无响应），并输出故障代码和故障时间戳。
4. 同步更新文档：I/O表、变量表、程序结构图、操作手册必须与程序版本同步。

案例拆解：故障诊断的可维护性实践

某注塑机程序频繁出现“合模不到位”报警，但原程序只输出一个布尔量Alarm_Clamp，维修人员无法判断是位置传感器故障、液压压力不足还是机械卡死。改进后：

• 在FB_ClampUnit中增加诊断逻辑：检测合模命令发出后2秒内是否收到到位信号，若超时则记录q_wFaultCode（16#1001表示传感器无信号，16#1002表示压力不足，16#1003表示位置偏差过大）。
• 将故障代码和时间戳写入独立的诊断DB，HMI上显示“故障代码+故障时间+可能原因”。
• 维修人员根据故障代码直接定位到具体传感器或液压阀，平均排障时间从45分钟缩短到10分钟。

常见误区与总结

• 误区一：注释只写“做了什么”，不写“为什么这么做”。例如“延时2秒”应注释为“等待气缸完全伸出，避免与下一工位干涉”。
• 误区二：变量命名使用拼音缩写或无意义字母（如a1、b2），导致程序无法阅读。
• 误区三：诊断信息只存当前值，不存历史记录，故障发生后无法追溯。

4.5 安全性设计：从“功能安全”到“信息安全”

核心原理

PLC程序的安全性包含两个维度：功能安全（设备在正常和故障工况下都不会对人、机器、环境造成伤害）和信息安全（防止未经授权的访问、修改或恶意攻击）。功能安全的核心是“安全回路独立于控制回路”，即紧急停止、安全门、光栅等信号必须通过硬接线安全继电器或安全PLC处理，不能仅依赖普通PLC程序。信息安全则涉及访问级别控制、程序加密、通信认证等。

判断方法与操作流程

判断安全性设计是否到位，可以检查：急停回路是否独立于CPU？安全门打开时，所有危险运动是否立即停止？程序是否设置了密码保护？HMI是否有操作员/工程师/管理员分级权限？操作流程：

1. 安全风险评估：识别设备的危险源（夹伤、剪切、高温、高压），确定所需的安全等级（PLr/SIL）。
2. 安全回路设计：将急停、安全门、光栅等信号接入安全继电器或安全PLC，输出直接控制接触器/伺服使能。
3. 程序内安全联锁：在工艺层增加软联锁（如“门开时禁止自动启动”“气压不足时禁止合模”）。
4. 访问控制：在TIA Portal中设置不同级别的访问权限，HMI用户分为操作员（仅可启停）、技术员（可修改参数）、工程师（可修改程序）。

案例拆解：冲压设备安全改造

某冲压设备原程序将急停信号接入普通PLC输入，通过程序控制伺服停止。在一次急停测试中，由于PLC扫描周期（10ms）延迟，滑块多下行5mm，险些造成事故。改造方案：

• 将急停按钮、安全门开关、光栅信号全部接入安全继电器（Pilz或Sick），安全继电器输出直接切断伺服驱动器的STO（安全转矩关闭）端子。
• PLC程序仅接收安全继电器的状态反馈（i_bSafetyOK），用于HMI显示和故障记录，不参与安全控制。
• 在工艺层增加软联锁：i_bSafetyOK为FALSE时，禁止任何自动或手动运动命令。

改造后，急停响应时间从PLC扫描周期（10ms）缩短到安全继电器动作时间（<5ms），且即使PLC死机或程序跑飞，安全回路仍能独立保护设备。

常见误区与总结

• 误区一：认为“PLC程序里写了急停逻辑就安全了”，忽略了安全回路的独立性要求。
• 误区二：所有HMI用户使用同一密码，无法追溯操作记录。
• 误区三：程序上传下载无保护，现场工程师可随意修改，导致版本混乱。

4.6 五大原则的综合应用与权衡

在实际项目中，五大原则并非总是完全一致，有时需要权衡。例如，过度模块化可能降低扫描周期效率；过度分层化可能增加程序跳转层级；过度追求可复用性可能使FB接口过于复杂。下表总结了各原则的优先级建议和常见冲突场景：

设计原则	优先级建议	常见冲突	权衡策略
安全性	最高，不可妥协	安全回路增加硬件成本	安全投入视为必要成本，不参与权衡
模块化	高	模块过多导致扫描周期变长	合理控制模块粒度，将高频调用模块优化为FC
分层化	高	层间数据传递增加编程量	使用UDT（用户自定义类型）批量传递数据
可复用性	中高	通用FB接口复杂，学习成本高	提供简化封装和高级配置两套接口
可维护性	中高	注释和诊断增加开发时间	将诊断功能作为标准模板，新项目直接套用

综合应用时，建议采用“安全优先、模块为基、分层为架、复用增效、维护保底”的总体策略。在项目启动阶段，先完成安全风险评估和架构设计评审；在编码阶段，严格执行模块化和分层化规范；在测试阶段，验证安全功能和诊断功能；在交付阶段，确保文档和程序版本一致。

程序架构设计原则不是纸上谈兵的理论，而是经过大量项目验证的工程方法论。模块化让程序“拆得开”，分层化让程序“理得清”，可复用性让程序“用得广”，可维护性让程序“改得动”，安全性让程序“靠得住”。在实际项目中，建议从一个小型设备开始实践这些原则，逐步形成适合自己团队和行业特点的编程规范。当这些原则内化为习惯后，你会发现PLC程序不再是“一次性代码”，而是可以持续积累和增值的工程资产。