Autosar-OS软件概述和配置

诊断协议那些事儿

已于 2023-09-18 19:26:45 修改

阅读量2.7k

点赞数 2

分类专栏： Autosar-CP 文章标签：车载系统架构经验分享

于 2023-07-21 22:50:33 首次发布

本文链接：https://blog.csdn.net/qq_41908302/article/details/131840544

版权

Autosar-CP 专栏收录该内容

46 篇文章 23 订阅 ¥199.90 ¥99.00

订阅专栏

Autosar OS目录

一、为什么需要OS
二、Autosar OS
- Autosar OS可裁剪类型
三、OS配置
- OS Application

一、为什么需要OS

为什么汽车电子ECU需要使用OS(Operation System)呢，它的必要性在哪里？

随着车载系统需求越来越复杂化，需要用到模块化设计方法以及多任务编程思想，为此减少后期软件升级维护成本。采用传统的计数器与状态机来实现简单多个任务的调度，无法满足多个任务之间的状态切换，优先级，现场保护，执行时间控制等各个方面。

此时迫切需要一种机制来替我们完成各个任务之间的调度功能，使得开发人员能够更关注于应用软件的开发，提高软件开发效率，为此OS便应运而生！

OS的功能

①改变各任务的执行频率；
②改变各任务的执行时间；
③设定各任务的优先级，保证高优先级任务能够及时执行；
④任务调度、切换时的现场保护与恢复；
⑤共享资源的安全访问机制等；
调度器

在一个单核系统中，多任务只能并发执行，通过时间片轮转法来切换任务，通过时钟中断或者软中断的方式来触发一次任务的切换，从而打断当前执行任务，调度器抢夺CPU控制器，来进行任务调度并切换至新任务开始执行。

实时操作系统

实时操作系统（RTOS-Real Time Operating System）中实时（Real Time）指的是任务（Task）或者说实现一个功能的线程（Thread）必须在给定的时间(Deadline)内完成。

系统可以大致分为四个部分：硬件（Hardware），操作系统（operating system），应用程序（application programs），使用者（user）。

目前比较流行的实时操作系统包括Linux，黑莓QNX，RTOS（例如uCOS FreeRTOS,以及一些商用的认证SafeRTOS等），AUTOSAR OS(基于OSEK/VDX OS)，RT-Thread，华为的鸿蒙等
提示：FreeRTOS的官网地址：https://www.freertos.org/

OSEK OS

OSEK是德文“Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug”的缩写，译为汽车电子开放系统及接口。OSEK OS是一个为满足汽车电子可靠性、实时性、成本敏感性等需求而打造的实时单核操作系统(RTAOS)。

类别	OSEK OS
基本特性	①操作系统中任务、资源、服务静态配置；②支持在只读存储器上运行；③应用中的任务具备较好的可移植性；④操作系统所定义的动作可预见且可记录
基本服务	①任务管理：包括任务激活与终止以及任务的切换；②同步服务：主要通过资源调度和事件控制来实现；③中断服务程序：包括Catogory I与Category II两类中断；④Alarm机制：主要包括相对Alarm与绝对Alarm；⑤ 进程通信：主要用于进程间数据交互；⑥错误处理：支持各类错误的处理

osek已经被iso标准化，ISO17356，有兴趣的可以私聊小编获取。

二、Autosar OS

AUTOSAR OS是基于OSEK OS继承发展而来，所以上述的OSEK OS的基本特点在AUTOSAR OS都能够得到满足，所以AUTOSAR OS是向后兼容的，也就意味着在OSEK OS上能够运行的应用程序同样也可以在AUTOSAR OS上运行。
AUTOSAR OS继承OSEK OS，在OSEK OS的基础上又特别明确了一些AUTOSAR OS需要提供的系统服务：

基于优先级的调度
中断优先级必定高于task；
通过StartOS（）与StartOSHook（）来创建启动接口；
通过ShutdownOS() 与ShutdownOSHook来创建关闭接口；

Autosar OS是用于车载MCU的实时操作系统，在整个Autosar架构中属于BSW层的System Services中的一个组件。其上至RTE、下至驱动，中间与BSW基础模块进行交互，是整个autosar框架下最重要的组成部分。

标准地址: https://www.autosar.org/standards/

虽然说OS 是整个框架的灵魂，但是也有极少数的BSW 模块不与OS 直接交互。换句话说，其他BSW 模块在改动的时候，是需要考虑一下OS 对其的影响，和它对OS 的影响。
BSW-OS

Autosar OS可裁剪类型

AUTOSAR组织根据是否支持时间保护和内存保护为不同的用户提供四类不同功能安全的OS可裁剪类型，分别为SC1-SC4。

SC1: OSEK OS + Schedule Table；
SC2: OSEK OS + Schedule Table + Timing Protection;
SC3: OSEK OS + Schedule Table + Memory Protection;
SC4: OSEK OS + Schedule Table + Timing Protection + Memory Protection；

Timing Protection：用于监控任务或者中断是否超时（超过规定的时间deadline）

Memory Protection：用于防止不同的OS application异常访问其他不允许的程序段或数据段

三、OS配置

Os主要包括以下内容
①单Core/多核
②Os应用（任务，中断等object的集合）
③任务管理
④中断管理
⑤定时器
⑥调度表
⑦资源
⑧Memory/Timing Protection
⑨Stack

OS Application

OS Application是程序应用的单元，每个OS Application包含如下内容：
①Task Management（任务管理）
②ISR Management（中断管理）
③Scheduler（调度表）
④Resource Management（资源管理）
⑤Counter and Alarms（时基和警报器）
⑥Hook Rountines（Hook程序）

APP

Counters

Counters是OSEK OS中一个组件，在软件中可以理解为Ticks
counter

Counter Type: 采用硬件时钟并关联到硬件Timer
Counter Tick Per Base: 每100个硬件Timer Counter触发OS Counter 累加
Seconds Per Tick: 1us, 为了增加OS调度速度，精度不宜过小

Alarms

Alarm（警报器）是由Counter驱动的，多个Alarm可以连接到同一个counter
Counter每次累加都会触发相关联Alarm的检查，如果满足触发条件，Alarm会被触发
Alarm
Alarm报警，主要实现的是定时功能，在预定时间到达时候触发相关操作，例如：触发一次事件（Set Event），激活任务（BCC task），进行回调等操作
回调函数是在IncrementCountrer()的上下文中执行的，而IncrementCounter一般是在与硬件计数器关联的计数器的中断函数中执行，所以中断执行函数不会知道回调的堆栈使用情况。在实际项目中我们要避免在回调中做大量的计算和函数调用，而只是设置全局变量等一些简单的事情

Alarm的类型：

Relative（相对时间Alarm）：对比当前时基又过了Tick数量后触发
Absolute（绝对时间Alarm）：当counter到达固定数值后触发，或者周期固定间隔触发

setrelative

FUNC(Std_ReturnType, RTE_CODE) Rte_Start(void)
{
    /* activate the alarms used for TimingEvents */
    (void)SetRelAlarm(Rte_Al_TE_Test_SWC_Test_ECCTaskRunnable, RTE_SEC_OsCounter_Core0(0) + (TickType)1, RTE_SEC_OsCounter_Core0(1));
    return RTE_E_OK;
}

Task Management

OS的task分为两种：基础任务(BCC task)和扩展任务（Extended Task）。主要区别在于有无waiting状态：
task
运行状态(Running)：处于运行状态的任务可能被高优先级任务或者中断抢占从而进入就绪状态，且同一Core中任何时刻只会存在一个任务处于运行状态，任务运行结束后则将自己挂起进入阻塞状态；
就绪状态(Ready): 处于就绪状态的任务由调度器决定是否启动进入运行状态，且该状态时任务切换至运行状态的前提；
阻塞状态(Suspend): 处于阻塞状态的任务是被动的，可以由API函数或Alarm激活进入就绪状态；
等待状态(Waiting)：当任务的运行需要等待某一或某些事件被置位时，任务进入就绪状态。

基础任务每次启动都会从程序开始执行到程序结束，没有等待状态，会在如下情况下停止运行
• 任务结束
• 被高优先级任务抢占
• 被中断抢占（中断优先级高于任务）
bcc

Task Activation:同时只允许一次任务激活
Priority：任务优先级（值越大优先级越高），高优先级任务可以抢占低优先级任务（如果低优先级任务配置成支持抢占类型）
Schedule：NON-不支持抢占；FULL-可以被任何高优先级类型抢占
Stack Size：1K（根据当前任务所需要stack进行设置，如果Stack产生overflow，os会在任务切换时报错挂死，进入error hook或者是protection hook）
Type：Basic Task

TASK(Core0_App_100ms) /* PRQA S 3408, 1503 */
{
    /* call runnable */
    Test_SWC_Runnable(); /*任务挂在Alarm上, Alarm激活后Task会执行到任务结束，中间不会进入Wait 状态*/
    (void)TerminateTask(); /* PRQA S 3417 */
}

• Event用于扩展类型任务的触发执行（从Waiting状态到Run状态）
• 每个扩展类型任务可以关联多个事件
• 任何任务或者中断程序都可以激活事件
• 只有关联事件的任务可以等待和清除相关联事件
Event
会在如下情况下停止运行
• 任务结束
• 被高优先级任务抢占
• 被中断抢占（中断优先级高于任务）
• 自主挂起进入Waiting状态
extended

Task Activation: 同时只允许一次任务激活
Priority: 任务优先级, 高优先级任务可以抢占低优先级任务（如果低优先级任务配置成支持抢占类型）
Schedule: NON-不支持抢占；FULL-可以被任何高优先级类型抢占
Stack Size: 1K （根据当前任务所需要Stack进行设置，如果Stack产生Overflow, OS会再任务切换时报错挂死）
Type: Extended

TASK(Core1_Bsw_5ms) /* PRQA S 3408, 1503 */
{
    EventMaskType ev;
    for(;;) /* 无结束任务调用 */
    {
        (void)WaitEvent(Rte_Ev_Run_Test_core1_SWC_Test_Core1_SWC_Runnable); /* 任务进入Waiting状态并等待事件 */
        (void)GetEvent(Core1_Bsw_5ms, &ev); /* 事件触发，任务恢复执行 （事件由Alarm触发） */
        (void)ClearEvent(ev & Rte_Ev_Run_Test_core1_SWC_Test_Core1_SWC_Runnable);
        if ((ev & Rte_Ev_Run_Test_core1_SWC_Test_Core1_SWC_Runnable) != (EventMaskType)0) /* 事件为runnable执行所等待事件*/
        {
            Test_Core1_SWC_Runnable(); /* 执行runnable */
        }
    }
}

AUTOSAR OS是基于优先级进行task 调度，所以每个任务必定有一个优先级，而每个任务都是根据其自身特点来定义一个优先级且需要配置其可抢占属性。可抢占属性可分为不可抢占与全抢占，调度策略可分为以下两种：
非抢占式：OS中所有任务均是不可抢占的；
完全抢占式：OS所有任务均是可抢占类型；

假定TaskA为扩展任务，TaskB与TaskC为基本任务，优先级TaskA > TaskB > TaskC。
①若采用非抢占式调度策略，那么当前运行状态的任务在任何时刻都不会其他高优先级任务所抢占，任务的切换只会发生在任务完时。非抢占式调度策略的问题在于任务执行时间不确定，系统调度实时性较差。如下图所示为非抢占式调度策略，可见即使高优先级任务 TaskB被激活切换至就绪状态，也必须等到TaskC执行结束之后才能够被调度。

②对于完全抢占式任务调度策略而言，当前运行的任务可在任何时刻被高优先级任务打断而被迫释放处理器控制权，具备最高优先级的任务从就绪状态转入运行状态，而当前任务被抢占从而进入就绪状态，同时保留现场环境，带下次运行时恢复。
完全抢占式调度
Case1：当前TaskC处于运行状态，当激活TaskB进入到就绪状态时，由于TaskB优先级高于TaskC，所以TaskC被迫释放处理器控制权，调度器开始调度TaskB从就绪状态变为运行状态，直到TaskB运行完成之后，在调度TaskC继续运行。

Case2：当前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，也就意味着在重要代码执行之前，应采用资源保护机制，以免被高优先级的任务打断。

多个任务共享的资源（数据和外设等），需要防止task1再读取共享数据的时候被task2改写。
临界区保护（Exclusive Area Handling）：
①开关中断
②Get/Release Resource
③Get/Release SpinLock

Resource Management

Resouce作为OS调度过程中一个十分重要的对象，资源管理就是为了协调具有不同优先级的多个任务或者中断对共享内存（如内存或者硬件等）的并发访问。
AUTOSAR OS采用上述的优先级天花板模式来避免任务优先级反转以及死锁问题的发生，即资源的上限优先级必须高于所有该资源的任务以及中断的优先级，但是应低于不访问该资源的任务的最低优先级。
其中为了保护共享资源而提出的锁机制-自旋锁(Spin Lock)。该自旋锁一般用于多核操作系统解决资源互斥的问题。当内核控制必须访问共享数据结构或进入临界区时，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了该锁，从而达到某共享资源的互斥作用。

ISRs

ISRs
在AUTOSAR中定义了两类中断服务程序(Interrupt Service Routine)。分别为一类中断(Category I)与二类中断(Category),两者之间的区别定义如下：
Categoty I：此类中断服务程序不能够使用OS提供的系统服务，当中断执行完成之后则会重新跳转至产生中断的地方继续执行，不会影响到任务的执行，因此占用系统资源较少。

Category II：该类中断则可以调用OS系统服务，如激活任务或者设置事件等，受OS控制。
如下述代码所示，中断向量表不直接指定中断服务程序，而是指向Os_Hal_IsrRun 程序由OS接管中断服务程序。
二类中断
在AUTOSAR OS中，中断的优先级始终高于任务的优先级，即最低优先级的中断都可以打断最高优先级的任务，即使该任务配置不可抢占也会被中断抢占。因此，中断服务子程序的执行时间不宜过长，否则会影响到整个系统的实时性。

ScheduleTables

调度表（ScheduleTables) 通过提供一组静态定义的到期点（expiry points）的封装来解决同步问题。每个到期点定义：
处理时必须发生的一个或多个动作，其中动作是任务（Task）的激活或事件（event）的设置。
从调度表（ScheduleTable）开始点一个以滴答（Tick）为单位的偏移量(Offset)。

每个调度表都有一个持续时间(Duration)，即调度表的一次运行时间，度量单位为计数器的计数单位 Tick。

Hook 函数和错误处理

Hook函数	功能描述
StartupHook	在StartOS之后，第一个任务启动之前触发
ShutdownHook	ShutdownOS函数被调用后触发
PretaskHook	任务启动前触发
PosttaskHook	任务结束时触发
ErrorHook	系统故障时触发，可以在MICROSAR OS查看Error Code
Protection Hook	Stack, Memory, timing 保护错误发生时触发
Panic Hook	NULL指针，unexpected process