基于任意长度的数据帧头搜索实现方法

汤 昊，范志芳

(1.中国空间技术研究院西安分院，西安 710000；2.航天东方红卫星有限公司，北京 100094)

0 引言

近年来，遥感系列卫星的卫星数据类型和数据量越来越多，载荷类型呈现多样化，遥感卫星的分辨率从米级到亚米级，幅宽从几公里到几百公里。新型遥感卫星的快速发展，一次性可观测数万平方公里，重访频次越来越高，甚至要求可持续监视，数据任务量成量级增长，数据类型也变化多端，随着卫星种类越来越多，多维信息不断增强，因此，相应的对遥感地面处理也提出了更好的需求，地面处理必须要考虑卫星处理协同才能发挥效能，为地面处理带来新的难题。

目前卫星由于处理数据量较大，实时性要求较高、数据类型多样化[1-10]等特点，对地面设备在进行基带处理的时候提出了更高的要求，在设计时如何保证数据的多样化自适应处理成为设计难点。

随着数传技术的飞速发展，卫星数据传输也呈现越来越多样化，而相对应的，地面接收处理的需求也随之逐渐多样化，如何更加高效地、高速率地完成地面数据传输的海量数据处理成为了难点。针对数据类型多样化的实际需求，数据格式也呈现多样化的特点，对不同数据格式需要对应的处理方式也不同。例如，不同的数据格式长度，就不能使用传统的固定位置搜索该数据，必须采用适应范围更广泛的搜索方法。文章所论述的处理验证系统就是以研制基于任意长度帧头的数据流搜索的实现方法，并且以满足当前卫星数传基带处理系统的设计理念而确立的。

1 地面基带处理系统设计思路

1.1 地面基带处理系统的总体设计

卫星地面基带处理系统[11-12]主要对卫星下传数据进行处理，恢复出原始数据，其系统方案设计如图1所示，分别由格式解析、解压缩、数据监控[13]等3部分组成。各模块具体功能介绍如下：

1)格式解析处理模块完成对原始基带数据的格式解析处理。接收到前端原始基带数据后，首先进行数据帧头搜索，完成对数据的判读、实时处理、去除格式信息、虚拟信道分离、有效数据提取等操作，并实时发送给后端解压缩节点。其前后端的数据接收和发送均是通过网络传输的方式来实现，此外，该模块还具备存储功能，可将需要的中间某级数据存储在本地服务器，以便分析查看。

2)解压缩处理模块接收到格式解析模块输出的数据后，分别进行帧头搜索和解压缩处理，并对处理后的数据进行网络格式打包、信息判读等操作，将最终的网络格式数据发送给后端的数据监控处理模块。此外，该模块也应具备存储功能，把需要的中间某级数据存储在本地服务器，以便后续分析查看。

3)数据监控处理模块对解压缩处理模块输出的数据进行帧头搜索和信息判读。与前两个模块相同，数据监控模块也应具备存储功能，以便后续分析查看。

图1 卫星地面基带处理系统总体设计图Fig.1 Overall design of the satellite ground baseband processing system

1.2 地面基带处理系统的具体流程

1.1节介绍的卫星地面基带处理系统总体设计方案主要包括3大模块，分别是格式解析模块、解压缩模块、数据监控模块。这3大模块有一个共同特点，就是每个模块接收到前端的输入数据之后，都会首先进行帧头的搜索，然后再进行后续各自具体的功能处理，因此文章提出的基于任意长度的数据帧头搜索方法对这3大模块均可适用。下面的介绍中把这3大模块统称为数据处理模块。

地面基带处理系统的数据处理模块的具体数据处理流程如图2所示，对于地面基带数据来说，可能包括n路不同信道的数据，对于每一路数据都需要进行相似的流程处理。

1) 首先进入数据接收模块，接收到前一级的输出数据作为本级的输入数据，然后对接收到的输入数据进行帧头搜索，对于每个模块而言，搜索的帧头可能并不相同，但是搜索的机制是一致的，因此统一均可用本文提出的这种帧头搜索方法实现各种模块、各种不同字节帧头的搜索。

2)对步骤2搜索到的每两个帧头之间的数据进行数据处理，不同的模块分别进行不同的处理，对于某些特殊的卫星型号 ，数据处理模块内部也许还会用到二次帧头搜索，对于这种二次搜索帧头同样也可采用本文提出的方法实现。

3)对数据处理之后的数据进行数据格式的编排，根据实际后级的需求，需要将输出的数据格式编排成指定的数据格式，然后将编排之后的数据发送给后级设备。

图2 地面基带处理系统流程图Fig.2 Ground baseband processing system flowchart

2 传统的数据流帧头搜索方法

卫星地面基带数据是一种大容量的数据流，一次成像任务，基带处理系统每次接收到少则几个G，多则几十个G，甚至几百G的数据，接收到数据之后，地面基带处理系统需要对这些数据进行实时的处理。鉴于卫星数传的处理特点，卫星处理的时候给数据流增加了一些特定的网络帧头，以便标识和查找定位，因此，在地面基带处理的过程中，就需要不断的搜索寻找某个特定的网络帧头，直到找到需要处理的最终有效的数据流，然后对该数据流进行后续真正的处理。

对于以往的卫星来说，增加特定网络帧头的时候，每两个网络帧头之间的长度是固定的，因此相对应的，对于地面基带数据处理来说，搜索寻找网络帧头的时候，只要从固定长度处即可寻找到需要的最终有效的数据流。具体流程如下：

1)接收输入数据，并放入固定大小的缓存A中；

2)判断该缓存的固定位置的起始几个字节是否为帧头，如果是，把该缓存的数据拷贝到另外一个大缓存B里面，执行下面第3步；如果不是，若该步骤是第一次执行，那么丢弃，重新继续步骤1接收输入数据，若不是第一次执行，那么同样把该缓存的数据拷贝到另外一个大缓存B里面，执行下面第3步；。

3)继续接收输入数据，重复步骤1、2。

然而，随着卫星发展的多样化，根据某些需要，卫星星上压缩和数据处理在增加网络帧头的时候，是随机增加的，每两个网络帧头之间的长度是任意的，并不固定且大小随机，因此每个帧头在固定缓存的位置并不固定，这种设计给后端地面基带数据处理增加了一定的难度，而地面基带数据处理在处理的时候搜索寻找网络帧头又是必需的一个步骤，因此，文章提出的一种基于任意长度帧头的数据流搜索的实现方法，不仅解决了这个设计难题，而且提高了数据处理速度和精确度。

3 基于任意长度的数据流帧头搜索方法

文章提出的一种基于任意长度帧头的数据流搜索的实现方法的具体实现流程图如图3所示。

图3 任意帧头搜索方法的具体实现流程图Fig.3 Flowchart of the implementation of any frame header search method

具体实现步骤描述如下：

1)采用引进向量容器(vector)[13-14]的方法，向量容器的数据安排以及操作方式与数组很相似，但是向量容器是动态的，随着元素的加入，它会根据需要自动扩充空间以便容纳新的元素。这种方法比较灵活，应用范围非常广泛，既可以适用于固定长度的数据帧头搜索，也可以适用于不固定任意长度的数据帧头搜索，而且适用的长度长短随机。

把数据放在一定大小的缓存中，对缓存中的数据，首先只进行搜索帧头(帧头假设为XXXXXXXX)，每搜索到一次帧头，都把该帧头(XXXXXXXX)所在的位置(设为j)，存储在向量容器中，如：index.push_back(j)即可，对该缓存中的搜头完毕后，判断当前该向量容器的大小是否为0，若为0，则表示没有搜到帧头XXXXXXXX，若不为0，则进行下一步的操作，对每两个帧头XXXXXXXX之间的数据进行后续的基带处理，如此循环，直到最后一个帧头XXXXXXXX，把最后一个以XXXXXXXX开头的数据流存储在一个局部缓存中即可，这样不会因为搜索帧头而造成数据的丢失。

2)采用定义一个局部缓存的方法，把每次拷贝进来的数据(假设大小为BIG_LENGTH)拷贝到该局部缓存A中，把该局部缓存的大小定义为2倍的拷贝数据大小(即为2*BIG_LENGTH)，原因如下：把最后一个帧头XXXXXXXX开头的码流拷贝到该局部缓存中，且该码流的大小一定是小于等于拷贝进来的数据大小BIG_LENGTH的，因此，只要定义该局部缓存大小为2*BIG_LENGTH，则不会出现数据溢出的问题。

根据以上方法，选取500幅，1536×3072像素的卫星图像[15]作为测试数据，在相同的硬件平台上，分别对传统的搜索方法和本文提出的搜索方法进行对比测试。统计两种搜头机制下对每组数据处理所需要的时间和计算的精确度，具体统计结果如表1、表2所列。

表1 新的搜头机制与传统搜头机制测试时间比较Tab.1 Comparison of test time between new search mechanism and traditional search mechanism

表2 新的搜头机制与传统搜头机制测试精确度比较Tab.2 Comparison of testing accuracy between new search mechanism and traditional search mechanism

可以看出，本文提出的新的搜头机制所消耗的时间少、处理速度更快、精确度更高。

通过该种帧头搜索的方法，可以实现对任意长度、任意形式的网络数据帧头的搜索查找。该方法已经成功应用于目前地面基带数据处理系统中，成功应用于多个型号卫星，数据处理效率得到了很大的提升。

4 结论

目前卫星地面接收处理软件内部会涉及到海量数据的处理工作，如何提高数据处理的任意性、广泛性、实时性以及准确性是软件设计的重点和难点。因此文章提出了一种基于任意长度帧头的数据流搜索的实现方法。经过大量的测试验证，通过该种方法，地面处理软件能够完成实时对任意长度数据帧头的搜索查找，该机制对于软件搜索的广泛性具有较大的提升，具有很好的应用价值。