menu

实时性, Real-time

  • date_range    info
    sort

这篇文章里我想说的有几个主题：

  • 什么是实时系统？
  • 为什么需要实时系统？在Autonomous Vehicle或者Robot上？
  • 基于Linux的实时系统，我们需要做什么？怎么衡量我做的东西是否有效果？
插个私货：就我自己的理解，在目前我们所提及的语境下，RTOS(Real-time Operating System)和IoT OS概念似乎太过于重合了。  
提起RTOS我们可能就想到FreeRTOS，Mbed.....等等。其实这些OS更突出的特性是IoT特性(designed to be small enough to run on a microcontroller)，而不是实时特性。

What is a Real-Time Operating System (RTOS)？

定义

What is a Real-Time Operating System (RTOS)?

一般而言，操作系统的任务是管理计算机的硬件资源和应用程序。 实时操作系统会执行这些任务，但是运行时间精度和可靠度都极高。 在实际应用中，有的系统失常代价高昂，甚至会引起安全事故。这时，操作系统的时间精度和可靠度都显得格外重要。

顾名思义，实时操作系统必须在已知的关键时间内完成关键操作，至少要在绝对大多数情况下在已知时间内完成关键操作。 部分这类操作包括操作系统调用和中断处理。 完全满足在指定时间内完成关键性操作的实时操作系统，被称为“硬实时”操作系统。大多数情况下能满足在指定时间内完成关键性操作的实时操作系统，被称为“软实时”操作系统。 实际情况中，上述分类的指导意义有限。每个实时操作系统都有独特的性能特征，用户在决定使用某个实时操作系统之前需要仔细研究这些特征。

下面通过列子来帮助理解实时操作系统的概念。 假设您在为一款新车设计安全气囊系统。 在该情况下，极小的时间误差（太早或太迟）都会产生灾难性后果，甚至导致人员伤亡。 因此，需要一个硬实时系统；在系统设计上要确保没有任何操作的优先级可以凌驾于时间限制之上。 另一方面，如要设计一个接收流媒体手机，在保持大致不丢失流媒体数据的前提下可以偶尔遗失少量数据。 在这种应用中，一个软实时操作系统就可满足要求。

如果编程合理，实时操作系统可保证程序运行在时间上的稳定可靠性。 实时操作系统向用户提供任务优先级排序的高度控制权，也通常会允许用户检查任务执行是否符合时间上设定的要求。

分类

大体上，分为下面三个类别，Hard/Firm/Soft：

* Hard: missing a deadline is considered a system failure. Examples of hard real-time systems: airplane sensor and autopilot systems, spacecrafts and planetary rovers.
* Firm：treat information delivered/computations made after a deadline as invalid. Like soft real-time systems, they do not fail after a missed deadline, and they may degrade QoS if a deadline is missed (1). Examples of firm real-time systems: financial forecast systems, robotic assembly lines.
* Soft: try to reach deadlines but do not fail if a deadline is missed. However, they may degrade their quality of service in such an event to improve responsiveness. Examples of soft real-time systems: audio and video delivery software for entertainment (lag is undesirable but not catastrophic).

功能

实时系统的定义看起来明确的，但是是不是可以更具体点？实时系统到底比正常的桌面系统，多了什么。

  • 如果编程合理，实时操作系统可保证程序运行在时间上的稳定可靠性。
  • 实时操作系统向用户提供任务优先级排序的高度控制权
  • 也通常会允许用户检查任务执行是否符合时间上设定的要求。

确定性 (Determinism)

系统的实时性，在于其能不能很好的完成Deadline——而Determinism就是完成Deadline的必要条件。

  • ”Determinism“：系统在“for a known input”的时候，必须得是“same output”，必须是确定的执行时间。
  • “Nondeterministic”： means the ∆Ƭ latency between “stimulus” and “response” falls outside of an accepted upper and lower bound, or cannot be predicted. Known as “Latency Jitter”。

Latency –> Determinism –> Deadline –> Realtime

PS: 面向桌面/服务器领域的操作系统更多会偏向Throughput，而没有顾及Determinis，也因此没有了实时性。

PS: task并不单单指代进程，比如说interrupt handler也是一种task，只不过我们基于Linux来开发的话，不太会使用到interrupt handler来做逻辑性的事务

程序执行时间的确定性

Neither deterministic user code on a non-real-time operating system or nondeterministic code on a real-time operating system will result in real-time performance.

执行时间确定性的实现，依赖操作系统和应用程序：

  • 操作系统保证其函数调用和服务的执行时间应具有可确定性。默认情况的Linux的就不能保证这点，比如说”Calls to malloc/new and free/delete will probably result in pagefaults”。
  • 应用程序需要保证其写法， 做到“delivers deterministic execution”。反例如Nondeterministic_algorithm。

程序调度的确定性

在实际应用中，通用操作系统不会始终严格按照程序设置的优先级执行。因为通用操作系统可同时运行多个应用程序和进程，所有任务都会被分配到一些处理时间。 在某些情况下，低优先级任务的临时优先级可能会比高优先级任务更高。 这样，每个任务都会分配到一定的运行时间。 这会违背程序设计人员的设计初衷。

如上是通用操作系统所用的公平调度常见的问题，“每个任务都会分配到一定的运行时间”，会导致调度的延迟 –> missing a deadline。

实时操作系统可严格按照程序员设置的优先级执行程序。 在多数实时操作系统上，如果一个高优先级任务占用率100%的处理器资源，低优先级任务将一直等待直到高优先级任务完成。 因此，设计实时应用程序时，必须谨慎、合理设置优先级。 在一个典型的实时应用程序中，设计者应该将实时代码放置在高优先级的部分。 写入磁盘、网络通信等较低优先级的代码应该放在较低优先级的部分。

调度上的实现，主要分两个类别, Event-driven和Time-sharing：

  • Event-driven – switches tasks only when an event of higher priority needs servicing; called preemptive priority, or priority scheduling.
  • Time-sharing – switches tasks on a regular clocked interrupt, and on events; called round robin.

也就是说，实时调度算法不等于固定优先级抢占，只要可以满足程序执行的timing和deadline就可以。比如在多核系统中，不用实时调度算法，直接用cgroup来做CPU Isolation，间接的做到Time-sharing。

monitoring for Timing/Deadline

Wind River StethoScope

通常情况，我们针对计算机系统的Monitor/Profiling都是针对Performance/Utilization/Throughput等等，而不是针对Timing/Deadline。

传统的实时操作系统上的程序，都是进行严格的设计和调试之后，由设计人员保证响应的确定性。整个系统的逻辑相对比较清晰，甚至都不是多核心的结构。

但是对现代机器人/自动驾驶平台来说，软件的复杂性要大的多，从感知到控制，还有像平行驾驶/车路协同这种Client。在这种背景下，必须要有辅助的软件机制来帮忙实现设计阶段的测试和生产环境的监控。

Do I Need a Real-Time System?

Do I Need a Real-Time System?

Which applications need a real-time system？

事件响应(event response)

事件响应类应用需要在指定的时间内对外界触发条件作出响应。这种程序类型是我们最常接触的，比如如下一段ROS代码。

while (1) {
struct can_frame frame;
int nbytes;

nbytes = read(s, &frame, sizeof(frame));

if (nbytes > 0) {
    ......
    range_msg.header.frame_id = "ultrasound";
    pub_range.publish(range_msg);
    ......
}

ros::spinOnce();
}

从read到spinOnce是这段代码的一个周期，从“被can触发signal唤醒”到重新“read进入睡眠”。
在这个周期中，其不确定性来源于几个地方： 1.read, 2.publish, 3.没有分配足够的时间片。
其中，1,2的不确定性来源于系统调用，3的不确定性来源于调度策略。

从deadline的角度上讲，

闭环控制(closed-loop control)

闭环控制同时需要输入和输出事件

PID控制是我们最常接触的closed-loop control。

也是，我们贴一段ROS代码来分析。

对于PID控制器来说，如果在y(t)，也就是measured process value，这个环节出现Latency，那么PID控制器

汽车巡航控制系统会连续处理反馈数据，调整输出。 因为输出数据取决于是否能在指定时间内处理完输入数据。在指定时间内完成任务至为重要，只有这样才能有正确的输出。 如果巡航系统无法在给定时间点上判断合适的油门设置，会发生什么情况？ 硬实时系统可保证在指定时间内及时处理控制系统的输入数据。

Autonomous Drive

那么，在自动驾驶的场景下，我们对Real-Time的需求是怎么样的

Simulation: What would happen if i use a non-real-time system?

待补全
找时间用Matlab模拟下几个case。。。。