嵌入式实时操作系统在运载火箭中的应用研究

宋征宇

北京航天自动控制研究所，北京100854

1 概述

嵌入式操作系统是否适合运载火箭飞行控制的应用，一直存在不同意见。一种观点认为，现有的“中断+循环”的运行方式能够满足任务需求，而采用操作系统会增加软件的复杂性，软件应越简单越好。而随着技术发展，飞行软件发挥的作用在增加，因为能简化硬件设计，并增加系统的灵活性，因此在传统控制功能外增加了诸如故障诊断与重构、总线通讯、数据管理等功能，同时数字化导致智能设备增多，多任务的特点愈发明显，操作系统的研究开始受到重视。

操作系统在国外航天器中已经得到了应用，如美国［1－3］火星探测、彗星撞击以及运载火箭等均有采用，类型包括了VxWorks，ThreadX 以及早期的RTEMS 等。国内航天系统也开展了操作系统的研究［4］，但还未形成广泛的应用，尤其在运载火箭领域。在航空系统，相关研究所与美国Wind River 公司在上海联合建立了“嵌入式实时操作系统应用开发实验室”，用于推广操作系统的应用［5］。本文将结合我国运载火箭的实际情况，对是否需要操作系统、如何使用操作系统等问题进行探讨。

2 飞行软件的现状及操作系统应用优劣分析

2.1 飞行软件的发展

早期的飞行控制软件，主要从事制导计算，属“计算型”的软件。随着数字控制方案的普及，机电式程序配电器等设备逐渐被电子式时序控制器替代，飞控软件增加了分离、调姿等控制功能，软件发展为“计算+控制”型，但控制功能相对简单，主要是固定时间间隔的指令控制，上述情况下由于功能以及速度等的要求，均未采用操作系统。随着载人航天工程的发展，各种冗余设计技术广泛采用，软件在故障检测与管理中发挥了重要作用，这部分代码量开始增加。回顾过去展望未来，软件的发展面临着以下情况:

1)硬件接口种类增多，且有智能化的趋势

接口智能化，意味着主处理器与接口电路之间不再适用单条I/O 指令的控制，存在着通讯、应答以及时序要求，响应时间也不再是确定不变的，取决于智能接口当时的状态。

2)有优先级要求的中断和任务增多

各个智能设备按自身的节拍来工作及通讯，整个系统本质上是异步的。为了保证对各设备控制的实时性，中断会逐渐增多。同时，信号的重要程度有优先级之分，原有多数任务顺序执行的基础已不再存在。

3)软件配置项之间的交互增多

数字化带来软件配置项大增，要保证软件间信息交互的完整性、同步性和实时性，避免资源的冲突和死锁等。

4)故障诊断的工作量增多

软件在冗余系统中发挥重要的故障诊断工作，但增加了软件的复杂性，降低了软件固有可靠性。

上述4个方面均导致软件复杂度和代码量增加，并又带来了以下2个方面的特点:

1)传统飞行控制代码量所占比例70%以下

I/O 管理、冗余管理、总线通讯等非传统的飞行控制代码量达到或突破总量的30%。

2)传统飞行控制代码的测试用例数量所占比例50%以下

以某软件为例，采用“中断+循环”模式，只统计圈复杂度超过10 和扇出数大于7 的模块，因为这些模块基本决定了测试用例的分布，如表1 所示。

表1 某软件静态分析结果及测试用例统计

表1 中前3 项在圈复杂度所占总数达到了38.17%，扇出数所占总数达到了83%，这意味着将有大量的测试用例花费在这些功能上;而另一方面，计算模块路径单一，例如，18个通用制导计算模块以及22个姿控计算模块中的20个，圈复杂度均低于10。从实际测试用例数量上看，与控制功能密切相关的测试用例只占53.22%。

以上分析虽是一个具体的案例，但具有代表性。进一步考虑未来应用，诸如上面级长时间在轨飞行等，故障恢复、并行处理等需求会逐渐增加，非传统控制功能的代码量和测试用例所占比例还会增多。鉴于此，本文将上述6个特征作为采用操作系统的基本前提条件。

2.2 操作系统的优劣分析

随着硬件产品性能的提高，操作系统的大小及对运算速度的影响等因素不再显得那么突出，评价其优劣的主要出发点还是对软件可靠性的影响。从这方面其优点有以下几方面:

1)能够显著降低软件质量问题

根据控制系统2006 ～2011年的不完全统计，软件典型质量问题分布如下表所示。硬件初始化、I/O的管理、中断管理、共享资源的管理等均是较为适合操作系统完成的工作，如果操作系统是成熟的，将会显著降低上表中“初始化”、“中断使用错误”、“接口不匹配”、“并发与竞争类错误”等问题的发生，这类问题占目前总质量问题的49.1%。

表2 软件典型质量问题分类及分布

上述问题的主要起因，是由于不同项目组重复开发，设计经验与教训没有得到充分利用，既浪费资源，也带来众多质量风险以及测试验证工作。如果用操作系统来统筹上述功能，将能减少这些错误的发生，同时更多型号的应用能够进一步提高操作系统的成熟度。

2)提高软件的重用度

操作系统自身的功能不用重新开发(当然可能会随着硬件的变化进行增补)，这体现了重用的一方面;另一方面，操作系统还能使应用软件实现对底层硬件的不相关性，促使飞行软件设计人员将各种算法的编程与其他功能很好地剥离出来，降低不同功能之间的耦合性，有利于重用。此外这也可以减少“平台相关错误”，与前述统计合计，操作系统可以解决的问题已超过了问题总数的50%。

3)分散技术风险

传统飞行软件的功能和风险将由应用软件和操作系统共同承担;随着操作系统设计的专业化、广泛的推广应用以及成熟度的不断提升，这部分的风险也在降低，从而分散和降低了技术风险。

上述分析的出发点均是在操作系统已较为成熟的基础上，否则其自身仍然存在表2 所体现的各类问题，例如，操作系统底层硬件驱动的初始化问题、接口不匹配问题，中断处理考虑不周等。此外，由于我国在自主设计操作系统方面的技术积累仍较薄弱，其劣势还体现在以下方面:

1)操作系统的成熟度还不高，影响了其自身的质量和推广;

2)操作系统与应用软件的界面不够清晰，增加了编程的复杂度;

3)操作系统还不能以通用化的产品来满足各类应用，这增加了定制的工作量及技术风险。

3 操作系统的基本功能

3.1 典型应用对象介绍

在介绍操作系统功能前，先对其应用对象进行简要介绍。图1(a)是较为典型的三冗余箭载计算机的功能框图，飞行软件通过1553B 总线完成惯组信息的录取与关机指令、姿态控制指令的发送。软件的运行过程如图1(b)所示，主功能为20ms 周期任务，录取惯组信息、进行同步处理、开始控制运算，并将控制指令通过总线发送到执行设备。当接近有效载荷分离时刻，为提高关机控制的精度，启动1ms中断，在1ms 任务中实现关机控制。

3.2 操作系统的基本功能

综合国内关于航天器操作系统的研究［6－8］，可以梳理出操作系统最基本的功能，分以下几方面:

1)初始化功能，含初始化后的自检功能

初始化工作确保各接口电路处于安全的初态，自检结果要传输到测发控系统的监控终端。

2)I/O 管理，包括内部与外部各种接口

向飞行软件提供统一的、与设备无关的用户接口，实现对底层硬件设备的安装、创建设备驱动，以及设备使用过程中的打开、关闭、读、写、控制(扩展)等操作。以本项目为例，包括1553B，ICU，MSU(RS－485，RS －422)，BMU，DRU 等设备以及扩展的三机同步信息交换等。

图1 飞行软件运行环境及流程示例

3)故障与设备状态管理

对箭上各类设备的状态进行管理，向飞控软件提供故障检测、设备状态维护、查询等功能，涵盖CPU，I/O 设备以及系统自定义功能3个层面。对绝大部分智能通讯接口而言，是否通讯正常可通过其控制字或状态字来判别，这类故障的诊断可以不用应用软件参与(当然，对于惯组数据的合理性判断，仍只能由应用软件来完成)。上述功能将在下面作重点介绍。

4)中断管理

5)任务管理

6)其他必需的辅助功能，指一般操作系统均必备的基本功能，包括上述5 项功能中可能用到的支撑技术，如任务和二值信号量管理功能、计时管理、内存管理功能等。

3.3 故障与设备状态管理

随着对可靠性要求的提高，冗余设计的复杂性也在增大，故障检测、隔离与重组(FDIR)的代码量不断增大。这部分工作可以由操作系统和应用软件共同完成，其中，利用操作系统完成故障检测与隔离，由应用软件实现故障后的重组，既统一且明确了操作系统与应用软件的界面，也可以缓解飞行软件的复杂度。故障的检测往往采用硬件设备提供的各种状态检查功能，或冗余部件的相互对比，从而实现故障定位(隔离)，这部分功能可以集成在底层硬件驱动函数中。而故障的重组因故障类型而异，在很大程度上属于系统设计范畴，这部分功能设计在应用软件的接口处理函数中。

3.3.1 通用设备状态管理

通用设备状态管理模块为飞控软件提供统一的设备管理架构，如图2 所示，其工作包括:

1)注册设备状态观测字;

2)定义设备状态观测字的阈值;

3)定义阈值超限时的处理函数接口，操作系统可以提供缺省的处理函数，用户也可以重新定义，尤其涉及系统层面的故障重组时;

4)定义处理函数的触发模式，如果是轮询触发模式，则作为一个低优先级的任务，周期性地轮询该观测字，并在满足条件时触发处理函数;如果是立即触发模式，且在该观测字达到设定的阈值时立即调度处理函数。

采用上述机制，基本满足了各种故障(异常)的处理要求。

图2 通用设备管理原理图

3.3.2 CPU 异常检测与处理

CPU 异常是严重的错误，由于火箭飞行时间短、实时性强，且没有遥控功能，一般在CPU 异常后难以采取诸如复位等故障恢复措施，只能靠硬件的冗余来达到容错的目的，因此，飞行中CPU 的异常是要尽量防止的，其异常检测与处理更多的是为后续避免此类问题和查找原因提供足够的信息，其处理流程一般如下:

1)首先使系统进入安全模式，例如测试模式，避免异常的扩散或复位;

2)在预定义的地址中记录异常发生时的指令寄存器、故障状态寄存器、故障地址寄存器、复位和错误状态寄存器、测试控制寄存器、系统软件的执行路径、健康状况等信息;

3)为不立即复位的异常进行计数，提供异常状态字，并提供查询函数接口;

4)通过邮箱向外发出第2)和3)项的信息;

5)如果用户注册异常处理函数则调用执行，否则退出。

CPU 的异常因处理器而异，一般包括复位、取指出错、非法指令、不使能FPU 时使用浮点指令、协处理器未使能异常、内存地址不对齐访问、FPU 异常、可校正的EDAC 错误异常、数据访问异常等。不管用户是否新注册处理函数，上述步骤1)～4)均要执行。

3.3.3 I/O 的异常检测与处理

按照3.3.1 节的介绍完成注册和处理函数的设计，在I/O 的操作中更新状态观测字，主要依据各I/O 驱动的状态字或控制字来进行诊断;当设备状态管理模块判断观测字超阈值时，激活处理函数。处理函数可以由操作系统提供缺省处理方式，也可以用户定义，这也主要通过重新设置I/O 驱动的控制字或状态字来实现，由此可见，故障与设备管理与I/O 管理要配合使用。

例如，当1553B 故障时，可以在A 通道重发;重发若不成功，则切换到B 通道再重发。如果重发次数达到阈值，通过处理接口函数直接设置在B 通道发送;如果B 通道再次发生故障且达到阈值，则可以通过处理函数设置错误标志并直接返回。但后续也可以根据需要重新激活相关设备。

3.3.4 系统级的异常检测与管理

在所有故障中，CPU 的故障是处理器事先定义的，其故障处理以中断形式触发;I/O 的故障可通过接口电路的各种寄存器或状态字来查询，其故障处理通过I/O 管理来实现。上述2 类异常处理操作系统可以不需要应用软件参与独自完成。但还有一些异常无法直观地通过硬件自身来诊断，属于系统冗余管理的范畴，也可以结合操作系统来实现，本文以时钟故障检测与处理来举例说明。

时钟故障导致计时基准产生很大偏差，导航计算以及时序控制均会出错。仅靠本机的计时器是无法判别故障的，但可以利用各种总线通讯信息中所带的时标信号进行对比，例如，当前后2 次总线通讯自带时标的时间差与此段间隔内计时器的计数值不一致时，说明存在故障;用1553B，485，422 等多种总线消息中的时标进行多数表决可定位故障，并更新观测字。而定位出时钟故障后具体如何处理，可以由系统设计人员编写特定的处理函数并在设备状态管理中注册。

4 操作系统的应用

与“中断+循环”不同，对操作系统使用方式不同，产生的应用效果也不同［9－12］。本文首先针对3.1节介绍的应用对象，提出了飞行控制软件的基本架构，尽管只用到了操作系统最基本的功能，如任务调度，但在解决不同优先级任务的资源冲突方面已体现出了优势，本文以示例进行说明。

4.1 飞行控制软件的基本框架

操作系统在飞行控制软件中的主要应用，是将传统的中断服务程序转化为多任务管理［13－15］。本文也给出了一种利用操作系统划分多任务的飞行软件功能框图，如下图表示。

图3 基于嵌入式操作系统的飞行软件功能示意图

图中深色方框内的任务属于应用软件的范畴，浅色方框表示的是外部中断，其他功能均属于操作系统的范畴。其中任务的优先级可以有不同的设置，任务本身还可以根据需要进一步细分。

通过中断激发一个“任务”，该任务可以看作是传统的中断服务程序。将传统中断服务程序中的功能划分为多个优先级的任务，例如“控制任务”优于“遥测任务”，可以解决20ms 周期计算余量不足的问题。即若在某一个周期20ms 遥测任务超时，下一中断产生后20ms 控制任务会抢占运行，关键任务不会受到任何影响。20ms控制任务运行结束，任务切换回20ms 遥测任务继续执行。

“任务”由“中断”激发，这些都在操作系统内核的调度下完成。软件对硬件接口的控制，均通过操作系统调用驱动实现。操作系统在进行具体I/O 操作时，会同步完成对个接口功能的检测，如故障则将更新该设备的错误计数器。当达到阈值且该故障模式被设置为“立即触发”时，立即激发用户在初始化时注册的故障处理程序，这也将被作为一个“任务”来调度;用户也可以将该故障模式设置为“轮询”，则由操作系统的一个低优先级任务轮询到超过阈值时触发，或者由应用软件通过查询故障计数器并自行决定如何处理。

操作系统的使用是较为复杂的设计，不同的设计方案使得操作系统和应用软件发挥的功能不尽相同，限于篇幅，本文以共享资源的管理介绍如何发挥操作系统的作用，其他内容不一一涉及。

4.2 共享资源管理的示例

4.2.1 因共享资源而带来的不同步

在存在多个中断的系统中，每个中断可能对同一硬件进行操作，存在共享资源的管理问题。当低优先级的中断占用资源时，即使高优先级的中断被触发，也无法强制接管该资源，并会影响到多机冗余系统的同步性。以图4 为例，1ms 中断优先级高于20ms 中断。在20ms 中断中需要通过1553B 总线采样惯组数据，并进行三机的同步处理;而在1ms 中断中，当需要关机时，通过1553B 总线将关机信号发送到综合控制器实时关机控制。在这过程中，2个中断程序均会对1553B 总线进行控制。

图4 共享资源管理示意图

三机按各自时钟工作，仅20ms 中断是三机同步产生，但此时每个CPU 当前正在执行的指令(PC值)存在若干个指令周期误差，加上三机的1ms 中断源未进行同步处理，因此1ms 中断发生的时间点相对于当前指令之间会存在微秒级的偏差。

在图4(a)中，假设CPU3、CPU2 运行速度较快，完成了20ms 任务中的1553B 总线录取工作，此时1ms 中断到来，进入1ms 中断处理，并通过1553B 总线发送关机指令;1ms 任务结束后，返回20ms 中断继续处理，并发出同步控制指令。而对CPU1 而言，当1ms 到来时，20ms 任务中的1553B 操作还未结束，尽管1ms 优先级高，但总线资源被20ms 任务占用，于是切换至20ms 任务，待1553B 总线资源释放后，再重新切换回1ms 任务，完成总线控制;待1ms任务结束后，再返回20ms 任务，并执行后续的同步控制。从图中可以看出，由于CPU1 多增加了两次任务的切换，导致CPU1 发出同步控制时已严重滞后于CPU2 和CPU3，在某些场合，这种不同步是不允许的。

4.2.2 多任务管理

前文没有区分中断与任务的概念，中断只负责计时并唤醒任务，而任务实际上是传统的中断服务程序，将中断与中断服务程序(即任务)区分开是避免中断长期占用资源，增强响应的实时性。因此，将图3 中“任务”继续细分，例如将20ms 控制任务分解为总线录取与同步任务TSK_20_BUS_SYN 以及导航、制导与控制任务TSK_20_CTL。1ms 中断ISR_1唤醒1ms 任务TSK_1_BUS，20ms 中断ISR_20唤醒TSK_20_BUS_SYN 和TSK_20_CTL，优先级从高到低依次为:

ISR_1;

ISR_20;

TSK_20_BUS_SYN;

TSK_1_BUS;

TSK_20_CTL。

以图4(b)为例，尽管1ms 中断在TSK_20_BUS_SYN 的不同时刻到来，但因为1ms 中断唤醒的任务TSK_1_BUS 优先级低于TSK_20_BUS_SYN，该任务不会被打断，进入同步区间时基本没有偏差;在完成TSK_20_BUS_SYN 任务后，切换至TSK_1_BUS任务，此时总线资源已经被释放，不存在冲突;TSK_1_BUS 任务完成后，进入TSK_20_CTL 任务。图3(a)中CPU1 多增加的2 次任务切换得以避免，三机基本上仍能保持同步。

上述任务分级的另一个好处是，总线被占用的时间最长为TSK_20_BUS_SYN 任务的时间，远低于传统编程中20ms 中断服务程序的时间，这提高了关机的时间精度。

5 结束语

回答是否需要操作系统，应用发展的眼光来看，例如，如果软件还停留在简单计算型的应用，确实不需要操作系统;从简单计算型发展到“计算+控制”型，软件的功能增加了，采用中断也能处理。而未来的应用，已显现出计算密集型、控制多样性和信息集成化的特点，此时就必须有专业的操作系统支持。计算密集型会带来并行计算的要求，控制多样性使得多任务的需求愈发迫切，而信息集成化则赋予了控制系统更多的职责，可能用“信息系统”来描述原有概念上的“控制系统”更为适合。在这种背景下，应适时地开展操作系统的应用研究，基础性的工作要提前打牢。

本文提出了可以考虑采用操作系统的6个条件，以某飞行控制为对象，对操作系统在故障与设备状态管理、共享资源管理中的作用进行了较为深入的分析。可以看出，即使采用同样的操作系统，不同的使用方式也会产生不同的使用效果，那些较为合理的设计，能够简化应用软件的复杂性，使得应用软件更能专注于飞控的核心功能。而随着操作系统成熟度的不断提高，整个软件系统的可靠性也随着增加，操作系统的作用将能得到真正的体现。

［1］EDN China. 风河为NASA 运载火箭提供操作系统［EB/OL］. http://www. ednchina. com/ART_76375_29_20026_NT_363ff7f9.HTM，2009，12，23.

［2］EDN China. 美国撞击彗星计划揭密ThreadX 实时操作系统担当重任［EB/OL］. http://www.ednchina.com/ART_8985_29_20023_NT_b8f86eea.HTM，2005，8，9.

［3］EDN Chian. NASA 好奇号火星车安度”恐怖7 分钟”，Wind River VxWorks 再建奇功［EB/OL］.http://www.ednchina.com /ART_8800507449_29_20026_NT_91cc6927.HTM，2012，8，7.

［4］程胜，蔡铭.航天高可靠嵌入式实时操作系统原理与技术［M］.中国宇航出版社，2012，8.

［5］EDN China (EDN China 电子技术设计网站).风河与中国航空无线电电子研究所成立联合实验室［EB/OL］. http://www. ednchina.com/ART_53867_20_0_NT_facc8737.HTM，2008，12，30.

［6］乔磊，彭飞，赵玮，孙越，杨桦，刘波.航天器嵌入式操作系统研究与设计［J］.空间控制技术与应用，2011，37(5):31-35，41.(QIAO Lei，PENG Fei，ZHAO Wei，SUN Yue，YANG Hua，LIU Bo. Aerospace Control and Application，Embeded Operating System Research and Design for Sapcecraft［J］. Aerospace Control and Application，2011，37(5):31-35，41.)

［7］杨牧，王昊，张钰，郑伟，郑阳明，金仲和.抗辐射加固的皮卫星用实时操作系统设计［J］. 浙江大学学报(工 学 版)，2011，45(6)，1021-1026. (YANG Nu，WANG Hao，ZHANG Yu，et al. Design of Radiationhardened Real-time Operating System for Picosatellites［J］.Journal of ZHEJIANG University(Engineering Science)，2011，45(6)，1021-1026.)

［8］李林，王向晖，陶利民，张猛.航天器用实时操作系统设计［J］. 计算机测量与控制，2012，20(4):1026-1028，1032. (LI Lin，WANG Xianghui，TAO Li，ZHANG Meng. Type of Reali-Time Systems Designing Which Applied in Aeroships［J］.Computer Measurement＆ Control，2012，20(4):1026-1028，1032.)

［9］刘锡祥，徐晓苏，冯丹琼，刘建娟. VxWorks 环境下捷联惯导系统的软件设计［J］，中国惯性技术学报，2006，14(2)，1-4.(Design of Software Structure of SINS on VxWorks［J］.Journal of Chinese Inertial Technology，2006，14(2)，1-4.)

［10］李化云.嵌入式实时操作系统在航天器软件中的应用研究［J］.微计算机信息，2012，(8)，73-74.

［11］冉汉政.嵌入式实时操作系统μC/OS 在控制工程中的应用［J］.现代电子技术，2003，(13):84-86. (Application of μC/OS in Controling System［J］.Modern Electronics Technique，2003，(13):84-86.)

［12］胡剑华.基于ARM-LINUX 实时嵌入式飞行控制系统设计与实现［D］.南京航空航天大学，2010.

［13］雷杰，文顺安.嵌入式实时多任务操作系统在强实时系统中的应用［J］. 战术导弹控制技术，2002，(4)，37-40.

［14］刘宗玉，王玮，陈明，田洪波，综合导航系统中的实时多任务软件设计［J］. 计算机工程与应用，2004，40(27)，185-187. (LIU Zongyu，WANG Wei，CHEN Ming，TIAN Hongbo. Design of Real-time Multitask Software of Integrated Navigation System［J］. Computer Engineering and Applications，2004，40(27)，185-187.)

［15］曹宁.组合导航系统中实时多任务的软件设计［J］.导航，2007，(2)，35-40.