空间边缘计算：需求、架构及关键技术

虞志刚 冯 旭 戴 天 陆 洲

(中国电子科技集团公司电子科学研究院 北京 100041)

1 引言

随着人类活动疆域从陆地向深海、深空的不断扩展，为切实保障远洋航行、空间探测等领域网络通信需求，世界各国纷纷布局以低轨星座为代表的空间信息网络建设，构建全球无缝覆盖、服务无处不在的网络能力[1–3]。

与此同时，随着航天电子技术的迅猛发展，宇航级计算、存储设备能力逐步增强，如图1所示，以中央处理器(Central Processing Unit, CPU)为例，随着CPU主频逐步提升，星载计算能力也获得较大的跃升[4]。除此之外，随着商业航天的快速推动，商业货架器件被广泛应用，部分地面高性能、低成本器件经过简单的加固之后运行在空间环境[5]，星载计算能力得到了大幅提升。

图1 宇航级CPU主频与处理能力增长曲线

未来通信卫星将突破传统的“转发器”概念，具备较强星载计算能力，将部分计算、存储、通信、网络与感知任务沉降到卫星边缘完成在轨处理，实现通信、计算有效融合，可以有效提高服务响应速度、降低各种数据回传造成的通信压力[6]，摆脱对地面系统依赖。

以星链(Starlink)为例，公开资料显示，美国太空探索公司(SpaceX)每发射60颗卫星包含4000多台Linux计算机，截至2021年6月，SpaceX已经发射星链卫星1737颗，在轨1638颗[7]。据此推算，已发射出116000台Linux计算机。一方面，分散在太空中的巨量Linux计算机将产生大量数据，若这些数据全部传回地面将给星间链路产生压力；另一方面，大量Linux计算机聚合构建强大算力资源，完成单颗卫星难以完成的任务[8]，避免数据回传。

通常受功耗、体积、重量等限制，单颗卫星能够搭载的资源类型和数量仍将有限，导致单颗卫星的星载计算能力也将有限[9]。面向未来广泛的计算能力需求，迫切需要多颗卫星之间或卫星与地面之间通过星间/星地链路临机自组织成集群，最终构成空间分布协同的“云”计算环境–空间边缘计算环境，实现资源相助、任务协同，获得倍增效应。

因此，在空间网络高动态、窄带宽、长时延约束下，如何高效地调动物理分散的星载计算资源，分布式协同完成计算任务成为一个亟待解决的关键问题。目前，面向空间网络的边缘协同计算理论研究方面尚处于起步阶段，本文从空间边缘计算的需求分析与发展现状出发，并在此基础上总结分析，提出一种空间边缘计算架构，以期能够为后续空间边缘计算的研究提供有价值的建议和参考。

2 需求分析

空间边缘计算的发展受应用和技术双轮驱动，下面将分别从应用和技术两个方面进行需求分析。

2.1 应用需求

(1)服务快速响应的需求。随着星上处理能力的提升，将原始在地面进行存储、计算、处理、分发的任务，直接搬移到卫星上，将会极大地服务响应的速度。如遥感成像、目标监视、态势分发等实时类应用，如图2(a)所示，通过直接在卫星上进行态势感知与情报生成，可以大幅缩减星地回传的时间，提高服务响应速度[6]。以高轨卫星为例，星地之间的单向时延在120 ms左右，相较于地面处理，星上处理可以节约两个星地传输延迟，即240 ms。

(2)摆脱地面依赖的需求。空间边缘计算将会使“空间信息基础设施”发展成为一个可以自治、自演进的独立的功能体[10,11]，如图2(b)所示，既可以在地面中心的控制下，星地协同工作，又可以在失去地面控制情况下，独立运行工作，摆脱地面依赖，在极端情况下，可以提高系统的可靠性。

图2 空间边缘计算应用场景

(3)节约星地带宽的需求。随着星上处理能力的增强，卫星外部感知的感知数据以及卫星节点自身状态产生的状态数据均将是海量的，传统计算架构下，数据必须通过馈电链路回传地面中心进行数据处理，势必会给星地带宽带来极大的压力[6]。以海上目标搜救为例，如果采用星上对图像数据直接处理，发现目标即确认，星上生成情报信息直接通知相关搜救船只，可以减少大量原始数据回传地面带来的带宽压力，同时节约宝贵的星地传输带宽。

2.2 技术需求

(1)多星协同计算需求。考虑到卫星平台对重量、功耗、体制以及空间辐照环境的限制，相较于地面环境，卫星单节点能力、资源等各方面均十分有限[8]：(a)计算能力有限，面向较大计算或存储能力需求，唯有通过多点协同(多星协同)方能实现能力倍增；(b)计算资源有限，受限于卫星节点的限制，单节点难以配备全套现场可编程门阵列(Field Programmable Gate Array, FPGA)、图形处理器(Graphics Processing Unit, GPU)、CPU、张量处理器(Tensor Processing Unit,TPU)等异构计算资源，为了使应用采用合适硬件进行处理加速，必须通过多点协同方能实现资源互补。

(2)星地协同计算需求。虽然大量商用货架产品(Commercial Off-The-Shelf, COTS)器件已经在卫星上开始使用，但星上计算能力仍然难以与地面的算力相比，空间信息基础设施更像是地面计算环境的“缩小版”，面向空间难以处理的计算任务，仍可通过星地协同的方式来满足算力需求[11,12]。

3 发展现状

围绕空间边缘计算，国内外均开展了大量的探索实践：一方面为了提高卫星网络的韧性，支持自主运行，星上具有较强的计算处理能力已经成为卫星网络发展的新趋势；另一方面，宇航级CPU、FPGA等芯片的计算处理能力的稳步提升，以及随着商业航天的快速推动，商用货架器件广泛应用于低轨航天器，星载计算能力大幅提升，也为空间边缘计算奠定了基础。

3.1 星载处理成为卫星网络发展的新趋势

如表1所示，2018年7月，美国国防高级研究计划局(Defense Advanced Research Projects Agency, DARPA)提出黑杰克(Blackjack)计划，计划发展由60～200颗卫星组成的低轨星座，星座能自主运行，支持卫星之间数据共享、相互协作，黑杰克上搭载“Pit Boss”载荷[13]，具有自主控制及自主决策等在轨计算能力。

表1 国内外典型卫星网络

2020年，美国太空发展局(Space Development Agency, SDA)面向太空日益凸显的战略作用，提出了灵活、弹性、敏捷的国防太空架构(National Defense Space Architecture, NDSA)[14]，分为传输层、跟踪层、监管层、威慑层、导航层、管理层、支持层等7层，其中管理层具有较强处理能力，支持基于人工智能的分布式管理、指挥、控制和通信等功能。

与此同时，国内各单位也在积极探索。2018年11月，中国科学院软件所研制的“天智一号”发射升空[15]，采用“开放架构、模块集成、软件定义、一星多能”设计理念，搭载小型高性能星载计算平台；与此同时，支持有效载荷即插即用、应用软件按需加载，可以通过不同应用软件，实现不同任务。目前，该星已经实现星上实时智能云检测及图像质量判读，以及APP指挥卫星等功能。

2021年9月，中国电科38所发布了商业SAR天仙星座计划[16]，每颗卫星均具有4种模式成像功能，按需成像，同时搭载一颗强大的计算处理系统，支持星上即可完成图像预处理，快速识别图像内容和信息传输。2021年12月，北京邮电大学与天仪研究院合作研制的天算星座1号卫星发射升空，搭载了开源的云原生环境，支持与地面协同推理[17]。

3.2 宇航级处理芯片的性能获得大幅提升

近年来，随着航天技术和信息技术的迅猛发展，宇航级CPU,FPGA等芯片的能力获得大稳步提升[16]。以CPU为例，美国宇航局和欧空局始终处于世界领先水平。如表2所示，1998年欧空局研制了基于SPARC(Scalable Processor ARChitecture)架构的TSC695F芯片，主频25 MHz；2001年美国宇航级的火星任务系统采用了基于飞思卡尔半导体片上系统处理器架构的CPU RAD750，主频200 GHz，可提供高达400 DMIPS的算力。2016年以来，欧空局和美国宇航局纷纷抛弃基于传统SPARC架构的宇航级CPU和基于传统PPC(Performance optimization with enhanced risc – Performance Computing)架构的宇航级CPU，转型研发基于ARM(Advanced RISC Machine)架构的宇航级CPU(欧空局的DAHLIA(Deep sub-micron microprocessor for spAce rad-Hard appLIcation Asic)芯片以及美国宇航局的HPSC(High Performance Scalable Computing)芯片)。其中DAHLIA由4个ARM Cortex-R52通过设计加固构成，计算处理性能可达4000 DMIPS；HPSC芯片主处理器由8个ARM Cortex A53处理器经过设计加固构成。

表2 国内外典型宇航级CPU芯片

国产宇航级CPU的计算能力达到了美国同等水平，初步具备自主可控的研发能力。2021年12月，北京微电子技术研究所发布了第3代国产抗辐射SPARC架构处理器BM3883MARH，该芯片为8核处理器，主频可达1 GHz，定点运算性能可达16 GIPS，浮点运算性能可达32 GFlops，配备神经网络处理加速引擎，支持智能处理。A R M 架构方面，2022年1月，欧比特公司披露自主研发的玉龙810A芯片正在等待批产，其主处理器采用4核ARM A9，协处理器包括GPU和NNA单元，浮点处理能力可达64 GFlops，定点处理能力12 Tops。综上可以发现宇航级CPU性能已经告别“单片机”时代。

另外，2017年8月，惠普公司自主设计研发的第1代空间超级计算机(Spacebourne Supercomputer-1)搭载SpaceX公司的猎鹰9号火箭被送往国际空间站[5]，运行常规Linux系统，采用软件加固消除空间恶劣环境的影响而非传统的硬件加固。经过两年的在轨运行之后，2019年该计算机已经被带回地球开展严格的检查以分析其在太空轨道上的受损情况，将有助于打造未来的空间超级计算机，为深空探测任务提供技术支撑。

3.3 问题与挑战

综上可见，无论国外还是国内，星上计算处理成为当前卫星的“标配”，通过星上搭载处理能力，可以有效地降低对星地带宽的依赖，同时提供服务响应速度。然而，在空间网络高动态、窄带宽、长时延约束下，如何高效地调动广域分散的星载计算资源、协同完成计算任务成为一个亟待解决的问题。主要包括6个方面：

(1)时变性挑战。空间网络(特别是中低轨)拓扑处于动态时变之中，如何在拓扑频繁变化的条件下调动分散计算资源协同计算具有极大的挑战性；

(2)移动性挑战。低轨卫星高速运动会导致用户-网络节点的双重移动性，如何在高速移动的场景下提供不间断服务及自主服务迁移具有难度；

(3)长时延挑战。空间网络的跨度大，导致卫星节点间传输时延至少几毫秒，比地面超级计算机/数据中心等集群节点之间微秒级传输时延高出多个数量级，提高了通信成本，如何进行有效的任务拆分和部署将是一个亟待研究的新问题。

(4)窄带宽挑战。截至目前，星间链路/星地链路传输带宽通常为Gbps量级，相对地面光纤差距较大，难以大规模数据搬移，给分布式计算带来挑战。

(5)高成本挑战。卫星相对地面普通节点来说仍然属于高价值资产，具有较高的成本且功耗受限，进行任务分配时必须要考虑卫星的功耗红线。

(6)计算理论挑战。为了实现全球覆盖，低轨星座通常具有几百、几千甚至上万颗卫星规模，在规模庞大、拓扑动态、能力分散的条件下，缺乏分布式协同计算的架构、模型理论以及相应编程模型。

4 空间边缘计算架构设想

针对空间边缘计算存在的问题与挑战，本文提出了一种空间边缘计算的架构，并分别从物理、功能、软件以及业务流程等多个方向阐述内涵。

空间边缘计算是将分散在卫星上的计算资源通过卫星网络协同组织起来，构建多星协同、星地协同的分布式计算环境，实现资源相助、任务协同，获得倍增效应。通过与地面云中心以及用户终端协同，形成云-边-端协同的计算环境，如图3所示。

图3 空间边缘计计算环境

4.1 物理架构

物理组成方面，空间边缘计算由空间边缘云、地面中心云以及用户终端3部分组成，如图4所示。

(1)空间边缘云：是由若干承载在卫星上的星载处理单元通过星间链路组网临机自组织成集群，构成卫星边缘“云”计算环境，如图4所示，支持资源统一调度与管理，满足实时感知、通信、计算等任务，具备自治、自学习以及自演进能力。其中，星载处理单元是“云化”的智能计算组件，由CPU/GPU/FPGA/DSP/TPU等星载处理资源构成[24]，通过虚拟化技术构建一体化处理资源池，实现资源统一表征与管理，分布式移动的星载处理单元高效协同构建空间边缘云。

图4 空间边缘计算物理架构图

(2)地面中心云：可以是由分布式部署在地面信关站、移动信关站以及运控中心等地面通用处理平台通过地面网络互联而成；也可以是商用云计算环境；或者两个混合构成的多云环境。不同于空间边缘云，地面云中心不受宇航器件、体积和功耗等约束，可以装配较强的处理资源，提供充沛算力。

(3)用户终端：主要包括陆海空各类用户终端，获取空间边缘计算架构对外提供的各类服务。

4.2 功能架构

参考欧洲卫星电信标准化协会(European Telecommunications Standard Institute, ETSI)多接入边缘计算(Multi-access Edge Computing, MEC)架构[25,26]，提出一种面向空间分布式计算环境的功能架构，如图5所示，主要由星载处理单元和管理控制单元组成。

其中，星载处理单元分为两个层次，一是资源层：包括虚拟化基础设施、星载运行平台以及星载APP，分别提供软件即服务(Software as a Service,SaaS)、平台即服务(Platform as a Service, PaaS)和基础设施即服务(Infrastructure as a Service,IaaS)等服务；二是管理层：包括负责星载处理单元管理的虚拟化基础设施管理系统以及单颗星载运行管理系统。管理控制单元负责全系统/跨星的运行管理与控制，主要由运行支撑系统、协同编排系统组成，具体功能如图5所示。

图5 空间边缘计算功能架构

4.2.1 星载处理单元

(1)虚拟化基础设施：根据星载处理单元提供的CPU/GPU/DSP/FPGA/TPU/存储/接口等硬件资源利用虚拟化技术形成计算、存储、网络、安全等各类虚拟化基础资源，提供IaaS服务能力。

(2)星载运行平台：一组基础的功能软件的集合，一方面为上层的星载APP提供运行环境，支撑星载APP的服务发现、注册等；另一方面，从星载运行管理系统那里接收指令并相应配置虚拟化基础设施，并对跨平台任务协作提供通信支持，提供PaaS服务。

(3)星载APP：运行在星载运行环境之上的目标识别、数据压缩等各类APP，支持第三方开发，构建星载的应用程序仓库(APP Store)，形成空间分布式计算的服务窗口。

(4)虚拟化基础设施管理系统：负责分配、管理和释放虚拟化基础设施的虚拟化资源，包括计算、存储、网络资源，为服务的部署准备虚拟化基础资源组件，收集和报告虚拟化资源的性能和错误信息。

(5)星载平台管理系统：接收运行支撑系统的平台配置文件以及任务编排器下发的服务规则文件，按要求生成在轨处理平台资源配置的具体指令，对星载处理平台上需要运行的本地服务进行生命周期管理，并将服务运行的状态信息上报给任务编排器。

4.2.2 管理控制单元

(1)协同编排系统：将应用请求拆分为由若干服务组成的服务链，根据自身部署的策略将服务发布至指定平台，当网络结构发生变化时该模块会将服务进行重定向以保证用户端体验的稳定性。除此之外，协同编排系统还负责构建并维护分布式协同环境的整体资源视图。

(2)运行支撑系统：所有需要与用户进行交互的功能均部署于该模块中，用户接入操运行支持系统后可直接申请使用平台提供的应用，第三方开发机构可申请获取平台对外开放的部分能力以获取数据处理、协同感知等服务。运行支撑系统负责应用的实例化以及用户权限核准，被批准的请求将移交给协同编排系统与星载平台管理系统作下一步处理。

4.2.3 运行模式

空间边缘云可以与地面云中心协同运作，如图6所示，在条件允许的情况下，向地面云中心上报感知数据、状态数据和能力数据，同时获得信息支援、决策支持和行动指导，可以用于增强数据共享、任务迁移、资源调度、冗余备份和容错抗毁能力；也可以自主智能运作，通过利用卫星边缘侧获得的海量数据，借助人工智能技术更好地提高数据分析、场景感知、实时决策和自主协同等智能化服务。

图6 星地协同运行模式示意

4.2.4 功能部署

根据管理控制单元部署位置的不同，空间边缘云将会呈现不同的运行模式：

(1)管理控制单元部署在地面。此时为一种集中式架构，管理控制面位于地面，星上仅需要装载数据面功能以及单星的管理控制功能。优点是可以很好地适应星上资源、功耗受限约束；缺点是所有的任务请求都需要传输到地面进行处理，地面管理控制单元将成为系统的瓶颈，同时空间边缘云的自治能力比较弱。

(2)管理控制单元部署在卫星。此时为一种分布式架构，所有的卫星都部署星载处理单元以及管理控制单元，根据星座构型或者轨道分布，通过某种机制选举某些卫星作为运维管控的锚定点。优点是无须受到地面约束，在星地链路干扰情况下也可以自主运行、自主决策；缺点是要求卫星具有较强的计算存储能力，能够部署全套的功能，另外如何选举合适卫星成为锚定点也是难点。

4.3 软件架构

空间边缘计算软件可以划分为基础资源层、操作系统层、虚拟化层、平台层、应用层、管理控制层6层，如图7所示。

(1)基础资源层：包括CPUGPUFPGADSPTPU等异构星载处理资源、网络设备、接口设备及数据库等基础设施资源；

(2)操作系统层：与基础资源层对接，实现各类硬件的驱动，提供软件部署基础环境，负责星载资源发现、接入以及纳管，是平台资源的管家，任务部署过程中的资源申请及释放也集成在该层；

(3)虚拟化层：利用容器技术对卫星网络中物理资源进行虚拟化抽象处理，在该层部署虚拟化、容器化、远程调用等软件实体，形成存储、通信、计算等功能分类且弹性的资源池；

(4)平台层：参考云计算、边缘计算理念，借鉴K8S, KubeEdge等开源软件架构[10,11]，提供轻量级、开放、通用跨平台的开发框架，提供良好的用户开发环境，支持应用软件按需加载、第三方应用的开发部署，提供应用服务与云端的接口，提供服务的基础和保障；

(5)应用层：提供各类应用服务APP，包括卫星导航、目标探测、卫星通信和目标跟踪等业务类应用，也包括用于平台管理等基础APP，形成空间分布式计算的服务窗口。

(6)管理控制层：负责各种资源与控制，包括单星资源管理、多星协同管理、星地协同管理等层级，同时也是应用服务与云端的接口，提供服务的基础和保障，在该层部署服务监测、任务编排、服务调度等软件实体。

4.4 服务范式

参考云计算的架构，空间边缘计算架构可以进一步划分为IaaS, PaaS, SaaS 3种服务范式，如图7所示，其中基础资源层、操作系统层、虚拟化层协作，打造云化的基础设施，对外提供IaaS服务；平台层提供基础的软硬件与开发环境，对外提供PaaS服务；应用层提供各类应用服务APP，对外提供SaaS服务[12,13]。

图7 空间边缘计算架构体系

4.5 服务流程

空间边缘计算服务流程按照管理控制单元的部署位置不同可以划分为自主运行、星地协同两种服务模式，前者卫星具有管理控制功能，后者地面统一管理控制，但其基本流程相似，此处我们以星地协同模式为例介绍服务流程，如图8所示。

图8 空间边缘计算服务流程

(1)用户APP(用户终端或第三方服务)向最近的地面云中心–管理控制单元发送请求参数，如位置信息、目标图像、通信服务等；

(2)运行支撑系统收到用户请求参数后，对用户权限以及数据完整性进行校验，确认无误后激活相关星载应用，并向协同编排系统发送应用请求参数，如服务类型、服务质量(Quality of Service, QoS)需求、可靠性参数等；

(3)管理控制单元–协同编排系统收到应用请求参数后，通过服务协同编排软件将请求匹配至不同的服务，并将服务分配至不同的星载平台管理系统，服务分配还需要在服务出现异常状态时对服务进行重定向；

(4)收到服务请求参数的星载平台管理系统生成本地的配置文件，包括待激活服务类型、服务生效时间、服务生效规则等，生成的配置文件发送至星载运行平台；

(5)星载运行平台根据配置文件在本地激活相应服务，不同服务会调用不同虚拟化基础设施资源；

(6)虚拟化基础设施的资源被调用后，会将自身的资源占用情况上报至虚拟化基础设施管理系统；

(7)虚拟化基础设施管理系统定期向星载平台管理系统更新资源使用状态；

(8)资源分配完毕后，星载平台管理系统会收到服务响应数据，并将其发送至协同编排系统；

(9)协同编排系统收到全部服务响应数据后即可得到应用响应数据，并将其发送至运行支撑系统；

(10)运行支撑系统收到应用响应数据后会得到用户响应数据，并将其发送至用户；

(11)用户得到用户响应数据，服务结束。

5 关键技术

5.1 空间分布式协同计算范式

当前，分布式计算/云计算以及并行计算理论和方法往往面向室内场景，具有相对稳定和富足的传输带宽。然而，面向拓扑时变、带宽有限、链路断续的空间环境，以及异构、广域分散、能力有限的空间资源，结合不同的任务对响应速度、计算能力的需求，迫切需要构建统一空间分布式计算模型，设计多星协同、星地协同的分布式计算处理架构，为空间边缘计算理论提供理论支撑。目前关于空间边缘计算的研究要集中在架构方面[27]，关于分布式协同计算范式与理论模型方面研究比较少。

5.2 时变网络的确定性路由

面向在轨多源信息融合处理、广域交通控制等时间敏感类应用对网络传输的确定性需求，以及空间网络动态拓扑特征带来的时变性、不确定性[28,29]，迫切需要研究时变网络场景下的确定性路由技术，充分利用卫星运行轨道的轨位信息以及规律性，通过在时变网络资源模型基础上构建相对确定性的路由模型，解决空间网络天然不确定性与应用的确定性需求之间的矛盾。目前，关于空间网络的路由算法研究较多，然而如何试验有保证的时间确定性路由仍然是一个新问题。

5.3 高移动场景下服务迁移

针对卫星高速移动带来的网络拓扑时变、用户频繁切换，以及复杂电磁环境带来的卫星或链路故障，均对空间边缘计算带来诸多挑战，迫切需要研究高移动场景下的服务自主迁移技术，包括服务流程分析、服务迁移架构和策略，综合考虑迁移前后时延、带宽、算力以及能耗的关系，寻找最佳的迁移卫星节点及迁移路径[30]。目前，地面边缘计算领域的服务迁移有较多的研究，而关于空间场景下的服务迁移研究较少。

5.4 在轨资源智能协同编排

卫星节点的异构性带来了计算资源的异构性和不均衡性，空间网络的动态性带来了资源连接关系以及计算资源关系的时变性[16]。与此同时，多样化的任务对资源和算力有差异化需求。那么，如何在空间网络特征下，在功耗、时延等成本约束下，智能协同编排广域分散的算力资源满足差异化的应用需求是一个迫切需要解决的关键问题。

6 结束语

随着星载计算处理能力增强，通过将广域分散的星载计算资源通过星间链路临机自组织形成空间分布式协同的边缘计算环境，可以有效摆脱对地面的依赖、提高服务响应速度。梳理了空间边缘计算的应用需求、发展现状以及存在的问题与挑战，并在此基础上总结分析，提出一种空间边缘计算架构，分别从物理架构、功能架构、软件架构以及服务流程等多维角度进行了阐述；最后对涉及的关键技术进行了概述和分析，以期能够为后续空间边缘计算的研究提供有价值的参考。