汽车电子笔记之：AUTOSA架构下的OS概述

目录

1、实时操作系统（RTOS）

2、OSEK操作系统

2.1、OSEK概述

2.2、OSEK处理等级

2.3、OSEK任务符合类

2.4、OSEK优先级天花板模式

3、AUTOSAR OS

3.1、 AUTOSAR OS对OSEK OS的继承和扩展

3.2、AUTOSAR OS的调度表

3.3、AUTOSAR OS的时间保护

3.4、AUTOSAR OS的内存保护

---

1、实时操作系统（RTOS）

        实时系统(Real-Time System)通常是指对任务的执行有严格时间要求的系统。在该类系统中应用所执行的动作及对外部事件的应答都应该是及时的并且是可预见的,否则,任务将会错过截止时间或者丢失数据。实时系统通常包含硬实时系统和软实时系统。硬实时系统要求任务必须在截止时间前完成，否则，系统将会出现故障；软实时系统则是期望任务在预定时间内完成,但一定限度的延迟对系统来说并非是致命的。实时系统通常具备以下特点：

        高的输入输出吞吐量；

        对外部异步信号快速的响应能力；

        快速的任务调度；

        具有任务间安全的通信机制等。

        汽车电子控制系统就是一种实时系统，它要求所有任务都是可预见的，通常情况下,包含硬实时任务和软实时任务,任务较多,系统较为复杂。过去,实时系统的设计方法是采取控制循环的方式来查询任务的执行，这种方法需要程序员对任务的执行时间和执行顺序有严格的把控,编程难度大,同时,造成软件移植难度增大,可重复利用性降低。

        实时操作系统(Real Time Operation System，RTOS)是应用于实时系统的操作系统，为用户提供了结构化的方便的任务执行环境，而且能够很好地满足实时性要求。RTOS有以下优点：

        消除了在应用软件中对处理器分配的需要;

        修正或添加任务可在应用软件中完成而且不会影响到系统的响应要求;

        除了对任务进行管理外,多数RTOS提供任务通信、任务同步、定时器及内存管理机制；

        RTOS 隐藏了底层硬件的具体特性，为用户提供了一个不依赖于处理器的实时运行环境；

        可以容易地移植到 RTOS 供应商支持的其他处理器。

        综上所述，当前嵌入式操作系统多为实时操作系统。

2、OSEK操作系统

2.1、OSEK概述

        OSEK操作系统（OS）是一个为分布式嵌入式系统所定义的单核操作系统。为适应汽车电子可靠性、实时性、成本敏感性的需求，OSEK操作系统具有以下特性:

        操作系统中任务、资源、服务是静态配置的；

        支持在只读存储器上运行；

        应用中的任务具有很好的可移植性；

        操作系统中所定义的动作是可预见和可记录的。

OSEK 操作系统提供以下服务：

        任务管理：包括任务的激活与终止、任务状态的切换；

        同步服务：主要通过资源调度和事件控制（下文会有例子）来实现；

        中断服务程序：包括一类中断和二类中断；

        报警机制（ALARM）：包括相对报警和绝对报警；

        进程间通信：用于进程间数据的交换；

        错误处理：用于支持各种错误的处理。

        AUTOSAR OS继承了上述全部特性。

2.2、OSEK处理等级

        OSEK操作系统定义了三层处理等级：任务层(task level)、调度器的逻辑层(logicallevel for scheduler)和中断层(interrupt level)。任务层分为全抢占、非抢占和混合抢占(preemption full/non/mixed)。任务的执行时序由调度器(Scheduler)根据调度规则而决定。处理器中有一部分中断是不受操作系统控制的中断,称为一类中断,受操作系统控制的中断称为二类中断。各层的优先级和执行时序如下图所示。        

 由上图可归纳OSEK操作系统的优先级规则如下:

        中断优先级总是高于任务优先级;

        不同的中断和任务可以有一个或多个优先级；

        中断和任务的优先级是静态分配（配置好的）的;

        同一优先级的任务依照 FIFO 原则决定执行次序;

        通过资源调度可实现优先级天花板模式(ceiling priority)，避免优先级反转。

AUTOSAR OS 完全继承了上述特性。

2.3、OSEK任务符合类

        根据不同的软硬件需求,OSEK OS定义了四种符合类(Conformance classes, CC),分别是 BCC1, BCC2, ECC1和ECC2,各种符合类及其属性见下图。

         由上图可知,基本符合类BCC1和BCC2仅支持基本任务,扩展符合类ECC1和ECC2支持基本任务和扩展任务；一类符合类BCC1和ECC1不支持多次任务激活请求，每个优先级只能有一个任务；二类符合类 BCC2 和ECC2支持多次任务激活请求，每个优先级可以有多个任务。各种符合类之间的兼容关系如下图所示。

 OSEK的基本任务与扩展任务

        OSEK 操作系统中有两种任务：基本任务（Basic Task）和扩展任务（Extended Task）。基本任务有三种不同的状态，分别为运行状态（running)、就绪状态（ready)和阻塞状态(suspending)。处于阻塞状态的任务由API函数或报警器(Alarm)激活进入就绪状态,处于就绪状态的任务由调度器决定是否启动进入运行状态，处于运行状态的任务可能被高优先级的任务或中断抢占从而进入就绪状态，任务运行结束后将自己挂起进入阻塞状态。与基本任务相比,扩展任务多了等待状态,当任务的运行需要等待某一或某些事件时进入等待状态(waiting)，当任务所等待的事件被置位时，任务进入就绪状态。基本任务与扩展任务的状态机及其之间的切换如下图所示。

         因为基本任务没有等待状态，所以只能够在任务启动和终结时进行同步，基本任务的优点是占用较少的内存和执行时间。扩展任务的优点是包含多个同步点，没有同步请求的麻烦，当进一步的工作出现信息缺失时，任务切换至等待状态；其缺点是占用较多的内存和执行时间。

2.4、OSEK优先级天花板模式

        若存在Task1, Task2, Task3为全抢占模式下的扩展任务,Taskl和Task3有共享资源,若Taskl在运行时占用了资源Sourcel,Task2和Task3被激活处于就绪状态,调度器根据任务优先级使Task3进入运行状态。由于Task3需要访问的资源Sourcel未被Task1释放,故进入等待状态,而Task2的优先级高于Task1,故Task2抢占Task1进入运行状态,运行结束后将自己挂起，Task 1 继续运行，释放资源后，Task 3 运行。其运行时序如下图所示。

下图为优先级反转示意（优先级task3 >task2 >task1）

        由上图可知,本该先于Task2运行的任务却在Task2之后运行,这种现象被称为优先级反转(Priority inversion)。这种现象与系统设计者的意图相违背，为避免这种现象的出现,OSEK操作系统采用优先级天花板模式(ceiling priority)。即,将访问共享资源的任务的优先级在占用资源的过程中提升至共享资源任务的最高优先级之上,从而避免优先级反转现象的出现，如下图所示。

3、AUTOSAR OS

3.1、 AUTOSAR OS对OSEK OS的继承和扩展

        AUTOSAR OS是在OSEK OS的基础上进行修改和扩展的,是向后兼容的，在OSEKOS上运行的应用程序可以在AUTOSAR OS上运行。

        AUTOSAR从4.0版本开始支持多核OS, AUTOSAR多核OS采用分区机制,多核处理器的每个核中至少有一个OS-Application。任务(Task)、中断服务(ISR)、报警(Alarm)、调度表(Schedule Tables)和计数器(Counters)被统称为操作系统的对象(OS Object)。每一个OSObject 必须从属于一个 OS Application，否则会出现错误。OS-Application 分为 Trusted 和Non-Trusted,Trusted和 Non-Trusted OS-Application 在运行过程中均可以配置相应的监控和保护机制。从属于Non-Trusted OS-Application的OS Object对存储器和API的访问受到限制，通常将一些基础软件层的模块的模式管理主函数映射到 Non-Trusted OSApplication中的任务,如: EcuM_MainFuction (), BswM-MainFuction (), CanMainFuction_Mode()等周期性查询函数，前提是这些模块的安全级别为QM

        AUTOSAR OS 有四类可裁剪类型（OsScalabilityClass)，分别是 SC1—SC4。根据不同的处理器特性,用户可选择不同的可裁剪类型。与OSEK OS相比,SC1具有调度表(Schedule Tables),SC2具有调度表和时间保护(Timing Protection)特性,SC3具有调度表和内存保护(Memory Protection)机制，SC4具有调度表、时间保护和内存保护机制。四者示意图如下图所示。

3.2、AUTOSAR OS的调度表

        调度表被用于安排复杂任务或事件序列,可视为一个单向的轴,通过在轴上设置一个或复多个静态的终点(Expiry Point)来激活任务或事件，每个终点上可设置单个或多个任务或事件,终点之间的时间间隔以Counter的Tick为单位,故每一个调度表对应一个Counter。调度表可设置为以循环或非循环的方式运行。调度表结构如下图所示。

3.3、AUTOSAR OS的时间保护

        如上所述，实时操作系统需要在预定的时间内完成一些任务，但是在某些情况下会出现超时错误，因此，操作系统须采用一定的措施来预防超时错误的产生。这种措施称为时间保护。一个时间保护的方法是时间监控，即:当检测到某一任务运行时间超出其截止时间时,操作系统报错并调用相应的钩子(Hook)函数。AUTOSAR OS并不是采用监控截止时间的方式来进行时间保护的,因为对截止时间的监控并不能识别出引起错误的原因。当任务的执行超过截止时间时,任务本身的执行可能没有出错,而是由于受到其他任务或中断过于频繁的抢占或者过长的阻塞资源的访问而衍生出来的错误。这种情况下,如果采用监控截止时间的方式，则有可能结束正确的任务，而错误的任务仍被允许运行。

        假设所有任务在0时刻就绪,则期望时序如下表和下图所示。由于任务A的优先级最高，故任务 A 先执行，1 个Tick之后任务B 执行，3个Ticks之后任务C执行，当任务C执行 1 个 Tick 后任务 A将其打断，任务A执行完毕后，任务C继续运行，到第 10 个Tick任务C执行完毕,周而复始，整个过程并未出现超时现象,并且有1个Tick的空闲状态。

        下图给出了任务错误运行的状态。任务 A 的第二个周期和任务 B 的第一个周期都出现运行时间过长的现象，但并未超出其截止时间。任务B在第二个周期提前进入运行状态，但也未超出截止时间。任务 C 按照正确的方式运行，但由于任务 A 和 B 的出错导致任务 C运行超时，发生超时错误。采用超时监控机制只能检测到任务C超时，这时，操作系统调用钩子函数，由于出错原因并未被检测到，从而操作系统采取的措施无法有效解决错误。

任务超时图如下：

 在实时操作系统中，任务或中断能否满足其截止时间取决于以下三个因素:

        1、静态任务或中断的执行时间上限；

        2、被低优先级任务锁住共享资源或屏蔽中断所引起的阻塞时间；

        3、任务或中断之间的间隔执行时间。

针对上述三个因素，AUTOSAR OS采取了三种时间保护机制：

        针对1,AUTOSAR OS为任务和二类中断服务设定了运行时间上限;

        针对2,AUTOSAR OS设定了共享资源被任务或二类中断锁定的时间上限,设定了OS中断被任务或二类中断挂起的时间上限，设定了所有中断被任务或二类中断挂起或屏蔽的时间上限；

        针对3, AUTOSAR OS设定了任务或二类中断执行间隔的时间下限。

        当任务或中断服务函数在运行过程中不符合上述要求时，AUTOSAR OS调用相应的钩子（HOOK）函数，作出相应的错误处理。

3.4、AUTOSAR OS的内存保护

        内存保护需要特定的硬件支持,即处理器上应该有MPU(Memory Protection Unit),英飞凌AURIX单片机具备该特性。内存保护可防止某些出错的应用程序影响到其他模块。内存保护分为以下三种形式:

         1、栈保护（Stack Protection）：每一个 OS Application 和其中的 OS Object 都有各自的私有栈，不同的 OS Object之间没有共享栈的存在。栈保护可以更快速地检测出栈上溢和栈下溢，同时，栈保护是划分OS Application的一种方式和依据。

        2、 数据保护(Data Protection)：OS Application 和其中的 Objects 都具有各自的私有数据,OS Application 的私有数据区是从属于该OS Application 的Objects 的共享数据区。

        3、代码保护(Code Protection)：代码区既可以为 OS Application 所私有，也可以被共享。在没有代码保护的情况下，错误的代码执行会导致内存、时间和服务上的出错。

        OS 通过 MPU 监控内存的访问权限，AUTOSAR 中的访问权限分为：受信任 Object 的和非受信任的Object(Trusted and Non Trusted)两级。受信任的Object 有读写大部分内存的权限，但是没有读取其他非激活栈的权限。非受信任的Object 仅有读写少数内存的权限,包括当前活跃的栈、当前OS Application的数据以及LMU中的共享数据。