一种近海通用航海实时监视及控制系统

技术领域

本发明涉及海上交通服务技术领域，具体涉及一种近海通用航海实时监视及控制系统。

背景技术

全球海上過险与安全系统(Global Maritime Distress and Safety System，GMDSS)是国际海事组织(International Maritime Organization，IMO)于1988年推行建立的一种海上遇险和安全无线电系统。GMDSS由卫星通信系统、地面无线电通信系统(即海岸电台)以及海上安全信息播发系统构成。其中，卫星通信系统又包括海事卫星通信系统(INMARSAT)及低极轨道卫星搜救系统(COSPAS/SARSAT)。GMDSS以岸基为基础，主要用于并播发海上安全信息(如航行警告、气象警告等)，提供紧急和安全通信，以援助和协调遇险搜救任务。

INMARSAT系统将移动通信从地面网延伸至地面系统无法覆盖的偏远地区，在抢险搜救、应急通信等领域的作用不可或缺，因此在我国得到广泛应用。同时，我国作为国际搜救卫星组织(International Satellite System for Search and Rescue)成员国，几十年来着力提高我国海上和陆地的遇险报警能力，使我国遇险搜救手段达到了较为先进的现代化水平。

近年来，我国卫星导航业务及海上移动通信业务迅速发展，海南、广东、上海等多地航道水域已实现99%以上移动信号无缝覆盖。秦皇岛、连云港、舟山、汕尾、珠海等多地港口及沿线海域实现了移动信号全面覆盖。2022年1月，印发了《关于大众消费领域北斗推广应用的若干意见》，鼓励我国企业加大对北斗导航系统的利用率。2022年9月，百度地图智能定位开放服务升级为北斗定位开放平台。百度地图率先正式切换为北斗优先定位，北斗卫星的日定位量首次突破1000亿次。

我国近海海域及航道移动覆盖率的提高以及北斗导航系统服务水平的提高，为多监视源的实时控制、动态航路搜索、高效电子航图等智能应用场景的实现提供了坚实的基础。相较而言，GMDSS主要用于遇险和安全通信系统，虽然也能够用于船舶的常规通信业务，但不便于服务的个性化定制和扩展。加之，海上航行器接入GMDSS需要建立船站，与岸站的通信依赖于多种专业设备，部署的便捷性较差，不适用于中小型航行器的便携式接入。

发明内容

器便携式接入的近海通用航海实时监视及控制系统，以解决现有系统个性化定制能力差，在多监视源上的协同控制能力差等问题。

本方案中的近海通用航海实时监视及控制系统，包括航行器子系统和控制端子系统，所述航行器子系统设有客户端程序，所述控制端子系统设有服务端程序；

所述航行器子系统包括客户端模组、移动通信模块、北斗短报文模块和导航模块，用于向控制端子系统发送数据及接收控制端子系统的配置和控制指令，所述移动通信模块信号连接客户端模组，所述北斗短报文模块信号连接客户端模组，所述导航模块信号连接客户端模组；

所述控制端子系统包括控制服务器、北斗指挥机和用户终端，用于接收航行器子系统传回的数据及向航行器子系统发送配置和控制指令，所述北斗指挥机信号连接控制服务器，所述用户终端信号连接控制服务器；

所述客户端程序运行在客户端模组的嵌入式操作系统上，实现航行器子系统的导航功能、与服务端程序通信的移动通信及短报文通信功能，同时实现航行器子系统的指令执行功能以及航行器子系统上的数据缓存功能；

所述服务端程序运行在控制服务器的微机操作系统上，实现北斗指挥机的控制功能、与客户端程序通信的移动通信及短报文功能、向航行器子系统发送指令的功能以及客户端程序的零接触配置功能。

进一步，所述移动通信模块、北斗短报文模块、导航模块以可插拔方式，分别通过数据线连接到客户端模组，或者所述移动通信模块、北斗短报文模块、导航模块分别通过集成电路与客户端模组集成，所述北斗指挥机及用户终端分别通过网线或数据线连接到控制服务器。各个模块通过标准通用接口进行连接，各模块可独立更换或升级，系统具有较强的可扩展性。

进一步，所述移动通信模块使用4G网络通信方式，与控制端子系统通信，并至少支持TCP、UDP、FTP和HTTP协议中一种。有益效果是：移动通信模块支持多种协议中的一种，以便对部署在所述系统上的具体应用进行优化。

进一步，所述北斗短报文模块同时支持RDSS和RNSS功能，所述北斗短报文模块通过卫星通信方式与控制端子系统通信。有益效果是：短报文功能是我国北斗导航系统相较于国外GPS等系统的特色功能，使所述系统具备更强的应急通信能力。

进一步，所述导航模块与北斗短报文模块相互独立，所述导航模块支持RNSS、GPS、Galileo、GLONASS导航系统中的至少两个。有益效果是：导航模块独立，能够在某种导航系统失效时快速切换至另一导航系统，可靠性更高。

进一步，所述客户端程序是所述嵌入式操作系统上的一个应用程序，所述客户端程序运行时的支撑工具包括：交叉编译工具、系统固化工具、拨号上网工具、终端调试工具、虚拟机、集成开发环境及驱动程序，所述客户端程序的移动通信功能基于Socket技术实现。有益效果是：嵌入式操作系统作为嵌入式设备及客户端程序的中间层，封装了嵌入式设备的可变部分，使嵌入式设备及客户端程序能够各自相对独立的升级，具有更强的可扩展性，具备部署和运行智能应用的能力。

进一步，北斗短报文及导航功能基于串口技术实现，串口通信的数据协议遵循NMEA标准，数据收发缓存功能基于数据库技术及多线程技术实现，数据的生产者和消费者分别在单独的线程中实现，具体步骤如下：

S1，生产者线程收集移动通信模块、北斗短报文模块和导航模块产生的4G通信数据、北斗短报文和导航数据，存储至数据缓冲池；

S2，缓存收发数据的数据库连接使用单例模式，全局仅打开一个数据库连接，并维护一个整型变量记录已打开的数据库终端数量，仅当终端数量减少到零时关闭数据库连接。缓存收发数据的数据库支持多线程安全的数据读，使用互斥信号量支持多线程安全的数据写；

S3，消费者线程从数据缓冲池获取数据，并通过4G通信或北斗短报文通信，发送到控制端系统的控制服务器。有益效果是：基于数据库技术实现数据收发同步，保证了数据读写的正确性和效率。数据收发缓存解决了通信状态不佳时传感数据的暂存问题，统一了不同传感数据的传输格式，支持对传输数据的个性化定制。

进一步，北斗指挥机的控制功能及短报文通信功能通过编程接口调用技术实现；多客户端模组管理通过多线程技术实现，客户端模组通过全局唯一的ID标志自身，标识具体步骤如下：

S21，客户端模组首次与控制服务器建立连接后，将自身ID发送给控制服务器；

S22，控制服务器为建立的连接创建一个线程，将客户端ID、线程ID与连接句柄三者绑定，放入线程池；

S23，在客户端模组掉线重连时，服务器根据客户端ID复用已有线程。有益效果是：连接句柄与客户端ID绑定，可以避免在后续通信过程中重复发送ID；客户端掉线重连时，可以根据客户端ID复用线程池中的线程，降低销毁及创建线程的系统资源开销。

客户端程序作为客户端，服务端程序作为服务器，两者构成客户端/服务器架构。

本发明综合利用北斗短报文通信及移动通信技术，集成了移动通信模块、北斗RDSS模块、北斗RNSS模块以及独立的RNSS模块，并支持GPS、Galileo或GLONASS导航系统中的至少两个，导航系统的可用性较高，具有对多监视源进行协同控制的能力；并且软件系统采用配置项对监控方式进行管理，支持自定义监视数据的内容和格式，支持自定义的控制指令，能够为多个客户端中的每一个使用不同的配置项，同时支持配置项的即时更新；进一步，各硬件模块通过标准接口与主设备相连，可单独替换或升级，可扩展性强，软件系统建立在嵌入式操作系统和微机操作系统之上，操作系统本身及软件系统均易于升级，系统的功能及性能随系统软硬件设施的演化而增强；更进一步地，客户端接入便捷，用户只需提供北斗卡及普通移动通信SIM卡，并将模组安装在航行器上即可完成接入准备，控制端系统部署便捷，只需接入互联网即可完成部署准备，卫星通信通过北斗指挥机完成，无需部署基站或中继站。

附图说明

图1为实施例中近海通用航海实时监视及控制系统的原理框图；

图2为实施例中近海通用航海实时监视及控制系统各系统模块及其连接示意图；

图3为实施例中近海通用航海实时监视及控制系统中北斗短报文模块的通信模型图；

图4为本发明实施例中近海通用航海实时监视及控制系统中北斗模块的流程图；

图5为本发明实施例中近海通用航海实时监视及控制系统中导航模块的流程图；

图6为本发明实施例中近海通用航海实时监视及控制系统中SerialPort类的类图；

图7为本发明实施例中近海通用航海实时监视及控制系统中CmdParser类的类图；

图8为本发明实施例中近海通用航海实时监视及控制系统中CmdParser类的依赖关系；

图9为本发明实施例中近海通用航海实时监视及控制系统中CmdBuilder类的类图；

图10为实施例中近海通用航海实时监视及控制系统中CmdBuilder类的依赖关系；

图11为本发明实施例中近海通用航海实时监视及控制系统中数据库工具类的类图；

图12为近海通用航海实时监视及控制系统客户端程序进行数据收发同步的示意图；

图13为近海通用航海实时监视及控制系统中各控制端子系统模块及其连接示意图；

图14为近海通用航海实时监视及控制系统中处理WebSocket请求的相关类示意图；

图15为本发明实施例中近海通用航海实时监视及控制系统中M2000类的类图；

图16为近海通用航海实时监视及控制系统中M2000类的对象执行指令的序列图；

图17为近海通用航海实时监视及控制系统中指令解析相关的类的示意图；

图18为本发明实施例中近海通用航海实时监视及控制系统中WebSocketServer的类图；

图19为实施例中近海通用航海实时监视及控制系统中WSHandler及其子类示意图；

图20为近海通用航海实时监视及控制系统中传输配置类TransConfig示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。下面通过具体实施方式进一步详细说明。实施例如下：

如图1所示，近海通用航海实时监视及控制系统，包括：硬件系统和软件系统，硬件系统包括航行器子系统和控制端子系统，软件系统包括客户端程序及服务端程序。

1 航行器子系统的选型

如图2所示，图2中各标号说明如下：(1.1)客户端模组：(1.1a)客户端模组的核心板、(1.1b)客户端模组的底板、(A)客户端模组的直流电源接口、(1-3)客户端模组上与1.3连接的USB接口、(1-4)客户端模组上与1.4连接的USB接口；

(1.2)移动通信模块：(E)1.2的天线接口；(1.3)北斗短报文模块：(B)1.3的直流电源接口、(C)1.3的天线接口、(1.4)定位模块：(D)1.4的天线接口。

1.1客户端模组

客户端模组是机载嵌入式操作系统的宿主，与其他航行器子系统连接并控制连接到客户端模组上的航行器子系统。在图2示出的实施例中，12V/1.0A直流电源(A)与客户端模组(1.1)上的A口连接，为1.1供电。

在该实施例中，1.1使用正点原子出品的I.MX6U-ALPHA开发板。I.MX6U-ALPHA以恩智浦半导体公司(NXP)的I.MX6ULL为核心，是一种基于Cortex-A7平台的全功能开发板。

1.1又包括：(1.1a)核心板；(1.1b)底板。核心板插入底板上的接口，与底板组装在一起。在图2示出的实施例中，核心板和底板已经组装在一起。

根据存储芯片的类型，正点原子的I.MX6ULL核心板分为EMMC和NAND两种。所述实施例采用EMMC核心板。I.MX6ULL EMMC版核心板板载资源包括：800MHz CPU(MCIMX6Y2CVM08AB)；512MB DDR3L(NT5CC256M16EP-EK)；8GB EMMC芯片(KLM8G1GET)；两个2*30的防反插BTB 座，共引出120 PIN。

所示实施例采用的I.MX6ULL核心板具有如下特点：

(1)体积小巧，仅46mm*36mm，应用范围广泛；

(2)使用120P BTB连接座，便于集成到客户PCB，更换简单，维修测试便捷；

(3)资源丰富，存储器可选，适应性强；

(4)采用6层板设计，单独地层、电源层，且关键信号采用等长线走线，性能稳定；

(5)底部放有详细丝印，按功能分区引出IO口，安装布线便捷。

所述实施例的I.MX6U-ALPHA底板板载资源包括：六轴陀螺仪/加速度传感器芯片(ICM20608)；高性能音频编解码芯片(WM8960)；CAN接口(TJA1050)；485接口(SP3485)；RS232串口(母)接口(SP3232)；ATK模块接口，支持正点原子蓝牙/GPS/MPU6050/手势识别等模块；光环境传感器(光照、距离、红外三合一)；摄像头模块接口；OLED模块接口；USB串口，可用于代码调试；USB SLAVE(OTG)接口，用于USB从机通信；USB HOST(OTG)接口，用于USB主机通信；RS232/RS485选择接口；串口选择接口；TF卡接口；2个10M/100M 以太网接口(RJ45)；直流电源输入接口(输入电压范围：DC6~18V)；启动模式选择配置接口；RTC后备电池座，并带电池；Mini PCIE移动模块接口；Nano SIM卡接口；SDIO WIFI 接口等。

I.MX6U-ALPHA底板具有如下特点：

(1)接口丰富，多达十种以上，支持的开发场景丰富；

(2)采用核心板+转接板+底板的设计形式，板载资源可灵活配置，便于扩展；

(3)板载资源丰富，可满足多种应用需求；

(4)接口位置设计合理，各接口均使用丝印标注，使用便利。

在本申请的一些实施例中，在客户端模组的产品成型阶段，可对图2所述实施例的底板进行裁剪，仅保留必要的模块及板载资源，定制PCB与其他板载设备集成，并封装为可独立运行的航行器子系统。

1.2移动通信模块

移动通信模块基于移动通信技术与控制端子系统进行双向通信。在图2所示的本申请的一个实施例中，移动通信模块采用深圳高新兴物联出品的ME3630移动LTE模块和一块联通Nano SIM卡，基于移动技术进行通信。如图2所示，ME3630(1.2)插入I.MX6U-ALPHA底板(1.1b)的Mini-PCIE插槽，同时Nano SIM卡插入1.1的SIM卡槽(在ME3630模块下方)。1.2的天线接口(E)为IPEX座，与天线(E)连接。

如图2所示的I.MX6U-ALPHA底板(1.1b)的移动通信模块接口为Mini-PCIE形式，但内部通信接口实际为USB，因此移动模块的驱动使用USB驱动。

ME3630是一款LTE Cat.4七模全网通移动模块，目前广泛应用于车载通信、工业路由器、安防信息采集等M2M领域。ME3630具有如下特性：(1)支持双天线以提高通信质量和通信可靠性；(2)在LTE模式下，上行速率达50Mbps，下行速率达150Mbps；(3)内置TCP、UDP、FTP和HTTP等协议；(4)支持PAP、CHAP、PPP等多种网络协议；(5)拥有GNSS、Remote wakeup、SMS等多种功能，支持FoTA空中升级；(6)支持RAS、ECM、NDIS；(7)支持AT指令。由移动通信模块的选型可见，用户接入所述系统仅需提供普通移动通信SIM卡，即可完成接入准备。

1.3北斗短报文模块

北斗短报文模块基于短报文通信技术向地面发送数据。在图2所示的本申请的一个实施例中，北斗短报文模块采用海聊T2开发板。如图2所示，一块2200mAh容量的12V可充电锂电池(B)连接到T2开发板(1.3)的B接口，为T2开发板提供电源；天线(C)连接到1.3的C口。

T2开发板通过RS232转USB数据线连接到客户端模组1.1的USB接口(1-3)，使用PL2303驱动程序。

所述实施例的T2开发板具有如下特性：(1)低耗电，2200mAh足够T2开发板使用15小时以上；(2)功能强大，在功能和外形上向前兼容，增加了可编程的单片机STM32F105RCT6以及DC-DC同步整流降压芯片TPS54527；(3)集成了RDSS和RNSS模块；(4)引出了单片机STM32F105RCT6的USART3、SPI、AD4、AD5、GND、3V3等引脚，可扩展性强；(5)使用7V-18V供电，内部有TVS防护，稳定性好；(6)J12排针接口用于单片机的BOOT选择，J3 和J10排针接口用于选择RDSS模块的数据输出，可配置性强。

1.4导航模块

导航模块基于卫星无线电导航技术为航行器子系统提供导航服务。除北斗短报文模块的RNSS服务外，本申请集成了独立的RNSS模块。在图2所示的本申请的一个实施例中，导航模块使用U-BOX公司的UBX-M8030芯片(JS-U810模组)。如图2所示，JS-U810模块(1.4)通过D口与天线D连接，同时通过USB接口连接到1.1的USB接口(1-4)。JS-U810使用CH340驱动程序。

所示实施例的JS-U810模块具有如下优点：

(1)可并发使用多达三个GNSS(GPS、Galileo、GLONASS或北斗)；(2)导航灵敏度高(-167dBm)、定位精度；(3)电流消耗低；(4)支持所有的卫星增强系统；(5)工作温度范围广(-40°至+105°C)。

由上文可知，移动通信模块、北斗短报文模块及导航模块均通过串口与客户端模组进行连接，各模块及客户端模组均可独立升级。由于客户端程序使用串口通信技术控制各模块，各模块及客户端模组升级后，客户端程序只需少量改动或无需改动。客户端模组还能够复用已有的客户端程序，以较少的代价扩展新的模块，实现新的功能。

所述航行器端模组及各模块封装后的实际尺寸不足100*70*40mm，使用电池供电，能够作为独立的模块便携的部署在航行器上。

2客户端程序的实现

客户端程序运行在客户端模组的嵌入式操作系统之上，实现航行器子系统的导航功能、与服务端程序通信的移动通信及短报文通信功能，同时实现航行器子系统的指令执行功能以及航行器子系统上的数据缓存功能。在航行器子系统选型的基础上，客户端程序的实现流程如下：

(1)原型搭建：连接各硬件模块，为软件系统提供运行的基础；

(2)嵌入式开发：在嵌入式操作系统上开发客户端程序，使能各功能模块；

(3)电路裁剪：裁剪开发板电路，将各模块集成为满足封装要求的电路模块；

(4)模组封装：使用定制的外壳封装裁剪后的电路模块，满足尺寸、防尘、防水等要求。

客户端程序实现航行器子系统的导航功能、与服务端程序通信的移动通信及短报文通信功能，同时实现航行器子系统的指令执行功能以及航行器子系统上的数据缓存功能。

为了使客户端程序更易于维护和扩展，在本申请的一个实施例中，采用面向对象的方式实现，开发语言选用C++。为了实现北斗短报文模块、导航模块及移动通信模块的功能，主要涉及的开发技术包括串口编程、数据库编程、多线程、线程同步及Socket编程等。

2.1嵌入式操作系统

在本申请的一个实施例中，嵌入式操作系统使用Linux 4.1.15。

在本申请的如图2所示的实施例中，客户端模组使用正点原子出品的I.MX6U-ALPHA开发板。其核心(I.MX6ULL)是一种基于Cortex-A7平台的ARM开发板。与此对应，所述Linux系统在编译时的Multiple platform selection选项选择ARMv7 based platforms。(编译工具支持参见下文)

在所述实施例中，客户端程序是Linux 4.1.15操作系统上的一个应用程序，并在该系统上运行。

2.2支持工具

在上述实施例中，为了开发客户端程序，需要一系列软件工具的支持，包括：交叉编译工具、系统固化工具、拨号上网工具、终端调试工具、虚拟机、集成开发环境以及驱动程序。

交叉编译是指在一种平台上(例如Ubuntu)编译应用程序的源码，使其能在另一种平台上(例如ARM Linux)运行。采用交叉编译的方式开发ARM Linux上的应用，主要原因是ARM Linux系统本身的限制。例如，ARM Linux本身在固化到ARM上之前也需要编译、ARMLinux不能安装所需的编译器等。在本申请的一个实施例中，交叉编译工具选择Linaro forARM Linux gnueabihf 5.4.1。所述Linux 4.1.15及客户端程序，均使用该交叉编译器编译。

系统固化是指将编译后的Linux安装到目标平台的存储芯片上。在前述实施例中，目标平台是Cortex-A7，存储芯片类型为EMMC。在本申请的一个实施例中，固化工具使用正点原子提供的mfgtool，将Linux固化到EMMC芯片上。启动EMMC上的Linux系统时，将I.MX6U-ALPHA开发板的BOOT开关调节为从EMMC启动，再闭合电源开关。

在图2所示的实施例中，4G模块使用ME3630，ME3630支持通过PPP方式拨号上网。在本申请的一个实施例中，使用PPP方式拨号上网。为了使用PPP，首先需要在编译ARM Linux时配置内核的PPP功能，然后在ARM Linux上使用pppd拨号上网工具。

在本申请的一个实施例中，客户端程序的开发主要在Windows 10上进行。相关的支持工具主要涉及终端调试工具、虚拟机、集成开发环境等。

其中，终端调试工具用于在Windows上连接ARM Linux，调试ARM Linux上的应用。在实施例中，终端调试工具使用SecureCRT 7.1。使用SecureCRT时，首先将运行Windows的主机通过USB线与I.MX6U-ALPHA开发板连接，再启动SecureCRT，设置串口参数，即可打开调试终端。

为了向ARM Linux移植应用，交叉编译主要在Ubuntu 4.15.0上进行。所述交叉编译工具Linaro安装在Ubuntu上。在所述实施例中，为了便于在Windows上进行交叉编译，使用VMWare 15.5.0虚拟机安装Ubuntu 4.15.0，并配置Ubuntu的交叉编译环境。

为了提高客户端程序的开发效率，在Windows上使用ARM公司推出的ARMDevelopment Studio 5(DS-5)集成开发工具，完成客户端程序的开发及调试。DS-5在Windows上的交叉编译使用Linaro for Windows gnueabihf 5.4.1(与Ubuntu上的交叉编译工具Linaro for ARM Linux gnueabihf 5.4.1对应)。

在上述实施例中，为了驱动硬件运行，使用的驱动程序主要包括：CH340、PL2303。其中，CH340是一种USB与串口的转换驱动，PL2303是一种RS232与USB的转换驱动。在图2所示的实施例中，北斗短报文模块使用PL2303驱动，导航模块使用CH340驱动；运行Windows的主机与I.MX6U-ALPHA通过USB连接时，使用CH340驱动。因此，在上述实施例中，Windows、ARMLinux及Ubuntu均需要安装相应驱动。

2.3北斗短报文通信及导航

(1)通信模型

短报文模块的通信模型如图3所示。北斗卫星定位系统集成了RNSS与RDSS两种业务。其中，RDSS同时提供定位和通信功能。在短报文系统中，RN和RD消息分别通过以下方式传输：

①客户端程序将北斗模块产生的RN消息存入缓存队列，由移动通信模块发送给服务端程序(服务端程序的收发实际由网卡等网络设备完成，省略了次要的通用设备)；

②与此同时，客户端程序将RN消息作为RD短报文的内容，通过北斗模块发送给指挥机，进而传输给服务端程序；

③北斗模块收取的RD消息，交由客户端程序进一步处理；

④用户通过用户前端执行RN、RD或其它指令，服务器程序通过移动通信方式将指令传递给客户端程序执行；

⑤指挥机能兼收所管辖子用户的定位、通信信息(仅限于RD)，并向所管辖的子用户发送组播、通播信息，实现对子用户的分组管理和集中调度功能。

因此，RN消息从客户端程序传递给服务端程序的路径有两个：

①由移动通信模块通过移动通信方式传递；

②由北斗模块通过RD方式传递。

在此基础上，可以制定多种传输策略，有效的融合两种传输方式，应对不同的通信状况。结合缓存机制，进而实现频繁掉线状况下的应急传输及重传。

(2)通信协议

北斗短报文模块及导航模块的功能使用串口编程技术实现。使用串口时，首先设置正确的串口参数，如速率、数据位、校验、停止位等，然后打开串口进行读写。北斗短报文模块及导航模块的串口通信基于NMEA(National Marine Electronics Association)协议。协议数据的格式为：$IDsss, d1, d2, ……, dn*hh。

其中，“$”为定界符，收到该字符，说明一条新消息开始，接收消息是可以根据该字符判断一条新消息；“ID”为发送器的标识符；“*”号表示数据字段已结束，可根据该字符判断一条消息的结束；“d1, d2, ……, dn”为指令的内容字段，以英文“,”分隔；“sss”为通用语句标识符；“hh”为和校验字段，算法是在定界符“$”与“*”之间(但不包括这些定界符)的全部字符执行异或运算。

发送时将16进制的高4位和低4位转换成两个ASCII字符(0～9，A～F)，最高有效位首先发送。为回车换行符。例如，以下为GNSS模块的一条输出语句：

$GPGSV,3,2,09,26,75,312,,27,12,189,,29,26,053,,31,56,040,*7D；

其中，GP标识符是指GPS(Global Positioning System)；GSV表明本语句包含可视卫星数、卫星标识号、仰角、方位角及信噪比(SNR)值；其后用逗号分隔的部分是指令的内容字段；最后，7D是本条指令的校验和。又如，申请北斗短报文模块进行定位的语句为：$CCDWA,0242407,V,1,L,,0,,,0*65；其中，CC标识符指代“计算机系统”；DWA为设置用户设备发送定位申请的语句标志符；0242407为用户地址；V表示普通定位(相对于A紧急定位)；1表示无程高；65为本条指令的校验和。各语句的具体格式可参考NMEA协议。

(3)程序实现

北斗模块的控制流图如图4所示：①首先，打开串口，从指令队列弹出一个命令(popCommand)并执行(putRequest)；②其次，每隔60秒申请自身的RD定位(putRequest(CMD_LOCATION))(所选用北斗卡的服务频度最短为60秒)；③每次执行指令(调用putRequest)后，getResponse方法将串口的输出存入缓存队列。

导航模块的流程图如图5所示。它不断的读取RNSS串口的输出(readLine)，并将读取到的行存入缓存队列(即调用数据库工具类的exec方法，将数据插入缓存表)。

北斗短报文模块及导航模块的功能使用串口编程技术实现，两者预警GNSST2类封装了SerialPort类(图6)。使用串口时，首先设置正确的串口参数，如速率、数据位、校验、停止位等，然后打开串口进行读写。

串口的读写主要基于SerialPort类，它提供了设置串口参数(init)、读数据(getResponse)及写数据(putRequest)等功能。T2开发板的RDSS和RNSS各占用一个串口。基于SerialPort提供的功能，可对两个串口分别进行控制。

每次调用SerialPort的getResponse方法读取的数据为一个命令行(即NMEA协议的数据行，在SerialPort中称为Sentence)。命令行的解析依赖于CmdParser(图7)和CmdBuilder类(图9)。

CmdParser类主要用于解析(parse)命令行的字段(T2开发板支持NMEA 2.1协议)以及验证校验和(verify)。为了实现这些功能，CmdParser主要依赖于CmdVerifier、Checksum、HexChar、HexConverter等类，如图8：① CmdVerifier类主要用于校验和的校验；②Checksum用于计算校验和；③HexChar表示校验和的高、低两个十六进制字符；④HexConverter用于将字符值转换为十六进制的表示形式。

CmdBuilder类主要用于命令行的构建，即根据给出的命令行的各字段，补全校验和，生成合法的命令行语句。它主要依赖于Checksum、HexChar、HexConverter等类，如图10。

2.4数据缓冲池

(1)读写同步原理

客户端程序一方面接收北斗短报文、导航信息以及控制服务器传回的数据，另一方面通过北斗短报文和移动向控制服务器发送数据。为了解决掉线数据重发问题，以及对数据收发进行同步，在如图13所示的本申请的一个实施例中，使用SQLite 3.11.0对收发的数据进行缓存，实现读写同步。具体而言，客户端程序的数据收发是一个“生产者-消费者”问题。如图13所示，生产者和消费者分别在单独的线程中实现：

①生产者收集接收到的导航数据、移动通信数据及北斗短报文，放入数据缓冲池；

②消费者从数据缓冲池取数据，通过移动通信及北斗短报文通信，发送到控制服务器。

在所述实施例中，数据缓冲池使用SQLite数据库实现：

①为了进行高效的数据读写，开启SQLite的WAL模式，该模式支持多线程安全的并发读；

②使用单例模式，全局仅打开一个SQLite数据库连接，并维护一个整型变量记录已打开的数据库终端数量，仅当终端数量减少到零时关闭数据库连接；

③使用互斥信号量支持多线程安全的数据库写。

(2)数据缓冲池的实现

数据缓冲池以数据表的形式实现。即使用数据库表模拟先进先出队列，实现数据收发同步(如表1所示)。

表1数据缓冲队列(lines表)

lines表将NMEA协议语句分段存储，可用于数据的筛选(根据指令类型、字段值、日期等)。“visited”字段用于标志表中的行是否被访问过。仅有visited值为0的数据行参与缓存队列的出队操作。当visited被标记为1时，实际上并未从表中删除，而是作为历史数据保存下来。

字段“f1”至“f30”保存了协议语句的前30个内容字段(现有协议语句的字段数未超过30)。

lines表存储非NMEA协议语句时(例如指令结果)，可使用“code”字段标志数据的类型。

数据库访问的主要工具类是DataBase(如图11所示)，它提供了读取数据表(getTable)及执行更新(exec)等操作。为了方便SQL语句的构建，还提供了SQLBuilder等类。

2.5移动通信

移动通信使用Socket编程技术实现。客户端程序作为客户端(Client)，服务端程序作为服务器(Server)，两者构成C/S(客户端/服务器)架构，基于TCP协议进行通信。

该模块基于现有的Socket通信算法实现，在此不再详述。

3控制端子系统的选型

控制端子系统用于接收航行器子系统传回的数据及向航行器子系统发送配置和控制指令。在本申请的一个实施例中，图12示出了各控制端子系统及控制端子系统之间的连接。

图12中各标号说明如下(用户前端未包含在图12中)：(2.1)控制服务器；

(2.2)北斗指挥机：(A)2.2的直流电源接口、(B)2.2的网口、(C)2.2的天线接口。

3.1控制服务器

控制服务器是地面微机操作系统的宿主，通过网口控制北斗指挥机，并接收北斗指挥机传回的数据，同时接收航行器子系统传回的数据，为用户前端提供数据支持。在图12所示的本申请的一个实施例中，控制服务器采用研祥第三代4U 19"标准上架工控整机IPC-820(2.1)。IPC-820的一个网口接入互联网；另一个网口与2.2的网口B连接(网口均为RJ45型)。

IPC-820的主要资源包括：ATX 250W电源；移动内存；1T硬盘；VGA + DVI-D接口；2个千兆网口；6个USB 2.0接口；1个LPT；6个COM口；4个PCI；1个PCI_Ex16；1个PCIEX4。

IPC-820主要特点有：(1)气密性、防腐防氧化性、防尘性高，能够在多尘、潮湿、高低温、腐蚀等恶劣环境下可靠运行；(2)电气部位夹持力大，抗振动和冲击能力强，能够在振动环境下长时间可靠工作。

3.2北斗指挥机

北斗指挥机用于与北斗卫星进行短报文通信。在图12所示的本申请的一个实施例中，北斗指挥机采用海聊北斗指挥终端M2(2.2)。24V/2.5A直流电源(A)通过Q14J2A型连接器接入2.2的A口，为2.2供电。天线C通过JN(S)-KF4型连接器接入2.2的C口。

M2的功能特性包括：

(1)具有RDSS通信及定位功能，定位精度20米，可指示接收卫星信号功率；(2)采用10通道设计，具有北斗二代RD全波束接收能力；(3)可同时使用五张北斗指挥卡，可扩展北斗二代无源定位功能；(4)兼备子用户分组管理和集中调度功能，诸如子用户定位、组播短消息等，可管理多达2000子用户；(5)兼容北斗一代、二代多种协议输出，支持灵活的组网升级；(6)针对城市中复杂WIFI/移动电磁环境的抗干扰设计；(7)可靠性按照国军标相关要求设计，通过严格试验和检验。

由上述选型可见，控制端子系统基于北斗指挥机，控制服务器仅需接入互联网即可完成部署，而无需部署岸站或中继站。且北斗指挥机易于移动，控制端子系统具有一定的机动能力。

3.3用户前端

用户前端主要提供如下功能：

(1)向用户提供网页形式的操作界面，使得用户能够方便的使用系统提供的各种功能；

(2)提供网页的访问服务，在用户通过浏览器提交访问请求时快速的响应，同时作为代理从相关子系统获取用户所需的数据。

一个易用的、现代化的用户界面至少具备以下特点：

(1)优良的、合理的界面设计；(2)异步的操作请求，减少对用户操作的阻塞；(3)局部刷新，降低浏览器的渲染开销，提升用户的操作体验；(4)即时推送，支持双向的即时通信。

为此,用户前端基于WebSocket技术与服务端程序进行通信，并基于Ajax技术完成数据存取。

4服务端程序的实现

服务端程序运行在控制服务器的微机操作系统上，实现北斗指挥机的控制功能、与客户端程序通信的移动通信及短报文功能、向航行器子系统发送指令的功能以及客户端程序的零接触配置功能。

在本申请的如图12所示的实施例中,控制服务器使用Windows 7操作系统。服务端程序是运行在该操作系统上的一个应用。在所述实施例中选用Java实现服务端程序，主要包括北斗指挥机的控制、WebSocket服务、配置管理、多客户端管理、数据管理以及用户前端等方面。

4.1北斗指挥机的控制

(1)控制方式

北斗指挥机附带了工具软件“北斗标准测试软件”，提供了用户编程接口(Java及C#两种)。实现北斗指挥机控制的方式之一是：

①通过附带的工具软件配置北斗指挥机的工作方式；②通过Java调用指挥机提供的编程接口，读取北斗指挥机返回的数据、向北斗指挥机写入控制指令。但经过调研发现：

①基于Java的编程接口版本陈旧，缺少使用说明；②基于Java的编程接口是对低层通信方式的封装，存在一定的性能问题；③基于C#的编程接口不能与当前架构较好的集成。

实际上，通过网线连接到指挥机时，指挥机与它的用户终端之间工作在客户端/服务器模式：客户端通过TCP或UDP协议连接到服务器，指挥机作为服务器接受客户端的连接，客户端通过IO读写对指挥机进行控制。

为了解决以上问题，未使用指挥机附带的编程接口，而是通过实现指挥机客户端的方式。这种方式的优点是：①比使用编程接口的方式更为底层，效率更高；②自行解析IO数据，能够实现更灵活的控制功能；③能够与通信服务子系统内的其他模块更方便的集成。

(2)程序实现

①指挥机的控制。实现指挥机控制的类主要是M2000，它的类图如图15所示。M2000实现了Runnable接口，当服务端程序启动时，M2000类的实例在独立的线程中运行。M2000启动后，连接到指挥机，并开启两个独立的线程进行IO读写。IO读写主要通过它的两个内部类，Reader和Writer实现。这两个类的实例分别在并行的线程中运行。

Reader类不断的从指挥机读取数据，根据指令的起止符，每解析出一条指令(由CmdReader完成)，交由CmdLineFactory创建命令行实例。CmdLineFactory基于简单工厂模式(详见下文)，它负责创建合适的CmdLine(抽象类)类型的实例对象。

②指令的执行过程。M2000类的exec方法用于执行指令(如图16所示)。exec方法具有两个参数，类型分别是CmdLine及CmdListener。前者表示需要执行的指令，后者表示指令监听器。指令监听器用于处理感兴趣的指令。

执行指令时，m2000(以类名的首字母小写表示该类的对象，下同)将exec参数指定的指令监听器对象cmdListener添加到监听表，然后将cmd对象添加到指令队列。指令的执行具体由writer完成，它将cmd对象表示的指令写入IO流。接下来，每当reader读取一条指令，就会调用每个监听器的matches方法，判定该监听器是否能匹配这条指令。如果是，监听器的callback方法会被调用。callback方法包含了对感兴趣的指令进行处理的程序。它的返回值表示该监听器是否已超时。当callback方法返回时，如果调用其timeout方法，则使用监听器的默认超时时间。callback也可以返回false(表示未超时)，继续监听指挥机的输出指令。当callback返回true时，表示已处理完毕，不再监听指挥机。此时reader会将该监听器从监听表删除。callback处理完成时，m2000可以调用WebSocket服务模块(参见下文)，异步的响应用户操作。此外，m2000还通过RawDataDispatcher类将指定数据(例如导航信息)分发给数据管理系统。

③指令的解析。指挥机的控制涉及指令的解析及创建。M2000使用CmdLineFactory、CmdLine以及相关的一簇类完成相关的操作(如图17所示)。CmdLine是一个抽象类，它的两个子类，CmdLine2和CmdLine4，分别表示NMEA 2.1和4.0协议。CmdLine4的两个子类，CmdIcxx和CmdDwxx，分别表示ICXX指令和DWXX指令。CmdIcxx的两个子类，CmdIcxxFrames和CmdIxccIC，分别表示两种不同的ICXX指令。

CmdLineFactory基于简单工厂模式，根据Reader读取的指令行，创建具体的CmdLine实例。CmdLineFactory依赖于CmdIcxxFactory，后者用于创建CmdIcxx类的实例。

4.2 WebSocket服务

(1)实现框架

WebSocket服务基于SpringBoot框架，主要由WebSocketServer等类(如图18所示)完成。

Spring框架为开发Java应用程序提供了全面的基础架构支持。它包含一些能够提高应用开发效率的模块，缩短了应用程序的开发时间。SpringBoot是Spring框架的扩展，是在Spring基础上进行简化配置和开发流程的Web整合框架，使开发、测试和部署更加便捷。

WebSocketServer使用了@ServerEndpoint("/ws/{userId}")注解和@Service注解。

@ServerEndpoint将WebSocketServer定义成一个WebSocket服务器端,注解的值用于监听客户端(例如用户使用的浏览器)请求的URL。@Service注解用于标注服务层，主要用来进行业务的逻辑处理。当客户端使用"/ws/{userId}"请求WebSocket服务时，WebSocketServer以{userId}为键,以WebSocketServer对象为值，为该请求建立一个键-值对，保存在webSocketMap中。服务的请求处理完毕后，WebSocketServer根据{userId}响应相应的客户端。

(2)编程模型

具体而言，WebSocketServer实现了一种请求分发和处理的编程模型。

处理请求具体的类是WSHandler(如图14所示)。WSRequestDispatcher根据请求(ask参数)，加载相应的WSHandler对象，将请求分派给该对象进行处理。

WSRequestDispatcher加载WSHandler对象时，使用的@WSRequestMapping注解是一个自定义的注解，它标注了WSHandler的子类用于处理哪个请求。WSHandler的子类均包含在cn.com.jec.app.handler包中。WSRequestDispatcher遍历handler包，查找所有的@WSRequestMapping标注，创建相应的WSHandler对象，并根据标注值(例如“m2kInfo”，意为获取指挥机基本信息)，建立“标注值-WSHandler对象”映射。

每个WSHandler的子类均基于单例模式，用于处理一个特定的请求。WSRequestDispatcher将请求分派给WSHandler对象时，使用{userId}、客户端请求(ask)等，创建WSRequest对象，作为调用WSHandler.handle()方法的传入参数。

WSHandler对象处理完毕后，调用WebSocketServer的response等方法响应客户端。ResponseData类封装了响应客户端的数据格式。

(3)请求的处理

因此，在WebSocketServer请求分发和处理的编程模型中，处理一个特定请求的步骤是：

(1)在handler包中使用@WSRequestMapping注解添加一个类；(2)编写处理程序。

已有的WSHandler子类如图19所示。例如，处理指挥机基本信息获取的类是HandleM2kInfo，它使用@WSRequestMapping("m2kInfo")进行注解。当客户端的请求带有“ask=m2kInfo”参数时，请求的处理就会分派给该类的对象。客户端的请求和WebSocketServer的响应是异步的。客户端不必阻塞的等待响应。由于客户端和WebSocketServer已建立连接，WebSocketServer可以在请求处理完毕后，将结果推送给客户端。

4.3 配置管理

配置管理的目标是提供一种形式良好、可扩展的配置形式，实现监控数据格式的自定义。

(1)配置项

配置管理基于配置项。一个配置项由一个“键-值”对表示，一个配置由多个配置项构成。配置的格式为：name=value[#name=value][...]；其中，name表示配置项的名称，value表示相应配置项的值。多个配置项之间使用#分隔。目前已支持的配置是：id={ID}#addr={ADDRESS}#port={PORT}#gnss={GNSS}；各配置项的含义如表2及表3所示。

表2已支持的配置项

表3“gnss”配置项

例1："id=fv0001#addr=47.110.72.141#port=61135#gnss=cfg1,*,GGA,1-5,9;cfg2,*,RMC,1,3-11"；该例中的配置含义为：

①航行器id为“fv0001”；②服务器连接地址为“47.110.72.141”；

③服务器端口为61135；④gnss配置项的值为“cfg1,*,GGA,1-5,9;cfg2,*,RMC,1,3-11”。

该例中gnss配置项的含义为：

①该配置有两个子项，分别是“cfg1”和“cfg2”；②“cfg1”匹配的指令为：code任意，tag为“GGA”；③“cfg1”返回匹配指令的第1-5以及第9字段；④“cfg2”匹配的指令为：code任意，tag为“RMC”；⑤“cfg2”返回匹配指令的第1以及第3-11字段。

(2)配置表

在客户端(航行器端)，配置存储在数据库的配置表(config)中。如表4所示，配置表的每一行存储一个配置项：item字段对应于配置项的名称，val字段对应于配置项的值。

表4 配置表(config)

(3)程序实现

服务端不存储连接的配置数据，而是在每次连接建立时动态的获取。连接建立后，客户端传回的配置信息保存在TransConfig对象中(如图20所示)。

构造TransConfig对象时，传入配置数据(如上文例1所示)。然后parse()方法将配置数据解析为“键-值”对，保存在成员变量中，随后可使用get()方法获取。在客户端和服务端之后的通信过程中，双方各自维护配置信息。服务端保存了每个客户端的配置数据，每个客户端均可进行个性化的设置。

同时，TransConfig类实现了配置的变更机制，以支持配置的即时更新。当用户通过前端界面变更配置后，TransConfig对象的idChanged()、update()方法被调用，以便更新服务端配置信息。服务端更新配置信息后，调用WebSocket服务，通知在线的WebSocket客户端，使各WebSocket客户端的通信状态得以及时更新。

4.4 多客户端管理

在所述实施例中，为了对多个客户端(航行器)进行管理，服务端程序通过多线程方式，管理与客户端的连接：

①为了区分不同的客户端，客户端通过全局唯一的ID标志自身；②客户端首次与服务器建立连接后，自身ID发送给服务器；③服务器为建立的连接创建一个线程，将客户端ID、线程ID与连接句柄三者绑定，放入线程池。

通过线程池管理多客户端连接具有如下优点：

①连接句柄与客户端ID绑定，可以避免在后续通信过程中重复发送ID；

②客户端掉线重连时,可以根据客户端ID复用线程池中的线程,降低销毁及创建线程的开销；

③可以通过优化线程池的管理策略，降低系统资源开销，提升性能。

多客户端管理程序的实现基于现有的Java多线程管理技术，不再详述。

如上文所述，单个北斗指挥机能够管理和调度2000个用户终端。目前，所述实施例的服务端程序已通过具有国家资质的第三方测试机构的检验，能够并发的管理2000个航行器，具有对多监视源进行协同控制的能力。

4.5 数据管理

数据管理子程序基于Spring框架及MyBatis框架，采用MySQL 5.7.20对数据进行管理。

MyBatis是一个Java持久层框架，它使用ORM(Object Relational Mapping,对象关系映射)对结果集进行了封装。MyBatis封装了JDBC(Java Database Connectivity)的诸多细节，把数据库表和实体类及实体类的属性对应起来，实现了实体类与数据库表的同步。

数据管理子程序基于Ajax为用户前端提供数据访问服务，它提供了一组控制器类处理数据访问请求。具体而言，处理访问请求的类使用@RestController及@RequestMapping("/api/{requestItem}")注解标注。其中，{requestItem}表示访问项。

Spring根据访问项将请求转发给控制器类。控制器类的方法使用@ResponseBody及@PostMapping("/{subItem}")等进行标注，对访问请求进一步过滤。与请求匹配的方法处理访问请求时，使用MyBatis实体类对数据库进行操作，返回所需数据。

4.6 用户前端

用户前端基于Vue，为用户提供了对系统进行操作的界面。

Vue是一套用于构建用户界面的视图层(Model-View-Controller架构模式中的View)框架。它采用自底向上增量开发的设计理念，力图通过尽可能简单的API实现响应式的数据绑定和视图组件的组合。

组件(Component)是Vue最强大的功能之一。组件可以扩展HTML元素，封装可重用的代码。Vue通过不断复用小的组件来构建更大的组件，以此渐进的构建大型应用。

用户前端的整体框架是，通过Router实现多视图的单页Web应用(Single PageWeb Application，SPA)。Router是一个Vue提供的组件，它是基于路由和组件的：

① Router将路径映射到组件；②通过改变页面路径来切换组件。

用户前端的每个页面分别对应于一个组件。通过配置Router，可以将URL与组件对应起来。用户通过URL访问页面时，Router根据配置切换组件，实现不同视图的切换。

用户前端与服务端程序的交互主要基于Ajax及WebSocket。用户前端与后者相对独立，它基于SpringBoot框架，能够单独部署在服务器上，提供用户页面的访问服务。

传统应用系统的信息承载能力较弱，对GPS的依赖性强，难以支撑多监视源的实时控制、动态航路搜索、高效电子航图等应用场景。另一方面，在近海通用航海中，GMDSS主要用于遇险和安全通信系统，不便于服务的个性化定制和扩展。加之，海上航行器接入GMDSS需要建立船站，部署的便捷性较差。本申请综合利用北斗短报文通信及移动通信技术，集成了移动通信模块、北斗RDSS模块、北斗RNSS模块以及独立的RNSS，采用配置项对监控方式进行管理，支持监视数据内容和格式的个性化定制，导航系统的可用性较高，具有对多监视源进行协同控制的能力；各硬件模块通过标准接口与主设备相连，可单独替换或升级，可扩展性强；软件系统建立在嵌入式操作系统和微机操作系统之上，操作系统本身及软件系统均易于升级，系统的功能及性能随系统软硬件设施的演化而增强；客户端及控制端接入便捷，支持便携式部署；控制端系统部署便捷，只需接入互联网即可完成部署准备，卫星通信通过北斗指挥机完成，无需部署基站或中继站。

以上所述的仅是本发明的实施例，方案中公知的具体结构及特性等常识在此未作过多描述。应当指出，对于本领域的技术人员来说，在不脱离本发明结构的前提下，还可以作出若干变形和改进，这些也应该视为本发明的保护范围，这些都不会影响本发明实施的效果和专利的实用性。本申请要求的保护范围应当以其权利要求的内容为准，说明书中的具体实施方式等记载可以用于解释权利要求的内容。