这次来看一个偏“标准化”的方向西门子 TIA Portal 下的 CPG 思路与 PACKML 编程框架。包装机械、灌装线、贴标机、装盒机这类设备程序写到最后往往不是功能做不出来而是状态乱、交接乱、改一个型号就到处找逻辑。PACKML 就是专门解决这个问题的标准状态模型。这篇文章会把 PACKML 的状态机、模式管理、标签体系和西门子 PLC 里落地的方式讲清楚最后给出可以直接照着做的验证流程和常见坑。先说结论这个框架适合包装机械厂、产线集成商、设备维护工程师尤其适合那些一个系列设备要做多个机型、多个版本程序的项目。它不解决工艺算法本身解决的是“设备怎么被操作、怎么报状态、怎么和 MES 或生产线管理系统对接”这一层。阅读完你至少能回答三个问题PACKML 的状态机到底是哪几个状态西门子 PLC 里怎么用 SCL 写一个可复用的状态机 FBHMI 和上位机怎么通过 PackML 标签读取设备状态。硬件的入门门槛不高常见的 S7-1200 / S7-1500 都可以跑状态机逻辑真正的成本在程序结构设计和团队规范。1. 核心能力速览能力项说明框架性质包装机械标准状态模型与程序组织框架基于 OMAC PackML / ISA-TR88 思路解决的核心问题设备模式混乱、状态不统一、HMI/上位机接口重复开发状态模型通常包含 Stopped、Idle、Starting、Execute、Completing、Complete、Held、Holding、Suspended、Suspending、Aborting、Aborted、Clearing 等模式管理支持 Manual、Automatic、Maintenance 等运行模式区分标签体系按 PackML Tag Suite 定义状态、模式、指令、产量等对外接口适用 PLCS7-1200 / S7-1500使用 TIA Portal 工程环境启动方式TIA Portal 项目集成库函数方式复用也可纯手写 SCL是否支持 HMI 对接支持状态/模式/指令可直接映射到 WinCC 画面是否支持上位机/API 对接支持通过 OPC UA / S7 通信读取 PackML 标签批量任务更适合标准化程序模板复用到多台设备适合场景包装机械标准机、多机型系列设备、产线联调、MES 数据上报实施难度中高难点不在代码量而在状态定义和团队规范这里要明确不要把这个框架当成一个“装上去就能用的软件包”它更接近一套工程方法论加一组可复用的 PLC 程序结构。不同厂家的落地方式有差异但状态机和标签语义高度一致这才是它最有价值的点。2. CPG 与 PACKML 到底解决什么问题2.1 为什么包装设备程序总是很难维护包装设备有一个特点机械动作多、传感器多、运行模式多。手动调试、半自动生产、全自动生产、清洗模式、换型模式、故障急停恢复这些如果不提前建模最后会变成大量互相嵌套的 M 继电器、置位复位指令或者一长串“某条件满足就跳转”的混乱逻辑。一个新工程师接手的时候根本不敢动状态互锁。常见混乱表现有三种每个工程师都按自己的习惯定义设备状态A 写的“运行”可能是 B 写的“自动模式”HMI 上按钮的逻辑没有统一入口一个急停恢复可能要重复在十几个画面里改上位机或 MES 想读设备状态时没有标准地址表每个项目都重新对点费时且容易错。2.2 PACKML 的定位PACKML 是 OMAC 组织发布的包装机械标准ISA-TR88.00.02 也有对应内容它把一台机器的运行行为抽象成一组标准状态、标准模式和标准标签。简单说它规定了一台包装机在任意时刻应该处于什么状态怎么从当前状态切换到下一个状态以及上位机通过哪些标签去观察和控制设备。PACKML 不是告诉你怎么写具体的凸轮曲线也不是告诉你气缸怎么动作而是定义“设备生命周期”的框架。具体工艺逻辑放在状态内部执行而状态的切换由统一的指令触发。2.3 西门子 CPG 框架的定位CPG 在这里指的是 Consumer Packaged Goods也就是消费品包装行业。西门子针对 CPG 行业的设备商和产线集成商通常会把 PACKML、ISA-88 批次模型、设备模板这些内容组合成一个工程框架方便在 TIA Portal 里按标准方式构建设备程序。实际项目里这套框架经常体现为一个标准的状态机 FB、一套 PackML 标签 DB、一组 HMI 标准画面模板外加程序注释规范和上位机接口约定。所以你可以把标题理解为“西门子在消费品包装行业里怎么用 PACKML 做标准化的设备编程框架”。3. PACKML 状态模型与标签体系3.1 标准状态机PACKML 的核心是一张状态切换图。不同版本的文档对状态命名略有差异但常用的状态可以归纳为下面这些。状态含义典型进入方式Stopped停机状态设备无动作上电初始化完成、复位完成Idle空闲待机可接收启动指令手动复位完成、Clearing 完成Starting正在启动执行启动逻辑在 Idle 下收到 Start 指令Execute运行执行设备正常生产Starting 完成Completing完成收尾例如处理完当前产品正常运行收到完成指令或批次结束Complete批次/订单完成Completing 完成Held暂停保持例如突发事件暂定运行中收到 HoldHolding暂停过程中运行中收到 Hold 指令后的过渡Suspended暂停等待例如等上游物料运行中收到 SuspendSuspending暂停等待过程中运行中收到 Suspend 指令后的过渡Clearing清除故障/异常故障条件下收到 Reset/ClearAborting紧急停止过程中急停触发、严重故障Aborted紧急停止完成Aborting 完成状态之间不是随意跳转必须符合标准定义。比如从 Execute 不能直接跳到 Idle一般要先经过 Completing 或 Aborting。这样做的意义是所有异常和完成逻辑都有清晰出口不会出现程序里某个标志位直接跳到“待机”而设备物理位置还在危险状态。3.2 模式管理PACKML 里除了状态还有模式。常用模式包括Manual手动模式操作员单步动作Automatic自动模式设备按流程运行Maintenance维护模式允许点动和维护操作。模式决定了操作指令的权限范围。自动模式下不允许手动点动某台电机维护模式下不允许执行完整生产流程。西门子落地时通常在 FB 中增加一个 Mode 变量所有指令都带上模式校验。3.3 PackML 标签组标签是上位机最关心的部分。标准做法是把所有对外接口集中到一个 DB包括State / Mode当前状态和模式Command 相关Start、Stop、Reset、Hold、Suspend 等命令位产量类GoodCount、RejectCount、TotalCount设备信息UnitID、ProductID、Speed故障类ActiveAlarm、AlarmCode。标签命名建议和设备程序解耦尽量直接采用标准名称。这样上位机开发人员不需要懂 PLC 内部地址只需要看标签表。4. 环境准备与前置条件4.1 硬件推荐PACKML 状态机本身对 PLC 性能要求不高逻辑量不大。但考虑到整个设备程序还要包含运动控制、HMI 通信、远程维护等功能建议按设备规模选择 CPU。设备规模推荐 PLC理由小型标准机S7-1200 系列成本低能跑状态机和基础运动控制中型多功能机S7-1500 系列性能充裕适合多轴、复杂包装设备高端生产线集成S7-1500 OPC UA数据交互要求高需要稳定对外接口如果你只是学习验证不需要立刻买硬件。TIA Portal 的 PLCSIM 仿真可以完成状态机逻辑和 HMI 仿真对学习很有帮助。4.2 软件环境需要安装西门子 TIA Portal建议使用 V17 或 V18 及对应版本的 PLCSIM、WinCC。注意不同版本创建的库和项目不能直接向下兼容高版本可以打开低版本项目低版本不能直接打开高版本项目。团队协作时建议统一版本。如果涉及具体硬件型号还需要在 TIA Portal 中安装对应 GSD 文件或硬件支持包。4.3 知识准备落地 PACKML 框架前建议先熟悉这几项TIA Portal 基本项目操作包括 PLC 组态、DB 块、FB 块SCL 语言的基础语法特别是 CASE 状态切换HMI 变量连接和画面切换OPC UA 或 S7 通信的基本概念。不需要写出多复杂的算法但一定要理解状态机的“状态是唯一的、转移是有条件的、指令是统一入口的”这三个原则。5. 在 TIA Portal 中搭建 CPGPACKML 工程5.1 项目结构建议一个标准化的设备程序建议在 TIA Portal 项目中建立清晰的目录结构设备程序项目 ├─ PLC_1 │ ├─ 程序块 │ │ ├─ Main [OB1] │ │ ├─ PackML_StateMachine [FB] │ │ ├─ Mode_Manager [FB] │ │ ├─ PackML_Tags [DB] │ │ ├─ Equipment_Module_Ctrl [FB] │ │ └─ Fault_Manager [FB] │ ├─ 工艺对象 │ │ ├─ 轴1 │ │ └─ 轴2 │ └─ 设备组态 ├─ HMI_1 │ ├─ 画面 │ │ ├─ 主画面 │ │ ├─ 状态画面 │ │ └─ 故障画面 │ └─ HMI 变量 └─ 公共数据 ├─ PackML_Common [DB] └─ 配方数据这种结构的好处是状态机、模式管理、故障管理是通用模块可以复制到同系列下一台设备工艺相关逻辑单独放一个 FB换机型时只改工艺 FB。5.2 创建 PackML 状态机 FB新建 FB 命名为PackML_StateMachine语言选择 SCL接口变量建议按下面分类设计输入接口变量名数据类型说明StartCmdBool启动指令StopCmdBool停止指令ResetCmdBool复位指令HoldCmdBool暂停指令SuspendCmdBool暂挂指令AbortCmdBool急停指令ModeInt当前运行模式ProcessReadyBool工艺条件准备好AutoCycleCompleteBool自动循环完成输出接口变量名数据类型说明StateInt当前状态值StateNameString当前状态名称BusyBool设备忙FaultBool故障标志调用方式在每个扫描周期无条件调用一次。状态机内部根据输入指令和当前状态决定下一次状态。工艺逻辑 FB 不应直接修改 State只能通过调用状态机的指令接口触发。5.3 标签 DB 设计对外统一的 PackML 标签建议单独放到一个 DB 中。示例结构{ State: 0, Mode: 0, CmdStart: false, CmdStop: false, CmdReset: false, CmdHold: false, CmdSuspend: false, TotalCount: 0, GoodCount: 0, RejectCount: 0, ActiveAlarm: 0, AlarmCode: 0, ProductID: 0, LineSpeed: 0.0 }在 TIA Portal 中创建 DB 时直接把每个标签建为对应名称的变量即可。HMI 和 OPC UA 都直接连接这个 DB不直接访问工艺 FB 内部变量。这样上位机看到的地址表永远稳定不会因为工艺逻辑调整而大面积对点。5.4 HMI 画面HMI 建议做一个通用设备状态画面包含当前状态文本显示模式选择按钮Start / Stop / Reset / Hold 等操作按钮产量统计显示当前故障信息。按钮的使能条件由 PLC 侧的状态机输出决定不要在 HMI 脚本里写太多状态判断。例如Start 按钮只在 Idle 状态可用Reset 只在 Aborted 状态可用。否则如果把状态判断分散到 HMI后期维护会很痛苦。6. SCL 实现状态机示例6.1 状态枚举与变量声明SCL 不支持类似 C 语言 enum 的关键字但可以用常量或直接赋值方式定义状态值。推荐在 FB 的 Static 区定义常量。// PackML 状态常量 CONST cStateStopped : 0; cStateIdle : 1; cStateStarting : 2; cStateExecute : 3; cStateCompleting : 4; cStateComplete : 5; cStateHolding : 6; cStateHeld : 7; cStateSuspending : 8; cStateSuspended : 9; cStateClearing : 10; cStateAborting : 11; cStateAborted : 12; END_CONST实际项目中状态值可以按你们团队的规范定义但一定要写文档并且建议和 HMI、上位机的枚举表保持一致。6.2 状态转移 SCL 骨架以下是一个简化的状态机骨架覆盖常用状态切换。实际项目需要增加互锁条件、超时判断、工艺完成信号等。CASE #currentState OF cStateStopped: // 上电完成或清障完成 IF #ResetCmd THEN #currentState : cStateIdle; END_IF; cStateIdle: // 空闲状态下收到启动指令进入启动状态 IF #StartCmd AND #ProcessReady THEN #currentState : cStateStarting; END_IF; cStateStarting: // 启动逻辑执行完成进入运行状态 IF #StartComplete THEN #currentState : cStateExecute; END_IF; cStateExecute: // 正常运行 IF #StopCmd THEN #currentState : cStateCompleting; ELSIF #HoldCmd THEN #currentState : cStateHolding; ELSIF #AbortCmd THEN #currentState : cStateAborting; ELSIF #AutoCycleComplete THEN #currentState : cStateCompleting; END_IF; cStateHolding: // 暂停过程中暂停完成进入 Held IF #HoldComplete THEN #currentState : cStateHeld; END_IF; cStateHeld: // 暂停保持后可恢复运行或停止 IF #StartCmd THEN #currentState : cStateExecute; ELSIF #StopCmd THEN #currentState : cStateCompleting; END_IF; cStateClearing: // 清除故障后回到 Idle IF #ClearingComplete THEN #currentState : cStateIdle; END_IF; cStateAborting: // 急停动作完成 IF #AbortComplete THEN #currentState : cStateAborted; END_IF; cStateAborted: // 故障复位 IF #ResetCmd THEN #currentState : cStateClearing; END_IF; END_CASE;这段代码是骨架不能直接复制到生产项目里就跑需要根据实际轴动作、气缸位置、安全条件补全互锁。6.3 模式与指令处理模式切换建议单独处理。模式切换通常在 Stopped 或 Idle 状态下允许运行时切换模式需要走标准停止流程。举一个简单判断// 只在 Idle/Stopped 状态允许切换模式 IF #currentState cStateStopped OR #currentState cStateIdle THEN #Mode : #ModeRequest; END_IF;输出侧需要把状态值映射到State接口变量同时生成状态文本。状态文本可以通过字符串数组实现#StateText : #stateNames[#currentState];如果状态机运行出现未定义状态建议直接进入 Aborting避免设备带着未知状态继续动作。6.4 故障管理配合状态机只负责状态切换具体故障判断建议放在单独的 Fault_Manager FB 中。故障管理的原则是每个故障有独立编号故障触发时向状态机发送 AbortCmd 或 HoldCmd故障恢复后由操作员确认并发送 ResetCmd故障记录写入诊断 DB便于 HMI 显示历史。这种设计把“故障是什么”和“状态机怎么响应故障”分开逻辑更清晰。7. 功能测试与效果验证7.1 PLCSIM 仿真测试没有硬件时可以用 PLCSIM 验证状态机逻辑。操作步骤在 TIA Portal 中组态一个 S7-1500 CPU在 OB1 中调用 PackML_StateMachine FB创建监控表添加 StartCmd、StopCmd、ResetCmd、State 等变量启动 PLCSIM 仿真下载程序用监控表修改输入变量观察 State 的变化。测试用例建议覆盖测试场景操作预期结果初始上电下载后观察State Stopped 或 Idle启动StartCmd trueState 从 Idle - Starting - Execute暂停Execute 状态置 HoldCmdState 从 Execute - Holding - Held恢复Held 状态置 StartCmdState 回到 Execute故障急停Execute 状态置 AbortCmdState 从 Execute - Aborting - Aborted故障复位Aborted 状态置 ResetCmdState 从 Aborted - Clearing - Idle每个状态切换都应该在监控表中确认。特别是急停路径必须验证任何状态都能进入 Aborting不能出现某个状态卡死。7.2 HMI 仿真测试在 TIA Portal 中创建 WinCC 画面把按钮和状态显示连接到状态机变量。启动 PLCSIM 和 HMI 仿真后使用仿真模式点击按钮确认按钮使能是否符合当前状态状态文本是否正确变化操作模式切换是否只在 Idle/Stopped 状态下允许。HMI 仿真测试的一个重要目的是检查按钮防抖。如果按钮按下后状态已经切换但按钮仍然显示可操作说明使能条件没有做好。7.3 状态切换时序观察状态机最容易出的问题不是状态不对而是状态切换过快操作员根本来不及判断原因。例如 Starting 阶段如果只有一个条件判断程序扫描周期又很快可能表现成 Idle 一闪就进入 Execute现场人员会困惑。建议状态切换时加一个最小持续时间或延时每个状态切换时要记录切换时间戳用于诊断。可以在 DB 中增加LastStateChangeTime变量记录状态切换时刻。8. 接口 API 与生产数据对接8.1 对外数据接口西门子 S7-1500 支持 OPC UA 服务器功能可以把 PackML_Tags 这个 DB 直接开放给上位机。上位机通过 OPC UA 读取设备的当前状态、模式、产量、故障码等数据不需要了解 PLC 内部程序结构。如果设备比较老旧或者使用 S7-1200也可以使用 S7 通信协议通过 S7.NET 或 Snap7 库读取。但 OPC UA 更标准化推荐优先使用。8.2 通过 OPC UA 读取 PackML 标签示例以 Python 为例使用asyncua库读取 OPC UA 节点。实际使用前需要确认 PLC OPC UA 服务器地址和节点 ID。import asyncio from asyncua import Client async def read_packml_tags(): url opc.tcp://192.168.0.1:4840 async with Client(urlurl) as client: # 节点地址需要按实际项目导出 state_node client.get_node(ns3;sPackML_Tags.State) mode_node client.get_node(ns3;sPackML_Tags.Mode) good_count_node client.get_node(ns3;sPackML_Tags.GoodCount) state await state_node.read_value() mode await mode_node.read_value() good_count await good_count_node.read_value() print(fState{state}, Mode{mode}, GoodCount{good_count}) asyncio.run(read_packml_tags())OPC UA 的节点 ID 不是随便写的需要从 PLC 侧导出 UA 地址空间或者用 UaExpert 浏览后确认。如果 PLC 型号不支持 OPC UA可以改用 S7 协议。8.3 批量数据采集思路多台设备统一用 PACKML 标签后批量采集就很有优势。可以建立一个数据采集服务定时轮询所有设备的 PackML_Tags设备A OPC UA - PackML_Tags 设备B OPC UA - PackML_Tags 设备C OPC UA - PackML_Tags | v 数据采集服务 | v 数据库 / MES / 看板字段就按标准标签对齐。比如所有设备的State字段含义一致那么“统计全场设备运行状态分布”就变成了一个简单 SQL 查询而不是逐个设备去问工程师某个地址到底是运行还是停止。8.4 失败重试建议OPC UA 读取失败时需要做重试和超时处理。建议逻辑单次读取超时设为 3 到 5 秒连续失败 3 次后标记设备离线设备离线时不覆盖旧数据保留最后已知状态数据入库时带上采集时间戳。这样即使某台设备重启或网络断开采集服务也不会崩溃恢复后能自动续采。9. 资源占用与性能观察PACKML 状态机本身的运行开销很小常规 1200 或 1500 都跑得动。但在项目实施时要注意观察这几个点程序扫描周期。如果设备本体程序很重又增加了状态机和故障管理逻辑需要检查 OB1 扫描周期。建议 S7-1200 控制在 10ms 以内S7-1500 根据实际需求控制在 1ms 到 10ms 之间。通信负载。OPC UA 开放后上位机如果频繁轮询会增加 PLC 通信负载。建议轮询周期不要低于 500ms数据变化不频繁的标签可以用订阅方式。数据块数量。每个 PackML 标签都保存在 DB 中如果多台设备程序模板长期不整理会产生大量重复 DB。建议统一由公共 DB 承载避免每个 FB 都有独立接口 DB。在线修改时内存占用。TIA Portal 在线修改会下载增量数据频繁修改程序会增加 CPU 内存的碎片项目稳定后尽量减少在线改动。性能观察方法在 TIA Portal 在线监控界面查看循环时间在 PLC 变量监控表中查看 CPU 负载率OPC UA 采集服务统计响应时间。如果发现扫描周期明显变长优先检查是否在 OB1 中直接做了大量通信指令或字符串处理把非实时任务移到定时 OB 或 Background OB 中执行。10. 常见问题与排查方法问题现象可能原因排查方式解决方案状态机不切换状态输入指令没到位或互锁条件不满足在监控表中检查输入变量状态逐条验证互锁条件必要时临时旁路测试状态跳变过快状态内没有延时或完成条件立即满足检查程序扫描周期和状态时序增加状态最小持续时间或完成识别HMI 按钮无响应按钮使能条件为 False 或变量连接错误检查 HMI 变量连接和使能表达式对照变量表修正连接急停后无法恢复Aborted 状态 Reset 后 Clearing 条件不满足检查 ClearingComplete 来源确认清障逻辑和恢复条件OPC UA 读不到数据节点 ID 错误或服务器未启用用 UaExpert 浏览地址空间导出正确节点 ID重新配置上位机读取数据不稳定轮询周期太短或网络延迟大检查通信延迟和丢包率增大轮询间隔使用订阅模式程序下载后状态丢失状态变量未保持确认 DB 是否启用保持性对关键状态变量启用 Retain多设备状态语义不一致模板未统一状态值定义不同对比各设备标签表和枚举统一状态表使用公共库最容易忽略的是保持性设置。设备运行时突然断电如果状态变量没有保持性上电后状态可能直接回到初始值而设备实际机械位置还停留在断电前位置存在安全隐患。所以 PackML 状态 DB 中的关键状态变量建议设置为保持性同时上电后必须经过安全回零或复位流程再进入 Idle。11. 最佳实践与合规建议11.1 工程规范状态机 FB 要写得纯粹只做状态切换和指令分发不写具体气缸控制每个状态必须有超时诊断避免设备卡死却无提示标签命名统一PackML_Tags 中的变量不允许随意删改程序注释写明每个状态的进入条件和出口条件项目交付时附带 PackML 标签表文档和状态图。11.2 安全与合规边界PACKML 解决的是控制程序标准化不能替代安全控制。涉及安全功能的部分例如急停回路、安全门、光栅必须按机械设备安全标准独立设计不能只在 PLC 程序里做软急停。对接上位机或 MES 时要注意生产数据权限控制。OPC UA 服务应设置用户认证和访问白名单。厂内网络与办公网建议隔离避免外部设备直接访问 PLC。如果设备会被人像、声音、版权素材等识别方式采集信息这里特别提醒必须提前获得授权并遵守当地隐私和数据保护要求。包装设备读取产品二维码、拍照检测外观时如果涉及到人员或非公开数据要在项目合同中明确数据使用边界避免合规风险。11.3 团队协作建议PACKML 框架要发挥价值不是一个人写一个 FB 就结束更重要的是整个团队按同一套规范维护。建议建立程序库由专人维护 PackML 状态机 FB 和标签 DB新项目从标准模板复制不允许从零重写状态机代码评审时重点检查是否有人在工艺 FB 中直接改状态变量每次项目结束把新增的通用逻辑回收到公共库。12. 总结与下一步这个框架最值得尝试的地方不是某个具体功能而是它能让一个团队的多台设备程序在结构上保持一致。先验证状态机能不能在 PLCSIM 里正确切换再验证 HMI 按钮使能逻辑接着做 OPC UA 读取测试基本就能判断这套方案适不适合你的项目。最容易踩的坑有三个第一状态机写成了大杂烩工艺动作全塞在状态切换里第二没有做状态保持和上电安全恢复第三标签表没有统一管理上位机还是各对各的地址。把这些解决掉PACKML 框架的收益会非常明显。下一步可以把这个框架从单机扩展到产线把每台设备的 PackML_Tags 统一采集到数据库做线体 OEE 看板再对接 MES 实现工单下发和产品追踪。整个路线不复杂但每一步对设备的标准化程度要求都很高PACKML 就是这层地基。