c - 实时系统和确定性系统之间有区别吗?

标签 c embedded real-time definition deterministic

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

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

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

我觉得有信心回答,但后来我在想……别人怎么看? 我是在正确的轨道上还是错过了什么?

“实时”系统和“确定性”系统之间是否存在我遗漏的任何区别?除了 RTC 和 RTOS 之外,我是否遗漏了执行真正的实时系统所需的任何主要内容?

期待一些很好的回应!

编辑:

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

  1. 我公司的销量在几十万,所以我不想在价格上过高
  2. 我们通常销售主处理器板和独立显示器。还有其他 CAN 设备的附加网络。
  3. 开发板(目前)运行设备,还充当网络服务器,将基本的 XML 文档发送到最终用户的显示器

管理人员希望“快速”更新显示 (<1s) 的要求在这里出现,但是 IMO 的真实 限制来自可以通过 CAN 连接的设备。这些设备通常是电机控制设备,其要求包括“必须在小于 200 毫秒内响应”。

最佳答案

你需要区分:

  • 硬实时:响应时间有绝对限制,不得违反(视为失败)- 例如这适用于例如当您控制机器人电机或医疗设备时,未能在最后期限前完成可能会造成灾难性的后果
  • 软实时:大部分时间要求快速响应(可能是 99.99%+),但偶尔违反时限是可以接受的平均提供响应非常快。例如这适用于在计算机游戏中执行实时动画 - 错过最后期限可能会导致跳帧,但不会从根本上破坏游戏体验

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

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

重要的是要注意大多数商业应用程序都不需要:特别是我认为目标 <1 秒的响应时间与大多数人相去甚远会考虑“实时”要求。话虽如此,如果在需求中明确指定了响应时间,那么您可以将其视为具有相当宽松的截止日期的软实时。

关于c - 实时系统和确定性系统之间有区别吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12523595/

相关文章:

c - -static 编译命令怎么会有这么大的内存差异?(C)

c - 如何使用 TCP/IP 堆栈对 PIC18 上的引导加载程序进行单元测试?

user-interface - 图形均衡器

haskell - Haskell 软实时的当前状态

c++ - 数组索引循环开始而不是内存访问错误

c - 从文件中读取并在 C 中打印双比率

c - csc 中 spmv 的 openmp 并行化

android - 在AOSP源代码中添加系统应用程序(通过App源代码/工作AS项目)

c - 如何检测 GSM 调制解调器响应的最后一个字符

linux - ioread 中的延迟