(17353)

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

这是由于打铁需要自身硬，去过检的软件平台有很大一部分都是自己按照部标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购买。索要资料的是不会得到回应的，博客上已经提供了大量的技术文章，足够你决策是否购买，请阅读博客就够了。

(10279)

基于部标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

(24306)

如需代理部标过检请联系：2379423771@qq.com，注明购买过检服务，如无意购买，勿扰。

交通部796平台过检，是交通部要求物流车辆运输企业和GPS平台运营企业的一项交通部部标标准检测工作，是指各企业向交通部申请，将自己的平台送至通信信息中心，针对具体一系列标准，进行检测和审查的过程。平台通过交通部标准，即获得经营性资格，可以在指定范围内接入车载终端运营。

平台过检工作的前期准备工作千头万绪，很多公司的部标检测负责人着手开始这项工作时茫茫然不知所措，工作进展进度缓慢，其实交通部平台过检，我们需要把它作为一个复杂的项目来看待。既然是一个项目，就要做一个带有MileStone的项目计划，列出所需要准备的做的各项工作，确定时间节点和重大里程碑事件，这样就有一个清晰的方向指引着我们前进，不管有多复杂，有一个地图和指南针，我们始终知道自己所处的位置。

交通部检测流程说明

一、报名准备阶段

1、办理《电信增值业务许可证》

营运平台必须办理《电信增值业务许可证》。办理该证件周期较长，需立即开始办理。

2、选定IDC托管机房

选定独享10M电信IDC托管机房，获取唯一ip地址，和机房所在地详细地址。

机房应支持特定时间临时升级带宽至100M，应符合信息安全等级保护三级要求。。

3、购买服务器，服务器主要是对CPU和内存有要求，至少是双核，8G以上内存，一台服务器应该就够了，另一台做备机。

服务器：2台，预算：4-6万元

CPU类型： Intel 至强E5-2600

CPU频率： 2.5GHz

内存： 8G

4、提交检测申请材料

准备报名材料纸质版，交至中国交通通信信息中心，通过后领取平台编号，过标时使用该编号测试。具体材料包括：

表1 企业监控平台标准符合性检测申请函

表4 企业监控平台支撑软件清单

表5 平台硬件配置清单

表6 企业监控平台标准符合性检测登记表

表7 企业监控平台服务运输企业信息表

以上5个文档由加盖公章，骑缝章，准备检测。

5、部署运营平台软件环境

将服务器放入电信托管机房，技术人员相关人员在服务器上部署平台，保证平台稳定运行，在检测过程中，实时监控服务器的状态和日志，当检测遇到问题检测不通过时，提供日志，状态，查找问题，给出解决方案。

6、准备检测车辆

中国交通通信信息中心要求，所有待检平台，必须接入至少10台符合部标要求的车载终端，检测时必须确保至少10辆车同时在线，且同时有车速。

检测前，客户必须完成如下协调工作：

　　1. 至少2辆正常运行的车辆

　　2. 至少2台北斗部标终端机

　　3. 至少2个摄像头

　　4. 至少2张支持打电话，流量30M以上的手机卡

　　5. 检测过程中，至少2辆车必须同时在线且有车速。

7、符合性审查

需先提交电子版资料：

　　《符合性审查申请书-企业监控平台》

　　《电信增值业务许可证》复印件

　　《地图授权书》

　　《等级保护三级承诺书》

　　《企业平台详细信息》

　　《运输企业信息表》 

　　《企业法人营业执照、组织机构代码证、法人授权书、授权人身份证复印件》 　　

　　《部标平台检测合同书》 

电子版资料由客户提供，北京办事处提交至交通部符合性审查中心，电子版无误后，客户需提供纸质版，送至交通部审查中心。纸质文件包括：

　　《符合性审查申请书-企业监控平台》 每页公章、骑缝章

　　《电信增值业务许可证》复印件 公章

　　《地图授权书》 地图供应商提供

　　《等级保护三级承诺书》 公章

　　《企业平台详细信息》 公章

　　《运输企业信息表》 各运营公司的公章

　　资质审查通过后，就会在交通部网站进行公布，具体公布时间由交通部安排。

二、开始检测

1、压力测试

压力测试在一开始就开始测试，一直在稳定对服务器加压，并伴随着功能检测、协议、运行三个检测环节，最后算总账，发送包数量和接收包数量一致，确定过关。

2、部标796功能检测

该阶段检测工作主要检测受检平台是否具备《道路运输车辆卫星定位系统平台技术要求》（JT/T796‐2011）标准中对平台功能性的要求，主要实现平台功能完备性检测。本部分的检测需要检测人员与平台送检人员对送检平台的功能的逐一确认，并将检测结果如实记录。

平台功能，如地理位置监控功能、报警功能等所有功能是否全部能使用，而且全部符合部标要求。

注：功能复检阶段仍需要将此阶段重新检测一遍。

3、808协议检测

通过将被检平台嵌入模拟终端与上级平台之间实现三方的联通，并通过用例库实现逐条协议的组包与解析判定，并记录检测结果，形成记录文件。　检测中心提供测试工具，对平台检测。

4、运行检测

运行检测是通过将协议处理逻辑融会贯通起来，按业务逻辑的不同形成有机的整体，其中流程检测的核心是单业务逻辑的小循环检测，较少关注协议解析的数据内容，用以确保业务逻辑的一一正确性；运行检测的核心是整体性业务逻辑的大循环检测，并且依据解析出的数据内容进行整体性的判定。

5、功能复检

客户协调部分完全同796功能检测。

　　功能复检阶段，抽查796功能中的重点功能进行重新检测，并对《用户手册》和《技术方案》电子文档进行审核。电子文档审核完毕后，需制作纸质版《用户手册》和《技术方案》，封面采用凹凸感淡蓝色封面，正文部分双面打印，胶装成2本书，可由打印店负责制作，分别在封面、扉页、骑缝盖公章。寄给北京办事处。

6、压力测试

需提前通知机房，将带宽提升至100M。

　　通过模拟平台建立相应的模拟车辆，对申报平台进行车载终端的批量接入和运营测试，该测试主要影响对象为：平台的处理速度、网络设备的承载能力、网络的频带宽度。

　　1）模拟10000个车辆进行注册、鉴权后，发送GPS定位数据，发送频率为500条/秒，该部分检测时间为1小时；

　　2）模拟2000个车辆进行注册、鉴权后，发送GPS定位数据，发送频率为1000条/秒；

交通部部标平台功能说明，参见：交通部796部标平台开发索引

(14373)

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

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平台数据交换及转发服务器

(57247)

1.设计通信接口

在设计的时候，根据职责划分，拆分成不同的应用子系统，对各个子系统进行功能隔离，并通过设计接口规定子系统直接的调用规约。

首先我们根据部标平台的要求，设计和开发出各个主要的服务器子系统，这是平台中最核心的子系统，在实际的应用中，由于车辆规模的大小和行业需求，还会扩展出各种业务子系统。核心子系统如下：

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

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

3)809政府服务器，采用交通部的部标809协议，作为政府上级平台，负责与下级平台进行全双工通信。

4)GPS监控客户端，采用自定义的数据通信协议与服务器进行数据通信，为用户提供监控UI，各种监控功能都直接反映在此客户端上。交通部的部标检测和认证的所有工作，虽然涉及了平台的各个部分，但是检测的发起都是从客户端发起的，其他的子系统，我们统称为后台。需要购买部标平台源码的可以联系(2379423771@qq.com)

2.接下来，我们需要确定子系统直接的通信框架。

很多老牌的GPS程序员，对于Socekt特别熟悉，只要是通信，就设计协议，然后使用Socket框架，里面侵入了大量的业务逻辑。时间长了，代码非常难以维护。

现在开发技术的发展似乎与他们绝缘。连WebService都少用。更不用说瑞士军刀WCF框架了。这种面向字节的设计和开发，常常要重复编写大量的二进制字节转换，而现在我们更喜欢的是面向接口的设计和开发，底层的东西我们已经不需要考虑，通过简单的配置就可以快速的构建出两个应用程序之间的数据通信。采用WCF，可以让我们基本摆脱掉那些令人厌恶的Socket套路。

比如我们再808中，设计一个实时数据服务，RealDataService和接口IRealDataService，  编写一个获取实时数据的方法，通过WCF框架的配置，就可以快速的为其他子系统提供实时数据的推送和转发服务了。

而且，我们也可以通过配置，将WCF转换成JSON格式，这样手机查车等手机客户端引用也可以和服务器进行数据通信，获取数据。

3.全双工通信

  实际上子系统的通信基本全是全双工的通信，比如拍照的通信：809下级平台服务器收到上级平台的拍照指令后，将指令下发808服务器，808服务器再下发给终端，终端拍照应答给808服务器，808服务器再将拍照数据转发给809下级平台，809下级平台再将拍照数据转发给809上级平台。虽然我们描述流程的时候，仿佛是同步的，实际上网络通信是异步的全双工通信。可以看出部标要求的通信需求决定了子系统之间的通信的复杂性，而WCF的通信框架较好的隐藏掉底部通信的复杂性，满足顶层业务开发的需求。

4）部标流程检测和运行检测

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

(8840)

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

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

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

消息公布后，全国各地提供监控服务平台的企业开始按照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.符合性检测工作已完成，至此通过部标认证仅有一步之遥——符合性审查。

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

(14448)

也就是说凡是根据交通部这个标准开发的应用平台软件，都可以接入不同厂家开发的符合国标的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) 已下载 3701 次

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

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

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

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

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

(31024)