2.1 标准化核心思想：软硬件解耦

2.1 标准化核心思想：软硬件解耦

本节摘要：IEC 61131-3标准的核心贡献是把控制逻辑从特定厂商的硬件与编程软件中解耦出来：统一的五种语言、统一的变量模型、统一的程序组织单元。本节从标准诞生前的行业乱象讲起，划清"标准保证"与"厂商自由发挥"的边界，这是青线在合同里写进"程序资产可迁移"条款的知识底气。

本章支柱页留下的那场语言之争，先按下不表——争之前得先弄清楚争的对象。这一节往上追一层：为什么全世界的PLC程序能渐渐说同一种话，这个公约是谁在什么时候立的，它到底保证了什么。

1993年之前：一个程序换台机器就得重写

把时钟拨到标准发布前。那时每家PLC厂商有自己的编程语言：有的用助记符指令，有的用自家的图形语言，变量寻址方式、定时器的表达习惯、程序组织方式全都不同。工程师在A家平台练五年，换到B家平台几乎从零再来；业主买了A家的CPU，程序就被永久锁死在这家的硬件上——升级要整套推倒，议价没有筹码。行业的分工被这种锁定扭曲了：程序员的劳动力价值无法跨厂商流通，用户的程序资产无法跨项目复用。

1993年，国际电工委员会发布IEC 61131-3，给这件事立了规矩：定义五种编程语言——梯形图LD、功能块图FBD、结构化文本ST、顺序功能图SFC，加上后来被标记为"不建议新设计使用"的指令表IL；定义统一的数据类型与变量声明方式；定义程序组织单元，即程序、功能块、函数三类代码容器。从这以后，一个受过标准训练的工程师，换平台只学"方言差异"，不用重学语言本身；业主的程序，理论上可以从甲家的运行时搬到乙家的运行时。

注意"理论上"三个字，这是本节最重要的转折点：标准统一了语法，没有统一生态。

图 2-1：软硬件解耦——标准立在哪里，哪里就松动

标准保证了什么，没保证什么

把期望管理好，是使用标准的第一步。标准保证的是"形"：五种语言的语法与语义、数据类型的定义、变量声明与作用域规则、程序组织单元的模型。你写的一段ST条件判断，在任何合规平台上的行为都一致。

标准不保证的是"实"：库函数的丰富度、诊断能力的深度、执行性能、开发工具的手感。同样是标准ST写的PID，甲家用自家认证过的PID指令可能又快又稳，乙家只能靠你手写，第4章讲PID时会看到这个差别落在实处的样子。厂商自由发挥区里各家做出的差异，构成了真实的"方言成本"——青线从标准ST迁到某平台的ST，代码本身几乎不用改，但所有的定时器、计数器、通信指令调用都要换成该平台的库。

由此得到一条实用判断法：评估迁移成本时，把代码按"纯标准逻辑"与"库调用"分开统计。青线的程序里纯标准逻辑约占七成，这些是资产；库调用约占三成，这些是迁移工作量。合同谈判时，这组数字直接决定了"可迁移"承诺的成色。

一段代码的两种身份

看同一行ST代码在两个世界的身份差别：

// 纯标准逻辑：到哪家平台都长这样
IF Level_SP - Level_PV > Band_High THEN
    Pump_Cmd := TRUE;
END_IF;

// 库调用：方言区，迁平台时要逐个翻译
"IEC_Timer_0_DB".TON(IN := Valve_Cmd, PT := T#2S);
​

第一段的变量比较与赋值是标准的筋骨，跨平台近乎免费；第二段那个接通延时定时器是各家的实现，语法与行为细节各有习惯。青线的编码规范据此规定：逻辑尽量用纯标准写法表达，库调用集中封装在功能块里——将来真要迁移，翻译工作被压缩到几十个功能块内部，而不是散落在全线几千行代码里。这种"把方言关进笼子"的写法，2.4节讲程序组织时还会再碰到。

青线条款的由来

回到现实收益。青线签合同时，业主的设备部把一条写进了技术协议：乙方交付全部程序源码、变量表与设计文档，格式为标准格式加厂商工程文件，业主有权在未来自行或委托第三方维护改造。放在1993年之前，这条无异于天方夜谭；放在今天，它是标准化送给业主的议价权。我们作为乙方痛快地签了——因为编码规范里的"方言关笼"条款让履约成本可控，标准化保护的不只是买家。

把镜头拉远一点：软硬件解耦的思想，后来在IT行业以各种面目反复重演——虚拟机、容器、数据库抽象层，无不是把程序从具体执行环境中拔出来。PLC行业在1993年就交出了自己的答卷，理解这份答卷，你看后面四种语言时眼睛里就不只是语法，还有分层。

一个没写进合同的代价

青线之前，我们在另一家老厂见过标准的反面教材。那厂 2010 年上一条果汁线，程序由设备供应商用其私有图形语言编写，合同只写"交钥匙"，没提源码交付。七年后产能改造要加两路灌装阀，供应商报价里的程序修改费比新增硬件贵三倍——理由是"涉及核心框架，需整体重新适配"。厂里不是没人会改，是没源码：没有源码，连第三方评估都做不了，议价无从谈起。那两路阀最终按供应商的价付了，业主把这份合同复印件留在了设备科，后来成了青线合同条款的启蒙教材。

这个案例与 2.1 节的判断法互相印证：没有标准格式源码，"可迁移成色"为零，业主在后续二十年里每次改造都要重新谈一次总价。标准化给了用户筹码，但筹码要自己写进合同、自己保管源码才算数。技术解耦只是可能性，商务条款才是执行——两者缺一，都等于没解耦。

三个高频疑问

问：既然各家的库还是不同，标准化是不是名不副实？ 不是。看比例：青线程序七成是纯标准逻辑，这部分技能、代码、文档全部可迁移；三成库调用封装在几十个功能块里，翻译工作量可控。标准没有消灭方言，但把方言压缩到了可管理的比例——从"全部重写"到"翻译三成"，就是名副其实。

问：遵循标准的平台之间，程序真能直接拷过去吗？ 不能直接拷，但能低成本搬。变量声明、数据类型、逻辑结构基本原样保留；库调用与硬件相关配置要逐个映射。青线做过一次实际演练：把一号线的一个功能块库搬到另一平台的仿真环境，主体逻辑零改动，库映射花了两天——对比 1993 年之前的"整套重写"，是数量级的差别。

问：选平台时该怎么评估它的标准化成色？ 三个检查点：一是语言实现是否完整覆盖标准四种语言；二是是否提供标准格式（如文本格式）的源码导出，能不能进版本库；三是关键算法库（PID、运动控制）有没有认证文档。三个检查点过了，这个平台的程序资产就是你带得走的。

标准之外：这份公约的边界案例

把解耦思想用到极致会遇到什么？青线演练迁移时遇到过一个真实障碍：一个自定义运动控制功能块内部引用了平台特有的轴工艺对象——纯逻辑部分标准兼容，轴对象是厂商私有类型。处理方式值得记住：把轴对象隔离到功能块的一个"适配区"，接口保持标准数据类型，迁移时只需重写适配区十几行。这个模式后来有了名字——适配层隔离——它让"七成纯标准"的比例进一步提高到八成五。标准不能保证的地方，工程纪律可以再补一道。

反向的例子也有。某供应商交付的程序把大量逻辑直接压在平台私有指令上，交付物里连文本格式都没有——2.1节开头那个果汁厂的困境，本质是"解耦思想没有进入合同语言"。技术标准给了解耦的可能性，落地靠编码规范与合同条款双轮，缺一个轮子，公约就只是纸面文章。

本节要点回顾

• 历史坐标：1993年前的厂商孤岛把程序锁死在硬件上，标准用五种语言与统一模型解了锁；
• 保证边界：标准管语法语义与程序组织，库、诊断、性能仍是厂商方言区；
• 迁移成本公式：纯标准逻辑是资产，库调用是工作量，两者比例决定可迁移成色；
• 编码纪律：方言库调用集中封装进功能块，把未来翻译成本关进笼子。

下一个问题是：五种语言都合规，哪一段逻辑该交给哪支笔？下一节逐个过堂。