《使用IEC61499为控制系统建模》-第二章 IEC61499 模型和概念

最新推荐文章于 2024-02-05 12:04:05 发布

姚家湾

最新推荐文章于 2024-02-05 12:04:05 发布

阅读量2.2k

点赞数 3

分类专栏： IEC61499

IEC61499 专栏收录该内容

110 篇文章 169 订阅

订阅专栏

我们现在将描述在IEC61499 中主要的模型和概念，对这个关于功能块的标准有一个全面的了解。建议在阅读后面几章，详细了解IEC61499 特征之前，首先·了解本章的材料。

本章的主题包括：

功能块特征以及它们的执行
功能块的不同形式
提供硬件和操作系统接口的服务接口功能块
独立于系统配置表示应用的模型
分布式系统的系统，设备和资源的模型
将应用赋予不同设备和资源的分布式模型
IEC61499 项交换和存储模型

在我们详细研究IEC61499的许多模型和概念之前，我们重新思考在引言一章讨论的关于IEC61499 的范围。IEC61499 的主要目的不是编程方法，而是分布式系统的架构和模型。IEC61499 使用功能块概念提供了一组模型，描述分布式过程测量和控制系统使用功能块概念的行为和结构。这是必须理解的重要区别。避免引起对IEC61499 产生误解。

IEC61499 提供了术语，模型和概念，以利于明确，形式化地实现面向分布式控制系统的功能块。使用形式化的，标准化地描述系统有利于系统的验证，比较和理解。这是朝向分布式系统标准化程序设计方法学的第一步。IEC61499 标准的编写者提出的观点是如果没有支撑我们编写程序的一致性架构，不可能由一致的编程方法。

我们现在来研究IEC61499 引入的各种模型，形成面向分布式工业过程测量和控制系统的功能块架构。

2.1功能块模型

该标准的核心是功能块（function block）模型。它构成了完整的IEC61499 架构。功能块可以描述成为“软件的功能模块“。它具有自己的数据结构，并且由一个或者多个算法来处理它们。功能块类型（function block type）提供了数据结构和算法的形式化描述。功能块可以有多个实例（instance）。从形式上看，功能块和C++中的对象非常类似。在工业实践中，也经常使用功能块的概念，例如在许多PLC 和工业控制器中就有PID 功能块。许多厂商提供一个PID 功能块定义。程序员可以在控制算法中使用多个PID的实例，比如称为“Loop1”和“Loop2”，它们相互之间是独立的。每个PID 实例都有它们自己的参数和内部状态变量。也共享相同的更新算法。

IEC61499 定义了若干形式的功能块。在下面的章节中，我们会来详细地了解它们。IEC61499 功能块的主要特征总结如下：

每个功能块有一个类型名称和一个实例名称。

2.1.1一般特性

IEC61499 定义了若干形式的功能块。在下面的章节中，我们会来详细地了解它们。IEC61499 功能块的主要特征总结如下：

每个功能块有一个类型名称和一个实例名称。它们在功能块图形化描述时，会显示出来。
每一个功能块都能有事件输入。它们能够接收其它功能块通过事件连接传递的事件。
每个功能块都能有事件输出。它们向其它功能块传递事件。
每个功能块会有数据输入。传递给它其它功能块内部产生的数据。
每个功能块会有数据输出。将该功能块内部产生的数据传递该其它功能块。
事件可以使用”WITH“修饰词与数据关联。在图形表示中，将事件和相关联的数据连接线交叉点画一个小方块。对于输入和输出的含义如下：

-当一个事件发生时，它关联的数据更新。其它输入变量保持它们的值（也就是说，没有变化）

-当输出事件触发时，关联数据输出有效，而其它数据没有发生变化。

IEC61131-3的数据类型用作变量的数据类型（见附录A 可用数据类型）
功能块封装功能，它们具有内部变量。功能的形式和类型由功能块类型决定。
IEC61499不允许有全局变量。
所有功能块数据（输入，输入和内部）在功能块每次调用之间要加以保留。

在图2.1中，描绘了IEC61499 功能块的主要特性。在功能块的顶部，称为“执行控制”段，包含了将事件映射到封装功能的定义。也就是说，它定义了在“执行控制”中，到来的事件触发哪一个封装的功能，什么时候输出事件被触发-标准称之为：“输入事件，输出事件，封装功能执行之间的因果关系”，标准定义意味根据不同的功能块类型，实现事件输入端事件到达，封装功能的执行，输出事件的触发的映射关系-它们将在后面的章节按不同功能块类型分别讨论。

功能块的低端（Low portion）包含了封装的功能以及可能存在的内部数据-两者都隐藏在功能块内部。功能块是一种类型的软件组件。如果设计完善，使用者不需要详细了解其内部的设计。

功能块依赖于包含它的资源，资源提供了调度封装功能，映射通信和过程接口的机制。

标准指出，作为选项，资源能提供额外能够访问功能块内部的性能。比如说，在一个现场总，线设备的中，如果能够检查功能块内部的变量，对应维护和调试是有用的。所以，有“后门”的方式访问功能块内部。不过从IEC61499 架构的观点看，控制变量和事件只能通过外部暴露接口来访问。

注意：IEC61499 功能块包含了所有定义它们完整行为二点算法和初始化值。

2.1.2 功能块的执行模型

执行模型通常将功能块定义成为“被动元件”。需要一个输入事件触发来调用它封装的功能，执行顺序由图2.2 描述。在该功能块中的数值圆圈显示功能块不同部分执行顺序。该模型假设功能块所在的执行环境提供一个调度功能，保证功能块的各个部分按正确的顺序和优先级执行。进一步地，标准将功能块的执行定义为算法。这意味着它将在一定时间内结束。因此，在功能块中不允许有挂起操作单元。对于实时受限的应用而言，它的执行时间是严格受限的（也就是要低于应用指定的门限）。

有一定数量的离散阶段。当请求功能块执行时，它们每个都耗费一段时间。每个阶段都依据功能块和整个调度功能之间定义·的交互决定的。图2.2 描述功能块操作的8个最常见的步骤。每个阶段的中止都有一个数值编号的步定义

其它功能块提供的数据在数据输入端有效
输入事件到达，数据被采样，并且通知执行控制。
基于功能块执行控制的当前状态，通知调度功能，某一个封装的功能准备执行。
一段时间之后，调度功能开始执行请求的功能块封装功能。时间的长短依赖于资源的装入和性能。
分装的功能完成完成其任务，处理输入值。在有些场合要处理内部存储的值，产生写道功能块输出端的新的输出值
封装的功能完成它的执行，并且通知调度功能更新的输出值已经稳定就绪。
调度功能调用功能块的执行控制。通知它封装功能已经完成，并使它产生一个输出事件。根据输入事件端到达的事件和执行控制的内部状态，将产生不同额输出事件（或者没有事件输出）
执行控制在功能块输出事件接口依次建立相应的输出事件。并使相关的输出变量对连接的功能块可用（采样到连接）。输出事件用来触发后续功能块的执行。通知它们现在可

以使用该功能块产生的输出值。

注意：在第2步采样输入变量以后，输入变量值在有事件触发的整个功能块执行期间不会发生改变。这样保证在封装功能执行过程中，保证数据值的稳定和确定性。

这里表述的执行步骤序列是当输入事件到达时产生的大多数基本执行序列。根据输入事件端到达的事件和执行控制内部的状态。3-8 步可能执行若干次。在这种场合下，在一个输入事件的响应中会发送多个输出事件。

重要的是要注意：在这个执行模型上有一系列的限制。这些事件阶段不能够重叠。必须按照功能块预定的顺序正确地执行，然而，在某些实现中，某些阶段可以在周期中很断，以至于认为它们是同步额。IEC61499 没有定义任何这些事件的限制。不过它指出，在任何功能功能块模型中可以定义这些不同阶段的周期。以便建立完整功能块网络的时间特性的精确模型

标准定义下列周期在建立应用时是有意义的：

Tsetup=T2-T1 输入事件到达与输入值可用（由前续功能块更新）之间的时间

Tstart=T4-T2 接收到一个输入事件到执行功能块封装功能块之间的时间。这个时间间隔与资源装入性能有关。也就是，有多少其它队列排列在调度功能的队列中。

T algorithm =T6-T4 功能块封装功能繁荣开始到完成的时间

T finish=T8-T6 从功能块封装功能完成到触发输出事件的时间。

这些时间点的相互关系在图2.3 中描述功能块改变输入输出数据的时间点同样也显示了出来。值得注意的是；标准假设事件行为是事件的离散点，没有循环。在一个物理系统中，事件需要某种形式的状态转换。从挂起到一小段短而且有限的期限。

IEC 61499模型假设在一个功能块的输入端没有输入事件和数据队列。然而，标准定义了在执行环境需要保证在任何一个时间点只提交一个事件。执行环境能够有选择地使用事件队列，保证在功能块执行期间不会丢失事件。当一个功能块接收到的输入事件比功能块能够处理事件的时间快时，执行环境能够检测到是很重要的。进一步地，实现要提供输入数据队列。不过这不是IEC61499 显式模型。然而，这样的行为可用通过特殊功能快来建模。模型允许资源利用多任务处理功能块算法。在调度功能中，使用恰当的优先级。对于大多数事件而言，能够克服过载的问题。不过，调度功能的内部行为和特性不是标准的范围。已有功能块不同实现选项的详细描述在【20】中给出。

2.1.3 功能块类型（Function block types）

IEC61499 的一个重要的概念就是能够定义功能块类型。功能块类型定义了功能块实例的行为和接口。功能块实例能够通过类型来建立。这和面向对象软件中对象的行为由相应的对象类来定义方式是类似的。

功能块类型通过类型名称，功能块输入输出事件的形式化定义，和输入输出变量的定义来定义的。类型定义还包括了功能块的内部行为。对于不同类型功能块，定义的方式是不同。

基本功能块类型（Basic function block）

基本功能块的行为是以相应输入事件的算法来定义的。当事件执行时，触发输出事件，标志功能块内部的某些状态发生了改变。算法上的事件的映射是通过状态转移来标识的，它被称之为执行控制图（Execution Control Chart （ECC）

复合功能块类型（Composite function block）

复合功能块的行为是通过一个功能块实例网络来定义的。因此，定义包括了内部功能块实例之间的数据和事件连接。

服务接口功能块类型（Service interface function block types）

服务接口功能块提供了功能块域和外部服务之间的接口。例如，与远程设备中的功能块进行通信，或者读取硬件实时时钟的服务。因为一个服务接口功能块类型主要涉及数据交互，它使用服务序列图。服务序列图在3.3节有更详细的描述。

2.2应用模型

一个IEC61499 应用定义为一个互联的功能块网络。由事件和数据流连接。所以说，一个应用程序包括了若干个功能块实例和它们之间的相互链接定义。使用功能块来描述所有的行为是IEC61499的基本原理。于是我们看到，在一个应用中，除了功能块以外，没有任何全局变量和本地变量。这是基于IEC61131-3的PLC和IEC61499 应用的根本区别。

IEC61499应用程序的特征如图2.4所示。事件连接通常是点对点的连接。从一个事件输出连接到一个事件输入。数据连接标准允许”扇出”连接方式（fan-out connection style）。也就是说，一个数据输出可以连接多个数据输入。扇入（fan-in），也就是多个输出连接到一个数据输入是不允许的。这样做的理由是功能块在IEC61499 中是完全解耦的，没有数据源的信息。如果允许扇入，功能块将无法确定从那个数据连接上取数据。最后，输入的事件和数据不一定源自于同一个功能块（例如图2.4中的FB1）。这对于采样和处理多个源的数据需要同步与一个事件的场合是有用特性。

注意：为了简洁，事件和数据的输入输出名称在图2.4 中省略了。

现实中，应用程序是完整的一组功能块和相互连接，解决某个特定的制动控制问题。例如，一组功能块控制一条生产线，一个塑料挤出机，或者发酵炉。在这个阶段，应用程序模型不需要考虑任何硬件。只需要重点关注全面的控制功能。所以，相比于IEC611131-3应用程序开发是非常聚焦资源。而IEC61499 应用开发是应用为中心的。

2.3 系统模型

在物理层，分布式系统由若干设备通过各种网络连接，支撑一组相互协作操作的应用。诸如生产线控制，容器或者传输带处理等应用通常需要运行在一定数量设备上的软件协同操作。直到最近，远程分布式应用都是运行在远程设备上的小百分比软件。比如环路和温度控制器。而主要的智能控制都放置在后端的中心处理器上面，比如PLC。随着诸如智能传感器和执行部件这样的设备开始提供更多的处理能力。软件功能能够真正分布于多个设备上。到了这一点，很难标识出主要的控制设备

2.3.1 总体系统结构

我们从IEC61499 定义的系统模型的顶端开始研究。这个模型定义了若干控制设备和它们之间的通信关系，构建成一个通信设备的网络。通信链路可以有不同的类型，而设备可以连接到不同的通信网段。这样能够形式化通信的分层结构，如同2.5 所示。

2.3.2 设备模型

在图2.6 中显示的设备模型描述了支撑ICE61499 功能块网络执行的物理控制设备的总体结构。设备的主要目的是提供一个或者多个资源的基础架构。IEC61499 的资源类似于PLC 标准IEC61131-3 中资源的概念。资源提供了功能块网络的执行环境。然而，相比于IEC611131-3，一个IEC61499 的资源并不限制在一个执行单元中，

一个设备具有一个“过程接口（process interfance）”，它提供了资源与物理设备上IO点交换数据的服务。也具有一个通信接口，提供资源和外部设备中的资源通过网络交换数据的服务。如同图2.5 所示，一个设备能够连接到一个或者多个网络中。

2.3.3 资源模型

资源是支撑功能块网络执行的设施和服务。

资源提供了与通信系统和“设备特定服务device specific services”的接口。比如设备的I/O子系统或者显示。比如，比如每个资源都具有通信系统的接口。让功能块能够与远端资源中的功能块交换数据。也有一个接口读写设备I/O。所以，资源通过设备的通信接口将本地资源的数据和事件流与远程资源的功能块实现映射。同样地，资源将所有的设备IO读写请求映射到过程接口。很清楚，资源定义了IEC61499 模型的范围和设备和系统特定功能之间定义了边界。包括了操作系统设计和通信协议。指定了标准以外的设备和网络的类型。

图2.7 描述了IEC61499资源的主要特性。

在资源中，表明一个网络互联功能块连接了数据和事件流，一个由资源提供的调度功能（scheduling function）保证了功能块中的功能按正确的顺序执行。服务接口（Service interface）功能块是一种特殊形式的功能块，提供了功能块和资源接口之间的连接。例如，通信服务功能块能够读，发送远程功能块的数据，在IEC61499 中定义了一系列的不同类型的服务接口块，将在第五章描述。

资源的一个重要特性就是它支持独立的操作。一个资源能够独立地装入，配置，启动和停止。不会影响相同设备和网络中其它资源。然而，值得注意的是，管理分布式应用，需要若干资源协同控制

2.4 分布式模型

分布式模型使用系统模型连接系统独立应用模型，它涉及到将应用的各个部分映射到设备和资源，并且完成应用的特殊配置。

2.4.1 映射应用

应用可以是“分布式”的，也就是说，配置和运行在若干的资源之上。一个分布式应用由若干段功能块网络构成，每一段功能块网络运行在指定的资源之上。注意，IEC61499 考虑的分布式涉及将应用的功能块分配到设备的不同资源上，这些设备在系统模型中定义。为了实现这样的分配，要使用映射语句（mapping statement）。图2.8 显示了将我们在图2.4 的应用例子映射到图2.5 的系统模型上。

IEC61499 系统和分布式模型的一个特性是允许设备执行一个或者多个应用。标准按如下的方式定义设备模型，可以装入一个或者多个分布式应用，不会破坏已有的应用。这是通过在设备中使用管理服务来实现的-这将在后面的章节中介绍。

由于设备能够支持多个资源，所以将不同的应用映射到不同的资源（图2.9），能够在设备中区分不同的应用。进一步地，也能够将应用映射到一个设备上，也就是在同一个设备的不同资源（图2.9的应用2）

应用的事件时间性能取决于它分布的资源和通信网络，比如两个相同的传送带控制应用，一个运行在1GB 的光纤网上，另一个运行在低成本的1M双绞线上，由于通信的数据速率如此不同，显然两个应用由于网络延时不同，它们将明显具有不同的性能和响应事件。尽管它们的内部软件算法是一致的。

相比之下，假设功能块是不可分割的“原子”，它只能运行在一个单一的资源上。从这个意义上讲，功能块的性能不受到通信网络性能的影响。然而性能会受到包含该功能块实例的资源和设备的性能和行为的影响。这些分布式特性总结在表2.1中

2.4.2 平台的特定配置

应用映射的结果有两个方面，应用的分布式导致功能块之间的直接连接断开（例如FB4和FB5之间的连接）。第二个方面是系统特定的配置，比如赋值物理输入端口地址，以便提供传感器的值。这些特定的配置不是应用模型的一部分，它们是平台和系统独立的。

为了处理这一项，IEC61499 允许增加系统特定配置值和扩充在资源中的应用部分。平台特定的应用扩展典型的是插入通信服务接口功能块以及它们的配置（比如通信通道的标识符）。这些通信服务接口维持了设备和资源之间“断开”的连接。如图2.10

粗一看，这些系统配置的特定适配是不需要的，然而，它强力地支持了应用的平台独立性。应用的设计过程的重点放在关注控制的功能。平台特定的配置放在在研发周期的后期，有利于应用和部分应用的重应用性。进一步地，它的优点是以后修改设备和系统配置不影响应用的开发。

2.5 管理模型

我们已经看到，资源能够支持功能块网络分段。构成分布式应用部分。但是，这些应用如何分段和管理的呢？IEC61499 的设计考虑到了适配可配置自动系统的需要。这需要系统在运行的时候可以远程改变资源和其中包含的功能块网络。而且对控制的过程没有影响，或者影响极小。所以，IEC61499 定义了一个管理应用（Management Applications）的管理接口和管理项目的通用行为模型（例如资源，功能块实例和它们的相互连接）

2.5.1 管理应用（Management Applications）

IEC61499 定义了一个特殊形式的应用，称为管理应用。它的主要职能就是管理资源的应用生命周期和资源中的功能块网络。管理应用相比普通应用而言，具有更高等级的权限。能够通过建立/删除功能块和连接来构建/结构其它应用的部件。它通常通过连接到外部站点（比如远程编程工作站）的通信接口来提供管理功能的。

管理应用的功能需求包括：

在一个资源中建立功能块实例
建立功能块实例之间的事件和数据连接
设置资源和功能块实例的参数
初始化功能块实例的执行，作为分布式应用的一部分
改变资源和功能块实例的操作状态
提供支持来自通信链路的队列服务
1. 功能块实例的状态，包括操作状态和输入输出值
2. 当前功能块实例和它们的连接
删除功能块实例
删除数据和事件连接

一个重要的限制是管理应用要能够装入不同应用的功能块网络段，但是不打搅正在执行的其它应用。

管理应用装入普通应用，那么管理应用自身是如何装入的呢？假设在设备中需要在管理应用中具有某个层面基本功能来“bootstrap” 装入主应用的功能块。部分管理应用将存在设备的非易失性存储器中。当设备上电是总是能够装入应用程序

注意：有些设备将所有的功能块网络存储在非易失性存储器中，不能通过外部通信加以修改。在这种情况下，管理应用的大部分功能不再需要。

标准推荐两种管理应用的方案。图2.11a 描绘了设备具有专门的管理资源。其中包含了管理应用，提供在设备提供的资源中提立和维护功能块网络的功能。图2.11b 是另外一种管理方式，在每个资源中包含一个管理应用，能够在相同的资源中装入功能块网络

管理应用可以采样与其它使用功能块网和服务接口功能块的应用类似的方式建模。管理应用需要一定数量的服务接口功能块来处理与外部通信链路的接口。过程需要请求建立功能块实例。更进一步地，服务接口功能块将提供访问外部执行环境，完成管理任务。一个这样的功能块和需要的服务在5.5 节给出。

标准也预计到这样的情形，某些特权的功能单元将控制其它的功能单元。例如，设备A中一个“作业装入”功能块会用来装入新的功能块定义到远程设备B和C ，修改用于某种批量处理的应用。在这样的情形下，需要能够给定某些功能块权限，装入，配置和改变其它功能块的状态。在本章导入的管理应用将明确地需要特权装入和启动完整的应用。

管理应用功能的完整定义已经超出了IEC61499 的范围。然而很明显，以一种一致的方法装入和配置IEC61499 兼容设备是非常重要的。IEC61499 兼容概述文件在IEC61499 Part 4 描述，它需要清晰地定义管理功能如何实现。管理应用和管理功能块的定义提供了需求指南。在8.3 节和附件B 给出更多兼容性概况文件的信息。

2.5.2管理项的操作状态模型（Operational state model of managed entities）

所以，在功能块网络中，IEC61499提出了操作生命周期的概念施加到功能单元，比如设备，资源和功能块。这一操作生命周期可以像公共状态机的形式修改。它清晰地定义所有管理项何时允许事件处理，处理数据和产生输出数据和事件，下面是在不同的状态完成的公共操作。

IDLE：当进入状态IDLE，管理项初始化，例如，功能块的变量设置为缺省值。

RUNNING：在这个状态，管理项完成它的正常操作，对于资源而言，这意味着递交事件，调度功能块执行。对于功能块而言，这意味着根据2.1.2小节展示的执行模型处理输入事件。

STOPPED 当进入这个状态，结束当前触发的执行，之后没有更进一步的执行（功能块完成有一个输入事件触发的动作，不接受更进一步的输入事件）

KILLED 当进入这个状态，当前执行被中断，没有更进一步的执行完成。这将该管理项停留在非法状态。所以，KILL ED 管理项只能被删除和复位到初始状态，以便更进一步使用。

图2.12显示了允许不同状态之间转移的状态机。

2.6 IEC61499 的交换格式

能够在不同软件工具和平台上交换所有IEC61499 的模型是IEC61499标准非常重要一部分。在不同产品和系统之间交换功能块将对最终用户带来明显的好处。这包括在不同的硬件和系统配置中重复使用（reuse）功能块带来的成本节约。IEC61499 提供了两种选择（i）形式化文本格式（ii）利用web技术的XML。

2.6.1 IEC499的文本语法

IEC61499 的明显特性是采用富文本语法以文本形式描述模型，比如应用，系统配置，和功能块。无二义性的文本定义使得自动和明确地产生模型的图形表示。举例来讲，一个应用有若干个具有适当参数，并且链接数据和事件的功能块构成的网络。该应用的所有设计可以使用IEC61499 的文本格式来表示。

可以想象，通过编译文本模型，可以检查模型的正确性。文本语法对于将模型从一个平台移植到另一个平台是有帮助的。它定义了语义，而不是完整详细的图形描述。例如功能块在设计的时候可能放置在某一个位置。在另一个平台上，位置和图形的细节，比如颜色，字体等可能有所不同。但是功能块之间的链接是准确的。

应用实例

这里我们用一个简单的应用来展示文本语法的特性。语法的许多特性我们在后面的章节描述。

考虑一个实现PID 算法来控制一个容器的压力。一个压力传感器提供当前的压力，容器中的压力可以通过一个泵来改变。这能够使用一个有三个功能块构成的应用来建立模型如图2.13 所示。Sensor 功能块提供周期性更新当前压力值，它触发PID 控制器计算所需的泵的值，Actuator 功能块将该值施于泵。该应用实例的文本描述如下：

APPLICATION Controller (* Pressure control loop *)

FBS

Pressure : Sensor(

DT := T#100ms);

Controller : PID(

SP := 1.0,

KP := 2.3,

TR := T#1s400ms,

TD := T#25ms);

Pump : Actuator;

END_FBS

EVENT_CONNECTIONS

Pressure.IND TO Controller.REQ;

Controller.CNF TO Pump.REQ;

END_CONNECTIONS

DATA_CONNECTIONS

Controller.U TO Pump.VAL;

Pressure.VAL TO Controller.PV;

END_CONNECTIONS

END_APPLICATION

在该例中，要注意下面几点：

应用由名称标识，在本实例中是Controller
功能块参数在功能块实例说明时给定
事件和数据链接由不同的组分割，它们分别是EVENT_CONNECTIONS 和DATA_CONNECTIONS,

2.6.2 XML-交换格式

在IEC61131-3 PLC 软件标准中，不同厂商的软件设计的交换能力受到了一系列的限制。这是因为IEC-61131-3 中失败地包括文件交换格式的全定义。在不同的软件工具之间无法交换IEC61131-3 图形化PLC 软件。为了克服这个限制，PLCOpen 组织开发了一个基于XML 的文件交换格式。尽管这个文件格式改善了这样情形。他仍然允许厂商指定扩展，限制了移植。

在IEC61499 发展的早期，这缺点是同样存在的。为了克服这个缺点，在PLCOpen 之前，就考虑将XML 作为可选项。这就是在IEC61499 的Part 2 中使用了基于DTD （Document Type Definitions）格式的XML结构。

XML 格式除了提供IEC61499 模型的结构化特征以外，还包括图形布局信息（比如功能块的位置，链接的转弯点）。这些与厂商中性的（无关）。

应用实例

图2.13 压力控制器的XML 描述如下：

</FB>

</FB>

</FB>

<Connection Source="Pressure.IND" Destination="Controller.REQ"

dx1="247.05882" dx2="0.0" dy="0.0"/>

<Connection Source="Controller.CNF" Destination="Pump.REQ"

dx1="364.70587" dx2="0.0" dy="0.0"/>

</EventConnections>

<Connection Source="Controller.U" Destination="Pump.VAL"

dx1="164.70587" dx2="0.0" dy="0.0"/>

<Connection Source="Pressure.VAL" Destination="Controller.PV"

dx1="364.70587" dx2="0.0" dy="0.0"/>

</DataConnections>

</SubAppNetwork>

</Application>

在这个例中，由下面几点值得注意：

XML 描述的总结构和文本语法相同

文本语法更加简约和可读
XML 表示增加了图形布局信息，在我们的例子中，它提供了功能块的位置，链接的弯曲点（dx1，dx2和y）。这信息不影响功能。

2.7 小结

我们现在已经观察了由IEC61499 导入的主要概念。提供了面向功能块的分布式系统的建模框架和架构。小结如下

IEC61499 的核心元素是功能块。功能块以事件触发的方式执行。这就是说，功能块的执行是由输入事件触发的。
基本功能块和复合功能块处理不同形式的功能块结构和功能块分层结构。
服务接口功能块提供网络通信和其它通信设施。
应用能够通过实例化功能块，互联它们的事件和数据的输入和输出独立于控制硬件地开发，
系统模型定义了一组互连设备。能够通过网络连接相互通信。
设备模型支持支持一个或者多个资源，资源提供对装入，配置，和执行功能块网络。
一个应用可以留驻在一个或者多个资源。每个资源支持一部分应用的装入和配置，每一部分可以是一段分布的功能块网络。
掌握这些模型，IEC61499 控制系统开发工作流程由下面的步骤执行。
1. 通过实例化功能块和连接它们为应用建模
2. 通过指定设备，它们的资源以及设备之间的通信联络为系统建模
3. 将应用分布到控制设备的资源
4. 完成平台特定的参数和插入通信功能块
5. 利用管理接口将分布式应用部署到设备上。
IEC61499 提供两种可移植方式的交换模型
1. 文本语法提供形式化规范方法
2. XML 交换形式，并包含图层信息