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

最新推荐文章于 2024-05-09 07:05:56 发布

boonya

最新推荐文章于 2024-05-09 07:05:56 发布

阅读量4.5k

点赞数

分类专栏： LBS位置服务文章标签： 808 809 部标通信协议通信框架方案

本文链接：https://blog.csdn.net/boonya/article/details/78747222

版权

LBS位置服务专栏收录该内容

15 篇文章 4 订阅

订阅专栏

交通部过检的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坐标系的坐标出来。

关注

0
点赞
踩
11

收藏

觉得还不错? 一键收藏
1
评论
车载GPS等基于部标通信协议的开发方案

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

扫一扫