(17414)

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

(24357)

如需代理部标过检请联系：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部标平台开发索引

(14399)

    1）首先对于交通部部标标准文档的阅读、理解和消化需要很长时间，你面对的是冷冰冰的交通部信息中心颁发的jt/t 796、808、809协议文档，面对文字的歧义，这个消化、曲解、走弯路的时间成本，伴随在整个软件开发周期当中，一直到你进京赶考，进行部标检测，最终过检。所以这个时间是无法估计的，理解完毕，将理解的文档转化成开发团队必须要完成的功能用例，中间的误差极大，这也是很多开发者容易自信、乐观冒进的原因。

         你必须需要阅读和理解的协议文档有四份： 796文档、808协议文档、809协议文档、GB19056文档。参见-》交通部道路运输车辆卫星定位系统部标JTT808、809、796标准大全

    2）对于标准的严酷性准备不足，正常自己公司开发一个系统，功能标准是自己的写的，差不多，八九不离十就行了。很多开发者用这种习惯开发部标平台，很多功能看似都是八九不离十，结果到最后，结局就是通不过。在检测中心，检测人员进行检测主要是依靠检测工具和检测用例文档，特别是测试用例文档，比自己公司测试部门写的黑盒测试用例都写的细致和充分，可惜你看不到这个文档，开发人员就像一个瞎子不断的拿着自己脑袋硬碰才找到门在那里。

   3）联调难度大

    考不容易开发出来一个东西，需要测试，从客户端到服务器再到gps终端这样一个双向联调测试，服务器有服务器的问题，客户端有客户端的问题，网络通讯有网络通讯的问题，合在在一起联调，就像一群坏孩子集中在一个班里，乱成一锅粥了。由于互相影响，耽误的时间都是叠加在一起的，而不是并行开发所能解决的了得。

  4）前面问题，是部标平台开发不同于常规的信息化软件开发之处，这些不同之处加大或者恶化了计划失真的问题，就是无知者无畏，容易乐观、轻视、冒进、准备不足，反而更容易拖延整个开发交付的周期。我增经见过一个最激进的部标监控平台的开发计划，整个平台计划50多天完成，设计一周时间，部标808gps服务器一个月完成，web客户端20多天就要完成，809运管平台接入10多天就完成，留给测试的时间就5天。当时我就震惊了。估计是领导根据市场情况强加的，这简直是要人命的。项目经理很据领导或自己的意志写项目计划，反正计划归计划，让写几天就写几天吧，到时间完不成，就继续延期呗，难不成还开除不成？

5)  企业在运作过程中，刻舟求剑的静态思维往往低估软件项目开发的复杂性，待到项目开发周期超出原来的乐观估计的时候，往往温水煮青蛙，原来的3个月变成6个月，6个月变成年底，年底变成过完春节，这个时候进退两难，停止开发又难以交代，继续开发，还要继续投入成本。企业的目的并不是为了要开发一款软件产品，而是要用这款软件产品进行运营或者做某种业务，但是往往软件还没开发完，已经元气大伤，后面的事情就不用说了，就算开发出来，十几个月都过去了，黄花菜都凉了。

2.如何快速开发部标监控平台？

   坦白的说，就是购买我的源码，进而获得我的技术支持和经验，少走弯路。有两个路径可以走：

  1）结合自己团队的情况，购买我的部标808GPS服务器、部标809GPS服务器源码，大幅缩短自己在协议理解、开发、性能调试上的时间，在此基础上集中精力开发网页客户端或者CS客户端。极大减轻的进度压力，毕竟没有谁愿意顶着压力做事，从从容容得做事，是一件很幸福的事情，对于公司来讲，也会节省掉几个月的开发费用支出。当然转变思维也不是件容易的事，虽然花的是公司的钱，但是省得也是公司的钱。

  2）购买完整部标平台的源码（包含部标808服务器、809服务器、网页客户端和安卓客户端）

  公司或团队购买后，直接过检或者在此基础上，集中精力开发有行业竞争力的差异化客户需求功能，开发周期从以前的一年多的时间缩短为一个月的时间，一年多的开发费用是多少，会数学应该能算出来，划不划算，更应该能算清楚。

3.开发文章索引

   1）C#版的808GPS服务器开发-》基于部标JT/T 808协议及数据格式的GPS服务器

   2）Java版的808GPS服务器开发-》基于Java Mina框架的部标808服务器设计和开发

   3）C#版的809GPS服务器开发-》基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器

   4）Java版的809GPS服务器开发-》基于Java Mina 通信框架的JT/T809转发服务器设计

   5）Asp.NET版的部标平台开发-》基于Asp.NET MVC构建GPS部标平台

   6）Java版的部标平台开发-》基于Struts+Spring+Hibernate+Ibatis+Quartz+Mina框架构建部标监控平台

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

   8）基于C# winform桌面客户端的部标平台开发-》GPS监控客户端设计

   9）地图纠偏加篇算法-》地图服务算法库

  10）手机客户端-》Android手机客户端和手机查车设计

   11)部标检测-》交通部部标监控平台检测

(12089)

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

依据上述要求，对于企业平台的压力检测采用TCP方式进行，分为两个部分进行；动态目标压力为检测和定位数据压力检测。

如何开发高性能的部标监控平台的GPS服务器，参见：基于部标JT/T 808协议及数据格式的GPS服务器.

需要购买高性能的gps服务器源码可以联系：2379423771@qq.com

二、检测要求

首先进行动态目标压力检测，主要对企业平台的动态目标监控能力进行检测，检测方法为，模拟10000个车辆按照jt/t808协议，进行注册、鉴权后，发送GPS定位数据，发送数据频率为500条/秒，该部分检测时间为1小时。

然后进行定位数据压力检测，主要对企业平台对海量定位数据的处理能力进行检测，检测方法为，模拟2000个车辆进行注册、鉴权，发送GPS定位数据。发送数据频率为1000条/秒，以达到标准中峰值1000条/秒的性能要求。该部分检测时间为15至30分钟。考虑到检测机器的性能，将发送频率实际设置为200条/200毫秒。

四、压力检测步骤

4.1 检测软件的使用

    打开企业平台压力测试软件，点击“设置”→“参数设置”，如下图：

之后弹出如下对话框：

    将被测平台的IP地址以及端口正确填入更改车牌号及终端手机号信息，点击确定。

软件界面输入用户名（admin）以及密码（admin），点击“登录”

    在如上图的待测平台下拉列表中随意选择一个（被测平台的IP、端口信息已经在之前的步骤中写好，这里选择的检测平台不会对其存在任何影响），然后点击确定。

    然后点击“开始”按钮，开始压力测试。

    在测试过程中可随时在下方的日志查看当前的连接以及GPS数据发送情况。

    点击“打印”可在“…\Release\Report\”目录下生成压力测试报告的EXCEL文档。请注意，在每次打印文件后，需将文件进行重命名并妥善保存，以免造成无法恢复的文件覆盖。

4.2 检测流程

考虑到检测机器的性能。

第一个环节的检测分为三台机器同时运行压力检测软件，分别模拟3333辆、3333辆、3334辆，共计10000辆车对待测平台进行压力检测。设置发送数据频率为500条/秒，检测时间为1小时，需要检测链接建立线程时间都小于10分钟。

第二个环节的检测在单台机器上进行，检测2000辆车，设置发送数据频率为1000条/秒，检测时间为15至30分钟，其中全部检测建立链接的时间小于5分钟。

其中，考虑到时间以及鉴权情况，注册、鉴权发送时间间隔为1秒。

需要注意的是，为了保证检测的发送    ，检测软件在鉴权

首先发送注销，接收到通用应答后，再发送注册请求。

4.3 抽样对比

检测接收后，对每个环节下的数据均需抽样比对，取样如下：

对上述取样进行比对，每个部分结束后均需进行（产生主动、被关闭的除外），每一对比对结果均保存截图备查。

4.4 结果判定

在检测即将结束时手动查看链接总数，若模拟车机仍未全部链接完成，判定检测平台不通过压力检测。

在检测即将结束时手动查看发送GPS数据的频率，若GPS数据发送的频率仍然不到当前部分的频率；第一部分500条每秒（即每台机器167条每秒），第二部分1000条每秒，判定监控平台不通过压力检测。

检测期间在任意机器中发现任何连接的主动、被动关闭，均应全部停止检测，等待至少两分钟后，进行第二次检测，若在检测过程中再次出现主动或关闭，随机选择一台压力检测机器tracert指令。当有本机返回域名bjtrlecom.net访问时间小于500ms时，可直接判定检测平台不通过压力检测，保存当前检测报告，并对软件打印界面截图；否则，立即停止当前的全部压力检测，检测时间另行通知。

五、结果判定

压力检测进行时允许送检单位不安排人员至检测现场，而采用远程配合的方式，但需在检测正式开始前至少1个工作日提交“检测声明”，否则不予安排检测。

不论现场检测与远程配合检测，均需按要求提供真实有效的检测。

名词释义：

    主动关闭：指由于注册、鉴权不成功等而导致的检测软件主动关闭该连接，重新建立其它连接而造成的连接断开。

被动关闭：指由于被检平台由于连接等待超时等原因而造成的连接断开。

(8046)

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转发服务器的指令的数据包监控。

(8876)

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

(13184)

这种观点造成了业界内，很多GPS系统粗制滥造，不堪大用。

事实上，设计和开发一个GPS平台往往耗费数年时间，虽然这不是客户和领导所期望的，但是往往都摆脱不了三年周期的宿命：

第一年满足基本需求能够稳定下来已经很不错，

第二年增加差异化、个性化、有市场竞争力的功能，让平台功能壮大，提升用户体验；

第三年随着功能的堆砌，数据量的增大，接入车辆的增多，需要对平台进行较大规模的重构，使之满足可扩展性的要求，同时优化、提高性能，满足大规模车辆接入的要求。平台进入成熟阶段。

为什么设计和开发一个GPS平台需要这么长的周期？其实这些本来是很正常的，把事情搞砸，其实都源自于我们对美好事物的期望。

1）我们一开始想的太简单，规划的太粗糙，计划太激进，细节太少，造成后期面多了加水，水多了加面的狼狈。

2）或者一开始我们想的太复杂，过度设计，规划了很多或者意淫了很多莫须有的设计或者功能，开发难度加大，做出来的东西，有内涵，但用户体验差，错误多，不稳定。造成平台交付是个慢慢熊途。

所以，购买一个稳定已过检的部标平台，是一个明智的选择,(本人提供全套源码，需要购买者联系2379423771@qq.com)

随着交通部796部标平台标准的公布，帮助我们开始对部标平台由了一个较统一的，或者是叫清晰的认识，同时越来越多的GPS软件厂商，需要获取到796平台的认证，这样才能在政府和国企的车载设备和软件平台采购项目中获得投标资格，或者是获取到地方市场准入的资格。

很多人把部标平台看成一个门槛，由于过检费用成本很高，迟迟下定不了决心，但是部标平台不仅仅是个门槛，那只是第一步，它也是奠基石，事实上部标标准在2011年公布后，一直更新过程中，它所包含的东西也是与时俱进的，平台规定的功能标准也在一步一步的垫高，未来一年，将加入视频监控的标准，目前视频监控的草案正在征求意见当中，所以部标平台现在不过，未来更难。

这个时候我们面临的问题就是，一方面要保证原有的运营平台稳定运行，一方面要改造自己原有的GPS平台使之满足796要求，甚至重新写一个796GPS平台。

那么如何来构建一个796 GPS部标平台呢？

首先设计和开发一个平台，主要的步骤是：

1) 分析需求，规划功能，划分子系统；

2) 分析子系统交互的数据流程，设计子系统接口和调用关系；

3）子系统分层架构设计，功能设计，原型设计；

4）子系统开发，单元测试，模拟测试，集成测试，压力测试；

我们按照这些步骤来设计和开发我们的GPS平台, 应该问题不大，不会出现方向性错误

1）根据交通部下发的 JT/T 796-2011《道路运输车辆卫星定位系统平台 技术要求》，我们对796平台的功能规划如下：

2）我们根据功能，先规划了几个必选的、极简子系统，然后在增加候选的子系统，或者根据情况拆分原来的子系统，避免设计的复杂性。

(18659)

       部标平台检测主要分为四个阶段，功能、协议和流程、压力检测。

MySql数据库安装

        MySql服务端安装，“mysql-5.5.13-win32服务端部标检测版”安装些文件

        MySql可视化客户端安装，“navicat9_mysql_csMySql可视化客户端”安装后，连接数据库，然后：

创建三个库

分别以DB文件夹下的文件名命名

导入库

双击库名，单击右上角的“备份”按钮，其下“还原备份”按钮高亮之后，点击。在弹出窗口选择相同名字的文件

点击“开始”

不用做其他操作，再点击“开始”

导入成功，点“关闭”。

加2个用户

加2个用户，用户名分别是：admin与gps

点“添加用户”， 主机填“%”

“确定”，

数据库到库准备好了

测试数据库

安装“模拟终端 11-14”，然后启动

点击“设置”

点击“确定”，然后关闭软件，重启，输入用户名与密码

点“登录”，然后出现以下界面，点“确定“

“开始“按钮如果高亮了，说明与数据库连接成功了，同时模拟终端软件也可用了

安装模拟终端

参看“MySql数据库安装“中的最后一步”测试数据库“。

安装后台服务端

运行安装文件“检测服务“，安装完之后，打开服务管理器

启动以上三个服务，如果能正常启动，说明成功

安装809与流程测试服务端

执行“检测软件客户端“，完成安装，再启动

按以上参数配置，然后输入用户、密码登录，如果提示登录名或者密码错误，那么请打开MySql客户端，打开前面加的三个库的表都会有一个login的表

打开，把超级管理员的PassWord改成pwd文件里的密码，三个库里的这个表都要改，然后启动软件，如果可以正常登录，说明OK了，登录下进入以下页面，点击第一个

进入以下页面，

填好数据，然后先点添加，再点保存，如果保存成功，OK了，如果保存不成功，那进行以下操作之后，再进行以上操作

打开数据库

把testgpscompany库的target与targetdetail表清空，然后右键表“targetdetail“选择”设计表“，出现以下页面

把圈着的两个字段改成varchar类型即可。再重复以上操作，应该就OK了。

到此测试809与流程的软件安装完毕。

安装压力测试软件

压力测试软件与模拟终端软件是差不多的，安装后，测试与与模拟软件一样。安装完之后，安装目录下有配置文件，可配置相关信息。

(9143)

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

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

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

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

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

(14553)