写在前面：

本文章是根据 Robert Lewis 所著《Modelling Control Systems Using IEC 61499》翻译、整理而来。碍于本人学识有限，同时并非本专业人士，部分叙述难免存在纰漏，请读者注意甄别。

参考资料：

1. 介绍

背景

目前为止，工业控制系统分成了两大阵营。一类是基于传统的分布式控制系统(DCS)，另一类是基于可编程逻辑控制器（PLC）。

现行的DCS 主要应用于化工厂和炼油厂。它们是由少量的大型中央处理器构成，提供监控和数据采集。通过本地网络和部署在工厂中的众多控制器，仪表，传感器和执行部件相联。

系统可以具有分立的仪表和超级工作站。超级工作站由本地控制器和一串仪表构成。在一个DCS 中，许多的监控来自于一个或者多个中心处理器。工厂中的仪表提供本地的闭环控制，例如PID 控制。
在许多机器控制和生产过程控制中（特别是自动化生产线中），控制系统是使用PLC来设计的。

大型PLC 系统通常由多个PLC ，它们通过一个或者多个特定的高速网络相互通信。PLC 一般连接大量的输入输出（I/O) 信号，由它们处理传感器和执行部件。在这种场合，分立仪表，比如温度，压力传感器也连接到PLC 上。

使用这两种设计方法，系统都倾向编写一个大型单一的软件包。这种软件通常很难在新的应用中重复使用，相互之间集成也非常困难。DCS和PLC 两种系统难以修改和扩展，不能提供高度的灵活性。而这一点却是先进，灵活的控制系统所期望的。

IEC 61499 function block standard

IEC 已经开发了一个专门的标准 IEC61499 ，它定义了如何将功能块（function block）用于分布式工业过程，测量和控制系统。这项工作有助于解决语义集成的问题。

"In industrial systems, function blocks are an established concept for defining robust, re-usable software components. A function block can provide a software solution to a small problem, such as the control of a valve, or control a major unit of plant, such as a complete production line.

Function blocks allow industrial algorithms to be encapsulated in a form that can be readily understood and applied by people who are not software specialists. Each block has a defined set of input parameters, which are read by the internal algorithm when it executes. The results from the algorithm are written to the block’s outputs. Complete applications can be built from networks of function blocks formed by interconnecting block inputs and outputs."

在工业系统中，功能块建立了定义鲁棒性，可重用软件组件的概念。一个功能块能够提供解决小问题的软件解决方法，比如控制阀门。也可以解决一个工厂的主要部件，例如完整的生产线。

功能块允许工业算法封装在一种可理解的形式中，使非软件专家的人士可以使用。每个功能块都有数据输入，供算法执行时读取。算法的结果写入功能块的输出。完整的应用由功能块输入输出互联的功能块网络组成。

现场总线是连接智能现场设备和自动化系统的数字式、双向传输、多分支结构的通讯网络。也就是说基于现场总线的系统是以单个分散的，数字化，智能化的测量和控制设备作为网络的节点，用总线相连，实现信息的相互交换，使得不同网络，不同现场设备之间可以信息共享。

为什么使用功能块？

在面向对象程序设计中的对象在某种程度上类似于功能块。对象的概念之所以成功，是因为它们能够为在真实世界的概念和项目建立行为建模。

使用对象带来的好处：

对象反映现实世界。将与应用程序关联的现实世界实体表示为对象，更为自然和直观

对象是稳定的。通常，对象是经过验证的软件元素，不会发生重大变化

对象降低了复杂性。开发人员可以在不真正理解对象内部如何工作的情况下使用对象。可以通过创建和链接对象来开发应用程序通常不需要了解对象的内部结构

对象是可重用的。一旦一个对象被开发和测试，它就可以成为开发人员的一部分（类库）。

功能块也具有这些特性中的大部分，由此所带来的好处有：

减少了为应用程序开发的控制软件的数量
减少了开发控制系统所需的时间
使用相同类型功能块的控制系统将具有更一致的行为
使得控制系统更易于测试

功能块与对象的联系与区别

Feature	Objects	FBs	Comment
封装数据	✅	✅	对象可能包含同时也是其他对象实例的数据；功能块可能包含其他功能块的实例。
外部接口	✅	✅	在 IEC 61499 中，私有接口和公共接口之间没有区别和事件
调用	对象有含参方法和返回值	FB输入输出变量和事件	在FB中，数据可以与事件同步
继承	✅	❌	目前在 IEC 61499 中没有功能块继承行为的机制
多态	✅	✅	IEC 61499 引入了一个“Adaptor”概念，允许功能块共享公共接口
实例化	对象类和功能块类型是同义的	功能块实例是由功能块类型定义的

2. IEC 61499中的模型与概念

本章将回顾 IEC 61499 中定义的主要模型和概念，以全面了解功能块标准。IEC 61499 的主要目的不是作为一种编程方法，而是作为分布式系统的架构和模型。按照定义，该标准无意直接由编程工具使用。相反，IEC 61499 提供了一组模型来描述使用功能块编程的分布式系统。

本章涵盖的主题包括：

分布式控制系统的系统、设备和资源模型
表示分布式应用程序的模型
功能块的特性及其执行
不同形式的功能块的类型规范
服务接口功能块提供硬件和操作系统的接口
适配器（Adaptor）用于共享块接口
用于定义 IEC 61499 实体的文本语法。

2.1 系统模型

我们将从IEC 61499 中定义的顶层系统模型开始，这定义了通信设备和应用程序之间的关系。

分布式应用程序将被设计为连接功能块的网络。但是，当应用程序加载到系统上时，它通常会作为
一系列功能块网络片段加载到不同的设备中。由各个设备提供的通行服务确保构成应用程序一部分的功能块维护其数据和事件连接。

IEC 61499 系统模型允许设备支持多个应用程序的执行。该标准定义了一种设备模型，可以在不干扰现有应用程序的情况下加载和卸载分布式应用程序；这是通过使用设备内的管理服务来实现的这些将在第 4 章后面进行介绍

2.2 设备模型

一个设备能够支持一个或多个资源。 IEC 61499 中的资源具有与 PLC 编程语言标准 IEC 61131‑3 中定义的资源概念类似的属性。资源提供功能块网络的独立执行和控制。

设备模型有一个“进程接口”，它提供使资源能够与物理设备上的输入和输出 (I/O) 点交换数据的服务。还有一个通信接口，为资源提供通信服务，通过外部网络与远程设备中的资源交换数据。

过程和通信接口的内部结构和行为不在 IEC 61499 的范围内，但它们有望提供一系列服务以支持资源内功能块的执行。

该设备的目的是提供一种基础设施来维持一种或多种资源。功能块网络的片段分布在本地设备或远程设备资源中的资源之间。

2.3 资源模型

该资源提供设施和服务以支持一个或多个功能块应用程序片段的执行。IEC 61499 的主要重点是对每个资源内功能块的行为进行建模。该资源为通信系统和“设备特定进程”提供接口，即与设备紧密相连的外部服务和子系统，例如设备 I/O 子系统。

例如，每个资源都将有一个到通信系统的接口，以允许功能块与远程资源中的块交换数据，以及一个接口来读取和写入本地设备输入和输出（I/O）。

图 2.3 描述了 IEC 61499 资源的主要特征，它显示了一个由数据和事件流链接的互连功能块网络。资源提供的调度功能确保功能块内的算法以正确的顺序执行，即按照事件到达每个功能块的要求。

其中，“服务接口” (Service Interface) 功能块是一种特殊形式的功能块，它提供功能块和资源接口之间的链接。例如，通信 SI 块可用于读取数据或将数据发送到远程资源中的功能块。

资源的一个重要特征是它支持独立操作，不会影响同一设备或网络中的其他资源。

注意 ⚠️：

分布式应用程序的管理可能需要协调控制加载功能块网络片段的许多资源。实现这种协调所需的设施是 IEC 61499 尚未完全解决的问题。

2.4 应用模型

在IEC 61499中，应用被定义为由事件和数据流链接的互连功能块网络。

应用程序可以分散并分布在许多资源上。
在应用程序中，可以使用子应用程序进一步分解。
子应用程序具有功能块的外部特征，但可以包含功能块网络，这些功能块本身可以分布在其他资源上。该标准定义了应用程序分解的“分形”形式，允许在需要时将子应用程序进一步分解为更小的子应用程序。

该应用程序定义了各个块之间所需的事件和数据流之间的关系。分布块的各种资源必须确保事件用于在正确的优先级和时间安排块内的适当算法。

注意，IEC 61499 功能块包含用于定义其完整行为的所有算法和初始化值。

实际上，应用程序是解决特定自动化控制问题的一整套功能块和互连（interconnection）。应用程序由功能块实例和互连定义组成，在某些情况下，它们包括特定块类型的功能块的多个实例。 IEC 61499 的原则是所有行为都根据功能块定义。结果，我们将看到应用程序中没有可以存在于功能块之外的全局或局部变量。这是为基于
IEC 61131‑3 的 PLC 创建的应用程序与 IEC 61499 应用程序之间的重要区别。

2.5 功能块模型

功能块（Function Block）是支持整个 IEC 61499 的核心，其具有自己的数据结构，并且由一个或者多个算法来处理它们。功能块类型（function block type）提供了数据结构和算法的形式化描述。

功能块可以有多个实例（instance）。从形式上看，功能块和面向对象中的对象非常类似。

每个功能块有一个类型名称和一个实例名称。
每一个功能块都有一系列事件输入（Evnet Input）。它们能够接收其它功能块通过事件连接传递的事件。
每个功能块都能有事件输出（Evnet Output）。它们向其它功能块传递事件。
每个功能块会有数据输入（Data Input）。传递给它其它功能块内部产生的数据。
每个功能块会有数据输出（Data Output）。将该功能块内部产生的数据传递该其它功能块。
每个区块都会有一组内部变量，用来保存算法调用之间保留的数值。
事件可以使用 “WITH” 修饰词与数据关联。在图形表示中，将事件和相关联的数据连接线交叉点画一个小方块。
功能块的行为定义为一系列的算法和状态信息。利用块的状态和状态的变化，可以建立各种策略的模型，以定义哪些算法将在响应特定事件时执行。

上图描述了 IEC 61499 功能块的主要特性：

功能块的顶部，称为“执行控制（Execution Control）”部分，在某些情况下包含一个定义，以状态机的形式给出，用于将事件映射到算法；即它定义了下半部分定义的哪些算法在各种事件到达“执行控制”时被触发，以及输出事件何时被触发标准称之为“事件输入、事件输出和算法执行之间的因果关系”。该标准定义了映射到达事件输入的事件、内部算法的执行和输出事件的触发之间的关系的方法，这将在本章后面的部分中讨论。
功能块的下半部分包含算法和内部数据，它们都隐藏在功能块中。功能块是一种软件组件，如果设计得当，
则不需要用户详细了解其内部设计。

功能块依赖于其包含资源的支持来提供设施来调度算法并将请求映射到通信和处理接口。

该标准规定资源可以选择性地提供附加功能以允许访问功能块的内部。显然，在现场总线设备中，能够检查块内的内部变量对于维护或调试目的总是有用的。所以可能有“后门”方法来访问功能块内部；然而，从 IEC 61499 体系结构的角度来看，控制变量和事件仅通过外部公开接口传递。

2.6 功能块类型

IEC 61499 中的一个重要概念是定义功能块类型的能力，该类型定义了可以从该类型创建的功能块实例的行为和接口。这与面向对象软件中对象实例的行为由关联对象的类定义定义的方式同义。
复合功能块和子应用程序类型的内部行为由功能块实例网络定义。因此，该定义包括需要存在于内部功能块实例之间的数据和事件连接。
功能块类型由类型名称、块的输入和输出事件的正式定义以及输入和输出变量的定义定义。

基本功能块类型

基本功能块的行为是根据响应输入事件而调用的算法来定义的。当算法执行时，它们会触发输出事件，以表示块内发生了某些状态变化。事件到算法的映射使用称为执行控制图 (ECC)的特殊状态转换符号来表示。

基本功能块的执行模型

借助下图对基本功能块进行描述，功能块上的编号特征显示了块的不同部分由底层“调度功能”处理的顺序。该模型假设功能块所在的资源提供了一个调度功能，确保功能块执行的每个阶段以正确的顺序和正确的优先级发生。

在下图中有许多离散的时序阶段，每个时序阶段可能需要一段时间才能过去，这是基本功能块执行所必需的；每个阶段都取决于功能块和底层调度功能之间定义的交互。下图描述了基本功能块运行必须顺序出现的8个时序点；每个阶段的结束由特定编号的时间点定义：

$\mathbf{Time_1}$ ：来自外部功能块的值（Data）在功能块输入处稳定
$\mathbf{Time_2}$ ：与输入值（Data）关联的事件（Event）到达事件输入
$\mathbf{Time_3}$ ：功能块执行控制向调度功能发送信号，表明它具有输入值并准备好执行其算法
$\mathbf{Time_4}$ ：在资源的加载和性能特征确定的一段时间后，调度功能开始执行功能块的算法
$\mathbf{Time_5}$ ：该算法处理输入值，在某些情况下，还处理内部存储的值以创建写入功能块输出的新输出值
$\mathbf{Time_6}$ ：算法完成其执行，并向调度函数发出信号以指示输出值稳定并准备就绪
$\mathbf{Time_7}$ ：调度功能调用功能块的执行控制以生成输出事件。根据到达的输入事件和执行控制的内部状态，可能会产生不同的输出事件
$\mathbf{Time_8}$ ：执行控制依次在功能块的输出事件接口上创建适当的输出事件。下游功能块使用输出事件表示它们现在可以使用此块生成的输出值

注意 ⚠️：

这些时序阶段不能重叠，并且必须按功能块正确执行的规定顺序发生。

该标准定义了以下在构建应用程序时非常重要的持续时间：

$\mathbf{T_{setup}}= \mathbf{Time_2} – \mathbf{Time_1}$ ：接收输入值与其关联的输入事件到达之间的时间
$\mathbf{T_{start}}= \mathbf{Time_4} – \mathbf{Time_2}$ ：收输入事件和执行算法之间的时间；这个持续时间可能取决于资源加载，即调度函数的待处理队列中还有多少其他功能块
$\mathbf{T_{algo}}= \mathbf{Time_6} – \mathbf{Time_4}$ ：功能块算法开始和完成之间的时间
$\mathbf{T_{fin}}= \mathbf{Time_8} – \mathbf{Time_6}$ ：从完成算法到引发输出事件的时间

在不同的实现中，可能需要多种机制来确保功能块能够使用一致的数据来执行。例如，重要的是输入数据值在算法执行时保持稳定。该算法应该只使用在输入事件到达时存在的输入值，即输入事件可用于快照准备算法执行的输入值。

复合功能块类型

复合功能块和子应用程序类型的内部行为由功能块实例网络定义。因此，该定义包括需要存在于内部功能块实例之间的数据和事件连接。

服务接口功能块类型

服务接口 (SI) 功能块提供功能块域和外部服务之间的接口，例如与远程设备中的功能块通信或读取硬件实时时钟的值。因为 SI 功能块类型主要与数据事务有关，所以它是使用时序图定义的。这种形式的图更常用于定义跨通信接口的事务。时序图将在本章后面的服务接口块部分进行描述。

2.7 分布式模型

应用程序和子应用程序都可以“分布式”，即配置为在多个资源上运行。分布式应用程序将由功能块网络组成，功能块的片段在指定资源上运行。请注意，IEC 61499 认为分布涉及不同资源上功能块的排列。因为一个设备可以支持多种资源，所以分布式应用程序可以在单个设备上运行，即使用同一设备内的资源。子应用程序是一种较小的应用程序形式，可以复制，但在其他方面具有与应用程序相同的分布特征。

功能块和应用程序之间存在重要区别。

应用程序或子应用程序的时间和性能将取决于它所分布的资源以及连接它们的通信网络。如果两个网络的通信数据速率差异很大，因此两个子应用程序显然会由于网络延迟而具有不同的性能和响应时间，尽管它们的内部软件算法是相同的。
相反，功能块被假定为“原子的”并且仅在单个资源中运行。在这方面，功能块的性能不受通信网络特性的影响。但是，性能可能会在较小程度上受到实例化块的资源和设备的行为和特性的影响。下表总结了这些分布特征。

	Distributable	Timing	Reliability	Replication
Function Block	❌	只依赖于设备	只依赖于设备	FB类型的实例
Sub-Application	✅	依赖于设备和通讯	依赖于设备和通讯	子应用类型的副本
Application	✅	依赖于设备和通讯	依赖于设备和通讯	无

2.8 管理模型

在上面我们说到，资源可以支持构成分布式应用程序或子应用程序的一部分的功能块网络片段。但这些应用程序分段如何被创建和管理？

为此，IEC 61499 还定义了一种特殊形式的应用程序，称为“管理应用程序（Management Application）” ，负责在资源内创建功能块网络。管理应用程序具有比普通应用程序更高的特权功能，可以通过创建功能块和连接来构造其他应用程序的一部分。它通常会通过通信链路与远程编程站等外部代理进行交互。

管理应用程序的功能将包括：

在一个资源中创建功能块实例
将功能块片段与一个特定的应用程序联系起来
在功能块和服务接口块之间建立数据和事件连接
作为分布式应用的一部分启动功能块的执行
提供服务以支持从通信链路上查询功能块实例的状态功能块实例的查询
删除功能块实例以及它们的数据和事件连接。

一个重要的约束是管理应用程序应该能够为不同的应用程序加载功能块网络片段，而不会干扰其他正
在运行的应用程序的执行。

管理应用程序的一部分可能将以非易失性形式存在于设备中，并且总是能够在设备加电时加载应用程序。

该标准提出了两种提供管理应用程序的方案：

下图描绘了一个具有特殊“管理资源”的设备，该资源包含管理应用程序，这些应用程序提供在设备中提供的相邻资源中建立和维护功能块网络的功能。
在图2.9中，定义了另一种方案，即每个资源包含一个管理应用程序，负责在同一资源中加载功能块网络。
管理应用程序的建模方式与其他使用功能块网络和服务接口功能块的应用程序的建模方式完全相同。一个管理应用程序很可能需要一些服务接口功能块来处理与外部通信链路的接口，例如，处理创建功能块实例的请求。

管理应用程序的功能尚未在IEC 61499中详细定义，但显然这是一个需要标准化的重要领域，然后才能以一致的方式加载和配置符合IEC 61499的设备。统一的方式加载和配置IEC 61499兼容的设备。

2.9 运行状态模型

基于 IEC 61499 功能块网络的大型系统通常会分几个阶段进行开发、调试和投产。因此，在功能块网络中，IEC 61499 提出“生命周期”的概念被建模并应用于功能单元，例如设备、资源和应用程序。

操作状态模型尚未在标准中完全定义，但建议每个功能单元都有明确定义的状态，例如：

$\mathbf{STOPPED}$ ：单元未运行
$\mathbf{LOADED}$ ：单元已加载，例如，当应用程序的所有功能块定义和相关功能块实例已加载到设备中时，设备可能处于“已加载”状态
$\mathbf{CONFIGURABLE}$ ：单元已加载并准备好在开始运行之前进行配置；当功能块实例已加载但仍
等待功能块连接详细信息时，设备将处于“可配置”状态
$\mathbf{OPERATIONAL}$ ：单元已加载和配置并准备好开始执行或支持执行部分加载的应用程序
$\mathbf{RUNNING}$ ：装置完全可操作并正在运行

为了控制和同步分布式应用程序的加载，该标准建议制定策略以确保“跨组件的一致操作状态”。

例如，分布式应用程序可能需要将功能块网络的片段加载到位于各种不同的（在某些情况下）远程设备中的许多不同资源上。驻留在不同设备中的功能块的加载和配置可能发生在不同时间；但是，可能需要同步所有关联设备和资源从“运行”状态到“运行”状态的切换，才能使应用程序正确启动。

该标准还预见到某些特权功能单元可能会控制其他功能单元的情况。

例如，设备 A 中的“作业加载器”功能块可用于在远程设备 B 和 C 中加载新的功能块定义，以便为特定类型的批处理配置文件修改应用程序。在这种情况下，需要能够赋予某些块加载、配置和更改其
他块状态的权限。本章已经介绍的管理应用程序功能块显然需要具有特殊权限才能加载和启动完整的应用程序。

应用程序管理和应用程序操作状态的控制是 IEC 61499 中仍有待开发的领域，可能会在该标准的其他部分中解决。

2.10 使用适配器的通用接口

面向对象软件的一大优势是能够让不同的对象共享相同的接口。在面向对象软件中，表示具有相似基本特征的实体的对象具有共同的外部接口部分是一种普遍的做法。例如，在设计图形用户界面 (GUI) 时，具有相似特征的图形实体（例如表示圆和正方形的对象）通常具有通用的接口方法（表示正方形和圆形等项目的对象可能有许多共同的方法，例如用于调整大小、移动、复制和颜色填充）。

面相对象软件中的行为共享是通过一种称为“继承”的技术实现的。这允许新的专用对象“继承”，即共享来自另一个更通用类型的对象的相同接口和基本行为。拥有具有通用接口的不同类型的对象在软件设计中具有显着的优势。

一个很好的例子是处理具有相似特性的传感器的功能块。我们可以设想块处理模拟传感器，比如温度和压差，在它们的接口中有一些共同的特征。例如，两者都需要能够设置高低警报级别，并检测超出范围的情况。能够使用相同的软件来处理不同类型传感器的功能块的共同方面显然是有用的。

为了促进对通用接口的支持，IEC 61499 定义了一个称为“适配器接口”的特殊概念。这允许具有相似行为的功能块通过附加特殊类型的功能块来共享相同的接口。

这种类型的功能块称为“适配器”。它类似于可以连接到其他设备的电子设备，这些设备使用插头和插座布置提供专门的行为。图 2.10 以图形方式描述了这个概念；该图的左侧显示了能够与其上方的专用块紧密连接的适配器块；在右侧，我们看到两个块连接在一起形成适配器连接。

为了进一步阐明使用适配器的好处，考虑功能块的设计来处理各种形式的模拟输入。

让我们考虑一个块来处理温度输入，另一个块来处理差压输入。显然，每个块都需要自己专门的接口输入和输出。温度块将需要输入来定义热电偶范围、校准偏移、缩放等，而差压输入将需要专门的输入和输出来定义压力滞后和压力传感器特性。

但是，这两个块也将具有一系列通用的输入和输出。只需考虑警报定义和创建的要求；将报警处理的标准实现封装在一个块中显然会更加高效和一致。图 2.11 描述了如何使用适配器概念为警报管理提供一个公共块，该公共块可以连接到具有特定行为和不同类型传感器接口的专用块。

在 IEC 61499 中，功能块可以配置为适配器“提供者（Provider）”或“接受者（Acceptor）”。在我们的示例中，警报块 Alarm 被描述为适配器“提供者”，而传感器专用块“Temperature”和“Diff_Pressure”是适配器“接受者”。

请注意，可以用不同的方式对常见行为进行建模。在此示例中，也可以将通用传感器块作为具有所有共享行为的适配器接受器，然后将专用块附加为适配器提供者以提供传感器专业化。

2.11 IEC 61499 实体的文本语法

IEC 61499 标准的一个显着特征是丰富的文本语法（textual syntax），允许以文本语言描述应用程序和功能块等实体模型。文本定义可用于明确定义模型，以便可以自动且一致地创建图形表示。

例如，一个复合功能块可以由几个具有适当数据和事件连接的较小块组成的网络构成。复合块内部设计的所有方面都可以使用 IEC 61499 文本句法表示。

可以设想，编译文本定义作为检查特定模型有效性的手段是可能的。文本形式对于将模型设计从一个工作站平台移植到另一个工作站平台当然很有用。它定义了模型的语义方面，但没有完全描述图形细节。

注意 ⚠️：

在 IEC 61499 标准的第 2 部分中，可以使用基于 XML 的文件交换格式来传输图形属性。这在第 7 章中进行了回顾。

例如，可能已经开发了一个特定的模型，显示位于网络图中某些位置的功能块。实际位置和更精细的图形细节（例如颜色和字体）不是此语法的一部分。但是，块之间的逻辑连接是精确定义的。

该标准包含一个详尽的附件，描述了文本句法所有特征的生成规则。请注意，此语法的某些方面将在本书中进行描述，但对于完整和准确的定义，建议参阅 IEC 61499标准第 1 部分中的附录 B

【示例】- 3选2投票算法

这里使用一个简单的功能块来说明文本语法的一些特性。语法的许多特性将在后面的章节中进行更详细的讨论。

考虑一个功能块，它在三个输入 A、B 和 C 上应用“3 选 2 投票”算法。这可以建模为“基本”功能块，如下所示：

该块有两个事件输入，Reset 和 Vote。

Reset 事件会触发一种算法来重置存储的选民内部状态。当 Reset 算法成功完成后，在 Ready 输出端产生一个事件。
Vote 事件用于触发主投票算法，该算法检查三个布尔输入 A、B 和 C 的状态。如果两个或多个输入为真，则输出状态设置为真并保持为真，直到执行 Reset 算法。当选举算法完成后，将在 Voted 事件输出中生成一个事件。

描述 Voter 功能块的文本语法（textual syntax）如下：

FUNCTION_BLOCK VOTER (* Voter FB *)

EVENT_INPUT
	Reset; (* Reset event *)
	Vote WITH A,B,C; (* Trigger Voter *)
END_EVENT

EVENT_OUTPUT
	Ready;
	Voted WITH State;
END_EVENT

VAR_INPUT
	A : BOOL;
	B : BOOL;
	C : BOOL;
END_VAR

VAR_OUTPUT
	State : BOOL;
END_VAR

EC_STATES
	Ready : ResetAlg -> Ready;
	Voted : VoteAlg -> Voted;
END_STATES

EC_TRANSITIONS
	Ready TO Voted := Vote;
	Voted TO Voted := Vote;
	Voted TO Ready := Reset;
END_TRANSITIONS

ALGORITHM ResetAlg IN ST; (* Reset Algorithm *)
	State := 0; (* Reset the state output *)
END_ALGORITHM

ALGORITHM VoteAlg IN ST; (* Voter algorithm *)
	IF State = 0 THEN
		State := (A AND B) OR (A AND C) OR (B AND C);
	END_IF;
END_ALGORITHM

END_FUNCTION_BLOCK

从这个例子中可以看出以下几点：

文本定义包括 EVENT_ 和 VAR_ 部分，用于声明块的输入和输出接口的所有事件和数据
块的内部状态被定义并与触发状态转换的事件相关联；这是在 EC_STATES 和 EC_TRANSITIONS 部分中声明的
当块处于块定义的 EC_STATES 部分中定义的特定状态时，算法由事件触发
每个算法都可以用特定的文本语言定义。在本例中，ResetAlg 和 VoteAlg 算法都是使用结构化文本 (ST) 语言定义的；这是 PLC 编程语言标准 IEC 61131‑3 中定义的高级语言。但请注意，IEC 61499 并不排除使用其他语言（例如 JAVA 或 C）来定义算法内容。事实上，IEC 61499 并没有定义算法定义的文本语法，而是允许使用任何现有的标准文本语言。

2.12 总结

我们现在已经回顾了 IEC 61499 引入的主要概念，这些概念提供了一个框架和体系结构来为面向功能块的分布式系统建模。

总结一下：

系统模型定义了一组可以通过网络连接进行通信的互连设备。
设备模型支持一种或多种资源，这些资源为功能块网络的加载、配置和执行提供支持。
应用程序可以驻留在一个或多个资源上。每个资源可以支持应用程序的一部分的管理和执行，每个部分作为功能块网络的一个片段分布。
有基本功能块和复合功能块，用于处理不同形式的块构造和块层次结构。
服务接口块提供网络通信和硬件接口设施。
适配器概念允许功能块共享通用接口。
IEC 61499 文本句法为移植和创建功能块和应用程序等实体的定义提供了一种简洁且可编译的形式。

3. 定义功能块和子应用程序类型

在本章中，我们将回顾如何为功能块和子应用程序创建类型定义，并展示如何使用这些定义来创建功能块实例和子应用程序的副本。

具体我们会：

查看不同形式的功能块定义
显示如何定义事件和数据接口
检查算法是如何构建的以及如何与事件执行相关联
考虑功能块实例的行为方式
查看可以使用子应用程序的位置，并将它们的行为和属性与复合功能块进行比较。

3.1 类型与实例

在继续定义 IEC 61499 中提供的机制以更详细地定义功能块类型之前，让我们回顾一下功能块类型和实例的作用。

功能块类型定义描述了特定类型功能块的外部接口和内部行为。
然而，功能块实例实际上是使用功能块类型定义创建的功能块的工作副本。

在大型系统中，功能块类型定义很可能保存在各种库中，用于“控制算法”、“警报管理”、“输入传感器”等目的。基于大型功能块的系统的配置将需要选择合适的功能块类型库，然后根据所选功能块类型声明功能块实例。因此，功能块类型的清晰、精确和明确的定义与有效使用 IEC 61499 密切相关。

3.2 不同形式的功能块

该标准为三种不同形式的功能块提供了类型定义；每种形式都有自己特定的属性和用途，如下表中所列。

形式	是否可分布化	定义	注释
基本功能块 Basic FB	❌	使用执行控制图 (ECC) 定义的状态。使用适当语言定义的算法，例如结构化文本，Java。	基本功能块不能分布化；它只能在单个资源上运行。基本功能块定义了可以构建大型复合块的基本块。
复合功能块 Composite FB	❌	由基本功能块和复合功能块组成的网络构成。定义是根据功能块之间的数据和事件连接给出的。	复合功能块是从较低级别功能块的网络构建的。这些可以是基本的或较低级别的复合块。
子应用 Sub-App	✅	由基本功能块和复合功能块组成的网络构成。一个子应用程序又可以包含更小的子应用程序的副本。	这种类型的块旨在提供可以分布在许多资源上的应用程序的可重用部分。

这三种形式的主要特征如上图 3.1 所示。应该注意的是，

基本功能块和复合功能块始终驻留在单个资源上，并在其输入和输出处提供变量以保存数据值。
基本块还需要用于执行控制状态机的内部存储。
然而，相比之下，子应用程序并没有专门存储输入、输出和事件。对于子应用程序，此类存储由存在于子应用程序主体中的内部功能块提供。

3.3 基本功能块的定义

基本功能块（Basic FB）可以使用 IEC 61499 文本句法以文本方式或图形方式进行描述。

有两种图形表示形式共同描述了基本功能块的属性和行为：(i) 外部接口声明和 (ii) 定义事件、状态和算法执行之间关系的执行控制图 (ECC)。

对外接口声明

如图3.2所示的对外接口声明具有以下特点：

功能块类型名称应位于主块的中心，如图3.2 中的“Ramp”所示。
块的输入始终显示在块的左侧；***输出***显示为来自块的右侧。
输入事件被描述为进入块上部的左侧，输出事件显示为来自右侧。
输入和输出变量的名称显示在块内与其关联的图形连接器旁边。
输入和输出的数据类型显示分别在图形连接器的左侧和右侧

图形表示提供了足够的信息以用作正式的类型声明。事实上，IEC 61499 的主要目标是图形表示始终具有精确的文本表示。设想图形建模工具将始终能够将图形形式转换为文本表示，反之亦然。

【输入事件】：例如图 3.2 中描绘的 E_Init 事件，显示为进入功能块标题，如果需要，可以与一个或多个输入相关联。如果模块需要在运行内部算法之前对输入值进行采样，这通常是必需的。在 Ramp 功能块示例中，无论何时发生 E_Init 事件，即在块初始化的瞬间，输入X0、X1、Cycle 和 Duration 都需要保持稳定。同样，当 E_Run 事件发生时，PV 输入值将被采样。
【输入事件与输入数据的关联】使用 IEC 61499 表示为 WITH 限定符的构造。在图形表示中，这使用将事件与其关联数据链接的小正方形显示。

也可以将输出事件与某些输出变量相关联。这用于表示那些已由内部算法更新并在触发输出事件时准备就绪的输出变量。在图 3.2 的基本功能示例中，当内部斜坡算法更新输出 Out 和 Hold 时，会发生 E_Ex0 输出事件。
【事件】可以定义为具有可选的事件类型。这是为了让功能块可以设计为仅在其事件输入处接受特定类型的事件。事件类型提高了设计的鲁棒性。这是对数据类型用于提高设计完整性的方式的逻辑扩展，仅允许连接携带兼容数据的输入和输出。
【初始化事件】：例如，不可能将 E_stop 类型的关闭事件连接到此事件输入。
如果未给块事件输入或输出指定事件类型，则应用默认类型 EVENT。这种通用类型 EVENT 的事件可以连接到 EVENT 类型的任何其他事件输入。相反，EVENT 类型的事件输入可以接收任何事件类型的事件。

注意 ⚠️：

基本功能块的每个输入和输出必须分别与至少一个事件输入或输出相关联。

这是因为，当输入值被采样或输出值发生变化时，总是需要至少一个事件来发出信号。另一种查看方式是将事件及其关联数据视为一种消息类型，允许事件及其数据作为连贯集在块之间传递。

基本功能块行为的一个重要方面涉及对事件和算法执行之间的关系进行建模。这是使用称为执行控制图(ECC)的概念实现的。与块的其他功能一样，ECC 可以图形方式或文本方式定义。此功能的一个结果是暗示块必须具有存储空间来保存事件样本之间的输入值。同样，它有存储空间来保存输出事件触发之间的输出值。当然总是有这样的可能性，一个块可能以比块可以存储然后处理更快的速率接收带有数据的事件。该标准规定，在这种情况下，底层调度功能应优先考虑功能块算法的执行，以确保此类过载情况不会发生。

内部行为

基本功能块内部行为的描述有两个方面：算法体和算法执行控制。

基本块通常包含一种或多种算法。每个算法都由资源调度功能调用，以响应到达块接口的特定输入事件。

当算法执行时，它处理来自输入和内部变量的数据，为内部和输出变量创建新值。
当算法完成其执行的某些阶段时，它可能会触发输出事件以表示输出数据已准备就绪并且可以被其他块“使用”。

每种算法都必须触发至少一个输出事件，以表明它已完成执行。

IEC 61499 没有定义应该用于算法定义的语言。只要可以在输入和输出数据变量及其数据类型和算法语言内的变量之间定义映射，就可以使用任何高级语言。

基本功能块行为的一个重要方面涉及对事件和算法执行之间的关系进行建模。这是使用称为执行控制图(ECC)的概念实现的。与块的其他功能一样，ECC 可以图形方式或文本方式定义。ECC 是一种状态转换图，与 IEC 61131‑3 中的图形顺序功能图有许多相似之处。然而，作为一种状态建模技术，它的目的非常不同，不应与 SFC1 等图形编程语言混淆。

每个基本功能块都需要一个 ECC 来定义以下内容：

块的主要内部状态；
块将如何响应每种类型的输入事件；
响应输入事件激活哪些算法；
执行算法时触发哪些输出事件。

下图3.3是一个执行控制图（ECC），其描述了我们之前讨论过的 “Ramp” 功能块。在该 ECC 中描述了三个状态 START、INIT 和 RAMP，他们对应功能块中的三个主要状态：

“START”状态表示块在等待接收事件时的静止状态。

当模块运行初始化算法“ALG_INIT”时，会出现“INIT”状态。

在“ramping”算法运行时存在“RAMP”状态，即“ALG_RAMP“

状态之间的转换由布尔表达式描述，涉及事件变量和在功能块主体内声明的布尔变量。事件变量提供输入事件的内部表示，并用于描述状态之间的转换。表 3.2 列出了此示例 ECC 的转换条件。

FROM state TO state Transiton

START INIT E_Init (event)

INIT START 1 (always true)

START RAMP E_Run (event)

RAMP START 1 (always true)

在此示例中，“INIT”和“RAMP”是仅在算法执行时存在的瞬态。在更复杂的块中，状态可以表示块的基本状态或模式。

FROM state	TO state	Transiton
`START`	`INIT`	`E_Init` (event)
`INIT`	`START`	`1` (always true)
`START`	`RAMP`	`E_Run` (event)
`RAMP`	`START`	`1` (always true)

执行控制图（ECC）功能

该标准定义了一系列适用于执行控制图（ECC）的规则和功能，总结如下：

一个基本功能块只有一个执行控制图，它是使用功能块类型定义的执行控制块部分中的文本句法定义的；
每个 ECC 必须有一个初始状态，在图中使用两个同心圆（本书中用矩形表示）表示；
圆形和矩形都可以用来表示 ECC 内的状态（本书中用矩形表示）；
ECC 可以使用事件变量作为事件输入。通常，状态之间的转换由使用事件输入变量的逻辑表达式来定义；
ECC 还可以测试或修改事件输出，同样在 ECC 内部表示为布尔事件输出变量；
ECC 也可以测试但不修改在功能块体内声明的布尔变量。这使得 ECC 的行为可以根据功能块主体的内部状态来修改。

例如，一个功能块可能有两种主要模式，如 "手动 "和 “自动”，由一个内部布尔变量 “ManualFlag” 定义。在一个特定的输入事件到来时，ECC 可以测试 “ManualFlag” 并进入适当的状态以调用手动或自动算法。
触发 ECC 内部状态变化的过渡表达式通常涉及输入事件变量。然而，这些表达式也可以包括代表输出事件的变量、功能块内部状态，以及基于块的主要输入和输出变量值的条件表达式。
每个 ECC 状态可以有零个或多个动作。作为一个例子，图 3.4 描述了一个状态 “MAIN”，它有两个动作来调用算法 “CALC” 和 “FILTER”；当它们完成执行时，分别触发输出事件 “ExO_1” 和 “ExO_2”。每个动作通常与一个算法和一个输出事件相关。

当状态被激活时，为该状态定义的所有动作都会被执行。然而，一个动作可以有一个空的算法，它只需要触发一个输出事件。也有可能出现没有输出事件的动作。通常情况下，一个状态至少会有一个具有输出事件的动作，以向外部世界发出信号，表明某些输出已经被更新。

注意 ⚠️

只有在转换之前的状态处于活动状态时，才会测试 ECC 内的转换条件。因此，即使一个功能块可能有一个非常复杂的 ECC，在状态之间有大量的转换，测试转换所涉及的开销可能很小，因为在任何时候只有一个状态是活动的。

ECC 主要用于表示输入事件、算法执行和输出事件触发之间的关系。它不应用于对应用程序状态行为进行建模，例如对各种控制模式进行建模。应用程序状态和相关行为应在功能块算法本身中定义。对于大多数相当复杂的功能块，ECC 应该相对简单，只有四五个状态。

文本语法（Textual syntax）示例

我们依旧以之前讨论的 “Ramp” 功能块为例，考虑其行为，使用 IEC 61499 标准对其进行建模。

该功能块将输出“OUT”从输入“X0”给出的初始值“ramp”到目标值在“Duration”输入给定的时间内为“X1”。
“Cycle”输入定义了"ramp"输出更新之间的经过时间。
该块还检查输出是否超过输入“PV”，在这种情况下，“Hold”输出设置为真。假设 “ramp” 块以“Cycle”时间给定的更新速率重复调用；例如，它可能被配置为每 200 ms 执行一次。

我们已经回顾了这个基本功能块的两个图形视图：（i）图形功能块类型声明（见图3.2）和（ii）执行控制图 ECC（见图3.3）。这两个图中给出的信息也可以用 IEC 61499 文本语法来表示，它与使用 IEC 61131-3 结构化文本语言（ST）表达的算法一起提供了“Ramp”块的完整文本定义，如下所示：

FUNCTION_BLOCK Ramp
	(* Ramp function block type definition *)
	
EVENT_INPUT
	E_Init WITH X0,X1,Cycle,Duration;
	E_Run WITH PV;
END_EVENT

EVENT_OUTPUT
	E_Rdy;
	E_Ex0 WITH Out,Hold;
END_EVENT

EC_STATE
	START; (* Initial state *)
	INIT: ALG_INIT -> E_Rdy;
	RAMP: ALG_RAMP -> E_Ex0;
END_STATES

EC_TRANSITIONS
	START TO INIT := E_Init;
	INIT TO START := 1;
	START TO RAMP := E_Run;
	RAMP TO START := 1;
END_TRANSITIONS

VAR_INPUT
	X0 : REAL;
	X1 : REAL;
	Cycle : TIME;
	Duration : TIME;
	PV : REAL;
END_VAR

VAR_OUTPUT
	Out : REAL;
	Hold : BOOL;
END_VAR

VAR
	T : TIME; (* Time into Ramp *)
END_VAR

(* Algorithm definitions *)
ALGORITHM ALG_INIT IN ST:
	T := T#0s;
END_ALGORITHM

ALGORITHM ALG_RAMP IN ST:
	IF T < Duration THEN
		OUT := X0 + (X1-X0) * TIME_TO_REAL(T) / TIME_TO_REAL(Duration);
		T := T + Cycle;
		Hold := PV > Out;
	END_IF;
END_ALGORITHM

END_FUNCTION_BLOCK

“Ramp”功能块在上述类型声明中被完全定义。在初始化事件 “E_Init”到来时，描述“ramp”行为的输入值，即 X0，X1 ，Duration 和 Cycle。
“INIT”状态被激活，导致初始化算法“ALG_INIT”被调用。这就重置了内部定时器变量 “T”。当初始化算法结束时，输出事件“E_rdy”被触发，如 EC_STATE 声明中所定义。
同样，当收到运行事件“E_Run”时，会发生向状态“RAMP”的转换，导致“ALG_RAMP”算法运行。这个算法根据X0、X1、Cycle 和 Duration 的值以及进入 RAMP 的时间 T 来计算 OUT 的新输出值。该算法还检查输出是否超过了“PV”的输入值，在这种情况下，输出“Hold”被设置为真。

基础功能块实例的行为

使用文本或图形声明，都可以定义从基本功能块类型定义中创建的实例。一个基本功能块类型的实例将具有由其类型定义所定义的行为，但它将有自己的输入和输出变量、事件变量和保持其 ECC 状态的存储。换句话说，每个基本函数实例的状态是完全独立于其他实例的。
声明了基本功能块的资源，将在第一次激活该功能块之前初始化每个基本功能实例。这种初始化包括以下内容：

每个输入、输出和内部变量的值被设置为在块类型定义中给出的声明中定义的初始值。如果没有给出初始化值，将采用特定数据类型的默认值。例如，没有定义初始值的布尔输入将总是被初始化为 “FALSE”，这是布尔变量的默认初始值。
在 ECC 中使用的所有事件输入和输出变量将被初始化为 “FALSE”。
算法的内部状态将被初始化。例如，如果一个算法是用 IEC 61131-3 顺序功能图（SFC）语言定义的，那么该算法将被重置，以便它在 SFC 初始步骤中开始。
实例 ECC 的初始状态将被设置为激活；ECC 内的所有其他状态将不激活。

算法的执行

该标准非常精确地定义了到达功能块事件输入的事件触发 ECC 内状态变化的方式，然后反过来引起资源对功能块算法的调度。这一行为的主要方面总结如下：

该资源存储和更新事件变量，以记录输入事件在功能块实例接口处的到达；
然后，该资源只允许在 ECC 内改变状态，如果： (a) 已收到输入事件，(b) 从当前活动状态（即从过渡的前身状态）开始的过渡条件得到满足，© 当前状态下的行动所调用的所有算法已停止执行。

这种 IEC 61499算法执行模型的一个后果是，如果在算法执行之前或期间，一个输入事件有多次出现，该事件可能会丢失。由于这个原因，在标准中指出，资源应该提供检测这种过载条件存在时的手段，并采取适当的行动来恢复错误。

注意 ⚠️

通过各种手段，应该总是可以创建一个避免事件过载的模型；例如，通过创建块来提供事件和数据队列，或者通过将加载信息反馈给上游块来修改事件输出生成率。

基本功能块实例的执行控制图（ECC）在任何时候都可以处于与资源调度功能有关的三种主要状态（Idle、Scheduling_algo 和 Waiting_for_algo_complete）之一。这些状态形成了一个简单的状态机，如下图 3.5 所示，并在下表中描述。

State	Condition	Notes
$S_0$	Idle	在这种状态下，区块中没有任何东西正在执行或待执行。该区块正在等待输入事件的到来。
$S_1$	Scheduling algorithms	当处于状态 $S_1$ 时，资源已经检测到一个输入事件的到来，并将在其他当前活动的或其他区块的更高优先级的算法结束后安排该区块的算法。
$S_2$	Waiting for algorithms to complete	该资源已经开始执行该区块所选择的算法，现在正在等待，直到该算法结束。

资源调度功能对与这些状态之间的变化相关的转换进行以下操作：

$S_0$ 到 $S_1$ 与到达的输入事件相关的输入事件变量被设置为真，任何与使用’WITH'结构的事件相关的输入变量被采样并存储在块内。
$S_1$ 到 $S_2$ 资源安排块的算法运行，即资源开始执行与新的活动 ECC 状态相关的算法。在算法执行期间，各种输出事件变量可能被设置为 “TRUE”。在这段时间内，算法通常会更新各种输出变量的值。
$S_2$ 到 $S_1$ 该资源检测到算法已经完成执行。
$S_1$ 至 $S_0$ 该资源触发与算法执行期间设置的输出事件变量相关的输出事件。所有被定义为 "WITH "特定输出事件的输出变量现在都可以被外部连接的块采样。

当回到 $S_0$ 空闲状态时，输入事件变量也会被清空。
返回到 $S_0$ 空闲状态时，输入事件变量也被清除，为新事件的到来做好准备。

一个资源实际执行一个基本功能块的特定算法的方式在某种程度上是 “取决于实现（implementation-dependent）”的。如前所述，一个算法可以用各种语言来表达，因此它的行为不被认为是在 IEC 61499的范围内。然而，算法的实现应具有以下特点：

输入和输出变量以及事件变量应准确无误地映射到算法中的变量。
算法应该被封装，以至于它只能在功能块体内读写变量。
相对于将触发其执行的事件的预期到达率而言，算法的执行时间应该很短。显然，如果一个算法被设计为每 100 毫秒执行一次，并且要使用 100 毫秒的时钟事件来触发，那么它最坏的情况下的执行时间应该远远低于 100 毫秒，以便让其他算法执行。
该算法应该有一个明确的初始状态，当该块第一次被资源准备好执行时，它可以进入这个状态。

3.4 复合功能块的定义

复合功能块提供了一种方法，可以从基本功能块和其他较小的复合功能块中分层次地建立起更复杂的功能块。

$复合功能块 = 基本功能块之间/或与其他复合功能块之间的组合$

复合功能块的类型定义包含对选定类型的功能块实例的声明，这些实例通过数据和事件连接被连接起来。该标准将在复合块中使用的块视为组件功能块。组件块之间的数据连接定义了块输出到输入之间的数据值传输，而事件连接定义了块内算法的执行顺序。

复合块类型规范的规则

关于复合功能块类型定义的规范有一些规则和限制，特别是关于外部事件和数据输入和输出与内部组件块的连接。

这些规则的产生是因为事件不能直接被扇出 $^*$ （fanned-out）；也就是说，在事件输出和事件输入之间必须有一对一的连接。通过使用 E_SPLIT 功能块可以使一个事件产生多个并发的事件；这是第五章中讨论的IEC 61499的特殊事件功能块之一。相比之下，数据输入可以是扇形的，即允许一个数据输出来驱动许多不同的数据输入。

扇出系数 $^*$ （英语：Fan-out）是电子技术中表明逻辑门带负载能力的一个量度，其定义为一个逻辑门电路能驱动与之同类逻辑门的个数。大多数晶体管—晶体管逻辑（TTL）门能够为10个其他数字门或设备提供信号。因而，一个典型的晶体管—晶体管逻辑门有10个扇出。

（资料来源维基百科）

事件连接的规则

每个复合事件输入必须正好连接到内部组件功能块的一个输入事件，或者必须“通过路由（through routed）”到复合块的事件输出。也就是说，事件输入不可能直接连接到不同组件块的多个事件输入。

如果需要，E_SPLIT 等事件功能块可用于从单个输入事件中创建扇出事件，见第5章。

每个组件的事件输入端必须准确地连接到一个组件输出事件或一个复合块事件输入端。
类似地，组件功能块的每个事件输出只能精确地连接到一个组件输入事件或一个复合事件输出。
每个复合块的输出事件必须正好与一个组件的输出事件相连接，或者直接来自一个复合输入事件。

注意 ⚠️

一些组件块的输入和输出事件可能保持不连接。在这种情况下，仅与未连接的输入事件相关的算法将不会被执行。

数据连接的规则

以下规则适用于复合块数据输入和输出与组件输入和输出之间的连接。

复合块的每个数据输入可以
- 连接到内部组件块的一个或多个数据输入，
- 或直接连接到一个或多个复合功能块的输出，
- 或同时连接。
每个组件块的数据输入可以是
- 不连接，
- 或连接到一个其他组件块的输出，
- 或连接到复合块的数据输入。
显然，该标准不允许一个成分块输入连接到多个输出，因为这样输入就会有一个不确定的值。
每个组件块数据输出可以
- 不连接，
- 或连接到一个或多个组件数据输入，
- 也可以连接到一个或多个复合数据输出。
每个复合块数据输出必须连接到
- 一个组件数据输出，
- 或从一个复合数据通过通过路由（through routed）的方式输入。

复合块示例

考虑一下图 3.6 中描述的功能块例子，它被选来演示复合功能块的许多特性。

该图显示了一个复合块的图形主体，它被描绘成一个连接在一起的功能块网络，形成一个新的块。在这个例子中，一个额外的比较类型的组件功能块和事件功能块 E_MERGE 被用来扩展“Ramp”功能块的功能，形成一个“Sawtooth”发生器。

注意 ⚠️

Ramp1 是 Ramp 基本块的一个实例，如本章前一节所述。每个组件块的实例名称就显示在图形主体中每个块的轮廓上方。

这个新块的外部接口如图 3.7 所示。

注意 ⚠️

它的外观与基本功能块相同。事实上，从外部角度来看，仅仅从一个块的外部接口是不可能区分出基本块和复合块的。

现在我们将回顾这个块的行为，并说明它是如何被模拟成一个复合功能块的。

这个块的目的是提供一个输出值，如图 3.8 所示，遵循一个 “sawtooth”曲线，即重复地将输出从 0.0 “ramp”到一个目标值，然后复位并从 0.0 重新开始“ramp”。

该模块通过输入事件 E_Init 的初始化事件进行初始化。此时，输入X0、X1、Cycle 和 Duration 的输入值被存储在 “Ramp1”输入变量中。
- 在这个例子中，X0 和 X1 被固定在 0.0 和 1000.0 的值上，由复合块主体中定义的常数有效地设置了 ramp 输出 Out 的限制。
- Cycle 和 Duration 的值来自于块的外部接口提供的值，并定义了“sawtooth”波形的时间特征。
在初始化之后，该块已经准备好在事件输入端 E_Run 接收定期的事件流。E_Run输入的每个事件都会触发Ramp1 块向 X1 设定的上限递增其输出 Out。
每次 Ramp1 内部算法完成其执行，一个输出事件 E_ExO 被传递给 Compare1 块，然后它将 Out 的值与 Target 的值进行检查，即它比较输入X 和 Y。
最终，当 Ramp1.Out 值达到目标值时，比较块检测到输入 X 大于输入 Y 并触发其输出事件 E_GT。
这个事件被反馈给 Merge1 块，它为 Ramp1 块产生一个新的初始化事件。Ramp1 块被重新初始化，输出被重置为 0.0。
只要该块继续在其事件输入 E_Run 接收事件，它将继续产生锯齿形的波形。

锯齿（sawtooth）形曲线的斜率可以通过在事件输入端 E_Init 发出不同的持续时间值的初始化事件来改变该块。Merge1是第 5 章中描述的标准事件功能块的一个实例，它提供了一个将多个事件合并为一个新的事件流的方法。在这种情况下，Merge 被用来允许 Ramp 块由外部事件输入 E_Init 或由内部产生的来自比较块的事件来初始化。

`WITH` 结构的使用

通过使用 WITH 结构，可以用图形显示哪些数据输入和输出分别与特定的输入和输出事件相关。

例如，在图 3.7 中，初始化事件 E_Init 与输入 Cycle 和 Duration 有关。

然而，与基本功能块的行为不同，WITH 构造并不表示输入被存储在属于该块界面的变量中。

对于复合块来说，WITH 是一种手段，用来显示当一个特定的输入事件发生时，哪些输入需要准备好。输入值实际上被采样并存储在内部组件块的输入变量中。同样地，对于输出事件，使用 WITH 构造可以显示当某个特定事件发生时哪些输出值是准备好的，例如在图 3.7 中，当输出事件 E_Ex0 发生时，数据输出 Out 是准备好的。

注意 ⚠️

标准规定复合功能块声明中的每个数据输入和数据输出都必须与至少一个 WITH 构造相关联。

对于输入来说，这可以确保它们的值至少被一个事件所采样；

对于输出来说，这可以确保有一个明确的时间点来更新输出。

复合功能块的执行

复合功能块的实例可以作为资源中存在的功能块网络的一部分来创建，可以存在于顶层，也可以在其他更大的复合功能块的定义中使用。在所有情况下，复合块的执行都是由其事件输入的到来决定的。该标准定义了以下简单的规则，决定了事件的处理方式：

如果一个复合块的输入事件被直接路由（thought route）到一个复合块的事件输出，那么在事件输入端发生的事件将在该块的事件输出端产生一个事件。
1
2
graph LR
复合块A:OUTPUT --"直接路由"--> 复合块B:INPUT
如果一个输入事件被连接到一个内部组件功能块，那么输入事件的发生将导致一个事件到达组件的输入事件。然后，该组件块将被资源的调度功能安排执行。
1
2
3
4
5
6
7
graph LR

input_evt1([输入事件]) -.-> componentA

subgraph 复合块A
componentA[[组件A]]
end
同样，如果一个组件块的输出事件与另一个组件块的输入事件相连，那么第一个组件块的输出事件将导致第二个组件块被安排执行。
1
2
3
4
5
6
7
flowchart TB
componentA ---> componentB

subgraph 复合块A
componentA[[组件A]]
componentB[[组件B]]
end
如果一个复合输出事件与一个组件块的输出事件相连，那么当组件块产生一个输出事件时，复合输出事件就会产生。

flowchart LR

componentA -.-> output_evt1([输出事件])

subgraph 复合块A
	componentA[[组件A:OUTPUT]]
end

这些简单的规则在事件和块的执行之间提供了一个直观和逻辑的联系。从本质上讲，事件通过复合功能块的网络传播，从输入端到复合块的输出端进行传播。

复合功能块的文本语法示例

到目前为止，我们集中讨论了复合功能块的图形表示。与基本功能块一样，IEC 61499文本语法也可以用来描述构成复合功能块的结构和内部网络。例如，图3.6中描述的锯齿形块可以用以下文字描述来表示：

FUNCTION_BLOCK SAWTOOTH
(* Event definitions *)

EVENT_INPUT
	E_RUN WITH TARGET;
	E_INIT WITH CYCLE, DURATION;
END_EVENT

EVENT_OUTPUT
	E_RDY;
 	E_ExO WITH OUT;
END_EVENT

(* Variable definitions *)
VAR_INPUT
	CYCLE : TIME;
	DURATION : TIME;
	TARGET : REAL;
END_VAR

VAR_OUTPUT
	OUT : REAL;
END_VAR

(* Function blocks *)
FBS
	RAMP1 : RAMP;
	COMPARE1 : COMPARE;
	MERGE1 : E_MERGE;
END_FBS

(* Event connections *)
EVENT_CONNECTIONS
	E_RUN TO RAMP1.E_RUN;
	E_INIT TO MERGE1.EI1;
	MERGE1.EO TO RAMP1.E_INIT;
	RAMP1.E_Rdy TO E_Rdy;
	RAMP1.E_ExO TO E_ExO;
	COMPARE.E_GT TO MERGE1.EI2;
END_CONNECTIONS

(* Data connections *)
DATA_CONNECTIONS
	0.0 TO RAMP1.X0;
	1000.0 TO RAMP1.X1;
	CYCLE TO RAMP1.CYCLE;
	DURATION TO RAMP1.DURATION;
	RAMP1.OUT TO COMPARE1.X;
	TARGET TO COMPARE1.Y;
	Compare1.X0 TO OUT;
END_CONNECTIONS

END_FUNCTION_BLOCK;

文本形式比较像电子电路的构建清单。它描述了所有的事件和数据输入和输出、内部功能块以及事件和数据连接。

定义的每一部分都由一个块的关键字引入，例如，EVENT_INPUT … END_EVENT 定义了该块的所有输入事件，同样，DATA_CONNECTIONS … END_CONNECTIONS 定义了外部接口和内部块之间的所有数据连接。

文本语法的开发是为了形成一种通用和可移植的格式，可以用来表达复合块的结构。它并不直接表达块的行为的算法方面，但它确实明确地定义了块是如何构建的，从中可以推导出它的行为。事实上，目前正在开发的软件工具可以自动在图形和文本表示之间进行转换。

3.5 子应用的定义

一个子应用可以被看作是一种特殊形式的复合功能块，它被设计为 “分布式”。也就是说，它可以在一个以上的资源上运行。它的结构与复合功能块相似，但关于数据和事件的使用的一些规则被放松了。一个子应用功能块类型只能在其他较大的子应用的主体中和完整的应用中使用。然而，一个子应用类型本身可以使用复合、基本和其他子应用功能块来定义。

与复合功能块相比，子应用的主要对比特征是它可以选择在多个资源上运行。请注意，基本功能块和复合功能块只能在同一资源上运行，也就是说，不可能将它们分解成可以在不同资源上运行的部分。然而，一个子应用可以在一个资源上运行，也可以分布在不同的资源上运行；换句话说，它是可分布的。

关于子应用的一种方式是，它代表一个可重复使用的部分功能块网络。它通常被用来定义功能块和连接的安排，可以在不同的网络配置中重复使用。在许多方面，子应用类型的定义类似于软件的宏，因为它允许一个特定的解决方案以功能块网络的形式被轻易地复制。

例如，考虑一个提供温度控制回路的子应用块，如图 3.9a 所示。

它由一个模拟输入块 Input 1、一个PID控制块 PID 1 和一个模拟输出块 Output 1 组成。通常，这将用于控制一个设备的温度，例如，一个加热容器或炉子。这个控制回路的主要功能是：(i)测量当前温度，(ii)将其值与设定值或期望温度进行比较，然后(iii)调整一个输出值，驱动加热设备来校正温度。

这三个功能被映射到构成子程序的三个组件功能块上。Input 1 模块读取外部传感器的电流值。PID 1 块提供一个 ***PID 算法***来比较测量值（过程值）和设定值并创建输出值。Input 1 模块获取 PID 1 模块创建的值，并将其传输给外部执行器。
Input 1 和 Output 1 将被构造成复合功能块，每个功能块都需要至少一个服务接口功能块来提供与底层控制器的接口，以便从控制器硬件读取输入和输出（I/O)值。服务接口功能块是一种特殊形式的块，提供与物理设备或通信系统的各种接口，在第四章中讨论。

图 3.9b 显示了 TempControl 子程序如何在一个简单的控制器中运行，为一个使用蒸汽加热的容器提供闭环温度控制。TempControl 子程序的输入是一个从热电偶等传感器上读取的温度值；子程序的输出驱动某种形式的执行器，如蒸汽阀，以改变加热。

注意 ⚠️

在这个例子中，TempControl 子程序实际上是 Single_Vessel_Control 程序的一部分，该程序已在单一的 IEC 61499 资源中声明，即其所有功能块都在同一资源中运行。

这个子程序有两个事件输入，E_Init 和 E_Run。

E_Init 是用来初始化内部组件块的。它触发了 PID块的执行并读取其输入变量，也就是说，Setpoint 输入的值被读取并存储在 PID 1 中。这定义了控制环路将稳定的预期温度。一般来说，PID 算法将需要大量的参数，如积分和导数动作的定时常数。为了保持例子的简单性，这些参数没有显示出来，但将以与设定值相同的方式进行初始化。

E_Run 事件在子程序中传播，导致控制环路根据 PID 算法计算的值更新其外部输出。在这个例子中，我们可以假设应用程序中的另一个定时功能块提供一个定期的事件流，例如在 E_Run 事件输入处以 100毫秒 的间隔，以确保 TempControl 块被定期调用。这将确保以给定的扫描速率测量温度，并将其值传播给 PID 1，而PID 1又会创建一个新的输出值来调节热量输出。

子应用类型规范的规则

子应用构建的规则如下：

一个子应用的实例只能在其他子应用类型定义中或在一个应用程序中被声明。
在子应用类型定义中不使用 WITH 构造，因为事件和数据之间的关联将取决于子应用如何在资源之间分配。
在文本语法中，子应用的输入和输出变量使用 VAR_INPUT 和 VAR_OUTPUT 构造来声明，但与复合功能块一样，这并不意味着为这些变量创建存储。子应用程序的所有输入和输出值都存储在组件块的内部接口。

子应用的执行规则

子应用的实例可以在应用程序中声明，也可以在其他子应用中声明。然而，子应用程序的实例与复合功能块的实例相当不同，因为它真正代表了一组功能块及其连接的副本。在这方面，一个子应用可以被比作一个软件宏或一个图形模式。

该标准为子应用的执行方式定义了以下规则：

事件可以直接通过子应用程序路由，因此到达事件输入的事件将立即触发事件输出的事件。
每个没有直接路由的事件输入必须连接到一个内部组件块的事件输入。在这种情况下，当事件到达子应用程序的事件输入时，内部组件块将收到一个事件并被安排执行。
当一个组件块执行时，它将产生一个或多个输出事件。这些将反过来触发在子应用中与之相连的其他组件块的执行。
没有直接通过事件输入的子应用程序的事件输出必须连接到一个组件块的输出事件。当相关的组件块执行并产生一个输出事件时，该事件被传播到子应用程序的事件输出。

分布式子应用实例

到目前为止，我们已经考虑了在单一资源上运行的子应用。IEC 61499 的一个重要特点是能够重新安排应用程序和子应用程序，使它们能够提供相同的功能，但在不同的资源上以不同的分布安排运行。子应用，如图3.9中描述的 TempControl，可以被分解成更小的功能块网络片段，在不同的资源中运行。在 TempControl 的情况下，可以考虑以下安排：

所有块都在一个资源上运行，即非分布式配置
Input 1、PID 1 和 Output 1 块在不同的资源上运行，即完全分布式配置。即完全分布式配置
Input 1 在一个资源上运行，而PID 1 和 Output 1 块在第二个资源上运行，即分割配置。资源上运行，即一个分离式资源配置
Input 1、PID 1 块在一个资源上运行，而 Output 1 在第二个资源上运行，即另一种分割资源配置。

图 3.10 显示了第四种分布安排，其中模拟输入（Analog Input）和 PID 算法的块 Input 1、PID 1 在一个资源 Resource1 上运行，模拟输出（Analog Output）在第二个资源 Output1 上运行。

在实践中，这种安排意味着子程序 TempControl 可以在位于不同控制器的两个独立资源中运行。图 3.11 显示了可以考虑的一种可能的物理系统配置。它显示了两个控制器 Controller_A 和 Controller_B 通过某种形式的通信系统连接，例如使用现场总线或以太网的网络。模拟输入被连接到 Controller_A ，而执行器现在由另一个 Controller_B 驱动。子应用现在分布在两个控制器上，但内部功能仍然由原始 TempControl 子应用类型定义的功能块来确定。

我们设想，系统设计者可以根据系统设计要求，为子程序自由选择适当的分布安排。设计者选择的分布安排将取决于许多因素，包括：

资源是否能够支持特定类型的功能块，
特定资源的负载和性能，
以及资源之间通信服务的延迟和可靠性。

可以注意到，如图 3.10 所示，一些额外的功能块 Pub1 和 Sub1 已经被添加到分布式 TempControl 子程序中。这些是服务接口功能块的进一步例子，在第4章有更详细的讨论，它们在资源内的功能块和资源的通信系统之间提供一个接口：

PUB1 是一个发布者功能块，用于通过通信链路向其他控制器内的一个或多个外部资源发送一个或多个数据值。它只是使用一个给定的识别地址来发送数值。
SUB1 是一个订户功能块，在第二个资源中用来接收 PUB1 发出的值。在这种情况下，只有一个用户，但也可能有多个用户的配置。

这个例子使用了发布者/订阅者服务接口块，但标准中也讨论了提供不同类型通信模型的其他块，如请求者和响应者。在这个特定的例子中，使用了发布者/订阅者模型，因为在这个简单的设计中，没有要求向 PID1 块提供任何反馈，以确定向模拟输出的值的传输是否成功。PID1 模块将继续向其输出新的数值，而不管下游的通信问题。显然，在一个完整的设计中，需要监控通信并检查整个控制回路是否正常工作。这可以通过使用，例如，请求和响应通信模型或通过从 Output1 块反馈信号来实现。

注意 ⚠️

当一个子程序被重新安排在不同的资源上运行时，通常需要为通信系统增加参数。这通常包括诸如资源地址和网络路由参数等细节。这些信息通常将作为参数传递给处理资源间通信的服务接口功能块。

应该强调的是，IEC 61499 没有定义通信协议，也没有对通信相关的地址或参数进行标准化。但它确实提供了一个框架和架构，用于定义服务，如使用服务接口功能块的通信。

3.6 总结

在本章中，我们已经涵盖了功能块类型定义的最重要方面。我们回顾了类型定义如何被用来创建功能块实例。反过来，我们也看到了功能块实例是如何在新的类型定义中被用来分层建立功能更强的功能块的。尽管设计可以用图形来创建，但我们注意到，标准也定义了一种正式的文本语法，可以作为一种替代的表示方法。

总结一下：

有三类功能块：基本功能块，复合功能块和子应用功能块。
基本功能块的行为是以执行控制图（ECC）和一个或多个算法来定义的。
复合功能块是以一个组件功能块的网络来定义的。
子应用块与复合功能块类似，但也有一个灵活的特点，即它们可以分布在多个资源上运行。
服务接口功能块提供了一种方法来模拟资源与底层硬件和通信系统之间的互动。

所有的功能块类型定义都可以用图形或文字来定义。图形和文本的表述是可以互换的。

4. 服务接口（Service Interface）功能块

到目前为止，我们主要关注的是用于模拟资源内部行为的功能块。在第三章末尾，我们回顾了一个简单的分布式应用的创建，并表明只有在提供额外的服务接口（SI）功能块以在资源之间通信数据值和事件的情况下，这才可能实现。

事实上，只要资源内的功能块和外部世界之间需要任何形式的交互，就需要 SI 功能块。IEC 61499没有为特定类型的 SI 功能块设定标准，但确实规定这些形式的功能块应使用一套标准的输入和输出变量以及输入和输出事件来定义。还有一种特殊的符号用于描述在执行 SI 功能块期间外部发生的互动序列，如发送请求和等待响应。

现在我们考虑可能需要 SI 功能块的地方。在一个工业控制器中，显然需要读取物理输入值，如来自压力和温度传感器的输入值，也需要将输出值写入执行器，例如，用于驱动阀门、泵、电机等设备。还有要求通过串行通信链路传输数值，向外部控制器发送数据副本，驱动显示器，以及从显示面板和其他 HMI 设备读取输入。事实上，这些都是与资源进行外部交互的例子，可以使用不同类型的 SI 功能块进行建模。下表中列出了一些可能用于工业控制系统建模的 SI 功能块的例子。

Type name	Service provided	Application example
`IO_Writer`	允许一个资源向本地连接的I/O设备传输一个或多个值。注：IEC 61499假定控制器I/O子系统位于资源之外，但可以使用服务接口块进行访问。	用于更新驱动物理设备的执行器的值，如阀门、加热器或泵。
`IO_Reader`	允许一个资源接收从一个或多个设备读入的最新值。	读取输入设备的位置的最新值，例如机器人放置机构上的微动开关。
`Publisher`	将一个或多个变量的值传输给一个或多个变量。将一个或多个变量的值传送给一个或多个支持 "订阅者 "服务的外部资源。	不断向一些远程控制器传输输出值，以驱动执行器。
`Subscriber`	从提供发布者服务的外部资源接收一个或多个值。注意：发布者和订阅者将通过网络特定的唯一地址或服务标识符来识别一组特定的值。可以有许多用户从一个发布者那里接收数据。	定期从给定的外部资源接收数值流，例如，更新一组HMI显示器。

这些只是可能需要的 SI 功能块种类的几个典型例子。应该注意的是，该标准并不试图定义具体的 SI 块，因为很明显，每个系统都会有自己的特殊要求。然而，我们将看到，IEC 61499 确实对 SI 功能块接口的一些重要方面进行了标准化，包括主要的输入和输出参数。

4.1 类型定义

IEC 61499 一般性地规定了定义 SI 功能块接口的方式。每个 SI 功能块都提供某种服务，如读取I/O、通过网络发布（Publish）数值等。

应该注意的是，一个 SI 功能块可以响应应用程序的调用而启动一个服务。另外，SI 块可以响应外部请求，如来自 HMI 的信号，从应用程序中获得一个值。SI 功能块可以被建模以支持这两种类型的行为。

SI 功能块的标准输入和输出

每个 SI 功能块都应该使用以下标准输入和输出，尽管不是每个 SI 类型的定义都必须使用所有这些输入和输出：

事件输入

`INIT`

这个输入事件被用来初始化一个由块提供的特定服务。例如，它可以启动一个服务，通过串行链路提供数据传输。该事件通常与一些输入参数一起发送，以描述服务的类型，如网络地址和波特率。

`REQ`

该事件启动一个请求，以从外部代理获得数据。例如，该事件可用于启动一个从外部设备获取数据的请求的传输。

`RSP`

该事件启动了对外部代理的响应的传输。例如，它可以向一个远程HMI设备发送数据，以响应对数据的请求。

事件输出

`INITO`

这个输出事件表明 SI 功能块已经完成了它的初始化，即作为接收 INIT 事件的一个结果。它不一定意味着服务已经成功初始化；为此提供了一个状态输出。

`CNF`

当区块完成了对外部代理的请求的传输时，“确认（confirmation）”事件被输出。例如，它应该被用来表明一个读取特定物理 I/O 点的请求已经被控制器的 I/O 子系统处理。

`IND`

当服务接口块收到来自外部代理的响应时，“指示（indication）”事件被输出。例如，当从控制器的 I/O 子系统读取的 I/O 已经获得所选传感器的值时，就会产生一个 IND 事件。

数据输入

`QI: BOOL`

QI 数据输入与 INIT 输入事件一起使用，作为一个简单的限定符。当 true 时，它表示应该启动该块所提供的服务。当它的值为 false 时，与 INIT 事件一起使用，表示服务应被终止。

`PARAMS： ANY`

这个输入表示一个数据结构，它持有一组与 SI 服务相关的值，并定义其特定的特征。该结构中的数据类型和数值数量将具体到功能块提供的服务类型。SI功能块类型定义将定义 PARAMS 结构和其中的默认参数值。该输入仅与 INIT 事件一起使用，用于服务的初始化。

例如，一个通信 SI 功能块的 PARAMS 输入将包含网络寻址信息和其他通信特性。

`SD_1, ... SD_N: ANY`

这些数据输入被用来发送带有请求和响应的数据。输入的数量和它们的数据类型将特定于功能块提供的服务类型；这由符号 SD_1, ..., SD_N 表示。

例如，当向输出设备写值时，这些参数将包含硬件地址（如机架、模块、通道）和输出值。

数据输出

`QO: BOOL`

这个限定符输出用于指示任何输入事件的服务是否已经成功完成。例如，在初始化 INIT 事件之后，true 值表示成功启动；false 则表示服务未能初始化。

`STATUS： ANY`

这个输出可以与任何输入事件一起设置，用于提供处理最后一个输入事件的状态。例如，当使用 INIT 事件初始化一个服务并且不成功时，将设置 Status。同样，当一个用于向远程设备传输数值的 REQ 事件被处理并随后失败时，Status 被用来保持失败的原因。

`RD_1, ..., RD_N: ANY`

这些输出用于传达从 CNF 和 IND 中收到的数据。与 SD_1 ... SD_N 输入，这些输出的数量和它们的数据类型将具体到正在提供的服务类型。

例如，考虑当一个请求被提出来时，例如，从一组 10 个输入点中读取数值–当服务从 I/O 子系统中收到数值时，将发生一个 IND 指示事件；它们的数值将在一组 RD_1...RD_10 输出上提供。

图4.1描述了两个 SI 功能块，在 IEC 61499 标准中被作为例子给出。这些块仍然是 "通用 "的，因为它们没有被赋予特定数量的输入和输出。输入和输出的数据类型也是用关键字 ANY 来定义的。换句话说，这些是类型定义的大纲模板。要在特定的应用领域使用这些，还需要进一步的具体细节和数据类型。
请求者 SI 功能块提供了一个通信服务，以从远程资源获取数据。

PARAMS 输入用于指定通信地址和其他细节；
SD_1 到 SD_m 输入为一个请求提供参数，例如通过发送请求命令字符串和参数。
RD_1 到 RD_n 输出用于从远程资源收到的响应数据，并将在该块发出确认 CNF 输出事件时到达。

响应者 SI 功能块，实际上是提供了通信的另一端。它接收来自远程资源的请求，并在 RD_1 至 RD_n 上创建一个指示 IND 事件和输出数据，以表明已经收到了一个远程数据请求。通过将数据写入应答器输入 SD_1 到 SD_m，并在应答器 RSP 事件输入端触发一个事件，可以返回对请求的响应。然后，该数据将被通信系统送回原请求者块，在那里它将被接收，并反过来触发一个带有数据的确认 CNF 输出事件，如前所述。

请求者和响应者 SI 功能块一起可用于在由某种形式的通信或网络设施连接的两个资源之间交换数据。

请求者块为 IEC 61499 所提到的 "应用程序发起的互动（application-initiated interation） "提供服务；换句话说，对外部数据的请求是由应用程序内产生的事件触发的。
相反，响应者块为 "资源发起的交互（resource-initiated interaction）"提供服务。对数据的请求来自于外部资源，并导致指示 IND 事件的产生。在这种情况下，应用程序将需要对可能在任何时候发生的事件做出反应。

图4.2显示了 SI 功能块的另外两个例子；IO_Writer 用于向物理输出写值，而 IO_Reader 用于从选定的物理输入读值。两者的功能都是类似的。

让我们考虑如何使用 IO_Writer 块：

一个应用程序将需要至少一个这个块的实例来向物理输出写值。为了设置服务，应用程序必须首先发送一个 INIT 事件，QI 输入设置为 “true”，PARAMS 输入设置为识别服务的特征。PARAMS 输入可以包含一些细节，如“写的更新率”、“失败时重试的次数”等等。此后，通过将输入 SD_1 设置为输出地址，如机架、通道和 I/O 点，并将新值设置为输入 SD_2，可以将数据发送到选定的输出。写入是由事件输入端 REQ 的一个事件启动的。

一段时间后，当硬件I/O系统完成写操作后，将发生一个输出事件 CNF，以确认 "写 "已经完成。输出 STATUS 提供了一个操作是否成功的指示。如果操作失败，STATUS 将包含一个适当的错误代码。输出 RD_1 提供了从输出设备读出的数值的反馈。这可以用来确认写操作已经成功。
IO_Reader 块以非常类似的方式执行。在使用 INIT 事件初始化服务后，通过 QI 和 PARAMS 输入，可以通过设置输入 SD_1 的 IO 地址并向事件输入 REQ 发送一个事件来读取任何物理输入的值。

一段时间后，当数据从输入传感器中读出后，在输出事件 CNF 中会发生一个确认事件。读取操作的成功将由输出 STATUS 的值表示，如果成功，从输入端读取的值将在输出 RD_1上提供。

IO_WRITER 和 IO_READER 是访问硬件 I/O 的 SI 块的相当简单的形式。然而，可以考虑用更复杂的块来模拟读和写的设施，例如，在一次操作中为许多I/O点读出多个值。

注意 ⚠️

从触发 REQ 事件发出请求到收到确认事件 CNF 之间的时间将取决于许多因素，例如：

资源调度系统的负载

设备操作系统响应来自资源调度系统的请求的速度

向物理 I/O 点传输请求的时间。

4.2 SI 功能块的行为

与其他形式的功能块一样，SI 功能块的行为是由功能块类型规范定义的。然而，由于 SI 功能块主要与外部事务有关，该标准规定了一个额外的符号，称为 ISO Technical Report 8509 中的时间顺序图。这些可以用来显示与功能块的各种交互之间的时间和顺序关系。事实上，时间顺序图在通信标准中普遍使用，它提供了一种有效的方法来显示各种信息或事件发生的顺序。

图4.3显示了时间顺序图的一部分，用来描述图4.1中所显示的请求者功能块的行为。时间顺序图描述了三个事务：

Normal_initialisation，适用于应用程序启动Requester服务时；
Normal_data_transfer，描述了向远程资源发送请求；
Normal_termination，描述了应用程序终止服务。

让我们更仔细地看一下时间序列图的特点。首先，该图显示时间是向下递增的。例如，在图4.3中，INIT+ 事件发生在 INITO+ 之前，因为 INTIO 是一个输出事件，它是作为对输入事件 INIT 的响应而产生的，但发生在一段时间之后。此外，密切相关的事件，如 INIT 和 INTIO，总是由竖条内的垂直连接线显示。请注意，在时序图上描述了与事务有关的功能块输入和输出事件的名称。

每个时间序列图中描述的两个垂直条将发生操作的两个不同领域分开。图4.3显示了应用程序发起的事务的例子，在这种情况下，惯例是将功能块类型的名称放在两个垂直条的左边，资源放在右边。发生在功能块领域的事件总是被描述在有功能块类型名称的一侧。

图4.4显示了响应者功能块的一些事务实例，本章前面也介绍过。在这种情况下，由于主要的交互是由资源而不是应用程序发起的，所以惯例是将资源描绘在垂直条的左侧。

注意，只有 Normal_data_transfer 事务是由资源通过 IND 事件的到达指示启动的。在这个例子中，应用程序处理指示数据并返回一个积极的响应 RSP+。建立和关闭服务的 Normal_initialisation 和 Normal_termination 事务都是由应用程序发起的。

事件名称的后缀 "+“表示该事件是否与成功（或正常）事务有关，而后缀”-"则与不成功（或异常）事务有关。对于输入事件，后缀’+‘表示与该事件一起设置的输入 QI 的值将是 TRUE。反之，后缀’-'意味着输入 QI 将被设置为 FALSE。

例如，事件 INIT+ 表示它将在 QI 设置为 TRUE 的情况下被发送，并意味着服务将被初始化。相反，INIT- 表示该事件将在 QI 设置为 FALSE 的情况下被发送，并表明服务应该被终止。

与输出事件类似，后缀’+‘表示成功或积极的事务，而后缀’-‘表示该事件与不成功或消极的事务。对于输出事件，后缀’+‘表示输出 QO 的值将被设置为 TRUE，而后缀’-'表示 QO 将被设置为 FALSE。

例如，IND- 将是一个负面的指示，意味着事务在某种程度上是不成功的。如果这种情况发生在响应者功能块上，它可能意味着从远程资源发送的数据不正确–可能是数据的格式不正确。应用程序应该发出一个否定的响应，即 RSP，如图 4.5 所示。

显然，对于复杂的 SI 功能块，应该考虑正常和异常事务的所有不同组合和形式。

SI 标准事件的语义

对于 SI 功能支持的所有标准事件的积极和消极形式的意义（即语义）都有定义。IEC 61499 将这些不同的事件形式定义为服务原语。表 4.2 有两列，分别对应于通信服务和通用服务，并提供了标准服务原语的定义。

服务原语	在通信服务中的语义	在一般性服务中的语义
`INIT+`	请求初始化通信服务	请求初始化服务
`INIT-`	请求结束通信服务	请求结束服务
`INITO+`	表示通信服务已被初始化	表示服务已被初始化
`INITO-`	表示通信服务不能被初始化或已被成功终止	表示服务不能被初始化或已被成功终止
`REQ+`	正常请求传输数据	正常请求服务
`REQ-`	禁用请求传输数据	禁用请求服务
`CNF+`	确认数据传输成功	服务的正常确认
`CNF-`	确认数据传输不成功	确认服务请求不成功
`IND+`	数据成功到达的指示	正常服务到达的指示
`IND-`	数据到达不成功的指示	正常未成功到达的指示
`RSP+`	应用对数据成功到达的响应	应用对成功服务的响应
`RSP-`	应用对数据不成功的到达的响应	应用对不正常或不成功服务的响应

文本语法 - SI功能块示例

IEC 61499 为 SI 功能块类型指定了一个额外的文本语法，允许定义各种服务事务。通过回顾本章前面描述的 IO_Writer 功能块的文本类型定义，可以最好地证明这一点，如图4.2所示。

FUNCTION_BLOCK IO_WRITER
(* IO_Writer Service Interface *)

	EVENT_INPUT
		INIT WITH QI, PARAMS;
		REQ WITH QI, SD_1, SD_2;
 	END_EVENT
 	
	EVENT_OUTPUT
		INIT0 WITH QO, STATUS;
		CNF WITH QO, STATUS, RD_1;
	END_EVENT
	
	VAR_INPUT
		QI : BOOL; (* Event input qualifier *)
		PARAMS : IO_PARAMS; (* Service parameters *)
		SD_1 : IO_ADDR; (* Output address *)
		SD_2 : IO_VALUE; (* Output value *)
	END_VAR
	
	VAR_OUTPUT
		QO : BOOL; (* Event output qualifier *)
		STATUS : ANY; (* Service status *)
		RD_1 : IO_VALUE (* Returned value *)
	END_VAR
	
	SERVICE REQUESTER/RESOURCE
	
		SEQUENCE normal_initialisation
			REQUESTER.INIT+(PARAMS)->REQUESTER.INITO+();
		END_SEQUENCE
		
		SEQUENCE abnormal_initialisation
			REQUESTER.INIT+(PARAMS)->REQUESTER.INITO-();
		END_SEQUENCE
		
		SEQUENCE normal_data_transfer
			REQUESTER.REQ+(SD_1,SD_2)->REQUESTER.CNF+(RD_1);
		END_SEQUENCE
		
		SEQUENCE abnormal_data_transfer
			REQUESTER.REQ+(SD_1,SD_2)->REQUESTER.CNF-(STATUS);
		END_SEQUENCE
		
		SEQUENCE normal_termination
			REQUESTER.INIT-()->REQUESTER.INITO-();
		END_SEQUENCE
		
		SEQUENCE abnormal_termination
			REQUESTER.INIT-()->REQUESTER.INITO-(STATUS);
		END_SEQUENCE
		
		SEQUENCE resource_initiated_termination
			-> REQUESTER.INITO-(STATUS)
		END_SEQUENCE
		
	END_SERVICE
END_FUNCTION_BLOCK

提供了新的关键字 SERVICE 和 END_SERVICE 来包含服务序列的定义。
每个服务序列都用关键词 SEQUENCE 引入，用关键词 END_SEQUENCE 结束。序列定义定义了启动事务的服务原语和相关参数。-> 操作符意味着两件事：
1. 由于外部处理或通信延迟，可能会有时间延迟；
2. 由此产生的服务基元，如该操作符右边所述，将作为左边的服务基元的结果而发生。序列的名称必须与“时间-序列图”上给出的名称一一对应。

服务启动时应该有效的输入的名称被括在服务基元之后的括号里。同样地，为所产生的服务基元设置的输出名称也显示在右边。

注意 ⚠️

在资源发起的终止的最后一个序列定义中，在 -> 符号的左边没有给出事务的组件。这是因为，在这种情况下，事务是由资源之外的某个未知代理产生的。例如，这可能发生在即将发生电源故障的情况下，因此设备正在通过资源接口发送一个未经请求的事务以终止 IO_WRITER 服务。

SI 功能块的任何额外行为，例如在启动服务之前检查特定输入的有效性，可以通过将 SI 块封装在一个复合块中来建模，如第三章所讨论的。然后可以添加额外的功能块来过滤输入数据和验证响应数据。

应该注意的是，SI 功能块类型定义只包含在功能块域内发生的行为的定义，即在资源内。它没有定义资源外的行为，这些行为是由设备操作系统、硬件或通信系统提供的。这都不在 IEC 61499 的范围内。

4.3 伙伴式（Partnered）服务接口功能块

在有些情况下，SI 功能块被用来在不同资源之间提供和交换信息。例如，一个应用程序可能分布在两个资源 A 和 B 之间，需要从 A 发送请求数据并从 B 接收响应。然而，驻扎在 A 和 B 的应用程序的两个部分必须能够检测数据交换是否成功。这方面的一个解决方案是提供客户端和服务器 SI 功能块，能够进行双向数据传输。资源 A 中的客户端块向资源 B 中的服务器块发出请求；服务器响应并将响应数据发回给 A 中的客户端块。

为了对此进行建模，该标准规定时间序列图可以显示双方的事务。考虑图 4.6 所示的客户端和服务器功能块，并假设这些功能块提供一个互锁的数据交换服务。当客户端发出一个请求时，服务器会做出响应。图 4.7 显示了部分时间序列图；在这种情况下，两个竖条代表了在客户端和服务器之间传输消息的处理和时间延迟。

服务序列的文本语法可以包括事务两端的定义。例如，Server 的类型定义可以包括来自另一个 Client 的预期响应。为了说明这一点，下面的文本语法将把双向数据传输服务序列定义为服务器类型定义的一部分，也就是说，它描述了图 4.7 中的时间序列图。

SEQUENCE normal_data_transfer
	CLIENT.REQ+(SD_1,...,SD_m) ->SERVER.IND+(RD_1,...,RD_m);
	SERVER.RSP+(SD_1,...,SD_n) ->CLIENT.CNF+(RD_1,...,RD_n);
END_SEQUENCE

请注意，客户端的定义将简单地引用服务器的完整事务定义。还要注意的是，在这个例子中，符号 ...,SD_n 是表示客户端/服务器块是通用的，可以根据特定的应用进行调整。在一个真实的系统中，每个客户端/服务器对将被指定为发送和接收一个特定数据类型的固定数量的数据项。

客户端和服务器对实际上提供了一种机制来创建一个远程功能块的本地 “代理”。他们可以提供一组本地的输入和输出，模仿远程块上的输入和输出。根据设想，当一个应用程序在资源之间分割时，工程支持工具将能够自动插入客户/服务器对。

4.4 管理功能块

标准中定义的 SI 功能块的最后一种形式涉及到加载、启动和启动功能块执行的服务。该标准定义了一个通用形式的管理功能块，如图4.8所示，可以使用不同的命令定义来启动一系列的服务功能。这些服务的描述和它们的工作方式在标准中只给出了一个概要。这是一个特别难以建模的领域，因为系统将倾向于有完全不同的机制来加载和创建功能块网络，并开始执行加载的应用程序。在未来，关于这些服务的进一步细节可能会被包括在标准的其他部分，但这是一个很大的话题，很难以一般的方式来建模。

一个极端是，为了启动一个应用程序，一个系统可能需要将所有的功能块和支持的资源库编译成二进制格式，并向下加载到单独的设备中。在另一个极端，设备可能有大量的预装功能块库；例如，功能块的定义可能都是设备固件的一部分。在这种情况下，可以通过简单地下载在不同设备中创建应用的功能块网络所需的连接定义，来创建一个应用。也可能有混合系统，其中一些功能块在固件中，而另一些则被下载。

如下表 4.3、4.4 所示，管理功能块支持的服务在资源和设备层面都适用。

(表 4.3，资源层面的管理服务功能)

Service Function	Description
`Create`	创建数据类型定义、功能块类型和实例以及功能块之间的连接。这将涉及到从源头下载定义，例如，通过网络复制，从存储智能卡中复制进来。
`Initialise`	初始化数据类型、功能块类型和实例以及连接。这涉及到将功能块和连接设置为可运行状态，并包括将变量重置为其默认的初始值。
`Start`	启动函数触发了一个资源内功能块网络的执行。通常，它将启动资源调度功能并开始运行产生定时事件的 SI 功能块。这些反过来又会触发导致功能块执行的事件链。
`Stop`	停止服务通过暂停资源调度功能使所有执行停止。
`Delete`	删除服务可用于删除任何数据类型、功能块或连接的定义。
`Query`	查询服务提供了一种方法来访问关于数据类型、功能块和连接的状态、属性和存在的信息。

(表 4.4，设备层面的管理服务功能)

Service Function	Description
`Create`	在一个设备中创建和建立一个资源。这设置了一个设备中资源的特征和属性。
`Initialise`	初始化资源，使其准备好加载和执行功能块。
`Start`	启动资源以允许功能块执行。
`Stop`	停止资源执行功能块。
`Delete`	从设备中删除资源，使其不能再被访问以加载和执行功能块。
`Query`	查询设备以获得有关设备中资源的状态、属性和存在的信息。

管理功能块可以通过为 CMD 输入指定不同的值来启动各种服务功能。对每种形式的服务功能的响应是由 Status 输出中返回的值给出的。服务功能由输入 CMD_PARAMS 的值进一步描述。

CMD = CREATE
CMD_PARAMS = fb_instance_definition
PARAMS = fb instance definition data
RESULT = fb instance reference

这启动了服务功能，以创建功能块实例定义。

CMD = QUERY
CMD_PARAMS = connection_start_point
PARAMS = connection start point definition
RESULT = connection end point definition

这显示了一个查询管理服务功能的例子，为一个给定的开始连接找到对结束连接的引用。

作为一个一般性的评论，功能块在建模系统时非常有效，其行为主要与数据和事件流有关。对于加载和创建功能块以形成分布在各个设备上的应用的管理操作，是否可以用同一个模型来描述，这是一个问题。这种类型的行为可能需要一个不同类型的模型，因为它主要涉及到数据管理问题。

被管理的功能块

可以被管理功能块加载和访问的功能块被称为 “被管理功能块”。这与非管理功能块形成对比；这些功能块包括属于设备固件的一部分，因此有一定程度的固定功能。

(表 4.5，被管理功能块的主要状态)

State	Meaning
`THAWED`	功能块实例内部状态信息可用，功能块准备开始执行。当功能块的包含设备正在通电时，该状态存在。
`RETAINED`	当一个功能块的包含设备完全断电时，该功能块被认为处于该状态。
`IDLE`	该功能块处于初始化状态。该块的执行控制图处于初始状态；输入和输出变量有其初始值。
`RUNNING`	在这种状态下，功能块被认为可用于接收输入事件。任何输入事件都会被资源调度功能所处理。
`STOPPED`	所有算法和输入事件的处理都由调度函数终止。
`KILLED`	所有输入事件和算法进程的操作被抑制。

管理功能块可以有一些状态，如表 4.5 所定义。如果一个被管理的功能块与一个管理器功能块相关联，那么它的状态可以被改变。这个概念是，一个资源可以通过向管理功能块发出请求来动态地改变功能块的配置。在标准中，这种实际发生的方式还很粗略，但在 IEC 61499 的第二部分中可能会有更详细的处理。

注意 ⚠️

这只是对管理功能块的主要状态的概述。对于进一步的细节，读者应该参考 IEC 61499 第一部分 "受管功能块的行为 "一节，其中有关于受管功能块的状态机的细节，也有关于不同状态之间的相关转换的描述。

4.5 总结

我们现在已经介绍了 IEC 61499 服务接口功能的重要特征。重新总结一下，服务接口（SI）功能块的提供是为了在资源中运行的功能块和资源外提供的服务之间提供一个接口。一个 SI 功能块类型的定义只定义了进入服务的接口和它的响应；它并不定义资源外的服务行为。一个特殊的符号，即时间序列图，被用来显示 SI 块的输入和输出侧的事件之间的时间关系。

SI 功能块可用于：

对通过设备的 I/O 子系统访问的I/O点进行读和写
从外部资源请求数据或响应外部资源的数据请求
设置与外部资源的互锁数据交换，例如，使用客户端和服务器块
管理资源中功能块的创建和执行

5. 事件（Event）功能块

正如第1章和第2章所讨论的，IEC 61499 功能块网络的一个基本属性是，每个功能块内所有软件的执行在某种程度上是由事件触发的。在本章中，我们将回顾一组特殊的标准功能块，它们是为事件行为提供的。这些功能块可以用来对事件的控制、生成和检测进行建模。

本章将描述标准的事件功能块，它们是：

允许事件被分割以产生新的事件
允许事件被合并
允许特定事件的传播
在两个或多个事件之间进行选择
将事件延迟到一个给定的时间段
产生事件流
从布尔边缘检测中创建事件。

5.0 概述

在前几章中，我们已经回顾了创建功能块类型定义的几种不同方式，即基本功能块、复合功能块和服务接口功能块。在本章中，我们将回顾 IEC 61499 中定义的一组特殊的功能块类型，专门用于处理事件。这些功能块中的大多数被定义为 "基本"块。有几个块被定义为 "服务接口"的形式，因为它们需要与包含的资源进行一些交互。还有一些更复杂的事件块，它们是由基本的事件块组合而成的。

所有的标准事件功能块都是为了在更大的用户复合功能块和应用程序的定义中使用，并提供了许多事件行为建模时需要的常见操作。

在任何面向事件的系统中，总是需要能够生成初始事件，以触发第一项软件的执行。同样，在IEC 61499功能块网络中，需要一个事件来触发每个功能块链中的第一个功能块。控制系统通常还会有其他的要求，比如需要分割事件来同时触发多个块链，或者创建事件链，使块定期重新执行，例如在对扫描I/O的系统建模时。

图 5.1 显示了一个控制系统的简单例子，该系统在最初通电时开始执行，即 “冷启动（Cold Start）”，然后继续平行地执行两个功能块链。显然需要一个’冷启动’事件来启动链中的第一个功能块。当第一个功能块 FB1 执行完毕后，需要执行两个独立的功能块链。这表现在事件分割（Split）和触发块 FB2a 和 FB3a。当 FB2b 和FB3b 都完成了它们的执行，来自这两个块的事件通过 "会合（Rendezvous）"被连接起来，形成一个单一的事件，然后反过来触发最后一个功能块 FB4。

在这第一个例子中，当系统冷启动时，功能块只执行一次，因为只产生一个初始事件。然而，通常情况下，控制系统需要扫描的行为，功能块需要重复执行，以监测工厂状态和更新执行器等。这可以通过将一连串的事件传递到第一个功能块来实现，如图 5.2 所示。假设该事件序列由定期发送的事件流组成，例如每 100毫秒 一次。现在，两条并行路径中的所有功能块在冷启动后每隔 100毫秒 就会不断地重新执行。

在图 5.1 和 5.2 中，每个圆圈都代表某种形式的事件行为。事实上，我们将看到，每个圆圈都可以由 IEC 61499 事件功能块中的一个来代替。图 5.2 中功能块网络下面的时序图描述了进入功能块 FB1 的事件控制头的事件流。也显示了从事件汇合处出现的事件流。请注意，这里的事件稍有延迟，因为在并行功能块网络中执行算法的时间以及资源调度的延迟。事件之间的周期也略有不同，因为执行延迟可能不同；例如，一个算法不一定总是需要相同的时间来执行，因为这可能取决于输入和内部变量的值。

5.1 标准事件功能块类型

现在我们将回顾 IEC 61499 中定义的丰富的标准事件功能块类型，它允许对各种不同的事件场景进行建模。在下面的描述中，每个图的左边是功能块类型的外部模板，右边是其相应的类型说明。许多事件功能块是 "基本 "形式的，可以用执行控制图（ECC）来定义；有些需要与资源进行交互，因此用时间顺序图来定义。有几个复杂的事件功能块，如 “布尔上升沿检测器”，被定义为由较简单的事件块组成的复合块。

注意 ⚠️

在以下数字中显示的块类型声明中，正式的 IEC 61499 功能块类型名称显示在块模板内。在需要相关算法的地方，这些算法被描述在块类型说明中的 ECC 下面。在某些情况下，时序图也被描述在一些块的下面，以澄清输入和输出事件之间的时序关系。

令人惊讶的是，对于许多这样的块，仅仅使用执行控制图（ECC）就可以完全描述其内部行为。为了帮助理解下面的 ECC ，下图总结了 ECC 符号的主要方面，在第 3 章中有充分的描述。

翻译：一个带有双层外部框线的矩形块用来表示初始 ECC 状态

翻译：一个矩形块代表一个 ECC 中的状态

翻译：状态之间的转换用一条线和一个相关的逻辑表达式来描述。在这种情况下，如果事件变量 El为真，变量 NOT G，就会发生转换。

翻译：一个立即发生的状态之间的转换用一条线和一个 "1 "来描述，即一个“ALWAYS TRUE”的逻辑表达。

翻译：

状态右边的一个分割的矩形框代表了 ECC 中的一个 Action。

当状态处于活动状态时，被执行的算法名称显示在左边，相关的事件变量显示在右边。在许多情况下，这是一个输出事件。

翻译：

一个动作框可能不包含算法名称，在这种情况下，该动作只设置一个事件变量。

同样地，一个动作可能没有事件变量名称，而只执行一个算法。

在下面的一些定义中，如事件合并器，输入或输出的数量可能有所不同。例如，事件合并块可以合并两个或多个事件。在这种情况下，我们设想软件工具将自动给功能块实例设定尺寸，使其具有所需的输入和输出数量。

事件分割器 Event Splitter

如时序图（图 5.4）所示，事件分割器在接收一个输入事件时产生两个或多个同时输出的事件。

事件合并器 Event Merger

事件合并器通过合并输入事件 EI1 到 EIn 上的传入事件产生一个单一的输出事件流。这可以用来合并两个或多个事件（图 5.5）。

两个事件汇合 Two Event Rendezvous

双事件会合等待在输入事件 EI1 和 EI2 上接收一个事件，并在输出 EO 上产生一个单一的输出事件。如果该块在 EI1 和 EI2 的输入上再收到一个单一事件，它将在 EO 上再产生一个输出事件（图 5.6）。

请注意，如果在任何时候，该块在输入 R 上收到一个复位事件，那么在 EI1 和 EI2 上总是需要一个单一的事件，然后才会在 EO 上产生一个进一步的输出事件，如时序图所示。换句话说，复位可以用来重新同步两个事件流的汇合点。

处理其他更大数量的输入事件的事件汇合块可以使用类似的设计来定义。

允许性事件推进器 Permissive Event Propagator

允许性事件推进器根据输入 PERMIT 的值控制事件从输入 EI 到 EO 的流动。需要一个 TRUE 来允许事件流经该块（图5.7）。

事件选择器 Event Selector

事件选择器允许输出事件流从事件输入 EI0 或 EI1 中选择，这取决于 G 的值是 "FALSE"还是 “TRUE”（图5.8）。

事件切换 Event Switch

事件切换可以用来引导 EI 上的输入事件流进入输出事件 EO0 或 EO1。设置为 “FALSE” 的 G 将事件切换到输出EO0；设置为 “TRUE” 的 G 将事件切换到输出 EO1（图5.9）。

延迟事件推进器 Delayed Event Propagator

Delayed Event Propagator 提供了一种方法，将到达输入 START 的事件延迟一个由输入 DT 给出的定义时间。例如，如果 DT 被设置为 100毫秒，那么在每一个到达输入 START 的事件之后 100毫秒，输出 EO 将产生一个事件，前提是输入事件至少相隔 100毫秒。

然而，如果在 EO 的输出事件产生之前，又有事件到达输入 START ，这些事件将被忽略，因为没有输入事件队列。如果在输入事件被延迟时收到 STOP 事件，它将被取消，并且不会产生输出事件。

请注意，这个模块需要与底层资源进行交互，所以用一个简单的时序图来描述。一般来说，定时只能通过资源之外的某种形式的交互来实现，例如，通过使用设备子系统中的定时器电路（图5.10）。

重启事件发生器 Restart Event Generator

重启事件发生器在资源冷（COLD）启动和热（WARM）启动时提供单一事件，也在资源被某些外部代理停止时提供单一事件。大多数应用程序可能需要这个块的至少一个实例来启动触发事件，开始执行网络中的功能块链，如图 5.1 和图 5.2 所示。

这个模块需要与资源进行交互，因此用时序图来描述（图 5.11）。

循环事件发生器 Cyclic Event Generator

循环事件发生器用于以固定的时间间隔产生一个事件流。事件流在事件到达输入 START 时开始，在事件到达输入 STOP 时停止。输出事件之间的周期由 DT 的值来设定。
这个块被描述为一个复合块，使用一个延迟事件传播器 E_DELAY 的实例。从 EO 到 START 的反馈路径确保了在最初的启动事件后，以及随后的每个输出事件后，新的事件被延迟（图5.12）。

事件序列发生器 Event Train Generator

事件序列发生器在输出端 EO 产生一列事件，每个事件之间有一个给定的间隔。事件的数量由输入 N 的值设定，间隔由输入 DT 的值定义。已经产生的输出事件的数量在输出 CV 上给出。
如果在输入端 STOP 上收到一个输入事件，事件输出序列将停止。再有一个 START 事件将导致新的输出事件列产生（图 5.13）。

该块被定义为一个复合块，使用了事件驱动的上升计数器、事件开关和延迟事件传播器功能块的实例；这些在本章都有描述。

事件序列表驱动的发生器 Event Train Table-driven Generator

事件序列表驱动的发生器在输出端 EO 上提供了一个事件序列，其中事件的数量和事件之间的间隔可以被指定。事件的数量由输入 N 给出，TIME[N] 数组由输入 DT 定义每个连续的输出事件之间的间隔。

例如，如果 DT 被设置为大小为 4 的时间数组的值，即 TIME[4]，那么第一个和第二个事件之间的间隔将是 TIME[0] 的值，第二个和第三个之间的间隔是 TIME[1] 的值，以此类推（图5.14）。

注意 ⚠️

如果数组的大小是 m，那么 N 的值应该是 m+1。例如，如果序列上有五个输出事件，那么时间数组中就需要四个间隔。

这个块被定义为使用表控制块E_TABLE_CNTL 和延迟事件传播器 E_DELAY 的实例的组合。

E_TABLE_CNTL是一个特殊的支持块，用来从 TIME[4] 阵列中选择延迟时间，因为输出事件被计算。在这种情况下，它是为大小为 4 的数组设计的，但通过改变测试 CV 的表达式中的常数，可以用于任何大小的数组。

单独事件表驱动的发生器 Separate Event Table-driven Generator

分离事件表驱动的发生器用于在每个事件输出端产生单个事件，每个事件之间有一个定义的间隔。事件的数量由输入 N 定义，输出事件之间的时间间隔由输入 DT 上设置的时间阵列给出（图 5.15）。

例如，假设 DT 的输入是一个大小为4的时间数组，即 TIME[4]，输入 N 被设置为 4，该块被定义为有 4 个输出事件。那么当一个事件到达输入 START 时，在 TIME[0] 周期后将在 EO0 产生一个输出事件，在 TIME[1] 周期后将在输出事件 EO1 产生一个进一步的输出事件，以此类推，直到所有 4 个输出事件都发射一次。

如果在输入端 STOP 上收到一个事件，输出事件的产生就会停止。随后的 START 事件可以触发一组新的输出事件。

该模块被定义为使用事件列车表驱动的发生器和事件解复用器的实例的组合。

事件驱动的双稳态 Event-driven Bistable（设置主导）

事件驱动的双稳态（设置主导）提供了一种锁住事件到来的方法。当事件到达 "Set "输入 S 时，其输出 Q被设置为 TRUE。当事件到达 "reset"输入 R 时，输出 Q 被清除为 FALSE。

事件驱动的双稳态 Event-driven Bistable（复位占优）

事件驱动的双稳态（复位主导）也提供了一种锁定事件到来的方法。当一个事件到达 “Set” 输入 S 时，它的输出 Q 被设置为 TRUE。如果一个事件到达 “reset” 输入 R，输出 Q 被清除为 FALSE。

D（数据锁存）双稳态 D (Data Latch) Bistable

数据锁存器双稳态在一个时钟输入事件（CLK）到来时存储布尔输入 D 的状态。如果输入状态被反转，就会产生一个输出事件 EO；存储的布尔值的状态被提供给输出 Q（图 5.18）。

布尔上升沿检测器 Boolean Rising Edge Detector

当数据输入 QI 从 “FALSE” 变为 “TRUE” 时，布尔上升沿检测器产生一个输出事件 EO，同时用输入事件 E1 测试。图 5.19中的时序图最能说明这一点。

这是一个复合功能块，使用了数据锁存器和事件开关块的功能。因为数据锁存器只有在输入状态改变时才会产生输出事件，所以只有在从 “FALSE” 到 “TRUE” 的变化时才会产生事件。事件开关确保只有正向转换的事件被选中。

布尔型下降沿检测器 Boolean Falling Edge Detector

当数据输入 QI 从 “TRUE” 变为 “FLASE” 时，布尔型下降沿检测器产生一个输出事件 EO，同时用输入事件 E1 进行测试。图 5.20中的时序图最能说明这一点。

布尔下降沿检测器的设计与布尔上升沿检测器类似。

事件驱动的上升计数器 Event-driven Up-counter

事件驱动的上升计数器对到达输入 CU 的输入事件的数量进行计数。在对每个输入事件进行计数后，会产生一个输出事件 CUO。

事件数量的计数也在输出 CV 上提供。当计数达到 PV 值时，不再产生输出事件，CV 保持在 PV 值；然后输出 Q 被设置为 “TRUE”，表示事件计数完成（图5.21）。

输出 Q 被重置为 “FALSE”，计数器的 CV 被清零，并产生一个输出事件 RO，这时计数器可以在任何时候被 R上的重置事件重置。

5.2 使用事件功能块

根据设想，软件工具将在其标准功能块库中提供这些事件功能块的定义。现在我们可以回顾一下图 5.2 所示的循环事件链的例子，看看如何使用标准的事件功能块对事件进行建模。

图 5.22 显示了如何通过插入标准的事件功能块来创建图 5.2 所描述的事件方案。

冷启动事件是由重新启动事件发生器的一个实例提供的（见 FB_E3）。维持两个功能块链的循环执行所需的事件序列由一个事件循环发生器提供（见 FB_E4）。使用事件合并器（见 FB_E5）合并冷启动事件和事件链。合并后的事件流被用来触发FB1的执行。从FB1产生的事件流被分成两个事件流，用一个事件分割器（见 FB_E1）来执行两个功能块链。

来自两个功能块链的最终事件流，即来自 FB2b 和 FB3b 的事件流，然后被传递到一个会合块（见 FB_E2）。这确保了在执行最后一个块 FB4 之前，两个功能块链的执行都已完成。

可能有人会说，增加事件功能块会增加额外的细节，使功能块网络过于复杂。然而，应该注意到，现在得到的图是一个形式化的模型，它精确地、毫不含糊地定义了块的执行顺序。

为了简化功能块图，标准规定，一些常用的事件构造可以用图形速记符号来表示。图 5.23 显示了如何用简单的图形连接器来代替事件分割器和事件合并器块。

注意 ⚠️

如果以这种方式使用图形连接器，软件工具应该记录每个连接器代表一种特定类型的事件功能块。如果图表被转换为文本形式，这一点尤其重要。

5.3 总结

我们现在已经涵盖了 IEC 61499 中定义的所有标准事件功能块，并且看到这些功能块可以用来模拟各种不同的事件方案；例如，从只需要执行一次功能块的网络，例如作为对系统冷启动的响应，到有需要循环执行的平行块链的复杂网络。

总结一下：

事件功能块为事件行为提供了一个精确的定义。
可以为常见的情况创建事件，如系统冷启动和热重启。
可以创建事件列车，使事件以固定的时间间隔发生。
事件可以被合并，或者进行 “会合”。
当布尔运算的状态改变时，可以产生事件。
简单的图形连接器可以用来表示常见的事件块。

6. 工业应用的例子

在本章中，我们将考虑如何将 IEC 61499 概念和标准功能块应用于对工业控制系统的一些示例进行建模。具体我们会：

模拟一个简单的温度控制系统及其主要功能块
考虑如何为传送带控制系统设计 FB 模型
考虑与在现场总线设备上运行的建模系统相关的问题
探索过程控制中使用的功能块的一些特殊要求

6.0 概述

通过第 2 章到第 5 章，我们回顾了定义功能块和应用程序的概念和技术。这包括对 IEC 61499 架构的基本元素的讨论，涵盖设备和资源等概念，然后我们继续展示如何使用功能块网络对应用程序进行建模。我们现在准备考虑如何将这些想法结合起来对一些典型的工业控制问题进行建模。本章将回顾一些示例应用程序，这些应用程序已被选择用来说明一些常见的控制系统问题。

因为没有足够的空间来提供详细的模型设计，所以目的是展示如何对控制系统的重要方面进行建模，而不是花时间在不太重要的细节上。因此，错误检测和恢复、发出警报和处理正常行为的异常等问题不会在以下模型中详细介绍。但是，预计读者应该能够推断出如何扩展这些模型以涵盖完整工业系统模型中所需的附加功能范围。

在以下模型中，模型上带有“#”前缀的输入值（例如 #IO_PARAMS）表示配置常量。预计用于创建 IEC 61499 模型的软件工具将提供为此类配置常量赋值的方法。在某些情况下，已知输入值是固定的，会给出字面值，例如 T#100ms 。

6.1 温度控制示例

我们将研究的第一个示例是一个简单的温度控制系统，如图 6.1 所示。在此应用中，我们有一个热处理炉。烤箱由加热器元件加热，其温度使用传感器测量。我们假设加热器由某种形式的电流调节器控制，例如晶闸管堆，并且使用热电偶准确测量温度。对于我们的模型，我们只考虑该控制系统功能的高级方面，因此不需要更精细的细节，例如如何与加热器电流调节器和传感器接口。我们还将假设热电偶线性化和冷端补偿等问题在硬件 I/O 系统内置的固件中处理。最后，我们将假设控件将全部在单个资源内的单个设备上运行。

之所以选择此应用程序，是因为它代表了范围广泛的工业仪器仪表和控制问题。在许多情况下，都会对过程进行测量，在本例中是通过读取温度，然后使用算法来调整某种形式的流量或过程变量。在此温度控制示例中，我们假设将使用简单的 PID 算法来监控温度并对加热器电流进行适当调整以稳定温度。类似的模型可用于压力和速度控制回路。

为了保持模型简单，烤箱将被控制在一个固定的温度；即设定点温度内置于控制系统的配置中，不可调节。显然，在实际系统中，设定点通常可以通过外部设备或控制面板进行调整。类似地，假设比例范围、积分和微分时间常数等 PID 整定参数是固定的。

该控制系统的顶层应用模型如图 6.2 所示。该模型具有以下功能块：

FB_Scan1：这是一个 Scanner 功能块类型的实例，并提供“Init”和“Scan”事件。
- Init 事件触发链接在链中的其余块的初始化。
- Scan 事件每 100ms 提供一个事件来循环执行其他块。
FB_Temp1：这是第 4 章中描述的“IO_READER”块的一个实例。它用于在每次接收到“RSP”输入事件时从温度传感器读取最新值。设备 I/O 子系统的温度传感器地址在常量 #T1_ADDR 中指定。该块提供了一个服务接口，用于从设备 I/O 子系统访问 I/O 值。当从温度传感器获得新值时，该块触发其输出事件“IND”。
FB_PID1：这是 PID_SIMPLE 块的一个实例，提供调节加热器电流的控制算法。它有两个输入事件 “INIT” 和 “RUN”。
- “INIT事件用于初始化 PID 算法使用的内部变量。
- “RUN”事件触发 PID 算法的执行。这会导致 PID 算法采用过程值 (PV) 和设定点 (SP) 的最新值，并计算其输出的新值以驱动加热器。当 PID 算法运行时，输出事件 “OK”与输出 “OUT” 一起产生。
注意 ⚠️

每次 FB_Temp1 块接收到新的温度值并引发事件 “IND” 时，PID 算法都会运行
FB_Heat1：这是第 4 章中描述的 IO_WRITER 块的实例，用于将 FB_PID1 产生的新输出值写入加热器电流调节器。事实上，与 FB_Temp1 一样，这是一个服务接口块，它通过资源接口将值发送到设备 I/O 子系统。在这种情况下，输入 SD_2 上的值将发送到地址 #H1_ADDR1 所指定的 I/O 设备。

注意 ⚠️

每次 FB_PID1 更新其输出时都会运行此块。

顶层模型显示了划分为功能块的主要功能，并清楚地描述了执行控制。这种划分允许设计修改很容易建模。例如，可以使用替代算法，只需用 FUZZY 逻辑控制功能块替换 PID_SIMPLE 块的实例。

这是一个扫描执行策略的示例，其中功能块以定期和重复的更新速率运行；这是典型的闭环控制设计。在这种情况下，假定更新率为 100 毫秒。在反馈控制回路中使用功能块有时被称为“直接数字控制”。从数字控制的一般理论来看，存在一个理论上的最小信号采样率，信号采样率应达到该最小率才能提供稳定和准确的控制。这通常小于受控过程对阶跃变化的响应时间常数的一半。在实践中，建立适当的采样率可能需要有关设备响应时间、过程时间常数等的详细信息。这些问题不在本书的讨论范围之内。然而，了解受控过程的时间方面显然是控制系统设计和建模的一个重要方面。

用于创建 FB_Scan1 的扫描器功能块类型是使用标准事件功能块构建的复合功能，如第 5 章所述：参见图 6.3。

扫描器功能块使用“E_RESTART”块的实例来提供初始化事件 “INIT”，并使用 “E_CYCLE” 块的实例来产生循环事件 “SCAN”。

注意 ⚠️

“SCAN” 事件的周期由配置常量 T#100ms 定义，即该块每 100 毫秒生成一个事件。

PID_Simple 功能块类型规范被定义为基本功能块，并根据以 IEC 61131-3 高级语言结构化文本 (ST) 编写的执行控制图 (ECC) 和算法来指定。但是，请注意，只要明确定义了映射到 FB 输入和输出的规则，任何语言都可以用于该算法。

该块的部分类型说明在图 6.4 中给出；这显示了外部类型规范和内部类型规范。 ECC 显示当此块分别接收到 “INIT” 和 “RUN” 事件时存在的两个状态 “INIT” 和 “PID_RUN”。当 “INIT” 状态激活时，初始化算法“ALG_INIT” 运行；同样，PID 算法 “ALG_PID” 在 “RUN_PID” 状态激活时运行。当任一算法完成时，ECC 总是返回到初始 “START” 状态。

图 6.2 所示的功能块图显示了在单个资源上运行的功能块网络。通过使用服务接口块（例如 PUBLISH 和 SUBSCRIBE）在资源之间传输数据，可以将同一模型分布在多个资源上运行。例如，这个应用程序可以在两个控制器上运行，如第 3 章中回顾的子应用程序示例所示。

1. 介绍

背景

IEC 61499 function block standard

为什么使用功能块？

功能块与对象的联系与区别

2. IEC 61499中的模型与概念

2.1 系统模型

2.2 设备模型

2.3 资源模型

2.4 应用模型

2.5 功能块模型

2.6 功能块类型

基本功能块类型

基本功能块的执行模型

复合功能块类型

服务接口功能块类型

2.7 分布式模型

2.8 管理模型

2.9 运行状态模型

2.10 使用适配器的通用接口

2.11 IEC 61499 实体的文本语法

【示例】- 3选2投票算法

2.12 总结

3. 定义功能块和子应用程序类型

3.1 类型与实例

3.2 不同形式的功能块

3.3 基本功能块的定义

对外接口声明

内部行为

执行控制图（ECC）功能

文本语法（Textual syntax）示例

基础功能块实例的行为

算法的执行

3.4 复合功能块的定义

复合块类型规范的规则

事件连接的规则

数据连接的规则

复合块示例

WITH 结构的使用

复合功能块的执行

复合功能块的文本语法示例

3.5 子应用的定义

子应用类型规范的规则

子应用的执行规则

分布式子应用实例

3.6 总结

4. 服务接口（Service Interface）功能块

4.1 类型定义

SI 功能块的标准输入和输出

事件输入

INIT

REQ

RSP

事件输出

INITO

CNF

IND

数据输入

QI: BOOL

PARAMS： ANY

SD_1, ... SD_N: ANY

数据输出

QO: BOOL

STATUS： ANY

RD_1, ..., RD_N: ANY

4.2 SI 功能块的行为

SI 标准事件的语义

文本语法 - SI功能块示例

4.3 伙伴式（Partnered）服务接口功能块

4.4 管理功能块

被管理的功能块

4.5 总结

5. 事件（Event）功能块

5.0 概述

5.1 标准事件功能块类型

事件分割器 Event Splitter

事件合并器 Event Merger

两个事件汇合 Two Event Rendezvous

允许性事件推进器 Permissive Event Propagator

事件选择器 Event Selector

`WITH` 结构的使用

`INIT`

`REQ`

`RSP`

`INITO`

`CNF`

`IND`

`QI: BOOL`

`PARAMS： ANY`

`SD_1, ... SD_N: ANY`

`QO: BOOL`

`STATUS： ANY`

`RD_1, ..., RD_N: ANY`