面向大规模星座的卫星在轨自主管理方法、装置及介质

技术领域

本发明实施例涉及航天器自主管理技术领域，尤其涉及一种面向大规模星座的卫星在轨自主管理方法、装置及介质。

背景技术

传统的卫星系统通常只有单星，或者是由少量的几颗至几十颗卫星组成小规模卫星星座。随着商业航天的兴起，未来的空间段将会是由几百、几千甚至上万颗卫星组成的大规模卫星星座；这些卫星星座的业务范围包含通信、导航、遥感和混合业务等。然而，目前常规的卫星管理及控制方案大都是通过地面站在卫星可见期间向目标卫星上注控制指令或控制信息，人力物力资源消耗过大，管控效率低，难以适应大规模星座的管控场景。因此，目前需要在大规模星座场景下，提供卫星能够在轨进行部分甚至全部管理任务的方案。

发明内容

有鉴于此，本发明实施例期望提供一种面向大规模星座的卫星在轨自主管理方法、装置及介质；能够在星上完成部分在轨管理任务，提高了大规模星座管控效率。

本发明实施例的技术方案是这样实现的：

第一方面，本发明实施例提供了一种面向大规模星座的卫星在轨自主管理装置，所述装置应用于大规模星座的中每一个卫星，所述装置包括：数据存储部分、管控部分以及数据传输部分；其中，

所述数据存储部分，用于将设定回溯日期内本星的星上分系统数据进行存储；

所述管理部分，经配置为基于所述星上分系统数据对应的故障检测类型配置通用故障诊断模型，并根据配置后的通用故障诊断模型通过对应的星上分系统数据进行故障诊断，获得故障诊断结果；

以及，根据本星姿轨分系统所测量获得轨道数据以及本星的构型数据生成星座构型控制数据；

以及，维护用于进行数据传输的卫星间路由表；

所述数据传输部分，经配置为将需下传的星上分系统数据按照需下传的数据通道对应的通信协议进行组帧，获得下传数据帧，并将所述下传数据帧传输至对应的数据通道以进行下传。

第二方面，本发明实施例提供了一种面向大规模星座的卫星在轨自主管理方法，所述方法应用于第一方面所述的面向大规模星座的卫星在轨自主管理装置，所述方法包括：

将设定回溯日期内本星的星上分系统数据进行存储；

基于所述星上分系统数据对应的故障检测类型配置通用故障诊断模型，并根据配置后的通用故障诊断模型通过对应的星上分系统数据进行故障诊断，获得故障诊断结果；

根据本星姿轨分系统所测量获得轨道数据以及本星的构型数据生成星座构型控制数据；

维护用于进行数据传输的卫星间路由表；

将需下传的星上分系统数据按照需下传的数据通道对应的通信协议进行组帧，获得下传数据帧，并将所述下传数据帧传输至对应的数据通道以进行下传。

第三方面，本发明实施例提供了一种计算机存储介质，所述计算机存储介质存储有面向大规模星座的卫星在轨自主管理程序，所述面向大规模星座的卫星在轨自主管理程序被至少一个处理器执行时实现第二方面所述面向大规模星座的卫星在轨自主管理方法步骤。

本发明实施例提供了一种面向大规模星座的卫星在轨自主管理方法、装置及介质；通过数据存储部分以及管理部分实现在星上自主完成一些或全部的管理任务，无需再等待进入地面站可见区域后，通过与地面站的数据互传以完成星座管理任务，提高了管控效率；此外，在实施过程中即便仍然存在需要与地面站进行数据互传的情况，也因为管理任务在星上自主完成，而降低了互传的数据量，从而降低了资源消耗。

附图说明

图1为本发明实施例提供的大规模卫星星座系统组成示意图；

图2为本发明实施例提供的一种面向大规模星座的卫星在轨自主管理装置组成示意图；

图3为本发明实施例提供的另一种面向大规模星座的卫星在轨自主管理装置组成示意图；

图4为本发明实施例提供的存储空间的划分示意图；

图5为本发明实施例提供的存储区的划分示意图；

图6为本发明实施例提供的数据抽取流程示意图；

图7为本发明实施例提供的故障诊断流程示意图；

图8为本发明实施例提供的一种面向大规模星座的卫星在轨自主管理方法流程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

如图1所示的大规模卫星星座系统1，至少包括N个轨道，图1中仅示出虚线和点划线分别所示的两个轨道，其他轨道不再示出。各轨道之间的轨道高度和/或轨道倾角均不相同，每个轨道上布设有多个卫星，如图1中，在虚线所示的轨道中，包括M1颗卫星，图中仅示出六颗卫星，分别标识为：S11、S12、S13、S14、S15和S16，其余卫星因为地球遮挡而未示出；在点划线所示的轨道中，包括M2颗卫星，图中仅示出五颗卫星，分别标识为S21、S22、S23、S24和S25，其余卫星同样因为地球遮挡而未示出。面对图1所示的大规模卫星星座1的众多卫星，在需要对其进行管控时，常规方案均是当卫星运行至地面站11可见区域时，通过测控数据通道实现卫星与地面站11之间的信息交互，造成了资源消耗过大，管控效率低的问题，难以适应大规模星座的管控场景。

基于此，本发明实施例期望为每颗卫星均对应设置一在轨自主管理装置，从而凭借卫星的星上计算资源完成部分设置全部的管控任务，从而提高大规模卫星星座的管控效率。有鉴于此，参见图2，其示出了本发明实施例提供的一种面向大规模星座的卫星在轨自主管理装置20，该装置20具体可以实施为独立的具备数据存储及数据处理功能的单机设备，也可以作为星载计算机中的一个能够独立运行的软件模块，本发明实施例对此不做限定；而且该装置20可以应用于图1中所示星座中的任一颗卫星，该装置20可以包括：数据存储部分201、管理部分202以及数据传输部分203；其中，

所述数据存储部分201，用于将设定回溯日期内本星的星上分系统数据进行存储；

所述管理部分202，经配置为基于所述星上分系统数据对应的故障检测类型配置通用故障诊断模型，并根据配置后的通用故障诊断模型通过对应的星上分系统数据进行故障诊断，获得故障诊断结果；

以及，根据本星姿轨分系统所测量获得轨道数据以及本星的构型数据生成星座构型控制数据；

以及，维护用于进行数据传输的卫星间路由表；

所述数据传输部分203，经配置为将需下传的星上分系统数据按照需下传的数据通道对应的通信协议进行组帧，获得下传数据帧，并将所述下传数据帧传输至对应的数据通道以进行下传。

通过图2所示的技术方案，通过数据存储部分201以及管理部分202实现在星上自主完成一些或全部的管理任务，无需再等待进入地面站可见区域后，通过与地面站的数据互传以完成星座管理任务，提高了管控效率；此外，图2的技术方案在实施过程中即便仍然存在需要与地面站进行数据互传的情况，也因为管理任务在星上自主完成，而降低了互传的数据量，从而降低了资源消耗。

对于图2所示的技术方案，在一些示例中，参见图3，所述数据存储部分201包括被划分为多个数据存储区的本星存储空间2011；其中，每个存储区对应设定回溯日期内的一个日期区间，每个存储区中的数据完整度与对应日期区间距离当前时刻的远近程度相关。

在一些示例中，每个存储区均包括与星上分系统对应的存储块，每个存储块的容量与对应星上分系统的数据总量相对应；相应地，继续参见图3，所述数据存储部分201还包括：数据抽取单元2012，经配置为：

当相邻数据完整度中较高完整度所对应的存储区内存在数据已满的存储块，则在向所述数据已满的存储块存入数据过程中，将所述数据已满的存储块尾部的部分数据帧按照对应的完整度进行删除，并将所述数据已满的存储块尾部的另一部分数据帧按照相邻数据完整度中较低完整度进行抽取并存入较低完整度所对应的存储区内对应相同星上分系统的存储块。

对于上述示例，可以理解地，本星的星上分系统数据可以通过卫星的数据总线存储在存储空间内，该存储空间可以被实施为大容量的固态存储器，数据总线的接口形式可以包括但不限于CAN总线、RS485总线、I2C总线、RS422接口等。需要说明的是，若数据保存的时间过长，则将导致存储容量需求过大；若数据的保存时间过短，当卫星产生问题时，可能无法追溯至问题产生时刻的数据，也就失去了数据存储的意义。因此，为了权衡数据存储容量和存储时间的关系，本发明实施例将存储空间划分为多个存储区，每个存储区均对应存储回溯日期内的一个日期区间内的卫星数据，为了提高回溯日期的长度，可以将存储距离当前时刻越远的日期区间的存储区内的数据完整度设置为最低，存储距离当前时刻越近的日期区间的存储区内的数据完整度设置为最高，举例来说，按CAN总线速率500kbps最大负载的20％计算，24h的原始数据量约为1.03GB，6GB容量的存储空间至多能够满负载存储6天的全部原始数据；但如图4所示，将存储空间划分为3个存储区，每个存储区的容量均为2GB，第一存储区(区1)用于存储最接近当前时刻日期区间(如距当前时刻2天以内)所产生原始数据，该部分数据可以无差别的全部存储至区1，即数据完整度为100％；第二存储区(区2)用于存储中期(如距当前时刻3天至6天以内)产生的数据，该部分数据可以按星上分系统标识(nID)进行50％的抽取之后存储至区2，即数据完整度为50％；第三存储区(区3)用于存储远早期(如距当前时刻7天至14天以内)产生的数据，该部分数据可以按星上分系统标识(nID)进行25％的抽取之后存储至区3，即数据完整度为25％。如此，原先存储空间能够满负载存储6天的全部原始数据，通过时间远近以及完整度之间的对应关系进行抽取存储，就能够保存最长回溯至14天内的数据。

针对图4中所示的任一存储区，详细来说，可以按照星上分系统对应划分存储块，每个存储块对应一星上分系统标识(nID)，每个nID对应的存储块容量并非平均划分，而是按照各星上分系统(比如单机、载荷、平台中心等)在24h内CAN总线最大负载20％的发送数据总量进行划分，基于此，以第一存储区(区1)为例，如图5所示，星上分系统标识nID可以通过00-FF进行表示，区1中的每个nID对应的存储块容量均不相同，该容量与存储块对应的星上分系统的发送数据量的大小相对应；可以理解地，对于其他存储区，均可以按照图4所示的容量比例分别对每个星上分系统标识nID所对应的存储块进行划分，也就是说，在不同的存储区中，相同nID所对应的存储块的容量相同。

结合图4以及图5所示的存储区和存储块，详细来说，如图6所示的流程示意图，数据抽取单元可以如实线箭头1所示从数据总线接收nID 00所发送的数据帧，并存储于区1中与nID 00对应的存储块；若区1中与nID 00对应的存储块已满，则需要将该存储块中距离当前时刻较远的数据帧抽取并转存至区2中与nID 00对应的存储块，具体来说，当区1中与nID00对应的存储块已满，则启动接收数据次数的计数器；每当计数器为奇数，则将区1中与nID00对应的存储块的尾部数据帧进行组包，并如实线箭头2所示转存至区2中与nID 00对应的存储块；每当计数器为偶数，则如虚线箭头1所示将区1中与nID 00对应的存储块的尾部数据帧删除；从而实现了从区1数据至区2数据由完整度100％到50％的数据抽取。

相应地，若区2中与nID 00对应的存储块已满，数据抽取单元则需要将该存储块中距离当前时刻较远的数据帧抽取并转存至区3中与nID 00对应的存储块，具体来说，当区2中与nID 00对应的存储块已满，则启动接收数据次数的计数器；每当计数器为奇数，则将区2中与nID 00对应的存储块的尾部数据帧进行组包，并如实线箭头3所示转存至区3中与nID00对应的存储块；每当计数器为偶数，则如虚线箭头2将区2中与nID 00对应的存储块的尾部数据帧删除；从而实现了从区2数据至区3数据由完整度50％到25％的数据抽取。

相应地，若区3中与nID 00对应的存储块已满，则可以如虚线箭头3所示将与nID00对应的存储块内的尾部数据帧删除。

在一些示例中，参见图3，所述数据存储部分201还包括：与本星相邻的设定数目的邻星各自对应的邻星存储空间2013；相应地，每个邻星存储空间被划分为多个数据存储区，且每个存储区对应设定回溯日期内的一个日期区间，每个存储区中的数据完整度与对应日期区间距离当前时刻的远近程度相关；每个存储区均包括与邻星的星上分系统对应的存储块，每个存储块的容量与对应邻星星上分系统的数据总量相对应。

对于上述示例，需要说明的是，若数据仅存储在卫星本地，当卫星产生严重故障，无法响应指令进行数据下传时，那么存储的数据便失去了意义。因此，为了保证存储数据的可靠下传，实现对失效卫星的数据回溯，从而完成相关数据分析与问题定位，为后续卫星优化设计奠定基础，需要对存储的数据进行备份。与传统的数据备份方式不同的是，本发明实施例采用邻近备份的方式，将所存储的数据备份在邻近的卫星上。一般在大规模星座中，每颗卫星(本星)均可通过星间激光与周围四颗卫星(同轨两颗，异轨两颗，可称之为邻星)建立稳定的通信链路用于数据交换。当本地数据量达到一个最小存储单位时(如一个扇区、一个固定大小的文件等)，本星可以通过四个激光终端将数据备份至邻近四颗卫星，本星只负责将原始数据发送至邻星，由邻星采用前述相同的抽取策略完成数据抽取。可以理解地，由于每颗卫星需要存储五颗卫星(即一颗本星+四颗邻星)的数据，若按前述图4至图6所示的CAN总线数据量计算，每颗星需要的固存不应小于30GB，也就是说，目前航天用的大容量存储器完全可以满足上述备份的需求。

对于图2所示的技术方案，在一些示例中，继续参见图3所示，所述面向大规模星座的卫星在轨自主管理装置20还包括：数据标准化部分204，经配置为：将星上分系统数据增加本星在星座中的编号信息以及对应的星上分系统标识信息，形成星上分系统的初级标准化数据；

将所述初级标准化数据按照设定的对应于星上分系统的数据格式配置进行转化，形成统一数据格式的标准化数据。

对于上述示例，具体来说，数据标准化部分将不同厂商生产的卫星、不同组成的卫星数据进行了统一，可以有效降低星座管控难度，同时为统一进行星座各节点健康管理与构型管理提供了数据前提。详细来说，首先，需要对同一星座内卫星进行统一编号，共4字节，具体定义如表1所示：

表1

在表1中，将星座轨道按照轨道高度与轨道倾角两个因素进行划分，例如，编号为1表示高度为500km、倾角为87°的轨道，编号为2表示高度为500km、倾角为60°的轨道，编号为3表示高度为1150km、倾角为60°的轨道等等。1字节可表示256种轨道类型，预留1字节用于扩展；在同类型轨道下，不同的升交点赤经表示不同的轨道面，在本实施例中，可以设定升交点赤经最接近0度的轨道编号为1，沿着升交点赤经增大的方向编号依次递增；对于同轨卫星，不同卫星可以通过不同编号进行区分，在本实施例中，可以设定在某一约定的时刻下，相位正向最接近0度的卫星编号为1，沿着轨道运行方向编号依次递增。如此，就能够形成本星在星座中的编号信息，从而将区分明确星座中具体卫星的下传数据。

接着，对于卫星内，可以按照星上分系统标识对应的标识字段由中心机进行统一分配，以区分不同星上分系统的数据；举例来说，AXH字段用于非控制实体单机编号，比如热控-A0H，电源-A1H，USB测控-A2H、A3H，相机下位机-A4H，数传-A5H，压缩-A6H，UXB测控-A7H，UV测控-A8H、A9H；BXH与CXH字段用于姿轨控单机编号，比如太阳敏感器-B0H、B1H，GPS-B2H，星敏B3H～B5H，陀螺B6H～B8H，飞轮B9H～BEH，磁强计BFH，电推-C0H；EXH字段用于虚拟单机编号，比如星务-E0H，姿轨控-E1H，时间系统-E2H；9XH字段用于通信载荷类单机编号，8XH字段用于导航载荷类单机编号等。通过上述字段编号，结合前述的卫星编号，就能够区分明确具体卫星的具体星上分系统的下传数据。

最后，基于统一的配置文件，包括各部件产品的选型、数量、数据协议等，还可以将星上分系统内部的相关参数进行统一编号，从而管理部分202能够按照统一的数据格式进行数据处理，以星敏数据为例，前述的星上分系统标识字段为B3H～B5H，那么在B3H～B5H中，无论卫星选用的是哪个厂商生产的星敏，无论其数据协议采用那种形式，均可以统一遵循表2所示的格式。

表2

可以理解地，数据标准化部分并不会改变数据存储部分201所存储的卫星原始数据，而是需要进行下传或者管理部分202进行数据处理时进行标准化处理，也就是说，如果卫星上某个部件发生异常时，仍然可以采用下传原始数据的方式共地面站进行故障分析。

需要说明的是，在获得标准化数据之后，一方面便于下传至地面站后，针对下传数据进行卫星以及星上分系统的区分；另一方面，统一的数据格式便于管理部分202在进行数据处理过程中能够按照统一的配置进行处理，无需再单独进行数据格式转化，提高了管理过程的处理效率。

在上述示例中，继续参见图3，优选地，所述数据传输部分203，可以包括：数据加密单元2031和协议转换单元2032；其中，

所述数据加密单元2031，经配置为：

若需下传的标准化数据为明文传输，则直接将需下传的标准化数据传输至所述协议转换单元；

若需下传的标准化数据为秘密传输，则按照设定的加密策略对需下传的标准化数据进行加密处理后，传输至所述协议转换单元；

所述协议转换单元2032，经配置为：

相应于本星处于地面站的可见区域，将需下传的数据按照测控协议进行组帧，并将得到的第一下传数据帧传输至本星的测控通道向地面站传输；

相应于本星不处于地面站的可见区域，将需下传的数据按照星间通信协议进行组帧，并将得到的第二下传数据帧传输至本星的星间通信链路，以通过星间通信链路传输至星座中能够下传的卫星向地面站传输。

对于上述优选示例，在具体实施过程中，加密策略可由地面站上注更新，保证加密策略的灵活性。下传数据可以在本星相对于地面站可见情况下，通过测控通道直接传输至地面站；也可以在本星相对于地面站不可见的情况下，通过星间通信链路，比如激光通信链路转发至当前地面站可见的其他卫星，再由该卫星通过测控通道传输至地面站。可以理解地，由于下传的数据均进行了标准化，因此，即便由其他卫星下传至地面站，地面站同样也能够区分出该卫星与本星的下传数据。

在上述示例中，继续参见图3，优选地，所述管理部分202，包括：本星健康管理单元2021、构型管理单元2022以及路由管理单元2023；其中，

所述本星健康管理单元2021，经配置为：

根据预设的每种标准化数据对应的故障检测类型，确定所述数据标准化部分传输的标准化数据所对应的故障检测类型；

配置通用故障诊断模型以适配所述数据标准化部分传输的标准化数据所对应的故障检测类型；

基于所述数据标准化部分传输的标准化数据通过配置后的故障诊断模型进行诊断，输出诊断结果；

将所述诊断结果生成对应的控制策略并传输至本星的星上控制系统；

所述构型管理单元2022，经配置为：

相应于所述数据标准化部分传输的标准化数据为关于轨道参数的标准化数据，将所述关于轨道参数的标准化数据与预存的本星标准轨道参数进行比对；

若比对差值处于设定的偏差阈值内，则确定本星在星座构型中的位置是稳定的；

若比对差值大于设定的偏差阈值内，根据所述关于轨道参数的标准化数据与预存的本星标准轨道参数之间的比对差值生成姿轨调整策略，并传输至姿轨分系统执行以使得本星的轨道参数恢复为稳定状态；

所述路由管理单元2023，经配置为：

相应于本星计算资源余量小于设定的阈值，则根据本星的测控通道以及星间通信链路所接收到的数据更新本星的路由表；

相应于本星计算资源余量大于设定的阈值，则基于相关路由发现算法更新本星的路由表。

对于上述优选示例，本发明实施例的技术方案在具体实施过程中，管理部分202可以分别通过本星健康管理单元2021、构型管理单元2022以及路由管理单元2023实现本星的健康管理、构型管理以及路由管理三个管控任务。具体地，对于健康管理任务来说，本星健康管理单元2021内可以包括一通用故障诊断模型，该模型包括辨识器、分类器和诊断器，能够基于配置文件的参数配置而适配用于诊断确定不同类型的故障，如图7所示的故障诊断流程，配置文件中可以包括适配于常值类故障、跳变类故障、阈值类故障、期望值类故障等规则参数，当通用故障诊断模型基于某种故障类型的规则参数进行配置后，就能够进行相应故障类型的判断，而标准化数据来自于本星上的各类星上分系统，因此，不同种类的标准化数据分别能够用于判断或诊断不同类型的故障。数据标准化部分传输的标准化数据不仅能够确定进行诊断的故障类型，而且还是进行故障诊断的数据基础。通用故障诊断模型经配置文件的参数配置之后，通过输入的标准化数据进行故障诊断，诊断结果用于指示是否存在相应类型的故障；若诊断结果指示存在相应类型的故障，则生成相应的控制策略，并将承载有控制策略的控制信号反馈至卫星的中心控制系统(比如星载计算机)，以使得卫星的中心控制系统按照控制策略对相应的星上分系统进行控制从而消除故障。

对于构型管理单元2022来说，本发明实施例优选的构型管理方案采用绝对相位的分布式控制策略，以保证星座系统构型的稳定。详细来说，在星座设计完成后，每颗卫星的标准高度、标准相位便已经决定，这类标准值可以预存至卫星上，或者经由地面站上注至卫星。若每颗卫星均保证自身位置的高度及相位稳定在给定的约束范围内，则整个星座的构型便是稳定的，比如设定高度的最大偏差阈值为±5km，相位最大偏差阈值为±1°，则当卫星高度因大气阻力等因素以使得关于轨道参数的标准化数据降低至原轨道高度-5km或相位偏差达到1°时，构型管理单元2022则相应生成轨道高度抬升或相位调整策略，并传输至姿轨分系统执行以使得本星的轨道参数恢复为约束范围内。需要说明的是，绝对相位的分布式控制策略好处是不需要进行星间测距或者获取其他卫星的位置信息，仅依赖每颗星自身的轨道数据便可维持星座的构型稳定。

对于路由管理单元2023来说，其主要功能进行路由表的维护，当卫星需要向其他卫星或地面节点发送数据时，可依据最新路由表确定最优路由路径，从而保证数据传输的有效性和时效性。若星上计算资源紧张以使得无法自主实现路由计算，路由管理单元2023可通过测控通道、星间通道(比如星间通信链路)接收数据以完成自身路由表的更新；若星上计算资源充足，路由管理单元2023可利用预先集成的相关路由计算算法、路由发现算法，自主完成路由表的更新，从而保证路由表为最新状态。

可以理解地，在本实施例中，“部分”可以是部分电路、部分处理器、部分程序或软件等等，当然也可以是单元，还可以是模块也可以是非模块化的。

另外，在本实施例中的各组成部分可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

基于前述技术方案相同的发明构思，参见图8，其示出了本发明实施例提供的一种面向大规模星座的卫星在轨自主管理方法，该方法应用于前述技术方案所阐述的面向大规模星座的卫星在轨自主管理装置20，该方法可以包括：

S801：将设定回溯日期内本星的星上分系统数据进行存储；

S802：基于所述星上分系统数据对应的故障检测类型配置通用故障诊断模型，并根据配置后的通用故障诊断模型通过对应的星上分系统数据进行故障诊断，获得故障诊断结果；

S803：根据本星姿轨分系统所测量获得轨道数据以及本星的构型数据生成星座构型控制数据；

S804：维护用于进行数据传输的卫星间路由表；

S805：将需下传的星上分系统数据按照需下传的数据通道对应的通信协议进行组帧，获得下传数据帧，并将所述下传数据帧传输至对应的数据通道以进行下传。

对于上述方案，在一些示例中，进行存储的本星存储空间被划分为多个数据存储区；其中，每个存储区对应设定回溯日期内的一个日期区间，每个存储区中的数据完整度与对应日期区间距离当前时刻的远近程度相关；所述每个存储区均包括与星上分系统对应的存储块，每个存储块的容量与对应星上分系统的数据总量相对应。

基于上述示例，优选地，所述方法还包括：

当相邻数据完整度中较高完整度所对应的存储区内存在数据已满的存储块，则在向所述数据已满的存储块存入数据过程中，将所述数据已满的存储块尾部的部分数据帧按照对应的完整度进行删除，并将所述数据已满的存储块尾部的另一部分数据帧按照相邻数据完整度中较低完整度进行抽取并存入较低完整度所对应的存储区内对应相同星上分系统的存储块。

基于上述示例，优选地，所述方法还包括：

在收到针对目标星上分系统的第一数据索引指令时，根据存储块与星上分系统之间的对应关系，将所有存储区中与目标星上分系统对应的存储块内的数据进行提取以响应所述第一数据索引指令；

在收到针对设定时段的第二数据索引指令时，计算每个存储区内每个存储块的首尾数据帧的时间戳差值，将所述时间戳差值处于所述设定时段的所有存储块内的数据进行提取以响应所述第二数据索引指令；

在收到针对目标星上分系统以及设定时段的第三数据索引指令时，计算所有存储区中与目标星上分系统对应的存储块的首尾数据帧的时间戳差值，将所述时间戳差值处于所述设定时段且与所述标星上分系统对应的存储块内的数据进行提取以响应所述第三索引指令。

对于上述优选示例，需要说明的是，基于上述示例中所阐述的存储空间划分方案，在数据存储完毕后，通常会根据需要进行数据下传，如问题产生的时间、某部件的运行状态等，此时，需要对数据进行索引，从而减轻数据下传的压力，基于上述优选示例，在本发明实施例中，索引条件可以包括时段与分系统ID两类。

首先，按时间段条件检索；具体来说，结合前述图4至图6所示的存储空间划分示例，依次获取区1内各nID存储区、区2内各nID存储区、区3内各nID存储区中的首尾数据帧，计算首尾数据帧的时间戳差值是否涵盖检索条件所指示的时间段：若涵盖，则精确匹配满足该时间段内的所有存储数据，按照nID组成文本后反馈；若不涵盖，则给出提示反馈。

其次，按星上分系统标识nID条件检索；具体来说，若匹配nID成功，依次将区1内的相应nID存储区、区2内的相应nID存储区、区3内的相应nID存储区中的存储文本全部提取，并反馈；若匹配nID失败，则给出提示反馈。

接着，按nID以及时间段的结合条件检索；具体来说，首先，若匹配nID成功，依次获取区1内的相应nID存储区、区2内的相应nID存储区、区3内的相应nID存储区中的首尾数据帧，计算时间戳差值是否涵盖检索条件时间段，若涵盖，则精确匹配满足该时间段内的所有存储数据，组成文本后反馈；若不涵盖，则给出提示反馈。

最后，针对全部数据进行检索；具体来说，可以依次将区1、区2、区3中的存储文本全部提取，并反馈。

基于上述技术方案及其示例，本实施例提供了一种计算机存储介质，所述计算机存储介质存储有面向大规模星座的卫星在轨自主管理程序，所述面向大规模星座的卫星在轨自主管理程序被至少一个处理器执行时实现上述技术方案中所述面向大规模星座的卫星在轨自主管理方法步骤。

可以理解地，上述面向大规模星座的卫星在轨自主管理方法的示例性技术方案，与前述面向大规模星座的卫星在轨自主管理装置的技术方案属于同一构思，因此，上述对于面向大规模星座的卫星在轨自主管理方法的技术方案未详细描述的细节内容，均可以参见前述面向大规模星座的卫星在轨自主管理装置的技术方案的描述。本发明实施例对此不做赘述。

需要说明的是：本发明实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。

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