logo标签列表

实时系统和仅具有确定性的系统之间有区别吗？

cembeddedreal-timedefinitiondeterministic
7
在工作中，我们正在讨论一个新平台的设计，高层管理人员之一表示它需要运行我们当前的代码库（Linux上的C语言），但需要实时响应各种输入，响应时间需少于一秒。我指出：
  1. 这一点并不意味着它需要是“实时”的，而是需要一个更快的时钟和更多流程化的中断处理。
  2. 考虑的关键点之一是使用的操作系统。他们希望继续使用嵌入式Linux，我指出我们需要一个RTOS。由于内核/用户空间内存分离，使用Linux将阻止“实时”，因此I/O是通过文件和套接字完成的，这会引入延迟。
  3. 我们真正需要确定的是它是否需要确定性（例如需要在200毫秒内90％的时间内对输入做出响应）。

如果第3点成立，则它确实需要是实时系统，然后第2点是最大的考虑因素。

我对回答感到自信，但后来我在思考它...其他人有什么想法？我是在正确的轨道上还是我错过了什么？

实时系统和仅是“确定性”系统之间是否有任何差异，我是否遗漏了执行真正实时系统所需的任何重要内容，除RTC和RTOS外？

期待一些很棒的回复！

编辑：

到目前为止，我们得到了一些好的回答，似乎有一些人对我的系统和要求感到好奇，所以我将添加一些注释供那些感兴趣的人阅读：

  1. 我们公司销售数万台，因此我不想在价格上过度投入。
  2. 通常我们销售一个主处理器板和一个独立显示器。还有一个连接的其他CAN设备网络。
  3. 该板（目前）运行设备，并作为Web服务器向最终用户发送基本XML文档。

这里的要求在于管理层希望快速更新显示屏（<1s），但是真正的约束力来自可以通过CAN连接的设备。 这些设备经常是带有“必须在少于200ms内响应”的要求的电动装置。

2
实时计算意味着存在一个硬时间限制，而不是仅满足90%的时间就足够了。时间限制是硬性的还是非硬性的？这决定了您需要哪种系统。 - user684934
我认为这取决于你的平台预期使用量。如果产品量很大，那么 CPU 成本更加重要。与尝试移植到实时操作系统并且没有地址空间保护等功能相比，继续使用现有的 Linux 代码并购买非常快速的处理器会容易得多且更快速。 - TJD
@TJD - 那里的问题是即使使用最快的处理器也不能保证约束条件得到满足。据我所知，一个带有RTC和高时钟速率的uC系统可能会被操作系统限制。 - Mike
5个回答
10

您需要区分以下两种实时性：

  • 硬实时性：有一个绝对时间限制，不能超过此限制（否则将视为失败），例如在控制机器人电机或医疗设备时，未能满足截止日期可能会导致灾难。
  • 软实时性：大部分时间需要快速响应（可能高达99.99％+），但偶尔超过时间限制也是可以接受的，只要平均响应速度非常快即可。例如，在计算机游戏中执行实时动画时很适合这种方式 -错过截止日期可能会导致跳帧，但不会根本破坏游戏体验。

只要您具备足够的硬件并注意识别和优化瓶颈，软实时性在大多数系统中都很容易实现。通过调整，甚至可以在具有非确定性暂停（例如Java中的垃圾回收）的系统中实现。

硬实时性需要专用操作系统支持（以保证调度）和确定性算法（以便一旦被安排，任务就保证在截止日期内完成）。正确实现这一点非常困难，需要在整个硬件/软件堆栈上进行仔细设计。

重要的是要注意：大多数商业应用程序都不需要任何一种实时性：特别是我认为将响应时间定位在小于1秒的范围远远超出了大多数人对“实时”需求的考虑范围。尽管如此，如果要求明确指定响应时间，则可以将其视为具有相当宽松截止日期的软实时性。

对于硬/软实时系统的区分，可以给予加1分。另一个很好的硬实时系统的例子是飞机上的航空电子/飞行控制系统，在这种情况下，满足截止时间至关重要。 - prelic
+1，很有趣的一点，我喜欢这个定义调整。我们的系统确实有一些“硬实时”约束，例如我们的EEV（电子膨胀阀）的电机控制，但并非所有“硬”要求...也许使用两个“较小”的处理器和RTOS进行分离架构是一个更好的想法，用于电机控制。您对硬件需求的看法仅是RTC（用于提供RTOS的实时时钟）和足够的计算能力吗？ - Mike
基本上是的，高分辨率时钟是实时硬件的关键。RTOS的工作是以确保在给定的计算能力下满足截止日期的方式进行调度。从技术上讲，如果要求足够宽松，甚至不需要高分辨率时钟，因为RTOS可以处理调度。 - prelic
1
分离式架构通常是个好的想法。大多数实时操作系统应该支持这个：用RTC / 实时调度在C语言中编写硬实时部分，用Java或其他方便的堆栈以软实时方式编写系统的其余部分。这意味着您不需要担心在软实时侧使用非确定性算法。 - mikera
1
呃……电机控制。我总是会选择嵌入式微控制器来进行管理/监控，然后从“桌面”操作系统中进行操作。除了实时要求外，电机/电磁铁/其他控制器连接到外部布线，通常由第三方承包商安装，并且稍后可能会受到其他承包商在进行其他工作时的“意外高能注入”的影响。更换便宜的嵌入式板的烧焦、碳化残留物比安装新的桌面、从备份中恢复（如果他们有备份）并重新启用系统要容易/便宜得多。 - Martin James
@prelic - 很好的例子。机舱中的航空电子设备不会直接尝试控制引擎，实时的工作是由每个引擎上的专用控制器完成的。 - Martin James
5
根据“实时”标签的定义：
当活动完成的“及时性”是一项功能要求和正确性条件，而不仅仅是一个绩效指标时，任务就是“实时”的。实时系统是其中某些（但可能不是全部）任务是实时任务的系统。
换句话说，如果系统无法在截止日期前及时响应会发生不良后果，那么系统需要是实时的，并且需要RTOS。
实时系统不需要确定性：如果响应时间在50ms到150ms之间随机变化，但响应时间从未超过150ms，则该系统是非确定性的，但仍然是实时的。
一个实时系统不应该是或者说应该具备确定性的能力，这不是定义所规定的吗？ - Mike
不，确定性并非必需品。考虑一个系统，如果在中断B之前到达中断A，则系统响应可以在50毫秒内计算出来，但如果在中断A之前到达中断B，则需要150毫秒才能计算出系统响应。因此，如果中断到达时间是随机的，则系统响应时间是随机的，但是有界限，而且系统仍然是实时的。 - markgz
如果发生了什么不好的事情，无论你使用什么操作系统都会遇到麻烦。即使是实时操作系统（RTOS），如果由于任务过多、代码编写不当等原因而超出边界运行，也会遇到麻烦。因此，软实时、硬实时甚至非实时并不重要；在Windows上很容易轻松地获得50毫秒的保证，但您可能无法备份或玩射击游戏。然而，在RTOS上做这些事情吗？ - Arno
2
也许你可以尝试使用 RTLinux 或 RTAI 进行实验，如果你有足够的时间。通过这种方式，你可以将非实时应用程序保留在 Linux 上，但是实时应用程序将被移动到 RTOS 部分。在这种情况下，你可能会实现小于 1 秒的响应时间。
优点如下：
- 大量代码可重复使用 - 你可以手动分配实时和非实时任务，并尝试实现所需的小于 1 秒的响应时间。 - 我认为迁移时间不会很长，因为大部分代码都在 Linux 上。 需要注意的是，在实时部分可能需要运行硬件驱动程序。
RTLinux 的以下架构可能会帮助你理解这是如何可能的。
图片链接：https://istack.dev59.com/lU0PE.webp
+1 有趣的想法，我以前没有使用过RT Linux...实时调度器如何与非实时调度器结合，它只是被视为“更高优先级”吗？ - Mike
1
在 RT Linux 中的空闲任务是普通的 Linux（非 RT）操作系统。因此，当 RT-Linux 中没有实时任务运行时，Linux 就有机会运行并正常执行。 - Raj
1

听起来你在RTOS方面走在了正确的轨道上。不同的RTOS会优先考虑不同的事情，如健壮性或速度等。你需要确定你需要硬实时操作系统还是软实时操作系统，并根据你的需求确定调度程序的驱动方式。有一件事是肯定的，使用常规操作系统和RTOS之间存在严重的差异。

注意：也许对于最真实的实时系统，你需要硬事件驱动分辨率，以便能够保证你的进程将在你期望的时间执行。

0

RTOS或实时操作系统是专为嵌入式应用而设计的。在处理关键应用程序的多任务系统中，操作系统必须具有以下特点： 1. 内存分配必须确定性； 2. 应允许CPU时间分配给不同的线程、任务或进程； 3. 内核必须是非抢占式的，这意味着上下文切换只能在任务执行结束后发生。等等。 因此，普通的Windows或Linux不能使用。 嵌入式系统：专为执行单个或少数几个专用功能而设计的系统。 具备RTOS的系统：也可以是嵌入式系统，但通常会在需要执行多个功能的实时系统中使用RTOS。 实时系统：能够在一定/可预测的时间内提供输出的系统。这并不意味着实时系统更快。 两者之间的差别： 1. 普通嵌入式系统并非实时系统 2. 具备RTOS的系统是实时系统。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接