IEC61499 是针对分布式工业控制系统而设计的。一个工业标准要被广泛采纳是不容易的事情。况且在工业控制领域基于IEC61131-3 技术的PLC 技术已经非常成熟，而且被工业界广泛采纳。甚至于教育都有密切的关系。除非必需，自动控制领域接受一种新的编程方式和新技术的意愿非常淡薄。这也是推广IEC61499 标准的困难之处。
无独有偶，物联网（IoT） 面临着同样的尴尬。物联网技术主要是从互联网技术衍生而来的，这个领域的工程师希望将大量互联网技术用于物之间的连接。但是物联网至今为止缺乏标准。更确切地讲，是传统产业与新兴的物联网公司无法就标准达成共识。哪怕是彩电，空调的远程遥控都没有建立统一的标准。即便是苹果，华为，google 这些网络巨头也没有号召力。而某些企业干脆自己操家伙干起了家电产品。
在公共服务和工业领域同样是如此。各种iot平台无法避免定制化编写程序的环节，而且大言不惭地称自己为“低代码”。其实，低代码和‘多代码“没什么区别。会写少量代码的程序员并不感冒多写那么一点程序。而且为了写那么一点点代码同样需要读懂大量的API和程序库的使用。没有一点功力的程序员还真干不了这个瓷器活。哪怕是”低代码“。而OT行业更不买帐。大多数自动控制工程师的编程经历时在大学里做C语言课程的作业。在实际工作中基本没有使用计算机语言编写程序。他们需要的是无代码。
在物联网应用中，许多项目使用Node-RED。它是一个在NodeJS 引擎上实现的图形化，数据流编程方式。既能编写前端（HMI）界面，也能够控制硬件接口。当需要少量编程时，采用的编程语言是javascript 。使用了NodeRED 使原来只会写界面的IT 小白立马能开发软硬件融合的物联网应用。但是要让OT 工程师接受NodeRED，JavaScript 。恐怕你是要失望的。
另一方面，NodeRED是一种基于数据流的图形编程方式，它对节点没有进一步的建立标准化模型和规范。因此结点代码，程序库的标准化，可用性和可靠性受到一定的局限。
为了寻找为物联网应用编写少量代码的编程工具，我们关注了IEC61499标准。
IEC61499 率先在物联网应用中推广，具有下面几个优点：
- IEC61499 适合物联网应用程序的编排
- IEC61499 为分布式系统而生，与物联网非常契合
- IEC61499 基于事件的功能块，更加接近面向对象，面向服务的设计理念。
- IEC61499 能够满足大多数物联网系统对实时性的要求
大多数物联网应用系统的实时性没有工业控制应用那么高。对于的IEC61499 控制器相当容易实现。
近半年来，出现了一些好的现象，越来越多的人关心起IEC61499，去年年底，施耐德公司甚至推出了基于IEC61499 标准的商业化产品 EAE 2.0。国内也有一些公司和机构计划开发IEC61499 的相关产品。这将会推动IEC61499 标准的普及，研究和发展。但是，情况就是这么个情况，到底从哪一方面先入手，仍然是值得探索的问题。既然是商业化产品，就必然有其商业目标。
基于IEC61499 的物联网服务器
一个典型的物联网系统从传感器到云端完整的体现。简单的IoT架构由前端设备和后端设备构成。前端主要完成传感器数据采集和现场执行。云端包括了数据存储，分析，可视化控制（Dashboard）。近年来，人们又逐步提出了边缘服务器的概念。是将数据的存储，分析和可视化前移到网络的边缘，接近数据的地方。边缘服务器的软件架构和云端软件架构类似。只是规模比较小。
物联网系统架构
云端/边缘服务器架构
无论是GE 公司的predix，还是harting 公司的MICA 服务器，研华公司的边缘设备都采纳的基于容器/微服务架构。
Harting 公司的MICA 边缘控制器
- 普遍采用容器技术，目前Docker 是最流行的容器技术。
- 从过去单一软件解耦成为单一功能的微服务（microserver）
- 独立开发，快速迭代，敏捷开发
- 微服务之间通过消息系统交换数据,例如MQTT，或者Rabbit MQ 消息系统。
- 有一个IoT 中继服务（IoT Hub） 实现将各种物联网协议和消息转换成为内部的消息。传递给相应的微服务处理。
IEC61499 在云端/边缘服务器中的应用
物联网边缘服务器产品将会包含一系列基础微服务，使用户用户能够以极少的代码就能够开发出一个面向具体应用的项目。提供的微服务和API 越多，用户开发应用项目的效率就越高。与此同时，云端/边缘服务器厂商还努力地构建微服务的生态系统和App 市场。比如当年的GE Predix 就是类似的架构，后来推广的并不顺利，目前主要是GE 公司内部使用。
如果有了大量的微服务，那么在这样的平台上开发具体的应用项目会更加容易了。但是，毕竟“大炮不能上刺刀”。最终的应用程序仍然需要一种编排的方式。目前大致有下面几种方式：
- 使用高级语言如C++，java，NodeJS，GO或Python 编写少量代码，形成App 微服务。由于有大量额API和微服务可调用。所以用户编写的代码很少。这就是所谓“低代码”的来由。
- 使用NodeRED，图形化编排基于数据流方式的应用程序。
- 采用类似于工业自动控制系统中采用的组态工具来配置应用程序。
就笔者分析，这三种方式都不理想。前两种避免不了编程。而第三种方式的困难在于：物联网应用要比传统自动控制系统更加复杂和广泛。无法预先编写出能够满足大多数应用的组态软件。比如有些物联网平台上直接给出了灯光控制，家电控制和水泵，农业浇灌等组态图形，让最终用户可以通过拖动图标和设置参数来实现组态编程。不过试问一句，他们能够涵盖多少物联网应用呢？系统集成商的核心竞争力和差别化优势又如何去体现。作为演示是可以的，能否被别人接受是另外的事情了。
我们更加倾向使用IEC61499 功能块来作为物联网应用的编排工具。也就是说，最终用户使用IEC61499 功能块来编写物联网应用。
- IEC61499 具有很强的建模能力，比组态程序更加灵活。
- 基于事件的功能块网络与面向对象程序设计中的对象，以及云平台中的微服务更加契合。
- 系统集成者可以通过开发面向行业的功能块库来实现之身的核心价值
- 第三方可以参与面向特定行业的功能块库，有利于形成生态系统。
自动控制领域的工程技术人员更能够接受IEC61499 中的概念，模型和编程习惯。而目前的物联网项目大多数是由IT 公司发起的。IT 工程师相对比较容易接受新技术和新方法。相信他们能够很快学会IEC61499 功能块编程方式。
基于IEC61499 物联网边缘服务器的软件架构
基于IEC61499 物联网设备中的应用是使用功能块网络来编排的，然后将他们部署到IEC61499 运行时中运行。IEC61499 运行时也是在容器中运行。他们通过服务接口功能块来访问其它微服务和IO接口。 IEC61499 物联网设备中的所有东西都是采用功能块定义和使用的。应用通过功能块访问设备中的微服务和IO接口。
IEC61499 物联网服务接口功能块
IEC61499 标准为分布式系统提供了一整套模型。要将IEC61499 模型应用于物联网应用，同样需要开发相应的物联网功能块库（IoT FB Library）。以及相对应的软件微服务。微服务是可重复使用的软件模块。对于扩展IEC61499 应用的功能也十分重要。理论上每个微服务将会有一个IEC61499 功能块与之对应。
跨越市场接纳鸿沟的唯一途径是让功能块和微服务丰满起来。下面我们来讨论一些构架哪些功能块库。
基本的IoT 功能块
通信类功能块
-TCP/IP，UDP，Websocket 协议
-微服务消息（MQTT，Rabbit MQ）
-BN-IoT Publish/Subscribe
-Modbus 功能块（Master/Slave）
-ModbusTCP 功能块
基于Web 的HMI 功能块库
前端设备或者边缘服务器建立一个Web 服务器。IEC61499 运行时要能够提供一套基于HTML5的UI 功能块。能够通过这些功能块动态建立基于Web 的HMI 界面。
基于QT 嵌入式UI 技术的HMI 功能块库
对于现场控制设备而言，许多场合需要低成本的现场HMI 面板 。这可以使用带有LCD 控制器的MCU 芯片构成嵌入式系统，采用流行的嵌入式图形技术QT。
数据库访问功能块
物联网系统中主要使用时间序列数据库为主，比较流行的是InfluxDB 数据库。为了能够有效地访问时间序列数据库，需要使用数据库访问功能块（CREATE_DB,WRITE_DB,READ_DB）
数据采集和测量功能块库
前端设备需要对现场数据进行预处理，这就需要一系列数据处理功能块，他们包括
-数字滤波
-快速傅里叶变换
-平均值，中位数
-PID 算法
-卡尔曼滤波
IO 接口功能块
-数字输入输出接口
-ADC 模拟量采集（20mA 电流环，0~10V 电压等等）
- PWM 输出，脉冲计数
结束语
IEC61499 是为分布式工业测量，控制和监督系统而制定的国际标准，由于诸多原因，它在自动控制领域的推广十分缓慢。与此同时，伴随着互联网技术而兴起的物联网面临着标准缺失。笔者认为将IEC61499 技术应用于物联网领域，能够扬长避短。发挥各自的优势。也许能够走出一条创新之路。希望读者们共同探讨。
