车载GPS等基于部标通信协议的开发方案

交通部过检的808、809是车辆监控系统必须过检的功能，做车载的企业基本都围绕这两个协议做底层的封装，无非展示方式不同而已。对于一家做导航定位的企业，解析通信协议必须是最能够体现能力和耐心的一件事，必须了解协议规范和通信框架才能完成相关的开发任务，最要命的是要符合部标规范要过检（去北京貌似）系统才能正式上线。偶然间发现一个好地方，这里应有尽有，可以到http://www.cnblogs.com/productivity/category/492431.html 一看究竟。（非广告贴，提供大家学习之用）

基于Java语言开发jt808、jt809技术文章精华索引

而java语言是开发部标平台技术的非常理想的开发语言，因为他非常全面，各个方面的底层框架都有具备，高性能的socket通信框架比如netty、mina, 可以帮助你构建高并发大规模的Gps服务器，接入十几万的海量终端，之所以说全面，是因为我们不仅仅单单开发一个Gps服务器就完事了，一个完整的部标平台，还有复杂的web功能平台，提供给用户人性化的操作界面，进行GPS监控、报表统计、数据查询、报警提示等等，而Java平台的springMVC、Hibernate、spring等框架也是非常成熟的底层技术框架。而j2EE提供的基于RMI的RPC进程间调用框架，和spring结合的非常完美，可以方便web平台和808服务器、809服务器之间进行复杂的数据交互和转发。

基于部标Jt/T809协议和Java Netty框架构建Gps位置监控平台

JT809网关数据接口服务系统，是基于TCP协议开发的部标809协议服务软件系统。系统利用高并发的Netty通信框架，采用通信双方约定的809协议规范，完成对协议数据的解析、拦截、数据入库、报警分析和转发的工作。并实现协议数据与上级平台、下级平台（多方企业运营服务平台）之间的数据通信桥梁。从而实现多部标企业平台车辆动态数据通过拦截、转发、存储的功能推送至自有企业平台。

基于Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架构建高性能企业级的部标GPS监控平台

开发企业级的部标GPS监控平台，投入的开发力量很大，开发周期也很长，选择主流的开发语言以及成熟的开源技术框架来构建基础平台，是最恰当不过的事情，在设计之初就避免掉了技术选型的风险，避免以后在开发过程中，不断的填坑走弯路，以至于整个团队被坑埋掉。做GPS平台这么多年，以前就了解到一些开发团队过于关注某一种语言的优势，比如过于选用GO，Erlang，python,php等技术，最后团队熟悉这些技术的关键人员离职了，都没人接手，不能不说是个悲剧。所以说平台的技术架构选型要注重的是稳健，均衡而不是偏激，而SpringMVC4, Mybatis4, Hibernate4就是GPS监控平台软件开发的理想框架选择。

基于C#和Asp.NET MVC开发GPS部标监控平台

基于交通部796标准开发部标监控平台，选择开发语言和技术也是团队要思考的因素，其实这由团队自己擅长的技术来决定，如果擅长C#和Asp.NET, 当然开发效率就高很多。当然了技术选型一定要选用当前主流的技术，现在Asp.NET技术已经发展到5.0, 如果你还是用旧的ASP技术写程序，无疑是为以后的项目维护埋下地雷，后面新来人手学习不到技术，没有兴趣去改进，不愿意维护，没有人愿意接手。代码最关键的是要不断的重构，保持与当前的技术和需求同步，平台才有生命力，否则就会越来越臃肿而变得难以维护。开发一个基于Asp.NET MVC和C#语言的部标平台，主要应用的技术如下：1）服务器通信技术：因为C#中，基于.NET4.0的异步通信框架，还是非常不错的。不过编程模式也是比较复杂的，不像Java的NIO框架Mina和Netty那样方便省力,但是一样可以开发出高性能的jt808GPS服务器和jt809服务器。2）分布式服务：对于高性能的平台，服务一定是要求分布式部署和调用的，以应对压力，比如jt808GPS服务器、存储转发缓存服务器和web服务器，都是部署在不同机子上面，对于远程服务调用

基于Java Netty框架构建高性能的部标808协议的GPS服务器

使用Java语言开发一个高质量和高性能的jt808 协议的GPS通信服务器，并不是一件简单容易的事情，开发出来一段程序和能够承受数十万台车载接入是两码事，除去开发部标808协议的固有复杂性和几个月长周期的协议Bug调试，作为大批量794车载终端接入的服务端，需要能够处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理等。如果没有足够的网络编程经验积累和深入了解部标808协议文档，自研的GPS服务器往往需要半年甚至数年的时间才能最终稳定下来，这种成本即便对一个大公司而言也是个严重的挑战。

交通部部标平台检测(二)-如何快速的通过交通部过检

由于交通部部标平台过检的标准信息相对不是很透明，大家对796标准和jt/t 808 协议、jt/t809协议都是通过文档的字面意思各自去理解的，误差难免，误差大的，到北京过检的时候，就要耽误的时间长，过的就非常不顺，花费的差旅费和检测费就很大，得不偿失。很多去过检的企业都不是北京公司，在北京检测要背负额外的时间成本和费用成本，所以要追求较高的成功率，不然遇到问题，要面临两难选择，要么回来，改完了再坐一趟飞机去检测，要么呆在酒店里，改完了，重新预约下次检测时间，一直到过了为止。过完检的人都会感慨良多，不过不知道，过了感觉里面全是大坑，仅靠理解简单的功能列表是不行的，差的太远。

部标平台检测(一).企业监控平台标准符合性压力检测实施细则

2015-07-29 16:17 by GPS产品经理, 331 阅读, 收藏, 编辑

796协议中规定，平台车辆接入性能的要求为：监控平台需满足具有海量定位数据高并发能力；平均500条/秒，峰值1000条/秒；企业平台能支持至少10000台终端接入，支持超过10000个动态目标的监控能力。

GPS部标平台的架构设计(十)-基于Asp.NET MVC构建GPS部标平台

在当前很多的GPS平台当中，有很多是基于asp.NET+siverlight开发的遗留项目，代码混乱而又难以维护，各种耦合和关联，要命的是界面也没见到比Javascript做的控件有多好看，随着需求的增多，平台已经臃肿不堪。我们在设计基于.NET的GPS部标平台的时候，就坚定不移的选择了基于JQUERY+Asp.NET MVC来作为前端交互和后台处理的框架。选用一个灵活的脚手架，同时团队又能掌握这个脚手架为团队所用。

GPS部标平台的架构设计(九)-GPS监控客户端设计

交通部的部标过检，所有的测试都是从客户端发起的，也是在客户端体现的，在客户端承载了部标标准所要求的所有的功能，是整个部标平台当中工作量最大的部分，也是最繁琐的部分。客户端设计面临两个问题：1.基于CS还是基于BS，这是个问题，萝卜白菜各有所爱，客户要什么，我们就开发什么，从客户来讲，更适应桌面客户端，没有浏览器的七七八八问题，速度感觉上也比网页的快，操作方便。当然网页客户端也有很大的优势，部署和维护方便，不需要开发升级系统。

GPS部标监控平台的架构设计(八)-基于WCF的平台数据通信设计

部标平台开发的复杂性就在于，我们可以快速开发出一个大面上过得去的东西，但是却无法开发出一个严格符合要求的部标平台，从上图中可以看出一个拍照指令，需要贯穿四个子系统，并且是异步的。如何跟踪各种指令在横跨各个子系统或平台时的发送状态、执行状态和应答状态，不仅仅是一个需要在用户体验上面下功夫的功能，在交通部的部标认证的检测中，最最麻烦的就是运行检测，因为要跨两个平台，政府平台和企业平台，企业平台内部要跨越终端、808服务器、809下级平台服务器等多个子系统。检测失败，可能出现在各个环节当中，检测人员只是平静的告诉你没有通过，而我们剩下就是猜了。所以每个系统必须要有较好的指令监控的功能，以便于较好的应对实际的部标检测中出现的意外情况。以下是对809转发服务器的指令的数据包监控。

GPS部标监控平台的架构设计(七)-压力测试

部标监控平台的压力测试是部标检测流程的最后一个检测环节，也是最难的，很多送检的企业平台都是卡壳在这一个环节，交通部jt/t796协议中规定，平台车辆接入性能的要求为：监控平台需满足具有海量定位数据高并发能力；平均500条/秒，峰值1000条/秒；企业平台能支持至少10000台终端接入，支持超过10000个动态目标的监控能力。依据上述要求，对于企业平台的压力检测采用TCP方式进行，分为两个部分进行；动态目标压力为检测和定位数据压力检测。

GPS部标平台的架构设计(六)-Android手机客户端和手机查车设计

对于GPS软件平台，虽然有功能非常丰富的PC端或BS客户端，但是客户也是需要移动客户端来作为自己的辅助工具，也是需要的。做为GPS平台的设计者和开发者，在开发移动客户端的时候，也需要从常规的服务器开发和客户端开发的思维中，转变过来，当然客户的需求也需要转变，因为毕竟不能随心所欲的将PC端的所有功能需求照搬到手机客户端，手机的开发环境、网络环境、使用环境都决定了设计理念与PC端的设计是完全不一样的。通常我们成为GPS部标平台的手机客户端为手机查车，实际上现在的功能不仅仅是查车，由于客户需求的推进和演变，我们推出手机查车功能更加丰富，已经包含了统计报表、统计图表、车辆终端控制、个人手机定位和追踪等功能。

GPS部标平台的架构设计(五)-地图服务算法库

GPS平台，需要和各种地图打交道，需要解决以下的问题：1.GPS坐标偏移，这个不用多说，需要将原始坐标加偏，然后在百度地图或谷歌上显示出来，需要注意的是百度地图的加偏是偏上再偏，谷歌、高德地图等是火星坐标；2.坐标解偏，或者GPS纠偏，这个我们也是需要的，因为当用户在地图上画出的各种区域，标注，发送到后台存储的坐标都是基于地图所采用的坐标系统，因而是偏移的，这就面临一个严重的问题，因为在部标808协议中，对于区域报警，需要将区域的顶点坐标，下发给终端，终端在实际运行中，不断用GPS坐标和区域坐标进行比对，来判断是否是进入区域报警，还是离开区域报警。如果区域坐标是偏移的，那么判断出来必然是错误的。所以下发前，必须要将偏移的坐标逆向再还原成原始的基于wgs84坐标系的坐标出来。

GPS部标平台的架构设计(四)-百度地图设计

地图是客户端中不可缺少的一个模块，很多人在设计和画图时候，喜欢加上地图引擎这样高大上的字眼，显得自己的平台有内涵，说白了就是用第三方的SDK来开发，早期的GPS监控软件用的都是mapx、mapxtrem、acrgis之类的，使用的都是本地地图。不仅要购买正版地图，还要购买价格不菲的地图引擎license，服务器版的部署的时候，还要绑定到服务器ID上，现在这种开发方式已被抛弃。现在的百度地图、谷歌地图提供的SDK接口丰富，开发方便，系统稳定，大家都用的很爽。

GPS部标平台的架构设计(三) 基于struts+spring+hibernate+ibatis+quartz+mina框架开发GPS平台

在开发一个基于Java的、BS架构的GPS平台的时候，我们总是要花费很多心思去选择框架，在此基础上进行封装提供易用的功能，来作为我们快速开发的平台。有的公司有积累，可能在此上面花费的时间比较少，有的没积累，可能为了选择什么样的框架，为了优缺点争论不休，耽误个把月时间都有可能。我希望在此给出一个GPS平台的标准模版，供大家参考，统一思想，快速进入状态。

GPS部标平台的架构设计(二) 可扩展性设计

，在运营平台上，为不同的物流企业提供运营服务，各个企业必然有自己个性化的需求，想要吸引客户，销售上就得尽量答应客户的各种要求，技术上就要想办法实现客户的要求，但是其他企业客户八竿子用不着。很多运营平台都经历过功能弱智简单、功能丰富最后到臃肿再到最后推到重来这样的过程。

基于Java Mina框架的部标jt808服务器设计和开发

在开发部标GPS平台中，部标808GPS服务器是系统的核心关键，决定了部标平台的稳定性和行那个。Linux服务器是首选，为了跨平台，开发语言选择Java自不待言。

基于Java Mina 和Netty 通信框架的JT/T809转发服务器设计

开发部标809协议的协议设计者把面向对象的思想带入到了协议当中，造成了协议的不容易阅读和不容易理解，但在协议本身的开发和实现非常适合用Mina框架。通过借用框架的过滤器模式，来降低协议开发的难度。

如何做好GPS平台软硬件集成测试

集成测试是为了构建一个更大的系统或平台，这个系统的几个部分通常是由不同的团队或甚至不同的公司开发的，以前在做信息化的软件开发时，面临的集成测试通常是不同软件子系统之间的集成测试，往往被这一阶段的测试搞得人仰马翻的，在从事了四年的视频监控和GPS软件开发之后，才知道，软硬件系统之间的集成测试更加折磨人的脆弱的神经。虽然两者本质上都是一样，软硬件系统集成实际上是嵌入式软件系统和常规的PC软件系统直接的集成。集成测试常常成为压垮复杂项目的最后一根稻草

JT/T 808 809 部标认证流程和申报材料下载

交通运输部发布了《道路运输车辆卫星定位系统终端通讯协议及数据格式》(JT/T808-2011)和《道路运输车辆卫星定位系统平台数据交换》(JT/T809-2011)两份技术标准文件。这两份文件中严格规定了车载卫星定位终端与企业监控平台之间，企业监控平台与政府监控平台之间的通信技术要求。同时，中国交通通信信息中心开始组织实施JT/T808和JT/T809标准的平台符合性检测工作和JT/T794-2011标准的车载硬件终端符合性检测工作。即企业平台，政府平台和车载终端的部标认证检测。

部标JT/T809平台的必测内容

809的测试相对比较困难，因为你在开发的时候，没有一个可以供你对接的测试平台，而是你开发好后，在文件申报批准后，找到交通部信息中心的技术人员，一上来就是正式的测试，这个就头大了。

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

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

基于部标JT/T 808协议及数据格式的GPS服务器开发

部标808和809的出台，统一了产品的标准，统一了平台与终端之间的通讯协议，对于GPS运营商而言，只要平台支持部标，那可以选择任意一家的GPS车载终端，也不会受厂商的制约，GPS运营商在市场竞争过程中将更看重产品的质量及服务，从而也间接地促进市场上产品的稳定性和可靠性。但是开发部标GPS服务器是一个繁琐苦逼的活，有各种各样的GPS终端需要兼容和支持，现在交通部颁发了统一的标准协议和数据格式，大部分车辆的GPS终端都需要支持，软件也需要支持，否则可能在市场准入的时候就遇到麻烦。