1 前言

        OSEK是为单核分布式嵌入式控制单元量身定制的实时系统，对事件驱动（event driven）的硬实时控制系统具有良好的适配性。OSEK没有强求不同软件模块间的完全兼容性，而是将重心放到了软件的可移植性上来。简单来说，与其花费大量精力去适配各种软硬件环境，不如成为规则的制定者，让它们来适配我，OSEK如是说。

2 系统设计哲学

2.1 静态配置

       OSEK舍弃了一切动态配置OS对象的操作，转而采用通过标准接口来静态配置的方式，甚至连动态错误查询的操作都被舍弃。静态配置意味着稳定可控可预测，另一方面也会规避动态操作对于系统运行速度的影响。

2.2 标准化OS接口

        标准化OS接口是OSEK的另一设计哲学，这使得应用程序与OS之间的接口通过系统服务的方式得以统一，OS成为硬件和应用程序之间天生的中间层，这进一步提高软件的可移植性。

        标准化接口，主要包括系统调用（service calls），类型定义及常量定义等，以支持OS源码级的可移植性。然而，OSEK并没有标准化与硬件直接相关的I/O接口（如图1所示），显然有点革命尚未成功的感觉。        

图1 软件接口示意图 

2.3 拓展性

       多样的标准化类型定义（conformance classes）、调度机制以及配置方式，使得OSEK的可拓展性也得到了很大的提高。微内核的设计思想，使得OS对于RAM，ROM和CPU的要求都相对较低，以至于其可以通过裁剪运行在8位控制器上。

2.4 错误检测（Error checking）

        OSEK的错误检测，包括开发阶段的拓展状态（extended status for development phase）和生产阶段的标准状态（standard status for production phase）两种类型。

        拓展状态允许通过调用系统服务进行加强型的错误检查，这必然带来更多的执行时间和内存空间等资源消耗。因此，拓展状态主要用于开发阶段，并建议通过宏定义隔离开，一旦开发测试完成后，则重新编译，去除这些运行时的错误检查，生成标准状态版本。

2.5 车规级优化

        OSEK本质上就是为汽车控制系统量身打造，在可靠性、实时性及成本方面都有着很多考虑：

        ① 包括任务、OS资源/服务在内的各类OS对象，都通过静态配置来生成，这保证了稳定性和可拓展性；

        ② 支持从ROM启动程序（executed from Read-Only-Memory）；

        ③ 对于应用层程序来说，可移植性好；

        ④ 系统行为可预测性好，易于软件规划部署，满足车载实时性要求。

3 OSEK架构

        OSEK提供了不同服务和处理机制的集合，用户通过静态配置来选择所需要的系统服务和处理机制。同时，根据应用的实际需要，划分了四个一致类（conformance classes）以规范OS的行为，同一类的应用之间应是可移植的。

        服务的分类是以功能需求为基础的，这就包括了以下几个方面：

        ① 任务管理（Task management）

        包括任务的激活和终止（Activation and termination of tasks），以及任务状态、任务切换等；

        ② 同步与互斥机制

        包括临界区保护、基于事件（event）的同步机制等；

        ③ 中断管理；

        ④错误处理。

3.1 处理等级

3.1.1 两个实体（entity)

        总的来说，OSEK管理着控制器的硬件资源，并向应用层以标准化的接口提供系统服务，而这些服务都是面向以下两个实体的：

        ① 由OS管理的中断向量；

        ② 任务，包括基础任务和拓展任务(basic tasks and extended tasks)；

3.1.2 三个处理等级（processing levels）

        在此基础上，OSEK定义了三个处理等级：

        ① 中断级别；

        ② 调度器级（内核级，这是一个逻辑级别）；

        ③ 任务级；

        同时，如图2所示，对于各级别的优先级有如下规定：

        ① 中断的优先级高于任务；

        ② 中断处理可以包含一个或多个优先级级别，即不同的中断的优先级可以不同；

        ③ 中断服务函数的优先级的实现依赖于具体的硬件环境；

        ④ 对于任务优先级和系统资源上限优先级来说，优先级的值越大，表示优先级越高。

图2 OSEK的处理级别

3.2 一致类（Conformance classes，CC）

        为了针对不同的软硬件环境和产品应用需求做出更明确的规范，OSEK定义了四个一致类，且保证低级类可以向上升级至高级类。        

        一致类的定义主要从以下几个属性来划分的：

        ① 支持的任务激活次数；

        ② 支持的任务类型；

        ③ 支持的同优先级的任务个数；

图3 OSEK 一致类示意图

        具体来说，大概就是以上几个属性的排列组合：

        ① BCC1 （Basic Conformance class 1）

        只支持基础任务（basic tasks)，且每个任务最多只能激活一次，每个优先级都只有一个任务，即不同任务的优先级不同；

        ② BCC2

        在BCC1基础上，支持基础任务的多次激活，同优先级可以有多个任务，仍只支持基础任务；

        ③ ECC1

        在BCC1的基础上支持了拓展型任务（extended tasks）；

        ④ ECC2

        在ECC1的基础上，支持基础任务的多次激活，且同优先级可以有多个任务；

图4 不同CC的最低要求 

        其他信息，如图4所示。