软件定义测控系统体系架构与关键技术

李超,焦义文,傅诗媛,吴涛

1.航天工程大学 电子与光学工程系,北京 101416 2.电子信息系统复杂电磁环境效应国家重点实验室,洛阳 471003 3.智能化航天测运控教育部重点实验室(航天工程大学),北京 101416

1 引言

随着空间技术的发展,21世纪已经进入航天的世纪时代。航天工业正在经历巨大的技术创新和进步,推动着航天事业的变革。多波段、多轨道星座、小型/立方体卫星和软件定义有效载荷的出现[1-3],带给了空间资产、带宽和能力的拓展,软件定义网络,软件定义卫星的技术变革[4-5],使得空间系统变得越来越动态[6-7]。然而,长久以来,航天测控系统的建设一直以“按型号研制,一事一型号”的思路建设为主,航天测控系统很大程度上是“静态”的,存在“出厂定终身”的弊端,不能适应空间目标数量上的快速增加、性能上的灵活可变、功能上的可重组。这意味着空间系统的测控需求和地面测控系统服务能力的差距越来越大[8-10]。航天测控系统受困于按型号定制,按套部署,目的单一的硬件和软件紧耦合开发模式,已经成为制约空间技术发展瓶颈,迫切需要测控系统实现新的创新和变革,适应不断发展的空间技术进步。

新技术条件下,如何引导现代测控系统的设计、研制和发展向着更加科学合理的方向发展,充分挖掘系统潜能,适应不断变化的空间业务,已经成为航天测控系统需要进一步迫切解决的问题。

软件定义技术的出现与发展为解决上述问题提供了思路和解决方案。中国工程院院士梅宏指出,软件定义技术的本质是把原先一体化的硬件设施打破,将基础硬件虚拟化并提供标准化的基本功能,然后通过管控软件,控制其基本功能,提供更开放、灵活、智能的管控服务[8-9]。软件定义技术从软件定义网络到软件定义数据中心,再到软件定义一切,已经成为各行各业发展的趋势,成为各行业研究热点[13-16]。软件定义测控系统是利用软件定义技术,将测控系统中的射频前端、信道、基带等硬件资源打散,将系统基础硬件标准化为基本功能组件,通过集中控制软件实现硬件资源的集中控制管理,提供灵活、可重组的测控服务功能。发展研究软件定义测控系统,是顺应时代与技术发展的必然结果,是解决当前快速发展的航天技术与不断增长的卫星测控需求的必由之路。从当前技术发展趋势出发,提出了软件定义测控系统定义、体系架构、开发流程,并对涉及到的关键技术进行了分析研究,最后对软件定义测控系统技术发展作出了展望,给出了初步的研究思路。

2 软件定义测控系统体系架构

2.1 传统测控系统体系架构

航天测控系统是利用无线电技术实现对卫星、载人航天器、各类行星探测器等航天器的跟踪测量、遥测、遥控和数据传输业务的综合系统,一般由射频前端、信道、基带及各类保障分系统组成。传统测控系统中各设备以硬件为主要核心,系统架构采用封闭式架构[17-20]。如图1所示。

图1 传统测控系统体系架构

由图1可见,传统测控系统中,为确保测控任务顺利完成,一般采用1:1热备份模式,每套测控系统中除包含有共用的数据传输与存储分系统、时频分系统、健康管理分系统、测试标校分系统和监控分系统外,信道设备和基带设备都是两套设备同时工作,互为备份。一个测控站内通常部署多套不同类型的测控系统,各测控系统之间相互独立,互不兼容。由于传统测控系统以硬件研发模式为主,各测控系统之间也没有共享机制,各分系统只负责保障和管理本系统内部设备的正常工作,测控站资源存在重复建设和已有资源不能得到充分利用的问题。随着测控任务的日渐增多,传统测控系统的建设成本和维护成本越来越高,不能适应快速发展的航天测控任务需求。

2.2 软件定义测控系统体系架构

为满足快速发展的航天测控任务需求,借鉴软件定义网络技术,将测控系统各组成硬件标准化为基本功能单元,通过软件定义技术将各基本功能单元的控制部分集中管理,实现硬件资源的灵活重组,完成多样化测控任务。软件定义测控系统通过统一对外接口,接收和完成不同类型测控任务,实现了测控任务与底层硬件的解绑,硬件资源可复用,提高系统资源的利用率。软件定义测控系统体系架构如图2所示。

图2 软件定义测控系统体系架构

软件定义测控系统体系架构按照逻辑层次可划分为:应用层,控制层,基础资源层和管理层及连接应用层和控制层的北向接口、连接控制层和基础资源层的南向接口。

应用层由完成航天测控功能的测控应用和完成特定卫星业务的拓展应用组成,通过丰富开放的应用程序编程接口(application programming interface,API),用户还可以自主设计应用程序实现定制化功能。同时,应用层通过图形化界面显示基础资源的使用率、运行状态等信息,供用户分析查看各应用执行情况。应用层通过北向接口与控制层交互,即各种应用能够通过可编程方式把业务需求提交给控制层。应用层可以包含多个北向接口驱动(使用多种不同的北向API),同时应用层也可以对本身的功能进行抽象、封装来对外提供北向代理接口,封装后的接口就是更高级的北向接口。

控制层是逻辑集中的实体,主要承担如下任务:一是将应用层需求转换为实际资源的调用指令;二是将底层硬件资源的状态提供给应用层。控制层包含北向接口代理,南向接口驱动以及系统资源监视、资源申请部署、资源释放回收、资源调度、负载均衡、异常检测、干扰处理等多种业务监控与管理功能。控制层是系统的核心,起到链接用户需求和配置基础资源的作用。

基础资源层是系统的物理基础,由完成各类测控功能及其他卫星业务功能的通用计算资源和南向接口代理组成,包括各类高性能处理器,存储器,射频前端,信道设备,测试标校设备,网络设备,时频设备等,是完成各类任务的物理基础。它没有控制能力,只是单纯完成数据传输和处理。一个应用可以包含部分或全部物理资源,同时一个物理资源应支持多种物理连接,以便重构形成不同的计算模式,完成不同任务。

管理层主要负责系统的配置管理功能,这些功能大多是静态的,如系统初始化等功能。

每个层之间的接口实现都是由驱动和代理完成,具体如下。

南向接口是控制层和基础资源层之间的接口,主要功能包括:对所有的底层硬件资源进行控制和配置,如网络配置,信道配置,天线配置及通用计算资源的配置。它是一个通用的、与设备厂商无关的接口。

北向接口是应用层和控制层之间的接口,主要功能包括:提供基础资源层的使用情况,包括利用率、闲置率、业务执行情况、以及将用户的应用传递给控制层,这个接口也是与厂商无关的接口。

从软件定义测控系统体系架构可以看出,应用层、控制层和基础资源层实现了解耦合,控制层一方面将应用层需求翻译成底层的控制指令,配置具体硬件资源,另一方面将底层资源实际状态上报给应用层,方便用户启动或关闭各类应用。同时,通过标准的接口协议,测控功能不再依赖于某些特定厂商所生产的测控设备,基础资源层建立在通用硬件资源上,应用层通过开放API接口,直接面向用户。满足用户多样化需求的同时,有效降低了设备生产费用。

2.3 业务流程

软件定义测控系统是一种全新测控系统体系架构,业务包括了现在测控系统的所有功能,包括对航天器的跟踪测量,遥测数据接收,遥控指令上注,数传业务接收等。业务流程如图3所示。

图3 软件定义测控系统业务流程

软件定义测控系统任务输入可以是上级下发的任务,也可以由本级用户提出。业务开始于服务请求,不管是上级下发还是本级提出,都是通过统一的应用层输入。业务流程设计如下:

1)当应用层接收到任务请求后,通过标准北向接口将具体任务要求传送给控制层,信息包括需要使用的测控天线及工作频段、开始和结束时间、测控业务类型、数据处理要求及结果发送地址等信息。

2)控制层接收到业务请求后,根据具体业务请求,配置必要的射频硬件参数,初始化建立物理射频链接,如定义天线的工作频段、初始方位俯仰指向、信道带宽频率、基带参数等。软件定义基带采用虚拟化技术,如虚拟机或容器技术,将实现测控基带功能的各个应用程序虚拟化为虚拟网络功能(virtualization network function,VNFs)。通过各类测控功能的虚拟化,实现软硬件解耦。软件模块不再与专用硬件绑定,而是加载虚拟机或容器运行于通用计算资源之上。这样,测控功能可根据需求灵活部署、动态调整,提升了测控系统弹性和敏捷性。

3)启动控制程序。控制层通过标准南向接口协议,将解析出的服务请求,生成资源配置和调度文件,下发给基础资源层。资源配置和调度文件包含了使用哪些资源及如何将这些资源配置在一起,以接收、处理、存储和转发接收的信号。

4)执行任务请求。此时,系统已经启动并运行。基础资源层接收控制层的指令,按照指令部署配置好必要的射频资源、信道资源、计算资源、存储资源、网络资源等,并将计算结果、工作状态、资源使用情况上报给应用层。

5)用户可以通过应用层,实时查看测控业务执行及设备工作情况。应用层提供了相关的业务执行视图和状态信息,包括系统监控、设备状态、中间结果等,可根据业务执行情况作出必要的操作。

6)当任务执行完毕后,各测控业务链路将被分解,各测控资源将被释放,供其他测控业务使用,从而实现高效的资源利用。

由此可见,通过软件定义测控系统的集中控制和统一管理,任务规划时间大大缩短,以前可能需要几天甚至几周才能实现或改变的操作,现在只需要几分钟。此外,软件定义测控系统还可以在几秒钟内动态响应需求的变化,增加系统弹性和灵活性以满足突发事件需求。

2.4 软件定义测控装备及系统开发流程

传统测控装备开发流程为:首先是用户提出需求,总体单位论证项目可行性,提出战术技术指标,发布招标公告,研制厂所投标并根据具体战术技术指标开展相应研制工作。其中战术技术指标的论证、装备研制到最后装备定型是整个过程的核心,需要各工业部门、总体论证单位和需求单位的全程协调与沟通。传统测控装备开发流程一般包括用户需求、总体论证、厂所承研、工程样机试验鉴定和量产阶段[21]。如图4所示。

图4 传统测控装备开发流程

由传统测控装备开发流程可以看出,传统测控装备开发环节耦合性强,开发过程中软硬件开发者相互协同研发,导致研发进程相互制约,研发周期长;底层硬件开发效率低,造成人力和物力的严重浪费。装备软硬件紧耦合的特性,也使得装备后期功能扩展升级,技术更新迭代,保障维护等方面存在诸多困难。

软件定义测控装备开发流程整体上仍然按照上述5个阶段,但具备以下显著不同点。软件开发比重大幅增加。未来软件开发成本可能达到总成本的60%以上。而价值占比可能达到整个系统的80%以上。软件定义测控装备实现了软硬件开发解耦,开发过程持续协同,如图5所示。开发流程使得软件开发、验证、交付不再依赖于硬件的研发进度,在各个阶段均能释放验证软件产品,并可实现全流程迭代升级。

图5 软件定义测控装备软硬件解耦、持续协同开发

软件定义测控装备的开发流程模式是双闭环的开发流程,包括系统开发和软件迭代两个层面。系统开发是指新测控装备的论证、设计、研发、样机试验鉴定和量产列装等,通过试验数据反馈指导测控装备论证研发;软件迭代是指用户在使用阶段,通过交互式数据采集、及新需求增加,软件可远程实现迭代更新升级。在整个测控装备生命周期内,软件迭代可持续进行,使得测控装备具备全生命周期的开发过程。

硬件开发向通用化、模块化和工具箱策略方向发展。通过软硬件解耦合,软件向着功能化、定制化、组件化方向发展。硬件向着通用化、工具箱策略方向发展。通过软硬件的灵活重构组合覆盖所有体制类型测控系统研发需求。

软件定义测控系统基于软件定义测控装备软硬件解耦合,全生命周期迭代开发技术,实现层次化的研发模式。其以用户需求为导向,破除软硬件一体化研发模式禁锢,使得系统软件和硬件可协同并行开发。软件定制化,硬件通用化的层次化研发模式,极大满足未来快速发展的航天器测控需求、民商航天测控需求和热点地区军事冲突下的快速响应测控作战需求。软件定义测控系统层次化研发模式如图6所示。

图6 软件定义测控系统层次化开发流程

2.5 优势对比分析

由上文可以看出,软件定义测控系统是在软件定义技术和最新互联网IT技术成果之上发展而来的新一代测控系统,较传统测控系统的“竖井式”体系架构不同,软件定义测控系统采用分层式体系架构,实现任务管理、业务应用、任务控制和物理基础资源的分割解耦。通过应用层对外提供各类测控服务接口,通过任务控制,实现软硬件解耦,将一体化的硬件资源也分割为不同粒度计算单元,按照需要组合重构,扩展性和重构性都大大增强,满足了不断发展的新技术试验验证和多星多模式测控的需求,对于新技术的演示验证,应对快速变化的空间业务,动态调整测控业务模式较传统测控系统都具有很大优势。

软件定义测控系统与常规测控系统架构对比如表1所示。

表1 不同类型测控系统架构对比

3 软件定义测控系统关键技术分析

软件定义测控系统是利用软件定义技术发展而来的一种新型测控系统,关键技术包含标准接口与规范、软件定义射频前端、软件定义信道和软件定义基带。下面从这四个要素方面讨论实现软件定义测控系统的关键技术。

3.1 标准接口与规范

当前测控系统采用传统“烟囱式”体系架构,不同厂所研制的测控装备自成体系,对外开口及协议缺乏统一的标准,当系统需要更新升级,需协调不同厂所的工程师对接协议标准,造成系统升级和维护困难。

由软件定义测控系统分层体系架构可见,为实现对外开放接口和对底层基础资源的灵活重组,需要研究建立标准的接口规范,保证对外建立统一开放的API接口,供用户开发新功能,提高测控系统的灵活性和完成任务的多样性,同时也允许更多的科研人员参与到系统开发中来。具体包括:1、制定应用层对外API软件接口规范,定义测控系统应用软件标准接口,接口规范不依赖底层硬件资源,满足实现测控系统开放的基本架构。为实现军民融合,民商航天事业发展奠定基础;2、制定规范的南向接口规范,实现控制层对底层硬件资源的统一控制管理,实现基础资源层的射频、信道,通用计算资源,时频设备,网络设备等资源的控制管理功能;3、制定标准的北向接口规范,实现用户需求到资源使用的传递与解析,及资源使用情况上报等功能。

3.2 软件定义射频前端

软件定义射频前端是软件定义测控系统的射频信号接收单元,完成无线电信号的接收与数字化。随着航天技术的发展,当前测控系统工作频段包含了S、C、X、Ku、Ka等频段,具有频段宽,天线类型复杂的特点[22]。为了实现不同频段信号的接收,通常针对不同频段建造不同的天线完成对应频段信号的接收。当前测控系统为了最大限度地利用天线资源,开发研制了S/X双频段接收天线,S/X/Ka三频段接收天线,其基本原理是在一个天线口面内放置两个或三个不同频段接收馈源,通过切换不同馈源实现不同频段信号接收。由于馈源体积较大,当前的多频段天线仅适用于大口径天线,其应用场合受到一定限制。软件定义射频前端要求可根据实际业务及卫星情况,软件定义工作频段、极化方式、功率、带宽等,满足多功能天线重构,多频段信号接收需求[23-25]。因此需要针对宽频段信号接收技术,同时为了满足不同口径天线的约束,还需研究解决馈源的低剖面小型化技术。具体包括:紧耦合阵列天线技术,低剖面超宽带天线技术,可软件编程控制的频段分选技术等,以实现馈源小型化和宽带接收技术,频段可定义技术,满足软件定义测控系统射频前端不同天线口径,不同频段的需求。

3.3 软件定义信道

传统测控系统中,信道指的是从天线馈源经过低噪声放大器,模拟滤波器,下变频器等模拟设备到ADC之前的模拟设备。传统信道设备通常采用定制研发模式,针对不同的测控任务,信道频率带宽等参数研制,其灵活性差,可复用率低。软件定义测控系统中的软件定义信道指随着射频采样技术的发展,射频采样后的数字滤波,下变频,采样率变换等处理过程。

传统测控系统,信道的中心频率、工作带宽、调制方式、信号编码、信号体制等,按照任务型号,在出厂时已经定型,后期更新升级困难,且不同测控设备之间难以复用。软件定义信道是在全频段接收的基础上,数字化采样尽可能靠近射频前端。根据用户需求,定义工作带宽、中心频率、调制方式、信号编码、信号体制等,通过数字信道化技术,将有用信号分选出来,送到后续基带进行处理[26]。为实现将有用信号挑选出来,节省带宽资源,及实现高效滤波和重采样的需求。需研究高效信道化技术,实现宽频段信道的信道化接收和处理技术,具体技术包括:基于多相滤波器组结构的高效信道化技术,针对可能出现的一个信号跨多个子带的情形,还需研究信道完美重建及邻信道合并等技术,实现宽频段信号接收后的高效传输和处理问题。

3.4 软件定义基带

基带是测控系统的核心设备,完成信号的处理,获得航天器有效载荷数据及外弹道相关测量值。软件定义测控系统以通用处理平台为基础,实现细粒度的资源重构,实现测控信号的数据处理。同时测控系统也是一个强实时性系统,为满足硬件资源的重构复用和系统实时性要求,需研究以下关键技术:①高性能异构计算平台的数字信号处理架构设计;②多种异构计算平台的容错可靠性,实时性优化设计;③轻量高效的容器技术在信号处理领域的应用研究。④分布式计算,中间件技术在异构计算平台框架下的优化设计。⑤并行计算技术,针对异构计算平台,众核处理系统,研究测控信号的并行计算技术,提高系统的实时性。

4 结论

软件定义测控系统是一种新型体系架构的测控系统,该测控系统采用层次化体系结构,较传统测控系统架构,在开发流程、研制模式等方面都有显著的不同。随着不断变化的民商航天测控需求和快速发展的卫星技术,未来一段时间小卫星和大型星座的发展导致的测控任务爆炸式增长,传统的型号研制、按套部署的方式,已经不能适应未来测控任务需求。软件定义测控系统,从体系架构出发,解决了以往竖井式体系架构,能够很好地满足不断增长的测控任务需求。为解决测控系统研制周期长、型号庞杂、维护保障、升级换代难等问题提出了有效的解决思路,可以满足未来测控需求和适应快速响应航天能力。随着技术的发展,将来测控系统将向以下方面发展:

(1)智能化测控系统

自2017年,中国在“十三五”规划中就已经提出“智能卫星”的需求,卫星智能化已经成为国家层面研究热点问题。另一方面随着大数据,人工智能发展,智能化装备层出不穷。面对未来卫星技术发展,测控系统也必将向着智能化方向发展。提供更加精准、智能、可靠的测控服务保障。

(2)天地一体化网络化测控系统

随着5G/6G技术发展,地面以太网、蜂窝网、物联网等网络快速发展并融为一体。一方面,天地一体化网络势必将融为一体,为未来卫星发展提供新的机遇和方向,另一方面,测控系统数字化、智能化、网络化程度越来越高,测控服务将作为天地一体化网络服务的一个节点,提供测运控服务,满足不断发展的航天业务。

(3)快速响应测控系统

传统面向型号研制按套部署模式,不仅研发周期长,而且后期维护成本高,升级换代难。随着不断发展的小卫星和大型星座及快速响应的测控需求,未来测控系统将面向需求,发展功能可重构,资源可复用的高效测控系统,满足快速响应测控需求。