基于安卓系统的北斗卫星通信与导航智能架构及其应用的制作方法

本发明涉及基于安卓系统的北斗卫星通信与导航智能架构及其应用。

背景技术：

全球卫星导航系统，简称RNSS系统，由用户终端接收卫星无线电导航信号，是一种无线电导航业务，自主完成距离测量，进行用户位置、速度及航行参数计算。目前，已经投入使用的GNSS系统主要包括美国GPS系统、俄罗斯的GLONASS系统、欧盟的伽利略系统以及我国自主建设的北斗卫星导航定位系统。

卫星无线电测定业务，简称RDSS系统。其主要特点是通过有源的方式进行定位，在完成定位的同时能够对外进行用户位置的报告，实现定位与短报文通信的集成。

北斗导航系统，是我国自主建立的一套集RDSS与RNSS于一体的定位导航通信系统。目前已处于推广和投入实用阶段，该系统由5颗静止轨道卫星，和30颗非静止轨道卫星组成，预计在2020年提供一个全球性的服务，它的研制成功标志着我国打破了美、俄在此领域的垄断地位。主要为我国本土及周边区域提供导航服务，可以24小时全天候服务，无通信盲区。北斗导航系统同时具备定位与双向通信能力，可以独立完成移动目标的定位与调度功能。

北斗导航卫星系统在地图测绘、移动电信、交通运输、农业、渔业、森林防火、勘探和国家安全等诸多领域逐步发挥重要作用。同时它也促进了诸如北斗卫星、北斗天线、北斗终端、北斗元器件等一大批北斗产业链的发展。

在传统的定位导航领域中，接收机的标准输出信息都遵循着NMEA0183数据传输标准协议。该协议是GPS导航设备统一的RTCM标准协议，由美国国家海洋电子协会(NMEA-The National Marine Electronics Association)制定的一套通讯协议。目前传统的GPS定位系统方案如图1所示，主要实现流程为：1、GPS初始化，主要为GPS模块上电，打开串口并设置波特率；2、启动新线程，不断读取串口上报的NMEA数据；3、通过校验码验证NMEA数据的有效性；4、通过判定语句类型，分发到不同的语句接卸分支；5、将解析后的结果通过设计好的接口上报到应用层。

中国自主研制的北斗卫星系统最终目标是形成全球覆盖的导航系统，为了与世界其他卫星导航领域接轨采用兼容NMEA0813的北斗用户数据接口协议。然而如果依旧采用传统的GPS解析方案，远远无法满足我国对北斗系统的使用需求。传统的方案仅能满足对于RNSS的定位需求，能够解析的协议语句有一定的局限性。北斗导航系统相对于GPS导航系统增加了RDSS功能，且对于RDSS与RNSS的整合，还需要设计一套成熟的安卓Apk以加以验证测试相关功能模块。

技术实现要素：

为了解决以上技术问题，本发明提供一种基于安卓系统的北斗卫星通信与导航智能架构及其应用，旨在提供一套不同于传统的Andorid GPS专为RDSS&RNSS服务的稳定架构，通过建立可靠的数据解析模型准确解析涵盖所有的RDSS/RNSS原语，最终使系统不仅具备RNSS的定位、导航、精确授时功能，还能兼具有RDSS的北斗通信功能，同时也能够对系统的定位模式、接收频段和相关选项进行配置。

本发明的基于安卓系统的北斗卫星通信与导航智能架构，包括：

安卓Service层：连接NIL-Java层，代表所有与北斗功能相关的上层应用，包括地图导航、实时定位、短报文通信和精确授时；

NIL-Java层：连接安卓Service层和NIL Daemon守护进程端，将安卓Service层发起的request请求通过socket转发给NIL Daemon守护进程，然后再把通过NIL Daemon守护进程端接收到的response返回给上层安卓Service引用，用于对各发起请求的应用进行权限控制；

NIL Daemon守护进程端：连接NIL-Java层和北斗基带，建立一个socket监听NIL-JAVA层发过来的request请求，将其转成符合NMEA协议的指令语句发送给北斗基带，同时将北斗基带上报过来的NMEA消息进行解析，然后将解析后的结果通过Socket传到上层安卓Service层；

北斗基带：连接NIL Daemon守护进程端，内部组成包括北斗天线、天线屏蔽罩、高性能RDSS收发芯片、加密芯片和RNSS接收芯片。

进一步的，所述NIL-Java层中定义命令的传递格式为Parcel，主要由三部分组成：命令号、令牌及内容；当NIL-Java层的指令转发给NIL Daemon守护进程时，会将指令转义成北斗基带能够识别的NMEA指令；指令的响应采用异步的方式，一些特殊指令存放在一组等待队列中，间隔一定时间后通过触发时钟中断通知处理器解析等待队列中的指令。

进一步的，所述NIL Daemon守护进程中的NMEA消息为基于NMEA专用的消息列队，并可通过消息循环对NMEA语句进行处理，NMEA消息主要指北斗基带通过串口输出符合NMEA协议的含有RNSS的定位信息或RDSS的短报文信息的语句。

进一步的，所述NMEA消息使用IO多路复用机制，具体为建立待读写的多路IO描述符列表，使用select函数，当多路IO描述符列表中的一个IO描述进行准备IO时，select函数返回具体可操作的IO描述符。

进一步的，所述NMEA语句使用数据表驱动方法，具体为建立描述各种NMEA消息格式的数据表，并对NMEA的每种字段信息加以阐释，在北斗基带启动时对数据表进行读取即可使用。

进一步的，所述NIL Daemon模块中包括model_map映射表，所述model_map映射表中包含若干北斗基带专有识别指令。

进一步的，基于安卓系统的北斗卫星通信与导航智能架构的应用，应用于北斗卫星方位显示、北斗定位导航、位置报告和RDSS短报文通信功能，同时通过配置模块的定位模式，向北斗基带发送指令使其能够在不同频段进行切换，同时对相关技术要求的各项性能指标做测试验证。

卫星方位显示：RDSS&RNSS支持GPS和BDS的单系统定位和双系统联合定位，因此需要能够同时显示GPS卫星和北斗卫星的方位及卫星相关参数信息。当定位成功时，北斗基带将上报可视卫星状态消息语句GSA，通过相应的解析执行器，能够获取所有卫星的PRN号、卫星方位角、卫星仰角、信噪比信息，同时根据方位角及仰角结合数学公式计算出准确的方位信息显示到界面上。

在定位系统中，因卫星的空间分布造成的测距误差DOP(Dilution of Precision，精度衰减因子)由一组值来描述，为了准确描述定位精短计算的准确度，需要同时获取精度因子和有效卫星GSA语句，由此获取及显示语句报告的导航解算中用到的卫星以及精度因子PDOP、HDOP、VDOP、TDOP。

位置信息显示：位置信息需要能够描述当位置定位成功后获取到的时间、经纬度、准确度、海拔、速度、方向角及其他基本信息。其中关键信息语句主要为大地坐标定位信息GLL，主要信息字段如表1所示：

表1

RDSS相关信息显示：RDSS是一种有源定位系统，利用这种有源系统北斗一代也实现了短报文通信，这是其他国家所不具备的。在使用RDSS的短报文功能时，需要通过波束状态信息BSI跟踪捕获波束的状态，只有在成功捕获北斗GEO卫星所发射的波速，才能进入以下步操作，否则，通信将失败；接着需要对北斗IC卡进行检测，通过向北斗基带发送ICA查询指令，查询模块信息及IC卡信息，成功后北斗基带将返回本机信息ICI语句，主要包含有：用户通信地址、序列号、通播地址、用户特征值、服务频度、通信等级、加密标志、下属用户数；最后，通过TXR通信语句，向北斗发起通信请求。

其他功能：为了能够跟踪数据的准确性，需要实时查看北斗基带上报的原始语句，通过注册NMEA监听事件，即可实时接收到NMEA消息来进行人为分析，同时也需要配置模块的定位模式，通过向北斗基带发送MSS语句指令，可以让北斗设备在测试模式和工作模式下进行切换。当处于测试模式下时，对应的测试项目有：误码率、定位、冷启动、温启动、热启动、测距、定时、重捕、位置报告，当处于工作摸下，可配置不同定位方式：BDS RNSS单频定位、BDS RNSS双频定位、BDS RDSS定位、GPS定位、兼容定位。

本申请着重解决基于安卓系统中在不同的定位模式下(BDS RNSS单频定位；BDS RNSS双频定位；BDS RDSS定位；GPS定位；兼容定位)，能够有效的对RNSS&RDSS原语数据进行准确地解析，并且实现了一套RDSS&RNSS一体化应用满足各模块功能测试需求。本申请主要针对北斗一代、北斗二代和GPS结合的导航系统设计了一套NIL(NMEA Interface Layer)架构模型，从软件角度来看，NIL工作在PPP，TCP/IP协议之下，负责数据的可靠传输、北斗基带指令的发送及NMEA语句的智能解析。而且，除了能够支持定位服务，NIL也能够满足RDSS业务相关的短报文通信及位置报告等功能。

本发明的基于安卓系统的北斗卫星通信与导航智能架构及其应用具有的有益效果有：

1、实现了基于安卓手机终端的一套与北斗卫星通信与导航的架构，该架构贯通安卓Framework、JNI、HAL及驱动层，提高了系统与北斗卫星通信的安全性、健壮性及稳定性；可通过自主设计的NIL架构方案，或在原有的安卓GPS框架上加以修改的方式进行内容调整与改进；

2、通过表驱动方法解析北斗NMEA协议语句，传统NMEA解析方案只大多针对GPS且解析的语句有限，而本申请的解析方案加入了对RDSS原语的解析，表驱动方法使能够解析的语句多样化，同时方便后续的维护。

附图说明

图1为目前传统的GPS定位系统方案示意图；

图2为本发明基于安卓系统的北斗卫星通信与导航智能架构的整体设计架构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

由图2所示，本实施例的基于安卓系统的北斗卫星通信与导航智能架构，包括：

安卓Service层：连接NIL-Java层，代表所有与北斗功能相关的上层应用，包括地图导航、实时定位、短报文通信和精确授时；

NIL-Java层：连接安卓Service层和NIL Daemon守护进程端，将安卓Service层发起的request请求通过socket转发给NIL Daemon守护进程，然后再把通过NIL Daemon守护进程端接收到的response返回给上层安卓Service引用，用于对各发起请求的应用进行权限控制；

NIL Daemon守护进程端：连接NIL-Java层和北斗基带，建立一个socket监听NIL-JAVA层发过来的request请求，将其转成符合NMEA协议的指令语句发送给北斗基带，同时将北斗基带上报过来的NMEA消息进行解析，然后将解析后的结果通过Socket传到上层安卓Service层；

北斗基带：连接NIL Daemon守护进程端，内部组成包括北斗天线、天线屏蔽罩、高性能RDSS收发芯片、加密芯片和RNSS接收芯片。

基于RDSS&RNSS的系统交互层-NIL。由于传统的GPS方案只适用于RNSS，且目前还未有成熟的GPS方案能够同时支持RDSS与RNSS结合的系统，因此本申请设计了一套NIL(NMEA Interface Layer)方案。NIL是基于NMEA协议实现的一种通信接口层，提供了安卓导航服务与北斗基带之间的抽象层。由于安卓手持终端往往会集成不同的北斗厂商的模块，而相应的提供商在对外开放接口的设计上也会有所不同，各种模块的初始化或相关配置可能都不一样，为了消除这些差异性对NIL做抽象，使其能够兼容市面上主流的北斗模块。RDSS&RNSS功能应用在实现过程中，要求下层的支配环境有统一描述，而这个描述就是靠NIL来适配完成的。

其中，NIL-Java层中定义命令的传递格式为Parcel，主要由三部分组成：命令号、令牌及内容；当NIL-Java层的指令转发到NIL Daemon守护进程时，会将指令转义成北斗基带能够识别的NMEA指令；指令的响应采用异步的方式，一些特殊指令存放在一组等待队列中，间隔一定时间后通过触发时钟中断通知处理器解析等待队列中的指令。

在NIL-java中定义命令的传递格式为Parcel，主要由三部分组成：命令号、令牌及内容。当NIL-JAVA的指令转发到NILD时，会将指令转义成北斗基带能够识别的NMEA指令。由于北斗基带的一些特殊限制如通信指令规定两条发送指令间隔不能小于60秒，因此指令的响应采用异步的方式。一些特殊指令将会存放在一组等待队列中，然后间隔一定时间后会触发时钟中断通知处理器解析等待队列中的指令。

NIL Daemon守护进程中的NMEA消息为基于NMEA专用的消息列队，并可通过消息循环对NMEA语句进行处理，NMEA消息主要指北斗基带通过串口输出符合NMEA协议的含有RNSS的定位信息或RDSS的短报文信息的语句。

整个NIL层的实现基本都是靠NMEA消息驱动的。NIL会建立一个NMEA专用的消息队列，并通过消息循环对NMEA语句进行处理。NMEA消息：主要指北斗基带通过串口输出符合NMEA协议的语句，通常含有RNSS的定位信息或RDSS的短报文信息。一般格式为：$IDsss，d1，d2，......，dn*hh<CR><LF>，参数语句的类型标识(IDsss)由两部分组成。前两个字符(ID)为语句标识符，后3个字符(sss)为语句格式符。类型标识符字段之后为数据体，由若干数据字段(d1，d2，......，dn)组成。

NMEA消息类型在整合RDSS&RNSS功能后需要解析的语句也有所增加，在处理NMEA消息指令过程中，采用CommandModel模式对NMEA消息进行粒度分解，解析成可代码能够鉴别的格式，然后分发给对应的指令执行器。基于服务容器的依赖注入，可以针对每个NMEA消息指令执行前和执行后进行拦截处理。

NMEA消息使用IO多路复用机制，具体为建立待读写的多路IO描述符列表，使用select函数，当多路IO描述符列表中的一个IO描述进行准备IO时，select函数返回具体可操作的IO描述符。

在NIL数据传递过程中，往往需要同时对多个IO同时进行读写操作，为了达到多路输入并且不阻塞的目的，使用了IO多路复用的机制。首先构造一张需要进行读写的IO描述符的列表，然后待用select函数，当IO描述符列表中的一个IO描述符进行准备IO时，该函数会返回具体可操作的IO描述符。

NMEA语句使用数据表驱动方法，具体为建立描述各种NMEA消息格式的数据表，并对NMEA的每种字段信息加以阐释，系统启动时对数据表进行读取即可使用。

传统的GPS方案只关心定位导航的相关NMEA消息语句，能够解析的NMEA语句也只限于位置信息GGA、大地坐标位置信息GLL、设置初始化信息GLS、精度因子和有效卫星号GSA等几条位置信息语句。通常RNSS&RDSS系统应用场景多种多样，需要解析的NMEA语句也达到几十条不同的消息，这些消息通常含有位置、卫星、时钟等信息。

每一条NMEA消息包含有若干字段，并且每条消息都有一个地址段，其中有一个语句标示符用于定义传输数据的格式和类型，而且这些消息的格式并不是固定不变的，其所含有的字段的类型及数量都会根据地址段的标示符而有所不同。以下简单列举两种不同的语句格式：

AAM：双向语句，航路点到达报警。

格式：$--AAM，A，Ax.x，u，c--c*hh<CR><LF>。详细说明见表2：

表2

BSS：输入语句，设置用户设备的响应波束和时差波束。

格式：$--BSS，xx，xx*hh<CR><LF>。详细说明见表3：

表3

如果采用基于逻辑的方法，需要读取每一条消息，检查它的标示符，然后调用一个用来解析、处理的子程序。如果以后需要扩展的话还需要添加分支进行处理。为了使整个程序的程序易于扩展、维护，本申请采用表驱动方法来进行NMEA消息处理。

本申请采用了表驱动方法后，可以用一张表来描述各种NMEA消息的格式，而不用再把它们硬编码进程序逻辑里。并且在后期维护过程中，只需对表进行升级维护而不用修改代码。

为了使用该方法，先列出消息种类和字段类型，按照下面的方法来定义所有可能的字段类型：

根据上面标示对NMEA的每种字段信息加以阐释，以北斗通信短报文信息TXR为例，下面例子阐释了一种消息描述的方法：

上面这张表将存储在本地文件中，当RILD启动后会从文件中加载表信息。当把信息定义读入程序后，就能把所有的信息嵌入在数据里面，而不必嵌入在程序逻辑里面。数据要比逻辑更灵活，当需要增加一种新的NMEA指令时，只需往数据表里再增加一项元素即可。下面是表驱动法中最上层所采用的伪代码：

NIL Daemon守护进程中包括model_map映射表，所述model_map映射表中包含若干北斗基带专有识别指令。

尽管对于北斗卫星系统，有一套北斗卫星导航系统用户终端通用数据接口协议，然而由于目前北斗的技术发展还不够成熟，导致各个厂商在各自的北斗基带接口设计存在一定的差异性，如定位模式的切换、模块信息的读取。而各厂商提供的接口实现方案往往只针对自家北斗基带，当使用其他厂商的模块后会产生许多不可预知的问题。终端往往会使用不同的北斗基带，这就要求RDSS&RNSS的架构系统能够具备兼容性，因此本申请设计一套能够自适应兼容不同模块的方案，对市面上的主流北斗基带都能做到完美支持。

通过对比各个北斗模块厂商的指令差异，会发现每种模块都有着专门的模块版本读取指令。因此，通过这些差异性指令建立一张映射表model_map，model_map主要包含北斗基带厂商标示符model_tag、模块版本信息读取指令model_command_version、对应的返回信息model_version_info，及其他专有指令。如果需要增加需要识别的北斗基带，只需往model_map增加相关字段即可适配。

当启动定位服务时，本地RILD守护进程将会启动。在RILD初始化完串口及北斗基带后，将会读取我们已建立好的model_map的model_command_version和model_version_info字段，通过遍历所有的model_command_version，依次向模块发出该指令，然后等待返回，当北斗基带有返回版本信息时判断相应的model_tag，即可确认模块厂商，后续即可通过model_tag来提取相应的专有指令来与北斗基带进行通信。

基于安卓系统的北斗卫星通信与导航智能架构的一体化应用，应用于卫星方位显示、位置信息显示和RDSS相关信息显示，同时通过配置模块的定位模式，向北斗基带发送指令使其在测试模式和工作模式中进行切换。

本实施例的基于安卓系统的北斗卫星通信与导航智能架构及其应用具有的有益效果有：

1、实现了基于安卓手机终端的一套与北斗卫星通信与导航的架构，该架构贯通安卓Framework、JNI、HAL及驱动层，提高了系统与北斗卫星通信的安全性、健壮性及稳定性；可通过自主设计的NIL架构方案，或在原有的安卓GPS框架上加以修改的方式进行内容调整与改进；

2、通过表驱动方法解析北斗NMEA协议语句，传统NMEA解析方案只大多针对GPS且解析的语句有限，而本申请的解析方案加入了对RDSS原语的解析，表驱动方法使能够解析的语句多样化，同时方便后续的维护。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。