多源导航星历的统一化建模实现＊

2013-08-29陈正生

全球定位系统 2013年4期

陈正生，崔阳

（信息工程大学地理空间信息学院，河南郑州450052）

0 引言

多个卫星导航系统的相续建设和投入使用，为广大的导航定位用户带来了更多的选择，也为导航定位服务的提升带来了可能。由于不同的卫星导航系统在设计理念、轨道、频率等多方面存在着诸多差异，使得多个卫星导航系统的集成应用变得困难。目前多个系统的综合应用研究是一大热点[1－2]。对数据处理而言，卫星导航系统的差异主要体现在数据的异构性上。在统一数据交换格式方面，瑞士伯尔尼大学的天文学院提出的与接收机无关的交换格式（RINEX），并且在这方面做了大量的工作，已经成为导航卫星系统接收机数据格式的统一标准。RINEX整合了接收机的异同，但是无法屏蔽不同卫星导航系统的信号差异。其采取的办法是针对不同的系统设计不同的格式。为了屏蔽星历文件的差异，美国大地测量局（NGS）提出标准轨道格式，目前使用最广泛的是SP3。同时国际GPS服务（IGS）在其网站上将事后处理的精密星历数据以SP3文件格式发布。众多不同格式的星历数据源，为导航卫星星历的使用者带来了极大的不便，并且这些离散存储的导航星历通常并不能直接使用，还需要做进一步的解算。为方便多导航系统的集成研究和应用，有必要建立统一的导航星历数据源模型。

1 导航星历数据的异构性

导航卫星星历信息是GNSS数据解算的基本信息之一，包含导航卫星在某一时刻的位置、运行状态、卫星钟等信息。导航卫星星历的异构性主要体现在卫星导航系统星历信号的差异及其记录格式的差异。目前，比较著名的导航系统有GPS、GLONASS、GALILEO、COMPASS及一些区域增强系统（SBAS），由于这些系统涉及不同国家或地区、系统设计各异，并且花费巨大，要想统一其星历数据格式和内容是不太可能的。另外，由于导航卫星星历的发播机构和发播时间不同，其数据格式也存在着差异性，如GPS发播的是卫星轨道根数，而GLONASS则是卫星的瞬时位置，IGS数据服务中心定期发布导航卫星的精密星历是SP3文件格式。目前各机构的星历数据主要以单文件形式进行存储和发布。这些文件形式存储的星历数据在采用基准、记录格式、记录内容、采样率、发布时间、计算精度等方面都存在着差异，如表1所示。

除以上差异外，星历数据源还有以其它方式进行表达和存储的，如关系数据库、二进制数据文件等。这些数据源在表达和存储方式各有特点，可以满足不同阶段和层次的存储需求，但是从星历使用者角度来看，这些异构的星历数据源大大地加大了其使用难度，并且这些数据源通常还需要进行复杂的计算才能使用。如GPS广播星历参数包括基本开普勒轨道参数和一些摄动系数，用户必须由上述参数才可以计算卫星在地心地固坐标系中的位置[3－4]；精密星历则是以 SP3文件记录卫星每15 min的三维轨道坐标，用户必须进行适当的拟合或差值才能使用[5－6]。而一般用户并不在意这些底层的数据格式、存储类型，也不愿意去实现这些复杂的算法，而只在乎星历信息的本身，包含指定卫星的瞬时坐标和钟差，即星历服务与星历接口。

2 接口的设计与实现

2.1 星历服务接口设计

接口采用统一建模语言（UML）进行实现。首先设计服务类接口IEphemerisService和星历信息接口IEphemerisInfo，如图1所示。服务类对外提供星历服务，包含数据源和获取星历信息的方法。星历信息接口包含一颗卫星的GPS时刻，卫星坐标、速度、钟差、钟漂。其中卫星标识以PRN表示，包含了卫星导航系统和卫星编号。

图1 星历服务和星历信息接口

2.2 数据源接口设计

星历数据源接口为IEphemerisDataSource，与文件、数据库、网络三种数据源接口建立继承关系，分别为 IFileEphemerisDataSource、IDatabaseEphemerisDataSource和INetEphemerisDataSource.另外数据源有单源和多数据源之分，因此定义接口IEphemerisDataSourceCollection表示多源星历数据，并令其继承ICollection＜IEphemerisData－Source＞集合接口，同时该集合接口也是属于数据源，因此也继承自IEphemerisDataSource，其继承关系类图如图2所示。

图2 数据源接口设计

对于文件数据源以抽象类FileEphemeris－DataSource表示，其为IFileEphemerisDataSource接口的实现，封装了常用的文件相关属性和方法。GPS导航文件、GLONASS导航文件和SP3文件都属于文件类型，分别以 GlonassNavFile、GpsNavFile和SP3File命名，继承自抽象类FileEphemerisDataSource.多个文件组成的数据源FileEphemerisDataSourceCollectio，即实现文件数据源接口IFileEphemerisDataSource也实现集合接口IEphemerisDataSourceCollection，如图3所示。

图3 文件形式的星历数据源

2.3 接口的实现

定义好各种接口和类之后，就是类中具体方法和属性的实现了。不同格式的数据源之间的差异被封装在实体类中，而外部访问者只需通过接口调用。以RINEX表示的GPS导航文件为例，文件记录卫星在某历元下的轨道根数、原子钟、卫星状态信息等。GpsNavFile类在实现接口方法GetEphemerisInfo过程中，需要根据卫星编号和请求时刻寻找到相应的文件记录，然后将轨道根数计算为卫星位置；而SP3精密星历文件的实现SP3File类，只需要判断请求时间是否在该文件范围内，再进行拟合；对于多个数据源组成的集合类型，则需要判断时段有效性，直接调用子数据源就可以了。这些底层实现差异是相当大的，但是对于以接口访问的程序是透明的。同样，如果需要增加其它格式的数据源或自定义格式的数据源，只要实现该接口，在工厂方法中注册该类就可以了，不会影响系统的其它部分。

图4示出了创建文件数据源的工厂方法，采用C＃语言描述，其中 GetFileEphemerisType－FromPath方法的作用是通过文件名称，即最后一个字符，判断导航卫星星历文件的类型。

图4 文件数据源的创建

3 实例应用

3.1 应用1：同步操作多星历源

由于屏蔽了底层数据格式的差异，基于此模型的应用系统可以轻易实现多种格式的星历数据的同步操作，如卫星轨迹分析，可见度分析等。图5分别示出了三个不同卫星系统的导航卫星在同一时段的运行轨道图。

图5 不同系统卫星的运行轨迹

3.2 应用2：多源星历服务系统

基于Web的星历服务系统可以通过浏览器即时查询星历信息。图6示出了单颗卫星星历服务界面，用户只需要输入卫星编号PRN和GPS时间，就可以返回请求卫星在当前时刻的运行状态和钟差信息。而星历数据源的存储、更新、计算和整合等繁琐而复杂的工作，由后台完成。基于 Web的星历服务同时也实现了面向服务架构（SOA），用户可直接通过网络用程序绑定应用，从而进行更高层次的开发和应用。