实时系统和确定性系统之间有区别吗？答案

【问题标题】：Is there a difference between a real time system and one that is just deterministic?实时系统和确定性系统之间有区别吗？
【发布时间】：2012-09-21 02:51:46
【问题描述】：

在工作中，我们正在讨论新平台的设计，其中一位高层管理人员表示它需要运行我们当前的代码库（Linux 上的 C），但需要实时，因为它需要在不到一秒的时间内做出响应到各种输入。我指出：

这并不意味着它需要“实时”，只是它需要更快的时钟和更精简的中断处理
要考虑的关键点之一是正在使用的操作系统。他们想坚持使用嵌入式 Linux，我指出我们需要一个 RTOS。由于内核/用户空间内存分裂，使用 Linux 会阻止“实时”，因此 I/O 是通过文件和套接字完成的，这会引入延迟
我们真正需要确定的是它是否需要确定性（例如，需要在 90% 的时间内在

在我看来，如果第 3 点是真的，那么它需要是一个实时系统，然后第 2 点是最大的考虑因素。

我有信心回答，但后来我在想……其他人怎么看？ 我是在正确的轨道上还是我错过了什么？

“实时”系统和“确定性”系统之间有什么区别吗？除了 RTC 和 RTOS，我是否缺少执行真正实时系统所需的任何主要内容？

期待一些好的回应！

编辑：

目前收到了一些不错的回复，看来对我的系统和需求有点好奇，所以我会为感兴趣的人添加一些注释：

我公司销售的单位是几十万，所以我不想在价格上过度杀戮
通常我们销售主处理器板和独立显示器。还有一个连接的其他 CAN 设备网络。
板（当前）运行设备，还充当网络服务器，将基本 XML 文档发送到最终用户的显示器

管理层希望“快速”（真正约束来自可以通过 CAN 连接的设备。这些设备通常是电机控制设备，其要求包括“必须在 200 毫秒内做出响应”。

【问题讨论】：

实时计算机意味着硬时间限制，而不是仅满足 90% 的时间限制。时间限制是不是很难？这决定了您需要哪种系统。
我会说这取决于您平台的预期数量。与尝试移植到 RTOS 并在没有地址空间保护之类的东西的情况下生活相比，保留现有的 linux 代码并购买一个非常快的处理器要容易和快捷一百万倍。但如果产品量很大，那么 CPU 的成本就更需要考虑了。
@TJD - 即使使用最快的处理器也无法保证会满足约束条件。据我了解，具有 RTC 和高时钟速率的 uC 系统将（可能）成为操作系统的瓶颈。

标签： c embedded real-time definition deterministic

【解决方案1】：

你需要区分：

硬实时：响应时间有一个绝对限制，不得违反（算作失败） - 例如这适用于例如当您控制机器人电机或医疗设备时，如果未能按时完成可能会造成灾难性后果
软实时：要求在大多数情况下快速响应（可能 99.99%+），但偶尔违反时间限制是可以接受的平均来说非常快。例如这适用于在电脑游戏中执行实时动画 - 错过最后期限可能会导致跳帧，但不会从根本上破坏游戏体验

只要您拥有足够的硬件并充分注意识别和优化瓶颈，大多数系统都可以轻松实现软实时。通过一些调整，甚至可以在具有不确定性暂停的系统中实现（例如 Java 中的垃圾收集）。

硬实时需要专门的操作系统支持（以保证调度）和确定性算法（这样一旦调度，任务就可以保证在截止日期内完成）。做到这一点很难，需要对整个硬件/软件堆栈进行仔细设计。

请务必注意，大多数商业应用程序都不需要：特别是我认为以远大多数人会考虑“实时”要求。话虽如此，如果在需求中明确指定了响应时间，那么您可以将其视为软实时，并且截止日期相当宽松。

【讨论】：

+1 表示硬/软区别。硬实时系统的另一个很好的例子是飞机上的航空电子/飞行控制系统，在这些系统中，按时完成是至关重要的。
+1，有趣的一点，我喜欢清晰度调整。我们确实在系统中有一些“硬实时”约束。例如，我们的 EEV（电子扩展值）的电机控制，但并非所有“硬”要求......也许使用两个“出租”处理器一个更好的主意，其中一个带有 RTOS 用于电机控制。您对硬件需求的看法是否仅仅是 RTC（为 RTOS 提供数据）和足够的计算能力？
基本上是的，高分辨率时钟是实时硬件的关键。 RTOS 的工作是以确保满足给定计算能力的最后期限的方式进行调度。从技术上讲，如果要求足够宽松，甚至不需要高分辨率时钟，由 RTOS 处理调度。
拆分架构通常是个好主意。大多数 RTOS 应该支持这一点：使用 RTC/实时调度用 C 语言编写硬实时的东西，使用 Java 或任何其他方便您的堆栈以软实时风格编写系统的其余部分。这意味着您无需担心在软实时方面使用非确定性算法。
Eeww - 电机控制。我总是会为此使用嵌入式 uC，并从“桌面”操作系统进行管理/监控。除了您的实时要求外，电机/螺线管/任何控制器都连接到外部接线，通常由第 3 方承包商安装，然后会受到其他承包商的错误..“无意的高能量注入”。更换便宜的嵌入式主板烧焦的碳化残留物比安装新桌面、从备份恢复（如果他们已经做过的话）并重新调试系统要容易/便宜得多。

【解决方案2】：

来自real-time标签的定义：

当活动完成的及时性是功能要求和正确性条件，而不仅仅是性能指标时，任务就是实时。实时系统是其中一些（尽管可能不是全部）任务是实时任务的系统。

换句话说，如果您的系统响应太慢而无法赶上最后期限，就会发生一些不好的事情，那么系统需要是实时的，并且您将需要一个 RTOS。

实时系统不需要是确定性的：如果响应时间在 50ms 和 150ms 之间随机变化，但响应时间从不超过 150ms，那么系统是非确定性的，但它仍然是即时的。

【讨论】：

不应该实时系统是，或者有能力，根据定义是确定性的吗？
不，确定性不是必需的。考虑一个系统，如果中断 A 在中断 B 之前到达，系统响应可以在 50 毫秒内计算出来，但如果中断 B 在中断 A 之前到达，则需要 150 毫秒来计算系统响应。那么如果中断到达时间是随机的，那么系统响应时间是随机的，但是有界，系统仍然是实时的。
if something bad will happen 你有麻烦了，不管你有什么操作系统。如果由于任务太多、代码写得不好等而超出边界，即使是 RTOS 也会遇到麻烦。因此，无论是软实时、硬实时还是非实时都无关紧要。保证 50ms 可以在 windows 上轻松获得，但您可能无法进行备份或玩自我射击游戏。但是，您会在 RTOS 上做这些事情吗？

【解决方案3】：

如果您有足够的时间进行试验，也许您可以尝试使用RTLinux 或RTAI。这样，您可以将非实时应用程序保留在 linux 上，但 realtime 应用程序将被移至 RTOS 部分。在这种情况下，您将（可能）实现

优点是——

大量代码可以重复使用
您可以手动划分实时和非实时任务，并尝试实现您想要的响应
我认为迁移时间不会很长，因为大部分代码都在 linux 中

顺便说一句，请注意您可能需要在实时部分运行的硬件驱动程序。

以下 RTLinux 架构可能会帮助您了解这如何成为可能。

【讨论】：

+1 有趣的想法，我之前没有使用过 RT Linux……RT 调度器如何馈入非实时调度器，它只是被视为“更高优先级”吗？
RT Linux中的空闲任务是linux（非RT）操作系统。所以最终，当 RT-Linux 中没有实时任务运行时，linux 有机会运行并正常执行。

【解决方案4】：

听起来您在使用 RTOS 时走在了正确的轨道上。不同的 RTOS 优先考虑不同的事情，无论是健壮性还是速度等等。您将需要弄清楚您是否需要硬 RTOS 或软 RTOS，并根据您的需要，确定您的调度程序将如何被驱动。可以肯定的是，使用常规操作系统和 RTOS 之间存在严重差异。

注意：也许对于最真实的实时系统，您将需要基于硬事件的解决方案，以便您可以保证您的流程也会在您期望的时候执行。

【讨论】：

【解决方案5】：

RTOS 或实时操作系统专为嵌入式应用而设计。在处理关键应用程序的多任务系统中，操作系统必须是 1.确定性的内存分配， 2.应该让CPU时间分配给不同的线程、任务、进程， 3.kernel 必须是非抢占式的，这意味着上下文切换只能在任务执行结束后发生。 ETC 所以普通的windows或者linux都不能用。嵌入式系统中的 RTOS 示例：卫星、一级方程式赛车、CAR 导航系统。

嵌入式系统：旨在执行单个或几个专用功能的系统。带有 RTOS 的系统：也可以是嵌入式系统，但 RTOS 自然会用于需要执行许多功能的实时系统。实时系统：可以在确定/预测的时间内提供输出的系统。这并不意味着实时系统更快。两者之间的区别： 1.普通的嵌入式系统不是实时系统 2. 带有 RTOS 的系统是实时系统。

【讨论】：