【问题标题】:How can communication middleware support soft real-time applications?通信中间件如何支持软实时应用?
【发布时间】:2017-10-28 17:45:03
【问题描述】:

如今,“实时”这个概念有很多不同的解释。在这个question 中提供了两个定义:

硬实时定义将任何错过的最后期限视为系统故障。这种调度被广泛用于任务关键型系统,在这些系统中未能遵守时序约束会导致生命或财产损失。

软实时定义允许经常错过最后期限,只要任务及时执行,它们的结果就会继续有价值。已完成的任务在截止日期之前可能会增加价值,而在截止日期之后价值会减少。

在我的研究中,我得出以下结论:

  • 如果中间件提供对系统资源的可预测和高效的端到端控制,则它支持硬实时。就像设置中间件创建的所有线程的线程优先级一样。
  • 在我看来,良好的性能是支持软实时应用程序最相关的因素。

这是真的吗?支持软实时应用的通信中间件是否有其他相关特性?

【问题讨论】:

    标签: real-time communication-protocol soft-real-time


    【解决方案1】:

    首先,关于实时原理和术语的精确定义,基于第一原理和心智模型,我建议您访问 real-time.org。

    实时从业者计算社区使用“实时”、“硬实时”和“软实时”的各种不一致和不完整的“定义”。实时计算研究界对“硬实时”有共识,但对“软实时”感到困惑。

    研究界“硬”实时计算模型的核心是任务有硬期限,所有这些期限都不能错过,否则系统就失败了。满足最后期限是“及时性”标准,而保证所有期限都将得到满足是“可预测性”标准——可预测性是“确定性的”。

    (在其中一些模型中,如果不干扰硬实时任务,则允许在后台执行没有截止日期的任务;通常也可以防止它们被饿死。)

    该模型要求与硬实时任务相关的所有内容都是静态的(预先知道)——即,它要求预先知道系统的时间演化。这个要求非常强,在大多数情况下是不可行的。有一些重要的硬实时系统(至少假定)可以满足这一要求。众所周知的例子包括数字航空电子飞行控制、某些医疗设备、发电厂控制、铁路道口控制等。这些例子对安全至关重要,但并非所有硬实时系统都是(我们将在下面看到大多数安全-关键系统不是也不能是硬实时的,尽管有些系统可能包含简单的低级硬实时组件。

    软实时是指一类实时系统,是硬实时系统的推广。概括包括较弱的及时性标准和/或较弱的可预测性标准。

    例如,考虑一个模型,其任务与硬实时任务一样具有截止日期。在这个特定模型中,及时性标准是允许任何数量的任务最多延迟 15%,而可预测性标准是必须保证(即确定性),就像硬实时系统一样。如果其中一项或多项任务延迟超过 15%,则系统已失败。此模型不是传统的硬实时模型,尽管它可能是安全关键模型。

    考虑另一个模型:及时性标准是不超过 20% 的任务可以迟到超过 5%,而可预测性标准是保证至少满足 0.9 的概率。违反及时性和/或可预测性标准意味着系统失败。这不是一个硬实时系统,尽管它可能是一个安全关键系统。

    但是考虑一下:如果该系统的效用由于不满足其中一个或任何一个标准而下降——例如,23% 的任务迟到超过 5%,或者不到 20% 的任务迟到但 10%其中迟到超过 5%,或满足所有标准,但可预测性仅为 0.8。有许多实时系统具有这种动态特性。

    我们需要指定系统退化(例如,系统的“效用”或“价值”)与这些及时性和可预测性标准的满足或未满足的数量和程度相关。事实上,这个模型是许多实际现有实时系统的一个概念示例,这些系统尽可能地对安全至关重要——例如,用于防御核武器武装敌对导弹(以及许多其他军事作战系统,因为它们都有各种固有的动态不确定性)。

    现在我们回到需要指定实时系统的及时性和可预测性如何与系统的效用相关联。一个成功使用的解决方案称为“时间/效用函数”(或“时间/价值函数”),并在 real-time.org 上进行了详细描述。每个任务的功能源自系统应用程序的物理性质。系统的时效性和时效性的可预测性基于任务的时效性——例如,通过对它们各自的效用进行加权应计。

    软实时系统(在 real-time.org 上描述的精确定义的意义上)是一般情况,而硬实时系统是适用于更小的实时问题领域的特殊情况。可以使用时间/效用函数指定和创建所有硬实时系统和软实时系统。

    所有这些都澄清了,现在我们可以解决您关于实时中间件的问题。

    答案的一个明显来源是 The Open Group Real-Time CORBA (RTC) 标准(Google,有大量可用的详细信息)。

    RTC 可以实现为固定优先级的基础设施,具有映射到节点优先级的 15 位系统范围的优先级。在这种情况下,最低要求是: 尊重客户端和服务器之间的线程优先级,以便在处理 CORBA 调用期间解决资源争用;限制端到端处理期间线程优先级反转的持续时间;限制操作调用的延迟。可以根据这三个要求(并且存在许多要求)构建硬实时 RTC 分布式系统——但显然底层网络 QoS 会影响实时行为。因此 RTC 提供了可插拔的特定于应用程序的网络,例如具有确定性 QoS 的网络(在 RTC 层及其以下可以实现硬实时),以及具有非确定性 QoS 的网络(但 RTC 层仍然具有三个基本固定优先实时属性)。

    更一般地说,RTC 在 CORBA 层提供软实时(在 real-time.org 上定义的技术意义上)。它通过提供称为“分布式线程”的一阶调度抽象来做到这一点。它提供了一个调度框架,不仅支持固定优先级,还支持时间/效用函数,这些函数足够通用,可以表达一类非常通用的“效用累积”软实时调度算法。这种算法(或通常是启发式算法)对于由上述应用特定的软实时系统模型组成的分布式系统是必需的。

    如果您不想使用 RTC,该怎么办?好消息是,RTC 的原理首次公开出现在不同的分布式实时系统中(在 real-time.org 上进行了描述),并且可以(并且已经)移植到其他硬实时中间件和软实时中间件中——时间系统。

    对于软实时(同样,从 real-time.org 精确定义的意义上)中间件,必须将动态及时性和及时性可预测性原则应用于中间件系统每个节点的资源管理——包括应用于调度中间件的网络(例如,访问、路由等)。这种方法的实例出现在几个博士论文中。论文,并已在多个军事作战分布式实时系统中实施。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-03-03
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-07-03
      相关资源
      最近更新 更多