Tag Archives: Real-time Systems

实时操作系统杂谈

实时操作系统 (RTOS) 在工业控制和电力系统中有大量应用。我自己接触实时操作系统已有几年时间,虽然并没有实际的项目使用经验,然而耳濡目染总归积累了一些经验和知识。在这里进行整理和分享。

实时操作系统(Real-time Operating System, RTOS)是针对有实时性要求的应用而设计的操作系统。这些应用通常包括汽车引擎控制、轨道交通、工业机器人、飞行器控制系统等。实时操作系统一般提供抢占式调度机制,重要的高优先级任务可以剥夺低优先级任务对CPU的使用权;同时,任务在等待使用资源时,RTOS可以将其CPU的使用权释放给其他就绪的任务,从而使得系统的总体响应速度更快。

目前市场上常见的商用实时操作系统一般有:
– uCosII / uCosIII | Micrium
– FreeRTOS
– Nucleus RTOS | Mentor Graphics
– RTLinux (需要MMU支持)
– QNX (需要MMU支持)
– VxWorks | WindRiver
– eCos

其中除了FreeRTOS和RTLinux外,其余RTOS都是需要商业授权的。uCos II和FreeRTOS是平时接触比较多的RTOS,相关资料比较多。而VxWorks是安全性公认最佳的,用于航空航天、轨道交通和卫星的应用。如果系统中需要使用复杂的文件、数据库、网络等功能,那么RTLinux是比较好的选择;但是如果系统对实时性和性能的要求极高,那么可以使用较为简单的RTOS(如uCosII),再根据需要开发协议或者软件包。总体上来说,操作系统的复杂性是与应用软件的复杂性一致的。同时,功能上更复杂的RTOS对硬件系统的要求也会更高。

一般的RTOS会提供以下全部或部分功能:
– 基于静态优先级(fixed-priority)的抢占式(preemptive)任务调度;
– 进程间通信(基于消息,消息邮箱,管道);
– 基于信号量(semaphore)的进程间同步;
– 任务的创建、暂停、删除;
– 资源访问控制;
– 临界区(critical section)控制;
– 驱动程序接口;
– MMU内存管理、内存动态申请与分配;
– 其他:如GUI用户界面和TCP/IP相关功能。

一般来说,实时操作系统的主要参数指标有:
– 支持的优先级数量,如64、128或256;
– 使用的任务调度算法;时间片轮转调度,加权轮转调度(weighted round-robin),先入先出(FIFO),优先级调度;
– 中断响应速度,即从中断产生到进入中断服务程序的时间;
– 上下文切换时间,即任务切换时间;
– 操作系统大小以及资源使用(ROM及RAM的占用);
– 授权费用与授权方式,是按产品型号计费、产品数量计费还是一次性授权。

其他的选择指标主要就是文档的完整程度,是否有GUI支持,团队对该OS的了解程度,所支持的CPU型号以及需求功能的规模。从更专业的角度上来说,还有是否支持防死锁(deadlock)和优先级反转(priority inversion)等提高系统可靠性的功能,操作系统自身服务程序占用的时间大小。对于时间关键性应用,操作系统需要具备相对确定的执行时间(deterministic execution time)。从调试的角度来说,操作系统是否具有调试功能(尤其是多线程、多核)以及支持的调试工具也是重要的指标。

关于实时操作系统的两个误区:
1、用了实时系统后,系统响应速度一定更快。
不一定。因为实时操作系统本身引入了执行开销,所以对于小型应用来说,有RTOS的性能也许不如无操作系统的情况。实时操作系统的优势最能体现在中大型系统中,当任务间存在复杂的耦合和依赖关系,并且应用程序经常要长时间等待外部资源时。

2、用实时操作系统就可以保证实时性。
不一定。相对来说,使用实时系统可以改善系统的实时性。但是实时操作系统只是作为工具存在的,如果需要提供实时性保障,还需要使用实时系统理论对任务的可调度性和响应时间进行分析,才可以得到科学、系统的响应性保障。

实时系统研究意义的思考

要想弄清研究实时系统的意义,首先必须明确实时系统在整个人类生活中的角色。

实时系统的主要研究对象是工业控制,交通和航空航天,电力及能源,网络设备及网络服务。这些系统的稳定性很大程度上决定了生命财产与经济的安全性:如电力系统的短时间崩溃会导致工业和交通停滞,并可能带来生命财产事故;航天飞行器的软件故障,会导致与地面控制中心的失联甚至是坠毁,带来巨大的财产损失。社会的正常发展和秩序很大程度上依赖于这些实时系统的稳定性和可靠性。纵使我们不想如此,人类生活的方方面面还是很大程度上依存于并不稳定的软件系统。设想如果有这样一个软件漏洞,使得多个重要系统在同一时间失控,那么其带来的社会影响和经济损失将不可估量。 实时系统的主要研究目标:保障实时系统在时间和行为上的可预测性,设立可靠的软件设计方法;就是在预防和避免以上的不可靠情况的出现。

至于在当前计算机速度已经如此之快的情况下,实时性研究是否还有其必要性。

答案我想也是肯定的。在新的计算机结构出现之前,CPU速度的提升不等同于系统实时性的提升。CPU速度的提升显然会减少程序的执行时间 (execution time),但是对于从请求产生到得出结果的响应时间 (response time) 及IO的输出间隔的稳定性 (IO jitter) 依然没有明确的保证。与此同时,更加复杂的操作系统和计算机硬件也提高了这种不确定性,例如Cache缓存和内存分页带来的运行时间浮动。综上所述,CPU速度的提升无法带来实时性上的保证,依然需要依靠实时性分析来保障系统在时间上的可预测性。

Hard v.s. Soft real-time systems

When you study your first lecture in Embedded Systems, you will definitely hear the term ‘hard’ real-time and ‘soft’ real-time. Systems such as avionic systems, automobile engine control systems and cardiac pacemakers could be included in the category of hard real-time systems, while web servers, human-machine interfaces and multimedia systems are soft real-time systems. By intuition, we can infer that these hard real-time systems are more critical and important than the soft ones. But what is the really distinction between them?

To answer this question, we should first introduce the notion of ‘timing requirements‘. Timing requirements, which is also known as timing constraints, are metrics that specify the temporal behaviors of tasks during run-time. Two most important parameters when defining timing requirements are the response time (R) and the deadline (D). The deadline of a task is the time instant by which the task should be completed and the response time is the execution time between the release and the completion of the task.

Now we can give a formal definition of hard real-time: a hard real-time system is a system where all tasks in that system should be completed before their own pre-defined deadlines, i.e., $R_i <= D_i$. Any failure to meet the deadline could possibly lead to disastrous consequence, e.g., chemical leakage, airplane crash or life risk.

When it comes to soft real-time systems, the deadline could be missed occasionally with the only consequence that the usefulness of the result could be degraded. Take the MP3 player system as an example. The failure of delivering the audio steam in time will only cause some annoying lags, but will not do any harm to the person who is listening to it.

Since hard real-time systems require a high level of predictability, the specification is often given in a deterministic way. On the other hand, the timing specification of a soft real-time system is often defined in a probabilistic form, e.g., the probabilistic of deadline misses in every 5 minutes is less than 1%.

The high requirement of temporal behavior of hard real-time systems poses a great challenge in designing such systems. Many restrictions should be imposed on the design of the software, as well as the hardware architecture. Formal methods should also be used to prove the system could work properly under any possible conditions without any deadline miss.

In reality, not all systems can be identified as either soft or hard real-time systems. In these circumstances, the system can be separated into the hard part and the soft part sub-systems and be designed and verified separately, in order to meet their own specifications.

Reference
[1] Jane W. S. Liu, Real-time Systems, Prentice Hall, 2000, page 26-33

Real-time Scheduling in a big picture

Real-time Scheduling Theory has been developed over last 40 years, since the first published work of Liu and Layland in 1973. Before that, real-times systems were designed with cyclic executives, which is in a ad-hoc manner and very difficult to maintain. In general, the theory is consist of task modelling, scheduling policy and schedulability test. Some other issues, e.g., resource management, response time analysis, worst-case execution time analysis, are also involved in the design of real-time systems. Here is a big picture of the real-time theory, based on my knowledge so far:

Research_Realtime Scheduling