基于Jetson TX2处理器的星载操作系统设计与验证

赵丽 李超 王冰 田帅虎 林博轩 徐婧瑶

(航天东方红卫星有限公司，北京 100094)

随着空间大数据在轨应用需求的日益增长以及人工智能技术快速演进，卫星使用智能化手段解决空间数据的应用需求越来越迫切[1]。为了使空间遥感数据更好地服务用户，开展支持卫星智能应用的操作系统设计和验证工作，有利于加快实现星载操作系统技术自主可控，推动卫星智能化程度的发展。当前主流的嵌入式系统有UCOS[2]、Vxworks[3]、Linux。UCOS为抢占式多任务操作系统，但缺少文件系统支持。Vxworks实时性强，为商业操作系统，不支持开源。Linux嵌入式系统，支持文件系统，代码开源，适配于多种处理器，兼容性强，且对于深度学习、神经网络等人工智能应用支持性较好。对于人工智能应用硬件处理平台，Nvidia Jetson系列处理器应用广泛，支持主流的并行计算平台和编程模型(Cuda)并行计算应用，尤其是NVIDIA Jetson Tegra TX2处理器功耗低、性能强。因此本文基于Linux系统进行在Jetson TX2硬件平台进行改进设计，形成适用于智能应用的星载操作系统。

国内有多位学者对星载操作系统进行了深入的研究，其中文献[4]对多核处理器的星载分区操作系统的调度方式进行研究，文献[5]对小卫星星载操作系统内核的实时性进行了研究，文献[6]对卫星星载操作系统的容错机制进行了研究，文献[7]对星载操作系统的安全机制进行了研究设计。这些研究成果重点关注星载操作系统的调度机制、实时性、容错机制、安全机制，但是缺少对Linux操作系统用于航天器的研究和工程验证。而深度学习、神经网络等人工智能应用深度依赖Linux系统，因此有必要开展基于Linux的星载操作系统专项设计和工程验证。

从当前国外行业Linux应用情况来看，国外龙飞船(Dragon)[8]、猎鹰火箭已经作为重要核心软件投入使用Linux系统，充分说明了Linux系统应用于复杂任务航天器的可行性和必要性。基于Linux操作系统的软件研制能够催生出代码完全自主可控的宇航系统软件，不仅有利于加快天基高速计算的推广应用，也必将有利于推动国家大数据服务体系的技术生态建设。

本文基于Jetson TX2处理器硬件平台上开展了Linux的星载操作系统的可靠性设计、高速传输设计、智能应用管理框架的设计及编码实现，并对星载操作系统进行了工程验证。通过开展面向智能应用的星载操作系统设计，可大幅提高卫星的智能应用水平，对于完成深空探测、星群协作、天基大数据服务等复杂宇航任务，具有十分重要的意义。

1 星载智能应用操作系统的设计与改进思路

空间环境相比地面环境较为恶劣和复杂，对操作系统的可靠性安全性有着较高的要求。在轨智能应用需要接收高速数据，需要操作系统具备强实时性的特征。另外，为了满足App上注、加载运行的需求，需要专门设计一套智能应用管理框架。当前的地面Linux系统多为单份启动，出现操作系统故障后没有自主恢复机制，而且在常规PCIE(PCI-Express)软件驱动方面不能实时匹配高速数据传输，因此需要针对星载操作系统开展专项设计和适应性改进，具体有以下3点。

(1)智能应用所需要的嵌入式系统为大规模Linux操作系统，启动流程包含了Uboot引导、Linux内核选择启动以及文件系统加载，启动过程较为复杂。为确保操作系统能够在复杂空间环境下正常启动，需要对星载操作系统的启动关键环节加强防护，以提升操作系统在无人值守环境下的可靠性。

(2)星载智能应用所运行的空间环境对高速数据的处理时效性要求更高，需要对操作系统所运行的CPU架构与高速数据传输流程综合考虑，增强操作系统的实时性，优化数据传输流程，从而提高遥感数据的传输速度。

(3)为了方便用户对星载操作系统进行智能应用的管理，需要设计智能应用的管理框架，实现对App的在轨管理模式。同时，为了促进星载智能应用的持续发展，增强操作系统生态建设，需要通过吸纳更多用户、参与者开发使用App，并不断拓展卫星数量、星座规模，最终成长为天基数据服务体系的重要组成。

典型星上操作系统如UCOS系统支持的硬件平台多以单核处理器为主，传输总线多以低速CAN总线、中速SpaceWire总线为主，并且对深度学习、神经网络等人工智能软件环境支持较差。Vxworks星上操作系统实时性高，但是属于商业操作系统，代码不支持开源。改进后的基于Linux内核的星上操作系统支持多核处理器的任务调度和并行计算，具备高速接口PCIE的数据传输功能，支持主流的人工智能软件运行环境及多种App的在轨管理运行，并且开放源码，代码自主可控。相对于典型星上操作系统，本操作系统在星上数据处理能力、星上数据传输能力、智能应用的管理能力上有很大优势。

2 星载智能应用操作系统的设计实现

2.1 星载智能应用操作系统设计架构

星载操作系统由系统底层、协议层、应用层3个部分组成，具体如图1所示。底层具有强实时和多内核冗余的特性，包括Bootloader与Linux内核。Bootloader采用引导软件Uboot，具有开源、硬件支持良好等优秀特性。Linux内核由实时内核和常规内核模块组成，实时内核采用RTLinux[9]实时调度模块，常规内核采用了稳定性和兼容性好的Linux4.9调度常规内核模块，这样可以满足实时任务和非实时任务不同等级的响应要求。

注：Cudnn为神经网络加速库；GDAL为空间数据转换基础库。

协议层支持动态更换基础库、软件高速上注、多文件系统冗余，从内容上包括自定义基础库、公用基础库、智能应用基础库、星载软件使用协议、文件系统。自定义基础库为第三方自行定义的库函数，公用基础库包含libc、libc++等常规C函数库，智能应用基础库包括Cuda[10]、Tensor[11]、Opencv[12]等，星载软件协议包括断点续传协议、高速上注协议、低速遥控协议、高速传输驱动，文件系统采用四份Ext4[13]文件系统进行备份。

应用层具有软件定义和软件动态重构的特性。应用层设计了智能应用管理框架，包括App生命周期管理模块、遥控遥测管理模块、数据库管理模块、容器管理模块。App生命周期管理包括App安装、App启动、App停止、App更新、App卸载。遥控遥测管理模块具备接收地面指令的功能，并对星上健康状态进行监控下传。App采用容器建立安全防护机制，数据库负责App数据的存储和记录。

2.2 星载智能应用操作系统改进设计实现

根据星载操作系统高可靠、高性能、生态优良、自主可控的需求，设计了Linux操作性系统多分区可靠启动策略、自主恢复策略、高速数据传输策略，并制定了智能应用管理框架设计方案。

2.2.1 多分区可靠启动策略与自主恢复策略

为了应对空间复杂环境可能引起的单粒子翻转导致数据错误问题，设计了Linux操作性系统“三取二比对启动”、“遍历内核启动”的可靠启动策略，并能够在操作系统被破坏的情况下进入“自主恢复模式启动”，完成内核与文件系统的覆盖恢复。

针对Linux系统的组成结构以及所在运行平台NVIDIA Jetson Tegra X2存储器的大小，进行多分区存储设计。NVIDIA Jetson Tegra X2存储器EMMC共32 GByte，存储了bootloader(Tboot、Cboot、Uboot)、Linux内核、Linux文件系统。由于NVIDIA厂商对Tboot、Cboot做了固化，只有Uboot、Linux内核、Linux文件系统所在分区可以修改，因此重新对Uboot、Linux内核、Linux文件系统进行分区设计。本设计方案Uboot存储一份，Linux内核存储4份(3份常规存储与1份备份存储)，Linux文件系统存储4份(3份常规存储与1份备份存储)，并对App分区单独划分一块存储分区。其中Linux文件系统存储分区大小为5 Gbyte，App分区存储大小为10 Gbyte。如图2所示，图中黑色箭头表示Uboot启动内核的过程，红色箭头表示内核挂载文件系统的过程，绿色箭头表示文件系统调用App分区的过程，蓝色虚线箭头表示备份分区恢复内核与文件系统的过程。

图2 多分区存储图

本操作系统设计了“三取二内核比对启动”、“内核遍历启动”、“自主恢复模式启动”3种方式。操作系统启动失败后会触发硬件看门狗，引起操作系统重新启动。如图3所示，“三取二内核比对启动”是操作系统上电后对三份内核进行“三取二”比对，比对成功则继续启动对应的文件系统完成启动流程。“内核遍历启动”是操作系统在上电后“三取二内核比对”失败后进入的启动方式，此时操作系统直接通过选择内核N(N=1,2,3)启动。如果“三取二内核比对启动”以及“内核遍历启动”3次启动后均启动失败，则进入“自主恢复模式启动”流程。自主恢复模式选择使用备份内核及备份文件系统对三份操作系统进行覆盖恢复，恢复完成后再次进入“三取二比对启动”方式。操作系统启动成功后，检测其他操作系统分区的文件标记，对于错误标记的操作系统分区使用备份系统恢复正常。

图3 可靠启动流程图

2.2.2 高速数据传输设计策略

为了增强操作系统的实时性，增加RTLinux实时内核的支持，使任务的进程调度延时和关中断延时大幅下降。在操作系统实时性的基础上，需要根据数据传输的流程进行优化，提高操作系统PCIE接口的数据传输性能。

对于PCIE高速数据传输设计了3种方式进行优化，分别是绑定专用CPU核、用户态内核态使用共享内存、传输数据双缓冲处理。首先，对PCIE高速数据读取模块绑定特定的CPU核，这样就减少了Linux操作系统调度CPU的时间，提高了PCIE数据的处理性能。其次，对于PCIE高速数据读取模块读取到缓存数据后，与应用层App交互时采用共享内存机制快速传输数据，减少了PCIE驱动内核态与用户态的数据拷贝时间。

另外开展了PCIE数据传输缓存数据的双缓冲区设计，如图4所示。

图4 PCIE图像读取流程图

以App读取图像数据为例，PCIE接口接收到图像数据后进行图像帧读取，当缓存1空闲时，PCIE将数据写入缓存1。此时如果有App读取缓存1数据，则将缓存1置为忙碌状态，App读取完数据时置缓存1为空闲状态。当有新的图像帧数据需要写入时，PCIE读取模块检测到缓存1为忙碌状态，则将读取的图像写入缓存2，并通知用户态App接收图像1。同理，当App读取缓存2的图像帧数据时，将缓存2置为忙碌状态，App读取完图像数据时置缓存2为空闲状态。由于当前操作系统仅允许同一个App读取缓存图像数据，所以PCIE写入模块寻找空闲的缓存区时不需要等待。这样既解决了App读写缓存数据同步的问题，又减少了PCIE的等待时间。

2.2.3 智能应用管理框架设计

智能应用管理框架包含App在轨全生命周期管理、App上注以及App应用方式。通过地面发送指令星上App可以完成整个生命周期的状态改变。App上注可实现地面完整上注、断点续传上注、增量文件上注。App应用模式包含容器应用和数据应用。本节对智能应用管理框架下App任务调度、动态加载、编译打包、资源访问机制进行了分析，同时给出了在轨上注的使用方式以及App的应用方式。

1)基于Linux实现APP任务调度、动态加载

智能应用管理框架设计了App遥控遥测进程、App管理进程，这两个功能进程长期在Linux系统后台运行。App遥控遥测进程负责进行地面指令的解析判断(如AppN安装、AppN启动、AppN更新、AppN卸载、AppN停止)与App状态的健康状态遥测下传。App管理进程负责接收App遥控遥测进程消息去执行不同的App任务。如图5所示，App遥控遥测进程通过套接字传递过来的方式通知App任务执行进程去执行不同的任务，App任务执行进程通过套接字进程通信的方式通知向App遥控遥测进程记录AppN的健康状态信息，并将App的状态信息进行遥测下传。

图5 App任务调度

App管理进程接收到App指令接收进程的消息后，根据消息的种类分别进行了线程创建、进程创建、消息队列创建。接收到AppN安装的消息后，创建AppN安装线程，执行App安装功能；接收到AppN启动的消息后，由于各个App需要有独立的存储空间，所以创建AppN启动进程，执行App启动功能；接收到AppN更新的消息后，创建AppN更新线程，执行App更新功能；接收到AppN卸载的消息后，创建AppN卸载线程，执行App卸载功能；接收到AppN停止的消息后，为了考虑节省资源消耗，采用创建消息队列的方式，将AppN停止的动作加入消息队列，按照先后顺序分别执行多个App的停止功能。从而App管理进程完成了多个App的任务调度和动态加载、卸载。

2)App编译打包过程

用户在地面完成App编译过程。如图6所示，App由总线数据、计算模型、可执行程序、缓冲区、程序区、配置数据等文件夹组成，文件夹里面分别存放对应的文件。用户代码编写完毕之后，由SDK工具包按照App开发实例和App编译指南，在开发机x86 Linux环境下由交叉工具编译链进行交叉编译，生成可执行程序文件。最后由SDK开发工具包进行App打包，从而完成App的地面制作。App注入到星上后，由Linux系统按照进程进行资源调度。

图6 App地面打包过程

3)App资源访问、独立运行机制

对于多个App访问资源，为了避免App对资源访问冲突的问题，App管理进程对特定资源访问设计了锁机制，当一个App进行该资源访问时，进行加锁操作。这样在当前App进行资源访问时，其它App无法进行资源访问，直到当前App资源访问完毕解锁操作后，其它App才能进行资源访问。

为了保证App进行图像数据处理后发送出各自独立的数据，App发送接口采用加锁操作。如图7所示，当一个App发送处理结果数据时，进行加锁操作，这时其它App发送处理结果时就要等当前App发送完毕解锁后再进行发送操作，从而避免了发送数据乱帧的现象。

图7 App资源访问锁机制

对于同一个App的安装、启动、停止、更新、卸载，App管理进程对同一个App的这些动作设计了线程加锁处理，保证每个动作完成之后再执行其他动作，如图8所示。当收到AppN的安装动作时，去获取AppN的线程锁，若没有该App的其它动作，则能获取成功，则执行该App的安装操作。当该App正在安装时，收到该App的启动操作，AppN取获取线程锁。由于AppN在安装过程中，还未释放AppN的线程锁，因此App启动的指令需要等待App安装完成之后执行。

图8 多个App锁机制过程

4)App在轨上注模式

操作系统支持用户发送指令数据进行App在轨上注与在轨管理，包含“进入上注模式”、“开始App高速上注”、“结束App高速上注”、“退出上注模式”、“AppN安装”、“AppN启动”、“AppN停止”、“AppN升级”、“AppN卸载”，指令码字设计见表1。

表1 App管理指令

星载操作系统接收地面注入的App完成在轨上注。上注的方式分为整体上注、断点续传上注、增量文件上注。对于占用空间较小的App，可以在卫星过境时间内完成整体上注。如果卫星过境时间内App无法完成整体上注，则可以选择断点续传上注，等卫星下次过境时再次上注。对于只需要改变App的某个配置文件或增加一个脚本文件，可以选择增量文件上注。

5)App的应用方式

为了减少App与操作系统的耦合性，设计了容器应用模式，App出现异常时，不会影响操作系统的正常运行。用户上注的App首先进入到测试容器环境中，经过规定时间验证正确后再执行在轨任务。

传统星载操作系统受限于存储空间和CPU的性能，使用文件系统较少，遥测数据多存储在内存中。基于Linux的星载操作系统支持文件系统，对于数据存储读写，可以使用数据库存储数据供在轨任务使用。数据库可存储多种遥测数据，包括实时遥测、延时遥测、重点遥测，为星载样本训练、自主健康管理、行为预测等智能应用提供了便利手段，解决了卫星难以实现长期有效数据分析的难题。

3 星载智能应用操作系统验证情况

3.1 验证方案及验证环境

根据航天器在轨数据实时计算任务对Linux操作系统的测试需求，搭建了星载操作系统单机测试环境。由于NVIDIA Jetson Tegra X2硬件平台具备性能高、功耗低的特点，因此本验证环境单机采用由四核NVIDIA Jetson Tegra X2模块组成的电性产品。其它硬件测试环境还包括地检设备及稳压源。软件测试环境包括操作系统组件(部署在星上)、部署地检设备(Ubuntu1804)、Linux测试平台(LTP)开源测试套件，见表2。

表2 验证环境

3.2 验证测试情况

该星载操作系统运行在单机测试环境，进行了可靠启动、高速数据传输的比对测试、智能应用的管理测试、操作系统的压力测试。

1)可靠启动策略与自主恢复策略测试

根据可靠启动及自主恢复机制的设计思路，分别进行了正常启动、故障注入测试。同时，针对操作系统应用程序的内存泄漏进行可靠性测试。测试结果见表3。

表3 可靠性测试项目及结果

2)高速数据传输测试

该高速数据传输测试中PCIE选用2.0版本，如图9所示，斜线图为改进前的PCIE驱动的传输速率，灰色图为改进后的PCIE传输速率。改进后的传输速率平均值为8.36 Gbit/s，改进前传输速率为6.08 Gbit/s，传输速率提高了37%。

图9 PCIE传输比对表

3)智能应用管理框架测试

对智能应用管理框架进行了App上注、App管理、数据库应用、软件重构的测试，见表4。App上注对上注数量和上注方式进行了测试，并对App的管理功能(安装、启动、停止、更新、卸载)进行了验证。数据库应用测试采用SQLite工具，测试了空间遥感数据的插入、删除、更新、查询功能。软件重构功能完成了应用程序和配置文件的更换测试，应用程序包括遥控遥测模块、App管理模块，配置文件包括App配置文件、操作系统配置文件。

表4 管理框架测试

4)压力测试

对操作系统通过Linux测试平台(LTP)测试环境进行压力测试，可以获取到资源利用率的情况。本测试选择8点到22点之间共8个时间段的测试结果，如图10所示。

图10 进程负载情况

从图10测试结果可知，用户进程负载、内核进程负载、IO进程负载、空闲进程负载、内存占用情况。其中系统运行时用户进程最大CPU占用率为96.05%，内存最大占用为76.2%，系统运行稳定。

4 结束语

本文从星载智能应用的可靠性、安全性、好用易用性需求出发，对Linux进行改进设计。经过单机功能性能测试及整星各个阶段的工程验证，改进后的星载操作系统的功能性能提升明显，满足了工程预定目标。设计的星载操作系统对整星数管系统的星上数据处理能力、星上数据传输能力、星上智能化应用模式都有较大整体性促进作用。对于高算力硬件平台，基于Linux内核的星载操作系统通过多核调度和并行计算，提高了数管系统的星上算力水平和数据处理能力。改进后的星上操作系统可支持PCIE接口高速传输数据，提高了数管系统的数据传输性能和数据吞吐量。在软件重构功能上，改进后的星上操作系统支持多种智能应用的上注与在轨管理，实现了数管系统软件定义卫星的理念。

本系统基于NVIDIA Jetson Tegra TX2处理器平台和Linux开源操作系统，开展支持卫星智能应用的操作系统设计，具有自主可控、兼容性广泛、轻量化、普适性强的特点。基于Linux开源分支进行改进设计，代码自主可控。本操作系统除了适用于NVIDIA Jetson Tegra TX2处理器，也可兼容NVIDIA Jetson Tegra系列的多种处理器平台。经过裁剪，本操作系统去除应用基础库占用大小为52 Mbyte，适用于多种智能应用场景，为多种智能应用提供了一个平台。下一步将开展星载操作系统人工智能应用、并行计算的研究，使得操作系统能更高好的发挥应用效能。