嵌入式系统及应用 OSEK/AUTOSAR OS简介

主要内容 概述 OSEK OS 调度表 堆栈监测 OS应用 保护功能

1.1 什么是OSEK/VDX? In May 1993 OSEK has been founded as a joint project in the German automotive industry aiming at an industry standard for an open-ended architecture for distributed control units in vehicles. OSEK is an abbreviation for the German term "Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug" (English: Open Systems and the Corresponding Interfaces for Automotive Electronics). Initial project partners were BMW, Bosch, DaimlerChrysler, Opel, Siemens, VW and the IIIT of the University of Karlsruhe as co-ordinator. The French car manufacturers PSA and Renault joined OSEK in 1994 introducing their VDX-approach (Vehicle Distributed eXecutive) which is a similar project within the French automotive industry. At the first workshop on October 1995 the OSEK/VDX group presented the results of the harmonised specification between OSEK and VDX. After the 2nd international OSEK/VDX Workshop in October 1997 the 2nd versions of the specifications were published.

The open architecture introduced by OSEK/VDX comprises the three areas: Communication (data exchange within and between control units) Operating System (real-time execution of ECU software and base for the other OSEK/VDX modules) Network Management (Configuration determination and monitoring)

Motivation high, recurring expenses in the development and variant management of non-application related aspects of control unit software incompatibility of control units made by different manufactures due to different interfaces and protocols Goal Support of the portability and reusability of the application software by: specification of interfaces which are abstract and as application-independent as possible specification of an user interface independent of hardware and network efficient design of architecture: The functionalities shall be configurable and scalable, to enable optimal adjustment of the architecture to the application in question verification of functionality and implementation of prototypes in selected pilot projects

Structure The Steering Committee is responsible for the overall project organization and co-ordination (e.g. assignment of working group leaders), for granting of licenses to other companies, and for the external representation of OSEK/VDX (e.g. publications). The participation in the Technical Committee offers associated partners to actively co-operate in OSEK/VDX. Currently the technical committee is formed by the initial OSEK/VDX partners and over 50 associated partners from different industries related to automotive electronics, i.e. car manufacturers, automotive suppliers, semiconductor industries and software companies. Obviously, OSEK/VDX is open for the integration of additional associated partners.

1.2 System philosophy Automotive applications are characterized by stringent real-time requirements. Therefore the OSEK operating system offers the necessary functionality to support event driven control systems. The specified operating system services constitute a basis to enable the integration of software modules made by various manufacturers. As the operating system is intended for use in any type of control units, it shall support time-critical applications on a wide range of hardware. For time-critical applications dynamic generation of system objects was left out. Instead, generation of system objects was assigned to the system generation phase.

Standardized interfaces The interface between the application software and the operating system is defined by system services. The interface is identical for all implementations of the operating system on various processor families. Scalability feasible for a broad spectrum of applications and hardware: Different conformance classes, various scheduling mechanisms and the configuration features make the OSEK operating system. require only a minimum of hardware resources (RAM, ROM, CPU time) and therefore runs even on 8 bit microcontrollers. Error checking offers two levels of error checking: extended status for development phase standard status for production phase For Error checking: The extended status allows for enhanced plausibility checks on calling operating system services. Due to the additional error checking it requires more execution time and memory space than the standard version. However, many errors can be found in a test phase. After all errors have been eliminated, the system can be recompiled with the standard version.

Portability of application software means the ability to transfer an application software module from one ECU to another ECU without bigger changes inside the application. For better portability of application software, the OSEK defines a language for a standardized configuration information. Support of Portability The certification process ensures the conformance of different implementations to the specification.

Service groups Task management Synchronization Activation and termination of tasks Management of task states, task switching Synchronization The operating system supports two means of synchronization effective on tasks: Resource management Access control for inseparable operations to jointly used (logic) resources or devices, or for control of a program flow. Event control Event management for task synchronization. Interrupt management Services for interrupt processing Alarms Relative and absolute alarms Intra processor message handling Services for exchange of data Error treatment Mechanisms supporting the user in case of various errors

1.3 OSEK OS & AUTOSAR OS 作为系统服务(System Services)的一部分，AUTOSAR OS包含了许多的功能模块和函数结构，供系统中的其他模块使用

概述 AUTOSAR OS 功能结构

OSEK OS规范中所定义的操作系统功能，自然也成为AUTOSAR OS的一部分。 系统扩展性（System Scalability） 系统扩展性是用户为了最大程度的利用处理器的功能，对OS的功能进行自定义。自定义操作系统的功能由扩展类定义，AUTOSAR OS支持4种不同的扩展类，每一种扩展类具有的功能及硬件要求如下图 OSEK OS规范中所定义的操作系统功能，自然也成为AUTOSAR OS的一部分。

主要内容 概述 OSEK OS 调度表 堆栈监测 OS应用 保护功能

2.1 Processing levels The OSEK operating system provides a defined set of interfaces for the user. These interfaces are used by entities which are competing for the CPU. There are two types of entities: Interrupt service routines managed by the operating system Tasks (basic tasks and extended tasks)

OSEK defines three processing levels Interrupt level Logical level for scheduler Task level Please note that assignment of a priority to the scheduler is only a logical concept which can be implemented without directly using priorities.

2.2 Conformance classes (符合类级别) Various requirements of the application software for the system and various capabilities of a specific system (e.g. processor, memory) demand different features of the operating system. Conformance classes exist to support the following objectives: To provide convenient groups of operating system features for easier understanding and discussion of the OSEK operating system. To allow partial implementations along pre-defined lines. These partial implementations may be certified as OSEK compliant. To create an upgrade path from classes of lesser functionality to classes of higher functionality with no changes to the application using OSEK related features.

符合类级别（Conformance Classes ） OSEK/VDX标准的版本2.2.2的内核分为以下四个符合类级别：BCC1、ECC1、BCC2、ECC2 版本2.2.2的COM部分分为CCCA、CCCB、CCC0、CCC1、CCC2这五个符合类级别 我们目前实现的OSEK操作系统支持BCC1、ECC1、BCC2、ECC2以及CCCA、CCCB。

符合类级别（Conformance Classes ） BCC1和BCC2只支持基本任务（BT），而ECC和ECC２既支持基本任务（BT）又支持扩展任务（ET）。 BCC1和ECC1中的任务只能激活一次，并且同一优先级的任务只能有一个，不同任务的优先级不同。而BCC2和ECC2中的基本任务可以被激活多次（扩展任务只能激活一次），并且同一优先级可以有多个任务，即不同的任务可以有相同的优先级。

符合类级别（Conformance Classes ） 扩展任务具有如下特性： 可以使用事件机制 有自己独立的堆栈 通过调用操作系统提供的等待事件接口，使任务进入等待事件的状态。

符合类级别（Conformance Classes ） 基本任务具有如下属性： 基本任务不能等待事件 其状态只有就绪、运行和终止三种 基本任务没有自己的堆栈，系统中所有的基本任务共用一个堆栈

各符合类的最小需求 BCC1 BCC2 ECC1 ECC２ 是否可以多次激活 否 是 BT（基本任务）：是 ET（扩展任务）：否 同一优先级的任务数 1 >1 1（包括基本任务和扩展任务） >1（包括基本任务和扩展任务） 不在挂起状态的任务数量 >=8 >=16 每个任务的事件数量 － 基本任务：无 扩展任务：>=8 任务优先级的数量 资源 只有调度器资源 >=8个（包括调度器资源） 内部资源 >=2 报警 >=1个单次报警或循环报警 消息 可能使用

通信的符合类级别 CCCA－定义了通信的最小特性集： CCCB－CCCA的所有特性都支持，并扩展了: 只支持内部通信 支持非队列消息 支持通知级别1 支持SendMessage和ReceiveMessage. CCCB－CCCA的所有特性都支持，并扩展了: 完全的通知级别1 消息状态信息 队列式消息 提供了GetMessageStatus, GetMessageResource 和 ReleaseMessageResource服务.

2.3 OSEK OS需求-功能要求 包含OSEK/VDX标准所要求的任务管理、中断管理、事件管理、资源管理、报警管理、消息通信管理、系统执行管理等功能，并支持操作系统功能扩展及一定的出错处理功能 其他功能：为方便应用的开发提供计数器管理和调试管理的功能。计数器管理为报警机制提供支持。调试管理功能提供获取堆栈使用信息、获取系统时间戳等辅助调试的功能

2.3 OSEK OS需求-接口要求 提供标准的应用编程接口（API），符合OSEK标准对API名称、参数类型和一些宏定义的要求，能使客户已有的基于OSEK操作系统的应用快速无缝地移植。

2.3 OSEK OS需求-性能需求 具有实时性的要求，并且确定性要好。具 体需求为： 中断响应时间为微秒级； 任务切换和任务响应时间为微秒级； 各个API的执行时间确定，在微秒级。

实现考虑： 支持优先级抢占、非抢占、混合（对整个系统而言） 等三种任务调度策略，既保证强实时任务得到尽快响 应，又提供了一定程度的应用灵活性 优先级位图算法提高确定性 资源的管理支持优先级天花板协议，有效防止优先级 反转、阻塞链和死锁 支持中断嵌套，保障高优先级的中断得到及时响应 各API采用扩展返回状态对输入参数的正确性进行检 查，应用开发完成后可屏蔽扩展返回状态以便将相关 源码剪裁掉，提高API的执行性能

2.3 OSEK OS需求-可剪裁、可配置需求 满足OIL（OSEK Implementation Language）标准 的要求，能根据应用的需求将操作系统对空间、时间 的占用降到最低； 操作系统是完全静态配置的，在系统服务中不存在创 建和删除各个对象的接口，各对象的固有属性都是在 系统初始化时根据应用的静态配置确定的。这能够避 免出现运行期资源竞争的问题，也在一定程度上提高 了系统的可靠性

2.3 OSEK OS需求-可移植性需求 各种体系结构的32位计算环境，能方便地移植到其他处理器平台上 包括MPC555 MPC5554 MC9S12X TMS470 PC386等 MC9S12X 支持PowerPC、X86、ARM体系结构多种型号的CPU

2.3 OSEK OS需求-可移植性需求 以下的实现考虑有助于提高可移植性，便于快速移植到不同的硬件平台上 代码编写技巧 良好设计的软件结构 基于C语言的实现 代码编写技巧

2.3 OSEK OS需求-指标性需求 支持64级的任务优先级 支持最多255个任务，不在挂起态的任务最多允许255个 每个任务允许的最多事件数为32个 允许的资源数仅受ECU内存资源限制 允许的Alarm仅受ECU内存资源限制 允许的消息对象数仅受ECU内存资源限制（实际受消息对象ID数据类型的长度限制） 应用模式数允许最多8个

2.4 OSEK OS软件体系结构 执行管理 内 部 通 信 管 理 HOOK管理 调试管理 事件管理 资源管理 任务管理 Alarm管理 中断管理 Counter管理 资源管理：OSEK中的资源是一种用于同步或者互斥的手段， 资源管理主要实现资源的获取、释放等功能 中断管理：主要实现全局中断、操作系统中断等的打开和关闭功能。 Hook管理：主要为用户提供功能的扩展能力，包括错误处理、任务切换前、 任务切换后、系统启动、系统关闭、系统进入IDLE等时机， 通过hook功能为用户程序提供机会来介入系统的处理 Counter管理：主要实现计数器的计数、信息查询等功能， 并且为Alarm提供定时计数功能。 调试管理：主要提供扩展任务栈的使用情况，以及当前系统时戳等功能， 这些接口都不是OSEK标准规定的接口，主要是用于调试的辅助手段 任务管理：主要实现扩展任务、基本任务等的激活、结束、重调度、 以及一些任务信息的获取功能。 执行管理：主要实现操作系统的启动和关闭功能 Alarm管理：主要实现定时功能，在预定时间到达时触发相关的操作， 如：设置事件、激活任务、进行回调等操作 内部通信管理：主要实现操作系统内部的消息通信， 不涉及外部通信，提供发送、接收消息， 以及消息的锁定和解锁等功能 事件管理：是附属于任务的一种通知机制，其不是一种独立对象。事件管理主要负责 实现事件的发送、等待、查询、清除等功能

2.5 任务管理 Two different task concepts are provided by the OSEK operating system: Basic Tasks only release the processor, if they terminate, the OSEK operating system switches to a higher-priority task, or an interrupt occurs which causes the processor to switch to an interrupt service routine (ISR). Extended Tasks allow to use the operating system call WaitEvent, which may result in a waiting state. In view of the operating system, management of extended tasks is, in principal, more complex than management of basic tasks and requires more system resources.

2.5.1 任务状态模型 Extended task

basic task

2.5.2 任务优先级 The value 0 is defined as the lowest priority of a task. Accordingly bigger numbers define higher priorities. To enhance efficiency, a dynamic priority management is not supported. Accordingly priority of a task is defined statically, i.e. the user cannot change it at the time of execution. However, in particular cases the operating system can treat a task with a defined higher priority (OSEK Priority Ceiling Protocol). Tasks on the same priority level are started depending on their order of activation. A preempted task is considered to be the first (oldest) task in the ready list of its current priority. A task being released from the waiting state is treated like the last (newest) task in the ready queue of its priority.

具体实现时：有32级和64级两种，优先级数大则优先级高。根据实际应用的规模选择32级的任务优先级，能有效降低OS的空间消耗。

任务上下文是多任务环境下任务的运行环境，主要包括运行地址、栈指针、CPU状态相关寄存器、通用寄存器、浮点寄存器等 2.5.3 任务上下文 任务上下文是多任务环境下任务的运行环境，主要包括运行地址、栈指针、CPU状态相关寄存器、通用寄存器、浮点寄存器等 PC是程序的返回地址 SP是任务的栈指针 gpr14-gpr31是通用寄存器的Non-volatile部分的寄存器，Volatile部分不需要保存 fpr14-fpr31是浮点寄存器的Non-volatile部分寄存器，Volatile部分不需要保存

保存不同处理器的任务上下文的空间消耗 保存PowerPC e200z6内核的gpr14-gpr31，这18个64位的通用寄存器占据的存储空间为：18*64/8=144字节

保存不同处理器的任务上下文的空间消耗 保存MC9S12X处理器内核的寄存器占据的存储空间仅需：6*16/8=12字节

2.5.4 任务的调度 任务的调度 支持抢占、非抢占、混合性等三种类型 抢占表示允许优先级高的任务抢占优先级低的 任务运行 非抢占表示不允许优先级高的任务抢占优先级 低的任务运行，除非任务自动放弃CPU 混合性表示系统中同时有抢占和非抢占的任务。 这样既保证强实时任务得到尽快响应，又提供 了一定程度的应用灵活性。

抢占式调度示意

非抢占式调度示意

系统调度时机 当在执行某个系统调用的时候可能发生任 务状态转换: 有新的高优先级任务就绪，或 当前运行任务发生状态变更,或 当在执行某个系统调用的时候可能发生任 务状态转换: 有新的高优先级任务就绪，或 当前运行任务发生状态变更,或 当前运行任务优先级降低

系统调度时机 当在执行某个系统调用的时候可能发生任务状态转换: 有新的高优先级任务就绪，或 当前运行任务发生状态变更,或 在当前任务允许被抢占并且未在中断中时，则立刻进行调度 如果处于中断中则记录一个标志，在中断退出的时候（中断派发程序的最后）进行调度 如果任务不允许被抢占，则在该任务主动放弃CPU（比如终止自己）的时候进行调度 当在执行某个系统调用的时候可能发生任务状态转换: 有新的高优先级任务就绪，或 当前运行任务发生状态变更,或 当前运行任务优先级降低

抢占式调度时机举例: Successful termination of a task (system service TerminateTask). Successful termination of a task with explicit activating of a successor task (system service ChainTask). Activating a task at task level (e.g. system service ActivateTask, message notification mechanism, alarm expiration). Explicit wait call if a transition into the waiting state takes place (extended tasks only, system service WaitEvent). Setting an event to a waiting task at task level (e.g. system service SetEvent, message notification mechanism, alarm expiration, if event setting defined). Release of resource at task level (system service ReleaseResource) Return from interrupt level to task level

非抢占式调度时机 rescheduling in the following cases: Successful termination of a task (system service TerminateTask). Successful termination of a task with explicit activation of a successor task (system service ChainTask). Explicit call of scheduler (system service Schedule). A transition into the waiting state takes place (system service WaitEvent). Implementations of non preemptive systems may prescribe that operating system services which cause rescheduling may only be called at the highest task program level (not in task subfunctions). A task switch at these points of scheduling usually requires saving of less task context information.

The definition of a non preemptable task makes sense in a full preemptive operating system if the execution time of the task is in the same magnitude of the time of a task switch, if RAM is to be used economically to provide space for saving the task context, or if the task shall not be preempted. Many applications comprise only few parallel tasks with a long execution time, for which a full preemptive operating system would be convenient and many short tasks with a defined execution time where non preemptive scheduling would be more efficient.

调度器 负责所有任务的调度 主要利用优先级位图获取当前就绪任务的最高 优先级，然后从就绪队列中获取第一个就绪任 务，然后通过对任务上下文的操作实现最终的 任务切换 调度器有一个全局的调度锁，用于控制是否运 行调度

就绪任务队列

任务运行时控制结构及配置结构

任务管理的API接口 类别 接口名称 功能 任务管理 ActivateTask 激活任务 TerminateTask 结束任务 ChainTask 结束并激活其它任务 Schedule 重调度 GetTaskID 获取任务ID GetTaskState 获取任务状态

Activating a task T0时刻 T1时刻 T2时刻 有1个任务就绪 1个新的任务被激活，系统中有2个就绪任务 激活了某已就绪任务的第2个运行实例 T2时刻

任务功能代码示例