贵州省西门子电源模块中国（西门子）授权总代理

IEC61499并非设计为取代IEC61131，IEC61499它是一种面向事件驱动型任务的系统建模语言，侧重于定义每个结构组件中的语义。IEC61131更多在集中式控制的周期性任务编程语言方面。这种“取代”在逻辑意义上无从谈起—可以理解为IEC61131组成的机器，再构成一个产线这一层的时候，标准语言是缺乏的-才产生了IEC61499这样的需求。任何技术都是得看需求来源，IEC61499更多来自于集成后，对全局性的协作任务处理的需求。而IEC61131就是针对由PLC作为集中控制中心，把单机内部进行了全局的控制协作，而机器之上的产线级，又需要另一种编程语言来实现。

两者更多是互补的关系，IEC61499的协作用于调度任务的编排，有了协作的“结果”输出，这些可以发送给下面的机器执行，IEC61499和IEC61131之间也可以通过OPCUA来交互任务，这样可以实现计算任务和控制任务的融合—他们不是取代关系，而是更好的协作关系。

当然了，还有一个就是，即便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的虚拟桥进行设备的连接。