翻译：http://blog.csdn.net/jimmyisme/article/details/78863789
作者：JAMES CURRAN, MARKEL ARIZA BALETA, THOMAS PANY, SANJEEVE GUNAWARDENA
过去几年来，面向GNSS应用或支持GNSS频段的软件无线电数据采集系统和的处理平台设计已经被广泛采纳。对于后处理，正确解析这些GNSS软件接收机采样数据集由这些系统产生或消耗的历史数据集是一个繁琐而且容易出错的工作。这些系统需要产生各种格式的数据集，当这些数据集的细微之处通常会在转换时丢失掉。本文描述的是导航中心的GNSS SDR元数据标准和相关的开源软件项目。这个免费和开放标准最初公众意见征询过程目前正在进行，直到2017年12月31日。欢迎读者在sdr.ion.org提交反馈意见。
GNSS软件无线电是GNSS接收机研究和设计中一个迅速发展的领域。在过去几年间，这个领域里取得了巨大的发展。大学和其它研究机构已经开发和展示了先进的能力，尤其是在有挑战的环境下对多星座GNSS和GNSS+多传感器导航处理。最近商用的多传感器数据采集设备，开发平台和开源软件项目都在快速创新步伐中催生。事实上，从现在到未来十年，软件无线电可能成为一个重要的商用GNSS接收机结构，部署多个全球或区域性的导航卫星星座及其不同的信号结构，以及并行低功耗处理器和廉价传感器的快速发展。
非实时软件接收机操作场景涉及样本的存储和后处理。这些采样的数据文件可以被用于GNSS接收机实验室测试和评估中的射频回放系统。后处理和/或回放要求几个通用的前端参数例如射频和中频中心频率，采样频率，文件形式，以及GNSS专用信息例如天线定位和类型。我们定义这些信息是GNSS软件接收机的元数据。元数据的手动转换是今天常用的方法，这是起码一个繁琐而容易出错的过程，没有建立自动进行元数据交换的方法。
在ION GNSS+ 2013年会中，一组参会者讨论了GNSS 软件接收机元数据交换的官方标准的需求。这个小组确定从事这项活动目前具有以下好处：
■ 它确定并将国际GNSS软件接收机社区合为一体成为一个工作组。为了获得广泛的认可和使用，这种合作至关重要。
■ 标准化将有助于避免技术细分问题，同时通过标准实践和合规工具促进创新步伐。
■ 正式标准如果得到广泛采用，将有助于确保未来GNSS软件接收机的兼容性和互操作性。 具体而言，前端不明的“即插即用”式软件接收机开始被设想。 这些将有可能彻底改变未来的定位，导航和定时（PNT）系统。
在过去的二十年中，大部分显著的GNSS软件接收机领域的出版物和贡献者大部分都是ION成员，并经常出席与会。因此，我们决定通过ION赞助来实现这个标准。 在2014年1月在圣地亚哥举行的理事会会议上，ION批准了建立正式标准的过程。 ION GNSS 软件接收机元数据工作组（WG）于2014年4月成立。成员涵盖美国，欧洲，亚洲和大洋洲的学术界，工业界（包括GNSS SDR产品供应商以及传统的GNSS设备制造商），非盈利研究结构和政府机构。
GNSS元数据标准化的理由
图1 显示当今GNSS软件接收机系统中主要使用的元数据传输方案。第一行描述了数据采集系统（DCS） A，产生软件接收机处理器A消耗的软件接收机文件或者格式A，这可能展现的是一个由供应商或最初围绕特定硬件平台开发系统提供的端到端的解决方案。在一些情况下，假定用于格式A的元数据被硬编码到处理器中。结果，支持其他文件格式涉及扩展的软件修订。一个组可能希望将DCS A的软件接收机文件与其它使用软件接收机X和Y的组进行研究合作上的共享。这涉及将文件格式和其它相关信息准确的传达给其它组。如今，这些元数据传输以ad-hoc的方式进行，而这种方式更容易出现错误。
第二行描述多流的DCS B产生的文件有更多复杂的格式。软件接收机处理器X和Y展现了更为灵活的软件接收机以至于能支持更多格式。然而，数据/元数据相关的需求仍然修手动干预。
DCS C将其他数据（例如传感器数据）与多GNSS样本流一道复用到同一个文件中。这种类型的多路复用采集将随着如VITA-49这样与软件接收机相关的数据流标准的兴起而具备更普及的潜力。在这种情况下，定制处理器C代表了一种完全支持多传感器集成能力的软件接收机。由于DCS C的GNSS流参数是开放的，软件接收机是能用ad-hoc元数据转换方案支持GNSS单独处理的。传感器数据的参数可能公开也可能不公开。
从图1中能清晰的看到，当今元数据交换ad-hoc的方法并不鼓励互操作，反而培养了技术进一步细化的潜力（即各小组开发自己的一揽子解决方案和技术）。
图2 显示的是与图1采用元数据标准的相同系统。如图所示，每个DCS与软件接收机一同产生一个兼容的元数据文件。元数据文件由兼容软件接收机处理器读入以正确方式解码，并无缝文件处理。
采用元数据标准有利于数据采集系统的开发者，因为他们的系统将变得适用于更广泛的用户群体。类似，SDR处理器的效果在能够无缝地支持来自多源的多文件格式时被扩展。因此，元数据标准化促进了GNSS SDR系统的互操作，并极大的简化了组间文件的交换。
元数据标准化还有利于后处理GNSS SDR以外的其他用途。例如，考虑使用元数据规范来合成用于RF回放系统的兼容的SDR文件。 此外，兼容的SDR文件库包含各种真实世界中的场景，这可以在兼容的RF回放模拟器中互换使用，以便对GNSS接收机进行重复性和一致性的测试。
SDR数据采集拓扑
ION 执行委员会规定，这个标准化活动不应对任何实体造成不公平。 具体来说，该标准不要求任何现有系统进行数据格式更改以达到合规。这个“不伤害”的规定意味着该标准被设计为支持所有当前和未来的 SDR 文件格式。它也意味着工作组必须“一次性正确”，因为对标准的重大修改是不可取的，并且这不利于广泛采用的目标。因此，我们考虑了可能的 GNSSSDR 数据收集拓扑的整个空间。
图3 拓扑图
图3.a 绘制的可能存在的最简单的数据采集拓扑。这是当单一射频频谱（以下简称为“频带”）是下变频和采样产生的一个单一数据流。数据流，可能是IF采样(真实采样)或者基带采样（复采样）被作为单独文件写入磁盘中。
图3.b 展示的是数据采集系统在多个文件间写到一个单独数据中一部分。这样做会降低存储驱动器持续性写入性能要求（类似RAID系统中的分条模式）。
图3.c 与图3.a类似，除了数据流表示多于一个RF频带。这种拓扑结构的一个例子是一个直接的RF采样前端架构，它有意将多个频带混叠在一起，并在基带上相邻。由于数字下变换过程，某些频带可能会被频谱倒置。
一个数据采集系统可能产生多个数据流。每一个数据流都包含来自天线阵元中一个的信息（如图3.d所示，其中每一个数据流可能围绕着多个频带，如图3.c所示）。换句话说，一个数据流可以被单带宽天线接收到的几个频带之一采样，其中多路复用的数据流被写入文件中，它代表信道采样。上述的组合也是有可能的。
每一个数据流也可能都要被不同的采样率和量化位数采样。例如，以民用GPS L1,L2,L5系统作为参考对象。在这种情况下，L1和L2的数据流是以为采样率，而L5是以10倍为采样率（由于L5信号空空带宽10倍于L1 C/A和L2C带宽），其中代表代表基础采样频率。图3.d可表达多个数据流是如何复合打包成为单一通道的二进制数据，并写入单一文件中。
与图3.d类似，图3.e画的是一个GNSS数据流复用到其它数据上并写入单独的文件。这个数据并非来源GNSS软件接收机，而是来自额外的传感器（如图所示），且被写入的专有格式并不清楚。
非GNSS数据的元数据参数规范不在现有标准化工作的范围之内。然而，标准必须支持足够的信息来跳过非GNSS的数据字节。由于元数据模式是可扩展，它可以覆盖作为特定用户需要的非GNSS软件无线电数据的描述。
值得注意的是，尽管我们在本文中使用术语“GNSS SDR数据”是泛指在标准中定义了元数据参数的采样数据的类型，但这些采样不需要与GNSS频带对应。例如，只要能够用标准的元数据参数来表示，就能被包含机会的RF信号的频带支持。
由于GNSS SDR的数据速率通常很高，许多数据采集系统将数据写入临时分割的文件，作为图3.f所描绘的。与单个大文件对比，可以通过多个较小的文件实现高效的数据管理。每个文件的元数据需要关联前一个文件和后一个文件才能表示序列。请注意，如图3.f所示的数据采集系统块可以表示图3 a，c，d和e中描述的那些拓扑结构。
如图3.g所示说明文件的空间分割。在这里，二进制数据通道形式将两个或更多DCS写入单独的文件。这些文件可能被不同的计算机系统写入。在这种情况下，标准支持可能存在的系统间的非零偏移。由于数据采集时并不清楚，因此它代表在SDR数据处理的初始通过之后可能被注释到元数据文件中的样本元数据参数。
多通道数据采集系统是将每个通道采集数据写入相互单独的文件中，也可以根据图3.f所示按照时间对文件进行分割。我们将此称之为“空时分割”，如图3.h所示。
由于多流多文件数据采集拓扑（如图3.g和图3.h所示）产生；饿适用于固定时间间隔的多数据文件，SDR处理器必须被“引入”与拓扑结构相关的全部通道或部分通道。这是由标准中通道选择参数进行覆盖。
元数据参数
元数据标准让用户能够指定二进制文件的广泛属性。其中一些属性与数据收集方案本身有关，例如时间、地点以及方案的类型。数据集的其它属性与特定RF数据相关通过中频采样被捕获。其它细节如中频数字化配置和数据打包。这些在下面简要地总结。参数中的一部分是自由形式的文本，整型、浮点型变量以及枚举。主要类型如图4所示。
元数据“会话”类型保存细节包括：时间、位置、度量活动以及场景类型。“文件”类型包括：相应二进制数据文件的路径、时间戳信息以及包括“通道”的引用(如下所述)。“系统”类型包括：数据记录设备细节，例如设备姓名，参考时钟频率和天线细节/规格。元数据标准允许规定各种RF频带，每个“频带”类型包括频带中心频率、中频频率、带宽和群延迟偏差的细节。
二进制数据的实际格式在“通道”类型，它允许指定二进制数据打包模式的层次结构，称之为“数据块”，“大数据块”以及“数据团”。这些类型指定了打包中频数据和可选的附加数据，例如：传感器测量或信息配置，并进一步排列指定相对于标准世界大小（字节，短整型，整型，长整型等）。这些数据块中的原始中频样本的排列由“流”类型。这个类型指定相关RF频带，采样率，量化，样本类型（实数/复数），样本的编码/对齐。这些类共同包含足够的信息可以清晰解释打包的二进制数据。
规范性参考软件
规范性参考实施分委员会的主要责任是减少通过工作组协商达成一致制定的概念设计，并根据行业最佳实践开发一个兼容软件库实施。工作组很幸运地接受了自愿参与这项任务的GNSS SDR供应商。
工作组决定在公开发布的参考软件库上开发该标准。这项工作的目标是促进标准的早期和广泛采用，使供应商和研究人员能够轻松的将标准库集成到现有软件中，从而实现标准兼容。这项工作的范围有两方面，一是开发元数据解释，二是用这个元数据解释开发二进制数据转换器。
第一个贡献是一个能从恰当原型数据结构产生的标准兼容元数据文件的库，这个库能够将这些文件内容读回数据结构。第二个贡献是以能够基于相关元数据描述的存储并转换为二进制中频拿数据。结合起来，希望这两个库提供充足的功能在SDR中采纳元数据标准，或作为针对被验证的标准实施的基准。
该软件是C++写的，并采用CMake管理。它能被分为两个库：“apilib”实现元数据的解释，而“Converterlib”实现二进制数据转换，并伴随着一系列的终端，包括数据转换应用和简单测试应用。该软件位于GitHub帐号上，链接如下：https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard.
元数据解释器库包括：读取器功能，能够存储元数据文件并填充相应元数据对象，然后通过选择成员函数来查询。类似，可以通过一系列成员函数被实例化并配置元数据对象，随后可以指示写入对应的元数据文件。
按照元数据文件，转换库可被用作二进制数据文件存储和数据解释。基本转换器可以适用于支持数据流转换的处理，且两个这样的适应已经被植入参考软件中。图5描述的第一个功能，其中数据转换器被嵌入文件转换器中。文件转换器使用元数据解释对象配置嵌入数据转换用，并且能够解析打包的二进制输入文件，并以用户指定的数据类型（int8，int16，float，double等）为每个IF数据流生成一个文件）。
如图6描述，第二个功能是通过将数据转换器嵌入“前端”来实现的。该前端提供了一种装载二进制数据文件的短部分并将其转换为用户指定的数据的方法在处理不同的流以不同的速率进行采样时，处理诸如样本对齐之类的细节时，输入（int8，int16，float，double等）。
该软件套件包括一系列示例二进制数据集和相关的元数据文件以及一个简单的MATLAB / Octave脚本，以便根据参考数据集测试构建。 迄今为止，存储库中已经包含了五种不同的文件格式，其中包括各种各样的前端配置和数据打包变化。
一部分工作组的成员自愿规范草案对SDR数据文件进行“盲测”。这涉及交换SDR数据文件和相关的元数据规范，并在各方之间核实、验证文件可以在没有附加信息的情况下被完全解码。 工作组成员参加。 参与此项活动的工作组成员将由合规验证分委员会组成。
SDR 数据存储库
与大多数标准和编程项目一样，通过很好的例子可以很好地理解它们。 因此，已经创建了页面：http://sdr.ion.org/api-sample-data.html，并包含多个二进制示例文件以及元数据文件。 所有的文件集都经过测试，符合标准，可以被规范的参考软件读取。 二进制文件通常包含超过60秒的持续时间的样本，并且通过至少一个软件接收机实现已经获得定位。
更多的例子将被增加，不仅强调新的数据记录系统，而且还描述不同的SDR应用如天线阵列，反射测量或离子闪烁分析。此外，仅在地球某些特点位置（例如准天顶卫星系统[QZSS]）看到的来自GNSS的数据的方式也正被考虑。
鼓励组织联系工作组，如果他们拥有目前在存储库中不充分代表的格式的文件或代表迄今尚未考虑的用例。网页上给出对应的联络点。工作组将对创建的文数据文件进行保存（若不可用时），校验并整理上传。
作者简历
James T. Curran received a B.E. inElectrical & Electronic Engineering in 2006 and a Ph.D. inTelecommunications in 2010 from the Department of Electrical Engineering,University College Cork, Ireland. He worked as a senior research engineer withthe PLAN Group in the University ofCalgary, Canada, from 2011 to 2013 and as a grant-holder at the Joint Research Center (JRC) of the European Commission (EC), Italy from2013. Curran is currently a radio-navigation engineer at the European Space Agency (ESA) in theNetherlands. His main research interests are signal processing, informationtheory, cryptography, and software defined radio for GNSS.
Markel Arizabaleta has a M.Sc. fromthe University of the Basque Country (UPV-EHU) in TelecommunicationEngineering. He studied the last year in Tampere University of Technology (TUT)where he worked on joint 5G mobile communication and positioning systems andjoined the Universität der Bundeswehr München in 2017 where he is involved insignal processing for satellite navigation systems.
ThomasPany is with the Universität der Bundeswehr München at the faculty of aerospaceengineering where he teaches satellite navigation. His research includes allaspects of navigation ranging from deep space navigation over new algorithmsand assembly code optimization. Currently he focuses on GNSS signal processingfor Galileo second generation, GNSS receiver design and GNSS/INS/LiDAR/camerafusion. To support these activities, Pany is developing a modular GNSS test bedfor advanced navigation research. Previously he worked for IFEN GmbH and IGASPIN GmbH and is the architect of the ipexSR and SX3 softwarereceiver. Pany has around 200 publications including patents and onemonography.
SanjeevGunawardena is a Research Assistant Professor ofElectrical Engineering with the Autonomy & Navigation Technology (ANT)Center at the Air Force Institute of Technology (AFIT). His researchinterests include RF design, digital systems design, high performancecomputing, software defined radio, and all aspects of GNSS receivers andassociated signal processing.