IEC61499标准背后的逻辑

俗话说，透过现象看本质。从工业控制软件的诸多概念，术语，软件中，我们如果理解了工业软件背后的逻辑，就明白了工业控制软件的本质。

功能块

IEC61499 标准中最重要的概念是功能块（function block）。从使用者的角度看，功能块是一个类似硬件原理图中集成电路的图形符号。通过连线，可以构建一个功能块网络。这就是基于IEC61499 功能块的控制系统应用软件。

那么从开发者的角度看，功能块到底是什么呢？为什么要采用这样的方式来编写工业控制的应用软件呢？采用一句话来透彻地描述功能块-“功能块是软件组件的图形化表示”。每一个功能块图形的背后是控制设备中的软件组件。软件组件和响应的物理部件一起完成相关的控制功能。

软件组件（software component）是一个成熟的概念。为了使软件能够重复使用，人们提出了模块化程序设计的概念。软件组件就是一种软件单元，它们具有规范的模型和接口定义。在传统程序设计中，程序库中的子程序可以看做一个软件组件。而在面向对象程序设计语言中。一个由类（class）定义的对象就是一个软件组件。

在IEC61499 系统中，每个功能块对应于设备中的嵌入式软件里面的一个对象（class）。比如E_CTU功能块对应 C++ 或者java 中名称为的E_CTU 类。

如果你理解了“功能块是软件组件的图形化表示”的概念，就能够认识到，实现 IEC61499控制系统的基础是实现背后的软件组件。IEC61499 功能块库对应的是设备软件内部的类库。

工业控制软件大多数是和物理设备紧密结合的嵌入式软件，它们要求具有高可靠性，确定性和实时性，而且和生产工艺和过程十分紧密。而且控制器的硬件资源十分有限。编写这样的嵌入式软件是一个巨大的考验，需要具有长期的工作经验和很强的行业背景。

开发工业控制的嵌入式软件是一项十分困难的工作。可惜许多人有一个错觉，认为编写小单片程序是新大学生干的事情。

正是由于工业控制领域的嵌入式软件开发成本高，周期长，软件的重用就显得十分重要。模块化，组件化就成为正确的选择。软件组件就像硬件的大规模集成电路类似，如果应用工程师都采用中规模集成电路来实现硬件的化，是非常复杂和困难的。半导体公司开发了大量的大规模集成电路，它们完成了电路的设计和测试。硬件工程师只要根据器件的数据表和输入输出引脚定义来设计原理图，并且部署到PCB板上，就能够实现它们需要的功能了。软件组件就是软件工程师的“元器件”，硬件工程师能够使用图形化的逻辑图来设计硬件电路，软件工程师也同样能够使用功能块网络来设计应用软件。

另一方面，工业控制系统的嵌入式程序通常是周期性运行的单一功能的程序。它们更适合软件组件化。其实在很早以前，工业设备中就采用了软件组件的模式来开发内部的嵌入式软件。只是他们那么称呼而已。比如SCADA 系统中的各种HMI 图形背后对应的是软件组件。PLC 的梯形图和后来发展起来的IEC61131-3 功能块，也是软件组件的图形化描述形式。工业控制软件中的各种组态程序背后都是丰富的软件组件库。

使用图形化，可视化，软件组件化。加上各种系统的形式化，模型化描述语言（比如UML ,sysML语言）。形成了工业控制软件完整的技术体系。保证了工业控制软件的可靠性，确定性。从这个角度，我们才能理解工业控制软件和IT 领域的软件技术和使用方式如此的不同。

架构

一个工业自动控制控制系统和物理设备一起安装运行，它们的生命周期会是十年，甚至更长。任何一个架构如果能长期地被采纳，需要能够从已有的系统向新系统转移和升级的能力。

这样的系统必须是“开放”的，也就是说这样的系统架构应该具备下面几个特性：

移植性Portability

互操作性（Interoperability）

配置性（Configurability）

一个理想的分布式系统如下图所示。一个中心计算机可以访问软件组件库和项目仓库。软件组件和项目应用程序采用了XML标准语言描述。实现移植性。通过配置协议部署和更新设备的控制程序。实现可配置特性。设备之间采用一个统一的协议和网络实现互操作性。

IEC61499 分布式工业控制系统正是符合上述特性的控制系统。配置协议采用了XML 协议格式。而互操作协议采用了TCP /UDP协议和ASN.1 信息编码。

在开源IEC61499 项目4DIAC 的IDE和设备中的运行时如下图所示。IDE 与设备之间的配置协议采用的TCP协议。而设备之间的互操作协议采用的UDP协议。

功能块描述

功能块背后的软件组件可以使用不同的计算机语言来实现，比如C++，Java 或者Python，Go 等。除了性能以外，它们实现的算法和行为应该是类似的。它们的接口是统一格式。IEC61499 使用XML 语言来描述功能块。

功能块的XML描述类似于软件功能块的“源代码”，它们部署到设备中，由对应的软件组件来实现该功能块的算法和行为。

采用了标准化XML 语言来描述。功能块的移植性非常强。只要设备中实现了对应的软件组件。就可以部署到该设备中运行。如果在X86，ARM ，处理器的设备中实现了一个功能块的软件组件，那么这些设备就可以运行该功能块。唯一的区别可能是性能优劣之分。。

应用程序描述

在IEC61499 系统中，应用程序是由功能块通过配置和连线构成的功能块网络。它们和硬件设计的中的逻辑图非常相似。只是这里不是逻辑电路块，而是功能块。在IEC61499 中，功能块网络也是采用XML 来描述的。

配置协议

IEC61499 标准的系统中，中心计算机通过配置协议。部署和监控设备中的功能块网络。该协议采用了Client/Server 结构。设备是服务器端，IDE是客户端。命令格式是ASN.1 编码的XML 命令和响应。

ASN.1 编码

ASN.1抽象语法标记（Abstract Syntax Notation One） ASN.1是一种 ISO/ITU-T 标准，描述了一种对数据进行表示、编码、传输和解码的数据格式。这种编码方式比XML和json 编码要简单的多，更适合嵌入式系统中数据交换。

Request/Rsponse 命令

在Client/Server 架构下，配置协议采取了请求/响应命令方式（Request/Response Command）下面是主要的Request/Rsponse 命令：

建立（Create）命令

使用建立命令建立功能块（FB），连接（Connect）和观察点（Watch）

建立功能块（FB）

请求

响应

建立连接（Connect）

请求

响应

建立观察点（Watch）

请求

响应

查询（QUERY）命令

查询功能块类型

请求

响应

查询功能块

请求

:<Request ID="0" Action="QUERY"><FB Name="*" Type="*"/></Request>

响应

写命令（WRITE）

初始化功能块输入数据。

请求

读命令（READ）

-读取所有观察点数据（Watchs）

读取所有观察点的当前数据。

请求

响应

<Response ID="5">

<Watches>

<Resource name="EMB_RES">

<FB name="E_CTU">

<Port name="PV">

</Port>

<Port name="Q">

</Port>

</FB>

<FB name=”E_CYCLE”>

…….

<FB>

….

<Resource>

<Watches>

</Response>

删除命令（DELETE）

删除某个观察点。

请求

响应

杀除命令（KILL）

启动命令（START）

启动应用程序开始执行。

请求

:<Request ID="19" Action="START"/>

响应

互操作协议

在IEC61499 分布式系统中，应用可以映射到不同的设备上运行。而不同设备之间的事件和数据要通过通信功能块传输。当部署到不同设备时，要添加通信功能块，如下图所示。

在4diac中，设备之间的通信功能块不是自动插入的(我原来以为是ＩＤＥ自动插入的呢)，而是在Forte-PC和Forte-PC_1　的RES 中人工的方式插入的。可以采用不同通信协议的通信功能块。例如UDP.TCP，MQTT或者modbus.现在想来，这样安排增加了系统的灵活性。如果插入publish和subscribe ,（ID 为　239:0.0.1:61000），没有指定IP协议，默认为UDP 协议。

239:0.0.1 是组播地址。传输效率更高。

设备和设备之间采用双向UDP 协议通信（端口为61000） ,UDP 的块数据格式采用了ASN.1 数据编码。数据的排列顺序是publish 的发送数据顺序（SD_1,SD_2 ..）依次排列。

结束语

功能块是软件组件的图形化描述。每一个功能块对应可控制器内部的一个软件组件，比如一个对象。

工业软件，特别是嵌入式工业软件的开发是非常困难的，工业软件更需要模块化和组件化。因此在工业控制领域，大量采纳了模块化，组态化，图形化程序设计方式。

开发一个功能块系统的关键是配置协议，分布式功能块的互操作协议，以及功能块库的实现。

基于这些观点，我们开发了一个在Cortex-M 单片计算机上运行的IEC61499 运行时，并且与4DIAC 兼容。后面我们将陆续介绍这个软件的实现方式。