硬实时，软实时和公司实时之间的区别？

我已经阅读了有关实时的不同概念的定义，并且为硬实时和软实时系统提供的示例对我来说都是有意义的。但是，没有关于实时系统的真实解释或示例。根据上面的链接：

坚定：很少的最后期限遗漏是可以容忍的，但可能会降低系统的服务质量。结果的有效期在截止日期之后为零。

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

在评论中，Charles要求我为新标签提交标签Wiki。我提供的“公司实时系统”示例公司实时标签是牛奶供应系统。如果系统在其到期时间后交付牛奶，则该牛奶被视为“无用”。一个人可以忍受不加牛奶的谷物饮食，但是体验质量却下降了。

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

硬实时性意味着您必须绝对按时完成任务。很少有系统有此要求。例如，核系统，一些医疗应用（例如起搏器），大量国防应用，航空电子设备等。

公司/软件实时系统可能会错过某些截止日期，但是如果错过太多，最终性能将下降。一个很好的例子是计算机中的音响系统。如果您错过了一点，没什么大不了的，但是错过了太多，您最终将使系统降级。地震传感器也将类似。如果您错过了几个数据点，那没什么大不了的，但是您必须抓住其中的大多数才能理解数据。更重要的是，没有人能够正常工作而死。

这条线是模糊的，因为即使是起搏器也可以在不杀死患者的情况下少量启动，但这就是总要旨。

有点像热和热之间的区别。没有真正的鸿沟，但是当您感觉到它时就知道了。

硬实时

在硬实时的定义认为任何错过最后期限是系统故障。此调度程序广泛用于任务关键型系统，在这些系统中，不遵守时序约束会导致人员伤亡或财产损失。

例子：

• 传感器故障导致一系列系统错误后，法航447航班坠毁入海。飞行员在回应过时的仪表读数时使飞机失速。所有12名机组人员和216名乘客被杀死。

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

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

公司实时

该公司的实时定义允许偶尔错过了最后期限。在这些应用程序中，只要间隔足够的时间，系统就可以幸免于难，但是任务完成的价值下降到零或变得不可能。

例子：

• 机器人组装线的制造系统缺少最后期限会导致零件组装不当。只要损坏的零件很少被质量控制捕获并且成本不高，那么生产就会继续。

• 数字电缆机顶盒解码时间戳，以指示何时帧必须出现在屏幕上。由于帧对时间顺序敏感，因此错过最后期限会导致抖动，从而降低服务质量。如果以后丢失的帧可用，只会显示更多的抖动，因此没有用。如果不经常发生抖动，观众仍然可以欣赏该节目。

软实时

在软实时定义允许频频失手的最后期限，只要任务执行及时的结果继续有值。在截止日期之前完成的任务可能会增加价值，而在截止日期之前可能会减少价值。

例子：

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

• 视频游戏机运行用于游戏引擎的软件。它的任务之间必须共享许多资源。同时，根据游戏的时间表需要完成任务，游戏才能正常进行。只要任务完全按时完成，游戏就会很有趣，否则，它可能只会滞后一点。

^{Siewert：实时嵌入式系统和组件。
Liu＆Layland：硬实时环境中的多程序调度算法。
Marchand＆Silly-Chetto：具有跳跃的软非周期性任务和周期性任务的动态调度。}

阅读完Wikipedia页面和其他有关实时计算的页面之后。我做出以下推断：

1>对于Hard实时系统，即使系统被认为已发生故障，如果系统仍未按时完成任务。

2>对于公司实时系统，即使系统未能按时完成任务，也可能不止一次（即针对多个请求），也不会认为系统发生了故障。同样，一旦超过特定请求的截止日期（结果的有用性在其截止日期之后为零），对请求的响应（对查询的答复，任务的结果等）就一文不值。一个假设的例子可以是暴风雨预报系统（如果在暴风雨来临之前预测到暴风雨，则该系统已经完成了工作，在事件已经发生或事发时进行预测没有任何价值）。

3>对于软实时系统，即使系统未能按时完成任务，也可能不止一次（即针对多个请求），也不会认为系统已发生故障。但是，在这种情况下，请求的结果对于截止日期之后的结果而言，并不是不值钱的，不为零，而是随着截止日期之后时间的流逝而降低。例如：流式音频视频。

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

将一些重大灾难与硬实时定义联系在一起很普遍，但这无关紧要。未能满足严格的实时约束条件仅意味着系统已损坏。当某些东西标记为“损坏”时，结果的严重性对定义并不重要。

硬和软根本无法在未满足单个截止日期的情况下自动宣布为损坏。

有关硬实时的公平示例，请在您链接的页面上进行以下操作：

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

如果视频生成循环中的某些内容仅错过了一个截止日期，那么整个显示都会出现故障，即使这种情况很少见，也将是无法忍受的。那将是一个损坏的系统，您将把它带回商店以获取退款。因此这很难实时进行。

显然，任何系统都可能会遇到无法处理的情况，因此有必要将定义限制在预期的运行条件之内-指出在安全关键型应用中，人们必须为恶劣的条件做出计划（“冷却液已蒸发”，“刹车失败”，但很少“太阳已经爆炸”）。

并且不要忘记，有时候会有一个隐含的“当任何人都在观看时”的运行状态。如果没有人看到您违反了规则（或者如果他们违反了规则，但是他们却在告诉任何人之前就死了），并且没人能证明事实之后您违反了规则，那就像您从未违反规则一样！

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

延迟的系统响应（在截止日期之后）是否仍然有用？

因此，根据针对该问题的答案，您的系统可以作为以下类别之一包括在内：

1. 困难：否，延迟回答被认为是系统故障

当错过最后期限将使系统无法使用时，就是这种情况。例如，控制汽车安全气囊系统的系统应检测到碰撞并迅速使安全气囊充气。整个过程大约需要二十分之一秒。因此，例如，如果系统以1秒的延迟做出反应，后果可能是致命的，一旦汽车已经坠毁，将气囊充气将无济于事。

2. 公司：否，但延迟回答不一定是系统故障

在可以容忍错过最后期限的情况下，会出现这种情况，但这会影响服务质量。作为一个简单的例子，考虑视频加密系统。通常，加密密码是在服务器（视频头端）中生成的，并发送到客户机顶盒。此过程应同步，因此通常机顶盒会收到密码开始接收加密的视频帧之前。在这种情况下，由于机顶盒尚未收到密码，因此无法解码帧，因此可能导致视频故障。在这种情况下，服务（电影，有趣的足球比赛等）可能会因未按时完成而受到影响。在这种情况下，延迟接收密码是没有用的，因为用相同的密码加密的帧已经引起了故障。

3. 软：是，但是系统服务降级了

根据维基百科的描述，结果的有用性在截止日期之后降低。这意味着，从系统中获得超出最终期限的响应对于最终用户仍然有用，但在达到最终期限后其有效性会降低。这种情况的一个简单示例是自动控制房间（或建筑物）温度的软件。在这种情况下，如果系统在读取温度传感器时有一些延迟，则对剧烈温度变化的反应会有些慢。然而，最后，它将最终对变化做出反应并相应地调节温度以使其保持恒定。因此，在这种情况下，延迟的反应很有用，但会降低系统的服务质量。

一个软实时是最容易理解，在即使在截止日期后得到其结果，结果仍视为有效。

示例： Web浏览器-我们要求输入特定的URL，因此加载页面需要一些时间。如果系统花了超过预期的时间为我们提供页面，则认为获得的页面无效，我们只是说系统的性能未达到要求（系统性能低下！）。

在硬实时系统中，如果在截止日期之后获得结果，则认为系统已完全失败。

示例：如果机器人在做某些工作，例如线条跟踪等。如果路径上出现障碍物，并且机器人未在某个编程的期限内（几乎立即！）处理此信息，则该机器人已失败（机器人系统也可能被完全摧毁！）。

在公司实时系统中，如果流程执行的结果在截止日期之后出现，我们将丢弃该结果，但是系统不被视为已发生故障。

示例：用于敌方位置监视或其他任务的卫星通信。如果卫星定期向其发送帧的地面计算机站过载，并且没有及时处理当前帧（数据包）而下一帧出现，那么当前数据包（错过最后期限的数据包）就没有关系处理是否完成（或一半完成或几乎完成）被丢弃/丢弃。但是地面计算机并不能完全失效。

要定义“软实时”，最容易将其与“硬实时”进行比较。在下文中，我们将看到术语“公司实时”构成对“软件实时”的误解。

随便地说，大多数人都隐含着一个非正式的心理模型，该模型将信息或事件视为“实时”

•是否（或在某种程度上）以明显的延迟（潜伏期）向他们表明可能与其感知的货币有关

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

“硬实时”有许多不同的临时定义，但是在该心理模型中，硬实时由“ if”术语表示。具体来说，假设实时操作（例如任务）具有完成期限，则所有任务完成的事件的可接受的令人满意的价值限于所有任务都满足其期限的特殊情况。

硬实时系统做出非常强烈的假设，即与应用程序，系统和环境有关的一切都是静态的，并且是先验的，例如，哪些任务是周期性的，到达时间，周期，截止日期，他们赢得了不会有资源冲突，而且整个系统不会随时间变化。在飞机飞行控制系统或汽车制动系统以及许多其他情况下，通常可以满足这些假设，以便所有截止日期都能得到满足。

这种心智模型刻意且非常有用，足以涵盖硬实时和软实时，而软则包含在“该范围内”。例如，假设任务完成事件具有次优但可接受的值，如果

• 不超过10％的任务未按时完成
• 或没有一项任务的延迟时间超过20％
• 或所有任务的平均拖延时间不超过15％
• 或所有任务中的最大拖延时间小于10％

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

考虑放学后接孩子的单任务应用程序。那可能没有实际的截止日期，但是根据事件发生的时间，您和您的孩子会有一些价值。太早浪费资源（例如您的时间），而太迟则具有一些负面价值，因为您的孩子可能被独自一人留着，有可能受到伤害（或至少造成不便）。

与静态硬实时特殊情况不同，软实时仅对任务和系统做出最低限度的特定于应用程序的假设，并且存在不确定性。要接送孩子，您必须开车去学校，而且上课的时间是动态的，具体取决于天气，交通状况等。您可能会倾向于过度配置系统（即，允许您希望最坏的情况是开车时间），但这又浪费了资源（您的时间，占用了家庭用车，可能会拒绝其他家庭成员使用）。

就浪费的资源而言，该示例似乎并不昂贵，但是请考虑其他示例。所有军事作战系统都是实时的。例如，考虑使用导弹进行更新，将其作为目标机动，对敌对地面车辆进行飞机攻击。通过对目标的直接破坏性攻击，可以达到完成课程更新任务的最大满意度。但是，尝试过度配置资源以确保这一结果通常太昂贵了，甚至可能是不可能的。在这种情况下，如果导弹的打击距离目标足够近以使其失效，您可能会感到满足，但您可能会感到满意。

显然，战斗场景具有许多可能的动态不确定性，资源管理必须适应这些不确定性。软实时系统在许多民用系统（例如工业自动化）中也很常见，尽管军事系统显然是实现可接受的令人满意的价值的最危险，最紧急的系统。

实时系统的重点是“可预测性”。硬实时情况只对一种特殊的可预测性感兴趣，即，所有任务都将按时完成，并且该事件将实现最大可能的价值。该特殊情况称为“确定性”。

有一系列可预测性。确定性（determinism）是可预测性范围内的一个端点（最大可预测性）。另一个终点是最小可预测性（最大不确定性）。频谱的指标和终点必须根据所选的可预测性模型进行解释；这两个端点之间的一切都是不可预测的程度（=不确定性的程度）。

大多数实时系统（即软系统）具有不确定的可预测性，例如，任务的完成时间以及因此从这些事件中获得的值。

一般而言（理论上），可以使可预测性（因此可以接受的令人满意的值）尽可能接近确定性终点，但价格可能在物理上是不可能的，也可能过于昂贵（例如在战斗中，甚至在战斗中）接孩子放学）。

软实时需要特定于应用程序的概率模型（不是常见的常客模型）的选择，因此需要用于预测事件延迟和结果值的可预测性模型。

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

• 没有任务将错过最后期限超过5％的概率大于0.87。（请注意其中表达的调度标准的数量。）

在导弹防御应用中，考虑到在战斗中进攻总是比防御具有优势，因此您更喜欢以下两种实时计算方案中的哪一种：

• 因为完全不可能或不可能完全摧毁所有敌对导弹，请分配防御资源，以最大程度地成功截获许多威胁最大的（例如，基于其目标的）敌对导弹的概率（紧密拦截计数，因为可以将敌对导弹移出航道）；

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

尽管在实时计算社区中对软实时存在各种误解，但软实时还是非常通用和强大的，尽管与硬实时相比可能很复杂。此处总结的软实时系统在实时计算社区之外已有很长的成功使用历史。

要直接回答OP问题：

硬实时系统可以提供确定性保证-最常见的情况是所有任务都将按时完成任务，中断或系统调用响应时间将始终小于x，依此类推。重要的事情都是静态的，并且是先验的（通常，对硬实时系统的此类保证是一个开放的研究问题，除了相当简单的情况之外）

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

显然，硬实时是软实时的简单特例。显然，软实时的分析性不确定性保证可能非常复杂，但在最常见的实时情况（包括最危险的对安全至关重要的情况，例如战斗）中是强制性的，因为大多数实时情况都是动态的而不是动态的。静态的。

“固定实时”是“软实时”的定义不明确的特例。如果术语“软实时”被正确理解和使用，则不需要此术语。

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

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

我知道这个定义很旧，很旧。但是，我找不到IEEE（电气与电子工程师协会）的最新定义。

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

这是很难实时的，因为如果响应晚了，数据可能会丢失。

考虑一个助听器，它可以从麦克风输入声音，处理声音数据，然后将数据输出到扬声器。该系统通常具有较小且有限的抖动，但是助听器中的其他任务有时会导致某些数据延迟，从而在扬声器上产生噪声脉冲。该系统是实时的，实时的还是实时的？

它是实时的，因为它会引起可以察觉的错误，但是这种影响是无害的，并且不会显着改变体验的质量。

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

它是软实时的，因为它响应越快越好，但是系统的价值（带宽是每秒打印的数据量）随着等待时间而减小。

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

也许定义有误。

根据我的经验，我将两者分开，取决于硬件和软件。

如果您有200毫秒的服务时间来处理硬件驱动的中断，那就足够了。您将300ms的代码放入其中，系统并未损坏，尚未开发。完成操作之前，您将被拒之门外。您的代码不起作用或不合适。许多系统都有明确定义的处理周期。视频，电信等

如果您正在编写实时应用程序，则可以将其视为soft。如果时间用完了，希望下次可以减少负载，则可以调整操作系统，增加内存或什至升级硬件。您有选择。

从UX的角度来看它没有帮助。斯柯达轿车可能不会发生故障，但宝马一定会做到。

多年来，该定义已扩展到损害该术语的范围。现在称为“硬”实时的是以前简称为实时的内容。因此，缺少计时窗口（而不是单边时间期限）会导致错误数据或错误行为的系统应被视为实时系统。没有该特性的系统将被视为非实时的。

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

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