实时IEC61499漫谈-实时功能块，运行时和OS

Posted 2022-01-08 姚家湾

        许多人都会问一些可爱的问题-IEC61499 是否有前途？它能成为自动控制系统的发展方向么？它会取代IEC61131么？

         负责地回答这些问题是困难的，人类并没有多少预测未来的能力。不过，我的回答是所有的答案取决于人们对IEC61499 投入多少热情。相比传统的PLC，IEC61499 更能够融入最新的IT技术。创新的机会更大。

        尝试简单地取代现有传统PLC 的想法是愚蠢的。模仿秀永远成就不了艺术家。IEC61499 要取得成功，需要寻找自己更适合的场合，也就是所谓“杀手级应用”（Killer Application）。因此，我们不能停留在标准的文本上，要大胆地去探索IEC61499 的潜能。实时IEC61499 是作者最近的思考。为了理清楚自己的心路历程，提出一些不成熟的，基本的想法。与大家分享。

时间触发也是一种事件触发

        前面我们已经多次提到实时控制系统中软件组件的执行有两种方式，时间触发和事件触发，时间触发是同步的，而事件触发是异步的。事实上，时间触发本质上是周期性产生的一个事件。所有说，时间触发是基于时间的事件触发。一切皆为事件。时间触发与事件触发并不对立。事件触发更加宽泛一点。

事件的优先级

                在IEC61499 标准中并没有规定事件执行的顺序，也没有事件优先级的概念。在我们看到的IEC61499 开源运行时中，事件一般是采取了事件队列来响应事件的。遵循的是先进先出的原则。

  但是，在实时系统中，事件的优先级是十分重要的。比如，在计算机硬件体系结构中，中断是一种处理外部事件的方式。大多数MCU中都实现中断优先级机制，是CPU 能够快速地响应实时性要求高的外部事件。

  那么在IEC 61499 功能块为基础的控制系统中是否能够实现事件的优先级响应呢？笔者认为是完全可能的，而且完全符合IEC61499 的标准。

  这需要两方面做出努力。

1 功能块要指明输出事件的优先级

2 运行时事件队列使用优先级队列

3 使用事件优先级调度

   一个事件可能会触发多个功能块的执行，可以通过事件调度功能块来调度那个功能块将被优先执行。

   为此，我们可以设计一个schedule 功能块 schedule。该功能块有一个EI1 事件输入，4 个事件输出（EO1 ~EO4）。当输入事件到达时，可以依次产生输出事件，其中EO1 的优先级最高。EO4 的优先级最低。

也可以设置一个优先级功能块，改变输出事件的优先级。

在上图中，RT_SYNC 产生的输出事件以优先级1 进入IW 功能块。

实时IEC61499 系统的调试与监控

        IEC61499 系统通过管理命令（Managment Command ）可以实现对功能块的数据和事件的监控。在4diac 中使用monitor 的方式来监控功能块的事件和数据。当实现实时IEC61499 分布式系统时，这些monitor 命令会增加网络的流量，影响系统的实时性。另一方面，这些管理命令是异步探询方式进行。在IDE 中，可以设置探询的周期。如果探询周期设置的过长，会丢失一些事件和数据的变化。这样给系统的调试带来了不确定性。因此，在实时IEC61499 系统中要采取更好的方式来实现精确时间的监控与调试。

         笔者设想开发一个EvenScope 软件来监控功能块的事件和数据。EventScope 是PC 上的一个应用程序。

1同步监控

  当新的事件到来时才发送监控数据。

2  通过网络检测事件和数据

类似于wireshark 软件的方式。

设备之间的事件和数据交换都是通过网络实现的。通过网络能够实现这些事件和数据的监控，这样避免了重复的数据传输，并且可以在确定的网络时间片发送。

   即便是设备内部功能块之间的事件和数据也输出到网络上。

3 具有实时和存储功能

实时IEC61499网络

        在我前面的博文中已经讨论了关于实时网络的有关问题。这里进一步强调我的观点。在一个系统中，如果每个参与者都是自律的话，那么它们之间的信息交互将是有序的。例如，我们召开一个座谈会是往往规定从左到右顺序发言，每个人发言10分钟。如果大家都遵守这个规则的话，主持人就非常的轻松。同样地，大量复杂的网络协议是为无序的信息交换制定的。比如时间敏感网络。我倾向让参与者自律。

   关于实时操作系统

        我们可以进一步思考，实时IEC61499 的支撑环境应该是什么样的呢？在此，我们先来谈谈PLC的程序执行。大家知道，早期的PLC 是使用继电器实现逻辑控制的。也就是说，它们完全是硬件实现的。当微处理器出现之后，PLC 内部使用了CPU和程序来实现控制逻辑。现代PLC中也使用了实时操作系统以及各种网络协议。自动控制行业的专家总是将在通用操作系统上运行的PLC控制程序成为“软件PLC”，普遍认为软件PLC 没有PLC 设备可靠。这其实是一种误解。某种意义上讲，现代的PLC 都是软件PLC。它们之间的唯一差别是PLC设备是在特定硬件平台上实现的实时操作系统和程序具有更高的实时性，确定性和稳定性。它们经过了厂商预先反复的测试。确保了软硬件匹配的的更好。如果重视软硬件的相互匹配，在通用硬件平台上，同样能够实现可靠运行的PLC 系统。比如倍福公司的工业电脑就是在微软公司为其定制的windows 下运行。同样非常的可靠。

        PLC 中大多数使用实时操作系统（RTOS），比如VxWorks OS。这是一个可靠性，实时性极强的实时操作系统。不过，RTOS的处理能力也是有限的，设想编写一个“巨大”的程序在PLC上运行， 也会出现性能下降问题。只是PLC 设备预留了足够的资源来保证在特定的应用中的需要。

        实时操作系统本质上是操作系统，只是内部调度算法上考虑了对外部事件的响应事件而已。但是令人遗憾的是，几乎所有的OS 调度算法都只是“尽力而为”，这就像我们排队进迪士尼乐园一样，长者可以优先入园，但是如果长者多了，乐园也无能为力。

        于是引发笔者进一步地思考一个根本性的问题，“尽力而为”的调度算法适合实时系统么？是否具有更好的程序调度方式满足实时系统呢？

为了进一步讨论这个问题，我们来分析一个近乎于常识的问题，硬件逻辑和软件逻辑的差别。

        一个纯硬件系统中，在数字电路中，有组合逻辑和时序逻辑两部分，组合逻辑由简单的与或非电路，编解码器等组成，它们的输出由输入逻辑产生，没有与时间有关的逻辑。时序逻辑中有一个时钟电路和寄存器。它们能够时序与时间有关的逻辑，比如状态机。现代计算机正是在图灵机理论的基础上开发出来的。

        在硬件实现的逻辑中，大多数功能是基于时钟同步的。当时钟信号的上升沿到来时，执行某一个硬件逻辑，在某个下降沿之前必须完成这个逻辑的运算，并且置入结果。所有的电路都具有“节拍”，集成电路的规格书中有大量的篇幅描述时序图。

        硬件电路的设计和调试也主要是时序的仿真和观察。防止出现抖动，竞争，误触发等常见问题。

        另一方面，几乎所有的硬件逻辑都可以采用软件来实现，事实上，现在已经能够使用软件高级程序设计语言来设计FPGA的逻辑。但是，由于软件尽力而为的调度和执行，执行时间是不确定的。有时候产生的脉冲信号抖动非常严重。只有充分考虑程序模块的时序关系，并且在高速的CPU上才能够替代硬件逻辑。

                在我前面的博文中多次提到，IEC61499 的功能块网络与硬件电路的逻辑图非常相似。功能的块的事件相当于硬件的时钟信号。如果严格地处理好事件的时序关系，想必能够实现类似硬件的确定性逻辑。操作系统“尽力而为”的调度算法不再适合功能块网络的执行，取而代之的是基于事件的调度方式。

        最佳的实时IEC61499 平台应该是一个多核处理器芯片。其中一个核为Realtime 核，运行IEC61499 运行时，基于事件队列的单一程序的效率比多进程结构高。保证功能块网络的实时性和确定性。其它的核运行支撑资源和服务，诸如网络，IO接口，时钟服务等，它们可以基于传统实时OS 尽力而为，优先级进程调度算法。目前的所谓跨界处理器，一个Cortex-M 内核加一个或者多个cortex-M 的处理器芯片也许比较合适。

结束语

        IEC61499是功能块的通用标准。通过开发各种功能块，可以具有很大的灵活性，设计满足各种控制系统的需求。从本文的描述可以看出，通过设计一个实时功能块库，可以满足实时系统确定性的要求，当然这需要IEC61499运行时支持这些功能块。

        技术标准都是为兼容性而指定的，实现不同厂商的设备具有互操作性。符合技术标准，只是设备供应商最基本的要求。在此基础之上，提高设备的性能，才是产品的竞争优势。

文章中我们还讨论了实时IEC61499 运行时的软硬件实现的一种方法。