IEC61499的理解及相关应用

随着工业物联网的兴起， 从事相关产品开发的人员应该可以从实际业务中发现， 基于工业开发的一些特性。

基于历史背景， 各大工厂内的设备环境复杂多样， 具体体现在各个设备包含不同的通信协议， 比如常规的ModbusRTU, 或者西门子的S7Comm， 或者基于Omron的Tcp Fins等， 各协议间通讯协议不一， 导致各个设备间互相间独立运行， 难以通讯， 各数据点间格式不一， 不好统一规划， 成了一个个信息上的孤岛。

如何解决上述问题就成了各行业头疼的问题， 基于当前的形式， 在软件侧， 有通过emqx或者rabbitMq提供数据并发过程解耦的， 平台侧有各大框架去做集成， 比如物联网框架thingsboard, 或者java的spring全家桶， 优劣各异， 但是在贴近现场一侧的边缘侧却是八仙过海， 有开发自由硬件走云化PLC路线的， 也有提供边缘环境走定制化开发路线的， 还有针对主流设备开发独立硬件提供通用接口的， 虽然各有各的玩法， 但谁也很难说利用自己的技术占据了绝对的主导地位， 这也就导致了市面上的需求五花八门， 基于这些需求的多变， 也造成了技术上很难有稳定的沉淀， 这也成了一个行业通用标准出台的必要性的由来。

IEC61131-3是一套为了简化编程方法、减轻用户重复学习负担而生的针对PLC规范编程的一套通用标准， 在传统工业中， 为了适应需求的多样性， 基于PLC去构建基于输入-输出的程序， 已经能够实现相关的设备控制的需求， 但是针对当前数字化工业的需求， 单单实现设备控制已经完全无法满足新增的设备联动， 数据集成等需求， 因此在61131的基础上， 衍生了IEC61499标准。

IEC61499针对整个系统进行了重新分层定义， 系统——设备——资源——应用——功能块， 基于这种面向对象的思维，对于用户对于复杂而又神秘的工业领域的理解是有着质的提升的， 而其分布式的特点， 也让用户在开发的时候能够从之前针对性的定制化开发中解脱出来， 将自己的实线能够从原来针对协议和过程的层面提升到设备间交互和系统构建的层面， 这本身也是软件层面比较优势的地方， 而经过这些年软件的发展也充分证明了对于软件的理解更适合大众的思维， 这也可以说， 通过IEC61499标准， 也无形中优化了开发人员的学习成本。

针对IEC61499的标准详情可以参照IEC61499文档以及姚家湾的博客， 个人对于这个标准的理解很大程度上也是来自于以上资料。

4diac为基于IEC61499标准提供的一套分布式工业过程测量和控制系统提供开源基础架构，这套架构成型期迄今为止已经有15年之久， 4diac更多。

通过市面上能够查询到的资料， 可以发现尽管已经有公司针对IEC61499有了相关的产品， 但目前在国内， 鲜有公布的该标准的相关技术资料， 而针对4diac的也是少之又少， 这从侧面体现了当前工业的生态环境目前还没有能够达到行业级的地步， 当然这也是一个机会， 谁先抢占了领先地位， 谁也就能占据主导地位。

4diac主要分为两部分， 一部分为IDE（程序编辑器）， 一部分为Forte(程序的运行环境)， 通过IDE对需要的逻辑进行编辑， 组成如下图的功能块， 然后可以对这些逻辑功能进行功能分发， 下发相关逻辑到运行着Forte的各设备中， 就可以实现应用的分布式部署。

其中IDE和Forte官方都进行了开源， 前者为JAVA构建， 后者为C++构建， 官方提供了一部分通用的FB（功能块）， 但实际业务中是远远满足不了需求的， 所以如果要构建新的功能块或者设备模型和资源， 则需要针对IDE和Forte进行同步开发（虽然官方提供了动态解析的方案， 但基于实际运行环境通常性能优先， 故处于效率考虑， 不建议采用低效率的解析型方案， 这也是基于公司既有业务中得到的经验之一）。

 上图为官方提供的demo， 构建过程可以参照官方文档， 大致如下。

1. 构建好项目， 大体结构如下

 2. 如上图般构建好相关应用程序

3. 如下图般构建好设备模型通讯和资源分配

 4. 将应用程序中的各部分映射到设备模型中，具体方式为在应用程序中右键功能块， 即可map到各个设备的各个资源

5. 针对各设备映射后的部分进行通讯逻辑构建

 从上图中可以看到一部分功能块的特性， 需要首先加载初始化， 然后才构建相关的逻辑传递， 其中传递包含时间传递和数据传递， 整体传递的特性可以理解为数据先行， 通过事件控制数据的流转和功能块中逻辑的执行。

另外各功能块都是基于发布和订阅的方式去构建设备间的通讯， 途中示例为基于udp的通讯方式， 实际业务中可为其他如mqtt等方式去构建业务通讯。

6. 构建好相关逻辑和映射， 以及映射后的设备间通讯方式后， 可开启各设备的Forte， 进行部署环境准备， 目前官方提供的支持Forte运行的环境有

        1. 乐高Mindstorms EV3

        2. RaspberryPi树莓派

        3. WagoPFC

        4. freeRTOS

        5. Windows

        6. Unix

        7. docker

基于以上环境， 基本可以满足各环境的通用部署（只要能够部署forte的设备都可以运行相关程序， 只是根据硬件性能差异， 会有执行效率上的差别）。

基于本地的Forte管理， 可通过Debug - Open Simulated Devices Manager

 7. 进行程序分发， 右键点击应用程序， 选择Deploy即可（需确保能够与各设备的网络通讯且设备上运行了Forte）

 可从Deployment Console中查看分发的异常信息

 8. 分发完成后， 即可从APP上进行数据观测， 从应用程序功能块上右键点击， 选择watch即可

至此即完成了IEC61499的样例搭建。

 通过对4diac的样例构建， 可发现官方提供的控件比较少， 无法完全适配当前工业开发环境需求的复杂性， 实际开发过程中， 需要大量开发所需要的控件， 而这除了需要对IEC61499标准的理解需要透彻外， 还需要对IDE和Forte的源码要有比较深刻的理解， 以方便功能集成。

同时， 从官方的样例中， 我们可以看到实际的应用构建基础是到了非常细分的地步， 这可能和这套标准原来是源自于61131的缘故， 主要是针对于PLC标准的升级指定的， 但实际上业务功能的需求中的逻辑复杂性需要通过大量的基础逻辑去构建， 故为了整体业务逻辑的把控， 可以在基于此架构构建时， 需要针对部分通用逻辑处理做适当的高度抽象和集成， 避免因为架构模型的解析和构建而损耗本身就有限的边缘侧资源， 而如何抽象和集成自用的功能块， 这除了需要对标准和技术的把控到位外， 对于自身需求的理解以及需求边界的把控和隔离也至关重要。

客观上来讲， 这套标准问世十五年之久， 却依然寥落如斯， 背后的原因， 除了工业目前还处在市场开拓占主导的原因之外， 针对于工业的相关的需求整理也是一个很重要的关键点。

一个较为理想的愿景就是， 带着这套标准， 针对N个设备， 搭建好这样一套运行环境， 通过opcua去构建好设备模型， 然后加载好针对于各个设备通讯的协议资源， 然后分发到各个设备上， 即可实现设备间相互通讯以及设备数据集成处理分析。