RTOS与否RTOS是问题

我对最近的文章“嵌入式系统的多样化世界及其在Embox中的地位”的一连串 评论 （很遗憾，我不能称之为讨论）促使我写这篇文章。 我在几个地方受到责备，因为它们混淆了RTOS和嵌入式OS，我称其为LynxOS，QNX和VxWorks，而不是RTOS，尽管我认为当然没有。 我曾多次建议这些评论的作者写一篇文章，阐述他对“实时操作系统”概念的看法，但出于某种原因，他拒绝了。 好吧，我将提出我对该术语的看法，让我们讨论可以调用什么RTOS，什么不能调用RTOS。 最后，这个问题通常是与Embox有关的 。

OS RV（RTOS）一词是指营销领域！

我认为应该以科学的方式开始，并引入术语，但最终决定欢迎这一具有争议性的论文。 那么，为什么我要争辩说RTOS（实时操作系统）一词是指营销，更确切地说，是营销（广告）口号吗？ 一切都很简单。 生产产品时，需要将其出售。 但是，如果您仅尝试出售操作系统，则会遇到困难。 这就是抢救市场定位的地方。 例如，您可以说“我们比他们快”。


但是你可以为此去法庭！ 在那里，您将需要提供证据。 但是，如何证明您在所有情况下都更快？ 这不是一场持续的比赛。 但是，当然，这种不完全正确的竞争稍微超出了正常的市场定位。

正常定位涉及消费者肖像的形成，识别需求量更大的产品属性，并着眼于这些属性。 好吧，或者您可以在用户那里形成这些需求。 例如，我们的处理器具有这样的频率，智能手机具有N核处理器，依此类推。

由于该类型的经典作品已经提出，不仅用户系统需要操作系统，而且在自动模式下控制各种工艺流程也需要操作系统，甚至引入了实时操作系统的概念，因此，不使用它是一个罪过。 在介绍实时系统的概念时，经典著作谈到了一定的临界时间阈值。 也就是说，它与常规系统不同，在常规系统中，如果用户等待某些东西，那么他可以等待，而硬实时系统（例如控制涡轮机）则无法等待，否则您可能会陷入困境。

因此，您可以告诉用户，与常规操作系统不同，它们将配备有保证系统响应时间的系统。 自然，它越小，系统可以控制的不同技术过程的数量就越大。 并且出现了许多表格，其中将RTOS的各种关键参数作为关键参数给出。

他们如何得到的？ 诚实地描述了这个过程！ 在这里，我们采用这样的模型问题，这样的硬件平台，并因此应用效果。 好吧，营销当然可以简化并给出1μs的响应时间。 但是我们没有考虑到这一点，我们相信所有内容都是诚实的。

但是请问，如果还有其他任务怎么办？ 10个任务，100个任务？ 如果醉酒的程序员锁定中断？ 如果程序员在系统中没有正确分配任务的优先级？

在某些情况下，Embox实时通过了测试。 我们坐下来思考如何证明这是一个实时操作系统。 有一个实验室，有一个客户希望如此。 我们发现，对于客户而言，实时意味着系统的响应时间为1μs。 我问以下实验是否可以作为证据：

• 我们采取一定的硬件平台
• 将信号施加到GPIO输入之一
• 以编程方式捕捉事件
• 在GPIO的输出处，我们以编程方式发出信号
• 使用示波器进行测量，反应时间将是输入和输出前沿之间的差。

客户确认这正是所需要的。 我问一个澄清的问题，我们正在设计一个模型系统，可能不会启动（不加载）其他任务。 也就是说，系统仅执行这样一个简单的测试任务是正常的。 客户说这需要测试任务。 您可能自己了解系统已通过测试！ 自然地，随着特性的确认，即重复了影响。

编写本节绝不是为了贬低任何OS或开发人员。 但这仅仅是为了显示图片的整体不完整。 我并不是说某些操作系统的特性不允许它们归因于RTOS，而营销人员只是使用此术语。 当我根据任务要求订购独立实验室的操作系统时，我看到了其他测试。 存在一组复杂的模型任务，并考虑了网络交互，以及在系统加载时参数如何更改以及在各种紧急情况下的行为。

术语“实时操作系统”的定义

现在，我将介绍术语“实时操作系统”。 不，我不会。 事实是，这个术语有很多定义。 至少要对原始文章发表评论：

在实时系统中，人员通常是多余的，因此，应将实时系统的速度与其控制的过程进行比较，无论是自动驾驶汽车还是工厂的过程控制系统。

SRV / RTOS-这仅仅是对关键事件响应的可预测性的排名。

RTOS是这样一种OS，其中任务的正确性不仅以逻辑正确性为特征，而且以完成此任务所花费的时间为特征。

将浮点协处理器确定为将所有任务的上下文切换为每100 MHz处理器1μs的标准（确定为0.1μs），一切都会落到位。
您将清楚地看到RTOS在哪里，哪里没有。

好吧，我不能忽略我在OSDAY会议之一发表的一篇文章中谈到的观点 ：

如果一个系统没有任何地方可以锁定中断，而这些循环的迭代次数未知，则可以将其视为硬实时系统。

但是，也许这一切都是特别的，并且正如评论中所建议的那样，您只需要使用经典而不是想出自行车。 我将引用指定的经典（如果有人没有猜的话，Andrew Tanenbaum）：

另一类操作系统是实时系统。 这些系统的特征是将时间作为关键参数。 例如，在工业过程控制系统中，实时计算机必须收集有关生产过程的数据，并使用它来控制工厂中的机器。 通常，必须有严格的截止日期。 例如，如果汽车沿着装配线行驶，则某些动作必须在某些时刻进行。 如果焊接机器人焊接得太早或太晚，汽车将被毁坏。 如果绝对必须在某个特定时刻（或某个特定范围内）执行该操作，那么我们就有一个实时的系统。 其中许多位于工业过程控制，航空电子，军事和类似应用领域。 这些系统必须提供绝对的保证，即在特定的时间将发生特定的操作。

另一类实时系统是软实时系统，其中错过偶尔的截止日期是不希望的，但这是可以接受的，并且不会造成任何永久性损害。 数字音频或多媒体系统属于此类。 数字电话也是实时系统。

由于在实时系统中必须满足严格的期限，有时操作系统只是与应用程序链接的库，所有内容都紧密耦合，并且系统各部分之间没有保护。 这种实时系统的一个示例是e-Cos。

手持设备，嵌入式系统和实时系统的类别有很多重叠。 几乎所有人都至少具有一些实时的软件方面。 嵌入式和实时系统仅运行由系统设计人员安装的软件。 用户无法添加自己的软件，这使得保护更加容易。 手持设备和嵌入式系统面向消费者，而实时系统则更多地用于工业用途。 不过，它们有一定的共同点。”

但是根据该描述，只能得出以下结论：该系统只能用于在给定时间内没有反应会导致灾难性后果的系统。 好吧，为了获得关键参数（不超过反应时间），OS可以是eCos的示例库。

如何实现实时特性

我无法给出严格的定义（如果有人愿意提供，请在评论中写下）。 但是在所有上述定义中，都有几个属性是可见的（这次和可预测性）。 如果将时间转换为可预测性选项（从一种状态转换到另一种状态时弧的权重），则仅保留可预测性！

让我们考虑如何实现这一目标。

很明显，从关键系统中删除了所有不必要的东西。 通用系统不太可能稳定。 我的意思是，甚至甚至连Tanenbaum同志也谈到了eCos。

Tanenbaum再次提出了另一种提高系统可预测性的方法，即使用特殊（简单）算法进行资源规划，主要是处理器时间，即特殊任务调度程序。 他提出了几种计划方法，但是我想首先关注静态表驱动表。

开发人员必须确保所有任务都能成功完成其时间片。 为此，建议静态分析关键任务并确定其阈值。 ARINC-653标准中规定了这种方法。 机载系统的标准让您自己理解，如果突然之间没有时间在飞机上工作，则可能会发生灾难。

下一种方法是静态计划，但要基于优先级。 也就是说，开发人员必须再次分析所有情况，并在系统优先级中分配了所有任务后，确保关键任务在给定时间完成。

我不想继续，因为有原始照片！ 当然，它写得比我能做的要好，而且，他们可能又被指控歪曲事实。 我精确地引用了这些方法，以表明在任何情况下，最终系统的开发人员都有责任确保系统的特性。 并且操作系统应仅提供适当的功能。

继续讨论增加可预测性的方法，我想再提一点意见

“您可以在树莓上实现实时，但不能使用RTOS，而是可以使用小型状态机进入其缓存。”

在这里，我要注意以下几点：

• 由于从系统中排除了任何RTOS，因此提高了可预测性（实时属性）
• 状态机表示的程序
• 好吧，实时系统不仅依赖于软件的属性，而且还依赖于硬件。

随着代码行数的减少，不可预测性的减少，我想每个人都同意。 尽管我一如既往地不同意，但以后会更多。

硬件的影响力也很可能毫无疑问。 特别是，当说在锁定中断的状态下不存在具有任意迭代次数的循环时，听起来在所描述的RTOS中的某些cortex-m上根本没有中断的中断。 这有点狡猾，因为中断控制器在那里独立地禁用了具有相同或更低优先级的中断，但是影响的事实是显而易见的。 当然，缓存的存在，地址转换（或者更确切地说是页面遗漏）会增加不确定性。 特别是，我想提请您注意以下事实：实际上，没有人可以保证设备的100％正确的可操作性。 好吧，您发布的帖子不多了，RTOS的存在将如何避免事件的灾难性后果？

将该程序表示为状态机，我建议从一个明显的角度考虑它。 即，可以分析可预测性程序。 并且由于我们正在讨论所有条件，因此应该针对所有可能的情况进行静态分析。 好吧，由于函数式编程语言更适合静态分析，因此可以使用某些特殊语言开发程序，或者增加使用特殊编程语言的可能性。 第一种方法例如在经过验证的seL4内核中使用。 第二种方法的示例是相同的ARINC-653标准，其强制性地以XML形式形成了需求。

还有其他方法可以提高可预测性，或者，如果您愿意，可以提高影响系统可预测性的因素。 我在OSDay的一个会议上就此主题做了报告。 特别是，除了已经列出的那些，我还强调了一种架构方法。 毕竟，众所周知，例如，微内核体系结构可以提高系统的可预测性。 但是即使在同一份报告中，也强调了一种不太明显的组织方法。 正是在这一点上，我不同意缺乏实时操作系统会导致可预测性提高。 如果您考虑一下，那么一般而言，操作系统的概念已大大减少了由于代码重用而导致的错误数量。 也就是说，如果您没有真正适合一个开关/箱的代码，那么最好使用现成的模块。 毕竟，参数“每1000行代码的错误数”尚未取消，并且无论新代码的调试方式如何，都存在错误。

实时操作系统是否存在？

在上一节中声明任何代码中都有错误之后，我想提出一个更具挑衅性的论文。 实时操作系统是否存在？

让我们弄清楚。 在与朋友讨论实时系统时，我们同意几乎不存在实时操作系统（我们在谈论硬实时系统）。 他建议将整个系统表示为状态机或图形，并描述从一种状态到另一种状态的最大过渡时间。 此外，如果证明对于所有输入状态和内部状态都存在一条导致给定状态并带有时间限制的电弧，则该系统可以被认为是稳定的。 嗯，您知道，只有在很小的系统上才有可能，只是注释中提到的状态机，但是在现代世界中，很少有人需要这样的系统。

但是我们毫无疑问地存在实时系统。 当然，RTOS也是如此。 如果不是这样， 那么第一只飞啄木鸟就会毁灭文明，那么就不会有航空电子，航天，机器人技术，ACS-TP等。

如何摆脱困境。 这很简单，尽管通常问题最有可能无法解决，但是对于特定问题，有可能引入使其可以解决的限制，并且具有某种有意义的错误概率。

例如，引入了标准： 实时POSIX ， ARINC-653 ， ITRON 。 实际上，这些标准区分了如果您遵守此标准可以解决的一类任务。 或者由独立实验室进行研究，研究特定OS的属性是否适合解决目标问题。

那么Embox RTOS还是不是RTOS？

我认为，要针对Embox和其他任何操作系统回答类似的问题，您只能问：“您的意思是什么？”。 更准确地说：“实时概念是什么意思？”。 也就是说，如果对中断处理时间感兴趣，并且是否可以直接调用中断处理程序，这是一回事，如果您需要提高工作的可靠性（尽管速度很慢），但是肯定会失败的可能性要小得多，这是另一回事，符合任何标准都是第三位。验证是第四。 伟大的经典作家安德烈·塔南鲍姆（Andrei Tanenbaum）提出了提高可预测性的方法，但它使用了实时系统的概念，但没有任何严格的定义，这并非巧合。

PS在撰写本文时，还没有一个RTOS受到影响。