实时系统和确定性系统之间是否存在差异?

Mik*_*ike 7 c embedded deterministic real-time definition

在工作中,我们正在讨论新平台的设计,其中一个上层管理类型表示它需要运行我们当前的代码库(C on Linux),但需要实时,因为它需要在不到一秒的时间内响应各种输入.我指出:

  1. 这一点并不意味着它需要"实时",因为它需要更快的时钟和更多的中断处理流程
  2. 要考虑的关键点之一是正在使用的操作系统.他们想坚持使用嵌入式Linux,我指出我们需要一个RTOS.由于内核/用户空间内存分裂,使用Linux将阻止"实时",因此I/O通过引入延迟的文件和套接字完成
  3. 我们真正需要确定的是它是否需要确定性(例如,需要在90%的时间内以<200ms响应输入).

真的在我的脑海中,如果第3点是真的,那么它需要是一个实时系统,然后第2点是最大的考虑因素.

我有信心回答,但后来我想到了......别人怎么想?我在这里是正确的轨道还是我错过了什么?

在"实时"系统和"确定性"系统之间我是否有任何不同之处?除了RTC和RTOS之外,我还缺少执行真正实时系统所需的任何主要内容吗?

期待一些伟大的回应!

编辑:

到目前为止得到了一些好的回答,看起来对我的系统和要求有一点好奇,所以我会为感兴趣的人添加一些注意事项:

  1. 我的公司销售数十万的单位,所以我不想在价格上超过杀人
  2. 通常我们销售主处理器板和独立显示器.还有一个其他CAN设备的连接网络.
  3. 电路板(当前)运行设备,还充当网络服务器,为最终用户向显示器发送基本XML文档

这里的要求是管理层希望"快速"(<1s)更新显示,但IMO 的真正限制来自可通过CAN连接的设备.这些设备通常是电机控制设备,其要求包括"必须在小于200ms内响应".

mik*_*era 10

你需要区分:

  • 硬实时:对响应时间的绝对限制不得违反(计为失败) - 例如,这适用于您控制机器人电机或医疗设备,如果未能满足截止日期可能是灾难性的
  • 软实时:大多数时候需要快速响应(可能是99.99%+),但是如果平均响应非常快,则偶尔会违反时间限制是可以接受的.例如,这在计算机游戏中执行实时动画时是合适的 - 错过最后期限可能会导致跳过帧但不会从根本上破坏游戏体验

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

硬实时需要专用的OS支持(以保证调度)和确定性算法(因此,一旦安排,任务保证在截止日期内完成).要做到这一点很难,需要在整个硬件/软件堆栈上仔细设计.

值得注意的是,大多数商业应用程序都不需要:特别是我认为针对<1秒的响应时间远远超出大多数人认为的"实时"要求.话虽如此,如果在需求中明确指定了响应时间,那么您可以将其视为具有相当宽松期限的软实时.


mar*_*kgz 5

real-time标签的定义:

当活动完成的及时性是功能要求和正确性条件而不仅仅是性能指标时,任务是实时的.实时系统是指一些(尽管可能不是全部)任务是实时任务的系统.

换句话说,如果您的系统响应太慢而无法满足截止日期,那么如果出现问题,系统需要是实时的,您需要一个RTOS.

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