CN111813561A - 一种开放通用的智能卫星软件体系架构 - Google Patents

Abstract

本发明公开一种开放通用的智能卫星软件体系架构，实现卫星快速设计及制造，有利于卫星实现星间资源共享。架构最低层是卫星的硬件资源，向上第一层是操作系统层。操作系统一方面将底层资源进行抽象和封装，实现基于容器的轻量级资源虚化。同时对卫星的文件、能源、安全等进行管理，向上提供通用的服务接口。其次，中间是容器引擎层，基于操作系统对资源进行高效的管理，对上层的应用软件提供负载均衡、服务发现、资源限制等服务。最后，软件的最上层是卫星的应用软件层。在该层将软件和其运行需要的相关库进行打包成镜像，基于容器引擎可以实现以应用软件级的资源分配和服务。本发明在智能卫星的软件体系设计和软件开发中具有广阔的应用前景。

Description

一种开放通用的智能卫星软件体系架构

技术领域

本发明涉及航天技术领域，具体是一种开放通用的智能卫星软件体系架构。

背景技术

卫星软件与一般软件相比，卫星软件系统数量较为密集，配置项多且复杂，且多运行在恶劣条件或高速条件下，一般处理自动运行状态，局部故障易引起全局崩溃，因此软件的重要性不言而喻，地位也相对较高。本发明的软件架构指的是卫星星载软件架构。

通用的软件架构有助于提高成本和计划的可预测性、提高任务关键软件的质量、降低测试和操作过程中的软件缺陷率、提高软件开发生产力、促进软件重用。自20世纪90年代初期开始，软件体系架构的研究受到了广泛的关注和重视，并被认为将会在软件开发中发挥重要的重要。软件的体系结构反映了待开发系统的高层架构特点。虽然至今还没有一个标准的定义，但它一般指组成软件系统的一个或者几个结构，它们构成了软件的各个部分，并形成组件的外部可见特性和相互之间的关系。

最早的卫星软件大部分都是嵌入式软件，一般都是每个卫星进行单独的架构设计，在实时性和可靠性方面有较强的保证，满足航天软件的需求。但是其与硬件紧密结合，随着卫星的日益复杂，带来了开发复杂、调试困难、软件复用率低、开发周期长等问题。为此国内外对星载软件体系结构均展开了研究，取得了一定的研究成果。目前典型的卫星软件架构如图1所示，它是一个分层的体系结构，有四个不同的层：平台抽象层、功能执行层、应用软件库层和应用程序层。最底层是卫星的硬件资源，包括通用及专用的处理器、高低速总线和多种载荷设备等等。向上是平台抽象层，包含了操作系统、板级支持包和多种设备驱动。在这一层的操作系统一般以操作系统抽象层的形式存在，和板级支持包提供常见的操作系统和BSP服务。第三层是中间服务层，包含提供的核心服务，这是卫星软件中通用的部分。平台抽象层和功能执行层的API基本保持稳定，它们一起定义了一个应用程序运行时环境，并支持卫星软件用户能够在上面进行开发。最顶层是具体的应用程序及用户程序。典型的星载软件体系架构有ASPEN飞行软件体系架构、core Flight System(cFS)、CubedOS、FIRSL。以CFS为例，它是戈达德航天飞行中心(GSFC)飞行软件部解决软件成本问题，提高嵌入式飞行软件的适应性而开发的可演化的软件架构，它支持运行时即插即用和分层功能的抽象。

发明内容

针对上述现有技术中的不足，本发明提供一种开放通用的智能卫星软件体系架构，实现卫星的快速设计和集成以及卫星间进行资源共享。

智能卫星目前没有明确的定义，一般认为是区别于传统的卫星，类似智能手机一样，是面向下一代的卫星，可能具备软件定义、网络化和智能化等特点。本发明在于解决智能卫星软件体系架构的开发性和通用性问题。

为了实现上述目的，本发明提供一种开放通用的智能卫星软件体系架构，其特征在于，包括由下至上的硬件资源层、操作系统层、容器引擎层与容器应用层，其中：

所述硬件资源层包含卫星全部的硬件资源；

所述操作系统层将硬件资源层中的硬件资源进行抽象和封装，实现基于容器的轻量级资源虚化，并对卫星进行管理，向上提供通用的服务接口，实现软件的跨硬件平台运行；

所述容器引擎层为承上启下的中间层，其向下对硬件资源进一步封装和管理，向上对容器进行管理和服务；

所述容器应用层将应用软件封装为容器，作为资源调度的单位。

进一步具体的，所述硬件资源层中的硬件资源包括存储器、网络设备、处理器、I/O接口与其他载荷设备，其中：

所述存储器为具有各类具备数据存储功能的星载存储资源；

所述网络设备为包含射频通信模组、激光通信模组、量子通信模组在内的能够为卫星提供星间与星地通信的网络资源；

所述处理器为卫星的计算资源；

所述I/O接口为卫星的输入/输出接口，包括各类星载设备的读取/写入地址、端口、带宽资源。

进一步具体的，所述操作系统层包括分布式文件系统、任务调度管理协同系统、能源管理系统、安全管理系统与资源虚化管理系统；

所述分布式文件系统用于提供海量、可靠、可拓展的分布式文件存储服务，实现增量扩容和数据自动平衡，并支持本地和远程文件管理，实现对包含卫星的载荷数据文件、系统文件、程序在内的部分进行高效、安全的管理；

所述任务调度管理协同系统用于完成卫星间的任务调度和协同服务，并支持在线和离线任务服务；

所述能源管理系统用于管理卫星内部各模块的能源分配，并根据各卫星能源使用情况和任务调度管理协同系统完成任务的分配和执行；

所述安全管理系统用于保证分布式文件系统间各卫星的安全可信环境，为分层的软件提供不同级别的安全访问能力，对卫星资源进行安全有效的实现隔离；

所述资源虚化管理用于完成计算、存储、网络和I/O资源的封装、虚化和接口化。

进一步具体的，所述容器引擎层基于内核的LXC技术实现容器的环境隔离和资源控制。

进一步具体的，所述容器引擎层包括负载均衡单元、服务发现单元、应用部署单元、资源限制单元、弹性伸缩单元与资源监控单元；

所述负载均衡用于通过多种负载均衡策略，使得集群中各节点的负载达到平衡状态，使得集群的资源在整体的角度上得到最大的利用，同时也使得各节点的服务性能达到最大化；

所述服务发现单元用于自动化发现并配置卫星容器参数；

所述应用部署单元用于是指将容器应用分配到本地或者其他集群里的卫星执行；

所述资源限制单元用于限制容器在运行时需要的资源；

所述弹性伸缩单元和资源监控单元一起为卫星系统提供集群和服务两个层次的弹性伸缩能力。

进一步具体的，所述负载均衡策略包括但不限于任务迁移与资源限制。

进一步具体的，所述服务发现单元、应用部署单元通过包含ningx反向代理和consul在内的自动化服务发现与部署功能，实现分布式服务部署和解决大量访问负载均衡的问题。

进一步具体的，所述资源限制单元基于Linux内核提供的cgroups功能，限制容器在运行时需要的包含内存、CPU、块I/O和网络在内的资源。

进一步具体的，所述容器应用层基于Docker的容器技术将应用软件封装为容器，使其可以在任意一台卫星上轻松地为任何应用创建一个轻量级的、可移植的、自给自足的容器。

有益效果：

在借鉴传统卫星软件架构的基础上，结合基于容器的轻量级资源虚化技术，本发明设计了一种开放通用的智能卫星软件体系架构，基于此架构下的卫星软件架构，不仅能够实现软硬件的解耦，达到提高软件重用率、缩小开发周期的同时，还能够实现卫星资源的轻量级虚化，提高卫星的资源利用效能，实现卫星星间的资源共享。本发明中的资源虚化是一种资源管理和应用的技术，是将卫星的各种实体资源，比如处理器、网络、内存等，予以抽象、转换后呈现出来，打破实体结构间的不可切割的障碍，使用户可以比原本的组态更好的方式来应用这些资源。虚化出来的资源不受地域或者物理组态限制，主要用来解决物理硬件部分资源过剩、部分资源紧张的问题，实现卫星间的资源共享，透明化底层物理硬件，从而最大化利用物理硬件、最大化提高硬件资源利用率的目的。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。

图1为传统卫星的软件架构示意图；

图2为本实施例中开放通用的智能卫星软件体系架构示意图；

图3为本实施例中智能卫星容器管理示意图；

图4为本实施例中容器化软件与本地软件共存示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明，本发明实施例中所有方向性指示(诸如上、下、左、右、前、后……)仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。

另外，在本发明中如涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本发明中，除非另有明确的规定和限定，术语“连接”、“固定”等应做广义理解，例如，“固定”可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接，还可以是物理连接或无线通信连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系，除非另有明确的限定。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

另外，本发明各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。

如图2所示为本实施例公开的一种开放通用的智能卫星软件体系架构，包括由下至上的硬件资源层、操作系统层、容器引擎层与容器应用层。

硬件资源层包含了卫星的全部硬件部分，主要包括存储器、网络设备、处理器、I/O接口和其他载荷设备等资源。其中，存储器即常用的存储资源，包括各类具备数据存储功能的星载存储器，如EEPROM、SRAM、FLASH等。网络设备代表网络资源，包括射频通信模组、激光通信模组、量子通信模组等为卫星提供星间与星地通信的的网络设备。I/O接口主要是卫星的输入/输出接口，包括各类星载设备的读取/写入地址、端口、带宽等资源。处理器是卫星的重要计算资源，包括ARM、DSP、PowerPC、FPGA等星载处理器。

本实施例中，通过资源虚化技术，将各类资源进行细颗粒度的虚化，采用基于商业货架产品(COST)的通用信号处理器、高性能处理器、高速数据交换网络、传感器等作为基础硬件资源，通过标准化的接口进行连接，实现对底层硬件资源的封装，实现各模块的独立访问。

操作系统层包含底层硬件抽象层与操作系统本身，是实现软件能够跨硬件平台运行的关键层。该层主要将底层各类硬件资源进行封装以及虚拟化，将信息获取、处理、输出、存储等能力及各类专属功能形成统一的API(Application Programming Interface，应用程序接口)，供上层调用。为了更好的对硬件设备进行表达，我们在通用操作系统的基础上还增加了虚拟化平台层并提供相应的API接口。

操作系统层是本实施例智能卫星软件体系架构实现软硬件解耦的关键，也是实现软件能够跨硬件平台运行的核心。与传统操作系统不同，卫星上的操作系统更注重资源的管理和实时性等内容。因此本实施例中的操作系统层，结合星载应用的需求对Linux的内核进行设计，分为分布式文件系统、任务调度管理协同系统、能源管理系统、安全管理系统与资源虚化管理系统。总的目的是能够实现硬件资源的灵活调配与管理，减少硬件之间的异构性，提升资源调度的灵活性，大幅提升资源利用率以及卫星资源的共享能力，具体的：

内核中的分布式文件系统提供海量、可靠、可拓展的分布式文件存储服务，实现增量扩容和数据自动平衡等功能；支持本地和远程文件管理，实现对卫星的载荷数据文件、系统文件、程序等高效、安全的管理；

任务调度管理协同系统完成卫星间的任务调度和协同服务，支持在线和离线任务服务。其中，在线任务服务是星间任务的实时共享与执行，离线任务是按照任务列表，基于设计的调度策略调度任务执行。这是由于卫星运行于空间环境，不同于地面系统可随时人工进行管控所限制的。

能源管理系统管理卫星内部各模块的能源分配，并根据各卫星能源使用情况和任务协同系统完成任务的分配和执行。

安全管理系统保证分布式操作系统间各卫星的安全可信环境，为分层的软件提供不同级别的安全访问能力，对卫星资源进行安全有效的实现隔离。

资源虚化管理是本实施例中操作系统层的关键核心，负责完成计算、存储、网络和I/O资源的封装、虚化和接口化。这四类通用资源经过资源虚化内核的虚化，将物理资源逻辑抽象化，使得顶层应用对资源的调用不需要考虑资源具体的物理细节，实现软硬件解耦的同时，为资源高效利用提供了可能。对于其他载荷设备类等非通用硬件资源，通过对其建立标准的硬件资源描述，实现设备的注册管理，也能够达到此类资源在星内星间共享的目的。

容器引擎层是一个承上启下的中间层，向下是进一步封装和管理资源，向上则是对容器的管理和服务。该层基于内核的LXC(Linux Container，一种内核虚拟化技术)技术实现容器的环境隔离和资源控制。其中，容器是一种操作系统内核级别的资源环境隔离方法，它运行在操作系统之上，是基于内核的LXC、Chroot等技术实现容器的环境隔离和资源控制。而且，在容器启动后，容器里的进程可直接和内核交互，无需经过容器引擎中转，因此几乎没有性能损耗，能发挥出最大的效能。本实施例中，容器引擎层由负载均衡单元、服务发现单元、应用部署单元、资源限制单元、弹性伸缩单元与资源监控单元组成，具体的：

负载均衡单元提供负载均衡服务，负载均衡是指卫星本地或者星间的服务请求、计算处理、网络连接等过多的任务运行在一个卫星上时，通过多种负载均衡策略比如任务迁移、资源限制等方法，使得集群中各节点的负载达到平衡状态，使得集群的资源在整体的角度上得到最大的利用，同时也使得各节点的服务性能达到最大化。

服务发现单元提供服务发现服务，服务发现是指自动化发现配置卫星容器参数。容器中的服务是用于生产环境的容器，当运行某一个容器时，对容器的相关配置，比如负载均衡、域名解析等，最终就是以服务的形式运行。

应用部署单元提供应用部署服务，应用部署是指将容器应用分配到本地或者其他集群里的卫星执行。在部署服务时，从外部调用服务需要知道服务接口及端口号，导致部署时需要进行复杂的配置。本发明通过ningx反向代理和consul等自动化服务发现与部署功能，实现分布式服务部署和解决大量访问负载均衡的问题。

资源限制单元提供资源限制服务，资源限制是容器的基础和核心。默认情况下，一个容器是没有任何资源限制的，它能够耗尽当前卫星内核能够调用给容器的所有资源。但这明显会给整个卫星带来不可预见的问题。容器的资源限制基于Linux内核提供的cgroups功能，可以限制容器在运行时需要的内存、CPU、块I/O和网络等资源。

弹性伸缩单元提供弹性伸缩服务，资源监控单元提供资源监控服务，弹性伸缩和资源监控一起为卫星系统提供集群和服务两个层次的弹性伸缩能力，能够根据业务运行情况，监控管理容器的CPU、内存、带宽等指标，并进行自动的扩缩服务。同时可以根据容器的部署情况，在容器不够资源分配时，或者有过多剩余资源的情况下自动伸缩集群。

容器应用层作为本实施例智能卫星软件体系架构的最顶层，包括各类容器应用，主要是基础应用软件、任务应用软件和其他类应用软件。容器技术可以在一台主机上轻松地为任何应用创建一个轻量级的、可移植的、自给自足的容器。通过这种容器打包应用程序，简化了重新部署、调试等工作，能够极大的提高工作效率。

本实施例中的容器操作和配置简单，通过Dockerfile配置文件支持灵活的自动化创建和部署。可通过开发工具或者手写Dockerfile，即可将应用软件和其运行的依赖库打包成镜像。容器的镜像是创建容器的基础，类似虚拟机的快照，可以理解为是一个面向容器的直读模板。容器提供了简单的机制来创建和更新现有的镜像，用户也可以从服务器中下载已经做好的应用镜像来直接使用。容器是从镜像创建的运行实例，它可以被启动、停止和删除。

本实施例中所创建的每一个容器都是相互隔离、互相不可见的，可以保证平台的安全性。如图3所示，是容器应用层对于容器的一个管理架构。软件库是用来集中保存镜像的地方，有公有软件库和私有软件库两种类型。公共仓库是用于管理公用容器镜像的地方，而私有仓库指的是卫星本地自己存储镜像的地方。当创建了自己的镜像后，可以将该镜像保存到公共软件库或者私有软件库，这样一来当下次要在另一台卫星上使用这个镜像的时候，只需要从软件库下载即可。软件库的管理通过注册服务器来完成。容器代理是对容器应用的运行管理的进程，负责容器的启动、运行等管理。

需要注意的是，本实施例中的智能卫星软件体系架构还具有开放性。架构的开放性体现在可拓展性和接口的共享性。本实施例中的智能卫星软件体系架构将卫星软件分为四层，每一层都是弹性可扩展的。每层都按照功能逻辑模块化，通过制定规范的交互标准，模块的规模可大可小，每一层的资源可以共享。比如硬件资源层，处理器可配置异构的CPU和FPGA，也可以只使用CPU，存储器的存储能力也可以根据需求进行配置。对于操作系统层，并不是划分的每一个模块都必须完全具备的能力，典型的安全管理在设置多种级别的安全权限。对于容器应用层，不是所有的软件都必须的，每个卫星的软件是根据所执行的任务进行加载及管理。共享性体现硬件资源和软件资源都能够在卫星内或者卫星之间进行资源共享。

需要注意的是，本实施例中的智能卫星软件体系架构具有基于容器的资源虚化功能，实现卫星之间的资源共享共享。首先，架构最低层是卫星的硬件资源，向上第一层是操作系统层。操作系统一方面将底层资源进行抽象和封装，实现基于容器的轻量级资源虚化。同时对卫星的文件、能源、安全等进行管理，向上提供通用的服务接口。其次，中间是容器引擎层，基于操作系统对资源进行高效的管理，对上层的应用软件提供负载均衡、服务发现、资源限制等服务。最后，软件的最上层是卫星的应用软件层。在该层将软件和其运行需要的相关库进行打包成镜像，基于容器引擎可以实现以应用软件级的资源分配和服务。

参考图4，本实施例中的智能卫星软件体系架构还考虑了容器化软件和本地软件共存的设计。对于天基网络智能卫星来说，星载应用有的对于实时性要求非常高，属强实时应用，这类的软件一般不直接容器化，以满足对实时性的苛刻要求。此类应用软件一般是对于星载执行器等应用来说。星载应用有的则对于实时性没要求或者不高，属于非实时应用。此类软件一般还能够进行分布式处理，比如大图像综合处理。这类软件可容器化，便于实现卫星间的资源共享。在操作系统之上，是属于容器引擎和本地软件的运行环境共存的。两类软件之间相互隔离，互不影响。

以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是在本发明的发明构思下，利用本发明说明书及附图内容所作的等效结构变换，或直接/间接运用在其他相关的技术领域均包括在本发明的专利保护范围内。

Claims (9)

1.一种开放通用的智能卫星软件体系架构，其特征在于，包括由下至上的硬件资源层、操作系统层、容器引擎层与容器应用层，其中：

所述硬件资源层包含卫星全部的硬件资源；

所述操作系统层将硬件资源层中的硬件资源进行抽象和封装，实现基于容器的轻量级资源虚化，并对卫星进行管理，向上提供通用的服务接口，实现软件的跨硬件平台运行；

所述容器引擎层为承上启下的中间层，其向下对硬件资源进一步封装和管理，向上对容器进行管理和服务；

所述容器应用层将应用软件封装为容器，作为资源调度的单位。

2.根据权利要求1所述开放通用的智能卫星软件体系架构，其特征在于，所述硬件资源层中的硬件资源包括存储器、网络设备、处理器、I/O接口与其他载荷设备，其中：

所述存储器为具有各类具备数据存储功能的星载存储资源；

所述网络设备为包含射频通信模组、激光通信模组、量子通信模组在内的能够为卫星提供星间与星地通信的网络资源；

所述处理器为卫星的计算资源；

所述I/O接口为卫星的输入/输出接口，包括各类星载设备的读取/写入地址、端口、带宽资源。

3.根据权利要求1所述开放通用的智能卫星软件体系架构，其特征在于，所述操作系统层包括分布式文件系统、任务调度管理协同系统、能源管理系统、安全管理系统与资源虚化管理系统；

所述分布式文件系统用于提供海量、可靠、可拓展的分布式文件存储服务，实现增量扩容和数据自动平衡，并支持本地和远程文件管理，实现对包含卫星的载荷数据文件、系统文件、程序在内的部分进行高效、安全的管理；

所述任务调度管理协同系统用于完成卫星间的任务调度和协同服务，并支持在线和离线任务服务；

所述能源管理系统用于管理卫星内部各模块的能源分配，并根据各卫星能源使用情况和任务调度管理协同系统完成任务的分配和执行；

所述安全管理系统用于保证分布式文件系统间各卫星的安全可信环境，为分层的软件提供不同级别的安全访问能力，对卫星资源进行安全有效的实现隔离；

所述资源虚化管理用于完成计算、存储、网络和I/O资源的封装、虚化和接口化。

4.根据权利要求1所述开放通用的智能卫星软件体系架构，其特征在于，所述容器引擎层基于内核的LXC技术实现容器的环境隔离和资源控制。

5.根据权利要求4所述开放通用的智能卫星软件体系架构，其特征在于，所述容器引擎层包括负载均衡单元、服务发现单元、应用部署单元、资源限制单元、弹性伸缩单元与资源监控单元；

所述负载均衡用于通过多种负载均衡策略，使得集群中各节点的负载达到平衡状态，使得集群的资源在整体的角度上得到最大的利用，同时也使得各节点的服务性能达到最大化；

所述服务发现单元用于自动化发现并配置卫星容器参数；

所述应用部署单元用于是指将容器应用分配到本地或者其他集群里的卫星执行；

所述资源限制单元用于限制容器在运行时需要的资源；

所述弹性伸缩单元和资源监控单元一起为卫星系统提供集群和服务两个层次的弹性伸缩能力。

6.根据权利要求5所述开放通用的智能卫星软件体系架构，其特征在于，所述负载均衡策略包括但不限于任务迁移与资源限制。

7.根据权利要求5所述开放通用的智能卫星软件体系架构，其特征在于，所述服务发现单元、应用部署单元通过包含ningx反向代理和consul在内的自动化服务发现与部署功能，实现分布式服务部署和解决大量访问负载均衡的问题。

8.根据权利要求5所述开放通用的智能卫星软件体系架构，其特征在于，所述资源限制单元基于Linux内核提供的cgroups功能，限制容器在运行时需要的包含内存、CPU、块I/O和网络在内的资源。

9.根据权利要求1所述开放通用的智能卫星软件体系架构，其特征在于，所述容器应用层基于Docker的容器技术将应用软件封装为容器，使其可以在任意一台卫星上轻松地为任何应用创建一个轻量级的、可移植的、自给自足的容器。

Images