AUTOSAR OS 操作系统详解（上）

点击订阅专栏不迷路

>>>>>>>>>>返回专栏总目录《AUTOSAR从入门到精通专栏》 <<<<<<<<<<

关注文章末尾公众号或微信中搜索“AUTOSAR解忧杂货铺”，后台发送“资料”领取汽车电子入门资料，发送“加群”加入汽车电子交流群

一、OS概述

在嵌入式系统开发领域，传统裸机编程(Bare-metal Programming)通过直接操作硬件寄存器实现功能控制，适用于需求单一、资源受限的简单场景（如基础车身控制模块）。但随着汽车电子系统复杂度呈指数级增长（如L3级自动驾驶需处理多传感器融合与决策算法），传统开发模式面临严峻挑战：代码模块化缺失导致功能迭代时牵一发而动全身，维护成本随代码量增加呈几何级数上升；基于轮询或计数器的任务调度机制难以应对多核架构下的并发控制，尤其在涉及μs级实时响应（如ESP系统）、资源共享冲突（如多核访问共享内存）及安全关键任务隔离（如ASIL-D级制动控制）时，传统方法的时序确定性与故障恢复能力无法满足ISO 26262功能安全标准。

实时操作系统（RTOS）的引入为复杂系统开发提供了系统性解决方案：通过硬件抽象层（HAL）封装底层细节，提供抢占式调度、优先级管理、内存保护等核心机制。例如，OSEK OS的静态任务配置表确保调度行为可预测，AUTOSAR OS的SC4等级支持时间监控与内存隔离。这些机制使开发者聚焦于业务逻辑实现，同时通过标准化接口（如OSEK的StartOS/ShutdownOS）提升跨平台兼容性。在智能座舱域控制器中，RTOS可同时管理信息娱乐、语音交互、AR-HUD渲染等数十个任务，通过优先级仲裁与资源同步保证关键功能的实时响应，开发效率较裸机编程提升40%以上。

其中调度功能则是OS的核心组件，主要功能就是负责任务的切换。在一个单核系统中，多任务只能并发执行，通过时间片轮转法来切换任务，通过时钟中断或者软中断的方式来触发一次任务的切换，从而打断当前执行任务，调度器抢夺CPU控制器，来进行任务调度并切换至新任务开始执行，如下图所示

二、OSEK OS概述

OSEK OS（全称Open Systems and the corresponding interfaces for automotive Electronics Operating System）是一种专为汽车电子控制单元（ECU）设计的实时操作系统标准，由德国汽车工业于1993年提出，后与VDX（Vehicle Distributed eXecutive）合并形成OSEK/VDX规范。其核心目标是为车辆嵌入式系统提供轻量级、高确定性的运行环境，支持静态配置的任务、资源和中断管理，所有系统对象（如任务优先级、堆栈大小）均在编译时固定，杜绝动态创建以降低运行时开销。

三、AUTOSAR OS概述

AUTOSAR OS是一种基于AUTOSAR标准的嵌入式操作系统，它在OSEK OS的基础上进行了扩展和改进。AUTOSAR OS继承了OSEK OS的核心特性，如任务管理、同步服务、中断处理和报警机制等，同时增加了对多核处理器和多任务的支持，以满足现代汽车电子系统对高性能和复杂功能的需求。AUTOSAR OS提供了更强大的功能和更高的灵活性，使其成为汽车电子系统开发中的重要工具。

四、AUTOSAR OS和OSEK OS功能区别

AUTOSAR OS 作为 OSEK OS 的演进版本，在架构扩展性、安全防护、动态配置和多核支持四个维度实现技术突破，具体对比如下：

对比维度	OSEK OS	AUTOSAR OS	技术演进价值
架构基础	单核实时操作系统（RTAOS）	支持多核/分布式架构的模块化操作系统	适应域控制器与中央计算单元的硬件升级需求
任务调度	固定优先级抢占式调度	混合调度（静态调度表+动态抢占）	兼顾时间触发任务的确定性（如动力总成控制）与事件驱动任务的实时性（如紧急制动）
安全等级	无显式安全等级划分	SC1-SC4分级安全保护（ISO 26262兼容）	通过内存保护（SC3/SC4）和时间监控（SC2/SC4）实现ASIL-D级安全隔离
内存管理	无内存保护机制	支持MMU/MPU硬件内存隔离（SC3/SC4）	防止任务间非法内存访问，满足安全关键系统需求
动态配置	完全静态配置（编译前预定义）	支持运行时动态配置（如任务创建/删除）	适应OTA升级和功能迭代的灵活性需求
多核支持	单核架构	对称多处理（SMP）与非对称多处理（AMP）	优化多核SoC资源利用率，支持分布式系统协同
开发模式	硬件强绑定（需适配特定MCU）	硬件抽象层（HAL）与软件组件解耦	降低跨平台移植成本，支持标准化软件组件（SW-C）复用
错误处理	基础错误钩子函数	增强错误处理机制（如安全状态切换）	符合功能安全标准的故障检测与恢复策略

五、AUTOSAR OS基本概念

接下来，我们对AutoSar OS中的部分概念有一个基本认识。AUTOSAR OS的核心架构定义了六类基础对象：

基本对象	功能含义
Counter	用于作为Alarm或者Schedule Table的触发基准
Alarm	用于定时触发某个Task或者某个Event
Schedule Table	用于定时同步触发多个Task或者多个Event
Task	AUTOSAR OS调度的基本功能单元
ISRs	内外部中断（主要包含Category I与Category II）
Resouce	资源管理

这些对象必须从属于一个OS Application（操作系统应用单元），其本质是上述对象的逻辑容器，用于实现功能隔离与访问控制。同一OS Application内的基础对象默认具备直接交互权限（如任务与资源的绑定、报警器触发计数器等），而跨OS Application的对象访问则需通过显式配置策略（如共享资源权限声明或接口暴露）实现受控协作，以此保障系统的模块化设计与安全性。

这些基本对象，OS Application，Core这三者存在着一定的关系，为了更好的理解它们之间彼此的关系，如下图就较为清晰地描述了者三者之间的关系。

在上图中所示，每个处理器核心（Core）可以包含1到多个操作系统应用（OS Application），而每个OS Application可以包含0到多个基本对象。每个基本对象必须归属于某个OS Application，否则将导致错误。此外，OS Application分为可信（Trusted）和不可信（Not Trusted）两种类型。

在运行过程中，可以为可信和不可信的OS Application配置相应的监控和保护机制。属于不可信OS Application的基本对象在访问存储器和API时会受到限制。通常情况下，会将一些基础软件的模式管理主函数映射到不可信OS Application中的任务，例如EcuM_Mainfunction、BswM_Mainfunction和Can_Mainfunction_Mode等周期性状态查询函数，但前提是这些软件模块的安全级别为QM（Quality Management）。

将针对这6大基本对象分别展开讲述各个对象的基本特点与用途：

5.1 Task（任务）

AUTOSAR OS中存在基本任务(Basic Task)和扩展任务（Extended Task）两种任务。

• 基本任务则存在以下三种状态：

  • 运行状态(Running)：处于运行状态的任务可能被高优先级任务或者中断抢占从而进入就绪状态，且同一Core中任何时刻只会存在一个任务处于运行状态，任务运行结束后则将自己挂起进入阻塞状态；
  • 就绪状态(Ready): 处于就绪状态的任务由调度器决定是否启动进入运行状态，且该状态时任务切换至运行状态的前提；
  • 阻塞状态(Suspend): 处于阻塞状态的任务是被动的，可以由API函数或Alarm激活进入就绪状态；

• 扩展任务与之相比，则多了一个状态：

  • 等待状态(Waiting)： 当任务的运行需要等待某一或某些事件被置位时，任务进入就绪状态。

如下图所示，为基本任务与扩展任务间的转化关系图：

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

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

5.2Counter（计数器）

Counter概念的引入是为了实现对硬件计数器以及软件计数器的管理，为Alarm与Schedule table提供支持。即多个Alarm可以共用一个Counter，一个Schedule Table只能由一个Counter来驱动。 Counter按照AUTOSAR定义可分为以下两种：

• Hardware Counter: 该Counter的增加由硬件外设驱动，如Gpt或者timer等；
• Software Counter： 该Counter的增加通过调用API函数IncrementCounter来实现，且每次只能增加1；

基本原则： 优先使用Hardware Counter，因为可以根据Task的激活状况来减少无意义的时钟中断。Counter、Alarm和Schedule table三者间关系如下图所示

5.3 Alarm（闹钟）

计数器（Counter）是闹钟机制（Alarm）的基础。多个闹钟可以连接到一个计数器。当计数器达到闹钟设定的值时，可以激活一个任务、设定一个事件、调用回调函数（callback）或增加计数器等功能，但这些操作只能是一对一的。

• 一对一关系：每个Alarm只能连接到一个Counter，并且在触发时只能激活一个任务、设定一个事件、调用一个回调函数或增加一个计数器。
• 灵活性：Alarm机制非常灵活，可以用于各种定时任务的触发，但它的限制在于每次只能触发一个操作。

虽然Alarm机制可以用于任务的定时触发，但它的限制在于每次只能触发一个操作。而Schedule Table的引入正是为了解决这一问题。通过Schedule Table，可以在一个时间点上同时触发多个任务或多个事件，从而提高了任务调度的效率和灵活性。

5.4 Schedule Table（调度表）

当计数器的计数值依次达到各个Alarm设定的计数值时，各个Alarm被触发，但很难保证各个Alarm有特定的时间间隔，且每个Alarm只能激活一个Task或者Event，所以需要多个Alarm来协作实现在同一时刻触发多个Task或者Event，因此引入Schedule Table机制。
Schedule Table会定义一系列终结点(Expiry Point)，且每个调度表都有一个以Tick为单位的持续时间(Duration)。每个终结点则是以Tick为单位的距离起始点的偏移量(Offset)，在每个终结点可以实现多个Task或者Event的设置。与闹钟机制类似，一个调度表只能由一个Counter驱动，同时调度表存在以下两种调度方式：

• 单次执行(Single-Shot): 调度表启动之后 只运行一次，到达调度表终点则终止，即每个终结点只运行一次；
• 循环执行(Repeating): 调度表启动后可反复执行，到达调度表终点后重头开始执行，则每个终结点会被周期性的执行，一般情况下激活任务采用此模式。

Tip📌

1. 每一个终结点必须配置至少一个Task或者Event；
2. 每一个调度表至少存在一个终结点(Expiry Point)；
3. 在每一个Expiry Point优先激活Task，随后设置Event；

5.5 ISRs（中断服务程序）

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

• Category I：此类中断服务程序不能够使用OS提供的系统服务，当中断执行完成之后则会重新跳转至产生中断的地方继续执行，不会影响到任务的执行，因此占用系统资源较少。
• Category II：该类中断则可以调用OS系统服务，如激活任务或者设置事件等。
  在AUTOSAR OS中，中断的优先级始终高于任务的优先级，即最低优先级的中断都可以打断最高优先级的任务，即使该任务不可抢占也不例外。 因此，中断服务子程序的执行时间不宜过长，否则会影响到整个系统的实时性。

5.6 Resource Management（资源管理）

Resouce作为OS调度过程中一个十分重要的对象，Resource管理就显得尤为重要。资源管理就是为了协调具有不同优先级的多个任务或者中断对共享内存（如内存或者硬件等）的并发访问。

为了更好的理解OS并消化，本篇介绍到此结束，在AUTOSAR OS详解（下）中我们将进一步介绍OS中的相关操作，敬请期待。