【车载开发系列】AutoSAR OS基础篇

【车载开发系列】AutoSAR OS基础篇

一. 为啥要用OS？

我们知道传统所说的“裸机编程”就是不带操作系统的编程，在系统需求相对比较简单的情况下使用裸机编程可以满足要求。但是随着系统需求越来越复杂，此时就需要用到模块化设计方法以及多任务编程思想，否则后期软件升级维护成本将会急剧增加。
虽然我们可以采用传统编程方式（如计数器与状态机）来实现简单多个任务的调度，但是当涉及到多个任务之间的状态切换，优先级，现场保护，执行时间控制等方面就显得极为吃力，开发效率低下且极容易出错。
此时迫切需要一种机制来替我们完成各个任务之间的调度功能，使得开发人员能够更关注于应用软件的开发，提高软件开发效率，为此OS(Operation System)便应运而生！

二. OS要解决的问题

实际上，OS主要是为我们解决了以下几个基本问题：
改变各任务的执行频率；
改变各任务的执行时间；
设定各任务的优先级，保证高优先级任务能够及时执行；
任务切换时的现场保护与恢复；
共享资源的安全访问机制等；
其中调度功能则是OS的核心组件，主要功能就是负责任务的切换。在一个单核系统中，多任务只能并发执行，通过时间片轮转法来切换任务，通过时钟中断或者软中断的方式来触发一次任务的切换，从而打断当前执行任务，调度器抢夺CPU控制器，来进行任务调度并切换至新任务开始执行。

三. OS调度器功能

对于传统汽车电子开发领域，早期使用的OS则是OSEK OS, 其中OSEK是德文“Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug”的缩写，译为汽车电子开放系统及接口。OSEK OS是一个为满足汽车电子可靠性、实时性、成本敏感性等需求而打造的实时单核操作系统(RTAOS)。
该实时单核操作系统具备以下基本特性以及基本系统服务。

四. AUTOSAR OS 与 OSEK OS联系

首先，AUTOSAR OS是基于OSEK OS继承发展而来，所以上述的OSEK OS的基本特点在AUTOSAR OS都能够得到满足，所以AUTOSAR OS是向后兼容的，也就意味着在OSEK OS上能够运行的应用程序同样也可以在AUTOSAR OS上运行。
除此之外，AUTOSAR OS也存在自身的一些独特的基本特点，下面将从该OS的基本属性与系统基本服务两个方面展开：

五. AUTOSAR OS基本对象

AUTOSAR OS总共包含以下6大基本对象：Counter，Alarm，Schedule Table，Task，ISRs，Resource。这6个基本对象必须归属于一个OS Application，可以简单理解为OS Application是上述6大基本对象的容器，而归属于同一OS Application的基本对象则可以互相访问，来自其他OS Application的基本对象则需要通过配置来限制性访问。

六. Task基本任务与扩展任务

AUTOSAR OS中存在两种任务：基本任务(Basic Task)和扩展任务（Extended Task）。基本任务则存在以下三种状态：

1）运行状态(Running)

处于运行状态的任务可能被高优先级任务或者中断抢占从而进入就绪状态，且同一Core中任何时刻只会存在一个任务处于运行状态，任务运行结束后则将自己挂起进入阻塞状态；

2）就绪状态(Ready):

处于就绪状态的任务由调度器决定是否启动进入运行状态，且该状态时任务切换至运行状态的前提；

3）阻塞状态(Suspend):

处于阻塞状态的任务是被动的，可以由API函数或Alarm激活进入就绪状态；

4）扩展任务的等待状态(Waiting)：

扩展任务与之相比，则多了一个等待状态(Waiting),解释如下：
等待状态(Waiting)：
当任务的运行需要等待某一或某些事件被置位时，任务进入就绪状态。

七. Counter

Counter概念的引入是为了实现对硬件计数器以及软件计数器的管理，为Alarm与Schedule table提供支持。即多个Alarm可以共用一个Counter，一个Schedule Table只能由一个Counter来驱动。 Counter按照AUTOSAR定义可分为以下两种：
1）Hardware Counter:
该Counter的增加由硬件外设驱动，如Gpt或者timer等；
2）Software Counter：
该Counter的增加通过调用API函数IncrementCounter来实现，且每次只能增加1；基本原则： 优先使用Hardware Counter，因为可以根据Task的激活状况来减少无意义的时钟中断；

八. Alarm

在计数器的基础上，AUTOSAR OS为应用软件提供了闹钟机制，多个闹钟可以连接一个Counter，当到达Alarm所对应的计数器设定值时，则可以激活一个任务，设定一个event，调用callback或者增加计数器等功能，但只能是一对一。

九. Schedule Table

如Alarm所述，当计数器的计数值依次达到各个Alarm设定的计数值时，各个Alarm被触发，但很难保证各个Alarm有特定的时间间隔，且每个Alarm只能激活一个Task或者Event，所以需要多个Alarm来协作实现在同一时刻触发多个Task或者Event，因此Schedule Table应运而生！
一个软件Counter +多个Alarm队列就可以实现静态定义的任务激活机制。 但随着Schedule Table的引入，因此一般建议能用Schedule Table就不要用Alarm。

十. ISRs

在AUTOSAR中定义了两类中断服务程序(Interrupt Service Routine)。分别为一类中断(Category I)与二类中断(Category),两者之间的区别定义如下：

1）Category I：

此类中断服务程序不能够使用OS提供的系统服务，当中断执行完成之后则会重新跳转至产生中断的地方继续执行，不会影响到任务的执行，因此占用系统资源较少。

2）Category II：

该类中断则可以调用OS系统服务，如激活任务或者设置事件等
在AUTOSAR OS中，中断的优先级始终高于任务的优先级，即最低优先级的中断都可以打断最高优先级的任务，即使该任务不可抢占也不例外。 因此，中断服务子程序的执行时间不宜过长，否则会影响到整个系统的实时性。

十一. Resource Management

Resouce作为OS调度过程中一个十分重要的对象，Resource管理就显得尤为重要。资源管理就是为了协调具有不同优先级的多个任务或者中断对共享内存（如内存或者硬件等）的并发访问。
不过幸运的是AUTOSAR OS采用上述的优先级天花板模式来避免任务优先级反转以及死锁问题的发生，即资源的上限优先级必须高于所有该资源的任务以及中断的优先级，但是应低于不访问该资源的任务的最低优先级

十二. Task调度策略

AUTOSAR OS是基于优先级进行任务调度，所以每个任务必定有一个优先级，而每个任务都是根据其自身特点来定义一个优先级且需要配置其可抢占属性。
可抢占属性可分为不可抢占与全抢占，这里所说的抢占指的是内核抢占。AUTOSAR OS可根据各个任务的可抢占属性配置，来提供不同的调度策略，调度策略可分为以下三种：
1）完全抢占式：OS所有任务均是可抢占类型；
2）非抢占式：OS中所有任务均是不可抢占的；
3）混合抢占式：OS部分任务是可抢占类型，部分任务是不可抢占类型；