硬实时、软实时和半实时之间的区别是什么?(这是一个提问标题,不需要回答)

126
我已经阅读了不同实时概念的定义,提供的硬实时和软实时系统示例对我有意义。但是,没有真正解释或举例说明什么是“确切的”实时系统。根据上面的链接:
稳健型:可以容忍偶尔错过的截止日期,但可能会降低系统的服务质量。结果在截止日期后变得毫无用处。
是否存在明显区别,区分稳健型实时与硬实时或软实时,并且是否有很好的例子说明这种区别?
在评论中,查尔斯要求我提交新标签的标签维基。我为标签提供的“稳健型实时系统”示例是一个牛奶供应系统。如果该系统在过期时间之后交付牛奶,则牛奶被认为是“无用”的。可以容忍不加牛奶吃麦片,但体验质量会下降。

当我最初阅读这个定义时,我脑海中形成的只是一个想法。我正在寻找一个更好的例子,也许是一个更好的实时牢固的定义,以改善我的概念。


15
基本上,这些定义并没有非常明确的界定。 - Hot Licks
我恢复了原始标签。我认为能够在问题上放置更具体的标签,以便于硬实时或软实时有关的问题更加有用。这会改变问题得到回答的方式。如果标签在6个月后没有被使用,标签将自动删除。 - jxh
如果你一定要为这个问题单独添加三个新标签,那么请至少添加维基并尝试找到其他适用的问题。 - Charles
12个回答

165

软实时的定义允许偶尔错过任务的截止时间,但系统仍可以继续运行,且任务完成的价值降到零或成为不可能。

例子:

  • 在线视频流服务的播放缓存。如果数据包没有按时接收,则视频会卡顿或停止播放。如果只是偶尔地出现这种情况,并且用户等待时间不会过长,那么观看体验仍然可以接受。

  • 图像处理软件的滤镜效果。如果计算耗时超过了指定的时间限制,则输出结果的质量会降低。在某些情况下,如进行艺术创作,稍微降低一些画面质量也不会影响最终的成品。


硬实时

硬实时的定义认为任何未能遵守时间限制的任务都是系统失败。这种调度在关键任务系统中广泛使用,如果不能符合时序约束,就会导致生命或财产的损失。

例子:

  • 法国航空447号班机因传感器故障引起的一系列系统错误坠入海中。飞行员在应对过时的仪表读数时,让飞机失速。机上12名机组人员和216名乘客全部遇难。

  • 火星探路者号航天器因任务优先级倒置而导致系统重新启动,差点丢失。由于一个较低优先级的任务阻塞了一个更高优先级的任务,导致后者未能按时完成。问题得到纠正后,航天器成功着陆。

  • 喷墨打印机有一个控制软件的打印头,用于向纸张的特定部位沉积正确的墨水量。如果错过了截止时间,则打印工作就会失败。

软实时的定义允许任务经常错过截止时间,只要任务按时执行,其结果仍然有价值。完成的任务在截止时间之前可能具有逐渐增加的价值,在之后则会逐渐减少。
例子:
  • 天气站有很多传感器用于读取温度、湿度、风速等。读数应该定期进行并传输,但是传感器不同步。即使与其他传感器相比读数可能早或晚,只要足够接近,它仍然是相关的。
  • 视频游戏主机运行游戏引擎的软件。许多资源必须在其任务之间共享。同时,任务需要按照游戏的计划完成才能正确播放。只要任务相对准时地完成,游戏就会很愉快,否则可能只会出现一点延迟。

Siewert: 实时嵌入式系统和组件。
Liu & Layland: 基于硬实时环境的多编程调度算法。
Marchand & Silly-Chetto: 软非周期性任务和跳跃周期性任务的动态调度。


25
多么令人愉悦的例子清单! - Erik Kaplun
1
最好的例子之一 - Vishnu N K
在447坠机事件中,飞机失速之前有很多截止日期被错过了吗?在这方面似乎所有系统都是严格的。 - Josiah Yoder
4
很好的列表,但是喷墨打印机的例子不符合硬实时要求,最多也只能算是中等实时,很可能只是软实时。 - Ab Irato
非常感谢提供示例。 - himanshuxd
1
我会将Air France Flight 447案例从这里删除,因为它与此无关。顺便说一下,主要原因是飞行员的错误。正如你所说,问题之一是传感器故障 - 这与时间无关。说这是响应时间问题就像说一个系统不是实时的,只是因为你可以用锤子打破它。 - Petr Gladkikh

130

硬实时(Hard real-time)意味着您必须绝对满足每个截止时间。这种要求的系统很少见,例如核应用、一些医疗应用如心脏起搏器、大量国防应用、航空电子等。

半实时/软实时系统可以错过一些截止时间,但如果错过太多,性能最终会下降。一个很好的例子是电脑中的音频系统。如果你错过了几位,没关系,但如果错过太多,你最终会破坏系统。类似的还有地震传感器。如果你错过了几个数据点,没关系,但你必须捕捉到大部分数据才能理解数据。更重要的是,如果它们不正确工作,没有人会因此死亡。

界限模糊,因为即使起搏器偏差很小,也可能不会导致患者死亡,但这是一般的概述。

这有点像热和温暖之间的区别。没有真正的分界线,但你在感受到时就知道了。


3
你的“坚定”的例子在我看来有些“软弱”。 - jxh
1
请记住这是一个连续过程。几乎每个计算机系统在某种时间尺度上都是“实时”的。公司的计费系统必须足够快地出账单,以维持公司的现金流,否则公司会像患者心脏起搏器错过数百毫秒心跳一样死亡。 - Hot Licks
我知道对于某些系统而言,错过截止日期可能是可以容忍的,但这是我对软实时系统的理解。我正在寻找一个实际的例子来说明以下标准:结果在截止日期后毫无用处。我猜你提供的声音示例中,如果声音与视频流同步,则一些延迟到达的音频数据包将毫无用处?但是有些电影播放系统会加速音频以赶上视频。 - jxh
实时要求是针对特定系统的上下文,而不是问题本身固有的。在你提供的例子中,声音仍然会受到损坏(加速),并且声音和视频之间存在暂时的不匹配。 - Joel
@jxh 如果下一个数据包再次同步,错过截止日期可能不会明显破坏同步。 - Mark K Cowan
显示剩余9条评论

44

阅读了维基百科页面和其他关于实时计算的页面后,我得出以下几个推论:

1> 对于硬实时系统,如果系统在一次时间限制内无法满足要求,则系统被认为已失败。

2> 对于软实时系统,即使系统在多个请求中多次未能满足时间限制(即未能按时完成任务),系统也不会被视为已失败。但是,在这种情况下,请求的结果并非毫无价值,超过其截止日期后的结果价值逐渐降低,例如流式音视频。

3> 对于固定实时系统,即使系统在多个请求中多次未能满足时间限制(即未能按时完成任务),系统也不会被视为已失败。另外,对于该特定请求的截止日期已经过期之后,回复查询或任务结果等响应的价值为零。一个假设的例子可以是一个风暴预测系统(如果在到达之前预测到风暴,则系统已经完成了工作,在事件发生或正在发生时进行预测无意义)。

这里是一个非常有用的资源链接。


5
风暴预报系统不是一个很好的例子,因为你需要根据时间设定截止日期,如果你已经知道风暴可能发生的最早时间,那么风暴预报系统就有点多余了。 - jxh

14
区分不同类型的实时系统最简单的方法是回答以下问题:
延迟响应(超过截止时间)是否仍然有用?
因此,根据您对这个问题的回答,您的系统可能被包括在以下几类中:
1. 硬实时系统:否,延迟的响应被认为是系统故障。
当错过截止时间会使系统无法使用时,就属于这种情况。例如,控制汽车安全气囊系统的系统应该能够检测到碰撞并快速充气。整个过程需要大约1/25秒左右。因此,如果系统反应迟缓1秒钟,后果可能是致命的,一旦汽车已经撞击,充气的气囊也没有好处。
2. 软实时系统:否,但延迟的响应不一定是系统故障。
当错过截止时间是可以容忍的,但会影响服务质量时,就属于这种情况。举个简单的例子,考虑一个视频加密系统。通常加密密码是在服务器(视频头端)生成并发送到客户机顶盒的。这个过程应该同步进行,所以通常在机顶盒开始接收加密视频帧之前,它就已经收到了密码。在这种情况下,延迟可能会导致视频出现故障,因为机顶盒不能解码帧,因为它还没有收到密码。在这种情况下,未能满足截止时间可能会影响服务(如电影、有趣的足球比赛等)的质量。在这种情况下,延迟接收密码是没有用的,因为已经使用同样的密码加密的帧已经导致了故障。
3. 软实时系统:是的,但系统服务降级。
在这种情况下,错过截止时间并不会使系统无法使用,但服务质量受到影响。根据维基百科的描述,一个结果在截止日期之后就逐渐失去了其有用性。这意味着,如果系统在截止日期之后仍能够给用户回应,那么对于最终用户来说,这个响应仍然是有用的,但是它的有用性会随着截止日期的到来而逐渐降低。一个简单的例子是一款自动控制房间(或建筑物)温度的软件。在这种情况下,如果系统在读取温度传感器时存在一些延迟,它将会比较慢地对突然变化的温度做出反应。然而,最终它仍会对变化做出反应,并相应地调整温度,例如保持恒定的温度。因此,在这种情况下,延迟的反应是有用的,但它会降低系统的服务质量。

13

把“硬实时”定义与一些大灾难联系起来是很流行的,但这并不相关。任何未能满足硬实时约束条件的失败都意味着系统已经出现故障。当某些东西被标记为“出现故障”时的严重性并不影响其定义。

在未能满足单个截止日期时,“严格”和“软”均不会自动声明为故障。

对于一个硬实时的公平例子,来自您链接的页面:

 

早期的视频游戏系统,如Atari 2600和Cinematronics矢量图形,由于图形和定时硬件的性质而具有硬实时要求。

如果视频生成过程中有任何一个截止日期被错过,整个显示屏都会出现故障,即使这种情况很少见,也是无法容忍的。那将成为一个出现故障的系统,你会把它退回到商店退款。所以它是硬实时系统。

显然,任何系统都可能遭受无法处理的情况,因此需要将定义限制在预期的运行条件内--值得注意的是,在安全关键应用中,人们必须为恶劣的情况做出计划(“冷却剂已蒸发”,“刹车已失效”,但很少会是“太阳爆炸”)。

还有一点不容忘记,有时存在着“只要有人在看”的隐含运行条件。如果没有人看到您违反规则(或者他们在通知任何人之前就死亡了),并且没有人能够证明您事后违反了规则,那么这与您从未违反规则是差不多的!


5
如果没有人看到你违反规则(或者即使他们看到了,但在告诉任何人之前就消失了),并且事后也没有人能够证明你违反了规则,那么这与你没有违反规则是差不多一样的!好的,HAL。现在,你能不能打开舱门? - Basic

6
要定义“软实时”,最简单的方法是将其与“硬实时”进行比较。下面我们将看到,“坚定实时”的术语构成了对“软实时”的误解。
通俗地说,大多数人隐含地具有一种非正式的心理模型,认为信息或事件是“实时的”
•如果或在他们感知到的货币价值上可以与延迟(延迟)相关的程度
•即,在信息或事件具有对他们令人满意的接受价值的时间范围内。
有许多不同的“硬实时”的特定定义,但在这个心理模型中,“硬实时”由“如果”项表示。具体而言,假设实时操作(如任务)具有完成期限,则所有任务完成的事件的令人满意的价值仅限于所有任务都满足其期限的特殊情况。
硬实时系统做出非常强烈的假设,即应用程序、系统和环境的所有内容都是静态且先验已知的——例如,哪些任务,它们是周期性的,它们的到达时间,它们的周期,它们的期限,它们不会有资源冲突,以及整个系统的时间演变。在飞机飞行控制系统或汽车制动系统等许多情况下,这些假设通常可以得到满足,以便满足所有期限。
这个心理模型有意地非常通用,足以涵盖硬实时和软实时——软实时通过“在某种程度上”短语得到容纳。例如,假设任务完成事件具有次优但可接受的价值,如果
•不超过10%的任务错过其截止日期
•或没有任务超过20%的迟到
•或所有任务的平均迟到时间不超过15%
•或所有任务中最大的迟到时间小于10%
这些都是许多应用程序中常见的软实时案例。
考虑单任务应用程序在学校放学后接孩子。那可能没有实际的截止日期,而是根据该事件发生的时间对您和您的孩子有一定的价值。太早浪费资源(如您的时间),太晚会有一些负面价值,因为您的孩子可能会被单独留下,潜在地处于危险之中(或至少是不方便的)。
与静态的硬实时特殊情况不同,软实时仅对任务和系统进行必要的最小应用程序特定假设,并且预计存在不确定性。为了接孩子,您必须开车去学校,而这需要的时间是动态的,取决于天气、交通状况等。您可能会想过度提供系统(即,允许您希望的最坏驾驶时间),但再次这会浪费资源(您的时间,并占用家庭车辆,可能会拒绝其他家庭成员使用)。
那个例子在浪费资源方面可能看起来不那么昂贵,但请考虑其他例子。所有的军事作战系统都是软实时的。例如,考虑使用更新后的导弹引导来对敌对地面车辆进行飞机攻击。完成课程更新任务的最大满意度是通过直接破坏性打击目标来实现的。但试图过度提供资源以确保这种结果通常过于昂贵,甚至可能是不可能的。在这种情况下,如果导弹足够靠近目标并使其失效,则你可能会感到不太满意,但已经足够了。
显然,战斗场景有许多可能的动态不确定性,必须通过资源管理来适应。软实时系统在许多民用系统中也非常普遍,例如工业自动化,尽管显然军事系统是实现可接受的满意价值最危险和紧迫的系统。
实时系统的关键是“可预测性”。硬实时情况只关心可预测性的一种特殊情况,即任务将全部满足其截止时间,并且该事件将实现最大可能的价值。这种特殊情况被称为“确定性”。
可预测性有一个谱。确定性(确定性)是可预测性谱的一个端点(最大可预测性);另一个端点是最小可预测性(最大非确定性)。谱的度量和端点必须根据所选择的可预测性模型进行解释;在这两个端点之间的所有内容都是不可预测度的程度(=不确定度程度)。
大多数实时系统(即软实时系统)具有非确定性的可预测性,例如任务完成时间以及从这些事件中获得的价值。
一般来说(在理论上),可预测性,因此接受满意的价值可以尽可能接近确定性端点--但代价可能是物理上不可能或过于昂贵的(如在战斗中或甚至在接孩子放学时)。
软实时需要选择一个应用程序特定的概率模型(而不是常见的频率模型),因此需要预测模型来推断事件延迟和结果值。
回到提供可接受价值的事件列表,现在我们可以添加非确定性案例,例如
- 没有任务的错过截止时间超过5%的概率大于0.87。(请注意其中表达的调度标准数量。)
在导弹防御应用程序中,考虑到在战斗中进攻总是优于防守,你会喜欢哪种实时计算场景:
  • 由于完全摧毁所有敌对导弹的可能性很小或不可能,因此将您的防御资源分配到最大化概率上,尽可能多地拦截最具威胁性(例如基于其目标)的敌对导弹(接近拦截很重要,因为它可以使敌对导弹偏离原路线);

  • 抱怨这不是实时计算问题,因为它是动态的而不是静态的,并且传统的实时概念和技术不适用,听起来比静态硬实时更难,因此您对此不感兴趣。

尽管实时计算社区存在各种误解,但软实时非常通用和强大,尽管与硬实时相比可能更加复杂。如下所述的软实时系统在实时计算社区之外有着悠久的成功历史。

直接回答OP的问题:

硬实时系统可以提供确定性保证 - 最常见的是所有任务都会在其截止时间内完成,中断或系统调用响应时间始终小于x等 - 仅当非常强的假设被正确地做出并已知先验(一般来说,对于硬实时系统的这些保证是一个开放的研究问题,除了相当简单的情况)

软实时系统不提供确定性保证,它旨在根据应用程序特定的标准,在当前动态环境下提供最佳可能的分析规定和完成概率时间性和可预测性。

显然,硬实时是软实时的一个简单特例。显然,软实时的分析非确定性保证可能非常复杂,但在最常见的实时情况下(包括最危险的安全关键情况,如战斗),这是强制性的,因为大多数实时情况都是动态而不是静态的。

“稳实时”是“软实时”的一个没有明确定义的特例。如果正确理解并使用“软实时”这个术语,则不需要此术语。

我在我的网站real-time.org上有关于实时、硬实时、软实时、可预测性、确定性和相关主题的更详细、更精确的讨论。


第一次革命是当你改变了看待事物的方式, 并意识到可能有另一种看待它的方式, 而这种方式以前从未被展示给你。--吉尔·斯科特-赫伦,《革命不会被电视转播》 - E. Douglas Jensen

6

软实时是最容易理解的,即使结果超过截止时间获得,结果仍被视为有效。

例如:Web浏览器-我们请求某个URL,它需要一些时间来加载页面。如果系统花费的时间超出了预期时间来提供页面,那么获取的页面不会被视为无效,我们只会说系统的性能不够好(系统性能较低!)。

在硬实时系统中,如果结果超过截止时间获得,则认为系统已完全失败。

例如:在机器人执行某些任务(如跟踪线路等)的情况下,如果有障碍物出现在其路径上,并且机器人未能在某个编程截止时间内处理此信息(几乎是瞬间!),则认为机器人未能完成其任务(机器人系统可能也会完全损坏!)。

在固定实时系统中,如果进程执行的结果超过截止时间,则我们将放弃该结果,但不称该系统已经失败。

例如:敌方位置监测或其他任务的卫星通信。如果卫星定期发送帧到地面计算机站,并且当前帧(数据包)由于过载而未能及时处理,下一个帧就会出现,当前数据包(错过截止时间的那个)无论处理是否完成(或半完成或几乎完成)都会被丢弃/放弃。但是地面计算机不被视为完全失败。


1
浏览器的例子是错误的。时间不是Web浏览器中的资源:这根本不是实时系统。 - Bart Friederichs

2
考虑一个从串行端口输入数据的任务。当新数据到达时,串行端口会触发事件。当软件处理该事件时,它会读取和处理新数据。串行端口有一个硬件来存储传入的数据(MSP432为2个,TM4C123为16个),因此如果缓冲区已满且有更多数据到达,则新数据将丢失。这个系统是硬实时、软实时还是半实时?
它是硬实时,因为如果响应延迟,数据可能会丢失。
考虑一个助听器,它从麦克风输入声音,操作声音数据,然后将数据输出到扬声器。系统通常具有小且有界的抖动,但偶尔在助听器的其他任务中导致一些数据延迟,从而在扬声器上产生噪声脉冲。这个系统是硬实时、软实时还是半实时?
它是半实时,因为它会导致可以感知到的错误,但效果是无害的,不会显著改变体验的质量。
考虑一个向打印机输出数据的任务。当打印机空闲时,打印机会触发事件。当软件处理该事件时,它会向打印机发送更多数据。这个系统是硬实时、软实时还是半实时?
它是软实时,因为响应越快越好,但系统的价值(带宽为每秒打印的数据量)随着延迟而降低。
UTAustinX:UT.RTBN.12.01x实时蓝牙网络

2

实时 - 指在外部过程发生的实际时间内执行计算的系统或操作模式,以便计算结果可以及时用于控制、监视或响应外部进程。[IEEE标准610.12.1990]

我知道这个定义很老,非常老。然而,我找不到更近期的IEEE(电气和电子工程师协会)定义。


2
实际上,1990年并不算太久远。我在70年代就已经讨论过这个问题了,而且定义大致相同。 - Hot Licks

1
也许问题出在定义上。
从我的经验来看,我会把硬件和软件分开考虑。
如果你只有200毫秒的时间来处理硬件驱动中断,那就只能用这么多时间。如果你在其中添加了300毫秒的代码,系统并不会崩溃,而是没有得到完善的开发。你会在完成之前被切换掉。你的代码不起作用或者不适合这个目的。许多系统都有硬性的处理周期。比如视频、电信等。
如果你正在编写一个实时的应用程序,这可能被认为是“软”的。如果你超时了,下一次你可以希望负载更少,你可以调整操作系统,增加一些内存,甚至升级硬件。你有选择的余地。
从用户体验的角度来看,这并不是有帮助的。斯柯达汽车如果出现故障并不会坏掉,但宝马肯定会。

你对斯柯达有什么意见! - Erik Kaplun

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接