实时 *** 作系统在星载计算机中的应用

摘要：介绍在星载计算机中应用实时 *** 作系统的两种方式：使用一种源码开放的RTOS——RTEMS和自主开发RTOS，并对两种方法进行比较。

随着我国航天技术的不断发展，越来越多的卫星应用在通讯、资源探测、遥感、气象、对地观察等领域。卫星的功能越来越强，对星务管理和有效载荷控制的星载计算机提出了更高的要求。星载计算机软硬件系统日趋复杂，传统的星载计算机软硬件设计方法，特别是软件的设计方法和开发手段已逐渐不适应这种要求。引入实时 *** 作系统（RTOS）能够有效地解决这些问题。RTOS把任务管理调度、任务间通信、内存管理等系统功能以函数调用的方式提供给用户，使用户能够将精力放在应用程序的开发上，有助于星载软件通用化和模块化设计，缩短软件产品的研制周期，提高星载软件 可靠性。

RTOS已经成功运用在包括航天在内的许多嵌入式领域，如SJ-5小卫星就成功应用了pSOS *** 作系统。但这种无法获得源码的 *** 作系统，无法确定其安全性。因此应该选用源码开放的RTOS或者自己独立设计一种适合自身系统的RTOS。本文将介绍一种适合于航天应用，特别是面向关键任务（CriTIcal Oriented）的源码开放的RTOS——RTEMS；探索自己开发RTOS设计方法，并对两种方案进行比较。

1 星载计算机与星载 *** 作系统的特点

星载计算机是RTOS运行的硬件环境，了解其特点对于RTOS的选用和设计将更有针对性。星载计算机主要用于卫星的星务管理、数据处理、姿态控制以及对有效载荷进行控制等。根据空间环境、可靠性、安全性、寿命、功耗、重量等方面的要求，星载计算机应具有如下特点：

·硬件资源有限，受功耗、尺寸的限制，星载计算机只有有限的内存空间；

·CPU型号多样，但不属于通用型CPU，配套的调试工具少。从8位的8031到16位的1750A、8086，到32位的ERC32、80X86，不同的型号任务，不同的研制单位采用不同的CPU型号；

·需要考虑空间抗辐射能力，必须考虑单粒子翻转（SEU）和单粒子锁定（SEL）对星载计算机的影响；

·对安全性与可靠性要求高；

·需要具有在轨可编程功能，对在地面考虑不周和出现意外情况时，能有所补救。

针对星载计算机的这些特点，星载 *** 作系统也具有如下特征：

·微内核，由于硬件资源有限，因此星载RTOS必须做成微内核的 *** 作系统；

*可裁减，能够根据不同的应用对 *** 作系统进行不同的配置，做到量体裁衣，也能更充分地利用硬件资源，减少软件多余物；

·强实时性，星载系统都是强实时系统，对实现性要求很高；

·高稳定性与高可靠性；

·代码可固化，在现在的星载计算机中仍然采用PROM对代码进行固化，这就要求星载RTOS必须是代码可固化的。

2 采用RTEMS作为星载实时 *** 作系统

2.1 RTEMS实时 *** 作系统

RTEMS（Real-TIme ExecuTIve for MulTIprocessor Systems）实时 *** 作系统最初是美国军方为了实时导d系统而开发的。当时RTEMS的全称是：Real-Time Executive for Missile Systems。随着该系统功能的逐步完善，应用范围也从Missile扩大到Military，再到Multiprocessor，而形成现在的RTEMS。RTEMS从1993年开始开发，并于1999年开始地外开放源代码，并由OAR公司进行维护和升级。现在最新版本为4.6.0，在OAR的网站（www.oarcorp.com）上可以下载到相关资源。RTEMS由于具有开放源代码的优势，以及能与最优秀的商业RTOS相的性能，使得它最适合应用到星载计算机中。RTEMS有如下特点：

·支持多处理器；

·支持事件驱动和基于优先级的多任务实时系统；

·支持优先级同级调度，支持单调速率（RMS）算法；

·支持多种任务间通信与同步方法；

·支持中断管理；

·支持动态内存分配与管理；

·支持符合POSIX标准的文件系统；

·支持多种网络协议，RTEMS带有完整的TCP/IP协议栈，具有强大的网络功能；

·RTEMS提供了符合POSIX1003.1b标准，以及ITRON规范的API接口；

·RTEMS支持C/Ada语言；

·RTEMS现在能支持包括ERC32（欧空局用于航天项目的CPU）在内的11种类型的CPU（包括Motorola MC68K系列、ColdFire、Hitachi SH、intel i386、i960、MIPS、PowerPC、SPARC、AMD、A29K、HP PA-RISC）。

2．2 RTEMS的使用与开发方法

RTEMS的开发工具采用GNU的相关开发工具，但需要打上RTEMS的补丁。如编译器采用GCC，调试工具采用GDB。

当需要将开发完成的程序向硬件板卡下载时，还需要修改BSP板级支持包文件。BSP部分是与硬件相关的，把BSP作为单独的一部分是为了使RTEMS具有更好的可移植性。因为相同的代码，加上不同的BSP就可以应用到不同的CPU板上。

在调试程序时，可以先把串口打通，这样可以方便下载程序，也可以利用GDB工具或者它的图形界面方式DDD调试程序。方便软件的开发与调试。

采用RTEMS *** 作系统的开发方法，可以不用关心 *** 作系统内部如何实现多任务之间的协调工作等RTOS具体的技术细节，只需要按照RTOS提供的API调用系统服务即可。能够充分利用成熟的技术，快速开发星载软件。但也有一定局限性，RTEMS是属于比较复杂的RTOS，至少需要60KB左右的内存空间才能使系统运转起来。因此对硬件要求相对苛刻一些。而且有些CPU，RTEMS还不支持，如国内在航天领域常用的1750ACPU，RTEMS就不不支持。

因此，使用RTEMS有一定的局限性，当RTEMS不适合使用时，可以考虑自行研制星载实时 *** 作系统。下面以笔者开发的SAR-RTOS为例介绍星载实时 *** 作系统的设计。

3 星载实时 *** 作系统的设计

3.1 实时 *** 作系统内核的原理

实时 *** 作系统（RTOS）的核心是其内核。笔者认为：通用 *** 作系统的本质特点是硬件资源的管理者，而RTOS的本质特点是引入了多任务和实时性的保证。当然引入多任务也是提高实时性的一种方法。实时性的保证主要是靠任务调度方法和任务调度时机来决定。引入多任务相应地带来了任务竞争与同步、任务的切换等问题。而这些问题在现代 *** 作系统理论里已经有了比较完备的解决方案。

实时 *** 作系统内核原理，概括起来就是：引入了多任务，并且为每个任务分配自己的堆栈空间，由任务调度器来决定让哪个任务获得CPU。被挂起的任务把当前的CPU状态保存在自己的堆栈区中，获得CPU的任务把它被挂起时保存的CPU寄存器从堆栈区中恢复，这样新任务就从挂起时的状态重新执行，从而完成了一次任务切换。而信号量、消息队列、邮箱、事件等系统提供的服务是为了解决多任务间对资源的竞争以及任务间的通信和同步。它们的共同点是从实现的角度，有效为复杂的数据结构作支撑，而对于用户来讲用法很简单。例如信号量（Semaphore），建立好（Create）后，对其进行的 *** 作就只有等信号（Pend）和发展信号（Post）。

3.2 星载实时 *** 作系统的设计要素

（1）总体设计

星载RTOS的设计属于复杂的软件设计，因此应该按照软件工程规定的V型模型的开发方法实话开发。在总体设计中，应确定 *** 作系统的结构、支持的任务数、采用的调度方案、提供哪些系统服务等问题。在SARRTOS的体系结构设计中采用了将整体式和客户/服务器模型结合的方法。将它定义为四个层次：硬件层、硬件接口层、OS层和应用层，如图1所示。

（2）任务调度

为了保证系统的实时性，可以采用基于优先级的抢占式调度，也就是一旦更高优先级的任务就绪，就能获得CPU的使用权，使任务响应时间最短。SAR-RTOS中就是采和了这种调度方案，调度时间确定、速度快、实时性好。

    SAR-RTOS中关于任务管理的实现方法为：考虑到星载系统的ROM和RAM资源有限，为了保证SAR-RTOS的微内核性，将其设计为最多能支持64个任务。给每个任务赋予不同的优先级，以优先级为基础建立任务就绪表。当某个任务就绪时，将就绪表中相应位置位，执行任务调度时按照优先级矢量位图算法查找任务就绪表，找出最高优先级任务，执行任务切换。

任务切换需要完成以下工作，但需要注意的是执行任务切换属于临界区代码（不可被中断），必须关中断，切抽象完成后再开中断：

*判断需要调度的任务是否是当前正在运行的任务，如果是就不切换，避免不必要的切换，缩短CPU执行时间；

*将被挂起的任务CPU寄存器压入堆栈；

*将当前堆栈指针保存在即将挂起任务的任务控制块中；

*把高优先级任务的CPU寄存器从堆栈中恢复；

*将高优先级任务的任务控制块中保存的堆栈指针恢复；

*执行中断返回指令，让高优先级任务运行。

（3）任务管理

任务在RTOS中通常同时作为系统调度和资源分配的最小单位，也是用户编写应用程序的基础，对任务的管理是RTOS最基本的功能。对任务的管理内容包括任务状态的设计以及任务状态变迁的实现。在SAR-RTOS中任务的状态总共有四种，如表1所示。

表1 SAR-RTOS中的任务状态

运行态（Running）任务占有CPU，并得以执行的状态就绪态（Ready）任务已经具备运行的条件，等待内核调度阻塞态（Block）任务由于某种原因被迫放弃CPU的使用休眠态（Dormant）任务不具备争取CPU的使用资格的状态，也就是说不会被调度

任务状态的变迁如图2所示。

（4）任务间通信与同步

任务间的同步与通信是多任务 *** 作系统都需要解决的问题。实时 *** 作系统的核心就是要支持多任务的并发执行，相应地也就引入了任务与任务之间、任务与中断服务程序之间必须协调动作、相互配合的问题。即常说的任务间的同步与通信问题。所谓任务间的同步是指多个任务中发生的事件存在某种时序关系，必须协同动作、相互配合，以共同完成一个任务。任务间通信就是任务在运行时与别的任务进行信息交换。其实，同步本质上也是一种信息交换，是为了保证在正确的时间和条件下进行信息交换，使任务间不会产生混乱。在现场 *** 作系统中已经对任务的同步与通信有比较完备的解决办法。信号量以及事件机制等都是RTOS常用的同步机制，RTOS为任务间通信提供邮箱及消息队列等服务。

在SAR-RTOS中，提供的任务间通信的服务包括：消息邮箱（Message Mailbox）和消息队列（Message Queue）;提供的任务间同步的服务包括：信号量（Semaphore）和事件标志（Event Flag）。

（5）时间管理

RTOS由于其实时性，在系统运行过程中必须提供可靠的时间保证，因此RTOS通常都在硬件定时器的基础上提供系统时钟服务。每一个时钟滴答（Tick）就是一次系统的脉动，指挥系统各部分协调工作，因此定时管理是RTOS的基础。时间管理一般提供以下功能：

*管理日历时间和日期，有的系统也可以是相对时间；

*任务等候消息、信号量、事件的超时时间或者任务长期占用CPU的超时时间；

*在预定时间间隔或指定时间到达后唤醒一个指定任务。

（6）其它服务

内存管理和I/O管理，以及中断管理等服务不是系统必需的服务，可根据不同的应用需要决定是否提供上述服务，在SAR-RTOS中上述三种服务都提供。

（7）星载 *** 作系统的可靠性措施

星载软件的可靠性设计是关键，通常可以采用如下措施：

*将任务的重要参数以“三取二”的方式保存在任务控制块中；

*通过任务的状态检查，对检测不正常的任务进行相应的出错处理；

*采用看门狗技术，实现冷热启动的判定。当盾门狗启动后，从程序跑飞的地方自动往下执行；

*可以在内存中开辟一段系统内存区，定时将CPU环境和主要参数放入其中。

4 两种方法的比较

选用成熟的RTOS（如RTEMS）可以有效地缩短开发周期，代码质量可以得到保证；自行开发RTOS代码需要经过严格的测试，难度相对更大，开发周期更长。但可以根据需要增减相关功能，有更大的灵活性。如果使用RTEMS支持的CPU，那么推荐使用RTEMS作为星载软件的开发，毕竟RTEMS经过了十多年的验证，源代码公开也有几年的时间，这样的代码质量和可靠性应该是很高的。如果由于条件限制不能使用RTEMS，可以自行研制星载RTOS，但必须按照软件工程的开发方法，从设计、编程到测试，每一项都需要严格把关。

把RTOS引脚到星载计算机系统，能使星载软件从传统的单线程前后台系统转向多任务编程，不至于一个环节的失效就引起整个软件的失效，增加了可靠性。另一方面，使用 *** 作系统后，使星载软件的平台软件和功能软件分离，用户可以集中精力编写应用程序，提高开发效率。而且如果使用相同的RTOS，一些通用的模块或任务可以在不同型号继承和使用，提高软件的复用性。引入 星载RTOS将带来星载软件开发的一次技术变革。