在开发部标GPS平台中,部标808GPS服务器是系统的核心关键,决定了部标平台的稳定性和行那个.Linux服务器是首选,为了跨平台,开发语言选择Java自不待言. 我们为客户开发的部标服务器基于Mina + Spring + Hibernate + Swing桌面系统开发,整个服务器的架构特点: 1.通信层:基于Java Mina通信框架进行GPS服务器开发,可以使得整个系统架构清晰,开发者可以专注于协议解析.业务和数据处理. 2.GPS终端协议层:而为了对于扩展终端的接入能力,协议层要具有很好

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

DotNetty 开源地址 https://github.com/Azure/DotNetty 个人博客地址   http://www.dncblogs.cn/Blog/ShowBlog/70 1.国家部标808协议格式 标识位采用 0x7e 表示,若校验码.消息头以及消息体中出现 0x7e,则要进行转义处理,转义规则定义如下:0x7e <————> 0x7d 后紧跟一个 0x02:0x7d <————> 0x7d 后紧跟一个 0x01.转义处理过程如下:发送消息时:消息封装——&

注意,此版本是2014年研发的基于Spring2.5和Struts2的版本,此版本的源码仍然销售,但已不再提供源码升级的服务,因为目前我们开发的主流新版本是2015-2016年近一年推出的基于spring4+springMVC4+mybatis3+Hibernate4+junit4框架构建高性能企业级的部标GPS监控平台,相对于原来的2014年研发的旧版的struts版本,从性能和功能上有了较大的提升,融合了大量客户的需求意见,相对于Struts版本,主要的特点,请点击文章详细阅读和比对: 基于

在开发部标GPS平台中,部标jt808GPS服务器是系统的核心关键,决定了部标平台的稳定性和行那个.Linux服务器是首选,为了跨平台,开发语言选择Java自不待言.需要购买jt808GPS服务器源码+808模拟测试终端工具+压力测试工具(1200元)可以联系我: 2379423771@qq.com: 我们为客户开发的部标服务器基于Mina + Spring + Hibernate + Swing桌面系统开发(基于Netty框架的GPS服务器参见:基于Java Netty框架构建高性能的部标80

在2011年交通部的796标准推出后,随着各地交管部门的硬性要求,大多数的GPS监控系统或者车辆管理系统或者物流管理系统,无论是旧的,还是新开发的,都必须要以796标准为基础蓝本,首先要满足796的要求,然后在此基础上增加行业应用的个性化要求,如物流运输车辆非常关心的油耗管理,冷链运输非常关心温度控制等等. 所以开发GPS平台的时候,必须要首先阅读交通部的jt/t 796 , jt/t808和jt/t809的文档,以此作为自己的功能设计的需求来源,行业需求或用户需求是排在后面的.很多开发团队做出

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

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

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

文章版权由作者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/ 1.背景 最近在不同项目中对接了多个车载GPS厂商服务终端,绝大多数厂商可以提供809协议的数据对接,还有部分可以提供自定义协议等方式的对接.多个项目中,我公司处于略强势地位,所以根据现场实际的项目进度和部署环境以及对方支持的对接方式,提出了不同的对接方案.这里做个总结. 2.809协议对接 2.1协议背景 2011年5月10日中国交通通信信息中心下发了<印发道路运输车

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

基于C#和Asp.NET MVC开发GPS部标监控平台 目前整理了基于.NET技术的部标平台开发文章,可以参考: 1.部标Jt808协议模拟终端的设计和开发 2.C#版的808GPS服务器开发->基于部标JT/T 808协议及数据格式的GPS服务器 3.C#版的809GPS服务器开发->基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器 4.Asp.NET版的部标平台开发->基于Asp.NET MVC构建GPS部标平台 5.基于C# winform桌面客户端的部标平台

部标1078视频监控平台,是一个庞杂的工程,涵盖了多层协议,部标jt808,jt809,jt1078,苏标Adas协议等,多个平台功能标准,部标796标准,部标1077标准和苏标主动安全标准,视频方面的协议有RTSP, RTMP, RTP, 音视频编码有H.264, AAC,  726,711等,消化这些协议和功能标准就已经是需要一个较长的周期了,而构建一个视频平台的架构,也是比较复杂的,后端不仅有网关,还要有流媒体服务器,转发服务器,播放器,RTSP或RTMP服务器等多个服务器模块,需要的技术

出租车jt/t 905协议,是jt/t 808协议的一个变种,设计者将部标808协议拿过来,并不是单纯的增加网约车相关的指令集,而且对原有的指令如定位0×0200指令也进行了修改,经过一通剧烈的修改,面目全非,协议已经与808协议本身并不兼容,这是比较失败的地方,保持兼容性,才能使协议更加让硬件和网约车平台接受和开发推广,没有经验的协议设计者和标准制定者高高在上不考虑兼容性,给硬件厂家和平台开发人员造成很大的麻烦,也增加了成本. 部标1078协议是在部标808协议的基础上,继续增加指令,并不修改

部标gps监控平台的架构,随着平台接入的车辆越来越多,架构也面临越来越大的负载挑战,我们当然希望软件尽可能的优化并能够接入更多的车辆,减少在硬件上的投资.但是当车辆增多到某一个临界点的时候,仍然要面临的三个问题: 1)连接的限制 服务器软件接入终端的连接数是有限的,无论如何优化,都是有限的,接入的增多就会排队,超时timeout重置reset等问题就会出现; 2)部标808服务器软件的内存限制的问题 内存的限制,服务器操作系统中一个进程所承受的内存是有限制的,超过则导致服务器软件进程内存溢出而退

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

总体来讲,GPS部标平台的软件开发是一个对网络通信和应用程序之间通信的技术应用密集型的开发工作,也是有一定设计技术含量的工作. 1.设计通信接口 在设计的时候,根据职责划分,拆分成不同的应用子系统,对各个子系统进行功能隔离,并通过设计接口规定子系统直接的调用规约. 首先我们根据部标平台的要求,设计和开发出各个主要的服务器子系统,这是平台中最核心的子系统,在实际的应用中,由于车辆规模的大小和行业需求,还会扩展出各种业务子系统.核心子系统如下: 1)808GPS服务器,采用交通部的部标808协议,负

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

原文地址:http://www.jt808.com/?p=1263 在开发部标监控平台的时候,我们要及时的将部标终端报警推送到web界面上,以弹窗的形式提供给用户显示,要将报警显示在界面上,部标808协议文档中规定的报警类型,如下图所示: 表 18     报警标准位定义 位 定义 处理说明 0 1:紧急报警,触动报警开关后触发 收到应答后清零 1 1:超速报警 标志维持至报警条件解除 2 1: 疲劳驾驶 标志维持至报警条件解除 3 1:预警 收到应答后清零 4 1:GNSS模块发生故障 标志维

原文地址:http://www.jt808.com/?p=1282 在开发一个大规模的部标GPS监控平台的时候,就算我们花费再多的时间设计和规划,我们也并不能准确的预测出自己未来的车载终端接入量有多大,而且一开始就为了我们宏伟的设计蓝图,投入大规模的服务器硬件设备和网络带宽,这会带来极高的成本投入,也会在早期造成大马拉小车,空耗+复杂度过高.所以大多数的平台一定是从一两台服务器搭建运营环境, 随着车载终端量级越来越大,并发越来越高,业务模式也越来越复杂,我们需要将程序解构,从一个模块拆出多个模块