预告
因为今年AI大火，我赶时髦写了几篇有关人工智能的文章，也算是自己对制造业使用AI的思考。不过毕竟自己的老本行还是工业软件，所以还是应该回归本位，写写自己熟悉的东西。
今天工业软件之于制造业的版图，基本上还是建立在工业3.0时代的ISA-95的架构上的（参看前文论金字塔的倒塌）。
ISA-95架构下的工业软件
笔者在前文论金字塔的倒塌中已经论述过，这些工业软件存在的目的是为制造业的业务服务的，业务常有，软件不常有。即使是在数字化和AI时代，制造业的业务依然没有改变，而这些工业软件也会被数字化和AI赋能后继续为业务服务。
ISA-95 工业软件系列文章
系统地介绍一下制造业工业软件的前世今生，他们存在的目的，价值和发展趋势，可以帮助自己把二十多年的职业经历整理一下，或许也可以帮助大家对制造业的工业软件有一个基本的了解。
ISA-95 工业软件前世今生系列
什么是PLC
想象一下，你是生产电梯的厂家，电梯不仅仅有动力系统，还有一些控制功能：比如要控制电梯按照特定的层数启停；开门的时候，要控制外门和电梯梯厢的内门同时开闭。好的电梯，还对上下行的控制有优化：如果电梯正向上行，有人按了向下的按键，电梯会一直向上把上行任务完成，然后才下行。
这些控制后面都有逻辑，所以我们把它叫逻辑控制。所谓自动化，就是用一个计算机来实现这些逻辑控制，不再需要人来执行。这个计算机安装在电梯用户看不见的控制柜里面，有CPU来执行逻辑运算，还连接IO模块来接收和发出信号控制电梯启停和开门。
这个计算机既有逻辑又有控制，我们把它叫做逻辑控制器。
如果你生产的电梯安装在一个五星级酒店里面，电梯的基本控制逻辑可能还不够。五星级酒店的电梯，为了保护客人隐私，要求客人刷卡才能乘坐，而且只允许客人停靠住宿的楼层和公共楼层。为了满足五星级酒店的业务需要，我们必须改变电梯的控制逻辑。
为了方便电梯在不同的场景下扩展和改变逻辑控制功能，我们可以编写程序来灵活满足不同业务的需要。电梯里面的计算机太小，也没有鼠标键盘，编程不方便，我们就在台式电脑上把程序编好，然后部署到电梯里面的逻辑控制器，让它可以根据我们编写的程序来完成特定控制业务。
这样，我们就有了一个可编程逻辑控制器，英文原文叫Programmable Logic Controller，简称PLC。
PLC工作原理
比如按钮、限位等信号被采样到PLC中进行逻辑运算处理给出一个结果，如果程序逻辑是按下按钮指示灯会亮，那么按下按钮，经过输入采样，再经过程序执行，最后输出刷新之后，指示灯就会亮。
循环周期执行是PLC最基本的工作原理，按照类似原理工作的软件还有电脑游戏。
PLC的特点
PLC在自动控制领域是属于不可或缺的存在，只要是有关自动化控制的，小到车库的抬杆，可乐自动售货机，大到一条轧钢产线，汽车生产线，核电站，都离不开PLC。
许多人有一个疑问，PLC不就是一个可以写程序的小计算机吗？现在随便一台PC机就可以完成编程计算，手机的算力也比PLC要高得多，为什么一定要用PLC。
回答这个问题之前，我们需要先了解两个世界：IT（Information Technology 信息技术）和OT（Operational Technology，运营技术）。这两个世界最大的区别，是IT主要在虚拟世界，而OT主要在物理世界（参看前文纵论IT/OT 融合之道）。
今天大多数计算机，是为虚拟世界设计的。今天我们熟悉的PC个人电脑，或者是手机，无论是上网聊天，刷视频，写文档，都是在数字世界，不能够完成泡一包方便面填饱肚子的工作。即使是面对工业的IT系统，也多是和服务器，数据库打交道，依然是在软件的数字世界里面天下无贼。
而PLC面对的却是物理世界，是电梯，自动售货机，机场行李传送带，食品厂的饮料灌瓶产线，炼钢厂的转炉，还有核电站的反应堆。
因为PLC控制的是物理世界中的实体，所以我们对PLC的功能和性能的有特殊要求，主要表现在以下方面：
稳定性
我们都经历过计算机出错，比如手机用了一段时间卡顿了，文档写了一半台式电脑崩溃了，这些虽然很烦心，但是大多数情况下，我们骂两句，把系统重新启动一下，要不了几分钟就恢复正常了。
而在物理世界，发生这些错误可不是骂两句，重启系统这么简单的。PLC出错的后果，从自动售货机不出矿泉水，电梯卡在23层和24层之间不动，机场行李传送带趴窝，到整条汽车生产流水线停产，滚烫的钢水在转炉里面出不来，核电站关停，都是损失巨大甚至不堪设想的。
所以，稳定压到一切这句话对PLC是非常适合的，PLC必须保证几个月甚至几年稳定运行不出错。
为了满足稳定性，PLC在硬件设计和软件实现上都有和一般计算机不同之处。
从硬件说起，最简单的区别，PLC的工作范围一般要满足-20~60℃，而一般PC只需要0~40℃，别小看了这几十度的区别，所有的元器件选型要求都会完全不一样。
再说散热，一般PC可以用风扇散热。而PLC工作的环境会是灰尘很多的工业现场，风扇很可能会在一段时间后因为满是灰尘而拒绝工作，无法散热了。所以，PLC必须设计成被动散热，还能够保证外部温度60℃的时候，PLC依然正常运行，挑战不小。
在工业环境中，电机、变频器都会产生强电磁干扰，所以PLC硬件设计需要满足三级以上EMC防护。正常计算机在普通办公室或者机房，二级EMC防护就绰绰有余。如果把一台普通PC搬到车间现场，工业干扰会让其马上死机。
当然，我们可以使用工业级PC来满足这些硬件的严苛要求，但是工业级PC的硬件成本会比专业PLC要高出好几倍，并没有什么优势。
再看看软件。老的Windows死机重启是家常便饭，而且我会每隔几个月重新安装系统。现在Windows稳定多了，不过运行七天系统依然会提醒我重新启动一下。手机也是，App用着用着就没反应了；或者是手机越用越卡顿，重启都没有用。
而PLC要连续运行几个月甚至几年功能不出错，性能不降低。PLC 的Runtime的核心技术，可以保证PLC在各种错误情况不崩溃，卡顿都不行，因为卡顿会影响程序运行的实时性。
PLC的研发工程师，不仅仅需要精通嵌入式软件开发，还要深度掌握对操作系统的实时性，内存管理，进程调用，硬件中断等底层技术，以保证PLC的软件稳定运行。
其实，工控行业急需有工业产品经验的硬件和软件开发人才。然而，现在招生，十个毕业生有九个是用python玩AI应用的，也是可惜。
实时性
实时，英文叫realtime，这个词，其实有歧义。我许多大学同学都在通信行业，他们也讲实时。但是通信行业的realtime，和自动控制的realtime，不是一个概念。
通信行业的“实时“，其实是“实况“。他们的业务场景，无论是电视转播，直播带货还是联机游戏，延迟越低就越实时。而在工控行业，“实时“其实是“准时“。举个例子，在一个饮料食品厂的自动灌瓶机产线上，光栅传感器监测到空瓶子到达预定位置，并把这个信号传给PLC，PLC计算出这个瓶子300ms以后到达灌瓶口，所以让传送带停止的控制信号必须在300ms以后准时发出，以保证阀门正对瓶口。晚了10ms发出不行，瓶子已经跑到后面去了，但是早10ms其实也是不行的，因为瓶子还没到。
通信行业，互联网行业的实时技术，是为了降低延迟，而工控行业的实时技术，主要是为了降低抖动，也叫“确定性（Determintstic）”
这个确定性的需求，贯穿PLC系统的整个控制链：从传感器的输入信号，到PLC的控制程序，再到输出信号控制伺服驱动器，最后控制电机驱动传送带按时启停，哪一个环节掉链子了，控制就会出错，瓶子就对不准灌瓶口。
一般电脑的操作系统是满足不了确定性需求的。即使是算力足，也只能保证算得快，却不能保证不抖动。比如Windows，就是安装在几十核的大型服务器上，它的平均抖动都在10ms以上。这是由操作系统内核设计决定的，和算力无关。
即使是使用实时操作系统，PLC的Runtime还要保证控制程序按照精准时间执行，不受外部网络通信量的大小和各种中断的影响。你在PC机上写的1+1=2的程序，跑在Windows上和跑在PLC上，是完全两个概念。
所以，当有人告诉我大力出奇迹可以解决PLC的实时性问题的时候，我只能无语。
更加有挑战的，是现场总线的确定性。PLC实时发出的控制信号，需要通过现场总线传给几十米甚至几千米以外的远程站驱动现场设备。这些现场总线，必须也是确定性的。
现在工控界常用的现场总线不少，主流是基于工业实时以太网的PROFINET和EtherCAT等。而这些现场总线的技术推动，大多是德国的自动化厂家。
有人问，为什么我们不能够自己定义一个自主可控的现场总线协议。原因其实不在技术，而在生态。
截至2022年，全球已部署5870万个PROFINET设备，涉及控制器、I/O 模块、驱动器等全品类工业设备。支持的厂家数量推测超过1000家（含芯片、设备、系统集成商）。
EtherCAT的生态更大，到2025年，全球EtherCAT节点数量突破8800万个（含芯片级设备），实际支持EtherCAT的独立设备厂商超过2000家。
有国内通信大厂曾宣称进军工业现场总线，且不说他们的低延迟技术和工控的低抖动需求格格不入。即使确定性网络协议开发出来了，要全球几千家设备厂商用你的协议，这个生态，可不是开一个发布会就可以建立起来的。
当然PLC的特点还有不少，再讲就超过科普范围了。写到这里，希望大家对PLC有一些基本了解，也明白为什么这样一个小小的计算机，在今天DeepSeek可以吟诗作画的时代，在制造业依然是一个常青树的存在。
前世今生
PLC起源于1960年代末的美国汽车工业，旨在取代继电器逻辑系统。1969年建造的第一个PLC被命名为Modicon 084，因为它是Bedford公司的第84个项目。Modicon品牌转手两次后，现在属于法国施耐德电气。大约在同一时间，Modicon创建了现场总线的先驱Modbus，这是一种用于PLC的数据通信协议。到今天为止，许多电气设备依然使用Modbus通信。
第一款PLC Modicon （图片来源 施耐德电气）
在Modicon PLC和品牌形成后不久，Allen-Bradley（简称AB）这个熟悉的名字于1970年代初进入PLC世界。AB公司（现为罗克韦尔自动化旗下品牌）普及了PLC的名称和缩写，同时在制定IEC 61131-3 PLC编程语言标准方面发挥了领导作用。
到今天为止，Modicon和AB都可以算是PLC的一线品牌，PLC的玩家世界几乎和PLC本身一样保持稳定。
虽然美国是PLC的发源地，但是德国的自动化公司却后来居上，成为PLC的供应商大国。许多大家耳熟能详的PLC品牌都发源自德国：西门子，倍福，菲尼克斯，博世，路斯特，Wago，还有专业的小众品牌PILZ，SICK等。其中西门子占据全球PLC市场半壁江山，独领风骚几十年。
西门子做控制器可以追溯到1959年的S3，这是它的第一代逻辑控制器，只是不能编程。真正意义上的PLC是1979年推出的S5，打开了市场。宝钢最开始的产线用的就是S5，当时是高端设备的代名词。到了1994年，西门子推出S7系列，逐渐奠定了PLC全球市场的霸主地位。其中仅仅一款S7-300在2015年就占全球市场的25%，到今天已经停产的情况下还占全球市场的15%，几乎是PLC世界里Windows XP的存在。
2009年，西门子推出新一代PLC S7-1200/1500系列，同时推出TIA（Totally Integrated Automation，全集成自动化）博途组态软件平台，让自动化产品，无论是PLC，伺服，HMI，SCADA等在组态上都可以无缝衔接。TIA的底层逻辑和工程实践，到今天依然是整个自动化的标杆，影响了一代的国内的追赶者，如汇川技术最新的iFA，宝信软件的天行IDE。
国产PLC现在开始奋起直追。在PLC硬件设计上，国产PLC已经可以和国外一线PLC看齐了。但是在软件核心技术上，无论是PLC嵌入式的Runtime，还是IEC 61131-3语言的编译器，还有完整的组态软件，对国产PLC来说都是挑战。
在国产PLC业内，德国3S公司的CODESYS应该是如雷贯耳。许多大家熟悉的国产PLC品牌，其实还是处于华强北组装手机的时代：除了硬件是自己设计生产的，组态和Runtime都用的是CODESYS。
今天国产PLC的业界有着“北和南川”的说法，同时也代表着国产PLC的两个生态圈：学院派的代表北京和利时，前生是电子部六所的一个科研课题组。类似院校起家的公司还有浙大中控、科远、优稳等；华为派的代表深圳汇川技术，还有英威腾、麦格米特，禾望电气，鼎汉，他们都和华为电气渊源不浅。
和利时研发PLC时间最早，1996年就推出PLC，算是国产PLC的先驱。可惜和利时的PLC近十几年没啥进步，技术停滞不前，已经被其他厂家后来居上。笔者个人观点，和利时在PLC上起了个大早，赶了个晚集的原因，是由于过程控制DCS市场太过诱人，一个项目动辄几千万上亿，相对于要花大量技术人员投入而单价只卖几百上千元的PLC市场是非常诱人的。所以，学院系的公司如和利时，中控都是DCS的玩家，PLC并不是他们的主打产品，主流还是项目型的商业模式。
华为系汇川技术的商业模式以产品为主，每年百亿销售额就是一个个几百块的PLC，伺服驱动器和电机累积起来的，所以汇川的产品思维比和利时强。汇川的PLC，直接搭载CODESYS，无所谓自主可控，能有市场就好。今天的汇川在自动化市场已成气候，无论在国内还是在海外市场都在挤压龙头老大西门子的空间。现在的汇川已经有实力准备在PLC技术上走自己的路了。今年汇川发布了自己的组态软件iFA，对标西门子的TIA博途，算是在软件自主可控上前进了一步。但是汇川PLC核心的Runtime至今依然依赖CODESYS。
从技术上来说，国产PLC厂家真正可以自主可控的玩家依然寥寥无几。
最新进入PLC市场的宝信软件潜力巨大。宝信软件从ERP，MES开始做起，向下生根，持续研发SCADA和PLC。2024年9月宝信软件发布了天行PLC T3/T4全栈自主可控的大型PLC，从硬件设计，实时内核Runtime，到编译器和组态软件，全部自己研发完成。现在已经在钢铁行业大力推广应用，假以时日将会成为国产PLC阵营的生力军。
正在运行在的宝信天行T4 PLC
（宝钢冷轧厂C104机组）
未来可期
PLC发展到今天，技术进步已经是今非昔比了。作为自动化常青树的存在，PLC将会继续独领风骚几十年，不过功能和形式将会有许多变化，笔者尝试从以下四个方面总结如下：
控制
原来PLC只是做逻辑控制的，现在的PLC不仅仅可以做逻辑控制，还可以做运动控制，大型PLC甚至还可以执行过程控制。所以，IEC组织已经把PLC的内涵改了，原来叫可编程逻辑控制器（Programmable Logic Controller），现在去掉了逻辑两个字，叫可编程控制器（Programmable Controller），缩写不变，还是PLC。
控制是PLC的老本行，在工业自动化稳定性和实时性的两个刚需面前，PLC的控制一哥的地位在可见的未来是无可撼动的。不仅仅硬件设计和Runtime不会发生大的变化，就是编程语言，IEC 61131-3依然还会是主流。因为其他流行的编程语言C/C++，C#，Java或者Python，在设计语言的时候都没有考虑到如何支持物理世界的容错。
举两个简单的例子，IEC的梯形图有一个管脚叫ENO，可以在用户程序运行错误的情况下关闭下一个连接。而且PLC的编译器在程序碰到除零，数组访问越界等情况都会做特殊处理，不会让PLC 停机。这些工业现场的稳定需求，IEC 61131-3都考虑到了。
当然，你可以重新写一个C++的编译器来满足控制要求，类似于改装一辆跑车来做农业收割机，也不是不可以。
那么我们能不能抛开IEC 61131-3用人工智能控制呢？这是一个大话题，容我在后面一段详细分解。
数据
业内把PLC的数据通信分为东西南北向。这是按照ISA-95的层级，底层是被控设备，之上是PLC，再上面是SCADA，然后以PLC为中心，根据上北下南的通则来命名的。
PLC通信
在工业3.0时代，PLC主要的任务就是控制，发送信号给物理世界的各种设备，就是南向通信。大型自动化应用场景中PLC之间会互相通信，完成多PLC协同工作，这是东西向通信。北向数据主要提供给SCADA，进行画面监控和数据采集。
到了工业4.0时代，PLC的南向通信依然稳如泰山，东西向通信变化也不大，但是北向通信需求急速增加。智能制造需要的PLC数据，远远超过了原来用于生产的监控业务。无论是集控中心的数据展示，还是可预测性维护的数据趋势分析，还有已经渗透到控制层的人工智能AI，都恨不得把所有PLC数据全部应采尽采，应存尽存。
今天的PLC对自己的老本行控制业务的完成是得心应手的，可是对于日益增加的北向数据的需求，已经是不堪重负，成了智能制造时代现场数据的瓶颈。
未来的PLC将会在数据通信能力上有大的提升，不仅仅是数据通信量和性能的提升，而且将支持全域互通，统一建模，所有的数据用一种语言说话，让PLC和其他现场设备的数据交互无缝衔接。
宝信天行DSF（Digital Shop Floor，数字工业现场）为此而生，天行PLC会和DSF深度融合，成为原生支持智能制造的PLC。
部署
今天的PLC供应商，大都是硬件供应商。用户必须要买特定厂商的PLC硬件，碰到PLC供应商的供货问题，涨价问题，停产问题，都非常痛苦。
多年前笔者在德国听过奥迪CTO的演讲，奥迪当年就有一个梦想：希望可以把控制逻辑跑在标准硬件里面，哪一天PLC坏了，去买一个标准电脑换上就好了，控制程序和业务不用依赖特定厂家的硬件。
Soft PLC（软PLC）就是这个需求的答案。
软PLC和硬PLC的区别，在于PLC Runtime的部署。软PLC的Runtime可以部署在标准的电脑上，类似于一个普通程序，而硬PLC只能部署在特定的硬件上，和硬件深度绑定。
在国产PLC产品里几乎无处不在的CODESYS，就是软PLC的鼻祖。起初的CODESYS是跑在Windows上面的，比如倍福。后来一众硬件厂家都生产自己的硬件再用CODESYS适配，让软PLC又和硬件绑定了。
软PLC变硬，首先是技术原因，要满足PLC的实时性和稳定性，还是要在底层绑定特定硬件，许多我们在市场上看到国产PLC都是这个技术路线。另一原因，在国内现今的软件生态下，这是能够赚钱的商业模式。纯软件破译方便，懂的都懂。
但是因为CODESYS本身不涉及硬件，所以即使是适配了硬件的CODESYS PLC，其性能和可靠性依然无法和原生的硬PLC相比。我们可以把硬PLC比作苹果手机，系统和硬件深度绑定，用了五年依然流畅。把适配了硬件的CODESYS PLC比作安卓手机，各手机厂家用不依赖于硬件的安卓系统来适配自己的硬件，其性能和流畅度依然无法和原生硬件苹果手机匹敌。
随着工业4.0的到来，虚拟PLC和云化PLC应运而生。其实虚拟PLC和云化PLC都属于软PLC的范畴，都是不依赖硬件的PLC。只是虚拟PLC是部署在虚拟容器里面的，而云化PLC则是让这个虚拟容器跑在云上。
硬PLC，软PLC，虚拟PLC和云化PLC
虚拟PLC的吸引力，在于它的PLC Runtime不仅仅可以不依赖于硬件，而且因为部署在容器里，甚至可以不依赖于操作系统和运行环境。
笔者对边缘计算在工业现场的应用非常看好。由于边缘计算机直接部署在现场，相对于云计算，无论实时性，数据带宽和安全性都有优势（参看前文纵论IT/OT 融合之道）。
虚拟PLC部署在有足够算力的边缘机上，再借助现代容器编排技术，需要几个PLC就部署几个容器，而且统一维护，有着硬PLC无可替代的优点。
两年前，奥迪终于如愿以偿，EC4P项目投产（Edge Cloud 4 Production，云边生产）。在该项目中，奥迪采用虚拟PLC技术将控制逻辑迁移至中央服务器集群，成功地用虚拟PLC替代了传统硬件PLC。
该项目由思科、CODESYS、西门子及VMware共同支持。通过思科的网络基础设施连接中央服务器与车间的IO模块，虚拟环境使用VMware，虚拟PLC有两个品牌，西门子S7-1500V 和CODESYS Virtual Control SL。2023年7月，奥迪宣布EC4P测试成功，并已在Böllinger Höfe工厂部署，支持e-tron GT，Quattro等车型的生产。
笔者很好奇，这个工厂虚拟PLC和硬件PLC的使用比例是多少。我也想问奥迪的CTO，“若要保证虚拟PLC的稳定性和实时性，不知阁下又如何应对？”。相信老爷子会笑一笑，回答说，并不是所有业务都需要硬实时的。
根据 IoT Analytics 最新研究，虚拟PLC目前整体技术成熟度较低，尚未满足传统硬件PLC的全部技术要求。研究从四大核心技术维度评估虚拟PLC成熟度：控制任务支持、功能安全、控制逻辑可移植性及冗余能力。
虚拟PLC的成熟度
拿实时性来说吧，西门子的虚拟1500V，其Runtime内核与1500硬件PLC是一样的，但是因为虚拟机本身实时性不好，整体系统实时性就无法保证。这就好比一台精度非常高的机床，工作环境却是在行驶晃动的汽车里面一样。环境一直在晃，机床再精密，精度也受限。
但是虚拟PLC的前途不容小觑，一是在现场一些业务场景并不需要毫秒级的实时响应，比如厂房的温度湿度控制，虚拟PLC抖动几十毫秒都是在误差范围之内的。二是虚拟技术也在发展中，其稳定性和实时性必将被持续优化。
虚拟PLC不会完全替代硬件PLC，特别是中小型的设备市场。但是在许多大型制造业的工厂，用一台边缘机来灵活部署虚拟PLC，对不少业务场景是非常有吸引力的。钢铁行业里面，行车控制可能就是一个很好的例子。
云化PLC和虚拟PLC原理是一样的，只是PLC没有部署在边缘，而是部署在云。相对于边缘，云端的资源和算力更强，同时响应也更慢，实时性更弱。
云化PLC的应用场景，流程自动化会更多。流程自动化许多是化学连续反应，不需要毫秒级的响应周期。其被控对象如温度，压力等的变化是以秒甚至分钟记的。同时流程自动化控制对象的数量很多，需要更大的算力支持。所以云化PLC在流程自动化还是有很大发展空间的。这也是为什么DCS厂家对云化控制的热情比PLC厂家大的原因之一。
智能
在AI应用方兴未艾的今天，PLC和AI的关系如何？
笔者个人对AI用于自动化的主营业务，比如生产和控制是非常期待的，也相信AI将会如毛细血管渗透一样进入自动化业务（参看前文AIDA：AI定义自动化）。
让PLC直接跑AI，可能会受限于硬件资源。AI训练需要大量的算力，使用PLC训练AI肯定不现实。即使是使用训练过的模型推理，AI需要的算力也不小。所以，未来的AI定义自动化，应该是PLC，机器人，多模态具身智能和大模型的完美配合。
今天具身智能的领跑者是智能驾驶。智能驾驶实现从感知，理解，决策到执行的全链条自动化，可能会是未来AI定义自动化的范例。
在AI定义自动化里，感知可以是有智能识别能力的摄像头，也可以是各种传感器，理解和决策可以是基于AI的行业大模型，而PLC担负着执行者的任务，是控制物理世界的核心系统。
在人工智能时代，PLC的全域互通，和AI无缝衔接的能力，以及为AI训练和决策提供高速和高质量数据的能力将成为未来PLC的刚需。
结语
人类对事物的理解，和事物本身的进步，大都是螺旋式上升的。从看山是山，看水是水；到看山不是山，看水不是水；再回到看山是山，看水是水。但是你第二次看到的山水，不会再是原来的山水。
PLC也是一样，多年以后，PLC依然还叫PLC，但是那个PLC将不会还是原来的PLC。
