硬实时,软实时和坚实实时之间的差异?

时间:2013-06-25 22:59:21

标签: real-time hard-real-time soft-real-time firm-real-time

我已经阅读了different notions of real-time的定义,为硬实时系统和软实时系统提供的示例对我来说很有意义。但是,没有真正的解释或坚实的实时系统的例子。根据上面的链接:

  

坚定:不经常的最后期限错失是可以容忍的,但可能会降低系统的服务质量。在截止日期之后,结果的有用性为零。

公司实时与硬实时或软实时之间是否有明显的区别,是否有一个很好的例子来说明这种区别?

在评论中,Charles要求我为新标签提交标签维基。我为标签提供的“公司实时系统”示例是牛奶服务系统。如果系统在到期时间后输送牛奶,则认为牛奶“无用”。人们可以忍受吃不含牛奶的谷物,但体验质量会下降。

这只是我在最初阅读定义时在脑海中形成的想法。我正在寻找一个更好的例子,也许是对公司实时的更好定义,这将改善我对它的看法。

12 个答案:

答案 0 :(得分:99)

硬实时意味着你必须完全按照每个截止日期。很少有系统有此要求。一些例子是核系统,一些医疗应用,如心脏起搏器,大量国防应用,航空电子设备等。

固定/软实时系统可能会错过一些截止日期,但如果错过太多,最终性能会降低。一个很好的例子是计算机中的音响系统。如果你错过了一些,没什么大不了的,但是想念太多,你最终会降低系统质量。类似的是地震传感器。如果你错过了一些数据点,没什么大不了的,但你必须抓住它们中的大部分才能理解数据。更重要的是,如果他们不能正常工作,没有人会死。

这条线是模糊的,因为即使心脏起搏器可以少量关闭而不会杀死病人,但这是一般的要点。

这有点像热和温暖的区别。没有真正的鸿沟,但是当你感觉到它时就会知道它。

答案 1 :(得分:79)

硬实时

  

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

示例:

  • 在传感器故障导致一系列系统错误后,法航447航班坠入大海。飞行员在回应过时的仪器读数时使飞机停滞不前。所有12名机组人员和216名乘客遇难。

  • 当优先级反转导致系统重启时,火星探路者航天器几乎丢失。由于被较低优先级的任务阻止,较高优先级的任务未按时完成。问题得到纠正,航天器成功降落。

  • 喷墨打印机的打印头带有控制软件,用于将正确数量的墨水沉积到纸张的特定部分。如果错过截止日期,则打印作业将被破坏。

公司实时

  

公司实时定义允许不经常错过最后期限。在这些应用中,只要系统有足够的间隔,系统就能在任务失败后继续存在,但任务完成的价值降至零或变得不可能。

<强>示例:

  • 带有机器人装配线的制造系统缺少最后期限会导致零件装配不正确。只要破损的部件很少被质量控制抓住而且成本太高,就会继续生产。

  • 数字有线电视机顶盒解码时间标记,以确定帧何时必须出现在屏幕上。由于帧是时间顺序敏感的,因此错过的最后期限会导致抖动,从而降低服务质量。如果丢失的帧稍后变得可用,则仅会导致更多的抖动显示,因此它是无用的。如果抖动不经常发生,观众仍然可以享受该节目。

Soft Real-Time

  

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

<强>示例:

  • 气象站有许多用于读取温度,湿度,风速等的传感器。应该定期读取和传输读数,但传感器不同步。即使传感器读数与其他读数相比可能是早期或晚期,只要它足够接近,它仍然是相关的。

  • 视频游戏控制台运行游戏引擎的软件。必须在其任务之间共享许多资源。同时,任务需要根据游戏的时间表完成才能正确播放。只要任务完全相对准时,游戏将是愉快的,如果不是,它可能只会滞后一点。

Siewert:实时嵌入式系统和组件。
刘&amp; Layland:在硬实时环境中进行多道程序设计的算法 Marchand&amp; Silly-Chetto:软周期任务和周期任务的动态调度与跳过。 功能

答案 2 :(得分:43)

阅读维基百科页面和其他关于实时计算的页面。我做了以下推论:

1&GT;对于硬实时系统,即使系统被认为失败,系统也无法满足截止日期。

2 - ;对于公司实时系统,即使系统未能满足截止日期,可能不止一次(即多次请求),系统也不会被视为失败。此外,一旦特定请求的截止日期过去,请求的响应(对查询的回复,任务的结果等)就毫无价值(结果的有用性在截止日期之后为零 )。一个假设的例子可以是风暴预报系统(如果在到达之前预测风暴,那么系统已完成其工作,在事件已经发生之后或当事件发生时预测没有价值)。

3&GT;对于软实时系统,即使系统未能满足截止日期,可能不止一次(即多次请求),系统也不会被视为失败。但是,在这种情况下,请求的结果并非毫无价值在截止日期之后的结果值,不是零,而是在截止日期之后随着时间的推移而降级。例如:流式音频视频。

Here是指向非常有用的资源的链接。

答案 3 :(得分:11)

将一些巨大的灾难与硬实时的定义联系起来很受欢迎,但这并不重要。任何未能满足硬实时约束只会意味着系统被破坏。当某些东西被标记为“破损”时,结果的严重程度对定义来说并不重要。

如果没有达到一个截止日期,公司和软件就不能自动被宣告破产。

从您链接的页面中获得硬实时的公平示例:

  

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

如果视频生成循环中的某些内容错过了一个截止日期,那么整个显示都会出现故障,这是不可容忍的,即使这种情况很少见。这将是一个破碎的系统,你会把它带回商店退款。所以这很难实时。

显然,任何系统都可能遇到无法处理的情况,因此有必要将定义限制在预期的运行条件范围内 - 注意在安全关键应用中人们必须规划可怕的条件(“冷却剂已蒸发) “,”刹车失败“,但很少”太阳爆炸了“。

让我们不要忘记,有时隐含的“当有人正在观看”操作条件时。如果没有人看到你违反规则(或者如果他们这样做但他们在告诉任何人之前就死了),并且没有人能证明你在事后违反了规则,那么就像你从未违反规则一样! / p>

答案 4 :(得分:9)

区分不同类型的实时系统类型的最简单方法是回答以下问题:

  

延迟的系统响应(在截止日期之后)是否仍然有用?

因此,根据您对此问题的回答,您的系统可能会被列为以下类别之一:

  1. :否,延迟答案被视为系统故障
  2. 错过死线会导致系统无法使用。例如,控制汽车安全气囊系统的系统应检测到碰撞并迅速膨胀行李。整个过程大约需要二十五分之一秒。因此,如果系统例如以1秒的延迟作出反应,后果可能是致命的,一旦汽车已经坠毁,行李袋就会膨胀是没有好处的。

    1. 公司:否,但延迟答案不一定是系统故障
    2. 如果错过最后期限是可以忍受的,但会影响服务质量。作为一个简单的例子,考虑视频加密系统。通常,加密密码在服务器(视频头端)中生成并发送到客户机顶盒。此过程应该同步,因此通常机顶盒在开始接收加密视频帧之前会收到密码。在这种情况下延迟可能导致视频故障,因为机顶盒无法解码帧,因为它还没有收到密码。在这种情况下,服务(电影,有趣的足球比赛等)可能会受到不符合截止日期的影响。在这种情况下,延迟接收密码是没有用的,因为用它们加密的帧已经引起了毛刺。

      1. :是,但系统服务已降级
      2. 从维基百科描述开始,结果的有用性在截止日期后降低。这意味着,在截止日期之前从系统获得响应对最终用户仍然有用,但在达到截止日期后其有用性会降低。这种情况的一个简单示例是自动控制房间(或建筑物)温度的软件。在这种情况下,如果系统读取温度传感器有一些延迟,那么对于粗糙的温度变化反应就会有点慢。然而,最后它将最终对变化作出反应并相应地调节温度以使其保持恒定。因此,在这种情况下,延迟反应很有用,但会降低系统的服务质量。

答案 5 :(得分:6)

软实时最容易理解,即使在截止日期之后获得结果,结果仍被视为有效。

示例: Web浏览器 - 我们请求某个URL,加载页面需要一些时间。如果系统花费超过预期的时间来向我们提供页面,则获得的页面不会被视为无效,我们只是说系统的性能不符合标准(系统性能低下! )。

硬实时系统中,如果在截止日期之后获得结果,系统将被视为完全失败。

示例:如果机器人正在执行线路跟踪等工作,如果路径上出现障碍,机器人在某个程序设定的截止日期内没有处理此信息(几乎是即时的!),据说机器人的任务失败了(机器人系统也可能完全被摧毁!)。

公司实时系统中,如果流程执行的结果在截止日期之后到来,我们会丢弃该结果,但系统不会被称为失败。

示例:用于敌方位置监控或其他任务的卫星通信。如果卫星定期向其发送帧的地面计算机站过载,并且当前帧(分组)没有及时处理并且下一帧出现,则当​​前分组(错过截止日期的分组)不会。是否丢弃/丢弃处理完成(或完成一半或几乎完成)。但地面计算机并不是完全失败的。

答案 6 :(得分:5)

定义&#34;软实时,&#34;最简单的方法是将它与“实时硬盘”进行比较。&#34;下面我们将看到术语&#34;坚实的实时&#34;构成对软实时的误解。&#34;

随便说一句,大多数人暗中都有一个非正式的心理模型,认为信息或事件是&#34;实时&#34;

•是否,或者在某种程度上,它对他们来说具有与其感知货币相关的延迟(延迟)

•即,在时间范围内,信息或事件对他们具有可接受的令人满意的价值。

有许多不同的临时定义&#34;硬实时,&#34;但是在那个心智模型中,硬实时是由&#34; if&#34;术语。具体来说,假设实时操作(例如任务)具有完成期限,所有任务完成的事件的可接受的令人满意的值仅限于所有任务满足其截止日期的特殊情况。

硬实时系统做出了非常强烈的假设,即关于应用程序,系统和环境的所有内容都是静态的,并且是已知的。先验 - 例如,哪些任务,它们是周期性的,它们的到达时间,它们的周期,它们的最后期限,它们不会有资源冲突,以及整个系统的时间演变。在飞机飞行控制系统或汽车制动系统以及许多其他情况下,通常可以满足这些假设,以便满足所有期限。

这种心理模型是有意且非常有用的,足以涵盖硬实时和软实时 - 软和#34;以及#34;短语。例如,假设任务完成事件具有次优但可接受的值,如果

  • 不超过10%的任务错过最后期限
  • 或没有任务超过20%迟到
  • 或所有任务的平均延迟不超过15%
  • 或所有任务中的最大延迟小于10%

这些都是许多应用中软实时案例的常见例子。

考虑放学后挑选孩子的单任务应用。这可能没有实际的截止日期,相反,根据事件发生的时间,您和您的孩子会有一些价值。太早的浪费资源(例如你的时间)和太晚都有一些负面价值,因为你的孩子可能会被单独留下并可能处于危害之中(或者至少是不方便的)。

与静态硬实时特殊情况不同,软实时仅对关于任务和系统的最小必要特定于应用程序的假设做出,并且预期不确定性。要接你的孩子,你必须开车到学校,根据天气,交通状况等,这样做的时间是动态的。你可能想要过度配置你的系统(即,允许你希望的是最糟糕的情况是驾驶时间)但这也是浪费资源(你的时间,占用家庭车辆,可能否定其他家庭成员使用)。

就资源浪费而言,这个例子似乎并不昂贵,但请考虑其他例子。所有军事作战系统都是实时软件。例如,考虑使用导弹对敌方地面车辆进行飞机攻击,并将其更新作为目标机动。完成课程更新任务的最大满意度是通过对目标的直接破坏性打击来实现的。但是,过度配置资源以确定这一结果的尝试通常过于昂贵甚至可能是不可能的。在这种情况下,如果导弹击中足够接近目标的位置以禁用它,你可能会更少但是足够满意。

显然战斗情景有很多可能的动态不确定性,必须由资源管理来解决。软实时系统在许多民用系统中也很常见,例如工业自动化,尽管显然军用系统是实现可接受的令人满意的价值的最危险和最紧急的系统。

实时系统的基石是可预测性。&#34;硬实时案例只对一个可预测性的特殊情况感兴趣 - 即,任务都将满足其最后期限,并且该事件将实现最大可能值。这个特例被命名为'34;确定性。&#34;

有一系列可预测性。确定性(确定性)是可预测性谱的一个终点(最大可预测性);另一个终点是最小可预测性(最大非确定性)。频谱的度量和终点必须根据所选择的可预测性模型来解释;这两个终点之间的一切都是不可预测的程度(=非决定论的程度)。

大多数实时系统(即软实时系统)具有非确定性可预测性,例如,任务&#39;完成时间,从而从这些事件中获得的价值。

一般而言(理论上),可预测性以及可接受的令人满意的价值可以在必要时尽可能接近确定性终点 - 但价格可能在物理上不可能或过于昂贵(如在战斗中或甚至可能是从学校接你的孩子。)

软实时需要特定于应用程序的概率模型选择(不是常见的频率模型),因此需要用于推理事件延迟和结果值的可预测性模型。

回顾上面提供可接受价值的事件列表,现在我们可以添加非确定性案例,例如

  • 任务将错过截止日期超过5%的概率大于0.87。 (注意那里表示的调度标准的数量。)

在导弹防御应用中,鉴于在战斗中进攻总是优于防守,你更喜欢这两种实时计算场景中的哪一种:

  • 因为所有敌对导弹的完全破坏是不太可能或不可能的,所以分配你的防御资源以最大限度地提高可能成功拦截许多最具威胁性(例如,基于其目标)的敌对导弹的可能性(近距离拦截很重要,因为它可以使敌方导弹偏离航线);

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

尽管在实时计算社区中存在各种关于软实时的误解,但软实时非常通用且功能强大,尽管与硬实时相比可能比较复杂。这里总结的软实时系统在实时计算社区之外有很长的成功使用历史。

直接回答OP问题:

硬实时系统可以提供确定性保证 - 最常见的是所有任务都将满足其最后期限,中断或系统调用响应时间将始终小于x等。如果只有非常强的假设和是正确的,重要的是一切都是静态的,而且已知的是先验(一般来说,对于硬实时系统的这种保证是一个开放的研究问题,除了相当简单的情况)

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

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

&#34;坚定的实时&#34;软实时是一个定义不明确的特例。&#34;如果术语&#34;软实时&#34;则不需要这个术语。理解并正确使用。

我在我的网站real-time.org上对实时,硬实时,软实时,可预测性,确定性和相关主题进行了更为详细的更精确的讨论。

答案 7 :(得分:2)

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

我知道这个定义很旧,很旧。但是,我无法通过IEEE(电气和电子工程师协会)找到更新的定义。

答案 8 :(得分:2)

考虑从串行端口输入数据的任务。当新数据到达时,串行端口会触发事件。当软件为该事件提供服务时,它会读取并处理新数据。串行端口有一个硬件用于存储输入数据(MSP432上有2个,TM4C123上有16个),因此如果缓冲区已满并且有更多数据到达,则新数据将丢失。这个系统是硬实时,坚固实时还是软实时?

硬实时,因为如果响应延迟,数据可能会丢失。

考虑使用助听器从麦克风输入声音,操纵声音数据,然后将数据输出到扬声器。系统通常具有小而有界的抖动,但偶尔助听器中的其他任务会导致某些数据延迟,从而在扬声器上产生噪声脉冲。这个系统是实时的,坚固的还是软的?

坚实实时因为它会导致错误,但效果无害,并且不会显着改变体验质量。

考虑将数据输出到打印机的任务。当打印机空闲时,打印机会触发事件。当软件为该事件提供服务时,它会向打印机发送更多数据。这个系统是实时的,坚固的还是软的?

软实时因为响应越快越好,但系统的价值(带宽是每秒打印的数据量)随着延迟而减少。

UTAustinX:UT.RTBN.12.01x实时蓝牙网络

答案 9 :(得分:1)

也许这个定义是错误的。

根据我的经验,我将两者分开,因为它们取决于硬件和软件。

如果你有200ms来维修硬件驱动的中断,那就是你所拥有的。你在那里坚持300毫秒的代码,系统没有被破坏,它还没有被开发出来。在您完成之前,您将被关闭。您的代码不起作用或不适合目的。许多系统具有硬定义的处理周期。视频,电信等。

如果您正在编写实时应用,则可以将其视为 soft 。如果你的时间用完了,你可能希望下次减少负载,你可以调整操作系统,添加一些内存,甚至升级硬件。你有选择。

从用户体验的角度来看它是没有用的。如果一个斯柯达发生故障,它可能不会被打破,但宝马肯定会这么做。

答案 10 :(得分:1)

这些定义多年来一直在扩大,不利于该术语。现在所谓的“硬”实时是过去被简单地称为实时的。因此,应该实时考虑丢失定时窗口(而不是单侧时间期限)会导致错误数据或不正确行为的系统。没有该特征的系统将被视为非实时的。

这并不是说时间对非实时系统不感兴趣,只是意味着此类系统中的时序要求不会导致根本上不正确的结果。

答案 11 :(得分:0)

硬实时系统使用优先级调度的抢占版本,因此可以立即调度关键任务,而软实时系统使用优先级调度的非抢占版本,这允许在将控制权转移到当前任务之前完成当前任务。较高优先级的任务,导致其他延迟。因此,在硬实时系统中严格遵循任务期限,而在软实时系统中,任务期限没有那么认真地处理。