上个世纪九十年代，国际电工委员会（IEC）就着手制定IEC16499标准，它是一个面向分布式工业过程，测量和控制系统的一个基于功能块编程的国际标准。它于2000年正式发布了第一部分，2005年全部发布完成。按照IEC 的规矩，每隔五年会修订一次，最近一次修订是2015年。IEC61499 工作组的成员来自于美国，日本，英国和许多欧洲国家。它们代表了工业控制的供应商和用户。
就这么一个阵容强大，花费了很大努力开发的标准，学术界的研究还比较热，出现了许多的论文。而工业界似乎是冰火两重天，一直是不温不火。除了奥地利的nxtControl 公司以外，像西门子，施耐德，Honeywell大公司始终没有商业化的产品出现。就像研华公司曾经在2016年推出了ADAM 6600 ，支持IEC61499。现在在它们的网站上已经不见了踪影。施耐德收购了nxtControl 公司，在它们的建筑自动化产品中具有功能块图形编程，但是任然是基于 IEC-61131-3 的PLC 功能块标准，并没有使用IEC61499。Rockwell 自动化公司收购了 ISaGRAF公司，现在在Rockwell 公司的网站上还能看到 ISaGRAF的产品资料。但是也好像只是一个软件孤零零地在那里。在施耐德公司的另一个产品-用于远程工业测量和控制的Foxboro SCD2200 RTU 产品中，声称内置了ISaGRAF的编程环境。支持IEC61131-3 和IEC16499 编程。真是够乱的。
问题到底出在哪里呢？不得而知。也许大公司觉得IEC1131-3 用的够好，没有必要那么急得切换到IEC16499？ 还是什么别个考虑？ 本人曾经花了一年多的时间研究数据流图形化编程技术，根据自己的体会，在这里谈谈IEC61499 产品实现的困难吧。
IEC61499 的核心概念是功能块（Function block）编程。其目的是采用面向目标程序设计的思想，使工业控制软件封装成为功能块形式的软件组件（Software component）。而且功能块与资源无关（所谓资源你可以理解为硬件设备）。一个分布式控制的应用软件，是一个功能块网络，可以将功能块网络分解成若干段，将每一段映射到分布式的设备中去运行。当映射的时候，自动地插入了通信服务接口功能块。这就是IEC61499 为我们描写的理想状态。如果设计一个复杂的分布式应用系统变成为通过拖动功能块，连线绘制一个功能块网络那么简单的话。当然是十分诱人的。专家会一下子总结出一堆优点，描绘令人激动的场景出来。
不过具体实现的过程中，会遇到许多的问题：
1 功能块不可能完全与资源独立
除非假设你的设备的性能无限地大，否则功能块就不可能完全与资源，也就是运行功能块的硬件设备无关。工业测量控制系统具有很高的实时性要求。使用软件实现的功能块在不同的硬件平台上运行时间会有很大的差异。比如一个FFT 功能块在cortex-M和cortex-A，或者X86 处理器上的运行时间是完全不同的。
2 功能块不可能完全与网络无关
和第一点相同的原因，不同的网络和协议对系统性能，时延的影响是非常大的。
3. 谁来开发功能块
另一个大的问题是谁来开发各种功能块，用什么语言来开发功能块？功能块网络编程真的很诱人，但是谁来开发这些功能块呢？IEC61499 编程环境会开发一些基本的功能块，它们包括了基础的事件功能块，通信服务功能块。而硬件设备厂商会开发一些与硬件有关的服务接口功能块，例如IO子系统的读写服务功能块。但是，一个复杂的分布式控制系统不仅仅是PID那样简单的功能块那么简单，它需要的功能块是非常多的，比如FFT功能块，信号滤波功能块等等。这些功能块由谁来编写呢？理论上IEC61499 提供了复合功能块的概念，用户可以使用一些基础功能块来实现复杂的功能块，不过这对控制工程师的要求就非常的高，学习曲线变得陡峭。国内的控制工程师实际上连PLC中的功能块都使用甚少，所以让控制工程师编写功能块是不太现实的。于是只能指望专业的平台公司或者第三方开发者来开发各种功能库，像nxtControl 公司，他们提供了许多的功能块库。包括建筑自动化库，过程控制库，机器自动化库。由此看来，只有针对某一个特定的领域，才能开发出功能块库。这是一个工作量巨大的任务。另一方面，即使你开发的足够的库，在具体的应用中，控制工程师还会觉得少一个库。工业过程控制系统真的是有千变万化的需求。
还有一个问题是使用什么工具来开发具体应用中专用的功能块程序。IEC61499 并没有规定功能块编程的程序设计语言，理论上任何语言都可以用来编写功能块程序。不过，功能块不仅是在开发平台上连个线，绘制功能块网络那么简单，他们最终要部署到各种资源中去。所谓部署，就是将功能块网络的”程序” 下载到设备上，和IEC61499 兼容的运行时，资源共同完成功能块的实际控制功能。这些程序也许是一个XML 文档，也许是一个java 程序。设备上的运行时就像一个虚拟机一样解释执行这个功能块网络。显然，解释器方式的运行效率不高，而且对硬件资源的要求更高（通常需要linux 系统支持）。所以在小型设备中，更加倾向于将功能块翻译成为C++，和运行库一起编译成为设备的固件，下载到设备之中。当然这样做增加了开发工具的复杂性和对硬件的依赖，而且对系统仿真和调试带来了不便。
目前大致有三种不同的方式来编写专用功能块程序的方式：
- 使用现成的功能块来构建复合功能块
- 使用java 编写功能块
- 使用C/C++编写功能块。ISaGRAF 就是输出C 语言源码。
最后一个问题是如果使用过分低级的功能块来编写复杂的复合功能块，会使软件的碎片化十分严重。从而影响软件的执行效率。
未来的研究方向：
-针对某一个领域中使用ICE61499 的概念和框架。
要聚焦某个具体的应用才可能实用化。要不然只能用于学术研究和教育。只有针对具体的应用，将行业种的经验，know-how封装成为功能块，来会产生使用它的动力。用户往往就是这样，当他需要某个功能，而刚好只有某一项技术才能解决，才会驱动自己硬着头皮去学习新技术。要不然你让一个工厂的控制工程师去学习像labviews ，matlab python 这样的新技术比什么都难。免费，开源，公开课都不好使。
-开发面向具体应用的功能块库，比如CNC机床控制，建筑自动化，能源管理等领域。
如果没有行业的背景，开发通用的功能块，觉得再怎么努力都无法满足用户的需要。我们以前开发数据流图形设计语言的时候就是如此感觉。要达到像NI 那样的境界，又不是一日之功。
-要与硬件设备同步开发。
在特定硬件平台上测试功能块的性能和行为，这就像芯片设计一样，要有silicon prove 的过程。
-小型装置上的功能块倾向于使用C/C++ 实现
效率更高，使用的硬件资源比较少，我们再尝试再STM32H743 平台上开发IEC61499 的运行时程序。而HMI 或者服务器端的功能块可以多样化语言来开发。特别是java,javascript,python 或者Go 语言。
-IEC61499 与其它物联网技术融合。
IEC61499 标准只是一种分布式系统的建模方式和概念，它并没有涉及任何实现技术。在具体实施过程中可以使用大量物联网最新技术 MQTT，OPC UA，Docker 容器等等。而目前物联网系统最缺乏的是系统建模和软件组件标准化。所以IEC61499 和物联网可以完美地互补。
个人看法，并不成熟。感兴趣的朋友可以多多交流。