目录
从PLC 历史谈起
PLC （可编程逻辑控制器）是美国汽车行业Bedford 协会的一位聪明的雇员Richard E. Morley在1968年发明的。起初的名称为模块化数字控制器（Modular Digital Controller MODICON），在GE 公司的一个咨询项目中，采用Programmable Logic Controller （PLC）的名称，Bedford协会也更名为Modicon PLC。成为世界上第一个PLC 供应商。第一台商业应用PLC 产品MODICON084。
Morley先生为了使当时的技术人员和维修电工易于理解和编程PLC。采用了类似继电器接线图的，也就是梯形图来为PLC编程。这种方式一直延续到现在微处理器时代。自动控制工程师接受的培训和工作经验都是基于梯形图编程方式。
目前PLC 已经成为使用最为广泛的制动控制设备。在生产线控制，机床设备，动车，地铁中，PLC产品几乎无处不在。
PLC 可编程逻辑控制器一直是中国自动控制厂商心中的梗。PLC领域长期以来都是欧，美，日企业把控的地盘。 在上个世纪80年代我曾经有机会在英国的Allen-Bradley公司学习PLC技术，回国后也曾极力地宣传PLC 的重要性，但是并没有被多少人认可，不久，无锡轻工系统的一家国企曾引进GE公司的PLC 产品（大散件组装，实际上就是整机引进），而Allen-Bradley 公司在厦门设立了独资公司。逐步在中国推广PLC产品和技术。后来西门子，日本三菱等公司也相继进入中国市场。之后的几十年间，也有一些公司尝试开发国产的PLC 产品，不过终究没有成为气候。目前少数国内PLC 公司。他们的产品主要是面向“自主可控”的重点领域。在普通工业市场没有竞争力。
从硬件上来看，PLC 并不是十分复杂的工业电脑。也没有多少专用电路。开发上并没有多少不可逾越的地方。问题主要出在软件上。编程环境，可靠的嵌入式程序还是有难度的，成为了PLC 产品的护城河之一。
事实上，在国外PLC 产品的软件也大多数并不是硬件厂商开发，而是第三方软件公司开发的。比较集中的是Taylor Software,和 ICOM。其它软件公司不是被硬件设备公司收购了，就是倒闭了。后来Taylor Software,被Total Control Products收购，之后这家公司又被GE Fanuc收购，而施耐德公司购买了Taylor 的一部分软件。
现在许多的PLC 厂商是购买的CoDeSys 公司的编程工具和嵌入式运行时程序（runtime）。 目前很多厂商的PLC控制器使用的都是Codesys系统，比如汇川技术的中型PLC，德国倍福的控制器，日本欧姆龙以及法国施耐德等等主流厂家也都有基于codesys平台二次开发的控制器产品。
PLC标准化-IEC 61131-3
各家PLC厂商的编程环境和语言是相互不兼容的。也就是为西门子PLC 编写的程序无法再三菱PLC上运行。为了解决这一困境。国际电工委员会IEC 于1982 年，发布了IEC 61131-3 标准。致力于PLC 标准化工作。IEC 61131-3标准很重要，因为它为所有符合该标准的软件产品带来了一致性。无论集成开发环境（IDE）的品牌或用户界面桌面的名称如何，功能和功能块看起来都一样，并具有相同的定义的输入和输出，从而使工程师或维护人员能够从任何制造商的软件中快速了解逻辑和程序流程。
该标准定义了五种编程语言：
- 梯形图LD
- 功能块（FBD）
- 顺序功能图（SFC）
- 结构化文本（ST）
- 指令表 IL 类似于计算机的汇编指令
IEC 61131-3定义了标准数据类型，命名约定，程序流程和各种其他编程元素。当PLC OEM声明其编程软件符合IEC 61131-3时，通常意味着该软件符合部分标准。IEC声明，要符合要求，编程包必须至少支持五种语言中的一种。CoDeSys可能是唯一支持所有这五个平台的编程平台。
PLCOpen协会
人们意识到仅有一个标准是不够的，还有许多的事情要做。于是成立了PLCOpen 协会。来推广，论证和进一步规范IEC 61131-3标准。
PLCopen是一个独立的全球组织，可根据用户需求提供工业自动化效率。它成立于1992年，总部位于荷兰，在美国，日本，中国和韩国设有支持办事处。
前面提到，在IEC 61131-3中，除了传统的梯形图和指令表以外，提出了功能块图编程（FBD）方式。这是一种基于图型的编程方式。
FBD 类似于硬件的电路图，一个PLC 程序是由若干个功能块用线连接起来的。功能块都有一个或多个输入和输出。块的功能是其输入和输出状态之间的关系。下面是一个FBD的例子，是不是很像硬件的原理图？
类似于原理图，基本的功能块相当于小规模集成电路。基础的功能块包括了
除了这些在 IEC 61131-3 标准中规范的核心功能块以外，在PLC 中还有大量的功能块。例如
- 算术功能块
- 移位功能块
- 字符串功能块
- 转换功能块
- 通讯功能块
还可以有许多许多，事实上用户可以编写自己的功能块，它们可以使用梯形图，结构化语言或者其它程序设计语言来实现。复杂功能块提升了PLC 的能力，例如电机控制，PID和运动控制类的功能模块。未来也许会有AI 功能块。但是功能块就像程序库那样。如何能保证不同厂商开发的功能块相互兼容，是一个需要相互规范和协调的事情。PLCOpen 在功能块设计等方面，提出了更进一步的规范。例如软件构造指南，运动控制用户指南和安全用户指南等。
按照IEC 61131-3 标准编写的PLC程序要最终在PLC中运行，需要通过翻译成硬件可执行的机器指令，或者一种中间代码在PLC 运行程序中解释执行。对于机器代码和中间代码的规范并没有在IEC 61131-3 中明确规范，具体的做法有两种：
1 将PLC 程序翻译成为C或者C++ 语言，使用C语言编译器编译成为机器代码
2 输出中间代码，由PLC运行时解释执行（就像JAVA的JVM那样）。
各个厂商的中间代码是格式不开放。这对软件仿真，调试，版本控制等带来的不便。于是PLCOpen 成立了一个名为TC6 for XML（可扩展标记语言）的工作组。形成了IEC 61131-3的XML格式。
不同厂商的IDE 软件可以输出XML 文档。然后将XML文档进一步转换成为特定PLC的输出代码。
综上所述，PLCOpen 协会致力于IEC 61131-3 的进一步规范。不过，它并没有开源任何PLC 开发环境和PLC 运行时。它只是一些规范而已。
网络上有一个OpenPLC 项目，名字经常会和PLCOpen 混淆。其实OpenPLC 是一个开源项目，将树莓派改造称为PLC ，不够它相对简陋，还是停留再业余爱好者水平。
IEC 61499标准
IEC 61131-3只是一个设备上的程序的标准。但是现代控制系统走向分散数字控制系统时。IEC 61131-3显得不够了。
于是，IEC 与2008年首先发布了面向分布式控制系统的标准IEC61499.
IEC 61499定义了一种特定领域的建模语言，用于开发分布式工业控制解决方案。IEC 61499通过改进软件组件的封装来扩展IEC 61131-3，以提高可重用性，提供与供应商无关的格式，并简化对控制器到控制器通信的支持。它的分发功能和对动态重新配置的固有支持为Industry 4.0和工业IoT应用程序提供了必需的基础结构。
基于IEC 61499的控制技术可用于对整个工厂和设备进行编程，即使在分布式控制系统中具有多个控制器也是如此。
IEC 61499与IEC 61131-3，的不同
IEC 61499
- 事件驱动程序执行
- 完整系统的编程
- 实时启用
- 使用其他IEC 61499工程工具创建的程序无需导入/导出即可进行处理
- 控制逻辑可以分配给多个控制器。定义了控制器之间的通讯
- 任何符合IEC 61499的工程工具均可使用不同供应商的库
IEC 61131
- 循环程序执行
- 单个控制器的编程
- 实时启用
IEC 61499 功能块
IEC61499 标准使用基于功能块图形编程方法，功能块（FB）是其重要的概念。
和IEC 61131-3 中的功能块类似，61499 的功能块有数据输入和数据输出(底部)。与61131 不同的是 61499 的功能块具有事件输入和输出端（顶部）。这是反映了两种标准不同的控制方式。
在PLC 中，是采取循环程序控制方式，或者称为扫描（Scanning）控制方式。在一个循环周期（通常为1ms）中，PLC 读取所以的输入端，将输入端子的状态存放在存放在内存，然后执行梯形图一次，修改内部和输出状态。
在IEC 61499 控制器中，外部输入产生一个事件信号，每个功能块只有输入事件发生变化时，内部功能才运行一次。同时输出新的事件和输出新的数据。由此可以看出，61499 控制器采取的一种异步控制方式。系统中的事件和数据也许在一个控制器内部传递，也可能通过网络在系统的多个设备之间传递。61499 系统的通信机制更适合采纳发布订阅模式（publish/subscribe）。
IEC 61499定义了在开发应用程序时可以使用的三种类型的FB：
- 基本功能块（BFB）
- 基本功能块（BFB）
- 服务功能块（SFB）
IEC 61499的编程方式
在一个分布式系统中，我们通常的方式是定义每个控制器的功能以及控制器之间的通信协议，数据格式，API，然后分别开发各个控制器内部程序和服务器程序。而在IEC 61499 中则不同，它是从系统的角度开发一个有各种功能块组成的程序。然后将程序中的各个功能块映射到每一个物理控制中。这个过程称为Mapping。
IEC 61499 使设计者从系统的角度开发应用程序。设计者不再关心设备之间的接口和通信。这样做的好处是提高的程序开发的效率。不像传统方式开发分布式控制系统那么碎片化。
IEC61499的开发者
和PLC 控制程序类似，IEC61499 开发工具同样由少数的第三方公司开发，其中比较著名的是奥地利的nxtControl公司，它是符合IEC 61499分布式系统控制技术领域的全球领导者。公司成立于2007年，过去十年来，公司已在这项技术上投入近1500万欧元。2017年nxtControl 公司被施耐德公司收购
利用nxtControl的建筑和工业自动化软件，可使用拖放功能在多个控制器之间轻松实现整个工厂的控制智能化。交互通信的实现是完全自动的。基础标准IEC 61499的事件驱动执行模型更易于将控制逻辑集成到更高层次的IT系统和云应用中，创建一个从现场层到管理层的无缝数据高速通道。
IEC61499 开源项目Eclipse 4 diac
值得幸喜的是，与IEC 61131-3 不同，IEC61499 标准的开发工具出现了一个开源项目-Eclipse 4 diac。
4diac 是基于eclipse IDE 框架和Java 开发的ICE611499.它包括四个部分 ：
- IDE 开发环境-使用Java编写
- FORTE – 一个运行时，使用C++编写
- 功能块库
- 系统实例
对IEC 61499 开发的看法
- 相对古老的PLC而言，IEC 61499控制系统还比较年轻，传统的制动控制厂商还没有完全成熟的产品。如果现在加快研发投入，有机会弯道超车。
- 出现了Eclipse 4 diac 这样的开源项目，能够大大帮助我们进入IEC61499 控制系统的开发领域。当然在开源项目上完善和优化还有许多的工作要做。毕竟，开源项目为我们指明了方向，让我们知道从哪里开始。
- 硬件模块化，标准化很重要。IEC61499 的功能块实现了硬件和软件的分离，硬件的虚拟化，参数化，但是所以的功能块最终还是要mapping 到控制器的硬件上去运行。硬件不规范和模块化，很难去开发针对所有接口的功能块。之前，我们尝试开发基于图形化的开发工具，经验告诉我们，开发一些AND ，OR，Counter 等基础功能块比较容易，但是一旦开发复杂一点的功能块，就必须和硬件模块开发同步进行。每开发一个硬件模块，就同步地开发一个或者几个功能块。
- 要从某个具体的行业开始。和上面第3点类似，如果漫无目标地开发同样的功能块。你会发现工作量非常大，而且到具体的应用时总发现还缺一个。所以一开始针对某个特定领域比较合适，nxtControl好像也是从建筑自动化开始的。做好一个行业，再做一个行业。让你的功能块满足特定行业的所有应用场景。
- 如果我们现在什么也不做，PLC的今天，就是IEC61499 控制系统的明天，我们永远进入不了自动控制的高端领域。什么工业4.0，工业物联网，中国制造2025 都将是浮云。
- 梯形图，组态软件的概念在控制工程师心中已经根深蒂固。其它方式他们难以接受。IT工程师和自动控制工程师就像鸡和鸭对话，尿不到一个壶里。IT 工程师只有妥协，才有机会。
如果有人点赞，我将继续这个话题。国内网络中，这个课题的文章并不多。