RTOS的最佳定义是什么？

Question

我还没有找到特定于具有意义的RTOS定义。我能找到的最好的是wiki：

https://en.wikipedia.org/wiki/Real-time_operating_system

但是我有一些批评意见/问题：

1. ＆＃34;实时＆＃34;似乎在我发现的所有RTOS定义中都没有定义。没有什么比实际的实时更快（无限小！）。因此，我相信＆＃34;实时＆＃34;只有在观察者的背景下才有意义。使用iPhone用户的人的实时时间可能<20ms，因为人眼视线无法更快地检测到变化。对于气囊展开，它可能<1ms。互联网上的所有定义似乎都掩盖了＆＃34;实时＆＃34;的定义！
2. 如果RTOS是由在特定时间范围内执行某些事情的要求定义的（＆＃34;截止日期＆＃34;），为什么抖动会进入定义？如果iPhone响应在12-14ms之间抖动，它是否不再实时响应？它符合20ms的要求，对吗？如果响应一次达到100毫秒，则用户可能会注意到，此时系统不是RTOS
3. 怎么可能有＆＃34;软＆＃34; RTOS？ RTOS的定义符合特定的截止时间要求。如果它不符合它，那么它不是RTOS！ RTOS的定义禁止使用＆＃34; soft＆＃34; RTOS

对我而言，似乎没有正式和精确的RTOS定义。它是一个通用术语，用于解释操作系统的特性，其主要优先事项是实时＆＃34;实时＆＃34; （根据要求编号）特定类型的观察员。看起来这个名称似乎已经采用了实现的含义，例如如何处理事物，多任务处理，消息传递，信号量等等......如果系统无法响应，那么所有这些都可能根本不属于RTOS的一部分。 ＆＃34;截止＆＃34;要求，对吧？

对于这样一个无处不在的问题感到抱歉，但我无法在脑中清晰地看到这个问题。我发现的所有定义都不够精确，或者使用实现细节来定义定义。

Answer 1

你是对的，没有定义来定义确切的时间范围。这不是定义的目标。但实时并不依赖于观察者，而是应用程序。由于应用程序不同，时间范围不同，因此定义不能将该范围赋予数字。

只要满足应用程序的时间限制，抖动就无关紧要了。你对这个例子绝对正确。如果截止时间是20毫秒，则花费100毫秒是失败的。如果操作系统要归咎于延迟，那么它不是RTOS。

＆＃34;软实时＆＃34;有一个非常具体的含义，这可能是你唯一真正错的。这里的概念是，当任务超过截止日期时你会怎么做？ （注意：这可能是任务本身或RTOS的错误。）在硬实时系统中，任务根本没有任何价值。迟到的结果和没有结果一样好，你取消了任务。没有必要担心其他任务。

软RTOS实际上更复杂。完成任务仍然有价值，虽然减少了。因此，RTOS不会难以杀死任务，但操作系统仍然必须确保其他任务满足其最后期限。这需要额外的照顾，如果你只是为了完成这项任务，这是不必要的。

Answer 2

有一个Embedded Systems Dictionary。以下是一些摘录：

  

实时 adj。具有及时性要求，通常以不能错过的截止日期的形式提供。

     

实时操作系统 n。专门设计用于实时系统的操作系统。简称RTOS。

     

实时系统 n。任何具有及时性要求的嵌入式或其他计算机系统。可以使用以下问题   将实时系统与其他系统区分开来：“这是一个迟到的答案   坏的，甚至更糟，而不是错误的答案？“换句话说，会发生什么   如果计算没有及时完成？如果没有不好的事情，   它不是一个实时系统。如果有人死亡或任务失败，   它通常被认为是“硬”的实时，这意味着暗示   系统有最后期限。介于两者之间的一切都是“软”   实时性。