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