PLC编程标准到底是什么？ISA88与IEC 61131-3详解

逛工控论坛的时候，经常能看到一类帖子，讨论PLC编程有没有标准，底下一定会有人搬出ISA88，再带上一句“全球公认”。最近有条帖子的标题很有代表性：《0913【万泉河】PLC编程标准，全球公认的标准 ISA88（不是真的）》。标题里那句“不是真的”加得很精妙——ISA88这个名字在圈子里流传极广，可大家其实也隐隐觉得，把它当成“PLC编程标准”这件事有点不对劲。我做过不少PLC和DCS项目，也面试过很多工程师，今天就把这个话题掰开揉碎讲一讲，顺便把自动化标准体系完整梳理一遍。

这篇文章适合谁看？新入行的PLC工程师、在流程行业做批处理控制的自动化工程师、需要对外解释“程序按什么标准写”的负责人，还有那些听到ISA88就条件反射想起SFC的程序员。你能从这里得到的不是一套“背了就能过面试”的套话，而是几个真正能用来组织项目、写程序、做评审的判断框架。

1. 先掰扯清楚：ISA88到底是什么，不是什么

1.1 ISA88是批过程控制标准，不是编程语言标准

先给结论：ISA88是真的标准，而且有年头了。它的正式名称叫Batch Control，最早由美国ISA（国际自动化学会）在1990年代中期发布，后来被国际电工委员会采纳为IEC 61512系列标准。这里要特别注意一个定位差异——ISA88规范的不是“用什么语言写程序”，而是“批量生产过程怎么描述、怎么组织、怎么复用”。它解决的问题是：一个工厂里可能同时用PLC、DCS控制几十台反应罐和几百台阀门，生产各种配方不同的产品，程序如果不分层、不模块化，每个人写出来都不一样，厂家一换、工程师一走，程序就成了黑盒子。

所以才有了ISA88。它把批生产过程拆成一套分层模型，让工程师可以像搭积木一样描述生产流程。这套模型是ISA88的灵魂，也是后来说它影响PLC编程的原因。

1.2 物理模型、程序模型和配方：ISA88的三大支柱

ISA88的核心内容可以概括成三大块。

第一块是物理模型。它把工厂设备从大到小拆成若干层级：工厂/Site、车间/Area、过程单元/Process Cell、单元/Unit、设备模块/Equipment Module、控制模块/Control Module。举个好理解的例子，一条生产线是一个Process Cell，里面每个反应罐是一个Unit，反应罐上的搅拌电机、夹套进水阀、进料阀各自是Equipment Module，而阀门的开到位信号、电机的接触器反馈这些最底层的点属于Control Module。这样分层的意义在于，任何一个控制逻辑都能被放到合适的层级去实现，而不是拍脑袋写在某个不相关程序段里。

第二块是程序模型。它把控制程序也分了层：Procedure（过程）、Unit Procedure（单元过程）、Operation（操作）、Phase（阶段）。Phase是最小的不可再拆分的过程环节，一个Phase执行完，才可以进入下一个Phase。这种“步进式”的结构，和PLC里常用的顺序控制思路天然契合，这也是很多人误以为ISA88是编程标准的直接原因。

第三块是配方模型。配方（Recipe）里定义了做一批产品需要哪些动作（Procedure）、多少原料（Formula）、哪些设备（Equipment Requirement）。比如生产一批果味饮料，配方规定了进料顺序、搅拌时间、加热温度、降温速率。产品切换时，不需要重写PLC程序，只需要切换配方。

用做菜类比就更好懂了。物理模型就是你的厨房：锅、灶、料理台、刀；程序模型就是做菜的步骤：备菜、炒制、装盘，其中炒制又能拆成热锅、倒油、下菜、翻炒、调味；配方就是菜谱：宫保鸡丁和鱼香肉丝的步骤结构基本相同，但调料比例和火候参数不同——这不就是流程行业“同一套设备生产不同产品”的缩影吗。

1.3 它没有规定任何编程语言

ISA88全文看下来，几乎没有一行内容规定你用梯形图、功能块图还是结构化文本。ISA88回答的是“做什么”和“怎么组织”，不是“用什么语言写”。这就决定了它不可能替代IEC 61131-3成为“PLC编程标准”。如果你把ISA88当PLC编程标准去学，会发现它不教你怎么写一段PID控制，也不讲怎么处理扫描周期，它的着眼点在生产过程建模上。换句话说，ISA88是给“过程”立规矩的，IEC 61131-3才是给“程序”立规矩的。

2. 误解从哪来：为什么有人把ISA88当PLC编程标准

2.1 历史背景：批处理系统的程序组织需求催生了ISA88

ISA88的诞生背景，其实就埋下了被误读的种子。上世纪八九十年代，制药、化工、食品饮料这些流程行业大量用DCS和PLC搭批处理系统。每条生产线可能有好几个罐，每个罐要执行进料、混合、加热、保温、冷却、出料一整套动作。那时候的程序大部分是工程师个人发挥，有人写在梯形图里，有人写在顺序器里，程序和硬件设备强耦合。一个工程师离职，下一个接手的人得花好几周去“考古”。

ISA88解决的正是这个痛点，它提出“把设备和流程分开建模”。于是很多厂商开始按ISA88的模型来组织PLC程序——把一个罐的控制写成若干个Phase功能块，再通过上层的Operation去调用。因为ISA88确实深度参与了“PLC程序怎么组织”这件事，从2000年以后，越来越多的工程师在讨论程序架构时引用ISA88。但请注意，这仍然是“借鉴模型来组织程序”，不等于“ISA88是PLC编程语言标准”。

2.2 SFC和Phase长得太像，边界被模糊了

第二个原因更直接：ISA88的Phase模型和IEC 61131-3里的SFC（顺序功能图）在外观和思路上都太像了。SFC用步（Step）和转换（Transition）描述顺序控制，步里有动作；ISA88用Phase描述一个阶段，每个阶段里也可以有步进逻辑。一个工程师先用SFC写了顺序程序，再去看ISA88，会非常自然地产生“这俩不是一回事吗”的感觉。

实际上，ISA88的标准文本里也用了类似SFC的图形来表示Phase之间的切换。但要注意，SFC是一种编程语言的表达方式，它只是描述“这段程序在不同步之间怎么跳转”；而ISA88的Phase是过程控制的组织单元，它除了包含执行逻辑，还包含状态、模式、互锁、配方参数和报警管理。你可以用SFC实现一个Phase，也可以用FBD和ST实现。把这两者混为一谈，是行业里最常见的认知误区。

2.3 “标准”这个词被用滥了，层级感丢了

还有一个很现实的原因：中文里“标准”这个词太宽泛。ISA的正式出版物里，严格区分了Standard（标准）、Technical Report（技术报告）、Recommended Practice（推荐实践）；到了国内，无论是国家标准、行业标准、企业标准，还是某个大厂内部的编程规范，都被统称为“标准”。于是ISA88被叫标准，IEC 61131-3被叫标准，某PLC品牌自己的程序模板也被叫标准，甚至连网上流传的一份《PLC编程规范》PDF也被叫标准。层级一乱，概念就乱。真正把自动化标准体系放在同一个维度上比对过的人，其实并没有想象中那么多。

3. 真正的PLC编程标准：IEC 61131-3到底规定什么

3.1 软件模型：从Configuration到Function Block的六层体系

既然要说“PLC编程标准”，那IEC 61131-3是绝对绕不开的。它才是真正定义“PLC程序应该怎么写”的国际标准。IEC 61131-3里首先规定了一个软件模型，从大到小依次是：Configuration、Resource、Task、Program、Function Block/Function、变量。

用人话解释。Configuration相当于整个PLC项目，它定义这台PLC的硬件配置和连接方式；Resource相当于处理器核心，一个Configuration可以有几个Resource，对应多核处理器或者不同任务域；Task是调度器，它决定每个程序按什么周期执行、由什么事件触发；Program是程序的组织单元；Function Block（功能块）是带内部状态的程序模块，比如定时器TON、PID控制块、电机控制块；Function是纯函数，同样输入永远得到同样输出，比如加法和字节转换。

这一层一层分下来，标准本身就倡导了一种“结构化”的思考方式：程序不是一堆梯形图堆在一起，而是有层次、有命名空间、有数据隔离的工程。

3.2 五种编程语言，什么时候用哪个

IEC 61131-3定义了五种编程语言：梯形图（LD）、功能块图（FBD）、结构化文本（ST）、指令表（IL）、顺序功能图（SFC）。这里最容易踩的坑是“PLC编程=梯形图”，实际上现代大型项目很少只用梯形图。

我做项目时的分配习惯是：联锁和电气回路用LD，因为它直观，电气工程师也能一起审图；过程控制回路和模拟量处理用FBD，信号流清楚，PID调试时方便；复杂的数据处理、配方计算、状态机逻辑用ST，因为写起来快、可读性强；顺序控制用SFC，特别是多步生产流程，阶段划分一目了然。IL现在已经很少用来开发新项目，更多是历史程序维护用。这五种语言可以混用，标准并不强制“一个项目只能用一种语言”，这给了工程师很大的发挥空间。

记住一个关键点：IEC 61131-3只管编程语言和软件模型，它不管你怎么拆批次、怎么定义配方、怎么和MES交互。所以它和ISA88不是竞争关系，而是互补关系——一个管语言和程序结构，一个管过程和设备建模。

3.3 更大的标准地图：IEC 61131-3、ISA88、ISA95、PLCopen、PackML各管什么

再把视野拉高一点会发现，自动化领域其实有一张标准地图，每张“标准”管一个剖面。IEC 61131-3管“编程语言和软件模型”；ISA88/IEC 61512管“批过程控制模型”；ISA95/IEC 62264管“企业层和控制系统层的集成”（就是常说的ERP到MES到控制系统的数据流）；PLCopen管“IEC 61131-3基础上的应用库”，最典型的就是运动控制功能块；PackML（ISA-TR88.00.02）管“单台设备/包装机械的状态模型”。

把这几个放在一起看清楚之后，你再去听别人说“我们按ISA88编程”，心里就有数了：他大概率是在说我们用ISA88的模型来架构批处理程序，但写代码落地的语言还是IEC 61131-3；如果他说“我们用PackML”，那他强调的通常是单机自动化设备的状态标准化，不是整个生产过程。

4. 一次理清容易混淆的自动化标准（对照速查表）

4.1 核心标准速查对照表

我把常见的容易混淆的标准化文件列成一张表，项目评审、技术交流时直接对照。

这张表最关键的用途是：遇到“按标准编程”的说法，先问一句“是哪个层面的标准”。语言层面、过程模型层面、系统集成层面，用的东西完全不一样，混着谈永远理不清。

4.2 不同项目的正确用法

面对不同类型的项目，标准的组合方式其实有规律可循。

如果你做的是单机设备，比如一台包装机、一台注塑机，最实用的组合是IEC 61131-3负责程序语言，PackML负责设备状态管理和界面状态显示，PLCopen负责运动控制。这样客户看到的触摸屏状态（执行、暂停、完成、报警）是统一的，后续做远程监控和数据采集也方便。

如果你做的是流程行业的批处理项目，比如反应罐、发酵罐、配料系统，那重点就是IEC 61131-3写逻辑、ISA88定架构：物理模型拆设备层次，程序模型拆批次动作，配方模型做产品切换。等到项目要上MES，再把ISA95里的信息模型拿来做接口规划，让MES能看懂PLC里的批次数据。

最怕的是什么？最怕的是做一个单机设备，项目周期两个月，硬要照着ISA88全模型从Process Cell拆到Control Module，导致过度设计；反过来，做一个大型连续化工项目，却只用梯形图平铺几百个程序段，连Operation和Phase的概念都没有，最后程序维护难度指数级上升。标准是工具，不是装饰品。

5. 实操启示：把ISA88的模型思想用到PLC程序里

讲完理论，来点实际的。ISA88虽然不是编程语言标准，但它的建模思想放到今天依然非常值得在PLC项目里借鉴。我下面用一套实际落地过的架构来讲。

5.1 设备模块化：把电机、阀门、仪表封装成功能块

ISA88物理模型里最实用的一层是Equipment Module。落到PLC里，就是一个一个有标准接口的功能块。以搅拌电机为例，功能块通常包含这些接口：启动/停止命令、远程/本地模式、现场反馈、故障反馈、联锁条件，以及内部的状态和报警。外部程序只需要发命令、读状态，不看内部的梯形图实现。这样做的好处很多：第一，联锁逻辑集中在一个块里，不会散落在几百行程序里；第二，工程师换人后不用从头读一个项目的每个细节，只要会看接口就能上手；第三，同一设备在多个罐上可以反复实例化，项目复制速度快。

一个设备模块的状态输出通常包括运行、停止、故障、联锁激活等。可以额外定义更细的状态，比如“本地操作中”“启动中”“停止中”，这些都是设备模块内部自己管的事情，不暴露给上层，上层只关心命令和结果。

5.2 按Operation/Phase组织程序：以一个反应罐为例

假设一个反应罐R101，要完成“进料、搅拌加热、保温反应、放料”四个阶段。按照ISA88程序模型，可以这样拆：

Unit：R101（对应一个Unit Procedure，叫“生产产品A”） Operation 1：进料

• Phase 1.1：检查进料条件（罐空、放料阀关、搅拌未运行）
• Phase 1.2：打开进料阀，按流量累计进料
• Phase 1.3：进料完成，关闭进料阀

Operation 2：反应

• Phase 2.1：启动搅拌电机
• Phase 2.2：夹套通入蒸汽，升温至目标温度
• Phase 2.3：保温计时，按配方维持温度
• Phase 2.4：反应结束条件满足（时间或pH），停搅拌

Operation 3：放料

• Phase 3.1：确认下游设备就绪
• Phase 3.2：打开放料阀
• Phase 3.3：吹扫管线
• Phase 3.4：关闭放料阀，复位状态

每一层都有自己的命名空间，每个Phase有明确的入口条件和出口条件。操作员在HMI上看到的不是密密麻麻的梯形图，而是“当前处于Operation 2的Phase 2.3，保温剩余8分钟”，这对工厂操作员来说非常友好。更重要的是，如果产品B只是加热温度不同、保温时间更长，只需要改配方，不需要改PLC程序结构。

5.3 状态机是ISA88留给PLC编程最值钱的遗产

ISA88的标准里定义了一组经典的设备/过程状态：IDLE（空闲）、RUNNING（运行中）、PAUSED（暂停）、HOLDING（保持中）、HELD（已保持）、COMPLETED（已完成）、ABORTING（中止中）、ABORTED（已中止）、STOPPING（停止中）、STOPPED（已停止）。这些状态串起来就是一台设备或一个Phase的生命周期。

很多PLC程序写得乱，不是因为工程师不会写梯形图，而是因为程序里没有状态概念。你按下启动按钮，程序把电机转了、阀门开了，下一步干什么全被堆在一串置位/复位指令里，一旦出现中途异常，根本没法优雅地停下来。引入状态机之后，一切操作都是“根据当前状态决定是否接受新命令”，程序的控制逻辑会变得非常清晰。

下面是一段用IEC 61131-3结构化文本写状态转移的示意代码，展示一个Phase的核心骨架：

CASE eState OF IDLE: IF bCmdStart THEN IF bPrefCond THEN // 预条件满足 eState := RUNNING; END_IF; END_IF; RUNNING: bOutput := TRUE; // 驱动执行机构 IF bCmdPause THEN eState := PAUSED; ELSIF bDone THEN eState := COMPLETED; ELSIF bFault THEN eState := ABORTING; END_IF; PAUSED: bOutput := FALSE; IF NOT bCmdPause THEN eState := RUNNING; END_IF; ABORTING: bOutput := FALSE; // 执行安全复位动作 IF bResetDone THEN eState := IDLE; END_IF; COMPLETED: IF bCmdReset THEN eState := IDLE; END_IF; END_CASE;

这段代码虽然简单，但它明确了一个原则：状态是这个模块的唯一事实来源（single source of truth），任何操作按键、配方指令、报警信号，都要先经过状态判断，再决定要不要执行。这就是ISA88的思维方式。

5.4 结合IEC 61131-3语言落地的参考架构

把ISA88模型和IEC 61131-3语言放在一起，一个批处理项目里的程序结构可以是这样：

Configuration: BatchPlant Resource: PLC_CPU Program: RecipeManager // 配方管理，使用ST Program: UnitProcedure_R101 // 单元过程调度，使用SFC Program: Operation_React // 操作层，使用ST或FBD Program: EquipmentModule // 设备模块功能块，使用FBD/LD

实际中我不建议把每一层都建一个独立Program，项目规模小的时候，UnitProcedure和Operation可以合并成一个SFC组织单元，EquipmentModule用功能块实例。关键是要让代码的物理层次名称和ISA88的模型命名对得上，这样以后无论是做MES接口还是技术交接，别人一眼就能看懂。

6. 避坑清单：这几个误区，我见一个纠正一个

6.1 “ISA88不是真的”这个说法，到底该怎么理解

回到标题里的那句“（不是真的）”。这句话悬在很多工程师心里，但必须分清楚：ISA88这个标准是真的，而且在国际上被广泛采用，作为批过程控制模型完全没问题。真正“不是真的”，是另一句话——“ISA88是全球公认的PLC编程标准”。这个说法站不住脚，因为ISA88从设计目标到标准内容，从来就不是编程语言标准。所以，下次再看到类似争论，可以反问一句：你说的“编程标准”，是指写程序用的语言标准，还是指组织控制逻辑的模型标准？把这个问题问清楚，一半的争论就消失了。

6.2 面试和项目评审中，如何正确回答“PLC编程遵循什么标准”

这个问题我在面试里问过无数次，大多数人的回答都会卡壳。比较好的回答方式是这样分层给：

• 程序语言层：遵循IEC 61131-3标准，根据场景选择LD、FBD、ST、SFC；
• 批量过程控制层：如果是批处理项目，参照ISA-88/IEC 61512的物理模型和程序模型做架构；
• 单机设备层：如果是单机或包装机械，参考PackML状态模型；
• 工厂集成层：如果涉及MES/ERP对接，按ISA-95/IEC 62264做信息交互规划。

这样回答既准确又完整，而且体现出你理解标准的层级关系，而不是背了一个名词就往上套。项目评审的时候也一样，先界定清楚讨论的是哪一层，再评价这个层有没有落实标准要求，效率会高很多。

6.3 学习建议：把标准吃透，而不是背结论

最后分享一点学习心得。我见过太多人收集了几十张“一张图看懂ISA88/ISA95”的知识卡片，真正做起项目来还是不知道从哪下手。我的建议是：

第一，直接读标准原文。ISA-88 Part 1就是一本很薄的小册子，信息密度远高于任何二手解读。不需要一字不差，重点看物理模型、程序模型、配方模型那几章，花一个周末就能过一遍。第二，拿手头的项目对照一下：你上一个项目的设备能不能拆成Unit和Equipment Module？你的程序能不能按Operation和Phase命名？如果拆不动，说明架构上可以改进。第三，看大厂的工程模板白皮书，很多DCS和PLC品牌都发布过基于ISA88的批处理解决方案，里面有现成的架构实例可以研究。

标准学习从来不是一次性的，我的经验是每做一个新行业项目，回来看一遍标准，都会有新的理解。比如做食品的时候你更关注清洗流程里的Phase划分，做精细化工的时候你更关注配方的版本管理，这些体会是纯理论学习得不到的。

最后再讲一点我自己的感受。刚开始做PLC那几年，我也觉得程序能跑就行，标准什么的都是给大公司做表面文章用的。后来真正栽过跟头：一套老设备交接过来，几千行梯形图散落在十几个程序段里，没有状态机，没有模块化，一个阀门开到位信号被复制了六个副本，改一个地方冒出一堆报警。从那之后我才意识到，ISA88和IEC 61131-3这些标准最值钱的地方，不是那个“全球公认”的名头，而是它逼着你在一开始就想清楚：设备怎么分层，程序怎么组织，状态怎么定义。把这些想清楚了，程序写起来反而会慢一点，但调试、交接、维护的周期会大幅缩短。如果你现在也处在“程序写得越久越怕接手项目”的阶段，不妨从ISA88的模型和IEC 61131-3的语言规范入手，重新理一遍自己的程序架构。这个投入，迟早会赚回来。