最近学习了一下实时操作系统(RTOS, real time operating system), 因为在软件需求以及架构中，OS是很重要的存在。既然是汽车软件的开发，那么当然real time operating system就是必然的选择。 其实操作系统就是一个软件，只是它的权力很大，它可以分配硬件资源给其他软件模块们，比如内存和CPU的资源。当然它也支持多任务的软件运行模式，这样我们才可以在windows上边听歌边工作边聊天。OS让软件更充分高效的利用了硬件资源，实在不得不赞叹人类的伟大。也难怪比尔盖茨成了世界首富。

当然我们讲的是RTOS, 对时间的响应显然是更为关注的。想想一下，车祸瞬间，安全气囊如果没有按时弹出，那就真的是车毁人亡。那会可千万不能弹出一个窗口说，此任务无响应，请稍后再试......

那为什么需要RTOS呢？我们具体看个例子, 异步通信问题.

我们有一个数据发送软件模块，最开始没数据传输的时候，我们只发送1. 当我们开始传输数据时，第一个被传输的数据是1bit的0. 之后8bits的数据被依次被传输出去。

接下来就是如何接受这8个bit的数据呢？

一开始，这个1bit的0信号对于接收端来说就是一个中断，此时，接收端软件模块被激活，然后接收端会等待1bit的时间，然后采集发送端发送的D0。然后再等待另一个1bit时间，然后再一次采集发送端的数据D1，重复8次。如下图所示:

我们也可以把这个过程画成图标的形式:

接下来就是重点，如果我们考虑两个发送端的情况呢？

这下就很复杂了，一个程序要干这个，另一个程序同时却想干那个，这就产生了冲突。并且如果有更多的程序同时运行呢？想想就头疼。

RTOS却提供了一个非常简单的解决方案。RTOS来管理这些tasks, 并且根据需要，决定哪些需要激活，哪些需要挂起。

RTOS就像一个交通警察，控制着整个大街的车辆行为，要么乖乖的等着，要么就快速通过，全凭警察叔叔的手势。

RTOS指挥程序执行的时序图

所以RTOS的功能也就很明显了:

任务切换示意图

上图是任务切换示意图，任务从1切换到2，就是先把task1存入local memory, 然后把task2写入CPU的寄存器来执行。

对于每一个task，我们至少有4种状态: Ready, Running, Waiting, Dormant(休眠).

对于CPU来说，只能有一个任务是处于Running状态的。Ready表示根据优先级，随时准备放进CPU进行执行。Waiting表示task需要其他的一些信息或者事件，所以放弃被CPU执行的权利，等待那个MR. Right的出现。Dormant就是睡着了，目前并不需要执行的task.

当然还有一个很重要的概念，优先级。

每一个task都有一个优先级，高优先的task比低优先级的task先运行。

上图有三个不同优先级的tasks, 当高优先级的task进入waiting状态时，低优先级的task就可以开始运行了，直到Delay结束，高优先级的task又抢占(preempt)回CPU的执行资源。

接下来是干货:

Scheduling Algorithm (调度算法)

RTOS会根据优先级产生一个优先级队列，如上图。相同优先级的tasks会放到一起，然后根据先来先服务( FCFS , first come first served)的策略执行。

当然除了task,我们还有handler这种霸道的存在。Handler表示一种紧急事件，它的优先级通常高于所有的task,并且在handler执行期间，中断是被禁止的。

ISR的调用如下图:

Cyclic Handler的调用:

汽车的软件要每100ms控制一次发动机，所以是一种周期性的高优先级事件。

接下来要讲一下什么是API，我的理解就是一种关于task的激活，终止，延迟状态切换的指令函数。

接下来看看 Semaphore(信号量) 的概念

首先什么是信号量?

例：若有一售票厅只能容纳300人，当少于300人时，可以进入；否则，需在外等候。若将每一个购票者作为一个进程，请用P（wait）、V（signal）操作编程，并写出信号量的初值。（强调：只有一个购票窗口，每次只能为一位购票者服务）

分析：题中有两类资源，售票厅和售票窗口，售票厅可以容纳300人，窗口只能服务1个人。用户到达后要想买到票，首先要进入售票厅，然后申请到窗口才行。因此用户需要获得两类资源才能成功购票。好了，我们定义两个信号量一个是S1，代表售票厅还能容纳的人数，一个是S2，代表窗口，它们的初始值一个是300，一个是1。程序如下：

解：semophore S1=300，S2=1；

用户进程Pi {

Wait（S1）

进入大厅

Wait（S2）

窗口购票

退出购票窗口

Signal（S2）

退出大厅

Signal（S1）

}

注意，申请的时候能不能把S1，S2的顺序调换呢？答案是不能的，因为如果某进程申请到了窗口（被叫号了），却无法进入大厅，那么其他人就无法购票，也就无法退出大厅，他也就一直进不去了。另外在释放过程中，能不能把siganl（S2）放在程序的最后呢，答案是可以的，但是多进程并发时，资源释放的太晚是不是会影响计算机的效率呢。

下面是另一个重要的概念 Event Flag,引入Event Flag的目的是为了，在一个任务和多个任务之间进行同步，例如有一做饭任务，需要打水任务和买米任务的支持，只有打水任务和买米任务都完成后，做饭任务在开始执行。

如下图，若要完成0b0011的任务，就要先完成0b0001+0b0010,然后正好和0b0011相等，就说明万事俱备，可以执行了。

接下来详细了解一下ready queue是如何执行的

其实每一个task都有一个TCB表，里面记录了上一个task和下一个task，这样就很容易一个接一个的执行。

Tick process

tick其实就是RTOS的钟表，和晶振频率不同，这是属于RTOS的独特时钟频率，是可以人为设定的。Tick interval就是RTOS的时间单位。

操作系统总是基于某个时钟节拍来跑的, 这个节拍的得到往往是通过硬件时钟中断得到，一般来说这个中断的优先级比其他的都高, 这个中断是给操作系统用的，操作系统用他来进行调度啊什么的各种处理。建议不要将时钟率设得太高，否则它就由硬实时变得趋向于软实时了。。因为过高的时钟率使得内核调度频繁进入，可能导致一些低优先级的硬件中断不能得到及时响应。

关于RTOS最后一个有趣的话题就是 Multicore RTOS (多核系统)

关于多核结构，我们有不同的构架。

架构1 SMP

好处就是可以动态调整硬件负载。开发也不用考虑太多硬件的事情。不好的地方就是实时性能不好，cache不能很好地利用。

SMP

架构2 AMP

每个task都有指定的CPU来执行，但是不能平衡CPU的负载。但好处是实时性能表现良好。

AMP

架构3 FDMP, multi-core ready RTOS

是一个比较中和的方案架构。

FDMP

接下来可以聊聊Autosar OS

做任何事情之前都要先看一下为什么要做这件事情，我们到底需要什么？

因为其他的一些功能已经在Autosar其他模块中实现了，所以对于Autosar的OS,它的功能主要就是时间管理和同步。

Requirements on OS

1. AUTOSAR OS shall be backwards compatible to OSEK OS (Autosar OS 应该向下兼容OSEK OS.)
2. AUTOSAR OS shall support isolation and protection of application software AUTOSAR OS shall support start-up and shutdown of ECUs
3. AUTOSAR OS shall support to start lists of tasks regularly
4. AUTOSAR OS shall support to synchronize ScheduleTables to an outside time source
5. AUTOSAR OS shall support communication between OSApplications
6. AUTOSAR shall provide mechanisms to protect the system from unauthorized read access
7. AUTOSAR OS shall support timing protection
8. AUTOSAR OS shall support to terminate and restart OSApplications
9. AUTOSAR OS shall offer support to switch off cores
10. AUTOSAR OS shall support multi-core deadlock free mutual exclusion
11. AUTOSAR OS shall support different methods of degradation
12. AUTOSAR OS shall support multi-core MCUs

接下来就是具体design:

首先从下图认识几个新名词:

功能实现规范:

Core OS

Autosar的核心core就是OSEK, 它早已经被广泛应用在汽车工业。

OSEK成立于1993，由一个德国的汽车公司联盟（宝马，博世，克莱斯勒，欧宝， 西门子 和大众）和 卡尔斯鲁厄大学 。1994年，法国的一个类似的项目VDX,由雷诺和标致汽车发起，也加入到这个联盟来。从此，正式名称为OSEK/VDX。OSEK是一个开放标准，由汽车工业的联盟来发布。OSEK的一部分被标准化为 ISO 17356 。

From < https:// zh.wikipedia.org/wiki/O SEK >

Autosar OS和普通的RTOS的主要区别就是设置了许多保护机制，比如内存保护(memory protection)，以及时间保护(time protection)。

Autosar操作系统中，关于内存保护这个部分的软件被称为SafeContext，控制了软件组件在任务切换和中断的期间的隔离。防止了一个软件组件在未经许可的情况下，写入另一个软件组件的内存。SafeContext被开发为ASIL D等级。

时间保护也是一个非常有趣的话题。

时间错误指的是一个task或者中断错过了它的deadline.

举个例子:

正常执行如上图，但是如果发生下图这种情况:

Task B多运行了1 tick, Task A也多运行了1 tick, 不巧的是下一个Task B还早来了，最终导致Task C超过了deadline.

对于这样的错误，我们有三种时间保护机制:

1 execution time protection 执行时间保护，设置task的执行时间上限，如果延迟了，就要立即停止，不要抢占别的task的资源。

AUTOSAR OS prevents timing errors by using execution time protection to guarantee a statically configured upper bound, called the Execution Budget

2 locking time protection锁定时间保护，设置任务时间锁定上限，就是即使task优先级很低，但依旧可以被执行，并且不被其他task或者中断打扰。

AUTOSAR OS prevents timing errors by using locking time protection to guarantee a statically configured upper bound, called the Lock Budget

3 inter-arrival time protection间隔到达时间保护，就是task执行期间，虽然可以被间断执行，但是可以设置间断时间上线，免得半天执行不完这个task.

AUTOSAR OS prevents timing errors by using inter-arrival time protection to guarantee a statically configured lower bound, called the Time Frame

每一个RTOS都将会有其独特的设计之处，例如ucOS，那个8x8的任务优先级就续表，我想必然惊讶了很多人，那是多么巧妙的一个快速查找最高就绪优先级的方法，FreeRTOS和ucOS的该方法比起来，那真是落后好几条大街。好吧，这里不比较ucOS和FreeRTOS，而是比较OSEK OS和FreeRTOS等的区别。

看过AUTOSAR OS文档的人都会知道，因为OSEK OS的设计思想太好了，所以AUTOSAR就直接借过来用了，也就是说AUTOSAR OS是基于OSEK OS的，而后在其上增加了些特性和需求，如调度表（Schedule Table），内存保护（Memory Protection）以及应用（Application）的概念。本文主要讲解OSKE OS和其他OS的区别。

首先，从OS支持的功能上看，常规OS如FreeRTOS等支持任务（Task）/报警器（Alarm or Timer）/事件（Event）/消息队列（Message）/信号量（Semaphore）/互斥所（Mutex），可见常规OS所支持的功能还是很丰富的。再看OSEK OS，其支持任务（Task）/报警器（Alarm）/资源（Resource）/事件（Event），其中资源和常规任务的互斥锁类似，但资源引入的一个机制，设置资源天花板优先级来解决了优先级反转和死锁的问题：

优先级反转即意味着一个低优先级的任务有可能会先于高优先级任务执行，而使高优先级任务不能够及时的被响应，而OSEK设置资源天花板优先级来解决此类问题。 如上图所示，任务T4优先级最低，运行中，其获取了信号量S1。之后最高优先级任务T1就绪，抢占了任务T4，同样申请获取信号量S1，获取失败而任务Ｔ1重新陷入等待状态。之后任务T4被优先级介于T1和T4之间的任务抢占。任务T1仅当所有低优先级任务执行完毕结束之后，并且信号量S1被释放之后，方可执行。由此可见，在此情况下，任务T2和T3虽然不使用信号量S1，但当T2或者T3执行时却可以延迟高优先级任务T4的响应时间，使高优先级任务不能够被及时的响应，此异常称作优先级反转。

如上图所示，任务T1获取了信号量S1，之后陷入等待状态，等待某个事件的发生。这时低优先级就绪任务T2将获得CPU使用权，开始执行，其将获取信号量S2，之后，任务T1等待的事件发生了，任务T1将重新获得CPU使用权，并尝试获取信号量S2，其将重新陷入等待状态，因为这时信号量S2已经被任务T2获取了。这时任务T2恢复执行，如果其尝试获取信号量S1，这是任务T1也会陷入等待状态，这时任务T1和任务T2都因等待一个已经被对方所获取的信号量而陷入死锁状态。

为避免此问题，OSEK OS定义了资源的天花板优先级的概念，其有以下行为：

• 在系统静态生成时，每个资源的天花板优先级是静态指定分配的，天花板优先级必须至少大于等于所有访问该资源或其链接资源任务中的最高优先级，并且天花板优先级必须小于所有不访问该资源且任务优先级大于所有访问该资源任务优先级的任务中的最低优先级；
• 当任务访问该资源，且其当前优先级低于该资源的天花板优先级时，任务须提升优先级至天花板优先级；
• 当任务释放资源时，须重置任务优先级至申请该资源时的优先级。

如上图所示，展示了天花板优先级的原理。任务T0具有最高优先级，任务T4具有最低优先级，任务T1和任务T4都会访问同一个资源，系统展示了将没有优先级反转的发生，任务T1将仅等待资源被任务T4占用的一个较短时间而就会获得优先响应。

感觉RTOS也是深如海的领域，我也就是了解了个皮毛，慢慢学习吧。有兴趣的可以一起交流学习起来了。