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