Autosar OS经典笔记整理：公众号（huihuige092）

**

文章版权归 糖果AUTOSAR 所有，转载请注明来源及作者, 盗版必究！！

扫描或长按二维码可关注公众号

01：AUTOSAR OS分析概述

**

—

AUTOSAR OS 为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，以及错误检测机制。所有服务都隐藏在良好定义的API 之后。应用与OS 和通信层的连接只通过API。

AUTOSAR OS 的基本特征包括：

	静态配置
   能够推断实时系统性能
   提供基于优先级的调度策略
   提供运行时保护功能（存储、计时等）
   可宿主在低端控制器上，并且不需要其他资源

它包含以下几个方面：

·实时操作系统

在嵌入式汽车ECU 中的实时操作系统构成软件动态行为的基础。它管理任务和事件的调度，不同任务间的数据流，并且提供监控和错误处理功能。
但是，在汽车系统中，对操作系统的需求集中在特定领域。所使用的操作系统必须高效运行并且所占存储空间小。
在多媒体和远程信息处理应用中，操作系统提供的特征集以及可用计算资源有很大不同。在纯粹的任务管理之上，OS 中还包含了复杂的数据处理（例如，流、快速文件系统等）、存储管理甚至图形用户接口。
汽车OS 的典型领域涵盖了调度和同步的核心特征。在AUTOSAR 中，上面讨论的附加特征在OS 的范围之外，其他WP4.2.2.1 工作包（例如SPAL）涵盖了这些特征。
在AUTOSAR 的体系结构约束之下不可能把其他OS（如，QNX、VxWorks 和Windows CE 等）的特征集合集成到整体的OS/通信/驱动结构中。因此，AUTOSAR OS只考虑核心特征。

·核心操作系统

OSEK/VDK 操作系统广泛应用于汽车工业，并且已经证明了可以在现代车辆的所有ECU 类型中使用。OSEK OS 引入的概念被广泛地理解，汽车工业领域在设计基于OSEK OS 的系统方面有多年的经验。
OSEK OS 是一个事件触发的操作系统。这为基于AUTOSAR 的系统的设计和维护提供了高度的灵活性。事件触发使得可以自由地选择在运行时驱动调度的事件，例如角反转、局部时间源、全局时间源、错误出现等等。

由于这些原因，AUTOSAR OS 的核心功能必须基于OSEK OS。OSEK OS 特别提供了以下特性以支持AUTOSAR：

固定的基于优先级调度

处理中断的功能

只有中断有高于任务的优先级

一些防止错误使用OS 服务的保护措施

StartOS()和StartupHook 启动接口

ShutdownOS()和ShutdownHook 关闭接口

AUTOSAR OS 基于OSEK OS 意味着应用程序是向后兼容的。为OSEK OS 编写的应用程序可以在AUTOSAR OS 上运行。但是，使用AUTOSAR OS 引入的一些新特性需要对已存在的OSEK OS 特性的使用有所限制。例如：为定时器回调实现定时和内存保护效率就会很低。此外，AUTOSAR OS 扩展了一些已存在的特性，例如直接通过定时器驱动计数器。

AUTOSAR OS 提供的API 向后兼容于OSEK OS 的API。新的需求作为功能扩展来集成。
AUTOSAR OS 对OSEK OS 扩展的API如下表：

·静态定义的调度
在许多应用中需要静态定义一组互相关联的任务的活动。这用于在基于数据流的设计中保证数据一致性，与时间触发的网络同步，保证正确的运行时定相，等等。
时间触发的操作系统通常作为这个问题的解决方法。然而，时间只是简单的事件，所以任何事件触发的OS，包括OSEK OS，会在汽车电子控制单元实现一个用于静态调度实时软件的调度器。

·监控功能
监控功能在适当的执行阶段检测错误，不是在错误发生的时刻。因此，监控功能是在运行时捕捉失效，而不是预防故障。

·保护功能
AUTOSAR 概念需要多来源的OS 应用共存在同一处理器中。为了防止这些OS 应用之间意想不到的交互，需要提供保护机制。

·计时器服务
计时器服务为应用和基础软件提供软件计时器。
计时机制的核心已经由OSEK OS 的计数器和闹钟提供。如果要提供通用的软件计时，一些补充特性需要添加到AUTOSAR OS。

·时间触发操作系统
时间触发操作系统在汽车电子控制单元实现了一个用于静态调度实时软件的调度器。
另外，操作系统为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，以及错误检测机制。
所有服务都隐藏在良好定义的API 之后。应用与OS 和通信层的连接只通过API。
对于特殊的应用，操作系统能够配置为只包含该应用需要的服务。因此操作系统的资源需求尽量少。

**

02：OS-Protection

**

—
1.OS-Protection

1.1 Protection的作用对象

受析的受保护对象是OS objects.因此有相应的约束。

具体的Constrains有以下两种：

►不适用一类中断的运行时保护。

►不适用于同一task或二类中断中的函数调用的运行时保护。

1.2 Protection保护类别

1.2.1. Memory Protection

►内存保护需要硬件单元MPU的支持。

►保护的对象：可执行程序的[代码][数据][堆栈] 。

（1） 代码：代码的执行域可以被一个OS分区所独占，或者是被所用分区共享使用。若果有异常的代码执行，则会有进入相应的内存保护hook，或者是相应时间保护hook。

（2） 数据：数据的作用域可以是OSApplication级别的，也可以是Task级别的。注意OS Application级别的可以被其他的OS object所共享。

（3） 堆栈：Autosar中，堆栈为task或中断所私有。堆栈量的大小可配置。如有堆栈溢出则会触发相应的memoryprotection hook 。

**

**03：OS-Protection ：Timing Protection **

**

—

对任务和二类中断进行Deadline的监控，如果超时则会产生时间保护错。

AutosarOS不提供基于时间保护的Deadline监控机制。注意被监控的TASK_UnderMonitor可能由于其他的Task或ISR执行时间太长而超过限定的Deadline，这种情况下此task的运行时时间超时只能表征系统的时间错误。

如出现错误的时候，则会EB中的实现是调用相应的hook函数。

Figure 1.1. Task Execution Time Control

下面举一个Autosar中例子：

TASK_A_High： TASK_A_Runtime =1tick，TASK_A_Period=5tick，TASK_A_Deadline=5 tick

TASK_B_Medium： TASK_B_Runtime =3tick，TASK_B_Period=10tick，TASK_A_Deadline=10 tick

TASK_C_Low:TASK_C_Runtime =5tick，TASK_C_Period=15tick，TASK_C_Deadline=15 tick

假设上述三个Task是可抢占属性的,在0tick时被激活成准备状态。

下图是A,B,C正常的一个执行顺序：

Figure 1.2. Correct execution order

下图是一种异常情况，A和B的执行时间超了一个tick（红色部分），并且B又早到了2个tick，由于错误的传播，尽管C的执行时间符合规定，但是C的监控实体会发现Deadline错误。

Figure 1.3. Wrong execution order

造成上述失效模式的hazard有哪些呢？主要有三种，

（1） Task/ISRs的执行时间太长

（2） Task锁定资源或禁止中断时间太长

（3） Task/ISRs的调度太频繁

针对这三种hazard有什么安全机制呢？

针对(1),AUTOSAROS提出了Task/ISRs执行开销的上限值Execution Budget，这在EB中是可配置的。

Figure 1.4 Execution Budget

针对(2),AUTOSAROS提供了锁定时间保护的上限值LockBudget，这在EB中是可配置的。

Figure 1.5 Lock Budget

针对(3),AUTOSAROS提供了到达率保护的下限值Time Frame，这在EB中是可配置的。

Figure 1.6 Time Frame

注意：对于queue的Task 状态，不影响器激活次数的统计，对于事件型的task，多个事件的发生只记录为一次激活。

下图直观地展示了状态转移和上述机制的一个交互关系：

​Figure 1.6 Time protection interaction

注意点：

（1）对二类中断的到达率监控可以避免Can总线babbling idiot（参见论文：处理CAN总线Babbling Idiot失效的方法）但不适用于一类中断。

（2）对于可信的OS-Applications的运行时间参数都必须正确，时间保护可用于监控非可信的OS-Applications的运行时间如有不争取，则结束相应的OS-Applications。

**

04：OS-Application

**

—

​1. OS-Application

1.1 设计OS Partiotion分区的意义

►AutosarOS 需要一个容器，用来收集OS对象。这个容器集合称之为OS 分区。OS对象包含中断，任务，警报，调度表，计数器等。具体参见EB工具中的对应标签：

Figure1.1. Configuring parameters of the OS container

内核负责协调调度各个OS应用分区去访问或占有Cpu资源。属于同一分区的各个对象可以互访问。但是不同分区之间的元素访问是需要配置才能允许的。注意如果一个task对于一个OS 分区是可访问的，则和这个task绑定的事件也具有对这个OS 分区的可访问属性。并且注意资源本身不属于任何一个分区，但是要配置哪些OS分区拥有对这个资源的访问权限。这属于功能安全的范畴。具体可咨询，我会发一张图给你们去理解。

1.2 OS Partiotion分区

►分区可分为以下两类：

（1）可信的。

（2）非可信的。

具体的区别可属性可参见下图：

Figure1.2. Classesof OS-Applications

做功能安全的都熟悉这个词[Assumption] ,我们假设Autosar OS内核都是可信的，这是实现复杂调度和访问内存保护单元MPU的前提。

不同OS 分区的访问服务可通过带有特定标签的函数签名实现分区之间的函数调用。也就是TrustedOS-Applications may offer services (“trusted services”) to other (evennon-trusted) OS-Applications.

Figure 1 .3 Configuration Of Trusted Function

关于OS application集合的见下图：

Figure 1 .4 UML-model of OS-Application

OS-Application间有个状态迁移图，实现状态的转移，其中OS-Application的状态（可访问的属性）有以下三种：

（1） APPLICATION_ACCESSIBLE

（2） APPLICATION_RESTART（EB和Davinci中不支持这种装填）

（3） APPLICATION_TERMINATED

Figure 1.5 States of OS-Application

**

05：Auotsar OS-中断和异常

**

—

​中断和异常

-中断

在EB中可以将具有给定中断级别和排队优先级的所有ISR分配给单个线程

当使用EB的Os时，中断应由此Os处理，因此Mcal_EnableALlInterrupts和Mcal_DisableALlInterrupts函数被重定向到Os的EnableAllInterrupts和DisableALlInterrupts函数。

在AUTOSAR OS 规范中定义了一类中断和二类中断。EB中的中断Level的优先级顺序如下图1：

图1 中断LEVEL的优先级

而在Microsar OS中，则扩展了中断的类型，见下图2的中断优先级排序：

图2 中断LEVEL的优先级

其中，类别0 ISR，具有最小的中断延迟时间，尤其是在SC2或SC4系统中。 这是OS标准的扩展。例如在OS内核切换任务堆栈时使用类别0 ISR。

那么类别1中断和类别2中断的区别是什么？

类别1：内部不允许OS API的调用，不支持中断的嵌套，但是支持内联汇编的方式实现嵌套。

类别2: 允许OS API的调用，支持中断的嵌套。

-异常

在SC3和SC4系统中，MICROSAR OS为内存保护错误和SYSCALL / TRAP指令定义OS异常处理程序，应用程序无法配置操作系统使用的异常源。即配置工具中不支持配置异常源和相应的属性。

自未分配的异常源的异常请求由OS处理，并通过调用PanicHook（）或ProtectionHook去分析或处理这些异常。

**

**06：Autosar OS（3）-Stack **

**

—
-堆栈概念：

每个OS对象（OS对象是由OS管理的数据结构。包括任务代码，ISR和异常处理程序）都有自己的堆栈内存区域和私有数据的内存区域（简称上下文）。

堆栈是上下文中的一部分。例如：EB中使用链接的CSA区域而不是堆栈实现函数的调用和返回操作。

其中任务的上下文包括：

►执行的线程，即任务的程序计数器

►CPU寄存器的保存（必须为每个EXTENDED任务分配一个单独的寄存器存储区，因为在任务处于WAITING状态时，将保留寄存器的值（如堆栈）。 对于BASIC任务和ISR，每个线程需要一个寄存器存储）

►用于动态变量和函数调用的堆栈

►内核控制结构

如果任务需要在LIFO（后进先出）顺序中获取和释放多个资源，所需的资源的管理也需要相应的任务堆栈。

MICROSAR OS实现了特定的堆栈概念。它定义了堆栈使用者可以使用的不同堆栈（运行时上下文）。而并非所有消费者都可以使用所有堆栈。具体见下表1

-共享堆栈的功能：

此处的介绍省略。如需使用，请联系。

-堆栈检查的功能：

–软件堆栈检查方法：

软件堆栈检查方法可用于检查堆栈是否发生上溢或下溢。为此，堆栈在启动时填充了已知值（通常为0xEE或0xEB）。有一个API允许系统通过计算尚未覆盖的字节数并仍包含标记代码来调查堆栈使用情况。

例如在EB中，通过以下的属性去使能此项检查。

–MPU硬件支持下的堆栈检查方法：

在OS的整个运行期间，当前有效堆栈由微控制器的MPU监控。因此，OS保留一个MPU区域，在任务/堆栈切换的时候该区域由内核重新编程。由于MPU避免超出堆栈边界的写访问，因此不会发生堆栈溢出。每当识别出存储器违规时（例如由于堆栈违规），就会引发异常。在异常处理中，OS调用ProtectionHook（）。应用程序决定在ProtectionHook（）中如何处理内存保护违规。如果应用程序调用OS的关闭，则也会调用ShutdownHook（）（如果已配置）。

一般堆栈会保留一个安全间隙，并且在链接脚本中进行链接以检测最低地址的堆栈的堆栈冲突。（假设堆栈的成长方向是高地质向低地址），详细见图1。

图1 OS堆栈及安全间隙

**

**07：Autosar OS 介绍 **

**

—
什么是Autosar OS？

1.Autosar OS是与OSEK兼容的操作系统，但是具有多个扩展性能。例如可扩展功能：调度表，OS applications，内存保护（如果处理器支持）和时序保护。

具体的OS的可扩展级别如下表所示：

2. 经典的Autosar OS是一个静态可配置及时间触发的实时操作系统操作系Adaptive Autosar OS适用于多核动态操作系统,如QNX(QNX是一个分布式、可扩展、遵从POSIX规范的类Unix硬实时操作系统),具体可参见下图1
   

图1 经典autosar与自适应Autosar的区别

3.Autosar OS是提供基于优先级的调度策略，具有可抢占的属性，具有同步的机制，通过事件和资源的属性去实现

4.AutosarOS是提供以下对象进行多任务并发执行的管理。如Task，Alarm，Event， Interrupts, Resource，Os kernel(对用户不可见)

**

08：Autosar OS 介绍 2

**

—
Autosar OS 和常见的OS(linux系统OS)具有以下的区别或限制。

在运行时不会动态创建新任务;

必须在编译之前定义所有任务（属于预编译配置变体）。

操作系统没有动态内存管理，也没有用于手动控制任务的shell。



弄明白了Autosar OS是什么和限制属性后，那么Autosar OS的代码结构是什么样的呢？

通常，操作系统的源文件（以plugin的形式呈现）和配置生成文件以及应用程序源文件被编译并链接到一个可执行文件（格式可以为ELF，Mot，hex），该文件被加载到仿真器中或烧录到ROM中。

其中头文件的结构见下图：

图1 OS模块头文件的结构

---

​！！！​​​​​​​​​​​​​​**
收集材料并写下，花费了漫长时间；拒绝白嫖，烦请您关注我和点击下在看，感谢你的分享和支持。扫描加群并分享你的在看截图给我，我会分享超过10G的自动驾驶和AUTOSAR资料给您!
资料截图如下：
##
文章版权归糖果AUTOSAR所有，转载请注明来源及作者, 盗版必究！！

扫描或长按二维码可关注公众号

---

******************************************************************/