CN113271142B - 软件定义卫星的运控系统和运控方法 - Google Patents

Abstract

本申请提供了一种软件定义卫星的运控系统和运控方法，其中，该系统包括：多个软件定义卫星、云平台、多个地面站以及用户终端，用户终端被配置为接收用户请求，并向云平台发送用户请求，云平台被配置为从多个软件定义卫星中确定执行指定任务的目标软件定义卫星，从多个地面站中确定满足目标软件定义卫星的使用时间的目标地面站，向目标地面站发送用户请求，目标地面站被配置为向目标软件定义卫星发送用户请求，目标软件定义卫星被配置为根据用户请求获取指定任务对应的业务数据，依次通过目标地面站和云平台将业务数据发送给用户终端。通过建立一种新的卫星运控模式，减小了软件定义卫星对地面站的压力，以应对大规模软件定义卫星的运维的需要。

Description

软件定义卫星的运控系统和运控方法

技术领域

本申请涉及卫星技术领域，具体而言，涉及一种软件定义卫星的运控系统和运控方法。

背景技术

随着卫星技术的快速发展，卫星技术在多个领域得到了长足的发展，例如，在海上、空中和偏远地带等这些传统地面网络无法覆盖或成本高昂的区域，采用卫星通信技术可以实现更好的通信。

目前，传统的软件定义卫星运控通常采用预生成测控跟踪计划，在软件定义卫星过境时，将提前生成的轨道、时间、任务等遥控指令通过地面站上传至软件定义卫星，软件定义卫星解析遥控指令，生成遥测数据和业务数据，根据设定的测控时间和数传时间，分别将遥测数据和业务数据下传至地面站，由地面站进行卫星状态的判断以及数据的后处理。

然而，上述过程中，软件定义卫星和地面站之间的通信发起端为地面站，大量的软件定义卫星的运维工作由地面站来执行，忽略了卫星本身的能动性和智能性，难以应对大规模的软件定义卫星的运维的需求。

发明内容

本申请的目的在于，针对上述现有技术中的不足，提供一种软件定义卫星的运控系统和运控方法，以解决现有技术中大量的运维工作由地面站执行，忽略了卫星本身的能动性和智能性，难以应对大规模软件定义卫星的运维的需要的问题。

为实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请一实施例提供了一种软件定义卫星的运控系统，所述运控系统包括：多个软件定义卫星、云平台、多个地面站以及用户终端；

其中，所述多个软件定义卫星和所述多个地面站、所述云平台互相通信连接，所述云平台还和所述用户终端通信连接；

所述用户终端被配置为，接收用户请求，并向所述云平台发送所述用户请求，所述用户请求用于请求执行指定任务；

所述云平台被配置为，从所述多个软件定义卫星中确定执行所述指定任务的目标软件定义卫星，从所述多个地面站中确定满足所述目标软件定义卫星的使用时间的目标地面站，并向所述目标地面站发送所述用户请求；

所述目标地面站被配置为，向所述目标软件定义卫星发送所述用户请求；

所述目标软件定义卫星被配置为，根据所述用户请求获取所述指定任务对应的业务数据，并依次通过所述目标地面站和所述云平台将所述业务数据发送给所述用户终端。

可选地，所述云平台还配置为：

对所述用户请求进行请求分析，获取所述指定任务对应的元任务，并将所述元任务映射为多个应用程序对应的任务；

所述目标软件定义卫星被配置为，查询是否部署有所述多个应用程序，若否，则向所述目标地面站发送软件上注请求，所述软件上注请求中包括所述目标软件定义卫星未部署的目标应用程序的标识；

所述目标地面站被配置为，向所述云平台转发所述软件上注请求；

所述云平台被配置为，根据所述软件上注请求，从航天应用商店中拉取所述目标应用程序的安装数据，并通过所述目标地面站向所述目标软件定义卫星发送所述目标应用程序的安装数据；

所述目标软件定义卫星被配置为，根据所述安装数据部署所述目标应用程序，并根据目标应用程序执行所述元任务。

可选地，所述云平台具体被配置为：

根据所述多个软件定义卫星的在轨运行数据，从所述多个软件定义卫星中确定可执行所述元任务的至少一个执行软件定义卫星，并向每个可执行的软件定义卫星发送是否执行所述元任务的询问请求；

所述至少一个执行软件定义卫星被配置为，自主判断是否确定执行所述元任务，若所述至少一个执行软件定义卫星中存在任一软件定义卫星确定执行所述元任务，则所述任一软件定义卫星向所述云平台发送执行所述元任务的指示信息；

所述云平台被配置为，将所述任一软件定义卫星作为所述目标软件定义卫星。

可选地，所述运控系统还包括：总控站；

所述总控站和所述目标软件定义卫星、所述云平台通信连接；

所述目标软件定义卫星还被配置为，在自主运行过程中若需要地面进行干预或需要向地面下传数据，则在经过所述总控站时，向所述总控站发送地面站资源使用请求，所述地面站资源使用请求中包括所述目标软件定义卫星对地面站资源的使用时间；

所述总控站被配置为，向所述云平台发送所述地面站资源使用请求；

所述云平台被配置为，根据所述地面站资源使用请求，从所述多个地面站中确定满足所述使用时间的多个可用地面站，并从所述多个可用地面站中确定所述目标地面站。

可选地，所述云平台还被配置为：

向所述目标软件定义卫星和所述目标地面站发送调度结果，所述调度结果用于指示所述目标软件定义卫星在所述使用时间内使用所述目标地面站。

可选地，所述运控系统还包括：信标站；

所述信标站和所述目标软件定义卫星通信连接；

所述信标站被配置为，在所述目标软件定义卫星经过所述信标站时，对所述目标软件定义卫星的通信参数进行校准。

可选地，所述运控系统还包括：中央库设备；

所述中央库设备和所述目标软件定义卫星通信连接；

所述目标软件定义卫星还被配置为，按照预设时间间隔向所述中央库设备发送在轨运行数据。

可选地，所述云平台具体被配置为：

根据预设解析规则，对所述业务数据进行解析处理，得到解析之后的业务数据，向所述用户终端发送所述解析之后的业务数据。

可选地，所述云平台还被配置为：

根据所述业务数据对所述目标软件定义卫星进行故障诊断与健康评估。

第二方面，本申请另一实施例提供了一种软件定义卫星的运控方法，应用于第一方面任一项所述的软件定义卫星的运控系统，所述运控系统包括：多个软件定义卫星、云平台、多个地面站以及用户终端，所述方法包括：

所述用户终端接收用户请求，并向所述云平台发送所述用户请求，所述用户请求用于请求执行指定任务；

所述云平台从所述多个软件定义卫星中确定执行所述指定任务的目标软件定义卫星，从所述多个地面站中确定满足所述目标软件定义卫星的使用时间的目标地面站，并向所述目标地面站发送所述用户请求；

所述目标地面站向所述目标软件定义卫星发送所述用户请求；

所述目标软件定义卫星根据所述用户请求获取所述指定任务对应的业务数据，并依次通过所述目标地面站和所述云平台将所述业务数据发送给所述用户终端。

本申请提供了一种软件定义卫星的运控系统和运控方法，其中，该系统包括：多个软件定义卫星、云平台、多个地面站以及用户终端，其中，多个软件定义卫星和多个地面站、云平台互相通信连接，云平台还和用户终端通信连接，用户终端被配置为，接收用户请求，并向云平台发送用户请求，用户请求用于请求执行指定任务，云平台被配置为，从多个软件定义卫星中确定执行指定任务的目标软件定义卫星，从多个地面站中确定满足目标软件定义卫星的使用时间的目标地面站，并向目标地面站发送用户请求，目标地面站被配置为，向目标软件定义卫星发送用户请求，目标软件定义卫星被配置为，根据用户请求获取指定任务对应的业务数据，并依次通过目标地面站和云平台将业务数据发送给用户终端。本申请通过建立一种新的卫星运控模式，减小了软件定义卫星对地面站的压力，以应对大规模软件定义卫星的运维的需要。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的软件定义卫星的运控系统的结构示意图1；

图2示出了本申请实施例提供的软件定义卫星的运控系统的结构示意图2；

图3示出了本申请实施例提供的软件定义卫星的运控系统的结构示意图3；

图4示出了本申请实施例提供的软件定义卫星的运控系统的结构示意图4；

图5示出了本申请实施例提供的软件定义卫星的运控方法的流程示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

软件定义卫星作为一种新型的卫星体系架构，其以天基超算平台为核心，采用开放系统架构，具有开源软件生态，设有航天应用商店，支持有效载荷即插即用，应用软件按需加载，可以通过软件升级不断扩充功能，提升性能。随着软件定义卫星技术的快速发展，未来在轨卫星的数量迅速增加，在轨卫星的自主能力也越来越强，其可完成的在轨任务也越来越丰富多样，此外卫星和地面站的动态加入与退出、任务的碎片化到达等高动态的属性，也给卫星的运控提出了更多的挑战。

因此，未来的软件定义卫星的运控面临的场景具有数量大、高动态等属性，卫星的运控模式也将发生改变，一方面需要对在轨运行的海量卫星进行综合管理，确保其正常运行，另一方面需要满足软件定义卫星的多种任务类型，应对不断到达的用户请求和卫星请求，使卫星和地面站资源尽可能得到最大化利用。因此，如何对在轨的卫星进行高效的管理，解决巨型星座运维的问题，是至关重要的。

传统的卫星运控系统通常采用预生成测控跟踪计划，在卫星过境时，将提前生成的轨道、时间、任务等遥控指令通过地面站上注至星上，星上解析遥控指令，生成遥测数据和业务数据，根据设定的测控和数传时间下传至地面，地面进行遥测数据和业务数据的解析，进行卫星状态的判断和业务数据的后处理。这种运控模式的缺点在于：

(1)地面发起。星地之间的运控通信发起端为地面，卫星是被动接收的执行体，缺乏足够的自主感知、自主决策、自主控制能力。

(2)静态规划。地面根据卫星的轨道信息，提前为卫星分配地面站资源，设定测控跟踪计划，可能会导致地面站(测控)资源的利用率降低。

(3)处理中心化。遥控指令的发送和遥测数据的接收往往需要在数据处理中心完成，缺乏一定的可移植性，无法满足用户随时随地查看卫星、运控卫星的需要。

这些缺点导致大量的运维工作放在地面进行，忽略了卫星本身的能动性和智能性，难以应对大规模软件定义卫星的运维的需要。

为解决海量的软件定义卫星运维的问题，本申请通过建立一种新的卫星运控模式，减小了软件定义卫星对地面站的压力，具体地，面向卫星的综合管理与任务规划，立足于卫星自主能力的提升与发挥、地面设施的完善、高效的运控云平台三个方面，解决大规模软件定义卫星运维的问题。

(1)卫星自主能力的提升与发挥

为解决海量的软件定义卫星运维的问题，需要提升卫星的自主能力，自主感知周围环境与自身状态，选择合适的程序、算法、参数等进行控制，在需要地面进行干预的时候向地面发出请求。星上自主能力的提升包括但不局限于：

第一，自主定轨：软件定义卫星可以自主确定自身的运行参数，并采用轨道外推算法，计算软件定义卫星在预设时刻的目标位置，在目标位置和软件定义卫星的当前位置的距离大于预设距离，则确定软件定义卫星存在异常，则可以向目标地面站发送异常修复请求，以使目标地面站调整软件定义卫星的运行参数。

其中，软件定义卫星可以采用轨道外推算法，根据运行参数计算软件定义卫星在预设时刻的目标位置，若目标位置和软件定义卫星的当前位置的距离大于预设距离，则确定软件定义卫星存在异常。

运行参数包括：轨道参数，轨道参数可以采用开普勒六根表示，例如可以包括半长轴、轨道离心率、轨道倾角、升交点赤经、近地点幅角以及平近点角。可以采用轨道外推算法，根据软件定义卫星的轨道参数计算软件定义卫星在预设时刻的目标位置，若目标位置和软件定义卫星的当前位置的距离大于预设距离，则确定软件定义卫星存在异常。

需要说明的是，软件定义卫星的当前位置可以通过设置于软件定义卫星的全球导航卫星系统(Global Navigation Satellite System，GNSS)接收机采集获取，软件定义卫星的当前位置和目标位置均可以采用J2000坐标系下的xyz表示。

第二，自主健康管理：软件定义卫星可以监测自身各个组成部件的状态，并给出量化的健康评估值，在健康评估值小于或等于预设值时，软件定义卫星可以进行异常诊断，确定异常类型以及异常发生的位置，并采取必要的异常修复措施，在软件定义卫星无法处理时，则可以向目标地面站发出异常修复请求，以使目标地面站对软件定义卫星执行异常修复操作。

其中，异常类型例如可以包括温度异常、动量轮转速异常、电池电压异常、全球导航卫星系统(Global Navigation Satellite System，GNSS)失效等，异常发生的位置可以为异常的类型对应的异常部件，例如若异常类型包括电池电压异常，那么异常发生的位置可以为软件定义卫星的电池，若异常类型为动量轮转速异常，那么异常发生的位置可以为软件定义卫星的动量轮。

确定异常类型以及异常发生的位置之后，可以采取必要的异常修复措施，具体包括：根据异常的类型和异常的发生位置，调整软件定义卫星的运行参数，需要说明的是，软件定义卫星的运行参数可以包括软件定义卫星的各组成部件的运行参数，若各组成部件的运行参数在各组成部件的预设运行参数的范围之外，说明软件定义卫星存在异常，则可以根据异常的类型和异常发生的位置，执行异常修复操作，也就是，异常发生的位置可以为异常部件，那么可以根据异常类型，对异常部件执行修复操作。

可选地，异常修复操作例如可以包括升温、降温、开关机重启、进入安全模式等。

作为一种示例，若异常类型包括电池电压异常，异常部件包括电池，则可以对电池执行异常修复操作，例如可以包括对电池进行放电开关断开操作，以确保软件定义卫星的运行。

当然，若软件定义卫星无法处理或者卫星自主执行异常修复操作失败时，则可以向目标地面站发出异常修复请求，以使目标地面站对软件定义卫星执行异常修复操作。作为一种示例，若异常类型包括电池电压异常，异常发生的位置包括电池，则软件定义卫星还可以向目标地面站发送异常修复请求，异常修复请求中包括异常的类型和异常的发生位置，那么目标地面站可以响应该异常修复请求，执行异常修复操作，该异常修复操作例如可以包括给软件定义卫星的电池进行放电开关断开或打开操作，以使软件定义卫星的电池温度保持正常。

将软件定义卫星由被动执行体变为智能体，减少了对地面站的压力，不仅提高了处理效率，还提高了软件定义卫星的自主能力，以满足海量卫星的运维需求，并且软件定义卫星具备相当的自主感知、自主决策、自主控制能力，对地面运控的请求减少，可以推动运控的高效自动化，实现越来越少的人管理越来越多的卫星。

第三，自主切换：软件定义卫星可以根据自身的位置、速度等确定周围的太空环境、自身的工作模式、应该选择的算法、应该启动的传感器及执行器等，例如可以根据自身的位置、速度等确定当前应采取速率阻尼模式或者对日定向模式等，或者，根据自身是否在执行任务确定当前应采取何种姿态，进而根据当前采取的姿态确定当前应该启动的传感器以及传感器算法等，例如在执行任务时，可以根据执行任务的类型确定应采取何种姿态，并根据当前采取的姿态确定启动的哪种类型的传感器，以及启动高精度的传感器和高精度的传感器算法；未执行任务时，可以启动对应的低精度的传感器和低精度的传感器算法。这样，无需地面工作人员生成用户请求以请求软件定义卫星执行特定操作。

第四，自主碰撞避让：随着太空飞行器数量的增加，碰撞发生的可能性越来越大，软件定义卫星可以通过通信、成像等手段确定是否存在碰撞预警，若可能发生碰撞，自主采取相应的避让措施。

具体地，软件定义卫星在轨运行的过程中，还可以通过与其他软件定义卫星建立通信连接，以获取预设范围内的其他软件定义卫星的当前位置，或者可以通过设置于软件定义卫星的图像传感器采集预设范围内的图像，并对预设范围内的图像进行提取，以确定该预设范围内的其他软件定义卫星的当前位置，若其他软件定义卫星的当前位置和软件定义卫星的当前位置的距离小于或等于预设距离，说明存在碰撞风险，那么软件定义卫星还可以执行相应的碰撞避让动作，例如，若位于软件定义卫星的左侧的其他软件定义卫星与软件定义卫星的距离小于预设距离，说明其他软件定义卫星和软件定义卫星可能即将碰撞，那么软件定义卫星可以执行相应的碰撞避让动作，例如，向右侧偏移运动，以防止碰撞。

其中，预设范围可以为以软件定义卫星为中心的预设范围。

(2)地面设施的完善

为解决海量的软件定义卫星运维的问题，需要不断完善的地面设施的支持。在现有的地面站设施的基础上，增加新型的地面设施，为海量软件定义卫星的运维提供便利和支撑，其中，新型的地面设施包括：

第一，超级基站：超级基站可以为改造后的第四代移动通信技术(the 4thgeneration mobile communication technology，4G)基站、第五代移动通信技术(5thgeneration mobile networks，5G)基站，超级基站可以与软件定义卫星100进行通信，从而可以实现软件定义卫星与超级基站的互联互通，从而实现卫星通信与手机通信等的网络一体化，降低通信时延，使用户可以更加便捷的访问和操控软件定义卫星。

第二，信标站：信标站为在轨运行的软件定义卫星提供自我标校的基准，包括星上时间、通信功率、接收延时、发送延时等，当软件定义卫星经过信标站的覆盖区域时，可以与信标站建立通信，根据信标站根据标准通信参数对软件定义卫星的通信参数进行校准，从而为软件定义卫星的在轨自主运行提供支持。

需要说明的是，信标站的覆盖区域例如可以为信标站所在区域的上方，信标站的覆盖区域可以根据预先划分规则确定，本实施例以区域的上方作为一种示例。

第三，总控站：总控站具有较强的通信带宽，可以为软件定义卫星的自主运行提供测控资源的分配等，软件定义卫星经过总控站时发出对测控资源的请求，总控站根据掌握的地面站测控情况进行资源的调度与分配，并向软件定义卫星发出资源分配的反馈。

第四，中央库设备：地面建立中央库设备对在轨运行的软件定义卫星进行集中管理，每颗软件定义卫星在轨运行时，按照约定的时间间隔，向中央库设备汇报自身的轨道、姿态等信息，供其他卫星访问使用，使得在轨运行的海量软件定义卫星可以更加方便快捷的感知其他卫星的信息、状态等，从而成为一个整体，更好的进行星上的自主管理和自主运行，完成更多的在轨任务。

(3)高效的运控云平台

运控云平台基于云计算等先进的互联网技术，为卫星的拥有者和使用者提供随时随地访问的途径，其面向的用户包括普通用户、运控员、管理员，普通用户可以基于该智能运控系统提出个性化的请求，运控员对软件定义卫星进行综合管理和应用服务，管理员进行人员管理、服务部署等。

相比于传统的卫星运维系统，这种软件定义卫星智能运控系统面向在轨运行的海量软件定义卫星，从星、地、云三方面着手建立智能运控系统。基于这样一套智能运控系统，可以实现以下的技术效果。

(1)减少地面运控的压力：在这种智能运控系统下，卫星具备相当的自主感知、自主决策、自主控制能力，对地面运控的请求减少，可以推动运控的高效自动化，实现越来越少的人管理越来越多的卫星。

(2)促进智能运控产业的良好生态：基于这样一套智能运控系统，可以实现多颗卫星，多个地面站的灵活加入和退出，有利于充分利用多个卫星、多个第三方地面站的空闲时隙，使卫星可以完成更多的在轨任务，地面站可以充分发挥作用，建立软件定义卫星智能运控的良好生态。

(3)促进软件定义智能运控的标准化：智能运控系统面向软件定义卫星，采用微服务架构，提供请求分析服务，通过将成像类、通信类等不同类型的请求进行标准化和原子化处理，可以满足多种类型的用户请求，促进软件定义卫星价值的发挥与体现。

下面结合几个具体实施例对本申请提供的软件定义卫星的运控系统进行详细说明。

图1示出了本申请实施例提供的软件定义卫星的运控系统的结构示意图一，如图1所示，软件定义卫星的运控系统10包括：

多个软件定义卫星100、云平台200、多个地面站300以及用户终端400；

其中，多个软件定义卫星100和多个地面站300、云平台200互相通信连接，云平台200还和用户终端400通信连接。

用户终端400被配置为，接收用户请求，并向云平台200发送用户请求，用户请求用于请求执行指定任务。

云平台200被配置为，从多个软件定义卫星100中确定执行指定任务的目标软件定义卫星110，从多个地面站300中确定满足目标软件定义卫星 110的使用时间的目标地面站310，并向目标地面站310发送用户请求。

目标地面站310被配置为，向目标软件定义卫星110发送用户请求。

目标软件定义卫星110被配置为，根据用户请求获取指定任务对应的业务数据，并依次通过目标地面站310和云平台200将业务数据发送给用户终端400。

其中，云平台200可以为运控云平台，用户终端400可以为来自车、船、飞机等服务用户的终端设备，用户可以通过用户终端400向云平台200 发送用户请求，用户请求例如可以包括通信请求、遥感请求、导航请求、等多种类型的请求，用户请求用于请求执行指定任务，指定任务例如可以包括通信任务、遥感任务、导航任务等。以遥感任务为例，用户请求中可以携带有拍摄参数，拍摄参数可以包括拍摄位置、拍摄时间、分辨率、帧频中的至少一种，拍摄位置例如可以为地区A，拍摄时间例如可以为1月1 日上午9点至12点。

云平台200被配置为，从多个软件定义卫星100中确定执行指定任务的目标软件定义卫星110，也就是说，云平台200可以评估多个软件定义卫星100是否可以执行指定任务，并从多个软件定义卫星100中确定可执行该指定任务的目标软件定义卫星110。

云平台200还被配置为，从多个地面站300中确定满足目标软件定义卫星110的使用时间的目标地面站310，并向目标地面站310发送用户请求，也就是说，云平台200还可以评估多个地面站300在目标软件定义卫星的使用时间的空闲程度，并从多个地面站300中确定满足目标软件定义卫星110的使用时间的目标地面站310，也即目标地面站310在目标软件定义卫星的使用时间内处于空闲状态。

目标地面站310被配置为，向目标软件定义卫星110发送用户请求。

目标软件定义卫星110被配置为，根据用户请求获取指定任务对应的业务数据，并依次通过目标地面站310和云平台200将业务数据发送给用户终端400，也就是说，目标软件定义卫星100将业务数据发送给目标地面站310，目标地面站310将业务数据转发给云平台200，由云平台200将业务数据转发给用户终端400。

以指定任务为遥感任务为例，指定任务对应的业务数据可以为地区A 的遥感成像图像；以指定任务为测量任务为例，指定任务对应的业务数据可以为目标软件定义卫星100的在轨运行数据。

可选地，云平台200还配置为：

对用户请求进行请求分析，获取指定任务对应的元任务，并将元任务映射为多个应用程序对应的任务。

目标软件定义卫星110被配置为，查询是否部署有多个应用程序，若否，则向目标地面站发送软件上注请求，软件上注请求中包括目标软件定义卫星未部署的目标应用程序的标识。

目标地面站被配置为，向云平台转发软件上注请求。

云平台200被配置为，根据软件上注请求，从航天应用商店中拉取目标应用程序的安装数据，并通过目标地面站向目标软件定义卫星发送目标应用程序的安装数据。

目标软件定义卫星被配置为，根据安装数据部署目标应用程序，并根据目标应用程序执行元任务。

具体地，云平台200还可以对用户请求进行请求分析，获取指定任务对应的元任务，并将元任务映射为多个应用程序对应的任务，也就是说，执行元任务需要多个应用程序的协同工作，其中，云平台200上可以安装有运控系统，通过运控系统可以对用户请求进行请求分析，并将指定任务对应的元任务映射为多个应用程序对应的任务，即执行该元任务需要启动多个应用程序。其中，运控系统是基于云平台200搭建的，随着云计算等互联网技术的快速发展，其与卫星产业也进行了极大程度的结合，运控系统将数据存储在云端，软件部署在云端，使用户可以随时随地的访问和使用整个运控系统；运控系统基于微服务架构搭建，易于软件的更新部署，那么可以为每个软件定义卫星构建一个独立的微服务，将软件定义卫星的加入与退出转换为服务的加载与停止；运控系统具有标准化、模块化的特点，使得更容易引入更加高效优质的资源分配等算法；采用微服务架构，提供请求分析服务，通过将不同类型的用户请求进行标准化，可以满足多种类型的用户请求，促进软件定义卫星价值的发挥与体现；基于微服务架构建立了完善的处理流程，该架构设计一方面具有足够的完备性，覆盖卫星运控的全流程，另一方面又具有足够的灵活性，可以满足高动态场景下的软件定义卫星的运控需求。

其中，请求分析可以包括两个步骤，第一步是将用户请求转换为预设格式，第二步是对格式转换后的用户请求进行分解或者合并，用户请求的分解指的是将用户请求对应的指定任务分解为多个元任务，用户请求的合并指的是根据不同的用户请求之间的相关性将多个用户请求对应的指定任务进行合并。

作为一种示例，若用户请求用于请求对北京地区的建筑物进行连续10 天的拍摄，那么可以将该用户请求进行格式转换，对格式转换后的用户请求进行分解，以将对应的指定任务分解为多个元任务，多个元任务可以为1 月1日对北京地区的建筑物进行拍摄，1月2日对北京地区的建筑物进行拍摄……1月10对北京地区的建筑物进行拍摄，然后可以将各元任务映射为多个应用程序对应的任务，例如，对于元任务“1月1日对北京地区的建筑物进行拍摄”，执行该元任务需要启动的应用程序可以包括照相机。

作为另一种示例，若云平台210还可以接收其他用户终端发送的其他用户请求，该用户请求用于请求对北京地区的建筑物进行拍摄，其他用户请求用于请求软件定义卫星对鸟巢进行拍摄，那么可以将用户请求和其他用户请求分别格式转换，并将格式转换后的该用户请求和其他格式转换后的用户请求合并为一个用户请求，即该指定任务的元任务，元任务为对鸟巢进行拍摄，执行该元任务需要启动的应用程序可以包括照相机。

目标软件定义卫星110被配置为，查询是否部署有多个应用程序，若否，则向目标地面站310发送软件上注请求，也就是说，确定出目标软件定义卫星110之后，目标软件定义卫星需要查询星上是否部署有执行元任务的多个应用程序，若缺乏某个应用程序，则目标软件定义卫星110可以向目标地面站310发送软件上注请求，软件上注请求中包括目标软件定义卫星未部署的目标应用程序的标识。

目标地面站310被配置为，向云平台200转发软件上注请求。

云平台200被配置为，根据软件上注请求，从航天应用商店中拉取目标应用程序的安装数据，并通过目标地面站310向目标软件定义卫星110 发送目标应用程序的安装数据。

其中，目标软件定义卫星110在缺乏某个应用程序，即目标应用程序时，可以向地面下发软件上注请求，云平台200根据软件上注请求，可以从航天应用商店拉取目标应用程序的安装数据，其中，航天应用商店可以安装在一设备上，云平台200可以从该设备中的航天应用商店中拉取目标应用程序的安装数据，该安装数据可以为安装包，然后云平台200可以通过目标地面站310向目标软件定义卫星110发送该安装数据，即将安装数据上注至星上。

目标软件定义卫星110被配置为，根据安装数据部署目标应用程序，并根据目标应用程序执行元任务，也就是说，目标软件定义卫星110根据接收到的安装数据可以在星上部署目标应用程序，并根据目标应用程序执行元任务。

可选地，云平台200具体被配置为：

根据多个软件定义卫星100的在轨运行数据，从多个软件定义卫星100 中确定可执行元任务的至少一个执行软件定义卫星，并向每个可执行的软件定义卫星发送是否执行元任务的询问请求。

至少一个执行软件定义卫星被配置为，自主判断是否确定执行元任务，若至少一个执行软件定义卫星中存在任一软件定义卫星确定执行元任务，则任一软件定义卫星向云平台发送执行元任务的指示信息。

云平台200被配置为，将任一软件定义卫星作为目标软件定义卫星110。

其中，在轨运行数据可以包括运行参数，云平台200根据在轨运行数据可以进行卫星资源预分配，具体地，根据多个软件定义卫星100的在轨运行数据，从多个软件定义卫星100中确定可执行元任务的至少一个执行软件定义卫星，其中，可执行元任务的执行软件定义卫星的在轨运行数据满足预设条件，因此，云平台200可以根据卫星的在轨运行数据，以确定可执行元任务的至少一个执行软件定义卫星。以及并向每个可执行的软件定义卫星发送是否执行元任务的询问请求，也就是说，每个可执行的软件定义卫星自主判断是否可以完成该元任务，以进行“抢单”。

至少一个执行软件定义卫星被配置为，自主判断是否确定执行元任务，若至少一个执行软件定义卫星中存在任一软件定义卫星确定执行元任务，则任一软件定义卫星向云平台200发送执行元任务的指示信息，也就是说，星上进行自主任务规划，判断是否可以完成该元任务，当可以完成时进行“抢单”，也即任一软件定义卫星可“抢单”时，则执行“抢单”的任一软件定义卫星则向云平台200发送执行元任务的指示信息，云平台200被配置为，将该任一软件定义卫星作为目标软件定义卫星110。

在“抢单”成功后，目标软件定义卫星110可以通过部署启动应用程序的方式完成该元任务，关于部署应用程序的方式可以参见上述描述。

可选地，云平台200具体被配置为：

根据预设解析规则，对业务数据进行解析处理，得到解析之后的业务数据，向用户终端发送解析之后的业务数据。

具体地，星上生成业务数据之后，申请下传业务数据，基于地面站资源实时调度服务分配的目标地面站310可以将业务数据下传至云平台200，云平台200获取到业务数据，可以对该业务数据进行后处理，即根据预设解析规则，对业务数据进行解析处理，得到解析之后的业务数据，向用户终端400发送解析之后的业务数据。

需要说明的是，预设解析规则可以由目标软件定义卫星110的数据传输格式而定，不同的软件定义卫星可以具有不同的数据传输格式。

可选地，云平台200还被配置为：

根据业务数据对目标软件定义卫星110进行故障诊断与健康评估。

具体地，云平台200可以存储故障类型和业务数据之间的对应关系，那么在接收到业务数据时，通过查询该对应关系，可以确定目标软件定义卫星110的故障类型，即对目标软件定义卫星110进行故障诊断。

此外，云平台210可以存储目标软件定义卫星110的预设业务数据，那么还根据接收到的业务数据和预设业务数据，对目标软件定义卫星110 进行健康评估，获取目标软件定义卫星110的健康评估结果，其中，预设业务数据可以为目标软件定义卫星100处于健康状态的业务数据。本实施例对故障诊断和健康评估的具体方式不做特别限定。

当然，云平台200还可以将故障类型和健康评估结果发送给用户终端 400，以便用户获知目标软件定义卫星110的健康状态。

本实施例的软件定义卫星的运控系统，包括：多个软件定义卫星、云平台、多个地面站以及用户终端，其中，多个软件定义卫星和多个地面站、云平台互相通信连接，云平台还和用户终端通信连接，用户终端被配置为，接收用户请求，并向云平台发送用户请求，用户请求用于请求执行指定任务，云平台被配置为，从多个软件定义卫星中确定执行指定任务的目标软件定义卫星，从多个地面站中确定满足目标软件定义卫星的使用时间的目标地面站，并向目标地面站发送用户请求，目标地面站被配置为，向目标软件定义卫星发送用户请求，目标软件定义卫星被配置为，根据用户请求获取指定任务对应的业务数据，并依次通过目标地面站和云平台将业务数据发送给用户终端。在本实施例，通过建立一种新的卫星运控模式，减小了软件定义卫星对地面站的压力，以应对大规模软件定义卫星的运维的需要。

图2示出了本申请实施例提供的软件定义卫星的运控系统的结构示意图二，如图2所示，软件定义卫星的运控系统10还包括：总控站500。

总控站500和目标软件定义卫星110、云平台200通信连接。

目标软件定义卫星110还被配置为，在自主运行过程中若需要地面进行干预或需要向地面下传数据，则在经过总控站500时，向总控站500发送地面站资源使用请求，地面站资源使用请求中包括目标软件定义卫星110 对地面站资源的使用时间。

总控站500被配置为，向云平台200发送地面站资源使用请求。

云平台200被配置为，根据地面站资源使用请求，从多个地面站300 中确定满足使用时间的多个可用地面站，并从多个可用地面站中确定目标地面站310。

具体地，目标软件定义卫星110在自主运行过程中若需要地面进行干预或需要向地面下传数据，则可以在经过总控站500的覆盖区域时，向总控站500发送地面站资源使用请求，地面站资源使用请求中包括目标软件定义卫星110对地面站资源的使用时间，其中，目标软件定义卫星110对地面站资源的使用时间包括目标软件定义卫星110通过地面站资源下传业务数据的时间。

总控站500可以向云平台200转发地面站资源使用请求，云平台200 根据地面站资源使用请求，从多个地面站300中确定满足使用时间的多个可用地面站，并从多个可用地面站中确定目标地面站310，也就是说，云平台200根据目标软件定义卫星110对地面站资源的使用时间，可以从多个地面站300中确定在该使用时间内处于空闲状态的多个可用地面站，然后随机或者按照预设筛选规则，从多个可用地面站中确定目标地面站310。

可选地，云平台200还被配置为：

向目标软件定义卫星110和目标地面站310发送调度结果，调度结果用于指示目标软件定义卫星110在使用时间内使用目标地面站310。

需要说明的是，总控站500可以具有较强的通信带宽，用于给目标软件定义卫星110的自主运动提供资源分配等。在实际应用中，目标软件定义卫星1100在经过总控站400的覆盖区域时，可以通过总控站400向云平台200发送地面站资源使用请求，以请求云平台200根据掌握的地面站资源的使用情况，进行资源的调度与分配，云平台200确定出目标地面站310 之后，还可以向目标软件定义卫星110和目标地面站310发送调度结果，以指示目标软件定义卫星110在使用时间内使用目标地面站310，这样，以便目标软件定义卫星110和目标地面站310在该使用时间内调整各自的信号接收方向等，以更好地进行数据传输。

需要说明的是，总控站500的覆盖区域例如可以为总控站500所在区域的上方，例如北京地区的上方，总控站的覆盖区域可以根据预先划分规则确定，本实施例以区域的上方作为一种示例。

其中，可用地面站在该使用时间为空闲状态，也就是，总控站210可以根据管理的多个地面站的空闲情况进行地面站资源的调度与分配，以确定出在目标软件定义卫星110对地面站资源的使用时间处于空闲状态的多个可用地面站。

当然，目标软件定义卫星110在需要地面干预时，也可以通过上述方式确定目标地面站310，以请求总控站500分配地面站资源，这样即可由分配的目标地面站310在该使用时间内对目标软件定义卫星110进行异常修复。

本实施例的软件定义卫星的运控系统，还包括：总控站，总控站目标软件定义卫星、云平台通信连接，目标软件定义卫星还被配置为，在自主运行过程中若需要地面进行干预或需要向地面下传数据，则在经过总控站时，向总控站发送地面站资源使用请求，地面站资源使用请求中包括目标软件定义卫星对地面站资源的使用时间，总控站被配置为，向云平台发送地面站资源使用请求，云平台被配置为，根据地面站资源使用请求，从多个地面站中确定满足使用时间的多个可用地面站，并从多个可用地面站中确定目标地面站。在本实施例，通过动态规划，改变了传统的地面站资源静态预分配的方式，而是根据地面站资源分配请求进行地面站资源的动态分配，实现了地面站资源的最大化利用，并且可以为多颗卫星提供运控服务，又可以充分利用地面站的空闲时隙，发挥其价值。

图3示出了本申请实施例提供的软件定义卫星的运控系统的结构示意图三，如图3所示，软件定义卫星的运控系统10还包括：信标站600。

信标站600和目标软件定义卫星110通信连接。

信标站600被配置为，在目标软件定义卫星110经过信标站600时，对目标软件定义卫星110的通信参数进行校准。

其中，软件定义卫星100的通信参数例如可以包括通信时间、通信功率、接收延时、发送延时等，信标站600可以为目标软件定义卫星110提供自我标校的基准，若目标软件定义卫星110经过信标站600的覆盖区域时，可以与信标站600建立通信连接，根据信标站600根据标准通信参数对目标软件定义卫星110的通信参数进行校准，从而为目标软件定义卫星 110的在轨自主运行提供支持。

具体地，若目标软件定义卫星110经过信标站600的覆盖区域，则信标站600可以获取目标软件定义卫星110的工作模式和通信参数，并确定该工作模式对应的标准通信参数，然后根据该工作模式的标准通信参数对目标软件定义卫星110的通信参数进行校准，也即将目标软件定义卫星110 的通信参数调整为标准通信参数。

需要说明的是，信标站的覆盖区域例如可以为信标站所在区域的上方，信标站的覆盖区域可以根据预先划分规则确定，本实施例以区域的上方作为一种示例。

本实施例的软件定义卫星的运控系统，还包括：信标站，信标站和目标软件定义卫星通信连接，信标站被配置为，在目标软件定义卫星经过信标站时，对目标软件定义卫星的通信参数进行校准。在本实施例，面向海量软件定义卫星运维的问题，通过提供信标站以支持星上以及星间的自主运。

图4示出了本申请实施例提供的软件定义卫星的运控系统的结构示意图四，如图4所示，软件定义卫星的运控系统10还包括：中央库设备700。

中央库设备700和目标软件定义卫星110通信连接。

目标软件定义卫星110还被配置为，按照预设时间间隔向中央库设备 700发送在轨运行数据。

中央库设备700可以对在轨运行的软件定义卫星进行集中管理。每颗软件定义卫星在轨运行时，按照约定时间间隔，可以向中央库设备80汇报自身的运行参数、姿态信息等，以供其他卫星访问使用，这样，海量的在轨运行的软件定义卫星可以更加方便快捷地感知其他卫星，从而使得海量的在轨运行的软件定义卫星成为一个整体，更好地进行自主管理和自主运行，完成更多的在轨任务，在轨任务例如可以包括碰撞预警。

其中，目标软件定义卫星110的在轨运行数据可以包括目标软件定义卫星110的运行参数，例如可以包括目标软件定义卫星110的当前位置、当前速度以及当前姿态。

中央库设备700可以与多个在轨运行的软件定义卫星建立通信连接，目标软件定义卫星110在轨运行过程中可以实时或每隔约定时间间隔向中央库设备发送目标软件定义卫星110的在轨运行数据，这样，其它软件定义卫星可以从中央库设备700中获取目标软件定义卫星110的在轨运行数据，并根据目标软件定义卫星110的在轨运行数据，预测目标软件定义卫星110在指定时间的位置、速度以及姿态，进而进行碰撞预警。

其中，目标软件定义卫星110的当前位置和当前速度可以采用J2000 坐标系下的(x，y，z，vx，vy，vz)表示。其中x是指x坐标，y是指y 坐标，z是指z坐标，vx是指x轴上的速度，vy是指y轴上的速度，vz是指z轴上的速度。

姿态是指卫星本体坐标系相对某个指定的坐标系下的旋转角度。通常采用欧拉角或者四元数的形式表示，姿态信息可以包括当前时间、定向方式、旋转顺序、参考坐标系、欧拉角、四元数。

当然，目标软件定义卫星110还可以向中央库设备700发送通信频段，以便其它软件定义卫星通过访问中央库设备700以获取软件定义卫星100 的通信频段，并在该通信频段与目标软件定义卫星110进行通信。

本实施例的软件定义卫星的运控系统，还包括：中央库设备，中央库设备和目标软件定义卫星通信连接，目标软件定义卫星还被配置为，按照预设时间间隔向中央库设备发送在轨运行数据。在本实施例，面向海量软件定义卫星运维的问题，通过提供中央库设备以支持星上以及星间的自主运。

基于上述实施例提供的软件定义卫星的运控系统，本申请还提供了一种软件定义卫星的运控方法，图5示出了本申请实施例提供的软件定义卫星的运控方法的流程示意图，软件定义卫星的运控方法应用于上述实施例的软件定义卫星的运控系统，运控系统包括：多个软件定义卫星、云平台、多个地面站以及用户终端。

如图5所示，该方法可以包括：

S11、用户终端接收用户请求，并向云平台发送用户请求，用户请求用于请求执行指定任务。

S12、云平台从多个软件定义卫星中确定执行指定任务的目标软件定义卫星，从多个地面站中确定满足目标软件定义卫星的使用时间的目标地面站，并向目标地面站发送用户请求。

S13、目标地面站向目标软件定义卫星发送用户请求。

S14、目标软件定义卫星根据用户请求获取指定任务对应的业务数据，并依次通过目标地面站和云平台将业务数据发送给用户终端。

本实施例的软件定义卫星的运控方法，实现原理和实现过程可以参见上述实施例提供的软件定义卫星的运控系统，在此不再赘述。

本申请实施例还提供了一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。

Claims (9)

1.一种软件定义卫星的运控系统，其特征在于，所述运控系统包括：多个软件定义卫星、云平台、多个地面站以及用户终端；

其中，所述多个软件定义卫星和所述多个地面站、所述云平台互相通信连接，所述云平台还和所述用户终端通信连接；

所述用户终端被配置为，接收用户请求，并向所述云平台发送所述用户请求，所述用户请求用于请求执行指定任务；

所述云平台被配置为，从所述多个软件定义卫星中确定执行所述指定任务的目标软件定义卫星，从所述多个地面站中确定满足所述目标软件定义卫星的使用时间的目标地面站，并向所述目标地面站发送所述用户请求；

所述目标地面站被配置为，向所述目标软件定义卫星发送所述用户请求；

所述目标软件定义卫星被配置为，根据所述用户请求获取所述指定任务对应的业务数据，并依次通过所述目标地面站和所述云平台将所述业务数据发送给所述用户终端；

所述运控系统还包括：总控站；

所述总控站和所述目标软件定义卫星、所述云平台通信连接；

所述目标软件定义卫星还被配置为，在自主运行过程中若需要地面进行干预或需要向地面下传数据，则在经过所述总控站时，向所述总控站发送地面站资源使用请求，所述地面站资源使用请求中包括所述目标软件定义卫星对地面站资源的使用时间；

所述总控站被配置为，向所述云平台发送所述地面站资源使用请求；

所述云平台被配置为，根据所述地面站资源使用请求，从所述多个地面站中确定满足所述使用时间的多个可用地面站，并从所述多个可用地面站中确定所述目标地面站。

2.根据权利要求1所述的运控系统，其特征在于，所述云平台还配置为：

对所述用户请求进行请求分析，获取所述指定任务对应的元任务，并将所述元任务映射为多个应用程序对应的任务；

所述目标软件定义卫星被配置为，查询是否部署有所述多个应用程序，若否，则向所述目标地面站发送软件上注请求，所述软件上注请求中包括所述目标软件定义卫星未部署的目标应用程序的标识；

所述目标地面站被配置为，向所述云平台转发所述软件上注请求；

所述云平台被配置为，根据所述软件上注请求，从航天应用商店中拉取所述目标应用程序的安装数据，并通过所述目标地面站向所述目标软件定义卫星发送所述目标应用程序的安装数据；

所述目标软件定义卫星被配置为，根据所述安装数据部署所述目标应用程序，并根据目标应用程序执行所述元任务。

3.根据权利要求2所述的运控系统，其特征在于，所述云平台具体被配置为：

根据所述多个软件定义卫星的在轨运行数据，从所述多个软件定义卫星中确定可执行所述元任务的至少一个执行软件定义卫星，并向每个可执行的软件定义卫星发送是否执行所述元任务的询问请求；

所述至少一个执行软件定义卫星被配置为，自主判断是否确定执行所述元任务，若所述至少一个执行软件定义卫星中存在任一软件定义卫星确定执行所述元任务，则所述任一软件定义卫星向所述云平台发送执行所述元任务的指示信息；

所述云平台被配置为，将所述任一软件定义卫星作为所述目标软件定义卫星。

4.根据权利要求1所述的运控系统，其特征在于，所述云平台还被配置为：

向所述目标软件定义卫星和所述目标地面站发送调度结果，所述调度结果用于指示所述目标软件定义卫星在所述使用时间内使用所述目标地面站。

5.根据权利要求1所述的运控系统，其特征在于，所述运控系统还包括：信标站；

所述信标站和所述目标软件定义卫星通信连接；

所述信标站被配置为，在所述目标软件定义卫星经过所述信标站时，对所述目标软件定义卫星的通信参数进行校准。

6.根据权利要求1所述的运控系统，其特征在于，所述运控系统还包括：中央库设备；

所述中央库设备和所述目标软件定义卫星通信连接；

所述目标软件定义卫星还被配置为，按照预设时间间隔向所述中央库设备发送在轨运行数据。

7.根据权利要求2所述的运控系统，其特征在于，所述云平台具体被配置为：

根据预设解析规则，对所述业务数据进行解析处理，得到解析之后的业务数据，向所述用户终端发送所述解析之后的业务数据。

8.根据权利要求1所述的运控系统，其特征在于，所述云平台还被配置为：

根据所述业务数据对所述目标软件定义卫星进行故障诊断与健康评估。

9.一种软件定义卫星的运控方法，其特征在于，应用于权利要求1-8任一项所述的软件定义卫星的运控系统，所述运控系统包括：多个软件定义卫星、云平台、多个地面站以及用户终端，所述方法包括：

所述用户终端接收用户请求，并向所述云平台发送所述用户请求，所述用户请求用于请求执行指定任务；

所述云平台从所述多个软件定义卫星中确定执行所述指定任务的目标软件定义卫星，从所述多个地面站中确定满足所述目标软件定义卫星的使用时间的目标地面站，并向所述目标地面站发送所述用户请求；

所述目标地面站向所述目标软件定义卫星发送所述用户请求；

所述目标软件定义卫星根据所述用户请求获取所述指定任务对应的业务数据，并依次通过所述目标地面站和所述云平台将所述业务数据发送给所述用户终端；

所述运控系统还包括：总控站；

在自主运行过程中若需要地面进行干预或需要向地面下传数据，则所述目标软件定义卫星在经过所述总控站时，向所述总控站发送地面站资源使用请求，所述地面站资源使用请求中包括所述目标软件定义卫星对地面站资源的使用时间；

所述总控站向所述云平台发送所述地面站资源使用请求；

所述云平台根据所述地面站资源使用请求，从所述多个地面站中确定满足所述使用时间的多个可用地面站，并从所述多个可用地面站中确定所述目标地面站。

Images