王钧慧,曾富华
(中国西南电子技术研究所,成都 610036)
随着我国航天事业的发展,日益增多的航天发射任务和大量在轨运行的卫星对飞行器测控系统提出了越来越高的要求,特别是随着载人航天技术的发展,空间站、空间运行系统等的探测任务也将逐渐在轨运行,预计未来数年将加速发展,这对测控和数据传输设备提出了更高更新的要求。
中频信号数字化、IP 网络传输和远端波形重构技术能够给卫星地面系统带来显著效益。对远端地面站而言,这些效益包括降低成本和更灵活的软件处理。美国 RT Logic 公司 2015 年推出了一项名为 SpectralNet的新系统,能够对卫星下发的中频信号进行数字化,并将数字化后的信号经过 IP 网络传输,并保持信号波形特征不失真,可在远端利用云计算平台进行信号软件化解调、记录以及分发等操作。
雷达和通信领域也在积极推进“软件化雷达”“软件定义通信”等新技术。采用通用化和数字化特点的新型系统具有开放式体系架构,可以适应“面向实际需求,以软件技术为核心”的开发理念,以软件化开发模式灵活地实现系统扩展、更新和升级[1-3]。
针对第三代跟踪与数据中继卫星系统(Tracking and Data Relay Satellite System,TDRSS) ,NASA 提出了“天基网地面部分维护计划”(Space Network Ground Segment Sustainment,SGSS)。SGSS 引入了数字光纤、硬基带池、虚拟机等新概念和新技术,将提供一个灵活的可扩展、可升级的开放式地面测控系统。这种“池”式结构减少了设备量,提高了结构灵活性和硬件利用效率。目前我国在二代中继地面终端站以及航天测控数传一体化地面站也在积极推进射频数字化以及硬基带池技术[4-5]。
现有电信网络设备在数量和性能上都无法满足呈指数级增长的数据传输带宽的需求,由此导致网络设备的采购和运营成本有增无减。利用虚拟化技术,把原本分散的通用服务器集中起来统一进行管理分配,在通用计算平台上采用高级编程语言开发方式实现网络功能虚拟化(Network Functions Virtualization,NFV),提高了计算和存储的利用率,实现了应用软件灵活部署并且不依赖于特定硬件,进而降低了管理、维护和运行成本[6-9]。微软公司在2020年10月20日宣布,它将使用OpenSpace作为其Azure Orbital地面站即服务的一部分。OpenSpace由美国Kratos公司研制,该产品将软件定义方法应用于地面站的虚拟产品系列。OpenSpace使用开放标准、基于云的系统,可以根据任务需求不断调整而无需安装新硬件,使之可有效通过数字转换器连接到任何天线。
本文借鉴NFV理念,基于航天地面测控系统的特点,提出了测控功能虚拟化(TT&C Function Virtualization,TFV)的全新概念,同时阐述了一种基于实时云测控基带池的实现方案,包括总体架构、关键技术解决方法以及原理样机的测试验证。
图1所示为实时云测控基带池总体架构。
图1 实时云测控基带池总体架构
实时云基带主要包括计算资源池、射频IP化前端资源池和管理与编排三部分。计算资源池分为基础设施层和测控功能层。
(1)基础设施层
主要提供系统运行的软件、硬件环境,其中,软件环境包括云平台管理系统、操作系统、数据库管理系统、虚拟化管理系统等;硬件环境包括物理服务器、分布式存储设备、网络设备和加速卡设备等,各类物理资源通过虚拟化形成通用的虚拟计算资源、存储资源、网络资源和加速资源,承载各类业务应用和服务。
(2)测控功能层
测控功能主要完成测控功能的软件化实现,主要分为信号处理和信息处理两大部分。信号处理主要完成测控信号捕获跟踪、位环、码环、帧同步以及编译码等功能。信息处理主要完成测控信息处理及分发,包括遥测处理、遥控处理、测距测速处理、遥控处理等功能。
(3)射频IP化前端资源池
将接收机接收到的射频信号进行调理,分别经射频数字化处理卡的AD采集、信号处理等操作后转换为数字基带信号,封转成网络数据包并发送给计算资源池。同理,计算资源池可将基带信号传输到射频数字化处理板上,通过DAC进行数字上变频,和波形整形后传输到相应射频通道。
(4)管理与编排
实现对基础硬件、虚拟化资源和测控功能的全生命周期管理以及对网络业务编排功能。同时,实现射频IP化前端资源池的分配以及动态建立IP化设备与测控功能的数据链路。
由于网络特性以及网络传输协议的影响,导致接收的信号时域波形中会出现随机或连续的数据中断、乱序、错误,更进一步地会影响到测距、测速与测角的零值及随机差。
基于测控信号在频域上的稀疏特性,可采用快速傅里叶变换得到信号的频谱信息,根据实际信号的频点信息对该频域数据进行提取,得到实际传输的有效信息,从而达到减小传输数据量、充分利用网络带宽的目的。
针对利用现有网络传输基带信号波形失真的问题,应该从网络协议入手,提高利用网络传输基带信号的可靠性。传输层协议建议选用TCP的方式来保证数据的可靠传输。应用层协议可选用自定义帧协议格式或者VRT(Vita Radio Transport)格式。VRT定义了一个在射频收发机和信号处理设备之间的传输协议,用于提升射频和信号处理单元之间的协同性,广泛应用于频谱监测、通信和雷达等领域[10]。VRT帧格式如图2所示。
31 30 29 282726252423 2221 2019 18 17 1615 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0包类型CT×MTSITSF序号含包头在内的总长度流标识符时间戳负载数据尾部(仅限于数据包)
1.3.1 操作系统优化
国产麒麟等Linux系统本身不是实时操作系统,需要进行内核实时性增强来进行优化,具体优化内容如下:用互斥锁替代自旋锁;采用“优先级继承”策略避免优先级反转;通过中断线程化方式来保证测控算法可以作为最高优先级的执行单元来运行,即使在系统高负载下仍能保证实时性。
1.3.2 网络I/O优化
采用SR-IOV(Singe Root I/O Virtualization)+DPDK(Data Plane Development Kit)来提高数据交换的性能。SR-IOV技术可以直接屏蔽虚拟层,采用多个虚拟机与物理网卡硬直通方式实现线速数据收发,比其他全虚拟化与半虚拟化的网卡虚拟化方案更加高效[11]。DPDK不仅实现了网卡缓冲区到用户空间的零复制,还提供虚拟环境下的虚拟接口,兼容OpenvSwitch虚拟交换机,可以达到单核20 Mpacket/s(百万分组/秒)的处理能力。
1.3.3 程序优化
主要通过如下手段来进行测控功能算法优化,以提高处理效率及实时性:减少线程调度开销;提前分配需要的内存,避免在使用过程中临时分配和释放;将已分配和可能分配的内存锁定在进程的地址空间中,避免因写时拷贝(Copy on Write,COW)导致的缺页中断影响程序运行效率。
航天测控信号处理的实时性要求较高,需要引入物理层硬件加速器的方法,将计算复杂度较高的信号处理模块(捕获、编译码等)放在加速器上,使用专用的加速卡进行物理层加速。其他计算复杂度较低的信号物理层单元、数据链路及网络层模块可以放在服务器的虚拟机上,由 CPU进行处理。
现阶段,所有云产品都不支持加速卡虚拟化功能,需要自主研发来满足加速卡管理功能,图3给出了加速卡虚拟化方案。
图3 加速卡虚拟化方案
加速卡虚拟化主要由三部分组成。
(1)物理层
主要由配置了多块加速卡的通用服务器组成,加速卡作为共用资源可以给所有的测控功能进行加速。CPU和加速卡通过40 Gb/s网络互连,保证数据的快速交换。
(2)虚拟化层
在每一个虚拟机上运行一个 “加速卡虚拟模块”,虚拟机上的测控功能认为自己独占该卡,测控功能与该模块进行直接通信。加速卡虚拟模块向调度中心申请资源,由调度中心分配可用的资源给加速卡虚拟模块,加速卡虚拟模块与加速卡进行数据交互,完成一次运算。
(3)调度层
加速卡资源调度中心完成加速卡状态监控、健康管理、加速任务创建及跟踪闭环、资源管理与调度功能。加速卡资源调度中心屏蔽了加速卡的差异,可支持异构加速卡,不影响顶层应用。
1.5.1 任务编排
任务编排主要完成任务一键化自动调度及资源分配,实现任务重构、故障重构、灵活性好、可靠性高的目标。通过管控系统还可监视任务的运行状态,包括资源状态、测控算法状态等信息。
提供可视化工具来对不同测控功能的应用模板进行编辑,包括软件构件、构件连接关系,对CPU、内存、加速卡等资源的需求,以及对通信带宽、实时性的需求。
由于射频IP化前端与虚拟基带不是固定连接,因此前后端设备的网络通信参数作为一种资源也需要由任务编排进行管理及维护。在测控任务执行前,任务编排功能分配IP地址及端口,并发送给前端IP化设备和虚拟化测控基带,这两类设备根据通信参数完成链路建立;任务结束后任务编排功能控制设备拆除链路。
通过分配冗余的虚拟测控基带,可对某些重大任务的数据处理节点进行主从备份来保证下行数据不丢失,同时当某个虚拟机出现故障时可快速切换到备份节点恢复上行功能。
1.5.2 测控功能管理
完成测控功能的生命周期管理,包括创建、释放和日常运行;还可通过基础设施管理来收集资源状态信息,同时还能够对测控功能的资源使用情况进行监控和故障预警。
1.5.3 基础设施管理
能够完成基础设施的健康管理、资源调度和任务分配。其中,云平台完成通用计算资源、存储、网络的管理,加速卡资源调度中心完成加速卡资源的管理。
利用云平台提供的热迁移功能,可快速将故障服务器的测控功能迁移到正常服务器上,实现故障自愈。
软件解调在实现过程中最为关键的指标是系统的实时性。首先,在软件解调处理流程上将整个软件解调过程分解为若干个功能上互相串接子模块,把各个子模块以流水线式部署在不同的处理器上,实现解调过程的空间并行化处理。其次,依照子模块内部是否可以并行处理,分为如下两种处理方式:将可以进行并行处理的子模块(信号捕获及信道译码操作)部署在加速模块上执行,而将不能并行处理的各种解调环路部署在CPU上执行。将软件解调过程分解为子模块后,还需要保证各个子模块正确分配和使用内存以及数据在各个子模块间进行正确传递。
软件化信号处理架构如图4所示。
图4 软件化信号处理架构
由于测量系统对相位非常敏感,因此利用通用服务器以软件方式进行测距最大的实现难点在于数据包的随机读入、读出以及处理时间的不确定会带来测距值的随机抖动。软件测距系统中存在三个随机时间,分别是发射时从服务器向射频前端FPGA通过网络输出数据包的随机读出时间Tout、接收时从射频前端FPGA向服务器通过网络输入数据包的随机读入时间Tin和数据包在软件中的随机处理时间Timp。为了实现准确的软件测距,必须消除上述三种随机时延对测距系统的影响。
本测距系统采用软硬件协作方式进行测距,如图5所示。
图5 测距功能实现原理图
硬件部分的具体工作流程如下:在调制端,如果在软件中进行侧音产生、上变频操作并直接输出,会造成读出数据包长度加大、读出时间随机,导致不同数据包间发射最低侧音时刻随机抖动。因此,一种方式是在FPGA中进行侧音产生以及上变频操作,这样不仅减少了PCIE总线传输压力,而且消除了读出时间Tout对测距系统的影响;另外一种方法是在软件中进行侧音产生以及上变频操作,然后再送入硬件里面的一个FIFO中,通过FIFO的延迟读取操作,只要软件产生调制信号的速率高于硬件读的速率则在FPGA中的信号就是连续的,从而消除Tout的影响。
通过在收发两端设置合理的协作机制,可以消除Tin的影响。首先在FPGA内部将发射主音及最低侧音时钟与FPGA处理后降速的数据流进行复用;然后通过网络传输计算机系统;接着在计算机中进行解复用,将数据流送入主音及分频链进行处理,得到接收侧音时钟数组,而将发射主音及最低侧音时钟送入发侧音时钟恢复模块恢复出发射侧音时钟数组;最后将这两个数组信息送入距离提取模块得到测距值输出。由于发射时钟信号同接收数据同时打包送入计算机,保证了时间上对齐,这样随机读入时间Tin只会影响系统处理的实时性,而不会影响测距结果的正确性。
在分析软件测距系统工作方式之前,首先分析软件随机处理时间Timp对测距系统的影响。由于服务器中的定时精度较差,无法像硬件系统那样进行精确的时序分析,因此只能将软件测距系统等效成一个异步系统。以主音环中的积分清洗操作为例,在每次工作时处理时间随机抖动。即针对同样长度的数据序列,硬件系统可以保证相同的处理延迟;另一方面,异步软件系统针对同样长度数据序列,软件处理时间也会存在抖动。这种随机抖动导致从时间上看,计算结果输出时刻存在抖动,存在随机误差。但是从软硬件测距的计算机理上分析可知,两者计算方法相同,因此输出的相位序列值也相同,只是软件系统处理时间存在随机抖动,导致等价到时间上被“拉伸”或“缩短”。软件主音环在连续数据段间输出的相位序列依旧保持连续性,并且与同步系统在数值上相同。通过上面的分析可知,软件系统的测距值可保证计算结果的正确性。
实时云测控基带池实验平台环境如图6所示,主要由3台射频数字化前端、5台通用计算服务器、1台管控服务器和1台万兆网交换机组成。需要开展的实验测试的项目主要包括多路测控信号并行处理能力、实时云平台扩展能力及处理时延、云环境下的软件化测控处理技术。
图6 实验平台
上述实验场景可满足20路测控信号同时软件解调与测量。其中,遥测解调性能较理论值恶化小于1.3 dB,扩频体制下的测距随机差可以达到0.3 m,扩频体制测距零值开关机稳定性可以达到0.8 m。实验结果表明,基于实时云测控基带池架构的技术能够满足工程应用条件。
本文提出了一种航天测控功能虚拟化方法,阐述了总体架构以及关键功能实现路径,同时搭建了实验平台对该方法的功能和技术指标进行了验证,对于后续工程化应用具有一定的指导意义。
测控功能虚拟化是一项全新技术,是NFV架构在测控领域的一种应用场景,需要尽快开展工程化研究。此外,测控功能算法还需要进一步优化,以适应云架构场景并提升计算效能。