OSEK的设计哲学与架构

 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所示。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。