发表于 1648112935000
关于EAE的那些小事
IAC NC OEM SAE 庞晓东
施耐德电气（中国）有限公司于2020年11月正式在国内发布了EcoStruxure Automation Expert，也就是EcoStruxure开放自动化平台，简称EAE平台。这个平台基于面向工业互联网边缘计算的可执行系统级开放建模语言IEC61499建立，不同于以往的IEC61131-3标准，这个平台完全面向对象编程，用事件触发来传导数据，可以做到软件硬件完全解耦。想一想：拥有一套完全属于自己的核心控制程序，又不必被硬件牢牢绑定。如果这个硬件不适应发展了，直接把硬件换成全新的硬件来实现同样的控制目标（对应的硬件可以是PLC、windows10工控机、Linux工控机甚至可以是跑Linux系统的树莓派）。这会是多么激动人心的一件事。以前设备厂家聊的最多的是你用的是哪家的控制系统，将来设备厂家聊的更多的会是你的核心控制程序现在在什么上面跑。本文会介绍一些EAE平台的细节来说明IEC61499的与众不同。
EAE使用的IEC61499是全新的编程标准，使用事件来驱动程序。事件又和数据相关联，当有事件发生，关联的数据就会传递，功能块里面的对应判断就会执行。执行的结果会产出对应的事件和数据。
那么问题来了，事件来自哪里呢？事件来自于三个地方：
- 具体的输入模块的通道数值改变会产生事件
- 通讯输入变量的数值改变也会产生事件
- 控制器启动也会产生事件
也就是说事件是来自于数据最初更新到控制系统的地方或者控制器状态改变，这是整个控制系统搭建的最前方，也可以说成是控制事件和数据的源头。
那么事件最后去了哪里？最后事件也有三个状态：
- 事件最后到了输出模块上，通过事件更新输出数值
- 事件最后到了通讯输出变量的数据更新模块上
- 在某个模块进入后没有继续往后传递，中断在这个模块上
事件的流向规划就是控制的流程规划，数据也会在这个流向中随事件不断往后传递，更新。
这也就要求编程人员要对整个控制工艺非常了解，把具体的控制对象完全抽象成控制模型，才能够做控制流程规划。以前用IEC61131-3写程序是从下往上搭，IEC61499则是从上往下细化，先搭大框架，再做程序丰满细化。IEC61499的控制模型不只是逻辑模型，还包括了控制系统里面的全部模型。举个例子：将一个控制对象抽象出来的模型应该至少包含但不限于以下4点：
- IO数据模型
- 通讯数据模型（ModbusTCP、OPCUA）
- 控制逻辑模型
- 与其他对象的接口模型
这就是前面提到的面向对象编程，对象控制系统里面的全部都要包括在这个模型中。只有这样才能真正做到最大化的复用模型，大量节约其他项目的开发事件。同时也为软硬件解耦提供了前提。
前面提到过数据必须由事件来传递，也就是说没有事件就没有数据，没有数据对应的控制也就不会执行。这一点和IEC61131-3完全不同，IEC61131-3里面只要变量A数据变化，通过程序不断的循环扫描机制就会更新A的数值，程序里面每一个用到变量A的程序语句都会执行。这个机制很像数据的广播，听到广播并且和自己相关的自己处理。而EAE里面数据A变化了以后，只有和数据A关联事件的程序块才能通过事件变化得到A的数值，如果事件没有传递到程序中其他用到变量A的地方，那么其他的功能块是得不到A的新数值的。
举个例子：一个物料搬运的现场，平面图如下：
当一盘货被叉车放到11114设备上，按照黄色箭头的方向需要输送到11116设备上。在EAE的程序中，11114上面的这盘货触发了光电管导致DI模块上的一个通道产生了一个事件，同时这个通道的数值从False更新为True。按照控制模型要求，11114的对应接口事件只和控制流程相关联的设备控制模型接口，也就是说这时候相邻而且符合路径的11113会得到这个事件和DI的数值变化。同一时间11116、11117、11118三个控制模型都无法获得11114的事件和数据变化。简单来说：当货物从11114往11113输送时，其他的设备的程序因为没有事件都保持静默，程序并不运行。而当货物到达11113要往11112输送时，11112的程序会被事件唤醒，11114已经完成输送会返回静默状态。
但是在IEC61131-3的程序中，11114的光电管有信号，通过全局变量更新和程序扫描，其他设备只要调用了这个变量的程序都会得到这个数据变化。即使没有调用这个变量的程序也会被扫描执行一遍。也就是说无谓的消耗了PLC的资源。
下面介绍下软硬件解耦，当控制模型高度提炼后，控制中需要一个光电管的输入信号，那么程序中就定义一个bool类型的变量来参与模型的搭建，至于这个变量从哪里来，我们并不关心。这个变量可以来自真实的离散量输入模块的某一个通道，也可以来自ModbusTCP通讯读取的一个字里面的某一位，甚至可以是上位控制系统通过OPCUA下发的一个变量。当整个控制模型搭建完成，我们选择将程序部署到真实的PLC中，那么这个时候我们只需要把变量和真实PLC的通道做一个关联就可以了，如下图：
EAE的部署很灵活，可以是一个dPAC580PLC，也可以是3个dPAC251PLC。甚至可以用自己的电脑运行softdpac直接来跑EAE的程序。多个控制器间的通讯全部由EAE自动完成，编程人员不用再像以前用IEC61131-3编程时那样提前规划通讯区，编写或者配置控制器间的通讯。按照同时使用3个dPAC251为例，EAE里面要做的就是选择一部分程序部署到PLC1，再选一部分部署到PLC2，剩下的全部部署到PLC3，完成。
PLC1、PLC2、PLC3可以是PLC、windows10工控机、Linux工控机、跑Linux系统的树莓派里面的任意组合，并没有平台必须统一的限制。这也就真正实现了软硬件的解耦，编程人员可以忘记硬件，全力研究控制模型。最后EAE程序部署在哪些硬件上，都可以。如果因为货期原因交货可能延迟，换硬件就可以。
本文以一个工程师的角度来介绍EAE平台和IEC61499，希望能够抛砖引玉，如有错误请帮忙指出并改正。