代码改变世界

基于部标JT/T809-2011的(已过检)GPS平台数据交换及转发服务器

2013-05-01 17:22  GPS视频平台产品经理  阅读(10370)  评论(0编辑  收藏  举报

基于JT/T 809-2011的(已过检)GPS平台数据交换及转发服务器

 
2013年4月3日 分类: GPS.NETGPS系统
 

很多人在看完交通运输部的JT/T 809的标准后,单纯的以为这就是个转发平台,在实际的实现过程中,发现很复杂,所以在开发809平台的时候,第一要透彻地理解协议,第二就是要架构设计清楚,便于调试和扩展,否则会显得乱糟糟的。

809协议,首先明确一下几点:

1.双链路维护,就是基于上面的对等概念,在Socket通信上面其实就是要同时扮演服务器监听和客户端转发的角色;从下级平台来看,转发数据的链路就是主链路,从上级平台来看,主链路用来就是监听并接收子平台转发过来的数据;所以很多团队有的是开发政府平台的,有的是开发企业平台的,立场不一样,理解就不一样。

2.正确的理解加解密算法和校验和算法,否则运管平台接入的时候,无法接入。

3.复杂的流程测试,和单一socket数据通信不一样,需要实现从登录、安全认证、链路保持和注销、基础车辆数据上传、注册、交换定位信息、拍照、驾驶员身份识别和车辆电子运单的功能。,我们可以快速开发出一个大面上过得去的东西,但是却无法开发出一个严格符合要求的部标平台,从上图中可以看出一个拍照指令,需要贯穿四个子系统,并且是异步的。如何跟踪各种指令在横跨各个子系统或平台时的发送状态、执行状态和应答状态,不仅仅是一个需要在用户体验上面下功夫的功能,在交通部的部标认证的检测中,最最麻烦的就是运行检测,因为要跨两个平台,政府平台和企业平台,企业平台内部要跨越终端、808服务器、809下级平台服务器等多个子系统。检测失败,可能出现在各个环节当中,检测人员只是平静的告诉你没有通过,而我们剩下就是猜了。所以每个系统必须要有较好的指令监控的功能,同时也必须要有一个模拟的上级运管平台,以便于较好的应对实际的部标检测中出现的意外情况。

所以在设计的时候,要设计可以集成808 GPS服务器的通信接口,如WCF服务接口,完成基于内存的数据交换,从808Server转发至809Server然后再转发给省级平台。这样一个平台就相当于内嵌了两个Socket服务器和一个socket客户端。当然也可以从数据库读取数据,然后再用于转发。

 

 为了提高开发效率,便于一次新通过(自己写的没办法知道是否能测试通过),最好的方式就是直接购买809的源码,再此基础上集成到自己的服务器上。交通部部标809的测试标准参见:交通部部标809协议测试和运行测试

提供809下级平台转发生产系统源码+上级政府运管服务器源码+809协议、运行测试用例文档和代码说明文档,开发测试二合一,收费1500元。需要JT 809源码的(提供C#、Java版本选择)可以联系我:2379423771@qq.com

java版的参见:基于Java Mina 通信框架的JT/T809转发服务器设计

如果用809协议接收第三方平台转发的数据,并开发web系统进行数据展现、报警提示、地图监控、电子围栏等功能,参见文章(C#和Java都有):基于部标Jt/T809协议和Java Netty框架构建Gps位置监控平台

以下是对809转发服务器的指令的数据包监控:

 
如下图,平台的测试流程是非常繁杂的,需要接受来自808终端的GPS数据,也就是说测试要从终端开始,然后通过自有平台,经过省级平台,再进入交通部的部级平台。