1.背景
最近在不同项目中对接了多个车载GPS厂商服务终端，绝大多数厂商可以提供809协议的数据对接，还有部分可以提供自定义协议等方式的对接。多个项目中，我公司处于略强势地位，所以根据现场实际的项目进度和部署环境以及对方支持的对
接方式，提出了不同的对接方案。这里做个总结。
2.809协议对接2.1协议背景
2011年5月10日中国交通通信信息中心下发了《印发道路运输车辆卫星定位系统平台和道路运输车辆卫星定位系统车载终端标准符合性审查办法（试行）的通知》。通知要求，系统平台和车载终端应当分别满足《平台要求》和《终端要求》，同
时分别满足《道路运输车辆卫星定位系统平台数据交换》和《道路运输车辆卫星定位系统终端通讯协议及数据格式》的要求。系统平台和车载终端，应按照本办法通过标准符合性审查。不符合标准的，不得用于道路运输车辆动态监管工作。《道路运
输车辆卫星定位系统平台和道路运输车辆卫星定位系统车载终端标准》简称部标，部标包括《道路运输车辆卫星定位系统平台技术要求》（JT/T796-2011，简称《平台部标》）和《 道路运输车辆卫星定位系统车载终端技术要求》（JT/T794-2011，
简称《终端部标》）。至此，关于系统平台和车载终端必须符合部标的政策性文件正式出台。而对应硬件终端标准的通信协议标准JT/T808-2011JT/T809-2011协议也随之出台。部标808和809的出台，统一了产品的标准，统一了平台与终端之间的通
讯协议，对于GPS运营商而言，只要平台支持部标，那可以选择任意一家的GPS车载终端，也不会受厂商的制约，GPS运营商在市场竞争过程中将更看重产品的质量及服务，从而也间接地促进市场上产品的稳定性和可靠性。
通过该协议流程可以知道，808协议为GPS客户终端与GPS服务终端的对接协议，而809协议为GPS服务终端与上级平台之间的对接协议。所以这里我们主要需要研究的是809协议。
2.2协议具体内容
需要理解的地方为（转）：
a.双链路维护，就是基于上面的对等概念，在Socket通信上面其实就是要同时扮演服务器监听和客户端转发的角色；从下级平台来看，转发数据的链路就是主链路，从上级平台来看，主链路用来就是监听并接收子平台转发过来的数据；所以开发
政府平台的，有的是开发企业平台的，立场不一样，理解就不一样。
b.正确的理解加解密算法和校验和算法，否则运管平台接入的时候，无法接入。
c.复杂的流程测试，和单一socket数据通信不一样，需要实现从登录、安全认证、链路保持和注销、基础车辆数据上传、注册、交换定位信息、拍照、驾驶员身份识别和车辆电子运单的功能。
对于我们企业对接GPS，我们监听主链路即可，主链路中包含了GPS服务端发送过来的数据。从链路是GPS服务端监听反馈信息使用。
2.3实现方法
a.判断状态
b.解析信息
3.自定义协议对接
由于我方不是交通监管部门，仅仅只是需要对接GPS数据，所以复杂的809协议往往适得其反。于是，我们可以和GPS服务方定义一种简单的传输协议。
可以描述为，我方监听一个端口，传输方以我们定义好的报文规范，将数据在每次心跳时传输到指定端口即可。我方对传输过来的数据进行接收和解析。
4.前置库对接
当我们和多个不同GPS厂商同时对接时，由于各厂商的对接协议和提供的功能可能均不相同，此时我们强制提供一个我们的规范表，将其放置在前置库中（车载商均可以连接该库）。其流程设计如下：
a.所有厂商将GPS数据实时写入该前置库表中，该表有一个flag字段。将该表理解为轨迹实时表，其轨迹的存储为saveorupdate，即主键车牌存在轨迹时，再传入为更新，没有该车牌时为插入新轨迹数据。
b.我方提供定时JOB，将前置库中的数据定时整体迁移至我方网段中的业务库临时轨迹表中。
c.我方提供定时JOB，对该临时表中的坐标进行实时转换，报警业务进行判断。转换后的数据存入实时轨迹表以及历史轨迹表中。报警信息存入对应的报警表中。
5.WebService对接5.1我方提供WS服务
我方提供WS服务，该服务中对传入参数进行定义，支持单次调用和以XML格式的批量传入。
XML格式定义如下：
5.2对方提供WS服务
我方编写JOB，定时调用对方WS服务进行轨迹获取。
6.总结
由于我方的车载仅为数据展示方，对于底层协议的对接方式，可以规避尽量规避。前置库对接以及WS对接，均可将对接的方式简化，而且可以将协议对接时的通信长连接对服务器的消耗进行规避。所以，项目中我们首推这两种方案。
| 
/1 
关于我们
发表于 2022-9-28 16:27:10
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务