通信中间件如何支持软实时应用



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

硬实时定义认为任何错过的截止日期都是系统故障。这种调度被广泛用于关键任务系统,在这些系统中,不遵守时间约束会导致生命或财产损失。

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

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

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

这是真的吗?通信中间件的其他相关功能是否支持软实时应用程序?

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

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

研究界"硬"实时计算模型的核心是任务有硬的截止日期,所有这些截止日期都不能错过,否则系统就会失败。满足截止日期是"及时性"标准,保证所有截止日期都能满足是"可预测性"标准——即可预测性是"确定性的">

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

该模型要求与硬实时任务相关的一切都是静态的(提前知道)——也就是说,它要求提前知道系统的时间演变。这一要求非常严格,在大多数情况下是不可行的。有一些重要的硬实时系统(至少被认为)满足了这一要求。众所周知的例子包括数字航空电子飞行控制、某些医疗设备、发电厂控制、铁路道口控制等。这些例子是安全关键的,但并非所有的硬实时系统都是(我们将在下面看到,大多数安全关键系统不是也不可能是硬实时的,尽管有些系统可能包括简单的低级别硬实时组件)。

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

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

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

但考虑一下:如果该系统的效用因不满足其中一个或任何一个标准而降低,比如23%的任务延迟超过5%,或者不到20%的任务延迟,但其中10%的任务延迟大于5%,或者除了可预测性只有0.8之外,其他所有标准都满足了,该怎么办。存在许多具有这种动态特性的实时系统。

我们需要具体说明系统退化(比如说,系统的"效用"或"价值")与这些及时性和可预测性标准中有多少以及在多大程度上得到满足或没有得到满足有关。事实上,这个模型是许多实际存在的实时系统的一个概念性例子,这些系统尽可能对安全至关重要——例如,用于防御核武装敌对导弹(以及许多其他军事作战系统,因为它们都具有各种固有的动态不确定性)。

现在,我们回到需要指定实时系统的及时性和可预测性如何与系统的实用性相关的问题。一种成功使用的解决方案被称为"时间/效用函数"(或"时间/值函数"),并在real-time.org上进行了详细描述。每个任务的函数都源于系统应用程序的物理性质。系统的及时性和及时性的可预测性是基于任务的及时性和可预测性的,例如,通过其单个效用的加权累算。

软实时系统(在realtime.org上描述的精确定义的意义上)是一般情况,而硬实时系统是一种特殊情况,适用于小得多的实时问题领域。所有硬实时系统和软实时系统都可以通过时间/实用程序功能指定和创建。

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

答案的一个明显来源是开放组实时CORBA(RTC)标准(谷歌,有大量详细信息可用)。

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

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

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

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

相关内容

  • 没有找到相关文章

最新更新