PLC编程语言和编程平台的现状和趋势

2019年PLCopen国际组织和美国的automation.com网站联合进行了PLC用户编程偏好的调查。总数为200个响应者绝大部分来自北美和欧洲。调查的结果反映了PLC编程的趋势，以及用户对PLC编程软件供应商的一些想法和意见。这些对我国的自动化领域的发展，特别是以PLC为主要手段开发工业控制系统的工程师们也有一定的参考价值。



一、用户喜欢用哪些编程语言？



图1是用户喜欢用哪些编程语言的调查结果。用得最多的是结构化文本语言，其次是梯形图，再次是功能块图，第四是顺序功能图，其它编程语言位居最后，在其它编程语言中用的最多的是C/C++语言。
从用户这些语言的偏好看，可以得出以下结论：

（1）各种编程语言运用的差距并不大，没有特别多的，即使居第一的结构化文本也不过比居于第五的其它语言多得有限。
（2）明显可见，用户对于面向对象的语言如结构化文本语言和C/C++语言更为青睐。这反映了在智能制造和工业互联网的应用中面向对象的编程语言更能满足用户编程的需求。
（3）许多PLC的编程环境支持用C/C++语言编写功能块。

图1  用户采用PLC编程语言的调查结果


为什么这次调查没有列出指令表（IL）语言呢？
这是因为在2012年更新的IEC 61131-3 V.3编程语言国际标准规范中，虽然还保留了IL语言，但已经有提议将将它从5种编程语言中剔除。随着时间的推移，使用这种类似汇编语言的IL对PLC编程的人越来越少，几乎失去了存在的价值。
这里顺便指出，结构化文本语言ST在国内的普及程度很差。有一个原因是某些在国内应用相当广泛的小型PLC不支持ST编程，影响了它的推广使用。面向对象的编程OOP正在随着智能制造和工业互联网的需求快速地发展，而IEC 61131-3规范的5种编程语言中ST是最容易实现OOP的。因此，这一倾向值得重视。如果我们国家继续沿着按某些自动化公司的PLC产品机型进行工科教育，那么在PLC的开发和应用方向上将永远步少数几个工业发达国家的后尘，很难有翻身的机会。




二、编程的熟练程度



从调查的结果看，熟练掌握梯形图语言和结构化文本语言的比例较高，熟练掌握功能图语言次之，熟练掌握顺序功能图语言的比例较低。而不了解顺序功能图语言的比例最高。
看起来结构化程度很高、而且最适宜表达顺序工艺，工艺与编程对应得最好（也即程序的可读性最好）的顺序功能图语言，在欧美普及程度不算高。这也令人有所不解。
源于法国的这种PLC编程语言获得了一些专业组织青睐，譬如美国OMAC推的PackML就重点选择了SFC作为包装行业的编程语言，符合顺序控制工艺的机械加工和批处理加工的比比皆是，为什么SFC的使用者不多呢？一种可能性是被调查的样本还不够多，或者说被调查的细分行业还不够全。   

图2 掌握编程语言的熟练程度





三、对PLC编程软件平台的要求



调查从软件的可靠性、软件的易用性、不同供应商软件平台所编制的应用软件的移植性、I/O配置软件和不同供应商的PLC控制器之间的通信等5个方面征询意见。
结果不出所料，认为软件可靠性好和很好的占大多数，认为软件的易用性中等和好的占大多数，认为应用程序移植性差、较差和中等的占大多数，认为I/O配置软件中等和好的占大多数，认为不同供应商PLC控制器间的通信差和中等的占大多数。
这些调查结果实事求是地反映了当前PLC编程软件和平台的现状，表明不同软件和平台开发出来的应用软件的移植性远远达不到最终用户的要求，这也是单纯基于IEC 61131-3的开发软件和平台难以基本解决的问题，更遑论彻底解决的问题。
看来要解决这一问题需要另辟蹊径，譬如说美国开放流程自动化系列标准OPAS正在开发以IEC 61499为依托的应用程序的移植性，已经取得了实验室的验证，进一步需要进行工业实践的验证。
     

图3 用户对软件平台的评价





四、流程控制采用PLC呈现增长趋势



这次调查有一个出乎所料的结果就是，PLC在流程控制领域中的应用呈现增长趋势，超过73%的被调查者反映他们采用PLC进行流程控制，而采用DCS在流程控制中的只占27%左右（见图4）。当然，规模巨大的流程控制（如I/O点接近10万点或超过10万点，非DCS系统莫属，在这方面PLC系统还有很长的路要走。
PLC在流程控制中的应用超过DCS，估计原因有几个方面：
一是PLC的性价比远超DCS，在PLC能满足流程控制的系统要求的时候，选择PLC的投入要显著的少，维护成本也随之下降。二是PLC的性能有较大的提升，在一定的成程度上可以替代DCS的功能。三是调查样本有可能不够全，参与调查的以流程控制为主的企业不够多。   

图4  PLC在流程控制中的应用超过DCS





五、调查中许多用户的想法和留言


编程软件和编程平台的用户在调查中通过额外的留言反映了他们的想法和意见，他们希望PLC的供应商在其编程软件方面能更好地满足用户的需要。下面按有关的题目分门别类的阐述。

应用软件的移植性问题

有用户认为，采用PLCopen的XML规范来解决多个软件供应商的移植性问题，看来不太可能真正付诸实现，或者总是难以适当地正常地运行。 最好是供应商现在能够为编程环境提供开放的脚本语言的接口，在这样的环境下代码转换和自动操作比较容易进行。
关于编程平台的相互交叉兼容性的问题，有用户认为应该引起重视。但另一种意见则认为，一般的PLC供应商和开发商都难以与他们的竞争对手合作，试想将一根以太网网线从罗克韦尔的ControlLogix PLC上接到西门子的S7-400的以太网口，想象得到如果能够真能通信起来，这岂不是滑天下之大稽吗。显然用户对移植性的问题是不抱太大的希望的。不过，希望已经开发的代码能够实现更多的交叉移植性，一直是用户希望解决的事情，但至少到目前为止，这还是没有很好的解决方案。

OPC UA


有用户认为，完全接受OPC UA的支持这种可能性实属异想天开，真正实现的可以说是凤毛麟角。也有用户提出，应该能够定义自己的信息模型和采用其它的标准信息模型（如PackML和其它）。
有一个用户提出很好的建议，PLCopen的IEC 61131-3的OPC UA信息模型应该完全发挥结构化文本语言ST面向对象编程（OOP）的性能。这样用OPC UA通信应该实现起来就简单了，只要一个接口便可以在OPC UA网络中点开一个实例，接着按程序中的一个对象（功能块FB）那样进行处理。这样最终得到一个面向通信的架构和面向对象的编程。不过我们仍然需要状态机进行方法的调用。为什么不这样做呢？

可靠性

有用户认为，现在有些PLC编程平台的集成开发环境IDE往往并不完善，或者有时会出现操作系统蓝屏。显然，可靠性问题出现在现代的集成开发环境内，每个供应商都太忙于将他们的编程环境集成到一个工具中，同时还实现新的喜好性能，而花在提高可靠性方面的投入不够。希望编程平台的开发商要认识到，可靠性和可用性问题常常造成最终用户昂贵的时间损失。



编程特性

关于编程平台的改善，调查中用户提出了改进的意见。如在用ST键入能时自动完成标签命名的全部；能给出有意义的出错信息；文档能易于存取和能搜索；软件开发者应该对客户负责，给予技术支持；在梯形图编程的框架下允许嵌入复杂的编程；能够实现由顺序功能图语言自动自动生成代码；能在编程平台系统中开放像C/Java的编程语言；文本文件的编译采用C语言类型的编程工具的方法，具有版本管理、归档、管理、实用程序库，以及转换为另一种编译程序/另一种版本/另一种语言的能力。还有用户提出，采用现代的编程方法和技术，软件供应商应该有更好的源代码控制（Git）、单元测试等的知识和集成能力。所谓Git是一种在软件开发期间跟踪源代码变化的分布式版本控制系统，专门用来协调编程人员之间的工作，但也可以用来跟踪任意组合的文件的变化。



PLCopen和OPC UA的协同


工业4.0和数字化转型推动着先进的物联网IoT方法，这就是语义信息模型。工业自动化工业已经在支持建立开放的语义模型，这就是为什么PLCopen和OPC基金会建立联合工作组来满足这一需求。其结果包括IEC 61131-3的OPC UA信息模型标准，以及PLCopen和OPC UA合作开发的IEC 61131-3的OPC UA客户端功能块规范和OPC UA服务端功能块规范。现在还只有很少的编程平台能够提供按规范开发的OPC UA的功能块。


六、后记


自从在国内活跃多年的德国KW公司被菲尼克斯收购后，因发展目标调整的关系，从2019年中开始不再发展基于IEC 61131-3的编程平台的客户。于是在国际和国内IEC 61131-3编程平台市场中3S的CodeSys一枝独秀，随之涨价之风盛吹。
国内经过多年的发展，虽然没有真正具有市场竞争力的有关软件产品出现，但毕竟一些DCS和PLC的公司（如浙江中控、、和利时、杭州优稳）都拥有自用的编程平台环境。杭州电子科技大学计算机学院的严义、邬惠峰团队的CASE平台历经十多年的锤炼和提升，在IEC 61131-3的编程平台上增加了PLCopen运动控制规范的功能。与此同时，近年在北京和上海都出现了专门以开发IEC 61131-3的编程平台为目标的公司，规模尽管不大，但由于创业着凭着许多年在这个领域内摸爬滚打的积累的技术，发展的还是有声有色。我们期待在此工业软件方向上会出现商品化产业化的突破。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！