01.前言

对于传统汽车电子开发领域，早期使用的OS则是OSEK OS, OSEK OS是一个为满足汽车电子可靠性、实时性、成本敏感性等需求而打造的实时单核操作系统（RTAOS）。

Classic platform AUTOSAR OS继承OSEK OS，在OSEK OS的基础上又特别明确了AUTOSAR OS至少需要提供的系统服务如下：

基于优先级的调度；

及时的中断处理的能力；

中断优先级必定高于Task；

通过StartOS()与StartOSHook()来创建启动接口；

通过ShutdownOS()与ShutdownOSHook()来创建关机接口；

能够在OSEK OS中跑的APP自然也能够在AUTOSAR OS运行，但同时AUTOSAR os也同时限制了OSEK OS的一些基本使用。

02.AUTOSAR OS 操作系统架构

2.1 OS 3层的处理级别

(1)、中断级

(2)、逻辑级

(3)、Task级

在Task级别，根据其用户分配优先权Task被调度（没有，全或是混合抢先调度），运行时间方面，是在开始执行时间时被占用，以及在任务完成时被再次释放。

以下是优先级规则定义：

(1)、中断优先于Task；

(2)、中断的处理级别由一个或多个中断优先级组成；

(3)、中断服务的流程有一个静态分配中断的优先级标准；

(4)、对于中断服务例程优先级的分配取决于执行和硬件结构；

(5)、Task优先级是被用户静态分配的；

(6)、0是最低优先级，数值越大优先级越高。

2.2 Task的符合类

AUTOSAR OS根据不同的软硬件需求，根据每个优先级可能具备的任务个数以及需要的是基本任务还是扩展任务等来定义了四种符合类分别为BCC1，BCC2，ECC1以及ECC2。BCC1与ECC1不支持多次任务激活请求且每个优先级只能有一个任务；BCC2与ECC2既支持多次任务激活请求，同时也支持每个优先级可以有多个任务。各种符合类之间的兼容关系如下图所示：

(1)、BCC1（只对基本的Tasks，所有的Task有不同的优先级，被限制只能有一个请求激活每个Task和每个优先级只能有一个Task）；

(2)、BCC2（象BCC1，但每个优先级可以有多个Task和允许多个请求激活Task）；

(3)、ECC1（象BCC1，增加扩展Tasks）；

(4)、ECC2（象ECC1，但每个优先级可以有多个Task和允许多个请求激活Basic Task）；

03.Task管理

3.1 Task状态模式

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

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

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

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

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

基本任务与扩展任务的状态机切换如下图所示：

基本任务没有等待状态，所以只能在任务启动与终结时进行同步，基本任务的优点就是占用较小的任务与执行时间。

扩展任务则包含多个同步点，没有同步请求的麻烦，当进一步的条件无法满足时，任务则会切换至等待状态，其缺点也很明显，会占用较多的内存和执行时间。

3.2 Task调度策略

3.2.1全抢占式调度

对于完全抢占式任务调度策略而言，当前运行的任务可在任何时刻被高优先级任务打断而被迫释放处理器控制权，具备最高优先级的任务从就绪状态转入运行状态，而当前任务被抢占从而进入就绪状态，同时保留现场环境，待下次运行时恢复。

如下图所示为完全抢占式任务调度策略，TaskA为扩展任务，TaskB与TaskC为基本任务，优先级TaskA > TaskB > TaskC。

场景1：

当前TaskC处于运行状态，当激活TaskB进入到就绪状态时，由于TaskB优先级高于TaskC，所以TaskC被迫释放处理器控制权，调度器开始调度TaskB从就绪状态变为运行状态，直到TaskB运行完成之后，在调度TaskC继续运行。

场景2：

当前TaskC处于运行状态，激活TaskA与TaskB分别进入就绪状态，由于TaskA优先级高于TaskB，所以TaskA抢占内核运行, 但是由于Resource1仍被TaskC占用，而TaskA无法访问到共享资源Resource1，则被迫进入到等待状态，TaskB开始运行。TaskB运行结束后挂起之后则重新运行TaskC，TaskC运行结束后释放Resource1，进入TaskA得以由等待状态转入运行状态。

此时你会发现高优先级的任务TaskA由于共享资源被占用的原因导致不能先于TaskB运行的现象，该现象也被称为优先级反转现象。

为了解决该问题，在此需要提到AUTOSAR OS的优先级天花板模式：即将访问共享资源的任务优先级在占用资源的过程中提升至共享资源任务的最高优先级之上，从而避免优先级反转现象的发生。

即若TaskC运行过程中占用共享资源Resource1，此时即使存在需占用共享资源的高优先级任务TaskA被激活，也必须保证TaskC运行结束之后才能执行TaskA，也就意味着在重要代码执行之前，应采用资源保护机制，以免被高优先级的任务打断。

3.2.2非抢占式调度

用非抢占式调度策略，那么当前运行状态的任务在任何时刻都不会其他高优先级任务所抢占，任务的切换只会发生在任务完成时。

非抢占式调度策略的问题在于任务执行时间不确定，系统调度实时性较差。如下图所示为非抢占式调度策略，可见即使高优先级任务 TaskB被激活切换至就绪状态，也必须等到TaskC执行结束之后才能够被调度。

04.Task 调度

4.1 AUTOSAR Task调度时序图

在软件架构设计时，为了保证CPU的负载率以及任务的前置条件，需要将每个SWC的Runnable进行定义，根据SWC的属性进行设计，如下图所示。

在原则上，需要定义一些主要规则：

(1)、SWC对时间要求不高的，尽量将Runnable的时间放长点。

(2)、相同Task的Runnable，可以设计多个Task，通过Offset的设置，避开同一周期的Task同时运行。

Task调度时序图

4.2 AUTOSAR Task调度构成图

在软件架构设计时，为了让软件架构更加清晰，可以分成三类：

(1)、ECU在怠速和空转时的任务处理；

(2)、ECU在上电或唤醒，下电或睡眠时的任务处理，以及总线收发通讯任务和消息处理任务；

(3)、ECU在Normal模式下运行时的任务处理（这里主要处理和执行功能所需的任务）；

Task调度构成图

05.AUTOSAR OS系统启动

5.1 OS在OSEK规范中的启动过程介绍

在处理器复位后，实施初始化过程，但是OS提供支持一个初始化的标准方法。OS和应用程序必须要清晰定义硬件初始化函数。在OS初始化后，OS没有强制定义一个需要启动的特殊Task，但是允许用户在系统创建时指定自动启动的Tasks和Alarms。在CPU复位后，硬件标准应用函数被执行（没有操作系统介入）。

例如，在OS被初始化后（调度程序没有运行），StartOS调用钩子函数StartupHook()，用户可以在那里为他的OS增加一些初始化代码。基于启动的应用模式，为了能在StartupHook()里结构化初始化代码，为此提供了一个GetActiveApplicationMode的服务。在从钩子函数返回后，OS启动中断，并且开始调度程序。在这以后系统运行并且执行用户的Tasks 。

(1)、在复位后，用户释放执行的（不可移植）特殊硬件代码。到Phase5之前，Category 2的中断不能运行；

(2)、调用StartOS；

(3)、OS执行内部启动函数；

(4)、调用钩子函数StartupHook()，用户可能会将初始化程序放在这里。在运行钩子函数期间，所有的中断需要被禁用；

(5)、OS激活用户中断和激活调度程序。对当前应用模式OS启动自启动的Tasks和声明的Alarm。自启动的Tasks优先级是未定义的，但是具有高优先级。自启动Tasks在自启动Alarm前被执行。

(6)、运行用户Tasks ；

5.2 OS在Vector模块中的启动过程介绍

(1)、执行Os_InitMemory() 初始化OS参数（OS使用到的变量等）;

(2)、执行Os_Init() 初始化OS参数（变量，OS中断控制器，MPU等）；

(3)、执行EcuM_Init() 初始化部分硬件模块（Port,Dio,Adc…）；

(4)、执行EcuM_StartOS() 启动OS；

(5)、再OS开始执行后Task_Init() 会首先被调用. 执行EcuM_StartupTwo() ，此函数会调用BswM_Init() 来初始化其他硬件模块(CAN/LIN/NVM…)；

(6)、再BswM_Init() 函数最后执行Rte_Start() 用于启动所有任务。

06.AUTOSAR OS系统关闭

6.1 OS在OSEK规范中的关闭过程介绍

规范中定义了一个服务以便关闭操作系统，ShutdownOS。这个服务被应用或是操作系统严重错误时调用。当ShutdownOS被调用时，操作系统将调用钩子函数ShutdownHook（用户通常在ShutdownHook自由的定义系统行为），然后再关闭系统。

6.2 OS在Vector模块中的关闭过程介绍

(1)、停止CAN/LIN/ETH通信；

(2)、保存NVM数据；

(3)、EcuM执行休眠程序；

(4)、设置唤醒源；

(5)、EcuM执行OS停止程序；

(6)、MCU进入休眠模式。

07.AUTOSAR OS调试

两个钩子函数（PretaskHook和PostTaskHook）在Task上下切换时被调用，这两个钩子函数也许可以用来调试或时间的测试（包括上下切换时的时间）。因此PostTaskHook在每次Task离开Running状态时直接被调用，PreTaskHook是每次Task进入Running状态时被直接调用。因为Task仍然/已经在Running状态下，所以GetTaskId不会返回INVALID_TASK。

如果PostTaskHook调用没被定义在ShutdownHook之前或之后，当调用ShutdownOS同时Task正在运行ShutdownOS时，PostTaskHook可能会调用或不被调用。

08.中断处理

处理中断（Interrupt Service Routine：ISR）的功能被分类为两种ISR（中断服务程序在OS中具有高于Task的优级先级）：

Category1

ISR 不需要OS接管，不受OS中断优先级等管理，在ISR完成后，处理程序继续运行被中断停止的指令，如中断不会影响Task的管理。这种类型的ISRs开销最少。

Category2

ISR需要OS接管，并受OS管理。OS提供一个ISR-Frame为专用用户程序准备一个运行时环境，在系统创建时用户程序被分配给中断。

在中断服务程序使用OS服务只限于下图所示。

在ISR内重调度不会发生。如果一个抢占式Task被中断并且没有其他的中断被激活，重调度会在Category2终止后发生。这个行为确认Task只有通过OS调度点才被执行，为实现这一目标，可实施对所有类型的ISR限制中断优先级。