基于微内核的星载实时操作系统设计与实现

徐 建，杨 桦

(北京控制工程研究所，北京100190)

基于微内核的星载实时操作系统设计与实现

徐 建，杨 桦

(北京控制工程研究所，北京100190)

当前星载嵌入式实时操作系统将各个功能模块都集成在内核之中，这导致内核庞大，增加了内核出现bug的风险，从而使整个操作系统的可靠性降低.设计并实现了一个基于微内核的星载嵌入式实时操作系统，通过将功能模块以任务方式运行在用户态，任务间通过消息传递机制通讯，以减少内核代码量.最后测试表明设计达到故障隔离的效果.

微内核;可靠性;嵌入式操作系统;故障隔离

一个计算机系统的可靠性和安全性很大程度上取决于运行在其上的操作系统内核.内核是指运行在处理器特权模式下的代码，内核中任何一个错误都会导致整个系统的错误甚至是崩溃.在任何代码量软件中出现bug的可能性不可避免，代码量越小，软件中bug出现的可能性越小.而传统的操作系统是宏内核结构，内核中包含了操作系统的大部分功能，随着操作系统功能的扩展，其内核不断扩大，使得内核可靠性降低.而基于微内核设计思想的操作系统通过减少内核部分代码，减少内核功能，减少内核出错的概率，从而提高整个系统的可靠性.微内核的目的是尽可能把所有的功能模块都移出内核，使内核缩到最小［1］.理想情况下，微内核中仅留下地址空间支持(address space support)，进程间通讯(IPC， inter-process communication，)，调度(Scheduling)，其他功能模块均作为用户进程运行.用户进程之间通过IPC进行通信.

微内核还具有以下几种优势［2］:

·扩充性强，支持更加模块化的设计;

·可维护性好，小的内核更容易更新与维护

·可靠性高，许多模块的bug可被封闭在模块内，一个模块发生故障时，其他模块和内核将不受影响或影响很小;

·灵活性强，策略与机制分离，使系统设计更灵活，不同方法实现的模块可在系统中共存.

基于消息传递的IPC机制是微内核的基本特点之一.这一设计理念有助于提高系统的灵活性，模块化，安全性，以及可扩展性.而IPC的性能表现是决定微内核性能的关键因素.以Mach为代表的第一代微内核在IPC性能上表现很差，大大减弱了微内核的应用.以L4［3］为代表的第二代微内核，通过精简内核架构，提高IPC性能，使得微内核的性能得到很大提高.目前国外正在对第三代微内核进行研究，一个澳大利亚的研究组织设计并实现了 seL4［4］，seL4是基于L4的面向于实时应用的微内核，并通过形式化方法完成了对微内核功能正确性和行为可预测性的验证［5］，进一步提高了微内核的可靠性.

目前大部分星载嵌入式实时操作系统都将任务管理、中断管理、信号量管理、消息管理、内存管理和时间管理等各个模块都集成在内核中，模块间耦合性很高.如果在某一模块由于编程错误或者其他未知的错误出现故障的情况下，将会直接影响到操作系统的其他模块［6］，从而导致整个系统的故障.通过微内核架构来可以达到各个功能模块之间故障隔离的目的.本文以航天应用的背景出发设计并实现了一个基于微内核的星载嵌入式操作系统Micro-SpaceOS，第二、三部分将分别介绍基于微内核嵌入式操作系统的设计和实现.

1 M icroSpaceOS的设计

MicroSpaceOS的设计目的主要是设计一款具有高可靠性的星载嵌入式操作系统.设计方法是设计基于微内核的系统，将各个功能模块放到内核外面，以服务程序的形式存在.设计的原则:

a)各个功能模块运行在用户层;

b)内核尽可能小，仅留必需的模块;

c)功能模块间相互隔离.

下面本文将依据以上3条原则来设计Micro-SpaceOS.

1.1 功能模块任务化

通用的微内核主要是在地址空间和进程的支持下达到各个模块间隔离的.不同的功能模块以进程形式处于不同的地址空间中，进程间通过IPC来完成通讯的.地址空间是建立在虚拟内存机制之上，这就要求系统要有存储器管理单元(MMU，memory management unit)的支持.然而，目前在航天领域由于使用的内存小、MMU可靠性低等因素，普遍不使用处理器上的MMU.

考虑到这一点，为了设计适合航天领域应用的微内核，如图1所示，本文通过将功能模块以任务形式运行将功能模块从内核中移出，满足了第一条设计原则.将不同功能模块放到不同的任务之中，当其他模块要使用某一功能模块的某一函数时，只能通过内核提供的基于消息传递的通讯机制来发送消息、接收返回消息，不能直接函数调用.通过任务切换过程中的上下文保护，来达到故障隔离的目的.虽然在这种消息机制会损耗部分系统时间，但可以大大提高系统的可靠性.微内核的相关概念在这里有相应的映射，地址空间对应于这里的任务上下文，进程对应于这里的任务，IPC对应于任务间通信.

1.2 微内核的设计

MicroSpaceOS的微内核部分主要是由任务间通信机制、任务调度、任务创建、时间片中断处理程序构成，如图 2所示.将内存管理、中断管理、信号量管理和任务管理的部分函数放到任务中去.在保证系统效率的条件下，尽可能减少内核中的功能模块.这一设计符合了设计原则的第二条.

图1 M icroSpaceOS系统结构图

图2 微内核结构组成图

不同的功能模块、应用程序运行在不同的任务中，具有各自的堆栈和任务控制块.当任务相互切换时，会调用任务上下文切换函数，保存相应的上下文，并赋给要运行的任务一个全新的寄存器组.这样就保证了任务间的隔离，从而达到功能模块间故障隔离的目的.

1.3 任务间通信机制

在M icroSpaceOS的设计中，处于任务态的各个功能模块相互之间通过基于消息的通讯机制符合功能模块之间相互隔离的原则.将部分任务管理、信号量管理、中断服务程序、内存管理、队列管理等模块都作为特殊的任务，其他用户程序也是以任务的形式存在.例如:当应用程序1要使用内存管理模块中内存分配功能时，首先应用程序1发消息给内核，内核根据消息的接受者参数，将消息传递给内存管理模块的任务，此时内核挂起应用程序1的任务、恢复运行内存管理模块的任务.当内存管理模块完成内存分配功能的时候，将返回值以消息的格式发回给应用程序1，同样是发消息给内核，然后内核将消息传递给用户程序1的任务，挂起内存管理模块任务，恢复运行应用程序1.这样就完成了一个简单的内存分配请求，如图3所示.

图3 任务间通信机制

2 M icroSpaceOS的实现

2.1 任务调度机制实现

在M icroSpaceOS的实现过程中，考虑到增加了任务间通信机制，如果两个任务之间进行通信需要挂起一个任务，然后再恢复另一个任务，这就使得任务间频繁地进行任务调度和切换.考虑到这点，MicroSpaceOS只支持不同优先级的任务，不存在具有相同优先级的两个任务，这样就不需要维护同优先级就绪任务链表.这种优先级策略能满足大部分的应用需求.每个优先级下至多对应一个任务.就绪任务表分为两个部分:一个索引(Index)，一个就绪位图(Table)，如图 4所示

图4 就绪任务表

而就绪位图对应于一个存放任务控制块指针的任务数组，如图 5所示.在就绪位图上的每一位都对应数组中的一个位置.就绪位图上某一位为1，则对应于此位的任务数组中的任务就处于就绪态，否则任务不处于就绪态或没有对应的任务.当进行任务调度时，只需要通过修改就绪位图的某一位，并不需要将任务移入、移出就绪队列.在任务间通信机制中使用这种调度方式会节省不少时间，大大提高了任务间通信的效率.

图5 任务列表

2.2 内核的内存分配

在MicroSpaceOS的设计中，功能模块都是作为服务任务运行在用户态，所以在任务调度开始之前必须先创建这些任务，因此将任务创建函数放到内核中实现.在MicroSpaceOS的任务调度启动之前，首先需要通过调用内核中的任务创建函数，来创建内存管理、中断管理等服务任务以及用户自己创建的应用任务.

在任务创建过程中，会使用到内存分配函数.然而内存分配函数是运行在用户层的，如果内核直接调用任务管理模块中的内存分配函数就会使内核发散，当内存分配函数出现问题时会直接破坏内核的运行.如果是通过内核向任务发消息的方法进行调用内存分配函数，就会出现死锁:任务创建函数是为了创建任务;而任务创建函数又用到任务中的函数.这就出现了死锁问题，最后导致问题无法解决.

那怎样解决任务创建函数调用内存分配函数呢?一种方法是:为服务任务划分固定的内存区域，任务创建函数在创建任务时直接通过将内存区域分配给相应的服务任务，不需要使用内存分配函数.当创建应用任务的时候再通过基于消息的任务间通信机制调用内存管理任务中的内存分配函数.另一种方法是:将内存分配函数内嵌到内核中，即:在内存管理任务中有内存分配函数，在内核中也有内存分配函数，而内核中的内存分配函数只能够被内核调用，其他任务在使用内存分配函数的时候都是通过内存管理任务中的分配函数来完成的.

应该选取哪一种方法来满足任务创建时内存分配的要求呢?首先分析一下这两种方法的优缺点.第一种方法的优点:为服务任务划分固定的内存区域，并使用消息机制来调用函数，保证了任务间的隔离;缺点是:不能体现动态内存分配的好处，不能最大化地利用内存，任务创建函数代码量会增加，降低了内核的效率.第二种方法的优点:不损耗任务创建函数的效率，也达到了故障隔离的目的;缺点是:在内核中增加了代码量，增加了内核出现bug的风险.综上考虑，在 MicroSpaceOS实现中，采用的是第二种方法.采用第二种方法虽然增加了内核的大小，但考虑到对内核高效、可靠的要求，这部分代码量的增加还是值的.

2.3 任务间通信机制

MicroSpaceOS的各个功能模块及应用程序都是以任务的形式运行在用户层，它们之间相互间的通讯是通过基于消息的任务间机制.当任务间需要通讯的时候，它们只需要按照规定的通讯协议以消息的方式向微内核传递.应用任务和服务任务间相互独立，互不影响，如图6所示.

任务间通信机制是影响微内核成功与否的关键因素，如果任务间通信设计不好，将严重影响到微内核的效率.在前面介绍的将系统中的任务都设计成不同优先级的也主要是为了提高任务间通信过程中任务切换的效率.如图7所示，为了提高内核传递消息的效率，采用的是内核直接将位于任务1中的消息内容直接拷贝到任务2中去方式，这个过程消息的内容不经过内核层.一次消息传递过程中就只需要进行一次消息拷贝过程.

图6 任务间通信示意图

图7 消息传递过程示意图

基于消息传递的任务间通信机制中，大部分消息都是同步的，即:只有在接受双方都做好准备的情况下，消息内容才能够传输，否则，无论是消息发送方还是消息接收方都要进行等待，直到等待对方同意接受或者发送消息.这种设计的好处是保证了消息的安全性，只有经过双方认可的消息才能传输，非法的消息是无法进行传递，从而提高了整个系统的安全性.在考虑到某些消息是需要异步机制的，所以在设计的时候，预留了异步消息机制.

在任务间通信机制的设计过程中，考虑了几种可能存在的任务间通信的方式:

a)内核向任务发送消息;

b)任务发送消息;

c)任务接收消息;

d)任务发送完消息然后等待接收消息(多用于函数调用).

在这里不考虑任务向内核发消息，是出于对内核效率的考虑.当用户程序使用内核功能通过系统调用的方式，这可以提高效率.所以在设计任务间通信机制的过程中，没有支持任务向内核发送消息的功能.

任务间通信的几种方式是如何来区分的呢?如何区分任务是发送消息呢，还是任务接收消息呢?最简单的方式是提供多个函数，有的函数是只用来完成发送消息，有的函数是用来接收消息.但是这种方式会有个弊端:对用户开放的系统调用函数增多，就会造成系统可靠性的降低.如图8所示，在Micro-SpaceOS中采用的方式是只提供一个系统调用函数，通过传入的参数来判断是进行哪种通讯方式.

图8 任务通信机制中SYSTpc()函数流程图

2.4 功能模块任务化实现

上面介绍了任务间通信机制，功能模块是如何以任务形式运行的呢?首先，操作系统将赋予服务任务较高的优先级，应用程序赋予其较低的优先级，这种优先级分配策略是为了保证当应用程序在调用服务任务中函数的时候，被调用的函数能够保证尽快地得到运行.而服务任务是如何来设计的?下面将以内存管理模块来展示服务任务是如何设计的，如图9所示.

内存管理任务首先调用一个SYSTpc()先让内存管理任务做好接受消息的准备，然后挂起自己.当内存管理任务再次运行的时候，说明内存管理模块已经收到来自其他任务的消息，然后内存管理任务根据收到的消息来判断要进行哪个函数的调用;再根据消息内容中要调用函数的参数，由内存管理任务来代表消息发送者执行内存分配函数或者内存回收函数.当函数执行成功之后，内存管理任务再次调用SYSTpc()将函数的返回值以消息的方式传递给其他任务.

图9 内存管理模块流程图

内存分配函数和内存回收函数都是以常量MEMALLOC、MEMFREE的方式展示给用户的.应用程序只知道这两个常量、内存分配回收函数的参数使用方式和消息的格式.例如，当用户需要用的内存分配功能时，通过消息方式将 MEMALLOC、以及分配内存大小等信息以消息的方式发给内存管理任务，由内存管理任务来执行内存分配功能.这个过程中用户无法直接调用内存分配函数，更不知道内存分配函数的地址，如果用户程序出现故障就不会影响到内存管理任务，从而达到故障隔离的效果.

3 结 论

本文提出将功能模块以任务的方式运行，内核部分只提供任务间通信机制、调度等少量必需的功能.这种设计符合微内核的理念，很大程度上提高了系统的可靠性.在内核设计过程中充分考虑各种提高微内核效率的方法，在一定程度上弥补系统性能的损失.基于微内核的系统可以应用到航天、航空等对可靠性要求比较高的领域.下表1给出了目前星载嵌入式操作系统与MicroSpaceOS在设计实现上的区别.

表1 目前星载OS与M icroSpaceOS比较

［1］ 陈斐.L4微内核技术浅析［C］.第二届江苏计算机大会，南京，2006年11月

［2］ Liedtke J.On μ-Kernel construction［C］.The 15thACM Symposium on Operating Systems，Coper Mountain， Colorado，Dec 1995

［ 3 ］ Liedtke J.Toward real microkernels［J］.Communications of the ACM，1996，39(9):70-77

［4］ K lein G，Elphinstone K，Heiser G，et al.SeL4:formal verification of an OS kernel［C］.The 22nd ACM Symposium on Operating Systems Principles， MT， USA，Oct 2009

［5］ Klein G，Derrin P，Elphinstone K.Experience report:seL4-formally verifying a high-performance microkernel［C］.The 14thICFP， Edinburgh， Scotland， Aug 2009

［6］ Swift M，Annamalai M，Bershad B，et al.Recovering device drivers［C］.The Sixth Symp.on Oper.Syst.Design and Impl.， San Francisca， USA，2004

Design and Implementation of Microkernel-Based Satellite Real Time Operating System

XU Jian，YANG Hua
(Beijing Institute of Control Engineering， Beijing 100190， China)

All functionalmodules of Satellite Real Time Operating System are integrated into the kernel at present， leading to the enormous kernel and augmenting the bugs in the kernel， and the reliability of the whole operating system is decreased.A Microkernel-Based Satellite Real Time Operating System is designed and implemented in this paper， All functional modules run as tasks in user-level， all tasks are communicated by the Message Passing Mechanism to decrease the size of the kernel.Higher reliability is gained without obvious efficiency lost.Tests demonstrate that the design can achieve fault isolation.

microkernel;dependability;embedded operating system;fault isolation

V448

A

1674-1579(2011)02-0038-06

DO I:10.3969/j.issn.1674-1579.2011.02.007

2011-02-28

徐 建(1987-)，男，山东人，硕士研究生，研究方向为高可信操作系统 (e-mail:xujian20080808@163.com).