这次变化中,变化最大的就是809协议,基本完全不考虑兼容了,本来希望jt/t809-2019标准能够改变以往2011版晦涩难懂的风格,结果大失所望, 相比以往复杂度大幅增加, 更令人痛苦的是二义性,一段不准确的文字,可以有多种理解, 开发的时候痛苦无比, 但是为了过检,只能硬着头皮去开发, 其实我自己非常不喜欢在809协议上面浪费时间, 觉得人生非常的无趣, 由于晦涩难懂, 又没有解释说明, 完全是人为制造出来的泥沼,让人泥足深陷,开发效率非常低.

由于809协议需要上级平台做测试,否则不知道对错, 所以不得已又回头先开发809-2019版本的上级平台模拟服务器,用来模拟政府运管平台, 这个又花费了好多时间才搞完. 这个是开发之前没有想到的.

一直到9月份开发完毕,10月份一整月都在过检, 10月底终于通过.真是红军过草地走出沼泽地的感觉, 人生好无趣! 虽然过检通过,但心绪难平,希望分享一些新标准的变化,提供有偿的过检咨询服务或购买完整的新标准平台源码. 如需购买部标2019标准源码请联系2379423771, 套资料的勿扰, 我是开发人员不是销售.

部标809协议2019版本与2011版本的变化差异总结如下:

(9731)

796平台检测和1077平台，如果是不同的平台，架构必须要一致，796是BS网页版本的，则1077视频平台也必须要是BS网页版本的，不能是CS桌面版本的。 由于很多厂商老旧的视频平台都是桌面客户端程序，不是真正意义的BS网页版本的程序，所以不得不做成假的BS程序，通过ActiveX控件，只能使用低版本的IE7,8，9等，依赖IE减低安全等级设置。所以如果是开发平台，最好是一步到位选择真正的BS网页架构版本的平台。 

BS版本架构的部标1077视频平台参见：

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

2、基于JT/T 1078协议设计和开发部标视频服务器

视频平台检测的主要难点是压力测试，主要的流程如下： 

相对于796平台检测的压测的主要区别是：

1.gps压测相对于796多了1000台，压测结果是对比发送的和接收的是否一致，一条也不能少；

2.gps压测通过后，3000台车保持在线，但停止发送定位，开始视频200辆车压测；

3.视频压测的时候，200路的视频连接和对应的200路上级监管平台的转发连接都保持稳定后才开始统计码流；

如果不够200路，压测直接就失败了，因为没有码流统计数字，无法统计结果；

4.200路转发成功后，任意选择一路播放视频，如果有黑屏，卡顿或者无法打开播放的情况，则视为失败；

5.视频播放的时候如果声音不连续也不行，这也说明了卡顿；

6.测试卡顿使用的视频，是一个座钟秒针转动的画面，如果有卡顿，秒针走的时候也会一顿一顿，很明显能够看出来。如果有丢包或者跳帧，则秒针就会时快时慢，或者跳跃前进。

7.测试30分钟，然后统计终端发送的码流，和上级监管平台接收的码流，两者的数字相加要大于11M。视为压测通过。

8.统计结束后，截屏上传到检测系统当中，生成压测报告。

压测的时候，对于带宽的要求显然要高于796平台的检测要求。

播放视频的时候，播放的那一路最好不要断开连接，否则容易出现卡顿或者黑屏的情况；

交通部测试终端的出口带宽感觉在100M一下，在家里做测的时候，用10M带宽对100M服务器测试的时候，2分钟3000个连接都建立了。在交通部测试的时候，需要3,4分钟才建立完毕。

码流统计标准，之所以设计为11M，估计是一个经验值，200路如果每一路都保证画面播放流畅，则码流必须要良好才行。进而累计200路的码流值必须要是一个合理的数字。

总之要想过检，压测是重中之重，必须要认真对待。

视频平台的检测难度无论从功能细节上面还是压测强度方面，都是要高于GPS平台检测的，本平台已经通过部标1077视频平台检测，提供有偿收费检测服务，如需购买源码或购买代理过检服务，请加QQ：2379423771，注明购买源码或购买部标过检服务；我不是销售，作为一个忙碌的开发人员哪里有时间在网上瞎扯淡，目前只针对真正想降低成本，提高效率，诚意购买的人提供服务。

压力测试结果后，会打印压测数据结果，存档备案，压测结果如下图所示：

我是提供源码的，少走弯路，降低成本对公司是好事情，光明正大的给公司申请下有什么不好，自己开发，无论你多牛逼，你都绕不过漫长的开发周期和测试稳定周期，公司也必须要承担长周期带来的不可预估的失败风险和高昂的开发成本，只有血气方刚没经验的新手才会给自己或者公司挖坑，要么没有时间观念无所作为每天荒废于互联网搜索免费资源当中，要么设定激进的开发进度计划和交付时间点，给自己以极大压力。时间是后知后觉者的高昂的成本，也是市场先行者构筑竞争的砝码和壁垒，购买源码，在短时间就拥有了视频平台开发技术，瞬间有一个较高的起点才是上上之策。

很多团队为什么宁愿让公司置于项目不断延期的风险之中，就在很多负责人都是技术人员出身，过于理性，做事思虑过多，瞻前而顾后，多谋而不善断，格局太小，只关注局部的成本开支，不以完成交付为第一目标，不重视项目高效推进落实，听不得收费服务，一听到要收费就痛苦的不得了，自己都不想想自己一个月多少工资成本，自己团队一个月多少工资成本，随便一个项目，几个月都难以交付，其实作为每个月要支持高昂开发成本的软件公司，在开发上是不能慢下来的，必须要杀伐决断，立即行动。我提供的平台代码和技术支持可以让技术团队快速聚焦，不再东一榔头西一棒槌，而是脚踏实地，拧成一股绳向前推进。

(17063)

(17326)

为什么去检测的软件平台非常不顺呢？

这是由于打铁需要自身硬，去过检的软件平台有很大一部分都是自己按照部标808协议和809协议新开发出来的GPS软件平台，本身就一堆毛病，没有给大量用户用过，也没有经过时间的考验。内部测试是不可能代替用户各种长时间使用的。由于按照部标协议完整开发的GPS软件平台开发周期都是在一年多以上（为什么大家愿意自己开发，就是因为不相信会花费这么长时间，开发完回头一看二年都过去了），已经耗尽了领导的耐心，按照计划，早该去过检测了，成为一个通过认证的部标平台是一个商务性质的，是需要配合市场竞争要求的，不可能在那里像温水煮青蛙一样慢慢搞的，所以很多平台都是迫于时间压力，仓促迎战。部标平台开发参加：交通部796部标平台开发索引

如何才能快速的过检呢，很多事情都是前车之鉴，部标2011年推出，到现在已经四年，翻一翻部标过检名单，已经过了万余家，别人已经走过的弯路，你还在那里用人民币铺路，使蛮劲吭哧吭哧的走，是不是有点滑稽，缺乏智慧。过检完全是一个经验主义的事情，你的能力再大，也不可能在一年内开发出一个部标平台并过检，前面有没有坑，和你的能力智商及公司团队的实力一毛钱关系都没有，要花时间和精力走过去才知道。如果能够给过检的企业提供专业全面的指导，从部标808和809协议测试、部标796功能测试、运行测试和压力测试，各个环节，在过检前，就填掉大坑，到北京再去过检测，就是直通车了，避免头撞南墙起大包后再修改，无疑是极大的提高检测效率，节省一大笔支出。

 部标1077视频平台过检和压力测试经验分享

好的消息是从2017年，基本上繁琐的商务资质已经不需要了，特别是机房安全等级证书不要了，也可以用百度高德地图了。过检的成本大大降低了，参见：交通运输部办公厅关于印发《道路运输车辆卫星定位系统车载终端和平台标准符合性技术审查工作规范》的通知

从2012年，我们帮助几十家客户顺利过检，最重要的是直接给客户提供最新的、符合主流技术团队要求的源码，我们的C#和Java源码都有很多客户过检，在过检后帮助他们二次开发，顺利的和他们的业务衔接在一起。我们给企业客户提供三种服务：

1.检测指导服务，如果你已经开发了自己的GPS平台，但是对去北京检测没有信心，我们为你提供专业的检测指导服务，从部标808和809协议测试、部标796功能测试、运行测试和压力测试，我们整理了详细的检测用例，和检测工具，帮助你完善自己的平台，符合交通部部标平台的要求，对于不符合压测的，我们也会帮助你优化平台，提高平台的性能。标准的实施就像你的公司要通过ISO9001认证一样，实施人员检查你的各项流程和输出文档，告你那个地方如何调整，你整改就是了，最后肯定符合标准。

此服务是收费服务，只是想套点资料或信息的人就不要加我了，如果真心希望快速过检，节省过检成本的愿意付费的有诚意的客户请加我QQ 2379423771，加QQ时注明购买过检服务。

本平台已经通过部标796GPS平台检测和部标1077视频平台检测，购买时请注明是购买部标1077视频平台检测服务还是部标796平台检测服务，或者两者都要购买。

部标检测流程参见：交通部部标监控平台检测

2.也可以直接购买我们的已经过检的部标平台Java版或者.NET版平台源码，直接过检。即节省了开发费用，又节省了检测费用和人工差旅成本。

        Java平台，参见：基于Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架构建高性能企业级的部标1077视频和GPS监控平台

          .NET平台，参见：基于Asp.NET MVC构建部标1077视频和GPS部标平台

3.北京代理过检，如果你已经准备好了平台和商务资质，我们可以在北京替你过检。

如果企业客户有需要可以联系2379423771@qq.com购买。索要资料的是不会得到回应的，博客上已经提供了大量的技术文章，足够你决策是否购买，请阅读博客就够了。

(10243)

基于部标809协议的转发服务器源码开发，参见》》基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器.

2019年开始过检的标准已经发生重大变更, 参见下列文章:

1) 部标809协议2019版本与2011版本的区别

2) 交通部部标平台过检认证(六)-如何快速的通过交通部过检

3)  部标的过检与认证系列文章

如需开发web平台，参见：基于部标Jt/T809协议和Java Netty框架构建Gps位置监控平台

按照交通部信息中心的测试收费标准，平台检测费用45000元。不通过复检4500元/次，也就是说，不通过，过两次后再找人家测试，每次都要收费，这个不像自己家里的测试部门，退回来的费用成本和时间成本很高。所以要想提高成功率，必须要有模拟的上级平台，必须要吃透809协议文档，测能写出像样的测试用例，只有用检测工具或者严格的测试用例进行测试，平台对接测试才比较靠谱一点。

交通部的测试的时候，是一个专门的可视化的测试工具软件，每一项通过和不通过，都会有显示和统计报告。这个工具软件交通部是不提供的，如果提供了大家的通过率就提高了。但是我们可以按照这个思路自己开发一个模拟平台，如下图所示：

如需购买部标检测工具（808模拟终端、809检测工具、压测工具三合一），请联系：2379423771@qq.com

同时我们还需要知道交通部过检测的时候，在809协议上测试的内容和流程是什么，它不仅是一个一个单一的命令测试，同时还是一个一环套一环的流程测试。

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

由于808GPS服务器和809服务器是需要集成通信的，你可以购买808809服务器模块套装源码(2700元），提高你的开发效率。

开发环境JDK1.7+, 数据库环境MySQL5.7, MSSqlServer2005+，运行环境windows, linux

(24266)

客户端设计面临两个问题：

1.基于CS还是基于BS，这是个问题

      萝卜白菜各有所爱，客户要什么，我们就开发什么，从客户来讲，更适应桌面客户端，没有浏览器的七七八八问题，速度感觉上也比网页的快，操作方便。当然网页客户端也有很大的优势(网页客户端设计，参见:基于Asp.NET MVC构建GPS部标平台)，部署和维护方便，不需要开发升级系统。

2.与服务端的交互通信，采用Socket, WebService还是WCF，这也是个问题

     WebService的性能很差，这个基本上不考虑，Socket效率高，但开发效率低，难以维护，WCF是面向服务(Service Oriented)应用程序的统一框架，非常灵活，它可以跨进程、跨机器、跨子网、企业网乃至于 Internet；以宿主程序而论，可以以ASP.NET，EXE，WPF，Windows Forms，NT Service，COM+作为宿主(Host)。WCF可以支持的协议包括TCP，HTTP，跨进程以及自定义。

     所以采用WCF框架，将传统的GPS软件转向了面向服务的GPS平台。通常我们在服务端，采用windows服务作为WCF的服务端宿主，采用tcp/ip协议作为传输协议，使得远距离互联网数据传输的性能大大提高，桌面客户端采用windows forms 作为wcf 客户端的宿主。客户端通信设计，参见：基于WCF的GPS平台数据通信设计

确定了两个问题后，开始确定两个设计：

1.服务端接口设计

  面向服务开发，首先就要确定服务端为客户端提供什么样的服务，比如报警推送服务，报表分页查询服务，实时数据推送服务，基础数据服务，终端命令服务等。

2.客户端功能和界面设计

  客户端的功能和服务端的接口是相辅相成的，功能的设计业决定了界面如何设计。

可以说部标平台的复杂性在于交互的复杂性，很多人对于开发的乐观，是因为在开发初期，无法清晰的看出具体的交互设计，更不能明确的估算工作量，由于交互，客户端的设计和服务端的设计是互相影响的，客户端增加一个功能，往往面临着服务端、通信端的功能逻辑的改变，虽然我们竭力从设计上采用面向服务的设计、面向对象的开发，仍然避免不了这种交互带来的互相影响和工作量的增加、测试难度的增加。购买部标平台源码联系2379423771@qq.com。

Java平台，参见：基于Struts+Spring+Hibernate+Ibatis+Quartz+Mina框架构建部标监控平台

.NET平台，参见：基于Asp.NET MVC构建GPS部标平台

   GPS软件界面设计，参见：GIS、GPS和视频监控界面设计

下面着重说下功能设计。

功能模块主要包括：

1.地图操作

    主要包含了拉框放大、缩小、测距、电子围栏、标注、历史轨迹、区域查车等功能，当然了还有些依赖于地图的附加功能。

    我们采用基于GMap.NET SDK来作为地图引擎，可以灵活的采用和切换谷歌地图、高德地图等，采用local cache的模式，浏览过的地图图片将会被存储在本地硬盘当中，提升了用户浏览地图的用户体验。GMap.NET具体开发参见:GMap.NET二次开发

   对于地图的电子围栏坐标，我们采用地图算法库，直接转换为原生的GPS坐标，存入数据库中，这样便于电子围栏算法模块的判断和分析。

2.终端命令下发

    包含了部标808标准中所要求的所有的指令下发功能，以可视化的形式提供给用户操作。

    终端命令很多，大部分是用户不常用或不需要的功能，但又是必须的，或者是部标过检必须的，所以设计时，需要要考虑权限功能限制的可伸缩的功能布局。

    终端命令下发的用户体验设计也是比较有难度的，从命令下发、服务器执行下发给终端、终端执行后应答、数据上传最后反馈到客户端界面，是个时间未知的异步过程，必须要设计一个超时跟踪的定时器跟踪命令状态，来给用户一种同步的命令执行的感觉，在点击按钮后，可以跟踪到命令执行的最终状态。

3.报表查询

部标中规定的所有的报表都需要显示在客户端，提供各种组合查询条件，当然了像BS网页客户端一样，也需要考虑分页查询和报表导出。

4.数据管理

平台所需要的用户、角色、权限分配、基础数据管理、车辆、车组、业户的管理、参数设置这些增删改查的功能，也必须要做入到客户端中；

5.报警推送

报警定义、报警推送、报警处理、报警弹窗声音地图展示的功能。

6.实时数据

实时数据的推送、状态刷新、地图显示等功能

7.图表

各种统计报表以柱状图、曲线等图表的形式显示出来，比如上线率统计、车速曲线图、油耗曲线图等。

8.运管平台对接

     平台能够响应政府平台基于交通部部标809协议下发的岗位巡检指令，上报到政府平台。平台在收到车辆上报动态位置信息后，即刻向政府平台实时上报车辆的位置、状态信息和报警信息，响应政府平台对车辆的拍照和监听等车辆远程控制指令，并显示政府平台下发信息。809的开发，参见：基于JT/T 809-2011的(已过检)GPS平台数据交换及转发服务器

(57215)

1.对于压力测试的具体指标要求理解含糊，只知道是模拟一万辆车终端进行数据包传输，不知道具体的检测标准是那些指标，等进京考试后落榜了，才知道部标过检的压力测试失败了，这个时候，还要通知后方的同志改进，耽误的时间和差旅费用成本惊人。很多检测人员需要在京住上几十天，算算得多少钱。因为不知道方向，所以改进也是盲目改进，不知道行不行，应付任务再次送检，也是摇骰子，祈求上天让我们通过吧。

2.不知道怎么检测，杀猪杀尾巴各有各的杀法，大家轮番发明各种检测方法，结果和交通部检测中心的检测方法不一样，看着测试人员盲目测试测的满头大汗，只是给领导装样子，效果还是和没测试一个样子。

3.根本就不清楚影响压力测试的各个因素，只知道改进某一个因素，而不知道影响压力测试效果的是各个因素的组合结果。

要解决这个问题，必须要有针对性的进行压力测试：

1.知道压力测试的硬性指标是什么，然后想办法模拟测试，达到这样的指标。

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

      检测期间在任意机器中发现任何连接的主动、被动关闭，均停止检测。

      GPS发送频率达不到标准要求，也停止检测。

      客户端显示的GPS时间与本机时间误差超过5秒，也视为压测失败。

2.了解影响压力测试的各个因素，把它罗列出来，一一进行整改，比如机房网络带宽、服务器性能、数据库性能、操作系统、808GPS服务器；比如你的网络不好，10M独享的网络，1万台连接涌入的时候，还没到服务器的处理瓶颈，自己就超时断开了。数据库的企业版和简体版的性能差别也很大。

3.要想改进优化你的808GPS服务器性能，就必须能跟踪服务器的状态，你的808GPS服务器必须增加一个功能，那就是GPS服务器性能监控，至少能跟踪出你服务器目前所能承受的最大并发，你的GPS服务器的入库速度，报警分析是否有延迟，在压力瓶颈下，出现的各种错误日志。压测工具发了多少个包，服务器收到多少的包，丢了多少个包，有多少个连接断开。这样你才能改进，否则就是东改改，西改改，没有方向。

4.模拟出交通部检测一样的环境，比如你的平台部署在南方电信机房，交通部的测试电脑的网络环境是北方联通，这个就抓瞎了，所以你的服务器的机房，怎么也得是个一样的网络，或者是双线机房。

5.使用专业的部标测试工具，进行测试，这样就和检测中心保持一致了。

6.基于高性能的socket框架，来开发自己的部标808GPS服务器，参见：基于部标JT/T 808协议及数据格式的GPS服务器

压力测试方案提供-GPS产品经理-2379423771@qq.com

(13136)

可以说这个标志对于GPS行业格局有很大的影响，如果通不过检测，或者赶不上第一波，意味着市场就要丢掉或者失掉先机，在宣传上也低人一等。因为GPS监控和视频安防一样，都是政府主导行为，而不是市场行为，如果没有政府的招标和补贴，物流企业可能不会齐刷刷的安装Gps设备，购买GPS平台软件或服务，那么GPS生产商服务商要死掉大半。

JT/T808企业监控平台符合性审查资料 已下载 2283 次

JT/T808系统平台功能检测要求 已下载 2307 次

消息公布后，全国各地提供监控服务平台的企业开始按照JT/T794-2011，JT/T808和JT/T809的要求（参见：JTT808、809、796标准大全）改进自己的车载终端和监控平台，并陆续交通通信信息中心，进行各项检测。表面上看来交通部的部标检测只是对被检企业的技术考核，其实是对企业研发能力，运营服务水平和企业战略眼光的全方位检验。。交通部制定的这套标准的确是一套高标准的行业规范。不仅仅是对技术细节的规定，更能通过对技术的考核进一步检验一个企业的综合能力。所以要吃透协议是第一步，808、809协议开发参见此文章,还要开发模拟终端的808、809测试程序，进行充分的内部测试，这样送检的一次通过率概率更高些，否则每次送检的费用都不菲，再加上差旅费用，小企业是吃不消的。最好使用交通部信息中心使用的标准的检测软件，在送检前进行测试。检测软件的使用参见：交通部部标检测软件使用说明。

物流平台运营企业必须严格遵照交通部制定的这三套标准来改进现有终端和运营平台。并且在做好准备工作后，需要到北京交通通信信息中心进行检测，通过部标认证。很多物流企业都第一时间跑到交通信息中心了解部标认证详细信息，和交通信息中心、上庄卫星地面检测站站(通信信息中心安排的具体检测地点)等部门工作人员的沟通，回家后制定部标认证的规划，并展开具体工作。当然开发一个符合部标检测标准的GPS平台，周期是很长的，往往超出预计时间很多，不是吹牛逼说大话就行了，毕竟最后是骡子是马，是要进京赶考的，通过还是不通过，交通部检测中心说了算，不是可以像传统软件验收那样，和客户协商妥协就行的。很多人理解的太单纯，就是因为传统的软件开发思维在作怪，认为功能差不多就行了。这样的思维会让你前面有很多坑在等着你。如何开发交通部GPS部标平台，参见GPS部标平台架构设计

根据交通通信信息中心的要求，受检平台的符合性审查分为两部分：符合性检测和符合性审查。符合性检测即技术检测，根据要求分为五个部分：功能检测，协议检测，流程检测，运行检测和压力检测。功能检测即检测运营平台所提供的管理服务功能是否完善，合理。根据交通部相关文要求，受检平台必须具备车辆监控管理，历史轨迹回放，平台对接能力等近百项服务功能，这些功能涵盖了目前所有监控平台的最优服务功能，可以按要求完成平台无疑将会是国内服务性能最优异的运营平台，也会是可以客户提供最合理，最完善，最人性化的全方位运营服务平台。

1.协议检测。协议检测分为808检测和809检测，808检测是检验受检平台与车载终端之间是否严格按照JT808通信协议来进行通信的，这一检测保证了受检平台以后可以无需任何改动，直接接入符合交通部JT/T794-2011标准的部标车载终端，并且具备完整的双向通信功能。809检测是检验运营平台是否安装JT809通信协议来开发平台对接接口。经过809检测的平台可以无缝隙，零差错，不需任何改动直接接入全国各地的联网联控平台，最终将平台所有车辆接入全国重点营运车辆联网联控系统。并且可以和所有符合809协议的其他任何平台进行准确无误的数据交换。后来因为参考各个厂家需求意见，又增补了808和809的补充协议。

2.通过了功能检测和808协议检测后，还需要通过了流程检测。流程检测和运行检测是保证受检平台在实际接入全国联网联控平台和进行实际数据交换时符合交通部要求，这两项检测充分保证被检平台在实际运行中的稳定和可靠。并且可以保证在没有人工干预的情况下，平台可以自动处理通信异常，数据补传，报警提醒和平台命令转发的数十项功能。

3.压力检测。

压力检测是符合性检测的最后一项功能，但也是要求最高，通过率最低的一项功能。根据标准，检测分为两个环节，2000测试和10000测试。2000测试，即检测方会在5分钟之内给受检平台接入2000台部标终端，同时完成终端注册与鉴权功能。之后，每台终端会以200毫秒一条数据的频率给受检平台发数据，持续时间不少于30分钟。这期间不允许丢失一条数据，断开一个连接，并且最终会对受检平台接收到的数据进行抽样检查，不能有任何数据失真或丢失。2000检测通过后受检平台才有资格进行10000检测，10000时接入的车载终端数将增至10000台，重复2000时的过程，并且检测时间延长至60分钟。同样不能有任何数据丢失或失真，不能断开一个连接。很多企业由于没有自己内测充分，匆忙送检，在压力测试中由于出现连接断开而失败.

4.符合性检测工作已完成，至此通过部标认证仅有一步之遥——符合性审查。

符合性审查主要是对运营企业的资质和运营能力的审查。运营企业不仅需要提供资自己的所有的资质证明还要同时提过其所服务的运输企业的相关资料，对于这些资料的搜集整理，无疑是对企业执行力的又一次检验。需要收集平台的运输企业客户资料。

(14365)

也就是说凡是根据交通部这个标准开发的应用平台软件，都可以接入不同厂家开发的符合国标的GPS设备发送的上传数据。因为协议是同一的，所以平台也可以将数据转发给各地的省级交通部门的运管中心。

目前国家对需要上路的客车、危险品运输车，简称两客一危，要求必须要安装符合国标的GPS，如果运输承运者没有自己的软件平台，可以使用运管局的客户端软件，并接入到运管中心进行监控，收费对于企业来说也是个负担。现在国家对与GPS终端设备的标准又进行了进一步的扩展，要求必须要加上指纹等身份识别的读卡器，强制性加，费用不低。

平台软件开发商和GPS设备开发商安装标准开发后，需要通过交通部的部标检测和认证，获得部标认证后，这样才可以参加各地的软硬件招标。交通部对平台的功能测试，主要是模拟GPS终端发送标准的协议数据，然后测试是否能正确的接收数据。

交通部796平台的功能要求，参考：GPS部标监控平台的功能设计(一)-功能列表

GPS应用的开发者必须要了解并掌握这些协议，平台协议主要JT/TB808、809及扩展补充协议，同时协议中对于行车记录仪部分又应用了部颁的GB19056标准，所以这些都要看，JT/T796主要是硬件设备的标准，可以参考。

1)808GPS服务器，采用交通部的部标808协议，负责与终端的数据接收、指令下发; 参见：基于部标JT/T 808协议及数据格式的GPS服务器

2)809转发服务器，采用交通部的部标809协议，作为企业下级平台，负责转发GPS数据到政府平台的服务器;参见:基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器

我们开发了一个支持JT/T808-2011数据格式的健壮的GPS服务器，提供试用版下载，试用版不支持转发和数据库存储。数据库版本支持Mysql, Sqlserver和Oracle等关系数据库，可以直接拿来做服务器连接前段GPS客户端和报表开发。需要源码的可以联系我。

交通部JT808协议GPS数据Socket服务器 已下载 4360 次

道路运输车辆卫星定位系统--协议补充(JT T808、809) 已下载 3671 次

JTT 808-2011 道路运输车辆卫星定位系统终端通讯协议及数据格式 已下载 3901 次

JT／T796-2011道路运输车辆卫星定位系统平台技术要求 已下载 3289 次

道路运输车辆卫星定位系统--平台数据交换(JT T809-2011) 已下载 3433 次

行车记录仪标准GB19056 已下载 3206 次

行车记录仪标准GB19056 硬件参数标准 已下载 2600 次

(30924)