我已经阅读了real-time 不同概念的定义，并且为硬实时系统和软实时系统提供的示例对我来说很有意义。但是，没有真正的解释或可靠的实时系统的例子。根据上面的链接：
坚定：偶尔错过最后期限是可以容忍的，但可能会降低系统的服务质量。结果的有用性在截止日期后为零。
硬实时与硬实时或软实时之间是否有明显的区别，是否有一个很好的例子来说明这种区别？
在评论中，Charles 要求我为新标签提交标签 wiki。我为公司实时标签提供的“公司实时系统”的示例是牛奶供应系统。如果系统在过期时间之后输送牛奶，则认为牛奶“没有用”。人们可以忍受吃没有牛奶的谷物，但体验的质量会下降。
这只是我最初阅读定义时在脑海中形成的想法。我正在寻找一个更好的例子，也许是一个更好的固定实时定义，这将改善我的概念。
硬实时定义将任何错过的最后期限视为系统故障。这种调度被广泛用于关键任务系统中，在这些系统中，未能遵守时序约束会导致生命或财产损失。
例子：
在传感器故障导致一系列系统错误后，法航 447 航班坠入大海。飞行员在响应过时的仪表读数时使飞机失速。12 名机组人员和 216 名乘客全部遇难。
当优先级反转导致系统重新启动时，火星探路者航天器几乎丢失。由于被较低优先级的任务阻塞，较高优先级的任务未按时完成。问题得到纠正，飞船成功着陆。
喷墨打印机有一个带有控制软件的打印头，用于将正确数量的墨水沉积到纸张的特定部分。如果错过了最后期限，则打印作业将被破坏。
公司的实时定义允许很少错过最后期限。在这些应用程序中，只要任务间隔足够大，系统就可以在任务失败中幸存下来，但是任务完成的价值下降到零或变得不可能。
例子：
带有机器人装配线的制造系统错过最后期限会导致零件装配不正确。只要损坏的零件很少被质量控制发现并且成本不太高，那么生产就会继续。
数字有线电视机顶盒解码时间标记，以确定帧何时必须出现在屏幕上。由于帧对时间顺序敏感，错过最后期限会导致抖动，从而降低服务质量。如果错过的帧稍后变得可用，它只会导致更多的抖动显示它，所以它是无用的。如果不经常发生抖动，观众仍然可以欣赏节目。
软实时定义允许经常错过最后期限，只要任务及时执行，它们的结果就会继续有价值。已完成的任务在截止日期之前可能会增加价值，而在截止日期之后价值会减少。
例子：
气象站有许多用于读取温度、湿度、风速等的传感器。应定期获取和传输读数，但传感器不同步。即使传感器读数与其他传感器相比可能早或晚，只要它足够接近，它仍然是相关的。
视频游戏控制台运行游戏引擎的软件。有许多资源必须在其任务之间共享。同时任务需要按照时间表完成，游戏才能正确进行。只要任务完全按时完成，游戏就会很有趣，如果不是，它可能只会滞后一点。
Siewert：实时嵌入式系统和组件。
Liu & Layland：硬实时环境中的多道程序调度算法。
Marchand & Silly-Chetto：软非周期性任务和带跳跃的周期性任务的动态调度。
硬实时意味着您必须绝对按时完成每个截止日期。很少有系统有这个要求。一些例子是核系统、一些医疗应用（如心脏起搏器）、大量国防应用、航空电子设备等。
硬/软实时系统可能会错过一些最后期限，但如果错过太多，最终性能会下降。一个很好的例子是您计算机中的音响系统。如果你错过了一些位，没什么大不了的，但错过了太多，你最终会降低系统的性能。类似的还有地震传感器。如果你错过了一些数据点，没什么大不了的，但你必须抓住其中的大部分才能理解数据。更重要的是，如果工作不正常，没有人会死。
这条线很模糊，因为即使是起搏器也可以少量关闭而不会杀死患者，但这是一般要点。
这有点像热和温暖的区别。没有真正的分歧，但当你感觉到它时你就会知道。
在阅读了 Wikipedia 页面和其他有关实时计算的页面之后。我做了以下推论：
1> 对于硬实时系统，即使系统被认为已失败，如果系统未能满足最后期限。
2> 对于Firm 实时系统，即使系统未能满足最后期限，可能不止一次（即对于多个请求），系统也不会被视为失败。此外，一旦特定请求的截止日期已过，对请求的响应（对查询的答复、任务的结果等）将毫无价值（在截止日期之后结果的有用性为零）。一个假设的例子可以是风暴预报系统（如果风暴在到达之前被预测，那么系统已经完成了它的工作，在事件已经发生或何时发生之后的预测是没有价值的）。
3> 对于软实时系统，即使系统未能满足最后期限，可能不止一次（即多次请求），系统也不被视为失败。但是，在这种情况下，请求的结果对于截止日期之后的结果来说并不是毫无价值的值，不是零，而是随着截止日期之后的时间流逝而降级。例如：流式音频视频。
这是一个非常有用的资源的链接。
将一些大灾难与硬实时的定义联系起来是很流行的，但这并不相关。任何未能满足硬实时约束的情况都意味着系统已损坏。当某物被标记为“损坏”时，结果的严重性对定义并不重要。
坚定和柔软根本无法在未能满足单一期限时自动宣布破产。
对于硬实时的一个公平示例，来自您链接的页面：
由于图形和计时硬件的性质，早期的视频游戏系统（例如 Atari 2600 和 Cinematronics 矢量图形）具有严格的实时要求。
如果视频生成循环中的某些内容只错过了一个截止日期，那么整个显示就会出现故障，这将是无法容忍的，即使这种情况很少见。那将是一个损坏的系统，您会将其带回商店进行退款。所以很难实时。
显然，任何系统都可能遇到无法处理的情况，因此有必要将定义限制在预期的操作条件内——注意在安全关键型应用中，人们必须为可怕的条件（“冷却液已蒸发”、“刹车失灵了”，但很少“太阳爆炸了”）。
并且不要忘记，有时会有一个隐含的“有人在看”的操作条件。如果没有人看到你违反了规则（或者如果他们确实看到了，但他们在告诉任何人之前就死了），并且没有人能在事后证明你违反了规则，那就像你从未违反过规则一样！
区分不同种类的实时系统类型的最简单方法是回答以下问题：
延迟的系统响应（在截止日期之后）是否仍然有用？
因此，根据您对这个问题的回答，您的系统可能属于以下类别之一：
当错过最后期限会使系统无法使用时，就会出现这种情况。例如，控制汽车安全气囊系统的系统应该检测到碰撞并迅速给气囊充气。整个过程大约需要二十五分之一秒。因此，如果系统以 1 秒的延迟做出反应，后果可能是致命的，一旦汽车已经坠毁，让袋子充气也没有任何好处。
错过最后期限是可以容忍的，但会影响服务质量。作为一个简单的例子，考虑一个视频加密系统。通常加密密码在服务器（视频头端）中生成并发送到客户机顶盒。这个过程应该是同步的，所以机顶盒正常接收密码在开始接收加密的视频帧之前。在这种情况下，延迟可能会导致视频故障，因为机顶盒由于尚未收到密码而无法解码帧。在这种情况下，服务（电影、有趣的足球比赛等）可能会因未能按时完成而受到影响。在这种情况下延迟接收密码是没有用的，因为使用相同加密的帧已经引起了故障。
根据维基百科的描述，结果的有用性在截止日期后会降低。这意味着，在截止日期之前从系统获得响应对最终用户仍然有用，但在达到截止日期后其有用性会降低。这种情况的一个简单示例是自动控制房间（或建筑物）温度的软件。在这种情况下，如果系统在读取温度传感器时有一些延迟，那么对突然的温度变化做出反应会有点慢。但是，最终它会对变化做出反应并相应地调整温度以使其保持恒定。所以在这种情况下，延迟反应是有用的，但它会降低系统的服务质量。
要定义“软实时”，最容易将其与“硬实时”进行比较。下面我们将看到，术语“固定实时”构成了对“软实时”的误解。
随便说说，大多数人都隐含着一种非正式的心理模型，认为信息或事件是“实时的”
• 如果或在某种程度上，它对他们来说是明显的，延迟（延迟）可能与其感知的货币有关
• 即，在信息或事件对他们具有可接受的满意价值的时间范围内。
“硬实时”有许多不同的特殊定义，但在那个心智模型中，硬实时由“如果”术语表示。具体来说，假设实时动作（例如任务）具有完成期限，那么所有任务完成的事件的可接受的令人满意的值仅限于所有任务都满足其期限的特殊情况。
硬实时系统做出非常强的假设，即关于应用程序、系统和环境的一切都是静态的并且是先验已知的——例如，哪些任务是周期性的、它们的到达时间、它们的周期、它们的截止日期、它们赢得了'不会有资源冲突，和整体系统的时间演变。在飞机飞行控制系统或汽车制动系统以及许多其他情况下，通常可以满足这些假设，从而满足所有最后期限。
这种心智模型是故意且非常有用的通用性，足以涵盖硬实时和软实时——软由“在某种程度上”短语所容纳。例如，假设任务完成事件具有次优但可接受的值，如果
这些都是许多应用程序中软实时案例的常见示例。
考虑放学后接孩子的单任务应用程序。这可能没有实际的截止日期，而是根据该事件发生的时间对您和您的孩子有一些价值。太早浪费资源（例如你的时间），太晚有一些负面价值，因为你的孩子可能会被单独留下并可能受到伤害（或至少不便）。
与静态硬实时特殊情况不同，软实时仅对任务和系统做出最小必要的特定于应用程序的假设，并且可以预期不确定性。要接您的孩子，您必须开车去学校，具体时间取决于天气、交通状况等。您可能会想过度配置您的系统（即，允许您希望最坏的情况下驾驶时间）但这又是在浪费资源（您的时间，占用家庭车辆，可能拒绝其他家庭成员使用）。
就浪费的资源而言，该示例似乎并不昂贵，但请考虑其他示例。所有军事作战系统都是软实时的。例如，考虑使用带有更新的导弹作为目标机动，对敌方地面车辆执行飞机攻击。通过对目标的直接破坏性打击来获得完成课程更新任务的最大满意度。但是，为了确定这一结果而过度提供资源的尝试通常过于昂贵，甚至可能是不可能的。在这种情况下，如果导弹击中目标足够近以禁用它，您可能会不太满意，但足够满意。
显然，战斗场景有很多可能的动态不确定性，资源管理必须适应这些不确定性。软实时系统在许多民用系统中也很常见，例如工业自动化，尽管显然军用系统是最危险和最紧迫的系统，以实现可接受的令人满意的价值。
实时系统的基石是“可预测性”。硬实时案例只对可预测性的一种特殊情况感兴趣——即，任务都将在最后期限内完成，并且该事件将实现最大可能值。这种特殊情况称为“确定性”。
有一系列的可预测性。Deterministic（确定性）是可预测性谱上的一个端点（最大可预测性）；另一个终点是最小可预测性（最大不确定性）。频谱的度量和端点必须根据所选的可预测性模型来解释；这两个端点之间的一切都是不可预测的程度（=非确定性的程度）。
大多数实时系统（即软系统）具有不确定的可预测性，例如，任务的完成时间以及从这些事件中获得的值。
一般来说（理论上），可预测性以及可接受的令人满意的值，可以尽可能接近确定性终点——但代价可能是物理上不可能或过于昂贵（如在战斗中，甚至可能在接你的孩子放学）。
软实时需要一个特定于应用程序的概率模型（不是常见的频率模型）的选择，因此需要可预测性模型来推理事件延迟和结果值。
回顾上面提供可接受值的事件列表，现在我们可以添加不确定的情况，例如
在导弹防御应用中，鉴于在战斗中进攻总是比防守更有优势，您更喜欢以下两种实时计算场景中的哪一种：
因为完全摧毁所有敌对导弹是非常不可能或不可能的，分配你的防御资源以最大化尽可能多的最具威胁性（例如，基于其目标）的敌对导弹被成功拦截的概率（近距离拦截计数，因为它可以使敌方导弹偏离航向）；
抱怨这不是实时计算问题，因为它是动态而不是静态的，传统的实时概念和技术不适用，而且听起来比静态硬实时更难，所以你对它不感兴趣.
尽管实时计算社区对软实时存在各种误解，但软实时非常通用且功能强大，尽管与硬实时相比可能更复杂。此处总结的软实时系统在实时计算社区之外有着悠久的成功使用历史。
直接回答OP问题：
硬实时系统可以提供确定性保证——最常见的情况是所有任务都会在最后期限内完成，中断或系统调用响应时间总是小于 x 等等——如果且仅当做出非常强的假设并且是正确的重要的一切都是静态的并且是先验已知的（通常，对于硬实时系统的这种保证是一个开放的研究问题，除了相当简单的情况）
软实时系统不提供确定性保证，它旨在根据特定应用的标准，提供在当前动态情况下可行的最佳分析指定和完成的概率时效性和时效性可预测性。
显然，硬实时是软实时的一个简单特例。显然，软实时的分析性非确定性保证可能非常复杂，但在最常见的实时情况下（包括最危险的安全关键情况，如战斗）是强制性的，因为大多数实时情况是动态的，而不是动态的。静止的。
“固定实时”是“软实时”的一个定义不明确的特例。如果正确理解和使用术语“软实时”，则不需要该术语。
我在我的网站 real-time.org 上对实时、硬实时、软实时、可预测性、确定性和相关主题进行了更详细、更精确的讨论。
软实时最容易理解，即使在截止日期之后获得结果，结果仍然被认为是有效的。
示例： Web 浏览器 - 我们请求某个 URL，加载页面需要一些时间。如果系统为我们提供页面的时间超过预期，则获得的页面不被认为是无效的，我们只是说系统的性能不合格（系统给了低性能！）。
在硬实时系统中，如果在截止日期之后获得结果，则认为系统完全失败。
示例：如果机器人执行线路跟踪等工作。如果障碍物出现在其路径上，并且机器人在某个编程的截止日期（几乎是瞬间！）内没有处理此信息，则称机器人失败在其任务中（机器人系统也可能被完全摧毁！）。
在严格的实时系统中，如果流程执行的结果在截止日期之后出现，我们丢弃该结果，但系统不被称为失败。
示例：用于敌方位置监控或其他任务的卫星通信。如果卫星定期向其发送帧的地面计算机站过载，并且当前帧（数据包）没有及时处理并且下一帧出现，则当前数据包（错过截止日期的那个）无关紧要处理是否完成（或一半完成或几乎完成）被丢弃/丢弃。但是地面计算机并没有被称为完全失败。
实时 - 与在外部过程发生的实际时间执行计算的系统或操作模式有关，以便计算结果可用于及时控制、监视或响应外部过程方式。[IEEE 标准 610.12.1990]
我知道这个定义很老，很老。但是，我找不到 IEEE（电气和电子工程师协会）的最新定义。
考虑一个从串行端口输入数据的任务。当新数据到达时，串行端口会触发一个事件。当软件为该事件提供服务时，它会读取并处理新数据。串行端口具有用于存储传入数据的硬件（MSP432 上为 2 个，TM4C123 上为 16 个），因此如果缓冲区已满且有更多数据到达，则新数据将丢失。这个系统是硬的、坚固的还是软实时的？
这是很难实时的，因为如果响应迟了，数据可能会丢失。
考虑一个助听器，它从麦克风输入声音，处理声音数据，然后将数据输出到扬声器。该系统通常具有小而有界的抖动，但有时助听器中的其他任务会导致某些数据延迟，从而导致扬声器上出现噪声脉冲。这个系统是硬的、坚固的还是软实时的？
它是实时的，因为它会导致可以感知的错误，但效果是无害的，并且不会显着改变体验的质量。
考虑一个将数据输出到打印机的任务。当打印机空闲时，打印机会触发一个事件。当软件为该事件提供服务时，它会向打印机发送更多数据。这个系统是硬的、坚固的还是软实时的？
它是软实时的，因为它响应越快越好，但系统的价值（带宽是每秒打印的数据量）会随着延迟而减少。
UTAustinX：UT.RTBN.12.01x 实时蓝牙网络
也许定义有问题。
根据我的经验，我会将两者分开，因为它们依赖于硬件和软件。
如果您有 200 毫秒的时间来处理硬件驱动的中断，那就是您所拥有的。您在其中粘贴 300 毫秒的代码，系统并没有损坏，它还没有被开发。你会在完成之前被切换出去。您的代码不起作用或不适合用途。许多系统都有硬定义的处理周期。视频、电信等
如果你正在编写一个实时的应用程序，这可以被认为是软的。如果您的时间用完了，您可能希望下次负载更少，您可以调整操作系统、添加一些内存甚至升级硬件。你有选择。
从用户体验的角度来看是没有帮助的。如果斯柯达出现故障，它可能不会坏，但宝马肯定会坏。
硬实时系统使用抢占式优先级调度，以便立即调度关键任务，而软实时系统使用非抢占式优先级调度，允许在将控制权转移到更高优先级之前完成当前任务任务，导致额外的延迟。因此，在硬实时系统中严格遵循任务期限，而在软实时系统中，它们的处理并不那么认真。
多年来，该定义已扩大到不利于该术语。现在所谓的“硬”实时是过去简单地称为实时的。因此，缺少时序窗口（而不是单边时间期限）会导致不正确数据或不正确行为的系统应考虑实时。没有该特性的系统将被认为是非实时的。
这并不是说时间对非实时系统不感兴趣，它只是意味着此类系统中的时间要求不会导致根本上不正确的结果。