e-works的在线学院邀请再把2022年的《PLC早已不是那个PLC》的课程升级和大家在线分享。在线和回放已经有2000人次且有20多个问题。我最喜欢的是听众提问，不管是在线还是线下，因为听众的提问往往会超过我们日常思考的视角，这会让你思考，并重新组织内容，因此，会让人进步。因此，通常我特别喜欢观众的问题，甚至愿意因为每个问题回复。因此和e-works的小伙伴们商量是否写篇文章来把这些问题进行概要性的分享…行动起来。对这些问题进行了“聚类”—AI就是模拟人脑这样进行分类的，然后可以列为PLC的几个常见问题。
PLC是做逻辑控制的？
即使到了2024年的今天，PLC是做逻辑控制似乎对于很多人而言，仍是一种根深蒂固的认识—以至于在立志改变世界的人眼里，PLC只能做逻辑控制不能做高级算法，谈及工业总线就是RS485、CAN、Modbus等古董级技术需要被改变…他们甚至认为这意味着巨大的机会。几年前我经常听到做工业互联网的，来自IT的专家们总是强调这些，我就问他们何以如此执念这些说辞—他们说也认真学习了大学关于PLC的教材。一声叹息，嗯，难怪，我说你们看的教材大部分都还停留在20年前。
其实，PLC执行计算任务采用高级语言编程，这样的控制器在30多年前就已经有了。就拿贝加莱的PLC来说，早在80年代就运行OS9基于优先级的一个操作系统，采用MC68000的 处理器，可以运行BASIC解释器编写算法。到了90年代，就已经采用了pSOS+的定性分时多任务操作系统（该技术所在公司被WindRiver收购并融入VxWorks）。后硬件从MC68K转到Intel X86，其实这两个CPU都有对应的协处理器可以处理浮点运算。
图1-贝加莱黑色系列与蓝色系列PLC
还有就是另一个现在似乎已经销声匿迹的公司叫SoftPLC，我记得2003年，和当年的老搭档Eric为昆山正新橡胶开发过一个超过100多台硫化机的集群管理项目。当时Eric就用Java编程—当时的CPU印象中是一个Pentium II 266MHz的处理器，这个CPU可以运行JVM（Java Virtual Machine-Java虚拟主机），想想也是20多年前的工业互联网项目了。印象中这个公司的介绍还挺拗口—SoftPLC是SoftPLC公司在SoftPLC平台上开发的名为SoftPLC的SoftPLC…。
所以，PLC局限于逻辑任务，从历史来看，在30年前就已经被改变了。
PLC的新概念-他们意味着什么？
世界总是这么有趣的两极分化，一方面，很多人还认为PLC仅能做逻辑控制，而另一方面，另一批人则开始为新的PLC概念而技术热情高涨。比如SoftPLC、云PLC、AI PLC、虚拟PLC，甚至在线时候有人问有没有GPT PLC，这不是正在说明PLC与时俱进的在改变吗？
PLC新概念都在试图告别传统PLC，并一致将矛头对准了原有PLC的各种弊端—比如不能用开放的语言编程，不能进行计算任务。充满着要与PLC割裂的决心，但又很矛盾，因为他们还叫PLC，只是加了个前缀。
SoftPLC区别于传统硬PLC的直接硬件资源操作，它出现在CPU、RAM既快又便宜了—配上高精度时钟，加载实时操作系统以及为系统配置高速高精度时钟。一种是采用Windows+RT扩展，或直接采用像VxWorks这样的RTOS，这个架构其实在机器人系统里也比较普遍。在新的CNC架构里，也是如此，将传统的CNC专用型硬件拆解为通用PC+RTOS，如RT-Linux或Windows+RT扩展的方式，代替传统专用的CNC系统。
云PLC将PLC部署在云端、虚拟PLC借助于今天高性能处理器的多核及软件部署，可以把Runtime运行在多个核上-这两者其实都是考虑了在性价比上的问题。因为云资源的确成本低，而把多个Runtime部署在一个多核处理器，本身也是一个好办法—但是，这里主要考虑还是可靠与稳定性问题。关于这个问题，之前e-works黄博士交流过虚拟PLC这一趋势，我与彭瑜老师请教，他觉得技术上当然是可行的，也具有经济性，但这又意味着把所有鸡蛋放在一个篮子，而设计分布式系统时，就考虑过降低系统风险而采用了分布式。因此，在计算任务上，这样的处理可以被理解，但当出现强实时性时，这种架构就会变得有风险。
图2-虚拟PLC
AI PLC其实也是同样道理，增强PLC的AI能力，这个也可以实现—既然PLC都已经并不局限于嵌入式本身，而可以将SoftPLC运行在PC的Windows+实时扩展或RT-Linux上，那在这个架构上增强AI能力-因为AI就其实现而言，就是软件，也并不是不可以—例如，把AI加速器部署在PCIe的插槽上，可以用Linux任务对其进行处理—而实时任务与非实时任务结合，这个在底层硬件上可以通过CPU多核间的虚拟以太网来实时完成通信，调度机制则由操作系统来实现。
周期性任务与事件驱动型任务，在这里完全可以被耦合—这个通过开发工具平台的配置即可完成。这也是工业软件里的一个重要环节，包括像Portal、Automation Studio、TwinCAT、Logix等。
这些PLC的新概念，主要还是聚焦了数据类任务的处理需求上，但是，这些与实时任务完全可以通过现有的架构硬件扩展或通信接口连接的软方式来实现。对于传统PLC厂商而言，这些都已经在研发或实际应用中。这里需要提醒，传统PLC厂商从来没有停下来发展的脚步—只不过，似乎声音没有IT厂商那么大，因为，解决问题是第一要务。
IEC61499会取代61131吗？
尽管我对IEC61499不那么了解，但在2018年，交大的戴老师作为这项IEC标准的制定专家之一，曾经滔滔不绝的给我描述过IEC61499的好处，作为边缘计算的一个实现方案，IEC61499的确在这个层级的业务编排方面有很大的优势。
图3-IEC61499软件架构图
IEC61499并非设计为取代IEC61131，IEC61499它是一种面向事件驱动型任务的系统建模语言，侧重于定义每个结构组件中的语义。IEC61131更多在集中式控制的周期性任务编程语言方面。因此，这种“取代”在逻辑意义上无从谈起—可以理解为IEC61131组成的机器，再构成一个产线这一层的时候，标准语言是缺乏的-因此，才产生了IEC61499这样的需求。任何技术都是得看需求来源，IEC61499更多来自于集成后，对全局性的协作任务处理的需求。而IEC61131就是针对由PLC作为集中控制中心，把单机内部进行了全局的控制协作，而机器之上的产线级，又需要另一种编程语言来实现。
两者更多是互补的关系，IEC61499的协作用于调度任务的编排，然后有了协作的“结果”输出，这些可以发送给下面的机器执行，因此，IEC61499和IEC61131之间也可以通过OPC UA来交互任务，这样可以实现计算任务和控制任务的融合—他们不是取代关系，而是更好的协作关系。
当然了，还有一个就是，即便IEC61131-3还是IEC61499也都不是唯一性的选择。并非做编程不是IEC61131就是IEC61499。比如即使在IEC61131比较多的用的时候，还是有工程师更愿意用C/C++编程。这也很正常，你不用IEC61499，你也可以用Java、Python…这种技术的标准，它是一个生态的问题，如果生态里大家都用这个规范，那对应的这方面的人才就比较多，支持的厂商也比较多，就会比较经济。当然了，工业标准都来自于工业领域的企业根据自身的特殊场景而设计的—对于适配性就会更好。但，这也不意味着对用户而言，就是唯一的选择。
PLC与DCS有哪些主要区别？
这其实，不大容易被混淆的-实际上，PLC是一个嵌入式系统，即，开发主机和运行对象并不是在一个平台，而DCS的开发和运行其实是可以在一个系统的（如开发在Linux，运行在Linux）。嵌入式系统它自己就有操作系统，自己有BIOS处理，自己的任务调度和处理机制。而DCS一般运行在Windows/Unix/Linux上，DCS更多的是指软件层面的包括开发的工程服务器、数据服务器、操作员站、现场控制器—仪表采集、DCS的闭环处理、到现场的调节阀、执行机构的执行。
DCS主要处理的是连续型任务的流程工业，它的Know-How包括工艺闭环控制，都在主机上，而且，在多回路间的相互关系也在主机上进行解耦…。DCS一样需要针对具体的应用场景做工艺的迭代，使得其能够响应环境变化，确保控制的精度、响应。
但是PLC实际也可以在流程工业被应用，因为流程工业里并不完全是流程，包括现场执行器也有很多离散的执行。前道流程后道离散这种场景也是很多的。
如何看待开源PLC？
有朋友问如何看待开源PLC的现状和前景？是否可预见的未来以闭源为主？
开源的PLC，主要指的是借助于开源社区资源来构建PLC的技术架构，这里包括几个层面：
（1）.开源硬件，比如Ardino、树莓派这类开源硬件；是否可用，当然对于IIoT非实时控制我想目前没有问题，至于是否可以被应用于控制器，那就满足控制器在稳定可靠方面的设计需求，认证通过即可。
（2）.开源RTOS，像RT-Linux，但这个会需要根据实际需求来裁剪；
（3）.开源的开发平台，像Eclipse，可以作为一个开源的工程平台来集成各种应用；
（4）.开源的应用类软件，如ROS、openCV视觉方面的库，这方面继承开源思想的主体IT企业可能在HMI设计、机器视觉方面会有开源的资源可用，但在垂直行业的应用方面，仍然需要自己来封装。
开源还是闭源，这里有个关键问题是“责任问题”，如果开源给你用，那代码的提供者就不需要承担因此造成的安全、稳定性方面的风险了。而自动化企业，可以借助于开源技术，但当你开发成为商业的产品进行销售时，在法律意义上，你就需要承担因此带来的后果，例如造成宕机、故障所需的服务，总不能说我用了开源技术，所以，我不承担这个后果，那你就别当做产品销售。
第二个大的问题是“商业保密”，如果工业Know-How都开源，那企业自身的商业价值是什么？因此，开源PLC，只是说它采用了开源技术，但不代表它的技术也是开源的。
PLC与5G的结合
5G与PLC的融合，如果在PLC集成5G模块，显然会增加PLC的成本，因此，在IEEE的方案就是采用TSN作为前传网络。目前，在欧洲由3GPP和IEC等组织在进行着5G与TSN网络的融合方案，5G将作为TSN的虚拟桥进行设备的连接。
图4-5G与TSN网络的时钟同步计算架构
图4为5G/TSN的时钟同步方案架构，对于通信而言，5G需要解决包括带宽、丢包率、抖动、时钟同步及精度等一系列问题。因此，由ACIA组织来自移动通信、自动化领域、用户端的厂商共同推进5G的传输方案。移动网络的优势和缺点其实是一样的明显，因此，这必须结合工业场景，在控制系统中集成5G，还有就是成本的经济性也是需要跨越的。
把5G集成到PLC上，还是说用一个盒子（交换机），将TSN有线和5G发射的集成在一起作为一个“桥”，可能更多的人还是愿意选择一个盒子，毕竟很多个PLC作为终端节点汇集到TSN/5G交换机，这样就一个车间一个5G节点，否则，每个PLC带一个5G通信口，这个成本还是有点高。
PLC与AI集成
显然，这是可以的，对于PLC来说，AI与PLC的集成。训练和推理是两件事情，训练的话仍然是需要较大的算力的，但是，部署这个算法则并不需要较大的算力。
之前，个人认为AI需要大算力，在工业里缺乏经济性，但是，记得几年前在家附近园区里散步，晚上总看到一个在做测试的移动台子，很感兴趣就和那个工程师聊，他说在做安防系统的夜间视觉测试，我心里想那些摄像头才200块钱怎么就这么智能呢？他告诉我这个训练是要大数据训练，但形成的判断模型则不需要较大的算力，普通摄像头就可以了。这个事情让我茅塞顿开…训练与推理自然是可以被分离的，当然，这需要离线升级算法包。
那么，对于PLC与AI结合的算力考虑就可以放在本地推理上的算力需求上。而在实际的自动化系统里，目前来说，就是视觉的数据量较大—那么AI的问题就简化为对视觉的处理。这个处理方案有两种，一种是基于PC的图像处理，那就把PC的算力用上进行信息处理。另一个就是直接在视觉上嵌入AI能力，硬件方式来处理数据，采用FPGA或专用的AI芯片—这里的问题就是视觉处理与自动化系统的集成问题。
在贝加莱的机器视觉中，即将推出的就是采用了26TOPS的AI处理器，内置深度学习模型，快速的处理信号，并可以将这个分析结果与自动化系统通过实时通信来实现同步。
PLC与边缘计算
边缘计算这个概念也慢慢的火起来了—我这里指的不是概念起来，而是现实应用的需求起来。
既然我们认为PLC已经可以做高级算法，又有大的数据处理能力—那作为一个嵌入式边缘节点也是可以的。还有就是如果PC+PLC被集成在一起，那作为一个边缘节点也可以。如果一个PC服务器作为边缘计算节点，那它也需要与现场任务进行交互，采集数据并下发指令。
因此，AI PLC、云PLC、虚拟PLC都是为了能够将AI的计算任务与控制的实时任务结合。由于AI、云PLC设计思想都是在边缘侧，通常边缘计算主要处理全局性的协作类、优化、调度、策略性任务—因此，以PLC、SoftPLC、云PLC、虚拟PLC作为一个边缘计算的实现方案，这也并非不可以。
PLC最新技术趋势有哪些？
PLC本身来自于需求的演变和横向技术的融合—这也是系统创新的两个抓手。要了解技术的趋势，其实，关注市场的需求、横向科技的发展则更为关键。
从需求侧来说，未来控制器更为强调开放性，这个在过去的数十年均是如此—它主要源于整个制造的集成度更高的发展需求。因此，必须打破纵向边界，让PLC融入到数字化的系统中，但是，PLC是一个非常关键的数据节点，它作为机器控制的中心，但也是一个数字化系统架构的数据节点。
1.通信增强数字化融合能力
PLC本身的通信能力集成，使得分布式架构更为通畅，OPC UA FX扮演了这个重要的角色，无论PLC的控制部分被部署在嵌入式对象上，还是PC、云端、虚拟架构下，那么，它对于通信的能力就会增强。OPC UA FX就解决同声翻译的问题，FX包括TSN/5G/WIFI-6它解决的是“同声”，而OPC UA则解决语义互操作中的“同语言”的问题。
图5-OPC UA FX保障数据的高速传输
因为云PLC、虚拟PLC、AI PLC各种新的概念下的实现，它依然依赖于连接从底层传感器到云端的链路，这个时候无论是采用有线的TSN，还是无线的WIFI6/7，或5G，都是需要通信提供这个连接支持的。而另一方面，为了在软件层面，实现数字化设计、运行、分析与决策系统的端到端连接，语义交互的规范接口也是必须的—因此，OPC UA FX正是为了这个场景而设计的。
2.AI加持让机器更聪明
AI的意义在于它会让机器“更聪明”—这与基于规则和安全值的控制不同，传统的机器它设计了简单的控制规则，包括过去大规模生产下，对于工艺参数本身都是通过“试凑”的方式来进行。但当个性化需求越来越普遍，频繁的更换作业时，就会遇到参数如何降低开机浪费的问题，那么通过物理建模构建整个控制策略，但对于模型的精度而言，需要数据来收敛，这个就可以基于历史数据来分析并做出收敛，来获得参数的最优组合。这个机器会不断去训练，它会越来越聪明。
3.编程语言的演进：PLC作为一种设备，它的开发必须响应快速的变化。因此，它本身作为一个设备，对它的应用开发工具而言，就得是越简单越好，至于低代码，还是生成式编程，都是可以作为选项去成熟。
在未来，可以想象，你并不需要采用IEC61131，你可以采用更为灵活的编程语言，甚至自然语言的编程，也并非不可能—因此。
这些需求结合横向技术，为PLC赋予了更多的可能性—至于它是否还叫PLC，也并不重要。
价值的竞争才是自动化的关键
归根结底，自动化的价值并不在PLC本身，而是加载在PLC上的工程集成能力、工艺Know-How的封装，以及由此带来的机器和产线的品质、效率与快速交付能力。
因此，讨论PLC本身孰优孰劣本身的意义并不大，纵观整个自动化业界的竞争力，在多年以来都已经不在产品本身，而在于整体工程能力。
产品之外的价值更为重要，对于自动化厂商而言，竞争力来自几个方面：
1).平台的能力：不管谁家的PLC，其实都是需要由平台来对对象进行集成，并根据机器的开发流程来进行全流程的服务集成。这就需要平台具有高的开放性，PLC向云、AI的发展，是更多将开放世界的资源能够被高效与控制的集成。
今天，我们讨论工业软件，这个聚焦都被放在了CAD/CAE，其实，集成开发平台像Automation Studio、Portal、Logix、TwinCAT等，同样是非常关键的工业软件。只是这个容易被忽视—但是，它关乎集成的难易度、深度（算法设计）、广度（开放资源的集成度）等多个维度的考量。并且，作为一种持续的创新平台工具，它会将历史积累的知识以APP形式封装，被调用—这是PLC真正的价值。工业软件的本质就是知识的复用—而这才是核心的核心。
2).工程能力
PLC厂商单纯依靠销售产品已经不能再成为有竞争力的。而是通过工程集成将机电对象组织为一个高效的机器，这种结合传动、逻辑、工艺算法、AI的算法集成。包括从建模仿真、代码开发、测试验证、远程诊断与维护等，整个完整的工程服务能力，才是自动化厂商的核心竞争力。
3).工程师的竞争
而在这些软件、工程能力的背后，则是人才的竞争。无论前端的销售，还是研发的工程师、应用开发、现场调试、维护—工程师在这里的角色，已经不是过去PLC仅做逻辑年代那么简单。控制系统的复杂性来自于机器和制造本身的复杂性。工程师的认知、规划与设计、动手能力、协作、沟通能力，成为了项目实施的基础保障。
因此，PLC早已不是那个PLC，自动化行业也早不是大家理解中的自动化行业—它是一个关乎整个产业高效发展的重要一环。
原文始发于微信公众号（说东道西）：PLC早已不是那个PLC
