基于OSEK/VDX规范的车用实时操作系统设计

 

　　随着汽车工业的飞速发展，电子技术在汽车上的应用比重不断增加。为了满足日益复杂的汽车电子控制软件的开发需要，实现应用软件的可移植性和不同厂商的控制模块间的可兼容性，1993年德国汽车工业界联合推出了“汽车电子的开放式系统及接口软件规范”，即OSEK(open system and the corresponding interfaces for automotive electronics)。1994年法国汽车工业界的相似规范VDX(vehicle distributed executive)和OSEK规范合并，从而形成OSEK/VDX规范体系。

　　此规范主要由4部分组成：操作系统规范(OSEKOS)、通信规范(OSEKCOM)、网络管理规范(OSEKNM)和OSEK实现语言(OSEKOIL)。其中OSEKOS是针对汽车应用特点而专门制定的一个小型RTOS规范，着重以下几个方面：

　　①可移植性，所有API都是标准化的并且在功能上都有明确的定义;

　　②可扩展性，OSEKOS旨在通用于任何类型的 ECU，因此一方面系统要高度的模块化，另一方面又要能进行灵活的配置;

　　③汽车应用的特定需求，诸如可靠性、实用性和代价敏感性等。相应的，OSEKOS 静态配置可以通过OS2EKOIL语言实现，用户在系统生成时静态制定任务的个数、需要的资源和系统服务。OSEKCOM为通信网络中的数据交换提供了标准的接口和协议。OSEKNM为监视网络的流量提供了一组标准的功能函数，以保证网络的安全性和可靠性。

　　μC/OS-Ⅱ是一个著名的源代码公开的实时内核，专门为嵌入式应用设计的。它的主要性能特点如下：

　　①源代码公开。这样很容易就能把操作系统移植到各个不同的硬件平台上;

　　②可移植性。μC/OS-Ⅱ绝大部分源代码是用C语言写的，而与微处理器硬件相关的那部分是用汇编语言写的，使得μC/OS-Ⅱ便于移植到其他的微处理器上;

　　③可固化。只要开发者有固化手段，μC/OS-Ⅱ可以嵌入到开发者的系统中;

　　④可裁剪性(Scalable)。开发者可以有选择的使用μC/OS-Ⅱ中应用程序需要的那些系统服务，可以减少μC/OS-Ⅱ所需的存储空间;

　　⑤占先(Preemp2tive)。μC/OS-Ⅱ完全是占先式的实时内核;

　　⑥多任务(Multi-Tasking)。μC/OS-Ⅱ可以管理64个任务，但是目前应用程序最多有56个任务;

　　⑦可确定性 (Affirmable)。μC/OS-Ⅱ系统服务的执行时间不依赖于应用程序任务的多少;

　　⑧实用性和可靠性。许多的行业都有成功应用该实时内核的实例，这些应用的实践是该内核实用性和可靠性的最好证据。

　　OSEKOS结构特点及运行机制

　　OSEKOS的结构特点

　　(1)高实时性。由于在汽车控制领域，如果出现丝毫的差错会导致危及生命安全的严重后果，因此要求具有高度的实时性。OSEKOS所有的系统对象由用户在建立时静态创建，避免了动态创建时的时间消耗，增强了其实时性。而且通过占先式的调度策略和警报机制也能满足实时性需求;

　　(2)标准化应用接口。其制定了标准的应用程序编程接口，这样可以屏蔽底层硬件结构的不同而提供一个一致的开发环境。并且用户只需修改OIL配置文件中与硬件相关的部分，可以方便地在不同的ECU上进行移植;

　　(3)可裁剪性。其具有高度模块化和可灵活配置的特性，用OIL语言进行裁剪，可以在很少的硬件资源环境下运行。

　　OSEKOS运行机制分析

　　任务管理

　　OSEK规范将任务分为基本任务和扩展任务。基本任务具有3种状态：运行状态、就绪状态和挂起状态。扩展任务多了一个等待状态。此外基本任务只在开始和结束时才有同步点，所以其需要的资源少，而扩展任务可以对应不同的时间，在运行中可能有多个同步点，所以对环境要求高。操作系统的任务之间的同步通过调度程序来实现。

　　OSEK规范支持3种调度方式：

　　①完全抢占式调度。该策略用于保存现场的内存开销较大，理论上可以在任务的任何位置重调度，因此任务必须同步访问共享资源，增加了系统的复杂性;

　　②非抢占调度。此策略通过调用某些服务例程实现任务切换，即用户设置重调度点。通过定义任务组，可以使多个任务同时具有抢占或非抢占调度的特征;

　　③混合抢占调度。抢占任务和非抢占任务共存于一个系统时，使用“混合抢占”调度策略。在这种情况下，调度策略依赖于正在运行任务的抢占特性，开发者通过配置任务优先级和抢占属性来定义任务执行顺序。

　　一致类

　　为了更加灵活的配置操作系统调度，OSEK规范定义了4种一致类：BCC1、BCC2、ECC1和ECC2。其根据每个优先级可能有的任务个数，需要的是基本任务还是扩展任务来进行划分。若每个优先级上只有一个任务，且是基本任务则定义一致类为BCC1，是扩展任务则定义为BCC2;若每个优先级上可以有多个任务，且是基本任务则定义一致类为ECC1，是扩展任务则定义为ECC2。

　　中断处理

　　OSEK规范定义了2种中断服务程序：①ISR1。此类中断程序不使用操作系统的资源，中断结束后，处理程序从产生中断的地方继续执行。其对任务的管理没有影响，不要求调用操作系统的API。②ISR2。此类中断程序是系统生成时，通过用户子程序配置而成，它可以调用操作系统的API。中断的优先级高于任务，因此可以抢占任何任务。

　　事件机制

　　事件机制用于保证不同扩展任务之间的同步。该机制含义是，一个处于等待状态的扩展进程，只有当它所等待的事件至少有一个发生，才能进入就绪态，并且事件的发生会以信号的方式传给该进程。只有扩展任务，才具有事件。

　　资源管理

　　具有不同优先级的多任务访问共享资源需要使用资源管理机制进行协调。这些资源可以是一段临界区代码、调度程序、共享内存或是数据结构，也可以是共享硬件设备。系统在处理多个进程对共享资源的互斥访问时，采用信号量对临界区数据或资源加锁，但是这样可能会导致优先级反转。为了避免这种情况出现，OSEK采用了优先级最高限度协议(PCP)，即当一个进程占用了一个资源后，该进程的优先级会临时升高为该资源优先级。当该任务释放了资源后，其优先级回到要求访问资源前的优先级。使用该协议同时也解决了死锁的问题。

　　报警器

　　报警器是OSEK为处理循环事件提供的服务机制，警报或者基于系统时钟，或者基于其他的某种计数器。当计数器到达警报设置值时被触发，此时可以激活进程也可以为某进程设置事件，或者执行一个警报回调程序。

　　消息处理

　　任务之间是通过消息实现通信的，消息是应用数据的容器，只有一个发送者，但是可以有多个接受者。OSEK规范将消息分为可排队和不可排队的。前者是静态长度消息，内部数据被组织成FIFO队列，能被接受服务例程移走;不可排队消息是不断被刷新的消息，不能被服务例程移走。

　　错误处理

　　OSEKOS提供了系统专用的钩子程序，以便在操作系统内部操作时执行用户定义的函数。钩子程序可用于：系统启动，相应钩子程序在操作系统启动后，进入调度程序之前执行;系统关闭，相应钩子程序在应用或操作系统(此时发生严重错误)请求系统停止运行时执行;跟踪、调试应用以及现场切换时调用用户定义的扩展程序;错误处理。

　　基于μC/OS-Ⅱ的OSEKOS设计

　　OSEKOS设计理念

　　根据OSEK规范和μC/OS-Ⅱ的内核要求，CC1和ECC1这2个符合级别都只允许一个优先级有一个进程，因此可以将优先级从0到N-1分配给N个进程，使每个进程分配到的优先级不同，N是系统中的进程数量，这样可以使修改后的μC/OS-Ⅱ内核满足ECC1类模式。由于BCC2和ECC2这2个符合级别可以允许每个优先级有多个进程，因此要使用复杂的调度策略来追踪各个进程。

　　设计的OSEKOS可以采用μC/OS-Ⅱ的调度结构——就绪表，使用简单的占先式的调度策略，将每个进程的就绪态标志都放入就绪表中，然后从其中找到优先级最高的就绪态进程执行，实现一个基于优先级的可剥夺型的实时内核。这样不仅可以提高系统的实时性，而且可以降低操作系统的CPU负荷。对于BCC2和 ECC2这2个符合级别而言，可以在基于优先级的占先式调度策略基础上添加时间片轮换调度算法来处理优先级相同的2个任务之间的调度;也可以为每个优先级增加一个FIFO队列，先以任务优先级为检索，然后选择该进程队列中位于对首的进程运行。但是这样会牺牲一定的实时性，并且加大CPU的负荷，占用更多的 RAM。

　　为了提高OSEKOS的可移植性和利于OSEKOS的配置，按照μC/OS-Ⅱ的内核结构将其分为3部分：硬件无关部分、硬件相关部分和应用相关部分。这样可以使其在不同的硬件之间移植时更加的方便，将与应用相关部分放入配置文件内，便于用户使用。

　　μC/OS-Ⅱ在处理多个进程对共享资源的互斥访问时，主要是采用开关中断与信号量来对临界区数据或资源加锁，使用互斥型信号量管理来避免优先级反转，通过允许用户在申请信号量时定义等待超时化解死锁问题。OSEKOS是通过采用优先级最高限度协议(PCP)来避免优先级反转和死锁问题。可以通过在系统生成期间，静态分配每一资源的最高限度优先级，使设计的OS2EKOS执行PCP协议，达到兼容OSEK规范的目的。

　　根据OSEK规定的2类中断，针对具体的处理器平台，实现中断管理的标准API，并且根据μC/OS-Ⅱ提供非OSEK标准的API：开/关中断。由于是基于ECC1类模式来实现OSEKOS，所以支持OSEK规范定义的事件机制，可用于实现任务之间的同步协调。根据μC/OS-Ⅱ，可以支持的事件种类有信号量、互斥型信号量、邮箱和消息队列。由μC/OS-Ⅱ提供的时间管理和定时中断功能，实现OSEKOS中要求的警报器管理，以进一步提高操作系统的实时性和安全性。在μC/OS-Ⅱ中，定义了一系列与OSEKOS规范要求类似的钩子程序，用于实现用户自己定义的函数。

　　OSEKOS基本结构的组成

　　由于OSEKOS中的标准应用程序接口(API)定义在操作系统的核心空间，根据以上设计理念可以将操作系统按功能分为进程管理和调度、资源管理、警报与计数器管理、事件管理和中断管理，其结构组成如图1所示。其中进程管理与调度是整个操作系统的核心，其他的管理机制为它提供不同的服务支持。

　　

 

　　图1　OSEKOS结构组成图

　　每个进程都通过一个进程控制块(TCB)来管理，在进程管理模块中，实现OSEK标准API：激活进程、终止进程、连接进程、调度、捕获当前运行进程ID 和获得进程状态。资源管理模块实现OSEK标准API：获得资源、释放资源。计数器管理没有标准API，警报管理结构由警报和警报行为组成。其标准 API：获得警报信息、获得警报到期所需时间、设置相对警报、设置绝对警报和消除警报。事件管理模块实现的OSEK标准API：等待事件、设置事件、消除事件和获得进程的时间状态。实现中断管理的标准API：开/关所有中断和开/关第二类中断。

　　结束语

　　根据OSEKOS规范和μC/OS-Ⅱ内核实现的不同技术特点，提出OSEKOS的一些设计思想，并且设计出OSEKOS的基本结构组成。 OSEK/VDX体系的建立给国际汽车工业带来深远的影响，采用基于OSEK/VDX规范的RTOS进行开发能节省开发时间，降低成本，提高软件质量和模块的可移植性，而且需要的资源少。因此，研究基于OSEK/VDX规范的操作系统具有重要的意义。