基于云计算的卫星一体化管控体系设计

辛维政，张国亭，颜文娴，万俊伟，张利萍，王 鹿，刘晓丽

(1.北京跟踪与通信技术研究所，北京 100094；2.中国电子科技集团公司第五十四研究所，河北 石家庄 050081)

0 引言

卫星管控系统主要是管理控制在轨卫星， 实现应用目的并保持其正常在轨运行的信息系统。 该系统是卫星效能发挥和在轨正常稳定运行的管理控制中枢,其具备在轨卫星需求筹划、任务规划、状态监视、运行控制和健康管理等功能,为卫星应用提供全方位支持,是我国庞大空间资产稳定运行、航天活动高效开展的基础保证[1,2]。

当前，我国卫星管控系统分布在各卫星测(运)控中心，各类卫星管控中心独立建设，虽然功能相同，但技术架构、软硬件平台差异较大，系统功能也难以快速迁移和重构恢复[3]，存在以下问题：① 容灾能力弱：各卫星管控节点容灾能力不足，一旦管控系统出现异常，卫星将难以发挥效能，甚至危害在轨卫星的安全；② 系统可扩展性不足：当前各卫星任务管控系统与卫星型号紧密耦合，软硬件系统“跟着型号走”的问题比较突出，新上型号从头开始建设，系统架构的可扩展能力严重不足；③ 系统接入灵活性不足：卫星管控必须与固定节点关联，管控业务与服务只能在该地实施，发生故障时，卫星研制单位与管控单位跨地区协同难，时效性难以保证；④ 系统协同应用能力不足：各类卫星管控系统分署不同部门,各自独立建设发展，缺乏统一接口标准,各系统难以互联互通,系统间数据无法共享,一定程度上制约了卫星应用效能的发挥， 亟需适应卫星高效综合运用要求,进行管控体系能力的升级[4-5]。

随着我国航天事业蓬勃发展，在轨卫星数量剧增，将达到数百颗至上千颗，具备遥感、科学探测、通信等多用途的综合型卫星快速发展，任务状态更加复杂多变，对卫星任务管控系统高效管控、可靠运行能力提出了更高的要求。同时，为保证在轨卫星的连续稳定运行和可靠管理，卫星管控系统需要具备较强的健壮性，且以更少投入、在更短时间内实现高效的容灾备份。如按照关键信息枢纽两地三中心的容灾备份方式[6-8]，每个卫星管控系统均需建设3套，建设规模庞大、投资要求高。

与此同时,信息领域技术快速发展,云计算、大数据和移动互联等技术逐步成熟，并在军、民、商各领域得到广泛推广应用,为卫星任务管控系统技术进步、体系革新和能力提升提供了有效途径[9-11]。需要以创新驱动的理念，充分利用云计算、网络互联等新技术，创新系统体系架构、技术手段与运用模式，推动卫星管控资源充分共享和灵活重组，不断提升系统建设与使用效益[12-14]。

本文基于云计算技术，构建了卫星任务管控云技术架构，并设计了基于云架构的卫星任务一体化管控产品体系、数据体系与运维体系，可实现各类卫星管控系统的互联互通与统筹协同应用，可实现资源灵活扩展和共用共享，支撑管控软件快速开发、部署和迁移重构。

1 卫星管控技术发展

美国、俄罗斯、欧空局等航天大国和组织均建立了较为完善的卫星管控体系，形成了一定规模的卫星管控能力，其中以美国最具代表性[15]。

1.1 美国国家航空航天局(NASA)高级多任务应用系统AMMOS

美国高度关注任务能力的保持与发挥，容灾抗毁设施完备。航天任务建有异地部署且处于热备状态的主、备2个中心，形成了完备的容灾能力，主中心平时出现灾难时，异地备份系统能够接替工作，确保能力不降级。

最初的NASA航天操控中心采用的是单任务应用系统。进入21世纪，NASA许多创新的空间任务，在卫星数目、结构配置、交互作用上与以往存在较大差异，对于每个新的任务，都要重新设计任务应用系统，系统开发维护成本高、地面系统重复利用率低、人员兼顾不同任务操作难，于是NASA提出了新一代用于支持深空和航天任务操控的新体系——高级多任务应用系统(AMMOS)。AMMOS利用虚拟化技术和软件共享技术构建多任务应用系统体系结构，提高系统实用性和计算机资源利用效率。计划6年内，实现任务飞行和地面系统支持兼容性，自动生成上行链路程序，提供端到端数据服务和自动化的飞行系统监控。

1.2 美军卫星管控系统

20世纪90年代，美军卫星地面系统在经历了“烟囱”式发展后，进行自上而下、有计划的整合，并探索用体系结构方法进行顶层设计的发展途径。为进一步提升联合作战能力，加快向“网络中心”转型，美军启动了相关系统建设。2004年确定的核心建设领域包括快速反应和可靠的网络资源与服务、无缝安全可靠的连通性和互操作性、分布式协同支持等[16]。目前，美军正按照C4ISR体系结构框架的要求全面更新卫星应用装备，向一体化装备体系方向发展。

以往任务管控都是面向单任务应用，不同任务系统在结构、配置和交互等上存在较大差异，对于新的任务均需要重新设计，系统开发维护成本高、地面系统重复利用率低、人员兼顾不同任务操作难。近年来，充分利用虚拟化、软件共享等新技术，发展构建面向多任务的地面系统体系结构，推行统一的技术架构、共享资源与网络通用服务，提升信息系统的开放性、灵活共享能力以及建设效益。

每个控制中心又可细分为数个“航天指挥控制设施”(MCC)。一个MCC一般负责一个卫星系列，若星座不大也可负责几个卫星系列。卫星管控系统建设中，采用了分布式架构，并推行统一的技术架构、共享资源与网络通用服务，可通过多类总线获取轨道确定、遥测显示、用户显示、事件分析和系统监控等通用服务，并针对GPS和MILSATCOM等不同类别卫星管理开发了特殊应用组件，如图1所示。

图1 美军用卫星管控系统架构示意Fig.1 Schematic diagram of US military satellite management and control system architecture

2 卫星管控云体系设计

2.1 体系架构

按照“云—网—端”架构，建立由云中心、各卫星管控端节点和轻量化用户端共同组成的一体化、分布式、弹性的卫星任务管控云，形成网络化分布式任务中心体系，实现体系性容灾，支持功能快速部署、系统快速重建以及能力快速迁移[17]。分布式卫星任务管控云体系架构如图2所示。

图2 分布式卫星任务管控云体系架构Fig.2 Cloud architecture of distributed satellite mission management and control

其中，云中心是卫星任务管控云监控、管理中枢和软件、数据的存储以及综合服务的中枢，具备承接所有卫星管控任务的能力，具体发挥“数据中心+软件中心+容灾中心+服务中心+运维中心”五大作用，为保证其可靠运行，采取异地双活部署；各卫星管控节点主要承担相应类别卫星在轨管控任务，技术架构与一体化管控云中心相同，可基于卫星管控通用平台独立建设部署，也可调用云中心计算资源和存储资源，形成本地化管控能力(根据不同用户可靠性要求以及管控模式，该端节点可不部署)；轻量化用户端，采用App或B/S方式远程接入管控云，获取管控服务，实现异地或移动管控；网即通信网，为云中心、端节点以及用户端提供栅格化通信接入，实现管控数据、运行数据等信息网络化传输。通过体系化架构，有效减少专用备份系统的数量，提高系统建设效益。

2.2 技术架构设计

卫星任务管控云技术架构基于云计算三层架构[18]，在基础设施层(IaaS)实现服务器、存储设备和网络设备等资源在分布式环境的融合共享，对分布在云中心和各管控节点的计算、存储和网络等资源进行池化，建立全网资源统一视图；在平台服务层(PaaS)构建共性基础服务环境，提供轻量级容器、微服务以及数据库、文件系统、中间件、大数据、用户管理等云平台支撑服务，构建共性云环境；在软件服务层(SaaS)基于管控通用服务进行集成和定制，形成管控业务中台和型号专用应用，构建面向各型卫星的任务管控系统。云中心和各节点应用遵循相同的技术架构，可根据各自任务定位和能力要求，各层裁剪，选用的具体软件功能，如图3所示，其中，轻量级用户端只包含应用层，基于移动互联技术，为任务管理、卫星管控、服务运维等岗位人员提供便携式用户端，支撑相关人员远程掌握卫星状态和管控人员“离岗”值班。

图3 卫星任务一体化管控云技术架构Fig.3 Cloud technology architecture for integrated management and control of satellite mission

2.3 数据体系设计

管控数据在云中心和各管控端节点上分布式部署，如图4所示。各管控端节点和云中心内部拥有独立的数据管理系统，业务数量动态增长，各管控端节点的数据按要求同步备份到云中心，以支持管控数据的日常备份及系统迁移重构。

图4 卫星任务一体化管控数据体系Fig.4 Integrated datamanagement and control system for satellite mission

云中心承担自身业务数据的管理与所有管控端节点数据的备份功能，作为所有管控端节点的全量数据中心，各管控端节点的数据备份到云中心。各管控端节点承担自身业务数据的管理功能，当端节点重构时，云中心可以将备份的端节点数据恢复到重构的端节点，并作为此新端节点的云中心。当管控端节点出现故障后，云中心数据可以支持接管原有管控端节点的任务。

云中心和各管控端节点的数据采用统一标准，根据不同类型卫星管控所需的静态数据和任务管控动态数据特点，设计和制定统一的卫星管控数据结构、数据管理模式、数据交换规程、数据共享机制和数据服务接口，形成统一的卫星管控数据仓库，为各用户按需提供数据服务。

2.4 产品体系设计

所有业务应用软件采用轻量级、易扩展的微服务架构研制开发，并基于容器技术容器化封装、部署和运行。为提升软件复用性，卫星任务管控软件由基础通用服务、领域类通用管控服务和卫星专用管控服务3类微服务拼装构建而成。其中，基础通用管控服务为所有型号卫星管控任务通用，领域类通用管控服务为某类卫星管控任务通用，专用管控服务应用于具体卫星型号。

按照不同卫星管控系统的功能定位，形成相应卫星应用产品包，构建产品型谱，支持管控任务软件的积木式组装和一键式部署。云中心具有管控产品的全部备份，在端初始构建时，从云中心一键式下载卫星应用产品包，完成在本地的安装和验证，按照需要定制端任务管控应用系统，同时为系统重构、重启奠定基础，是构建系统容灾抗毁能力的关键。针对不同类型端节点的功能，管控系统产品包涵盖遥感、通信和导航等各个卫星门类，按照管控范围分为单星管控产品和中心级卫星管控产品2大类。

在云中心构建统一的应用门户体系，在云环境下实现管控应用的统一管理、备份同步、开发上架、拓展更新能力。在卫星任务管控云技术架构下，基于管控业务中台提供通用服务，针对卫星个性化特征研制新卫星专用管控插件集，可快速构建新卫星任务管控产品，通过应用门户快速部署发布，加入产品型谱。云中心/各管控端节点应用体系如图5所示。

图5 云中心/各管控端节点应用体系Fig.5 Application system of cloud center/node of each management and control terminal

2.5 运维体系设计

通过云端协同，构建覆盖“云中心—端节点—用户端”多层次、“系统—资源—服务”多维度、“态势—监控—处置”多能力的全域系统运维体系，在任一节点均可实现运维态势综合、资源统一管理、系统精细监控以及维护远程实施；通过自助服务、智能分析等技术，建立系统运维自动化手段，提高运维效率。卫星任务管控云运维体系如图6所示。

图6 卫星任务管控云运维体系Fig.6 Cloud operation and maintenance system of satellite mission management and control

运维管理用户可根据权限实施对各自管理域云资源的管控，动态发现各类云资源及物理服务器的使用状态及健康状态，确保云资源能够得到合理的使用，既避免资源配置申请过高而导致的浪费，又可分析出是否存在配置过低导致业务运行的不稳定。

3 典型管控场景设计

3.1 系统运行方式

根据任务场景的不同，设计以下运行方式：

① 管控端节点独立运行。各管控端节点独立运行模式是各任务管控中心的日常工作模式，各端节点按分工具体完成相应型号卫星管控任务，云中心只负责端节点业务数据的备份，并通过端的运维数据监视端节点的运行状态。端节点接收各用户提出的任务需求，进行需求筹划、任务规划和卫星管控等工作，同步将任务数据发送至云中心进行备份。

② 云中心与端节点协同运行。云中心与端节点协同运行模式是端节点计算资源有限的情况下，直接调用云中心提供的服务。端节点管控人员通过远端登录，调用云中心的任务规划算法和轨道计算等服务，生成卫星任务方案和接收方案[19]。

③ 主备同时运行(热备)。管控云中心和管控节点，或主、备管控节点同时实施相同任务，具备快速接替能力。

④ 云中心接管。在特定情况下(如应急或某端节点故障情况)，云中心对某类或所有卫星管控任务进行接管。

3.2 节点重构模式

基于云体系，各卫星管控中心能够从云中心获取管控应用和任务数据，实现不同类型卫星任务管控应用的快速下载与接替，并提供重启及重构2种模式，完成端节点内各应用的整合和统一配置，并对重构端管控能力测试与评估，以实现卫星管控的功能快速异地重建。基于云中心管控产品与数据的同步备份，节点重构与重启能力，构建系统容灾抗毁体系，当某端卫星管控节点系统故障或被毁时，通过基于卫星管控云中心进行节点重构或备份端重启，快速启动接替卫星管控系统，实现系统任务接续。云中心/各管控端节点应用体系架构如图7所示。

图7 云中心/各管控端节点应用体系架构Fig.7 Application architecture of cloud center/node of each control terminal

(1) 重构

重构是指在端中从云基础上开始完全重新构建管控系统，迁移重构过程如图8所示。迁移过程包括从云中心获取管控应用和管控数据。整个过程包括管控应用和管控数据的查询和下载，管控应用和管控数据的获取可以并行进行。管控应用和管控数据迁移到端以后，需要在云环境中完成管控应用的重构，重构共分为4步：软件安装、数据导入、应用配置和应用验证。

图8 端节点系统重构流程Fig.8 Reconstruction process of terminal node system

(2) 重启

重启模式过程如图9所示，管控应用在备份端已经安装配置好，只需将当前的管控数据迁移到备份端，由备份端加载就可以实现卫星管控应用的有状态迁移与重构。其基本过程与重构模式一致，但省去了应用获取、应用安装和应用配置的环节，耗时也大幅降低。

图9 端节点系统重启流程Fig.9 Restart process of terminal node system

针对不同任务可靠性、恢复时效性要求，通过不同模式的灵活选用，降低系统整体建设成本，提高建设效益。

4 结束语

本文设计了基于云架构的卫星任务一体化管控体系，可有效提升卫星管控系统建设效益。通过资源、应用和数据虚拟化，实现功能快速重构、业务快速迁移以及系统快速重建；通过“平台+插件”管控软件架构，将卫星管控系统从单星完全重新建设转变为研制少量管控插件，有利于新增能力快速形成；基于体系化容灾思路，将各中心任务分离、独立容灾备份转变为一体化卫星管控、体系化容灾抗毁；基于云-端架构，将固定式中心管控转变为固定、移动管控相结合，终端功能可方便按需重构，实现不同航天器的管控能力。