IEC61499 是分布式工业测量，控制和监控系统的功能块标准，既然它是面向工业测量和控制的系统，对系统的确定性（Deterministic）要求必然也比较高。确定性又是安全性的前提。保证系统的确定性的两个重要措施是保证系统的实时性和同步性。 分布式系统结构又进一步增加了实现确定性的难度。本文探讨在实现IEC61499 的时间敏感性应用（time-critical Application) 过程中，如何满足IEC61499 设备中功能块执行的确定性，实时性和同步性的一些问题。

实时系统（Real-time syetems）

大多数工业控制系统都是实时系统(Real time Systems)。这样的控制系统从设备内部的控制（比如CNC，自动化设备中控制系统）到生产过程控制系统。我们经常提到实时系统，不过并没有在意它的确切定义。作者认为比较贴切的定义是-“实时系统是在有限和规定周期的时间内响应外部激励的信息处理系统“。从上面的定义看，实时系统能够在规定的周期内响应外部激励。它强调的是规定的周期内，而不是我们通常讲的“快速响应“，实时(real time)不是意味着快速（fast）,快速是指平均响应时间。而实时是指每一次响应都不超过规定的时间周期。 在一个实时系统中，不仅要求逻辑结果正确，而且要求递交结果的时间正确。超时的响应同样是系统故障。

实时系统的响应期限（Dead line）

  实时系统并不是响应时间越快越好， 响应时间越短，意味着成本越高。不同的应用场合对实时性的要求是不一样的，比如像通信系统的中信号处理是一个对响应时间要求比较高的实时系统，信号采样频率高达每秒几百兆。而对于工业控制系统而言，响应时间通常10ms~100ms 。 低于10ms响应周期的系统称为“强实时系统“。

     假设一个阀门需要10秒钟将从开启到关闭（0% 到100%）。流量传感器的精度为1% 的话，那么采样周期选择为10ms。

     发动机控制器，如果发动机的转速为6000转/分钟，那么曲轴每10ms 转360 度。如果我们的控制精度要求达到0.1 度的话， 采样周期应该为27 微秒。

实时系统的不同模式

     实时系统根据对实时性要求的不同，可以分为：

  -硬实时（Hard Real-Time systems）

  响应时间超过期限（Deadline）时将引起生命和财产损失。例如，火车来时，红灯必须在规定的事件内亮。硬实时要求在规定的时间内必须完成操作 ，硬实时系统不允许超时。硬实时也称为安全敏感（Safety-critical ）实时计算机系统.

 -软实时系统（Soft Real-Time）

如果响应时间超过期限，但是仍然具有利用价值。在软实时里面处理过程超时的后果就没有那么严格。

 -固实时系统（Firm Real-TimeSystems）

如果在规定的期限内计算没有完成，该计算结果就没有利用价值了，但是不会造成严重后果。典型的例子是预测系统。

系统同步

某些控制系统需要各个部件之间实现时间同步来保证系统的确定性和实时性。比如机器人控制，多轴运动控制系统，设备数据检测等等。一个独立设备的时钟同步是容易做到的。但是基于网络的分布式系统会变得复杂一点。IEEE1588 是网络测量和控制系统的精密时钟同步协议标准。目前许多的处理器芯片的以太网接口支持1588 协议。

IEEE1588的基本原理是网络中有一个主节点不断地发送时间标签，其它节点根据受到的时间标签与自己的时钟进行修正.保持全网同步的。流行的实时通信协议都支持网络同步技术。

IEC61499 运行环境

   IEC61499 标准将一个分布式工业控制系统定义为由网络连接的多台设备构成的系统。每个设备上由一个或者多个资源。这里的资源。

 

 

资源是能够运行IEC61499 功能块网络的运行环境（runtime），你可以将资源理解为运行功能块应用所需要的一组程序（或者线程）构成。

一个完整的分布式控制应用将会分解为若干段，分别部署到各个设备的资源上运行。资源是运行功能块网络的最小单元。

 

  IEC61499 功能块应用的运行基础是计算机硬件，它们可能是基于X86 的高性能处理器，也可能基于Arm 处理器为主的低成本芯片。Arm 处理器由多个Coetex-A 核构成多处理器SOC 芯片。比较流行的NXP 的i.mx 6，i.mx8 和瑞芯微，全志公司的Arm 芯片。最近ST 公司也推出了STM32MP1系列产品。

影响IEC61499 运行时实时性的因素

基于IEC61499 标准的设备是一个软件为中心的实时系统，功能块网络图看上去与硬件系统的原理图十分相似，但是它们运行的行为却不像硬件系统那么确定。由许多的因素影响IEC61499 功能块应用的实时执行，它们包括：

处理器性能

这是显而易见的。处理器的计算性能直接影响软件的执行时间。

IO 接口性能

在带有操作系统的设备中，应用程序通过IO驱动来控制硬件。它不像裸机的嵌入式系统那样可以简单直接地控制硬件，哪怕是控制一个LED 灯的状态，都将通过一系列复杂的调用才能够完成。因此，通常在带有OS 的设备中，除了PCIe 接口的网络，EMMC 存储器，GPU 等标准化外围电路以外，IO控制的实时性比起裸机系统更差。为了解决这个问题，嵌入式处理器厂商尝试开发了所谓异构性多处理器架构，将多个cortex-A 处理器和cortex-M 集成在一起，由cortex-M 完成IO 的实时控制。而cortex-A 完成数据处理。例如NXP 公司的i.mx 系列处理器就具有这样的架构。

为了满足实时系统的性能要求，IEC61499 功能块需要借助于硬件实现 也可以使用软件实现，或者软硬件混合实现。显然采用软件实现实时系统是最灵活和低成本的。随着处理器性能的不断提高，以及多处理器架构的出现，软件实时系统也来越流行，出现个各种各样“软件定义“的实时系统。例如软件无线电，软件PLC ，软件定义网络等等。使用软件定义的前提是通用处理器的性能足够强大。对于IEC61499 设备而言， 与IO接口相关的逻辑需要采用处理器的IO外围电路，FPGA ，或者专用IO 处理器来实现。比如1KHz 以上的脉冲产生，PWM 信号，脉冲计数等等，应该采用处理器的外围电路（TIM）来实现。而1K以上的ADC 模拟量采样和信号处理.可以使用专用IO处理器来实现。

   在设计IEC61499 功能块时，经常需要在软硬件实现方案之间做出权衡。一方面能够提高设备的实时性能，另一方面可以大幅度降低处理器的负荷。

操作系统性能

前面提到，IEC61499 模型中的资源提供了功能块应用的运行环境，它们由多个线程构成。操作系统的实时性能将直接影响到设备的性能。可以选择商业化的实时操作系统 ，例如Vxworks，QNX 等，也可以考虑开源OS，例如各种版本的Linux 。

功能块应用中功能块的执行时间

IEC61499 是一个开放性系统，用户和第三方开发者能够开发面向各种应用的功能块，这些功能有的可能比较简单，其中算法的执行时间很短，有的可能比较庞大，执行时间比较长，功能块内部算法甚至会通过其它外部微服务来完成。比如信号滤波，FFT 变换等等。应用中调用不同的功能块将会影响整体的执行时间。

功能块应用的结构也将会影响实时性能。如果你习惯PLC 扫描方式（SCAN），可能更加倾向采用SCAN 方式来编写IEC61499 的应用程序。

例如下面是一个按键控制LED指示灯

 

功能块应用按照1ms 的周期读取Button 的状态，并且传递到LED 输出端。这类似与程序“轮询“方式，显然占用的CPU 负荷更多。如果我采用类似“中断方式的IO 功能块，当GPIO 状态发生变化时能够主动产生IND 事件。不需要REQ请求。那么，功能块应用占用CPU 的时间大大降低，这类似于”中断“ 方式。事实上，硬件中断是一个典型的”事件“。

 

同一设备中其它应用程序

与传统PLC 不同，IEC61499 设备中能够运行其它的服务来支持功能块的运行，例如本地数据库，HMI ，数值计算，网络协议等各种应用服务。IEC61499 运行时（runtime）和其它软件同在同一个硬件平台上运行，它们会相互影响和牵制，其它应用程序运行多了，势必会导致IEC61499 运行时的性能下降。

在边缘服务器中，为了实现应用程序的隔离和解耦，流行采用容器（docker）技术。它们同样需要占用处理器资源。

网络和协议的性能

功能块执行时间由两部分构成，一是功能块中算法的计算时间，二是功能块之间的事件和数据传递的事件。一个资源内的功能块之间的事件/数据传递是通过内存访问来完成的。相对访问时间比较短。如果是跨资源之间的事件/数据传递可能涉及线程之间的消息交换。而不同设备功能块之间的事件/数据传递要通过网络协议来完成。网络传输会增加数据传输的时延。对于响应时间要求高的分布式系统而言，选择一个合适的实时通信网络及其协议是非常重要的。

IEC61499 并没有对网络的类型和协议做出规定，不过目前大多数的实现都是基于以太网上的TCP/IP 协议。虽然以太网已经高达1Gbps 。但是对应IEC61499 功能块之间的短小的碎片化数据，TCP/IP以太网的传输效率并不高，而且也不一定能够满足具体应用对实时性的要求。

如果应用对实时性要求比较高，需要使用实时性通信协议，PROFINET、POWERLINK、EtherCAT等工业网络已经可以达到比较高的实时性指标。

功能块执行的调度算法

IEC61499 运行时本质上是一个外部事件响应系统，当一个事件产生时，将调用相关的功能块执行。在一个实时系统中，外部事件是具有优先等级的。如果调度算法能够根据优先等级来调度功能块的执行，将会提升功能块执行的实时性。

如果必要，可以在IO模块中增加优先级参数。实现优先级调度。比如在下面的例子中，我们建立了一个带优先级的IO 功能块，当外部按下STOP 按键时，以最高优先级处理STOP 事件，以便应用快速停止。在这里我们假设功能块的priority 的值越大，它输出的事件优先级越高。

 

实时通信协议

前面已经提到，功能块应用的运行时间是分别包括算法和传输耗费的时间，设备之间的通信协议将影响IEC61499 功能块应用的执行性能。有许多的为实时系统设计的实时通信协议。例如Powerlink，EtherCAT，航空领域TTP 协议，汽车工业的CAN 。

实时通信协议

实时通信协议分为两种：

 -事件触发通信（Event-Triggered Communication Systems）

事件触发通信的传输是由一个状态的改变（事件）而发起。也就是说，传输是由设备发起的，而不是由通信系统发起的。采用共享通信网络（例如以太网） 时，如果两个设备同时产生了事件，可能会引起冲突。当然，共享型通信网具有防止冲突的技术。

 -时间触发通信(Time--Triggered Communication Systems)

时间触发通信的传输是由一个时间点发起的。典型的事件触发通信协议采用了时分复用技术（TDMA），各个设备分时使用通信总线。目前流行的PowerLink，EtherCAT 实时通信协议都是时间触发通信方式，对于高性能CPU，powerlink的扫描周期可达 100us~200us，抖动小于1us。

与事件触发通信相对比，时间触发通信的每一次传输都是由通信系统发起的。比如在Power link 协议中，系统有一个管理节点（MN），多个受控节点（CN）。

     -时间敏感网络（TSN）

       时间敏感网络技术基于带宽预留的方式，TSN 将数据进行所谓的Traffic Scheduling  ，对于实时要求高的周期性数据流，要预先告诉交换机，例如 Flow A to B  128 Byte 200us。然后交换机可以根据这个要求，优先调度通信流量，只有没有传送TSN 的流的空隙中，可以用来传送非TSN 的数据，这个过程称为Traffic shaping（交通整形）。

   TSN 的优点在于能够很好地实现实时数据和非实时数据在同一个网络中的传输。

IEC61499 分布式系统的通信协议

IEC61499 分布式系统的通信协议是一种事件触发通信协议。

其实，IEC61499 并没有对设备之间的网络协议做过多的规定。最普通的是使用以太网上的TCP/IP 或者UDP  协议来实现不同设备中功能块网络之间的输入输出事件和数据的交换。这是基于Client/Server 的网络方式，另外也可以采用Publish/Subscribe 的消息方式。消息方式通常需要通过一个消息代理来实现数据交换，MQTT是典型的消息系统。

Client/Server  模式

IEC61499 设备之间的通信协议可以采用最常见的Client/Server模式。其中发送端是Client模式，而接收端为Server模式。通信协议为TCP/IP，数据编码为ASN.1 编码方式。

Publish/Subscribe 模式

MQTT 消息系统是消息存储转发的方式实现消息分发的。MQTT 代理的转发时延同样依赖于运行MQTT 代理的操作系统和服务器硬件性能。对于一个独立的小型IEC61499 分布式控制系统而言，不可能单独建立一个性能强大的MQTT代理服务器，而是将MQTT 代理部署在某个设备上。MQTT 代理的性能将会受到限制。

 UDP 组播

在一个局域网中，可以使用UDP 组播方式实现高速的Pulish/subscribe 通信。这种方式的通信效率非常高。

IEC61499 设备的组网方式

IEC61499 模型下的应用系统是一个全分布式控制系统。这与传统的集中式控制系统有很大的不同。我们要突破集中控制的思维模式来构建分布式系统。而不是采用分布式技术去构建一个传统的集中控制系统。

在一个典型的集中控制系统中，使用一个运行SCADA 软件的PC 连接若干台PLC 构成。如果采用IEC61499 模型，我们当然也可以定义一个具有HMI界面的“主” 设备，连接若干台设备构成一个传统的控制系统。将控制算法功能块部署在主设备上，而其它设备承担传感器数据采集和执行部件。

 

如果采用分布式控制的思维方式，我们可以将算法功能块放置在执行部件的设备上，有传感器设备与执行部件直接通信，交换事件和数据。

 

IEC61499 系统的基础通信

IEC61499分布式系统适合各种网络架构，如果控制系统是主从架构，时间的周期性很强，对同步性要求高的场合，采用基于时间触发的协议（ Powerlink，etherCAT）比较合适。 如机器人控制，高速数据采集应用。 而对于异步事件的分布式控制使用事件触发通信协议更合适。为了提高功能块之间的事件/数据交换的实时性，可以使用TSN 时间敏感网络。将功能块之间的事件/数据交换规定为时间敏感通信（Realtime），而其它数据交换（数据库访问，云端访问，IT系统交换数据）规定为非敏感通信（Anytime）。

对于实时性要求不高的场合，我们可以为每个设备提供两个Ethernet 接口，一个用于传输实时性数据，另一个用于传输非实时数据。 一个传输Real time 的功能块之间的事件/数据交换 。另一个传输非实时数据。这不失为一种低成本的解决方案。

功能块应用的实时运行

 IEC61499 运行时的架构会直接影响功能块应用的实时运行效率。可以针对系统对实时性的要求 进行优化。它们包括：

-事件链调度算法

-多线程架构，提高运行时的实时响应能力

-动态功能块库接口优化

-与其它服务之间的接口优化

一个好的运行时就好比一个好的OS，能否针对IEC61499 功能块运行环境开发一个特别的操作系统，也是一个特别有意思的课题。只不过我没有想好它应该是什么样的？希望读者给我一点启发。

事件链和调度程序

在IEC61499 运行时内部通常会维护一个事件链（event chain），它是一个先进先出的队列，当产生一个事件后，就将该事件添加到事件链中，运行时内部的调度程序不断地读取事件队列中的事件，并且通过功能块连接表寻找与之连接的功能块执行。直到所有的事件处理完成后，暂时挂起调度程序执行，等待下一个事件进入。

功能块优先级

尽管IEC61499 标准中并没有规定功能块的执行优先级。不过，如果需要的话，我们可以在功能块中添加优先级参数。带有优先级的功能块产生的事件将排列在事件链的前面被优先执行。

功能块网络的运行的实时监测

监测的重要性

   我们已经讨论了影响IEC61499 功能块网络实时执行的各个因素。如果在设计过程中充分地考虑确定性，实时性，系统的性能将会有改善。但是我们也看到，通过设计来满足控制系统的预测性和实时性是比较困难的，而且对于OT 工程师而言，确定功能块网络的实时响应能力更加不容易。需要额外地进行各种测试和仿真。

IEC 61499 标准中规定了监控功能块应用中各个功能块的输入输出事件和数据值的方法，这是通过管理功能块和管理命令来实现的。在4diac 中，只要对功能块应用中的某个功能块的输入输出事件或者数据击右键，选择 watch 选项。就能够监控相应事件或者数据的当前值。

不过，这种监控是相当粗略的。首先监控是设置事件间隙的，比如 设置为200ms ，而且由IDE 开发环境异步发起的命令。所以，某些事件和数据将会忽略和丢失。

其次，IDE开发环境的管理命令是基于XML 的，解释执行这些命令并返回结果，是相当耗费设备运行资源的。过于频繁地发送管理命令将会影响功能块网络的运行。

最后，类似4diac IDE ，它们仅仅是在功能块网络图上标注的时间或者数据的值。没有更进一步的分析工具。例如每个功能块的执行时间，两个事件之间的时间间隔等等。

在IEC61499 运行时程序中增加测试功能非常重要。IEC61499 开发环境（比如4diacIDE）的在线检测实时性差，而且采用了XML 格式的管理命令，处理XML 命令增加了处理器和网络的负载。所以，实现IEC61499 控制系统运行监控更好的方法有两种：

日志记录

将事件的时间标签记录在内存，然后成块地写入文件中。然后通过分析程序读取日志文件，然后可视化显示和分析，通常日志文件只能记录最近的一段事件时间标签。而且记录事件也会增加一部分处理器负载。日志记录的格式不能过于复杂，要不然也会影响运行的实时性。

硬件事件信号

在我们开发嵌入式设备的过程中，比较喜欢采用调试硬件的方式来检测软件。结合IEC61499 功能块模式。可以使用若干GPIO 输出信号作为事件指示信号，当功能块网络中产生某一个事件，就在相对应的GPIO 输出端子上输出一个短脉冲，或者翻转状态。然后使用示波器，或者逻辑分析仪来观察不同事件之间的关系。利用逻辑分析仪也能够精确地测量功能块执行时间。

在下面的例子中，使用QX IO 功能块实时监控 E_CYCLE 事件E0 和E_SWITCH 事件EO1 。

 

         你可以通过示波器观测两个事件的频率和相互关系。在我们开发嵌入式实时系统的实践中，采用示波器。逻辑分析仪调试程序一直是我们行之有效的方法。

  对于变化比较慢，并且没有周期性的事件，适合采用日志方式，高频率周期性事件适合使用硬件监控方式。

分析软件

 

结束语

   以软件为中心的控制系统带来了灵活性和可扩展性。IEC61499 设备上可以安装各种服务和功能块库。构建功能强大的分布式控制系统。不过也正是这个原因，开放性系统的确定性和实时性显然不如PLC 这样封闭式系统可靠和确定。因此，开发和使用IEC61499 开放性实时系统时，要注意如下几点：

   -对于特定的应用系统而言，安装的应用软件是预先确定的，经过严格测试的。

   -功能块应用需要预先经过严格的实时性，确定性测试。

   -处理器和网络的负荷能力要具有足够的富余量。满足时间峰值的要求。

   -可以通过参数设置敏感功能块的优先级。

   -实时性要求高的IO 功能块可以采用硬件方式实现内部算法

   -可以采用实时通信协议实现IEC61499 系统中的通信。比如powerlink，etherCAT，TSN

   -使用硬件信号来检测功能块运行是一个简单而直接的方式。

     如何保证 控制系统的确定性，安全性，实时性和同步性是一个非常复杂的问题，其中涉及许多的行业经验。就实时系统而言，国外学者开设了一门课程，并且写了厚厚的一本书。在这篇博文中只能写一些我们在设计IEC61499 控制器时的某些思考。难免有很大的局限性。就算抛砖引玉吧！希望引起读者的思考和建议。