通用遥感卫星基带数据二级并行处理算法设计与实现
2019-06-28张人愉李景山
张人愉，李景山
(1.中国科学院遥感与数字地球研究所，北京 100094；2.中国科学院大学，北京 100049)
0 引言
卫星基带数据的处理是卫星地面处理系统的起始部分，负责卫星下传数据的帧同步、解扰、译码、解格式和解压缩等步骤，为后续的产品生产提供基础数据[1]。现今随着卫星遥感技术和计算技术的不断发展，每年都有大量遥感卫星发射，卫星遥感技术也向着高空间分辨率和高光谱分辨率的方向发展[2]。卫星传感器产生的遥感数据量不断增大，星上数据的下传码速率也随之不断增大。如当前我国主流的高分辨卫星高分1号、2号和资源三号1、2星等卫星的数传码速率为双通道450 Mbps，要实现实时的数据处理，即地面基带数据处理系统要有900 Mbps以上的处理能力。对处理卫星下传数据的地面基带数据处理系统而言，由于其处理过程需要的步骤较多，且解压缩部分计算又过于复杂，这样造成了系统设计的两个主要难点，一是对设计出具有通用性和扩展性的处理系统提出了更高的要求，二是在处理速度上要达到实时快速处理必须设计高效的解压缩处理策略。
针对卫星地面基带数据处理中的难点，已有人对此进行过一些探讨设计，比较有代表性的如何芳等[3]介绍一种基于刀片式服务器的遥感卫星基带数据处理系统平台，以建立满足国内遥感卫星基带数据处理系统的通用平台为目标而确立。杨甲森等[4]针对卫星地面应用系统支持多星多任务的运行控制需求，通过采用调度中心与处理程序集协同的工作方式，借鉴Hadoop MapReduce的框架设计思路，设计了卫星基带数据实时处理系统，且实践表明在万兆网链接的10台计算机机群上，能实现对3个地面站接收的4颗卫星的实时及事后2种模式的数据处理任务，处理的实时数据码率优于150 Mbit/s。刘莉[5]针对高速率卫星遥感数据实时处理的要求，设计了一种卫星遥感数据实时处理平台，其平台采用分层设计思想，自上而下分为表现与控制层、业务处理层、基础服务层和应用支持层，结合消息传递接口(MPI)技术，构建了分布式实时并行处理平台框架。
虽然有不少关于遥感卫星基带数据处理系统的研究工作，不过在对系统的设计上大都较为宏观，较少涉及内部算法的具体细节。在系统的通用性和可扩展性设计上，有将基带数据的每个处理过程独立设计成小程序然后组合调用的模式，和将每个过程设计成动态库调用的形式，较少研究外部配置文件能否实现通用性的文章，而外部配置的方式能最大程度实现代码的重用，无须给每一个卫星重新去实现单独的小程序。在计算复杂的解压缩的处理上，大多按虚拟信道号提取AOS(高级在轨系统)帧中数据，然后按照有效载荷分发到不同计算节点上进行处理，这种方式存在计算资源浪费的问题，不同载荷数据处理按节点进行了分离，使得在处理一个载荷时，另外载荷的计算节点处于等待状态，这不利于解压缩的快速处理。而使用MPI+OpenMP结合的方式用于基带数据的解压缩则能解决上述计算资源浪费的问题，而且得益于MPI在分布式计算上的优势，在计算节点的扩展上也十分便利。
本文在研究和借鉴高性能遥感卫星数据地面处理系统机群解决方案设计[6]的基础上，设计并实现了通用的基于高性能机群的卫星基带数据并行处理算法。该算法在充分分析不同卫星在各处理步骤中的差异性后，基于外部配置文件的方式和软件设计模式的思想进行了通用性和可扩展性设计；同时针对计算复杂的解压缩部分，在合理设计压缩数据的划分策略和并行处理策略的基础上，实现了计算负载均衡的MPI+OpenMP的二级并行处理。
1 算法设计与实现
遥感卫星基带数据处理是以实时基带数据码流或事后基带数据文件为处理对象，经帧同步、解扰译码、AOS帧格式解析分包和解压缩等处理，生成初级产品的过程。该过程如图1所示。
图1 遥感卫星地面基带数据处理流程
本文设计的通用遥感卫星基带数据二级并行处理算法在功能上具有如下指标：
①能配置输入源为网络或本地文件。
②能够对基带数据进行帧同步，准确提取帧同步字，对传输过程中出现的帧头滑位等错误进行纠正。
③能够将加扰的数据区域进行解扰，能配置扰码起始状态参数。
④对解扰后数据进行译码处理，能实现常见纠错编码如RS码和LDPC码的配置。
⑤对译码处理后的数据进行AOS帧格式解析，提取有效数据域，根据虚拟信道号进行数据分离。能通过配置AOS帧参数来实现不同卫星的处理。
⑥对各信道数据进行快速解压缩，能使用高性能计算技术最大程度地使用计算资源。
⑦拼接解压缩后数据，解析相机辅助数据，生成特定格式产品。
1.1 总体设计
本文设计的算法重点主要体现在两个方面，一个是通用性和可扩展性，一个是处理速度。这两个方面在遥感卫星基带数据处理中是难点。当前卫星数量不断增加，各卫星使用技术上存在差别，要实现通用和可扩展处理具有难度，而遥感卫星下传码速率也不断上升，对基带数据处理的速度要求也越来越高，要实现快速实时的处理难度也很大。但是如果能解决这两方面的问题，意义是重大的，解决通用性和可扩展性可以对新发射的卫星进行快速部署处理，解决处理速度问题就可以应对未来下传码速率的不断提高，实现遥感卫星数据的实时处理，所以良好的通用性与可扩展性，和快速实时处理基带数据就是本文算法想要达到的效果。
对于通用性和可扩展性的设计本文使用了外部配置和软件模式相结合的方式。使用外部配置来达到通用处理的方式是最简单方便的方式，因为该方式无需对程序代码进行任何形式的修改即可实现新卫星的扩展。某些不能通过外部配置实现扩展的，可以使用合理的软件设计模式，使代码最大程度上实现重用，同时对原有代码的改动达到最小。本文在设计通用性和可扩展性方面，结合了资源三号1、2号星和高分1、2号卫星的地面处理系统接口规范，对其中使用的技术、数据编排规范等进行了充分了解，总结出整个处理过程中能通过配置实现扩展的部分和需要编程解决扩展的部分，最大程度达到主流通用可扩展。
在处理速度方面，本算法选择了MPI+OpenMP相结合的并行编程模型。当前并行编程模型中消息传递模型仍是大规模并行编程主流，MPI作为消息传递编程模型事实上的工业标准，设计方便分布式计算，具有程序性能高、扩展性好的特征[7]。OpenMP是面向共享存储系统的主要并行编程模型和事实上的工业标准，它具有编程简单、可移植性好等优点[8]。本文算法使用MPI和OpenMP相结合的方式进行并行编程，能将二者的优势进行结合，MPI可以方便地进行计算节点间分布式计算编程，OpenMP方便节点内部共享内存并行计算。本文算法中选取基带数据处理过程中计算量最大的解压缩部分进行重点的两级并行设计，对于其他处理步骤，由于计算量相对解压缩而言小的多，所以只使用了线程级别的并行处理即可满足处理的要求。
基于上面的设计原则和思路，本文算法的整体结构设计如图2所示。
图2 算法整体结构设计
1)在计算节点1上进行数据的接收、帧同步、解扰、译码和AOS帧格式解析操作，为使处理速度更快，数据的接收同步放在一个单独的线程进行处理，解扰和译码通过OpenMP进行并行化处理，AOS帧格式解析和分包发送放在一个线程上处理，这3个部分之间通过2个线程安全的数据队列进行数据传递，数据接收、帧同步和解扰译码形成一种生产者-消费者模式，同时解扰译码和AOS帧格式解析同样形成生产者-消费者的模式。计算节点1上各虚拟通道的数据最终通过IB高速网络发送到计算节点2。
2)在计算节点2上为每个虚拟信道数据的接收和解析压缩块开辟一个线程，解析得到的通用压缩块数据放入待解压缩队列中等待处理。计算复杂的解压缩部分通过MPI进行多个节点间进程级别的并行计算，每次计算以计算节点的倍数个压缩块进行分配，保证计算任务的均衡分配，在节点的内部通过OpenMP进行线程级别的并行处理。数据在解压缩之后的拼接写入放在一个单独的线程进行处理。
3)在解压缩计算节点上只实现单纯的解压缩功能，合理设计的通用解压缩块数据作为节点上处理的基本单位，而节点内部可将通用解压缩块数据分为若干基本压缩单元，利用OpenMP对基本压缩单元进行并行处理，然后发送回计算节点2。
整个处理流程中的数据以一种类似流的方式在各个处理步骤间流动，在计算量大的步骤通过多线程技术和并行处理技术来增加计算资源，使之快速处理，使整个处理过程中各部分之间的等待时间尽可能的短，从而充分利用计算资源。如在解扰和译码部分计算量相对较大，本文算法通过OpenMP将其处理进行了并行化，并行使用的线程数目维护一个最小值和最大值，根据实际的处理情况线程在最大最小值之间浮动，实现动态的计算负载均衡，具体的线程增减策略通过对其前后的数据队列大小进行监控设置，当帧同步后的队列处于较满的时候，动态增加2个线程给解扰和译码部分，帧同步后队列处于快空的时候，动态减少2个线程，但增减范围都在最大最小值之间。计算量最大的解压缩部分通过MPI+OpenMP的二级并行进行处理，该部分是整个处理系统中性能的关键点，具体的处理策略将在后面单独进行说明。
1.2 算法通用性设计与实现
整个处理过程中通用性设计是本文一个重要探讨的主题，整体设计思路是通过外部的配置文件加上内部使用软件设计模式思想实现。通用性设计的关键是对整个处理过程中的处理步骤在不同卫星中的异同加以分析，合理设计配置文件参数，达到在不修改或极少修改原有代码的基础上实现新卫星数据的处理。能通过配置文件配置的部分，主要是针对AOS帧格式解析，分析好AOS帧格式后基本能实现帧同步到AOS分包过程中的通用性设计；在使用软件设计模式的部分，通过模板方法和工厂模式来实现，主要步骤在通用压缩块的解析、压缩算法的选择和最后拼接存档部分。以下将就上面2种方式的具体细节设计和实现进行更详细的说明。
1)通用AOS帧格式解析。在设计之初考虑到CCSDS高级在轨系统(AOS)标准已成为世界航天飞行器空间数据系统的新一代技术体系标准，并被绝大多数的空间组织和国家所采纳[9]，我国现今的主流卫星基本上都采用这一标准进行数传系统的数据组织格式，如资源三号系列和高分系列卫星都遵循该标准，所以本算法的通用性设计主要针对遵循CCSDS高级在轨系统标准的卫星进行。一个典型的AOS帧数据格式如图3所示。
信道编码/加扰区/译码校验区/CRC校验区格式编排同步字VCDU主导头版本号VCDU标识符航天器标识虚拟信道标识VCDU计数器信号域回放标识备用域VCDU插入区VCDU数据BPDU导头BPDU位流数据区VCDU差错控制域译码校验符号域
图3 AOS帧数据格式
从帧同步到AOS帧格式解析分包过程中，帧同步准确地提取遥感卫星下行数据流中的帧同步字，获取正确的帧结构，而后的几个步骤的处理都是以帧为基本单位进行处理，所以对帧结构的通用化是实现这一部分通用化的关键。在图3中描述的帧数据格式中，整个帧的数据以同步字起始，该同步字经过一定的处理用于帧同步，加扰区的数据需要进行解扰操作，译码校验区需要进行相应的译码处理，CRC校验区要进行CRC校验，在AOS帧格式解析分包处理中主要需要解析虚拟信道标识、VCDU计数器和VCDU数据单元，将对应虚拟信道中的BPDU位数据流进行提取，得到压缩的图像数据和辅助数据。通过分析AOS帧数据格式，本文设计了用于配置AOS帧格式的外部配置文件，该配置文件能描述AOS帧中的各项参数以及参数的位置。以下使用资源三号2星正视相机虚拟信道号的设置格式进行说明，AOS帧中的其他参数的设置具有类似结构：
2)解压缩的通用性设计。本文在解压缩的通用性设计上主要使用软件设计方法中模板方法和工厂模式方法，以及设置合理的通用数据结构。模板方法模式通过定义抽象的函数接口，使子类可根据自身情况进行方法的实现，在使用时结合工厂模式能很好地达到易扩展的目的。在卫星数据解压缩的通用性设置上，将数据的具体解码分为了3个层，1个是解码器的抽象层，规定了解码类需要实现的具体接口，然后是具体解码器算法选择层，该层实现具体的解码算法，如资源三号即实现JPEGLS解码算法，卫星层主要用于具体卫星的解码算法选择，不同卫星即使在压缩数据上使用相同的压缩算法，但实际具体实现时具有一定的差异，卫星层很好地解决了该问题。工厂模式通过卫星标识选择对应卫星解码器实例，新增卫星时，通过实现具体卫星层类，将卫星加入工厂模式即可实现可扩展。通用解码器类关系图设计如图4所示。
图4 压缩数据的解码器类关系图
模板方法和工厂方法的使用可使得解压缩算法扩展性变得容易，当需要处理一个新卫星的数据，只要实现该卫星自己的解码器接口，然后将新的卫星解码器加入工厂类即可。除了在解码器的实现上使用了模板方法和工厂类，在解压缩后的数据拼接和存储上同样使用了相同的思想，不同卫星通过继承拼接写入基类实现自己的拼接逻辑，从而使拼接写入具有易扩展性。
在整个解压缩的通用性设计上通用的数据结构同样起着十分重要的作用，有了通用的解压缩结构，使得在解析AOS分包后的图像数据和辅助数据上变得容易，同时解压缩逻辑上也变得更加清晰，无需为不同的虚拟信道数据进行单独的处理，所有数据放入同一个处理队列中，非常便于进行分布式并行处理，且利于计算资源的负载均衡。在得出通用解压缩数据结构之前，需要分析一般卫星压缩数据和辅助数据的编排格式。本文通过分析资源三号1、2星和高分1、2号卫星的压缩数据和辅助数据编排格式，最后得出了通用的压缩数据块结构。图5为资源三号1星正视相机的数据编排格式。
图5 资源三号1星正视相机压缩数据编排格式
在分析资源和高分卫星的过程中，发现所有这些卫星在编排数据的时候基本使用一致的格式编排，数据划分以幅为大单位，幅的下面分为块，块的下面分为辅助数据和小的压缩单元。所以本算法设计了如图6所示的通用压缩数据块结构，用于放入解压缩处理队列中进行分布式并行解压缩。
图6 通用解压缩块数据结构
通用压缩块数据结构的设计解决了同一卫星中不同虚拟信道数据必须分开处理的问题，现在所有虚拟通道的数据遵循该结构进行解析就能无差别地放入解压缩处理队列。解压缩处理完成后的数据同样使用该结构储存，只是压缩数据变为了已经解压缩后的数据，进行拼接的时候能根据虚拟信道号放入不同的队列，然后根据幅序号和块序号拼接数据还原图像。
1.3 并行解压缩
数据解压缩的过程在整个基带数据处理中属于计算最复杂的部分，也是本文算法的一个核心部分，通常一台机器远远不能满足快速解压缩的要求，所以本算法使用多台机器进行分布式计算，利用MPI进行计算节点间进程级别的并行，在计算节点内部使用OpenMP进行线程级别的并行，整个并行解压缩的流程如图7所示。
图7 MPI+OpenMP的并行解压缩框架图
从上一小节中可知，本文设计的通用压缩块数据结构大大方便了解压缩的分布式并行处理，本节说明的解压缩并行处理算法就是以该通用压缩块数据结构队列为数据的输入，经过MPI将压缩块数据发送到各计算节点进行粗粒度的并行处理，在计算节点内部，压缩块内部的压缩单元通过OpenMP在线程级别上进行细粒度的并行处理，处理完成的数据通过MPI重新发送回源节点，然后将数据以块的方式放入拼接类，在拼接类中维护有多个队列用于存放各虚拟信道数据，当数据队列满足拼接需求时，对数据进行拼接写入。
本文的并行解压缩算法在理论上具有计算资源接近0等待的优点，只要前面步骤一直在处理数据，解压缩队列中就持续有数据进入，那么并行解压缩就会持续进行，用于计算的节点就会全部处于计算运行状态，直到解压缩队列为空。区别于将特定虚拟信道数据发送到特定节点进行处理的策略，一旦在某些时刻一些信道的数据较少，那么处理这些较少数据信道的节点会存在资源等待，从而出现计算资源的浪费。本算法设计的二级并行解压缩很好地解决了这个问题。
2 实验验证分析
本文以资源三号1星在2017年5月30日由喀什站接收的轨道号为029922的2个通道的基带数据作为实验数据，算法处理程序运行在有5台机器组成的机群服务器上，每台服务器配置2颗4核的Intel Xeon E5620处理器和24 GB内存，服务器之间通过带宽20 Gbps的IB高速网络连接，实验数据存储在服务器内部署的lustre并行文件系统之上。实验中共使用5个节点，1个节点用于帧同步到AOS帧格式解析，其余4个节点用于并行解压缩和数据拼接写入。将MPI并行进程数设置为4，OpenMP线程数设置为16，使计算资源最大化，得出测试结果如表1所示。
表1 资源三号1星解压缩实验测试结果
由实验结果可知本文的处理算法具有较好的处理速度，满足了资源三号1星双通道450 Mbit/s下传码速率实时处理的要求，解压缩输出的数据率达到了4.8 Gbps。将输出的解压缩后图像数据截取10 240行，得到图像如图8所示。
图8 资源三号1星的解压缩结果影像
在实验中对并行解压缩部分进行了并行加速比的测试，加速比S的定义如公式(1)[10]所示，为并行处理时间除以串行处理的时间。测试数据使用单通道1的数据进行，整个测试分为三个部分，一是测试MPI在节点间的并行加速比，二是测试OpenMP在节点内部线程级别的加速比，三是将MPI和OpenMP结合起来测试加速效果。
(1)
首先对解压缩进行了节点间MPI的并行实验，实验的过程中每次将节点数目递增，节点内部线程数目设置为1，来查看单纯的MPI的并行处理的加速效果，实验结果如表2所示。
表2 MPI并行实验结果
从表2中可以看出，随着节点数目的增加，解压缩时间能明显减少，通过计算并行加速比，能更加直观地得出并行加速的效果，图9展示了MPI并行加速比与理想加速比之间的差别。在实际中由于网络带宽等因素的影响，MPI并行处理的加速比不可能达到理想效果，不过本文实验中由于节点数较少，MPI加速效果还是处于比较理想的状态。
图9 MPI节点间并行加速比
然后对OpenMP在节点内部线程级别并行进行测试实验，保持整个测试在一个节点上进行处理，依次改变节点内线程的数目，得出的实验结果如表3所示。
表3 OpenMP并行实验结果
节点内部的OpenMP实现线程级别的并行，从结果可以看出，随着线程数量的增加解压缩时间能明显减少，通过计算并行加速比，可以得出图10所示加速比结果图。
图10 OpenMP并行实验加速比
在OpenMP的并行实验中，加速比直线并没有按照较理想的加速比进行增长，一是OpenMP在每次并行处理时需要进行一些线程的初始化工作，二是由于并行处理时不同基本压缩单元的处理时间不一定相同，这会导致一些无法避免的线程等待，影响并行效果。而图10中在线程数为6时出现加速比向下波动的情况，是由于资源三号的通用压缩块结构由16个基本压缩单元组成，当线程数能整除16时，并行能实现资源的负载均衡，一旦线程数不能整除16时，那么会存在一定的线程间等待，影响并行效果，这也为本文调优OpenMP并行线程数目提供一些借鉴，即将OpenMP的并行线程数设置为能整除通用压缩块结构中基本压缩单元数目的值。
最后，将MPI和OpenMP进行结合进行实验，保持每个计算节点内部8个线程并行，而计算节点的数目不断增加，最终得出表4所示结果。
表4 MPI+OpenMP并行实验
为直观分析加速效果，将实验结果的并行加速比与理想线性加速比进行对比作图，得出图11所示结果。
图11 MPI+OpenMP并行实验结果
从并行加速比的结果图中可知，当并行的CPU核数增加到一定程度时，并行加速比增长将趋于平缓。造成这个现象的原因有很多，如网络传输速度和延迟、OpenMP的线程创建开销、CPU的调度、数据的复制和并行处理的压缩块之间的差异等。本文另外做了个小实验，通过屏蔽解压缩的解码计算过程，即直接将解码后的数据填充0值，保证了相同大小的数据量，但没有解码的计算过程，来单纯的看除并行解码计算之外的耗时。在4个节点的情况下，不管单节点的线程取1到16的任何值，所需耗时都在80±2s，在4节点8线程解压缩时，这部分的耗时占比达到了47%左右，而这部分耗时是很难通过增加计算节点和线程数来减少的，所以表现上就是解压缩单纯的解码计算的时间随着节点和线程数的增加而减少，但解码之外的耗时的占比却在持续增加，这导致了加速比会随着节点和线程数的增加而慢慢趋于平缓。
本文对程序的通用性和扩展性同样进行了实验，选取了资源三号2号星2017年10月18日密云站接收的基带数据，通过配置资源三号2号星的处理配置文件和编写具体解码器类(本实验直接使用的资源三号1号星的解码器，对通用性的验证没有影响)和拼接类，可实现对资源三号2号星数据的流程处理。
3 结束语
本文针对地面基带数据处理中处理步骤较多、通用性设计困难以及解压缩计算复杂的特点，设计并实现了一个具有良好通用性和扩展性的地面基带数据二级并行处理算法。文章首先对遥感卫星地面基带数据处理系统的流程进行了介绍，设计了AOS帧通用的格式解析配置文件，实现了从帧同步到AOS帧格式分包的通用性处理，对解压缩部分和拼接部分，通过模板方法和工厂模式以及设计通用解压缩块数据结构的方式，实现了可扩展性设计；其次文章对计算最复杂的解压缩部分设计了二级并行处理模型，实现了分布式并行处理，利用MPI进行节点间粗粒度的进程级别并行处理，利用OpenMP进行计算节点内细粒度的线程级别并行处理，同时对计算资源的负载均衡进行良好的设计，保持在计算过程中具有极少的计算等待，避免了计算资源的浪费。算法的实验结果表明，在以资源三号1星为基础的程序上，配置资源三号2星的配置文件，然后实现资源三号2星的解码器类和拼接写入类即能实现资源三号2星的数据流程处理，说明算法的通用性和扩展性得到了验证，在速度上利用5台刀片服务器实现了资源三号1星的实时处理，说明算法具有较好的并行处理性能。下一步工作的重点是进一步验证算法的通用性和可扩展性，实现更多卫星的验证处理工作，以期实现高分系列卫星的快速实时处理。
