对此次评测结果的总结：

1.部标视频协议的支持程度，锐明和博实结支持的都比较糟糕，不知道他们是怎么过检的，大面积的不符合1078协议指令，锐明还是第一批过检，也是部标1078协议标准的起草单位之一，自己参与撰写的自己都支持的不完善。博实结开始只给客户看证书，没有量产设备，从GF-01到GF-02,给客户换了两次设备，都测试有毛病，最后还要换设备，客户也没耐心了去他妈的换货不换了也不用了。车载视频做的最好的几家公司，主要是在视频领域有一定研发积累，研发实力较强的，比如海康、大华等几家浙江的上市公司，锐明和这两家比起来还差点，但在车载领域做的还可以。博实结只是在GPS上做设备，做视频还很弱。视频设备的研发还是需要有一定的实力积累的，如果仅是买了块板子，用了几个海思芯片SDK开发包，就像你用百度SDK包开发地图一样，技术能力肯定比不上专业搞GIS地图的，后劲肯定不足，技术细节处理不到位，处理问题的能力也很差。

    1）在部标1078协议中，对于终端参数设置和查询，增加了大量的音视频参数设置，这块锐明和博实结的都没有支持，也就是说还无法通过部标参数设置命令，设置视频设备的音视频参数,特别是码流，字幕叠加等功能，都无法通过远程设置，给锐明售后反馈过，这块锐明的研发速度特别慢，一直到现在大半年了也没有新的版本支持。

    2） 视频报警这块，视频报警也是在部标0×0200定位包中，进行了扩展，增加了视频丢失、视频遮挡还有ADS驾驶行为等指令，可以监控到各个视频通道的摄像头状态，但是这块锐明和博实结都没有完整严格的按照部标1078协议进行支持。无法在平台上展现各个通道的状态。

   3） UDP协议支持方面，部标要求TCP和UDP，终端都应该支持，但博实结不支持UDP协议传输，锐明的设备TCP和UDP都支持。我们知道流媒体协议传输的时候，由于由于UDP的传输时延低于TCP，能与视频和音频很好匹配。因此，在实际应用中，RTP/RTCP/UDP用于音频/视频媒体，而TCP用于控制信令的传输。 

   4）FTP上传， 博实结和锐明的都支持FTP上传，博实结的文件格式.avi格式，用常规的播放器都可以播放。锐明的是.264格式，264格式不符合部标1078协议要求，部标要求格式是avi或mp4格式。另外博实结FTP上传的指定文件目录名的时候，有一个明显的bug。

       锐明对于FTP上传的支持也有很大的缺陷，仅仅支持上传，但上传过程中取消不了，不支持0×9207文件上传控制指令，上传完毕后也不发送0×1206文件上传完成通知指令，结果就是服务器无法知道上传是否成功或失败。

   5）录像回放这块，锐明的不支持跨天回放，只能在当天时间段内回放，竟然不支持1078协议中要求的快进，快退回放这种视频监控中的基本功能。

   6）部标1078协议要求终端对平台下发的指令，都要给予应答。目前博实结的GF-02设备存在严重bug，收不到应答，导致平台无法判断指令是否正确执行；

   7）博实结和锐明的设备，都不带RJ45网口，这点就不如大华的设备方便，导致测试的时候，不能用网线连接，必须要插卡测试，浪费流量。WIFI是外置插件，需要单独购买，非常不好用。

   8）两家用的芯片是一样的，所以音视频编码都是一样的，视频是h.264编码, 音频编码是ADPCMA编码。

   9）两家都有自己的软件平台，功能非常弱，虽然是设备厂商，重心不在这里，但是两家的平台也有客户，也不应该如此的糊弄，一个平台仅仅能放个实时视频，其实视频功能多了去了。

2.技术支持服务，因为测试时锐明问题很少，没有和锐明技术服务体系直接打过交道，无法对比。博实结的从购买GF-01设备开始到最后客户终止购买，从17年10月24日，到最后18年1月29日，处理周期是3个月，时间大部分耽误在查找问题，来回物流快递设备换货上面了（换货时必须要先退货那边收到后才发新货）。要是你在参与项目市场竞争，估计菜都凉了。

3.两家设备价格一模一样，裸机对外报价暂时都是1300元，没有价格优势对比，配件中普通摄像头和高清摄像头价格有差异，没有可比性，锐明多了个70元钱的运维宝，不过可以不用。

4.设备质量，运行稳定性上面，没有经过上路测试和实际运营，无法给出对比，这个也不是我搞软件平台开发的职责范畴。博实结的设备问题到最后撕破脸也没查出问题，或许研发知道但不告诉你。他们惯用的招数就是换货。很多人觉得换货就很满足了，这在车载终端领域，换货的成本要多高，很多人都是无知的状态，一台设备安装到车上，人工安装成本、差旅成本是多少？ 然后再拆下来，拆卸成本是多少？ 需要发回原厂，物流成本是多少，然后对方再发货给你（需要注明的是厂家发货，运费都是到付，快递到付的成本比现结的成本要高很多），最后你重新再安装上去，整个处理过程的周期是多长？ 这么长的时间成本是多少？通过这几个问题，你应该知道换货的成本有多高，而设备厂商呢就是发了一个设备而已，还是到付。

如需购买符合部标1077功能标准和部标1078协议标准的B/S架构的平台，请参考文章：

 1）Asp.NET版的部标平台开发-》基于Asp.NET MVC构建BS架构的GPS视频部标平台

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

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

4）基于部标1078视频协议和苏标Adas协议构建主动安全平台

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

下面说下两个设备的评测的详细过程：

客户首先给我的是博实结的一款设备GF-01的设备，博实结的销售说是支持部标1078协议的，经过我测试，发现报文还是博实结的私有协议，我告诉了客户，他还不信，说博实结的销售给他说这款是过检的设备。还展示证书给我看。我说这款设备完全不支持部标。加了他们的技术支持，他们的技术支持开始还不敢承认此事和担当责任，让我们客户从销售买的自行去联系销售。

最后承认设备不支持，后续答应给升级，至于什么时候能升级能出来就不知道了。问有没有最新支持部标1078协议的视频设备，答复是没有。客户虽然很愤怒，但也没办法。因为只买了一台，犯不上和他们较劲，虽然想投诉他们的销售，但是他们的网站上也没有投诉的入口，也没有投诉电话。

过了一个多月，因为不想这个设备报废，就又联系博实结的技术支持，他们捣鼓半天，回复说这个设备GF-01的设备，升不了级，不过答应说给更换一台GF-02的设备，说是GF-02的设备符合1078协议。客户没办法，自己掏腰包把设备顺丰快递到深圳，然后那边收到退货设备后，他们用了个最慢的快递宅急送给送过来了，一来一回又小半个月过去。

GF-02设备接电，连接到我的部标1078视频服务器上面，测试发现服务器下发的所有的1078协议指令，都没有收到终端的应答，而下发808指令如拍照、查询终端参数等，可以收到终端的应答。搞开发的都知道，这明显就是个bug。而这个明显的bug，竟然和他们纠缠了好多天，耽误了我宝贵的开发时间，让我极度恼火，最后也让我撕破脸在QQ上怼了他们领导。我还原一下和他们纠缠的过程，让大家深刻理解这个过程又多艰难。

说别人有问题，首先要确定自己是干净的没问题的，第一步就是记录原始报文，看看报文里面有没有终端上来的1078应答，结论是没有终端应答。第二部是用wireshark, 抓包，结论也是没有。第三步，确定平台下发指令是正确无误的，其实基于部标协议，如果下发指令是不正确的，终端都必须要应答，回复终端指令不正确或者不支持。通过分析指令，确定指令是正确无误的，因为设备在收到指令后确实是执行了，但就是没有回复应答，这样服务器无法知道指令是否成功。因为客户手里还有锐明的最新款的部标视频设备D5M，上电连接后，下发指令完全支持。

首先对锐明的设备，下发各种1078指令，服务器都正常能收到应答：

联系他们的技术支持，他们在设备上抓取报文后，发现有设备有应答的日志，然后就坚持认为设备没有问题，我说这个逻辑不成立，设备有没有发送应答，应该以平台是否收到为准，你的设备记录了日志，不代表你最后成功发送出去了。为了这个逻辑，反复纠缠，最后他们才答应联系他们的3G终端开发人员，成立了一个群。没有人给你反馈这个问题，他们内部各个部门好像谁都不愿意联系谁，你还要自己重新和群里的人，再重复一遍问题的现象，再贴图，再说明其他厂家的设备，都没有此问题，他们好像也不听你的，仍然又回到原点，他们说设备有日志记录，设备没有问题。

最后他们同意再接一台设备到我服务器上验证此事，结果他们接的那台设备是正常的，这次他们稍微重视了这个问题，后面又升级折腾了一天，客户的设备还是不行，就是没有应答。他们自己实验室的设备究竟和我客户手里的设备有何不同，他们也没有说明。

他们的一个经理装模作业的答应换货，还精描淡写的说前面的工作都是他们配合我的，我一下子怒了，出了问题，自己不主导各个部门去解决问题，让我一个陌生人自己从销售到支持服务，到研发工程师，每个衙门都要转一圈，每个地方都要重新说明一遍问题，反复纠缠，他们就简单拉了群，还是是为了配合我，难道还要我感谢他们?

因为耽误了我好几天的时间，我情绪失控，在QQ上怼了他们的一个小经理的领导，由于我的情绪失控的代价就是，他们在他们也不换货，也不退款，设备算是白买了，好在就这一台设备，不买他们家的设备就行了。

后面我又测试了一些其他的设备功能，还有一些问题，因为客户不打算用他们家设备了，也就此打住了。

锐明的设备，我测试了一遍， 在指令上支持还是相对比较完善，不过也有小的瑕疵，在部标1078协议中，对于终端参数设置和查询，增加了大量的音视频参数设置，这块锐明和博实结的都没有支持，也就是说还无法通过部标参数设置命令，设置视频设备的音视频参数，另外一个就是视频报警这块，视频报警也是在部标0×0200定位包中，进行了扩展，增加了视频丢失、视频遮挡还有ADS驾驶行为等指令，可以监控到各个视频通道的摄像头状态，但是这块都没有支持。无法在平台上展现各个通道的状态。

教训总结：

1.由于博实结没有自己的部标1078视频调试服务器，无法在他们的服务器端看到原始报文。本来这块问题很简单，我只需要把设备接入到他们的视频服务器上，能不能收到应答，一下子就看出来了，结果呢他们只负责看终端，这块让我对他们的视频研发实力很是怀疑。没有1078视频调试服务器，他们是怎么调试终端程序的，怎么交互的，我很难以理解。如果没有调试服务器，他们的测试肯定不方便，就不可能进行充分的测试，必须会有问题出现，这是IT开发的规律。就像你是羽毛球选手，没有陪练的一样，你的水平高低自然可知。

2.和公司做生意，如果有问题，最麻烦最头疼的就是在商务销售、技术支持、研发部门绕来绕去，互相推诿，没有担当，没有人给你出头，把这个事情给你解决了，需要你自己挨个联系，经常是你口干舌燥的说完问题（为了把问题说清楚，必须要长篇大论），他告诉你，你去联系谁谁谁。经过此事，我唯一得到的是了解了博实结的处理的组织架构。

3.博实结这件事最没担当最混账的就是他们的商务，先是在没有部标1078设备量产的情况下，欺骗客户购买了GF-01的设备，不符合标准后，说是给升级，到后来又说不能升级，最后换来的GF-02 设备还是有毛病，他不负责，不去协调自己内部各个部门去解决问题。

4.博实结公司，没有投诉反应他们人员问题的入口，这些人的行为得不到惩罚，问题只能继续存在下去，得不到解决，由于得不到任何的惩罚处理，他们也绝不会意识到错误，没有人觉得事情这严重，都是云谈风轻，轻描淡写的，谁管你Y的是干啥的。这件事由于客户幸好只购买了一台GF-01设备，没有造成更大的经济损失，试想如果大批量购买了GF-01设备，并安装上车，怎么退货更换？ 客户的客户都饶了客户吗？

(18580)

      我们这里所说的10万+终端接入，首先是10万+在线的，另外并不是简单的接入，如果做一个基于Netty的网关,只负责协议解析并将数据通过消息队列转发出去, 这样的网关,随便一个程序员熟练使用Netty框架都可以轻松做到, 因为一个进程的Netty本身支持几万个连接时没有任何问题的, 而加上一个  Rocket MQ 或者样Kafka, 这样的网关只是一堆开源框架堆砌起来的Toy, 它的性能测试报告既没有意义也是没有任何技术含量的, 我们不需要实验室的数据, 我们能够给实际要购买的客户,实际演示真实客户的GPS平台.

     什么很多人使用Netty和Kafka, 程序一样容易出问题呢, 因为我们后续肯定还要保证实时数据推送、海量数据入库和查询、报警电子围栏分析和复杂的业务逻辑计算都能稳定的运行,这不仅需要扎实的编程能力,也需要长期运营的磨合,往往需要很多次的版本迭代。在这种场景下，通过长期经验, 我们觉得单台服务器或者单进程的一个808网关服务器是很难支撑到的。我们需要保证的是从前到后一系列的稳定运行指标：

      1） 接入：10万+终端接入不出现排队和无法接入现象，由于一般的基于JT808协议的终端设备，都是基于TCP长连接通信，UDP的很少，10万+长连接的维持对服务器的压力可想而知非常大。一般的服务器带宽不够的时候，或者由于服务器处理速度慢，造成连接无法及时归还连接池，造成服务器接入的时候，就卡壳。我们一般采用Netty来做为JT808服务器的NIO Socket服务器框架，而Netty在开发的时候就要求在Handler中，获取的连接数据的时候，必须不能做耗时的操作。这就要求我们必须要异步处理。

      2)   实时性 ： 虽然终端接入了，但是后续的逻辑处理模块如果处理速度过慢，即使是异步的，也会造成数据在内存中排队等候处理的情况，这样当数据传递到web用户面前的时候，就是滞后的，不满足用户对实时性的要求。如报警弹窗，位置显示等都是对实时性有要求的功能。

      3)   数据入库：并发的连接，必然会造成对数据库并发请求加大，要求及时入库的GPS数据也是海量的，一分钟将有几十万级别的GPS数据等待入库，而且根据jt808协议，一条0×0200指令的定位数据包，经过服务器解析和逻辑计算后，又衍生出报警记录，油量温度记录，里程统计记录等等，数据量也非常的大。虽然并发是提高入库效率的手段，但是并发过高，超过数据库服务器承载的能力，又会造成数据库服务器卡壳，进而造成连锁反应，web用户经常会看到页面打开过慢，数据显示不出来，其实不是web服务器的问题，是数据库的压力太大，难以及时响应。所以一个能承受10万+终端的部标808服务器，并不简单的是要求代码写的好性能高，前期数据库的设计和规划能力和实际的承载能力也必须要跟得上，这就是一条流水线，那个环节掉链子，都是多米诺效应的崩溃。

      4)  查询, 有长期运营经验的程序员都知道, 90%以上的服务器问题,都是由于数据库压力大, 造成整个程序卡壳, 进而造成程序队列堵塞, 内存增长来不及释放进而崩溃,  所以成熟的程序员, 总是非常注意数据库优化的问题, 以及程序中对于数据库的冲击的处理有着丰富的手段,  没有实战经验的程序员, 即使在优秀的代码基础上做二次开发, 也会非常容易造成性能问题, 因为他们没有技术积累, 又缺乏耐心阅读代码, 总是第一时间去想做局部的修改, 完成任务放在最前面, 而把阅读消化代码, 整体提高自己技术水平放在后面.

     5) 实际的业务场景处理, 压力是比较难模拟的, 这也是很多人做了压力测试, 上线后,也一样出现各种各样的性能问题, 这就需要我们本着务实的精神, 在实际的运营过程中, 做后续的优化. 而不是纸上谈兵, 在实验室里面写出来, 做下压力测试报告, 就昭告天下了. 

      在实际的运营中，单台的阿里云服务器并不贵，带宽的运营成本要高于服务器的成本，所以我们在设计架构的时候，必须要保证部标808服务器是可以像刀片一样是可以插拔的，通过分散压力，来保证系统的稳定运行。当某一个服务器模块停用或者上线，是不需要整个平台调整或者改造开发的，web平台是无感的。

      所以我们不能让Web平台直接面对808服务器，而是在808服务和Web平台之间，增加一个Redis缓存服务器，808服务器的实时GPS数据直接push到Redis缓存中，web平台获取实时数据的时候，不是通过RPC调用808服务器的实时服务，而是通过Redis的API，直接从Redis缓存中获取。利用Redis的Pipeline模式，可以批量获取所需的实时数据。

    需要JT 808协议 服务器端源码不含web平台(java和C#两版本可选其一)+808模拟测试终端工具 +压力测试工具  的请联系我购买1200元(2379423771@qq.com), 参见文章：基于Java Netty框架构建高性能的Jt808协议的GPS服务器

     在Web平台给终端下发指令的时候，如何知道终端是在那一台服务器上，这个是通过在Redis中缓存一个Sim卡号和部标808服务器Id的映射关系表，当终端接入的某台服务器的时候，808服务器会自动在Redis上更新映射表，这样web平台下发指令的时候，就知道通过那个部标808服务器下发指令。

     由于Redis有消息队列的功能，对于报警推送等实时性要求高的场合，当部标808服务器解析报警后，可以直接推送给Redis队列，然后web平台通过订阅消息队列，获取报警消息，然后再经由Websocket推送给前端平台。可以看出整个报警的推送路径发生了重大改变，不再是从数据库读取出来，而是通过典型的分布式内存，不断的推送。不单提高了报警响应的速度，更重要的是，大部分的GPS平台，报警误报频繁，频繁的插入数据库，对数据库压力非常的大。

(23946)

表 18     报警标准位定义

从部标808协议文档中对于报警的定义可以看出，一个定位包要承载多个报警，具体对应到数据库记录，一条定位记录要对应多条报警记录，在GPS部标监控平台车辆数到达一定的规模的时候，特别是很多平台的终端在安装的过程中接线松动，造成频繁误报，报警记录就会急剧的增多，如果采用轮询的方式，客户端定时向服务器发送Ajax请求，服务器接到请求后马上返回响应信息并关闭连接。优点：后端程序编写比较容易。 缺点：请求中有大半是无用，浪费带宽和服务器资源。 只能适于小型应用。车辆规模达到一定数量的时候，数据库压力比较大，报警查询性能下降，难以及时的将报警显示在客户端的页面上。

而WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。依靠这种技术可以实现客户端和服务器端的长连接，双向实时通信。基于事件驱动能够实现真正意义上的推送功能。在客户端与服务器端交互的web应用中，websocket最适合在高频率低延迟的场景下，进行事件的交换和处理。所以特别适合车辆终端报警信息低延迟，短消息高频率的推送场景。

各种浏览器对websocket的支持如下图所示：

具体技术的实现，可以采用spring框架，spring4.0以后加入了对websocket技术的支持，而SpringMVC框架可以完美的支持websocket, 只需要按照springmvc要求的规范开发。

      在maven的pom.xml中加入websocket所依赖的jar包

<dependency>

  <groupId>com.fasterxml.jackson.core</groupId>

  <artifactId>jackson-core</artifactId>

  <version>2.4.0</version>

</dependency>

<dependency>

  <groupId>com.fasterxml.jackson.core</groupId>

  <artifactId>jackson-databind</artifactId>

  <version>2.4.0</version>

</dependency>

<dependency>

   <groupId>org.springframework</groupId>

   <artifactId>spring-websocket</artifactId>//version须和spring mvc的version保持一致，否则会出现问题

   <version>4.0.5.RELEASE</version>

</dependency>

<dependency>

   <groupId>org.springframework</groupId>

   <artifactId>spring-messaging</artifactId>

   <version>4.0.5.RELEASE</version>

</dependency>

具体实现方式如下：

1）实现WebSocketHandler接口

WebSocketHandler接口主要是用来与websocket客户端来进行交互的接口，Spring WebSocket提供了一些实现类，可以根据自己的需求进行选择与重写。

2）新建一个自己的HandShakeInterceptor类 

HandShakeInterceptor是websocket握手拦截器，用于拦截websocket初始化连接的请求 。

3）配置spring.xml文件

(19230)

由于各地的企业平台基本都是符合交通部部标标准的，都具备809协议的转发功能，要和这些企业平台对接，不需要再一个一个的敲定接口标准了，只需要开发出809协议的网关应用，接入各地分散的企业平台的接入请求，就可以收集到车辆的位置数据了。

JT809网关数据接口服务系统，是基于TCP协议开发的部标809协议服务软件系统。系统利用高并发的Netty通信框架，采用通信双方约定的809协议规范，完成对协议数据的解析、拦截、数据入库、报警分析和转发的工作。并实现协议数据与上级平台、下级平台（多方企业运营服务平台）之间的数据通信桥梁。从而实现多部标企业平台车辆动态数据通过拦截、转发、存储的功能推送至自有企业平台。

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

         如需购买平台源码，请联系邮箱: 2379423771@qq.com

基于809的web平台，相对于一般的企业平台，有不同的复杂性：

1.由于多个第三方的企业平台的gps数据同时接入，相对于一般的gps平台，数据体量比较大，接入的车辆数多在几万台车甚至十几万台，对于网关的接入、分析、处理性能要求比较高。

2.连接维护的复杂性，由于809协议设计者设计了双链路的通信连接机制，主链路和从链路，还有数据加密的机制，加大了通信连接的复杂性，数据在传输过程中的断线重连，心跳机制是必须要考虑的，否则一旦数据中断了，第二天才发现，就会丢失大量的定位数据。

   针对以上特点，jt809平台的架构设计需要做到一下几点：

          1.       实时性

 网关接收到实时的定位数据后，实时位置数据和经过分析后的最新报警直接在内存中推送给web服务器，然后由web服务器推送到web页面上显示。

          2.       数据的分析

 海量的数据进入内存当中，等待分析和入库，所以分析和入库的速度必须要快，另外操作必须是异步的，不能堵塞通信连接和数据接收。

 基本的分析工作有：上线下线分析、各种终端报警分析、平台报警分析等工作；

 基于业务智能分析工作有：位置和运输业务结合的智能分析工作等；

 统计工作有：里程油量统计，上线率统计，其他结合业务的统计工作等；

          3.       存储和备份

 由于数据体量比较大，每天的定位数据记录都在百万级别以上，所以在系统运行前，存储和备份的规划工作必须要做在前面，否则后面数据库体积越来越大，难以维护和备份，另外数据库压力大，速度越来越慢也会影响web平台的正常运行。 存储和备份规划，影响着入库模块的设计以及web查询模块的设计，必须要做在最前面。对于海量的数据必须要分库分表设计。历史数据和报警数据分表设计如下图所示：

809网关服务器监控界面(界面采用swing开发，参见809转发服务器博客文章)

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

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

web系统 对809服务器连接和日志状态的监控

web界面上809消息通知和报警消息通知

(20953)

1）服务器通信技术：因为C#中，基于.NET4.0的异步通信框架，还是非常不错的。不过编程模式也是比较复杂的，不像Java的NIO框架Mina和Netty那样方便省力,但是一样可以开发出高性能的jt808GPS服务器和jt809服务器。

2）分布式服务：对于高性能的平台，服务一定是要求分布式部署和调用的，以应对压力，比如jt808GPS服务器、存储转发缓存服务器和web服务器，都是部署在不同机子上面，对于远程服务调用，可以采用微软的WCF技术开发出各种部标平台的API服务接口，满足Webgis和808服务器，809服务器之间的分布式服务调用。

3）web框架：可以采用当前最流行的主流开发框架Asp.NET MVC框架来开发web应用，前端采用jquery + ajax调用，MVC框架返回Json数据，清清爽爽的，代码容易阅读和维护。

4）如果开发桌面客户端，可以采用GMAP.NET的地图框架，可以很方便的将地图缓存在本地，解决了webgis地图操作不太流畅的问题。

5) 部标GPS平台可以单独付费升级为部标1077视频平台，支持符合部标视频Jt-t 1078协议标准的部标1076视频设备终端接入，在BS端通过flash插件或者HTML5 VIDEO组件进行实时视频监控和录像回放、视频文件下载。参见：

    1.基于Html5+HLS协议播放符合部标1078协议的实时流媒体视频

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

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

通过增加1078视频服务器和web视频播放器，成为符合部标1077的视频平台。当然视频开发的工作量和复杂度也是gps平台所不能比的。

6) 根据苏标主动安全协议中的平台功能要求和苏标终端通信协议要求,增加苏标主动安全平台功能和苏标报警解析及附件上传功能.

详见: 

基于Asp.NET MVC框架+SignalR +ActiveMQ + Ali OSS 服务构建苏标主动安全智能平台

提供基于C#语言的Asp.NET MVC和WCF架构的部标平台源码，需要购买的请联系2379423771@qq.com，可以出差免费为客户提供技术支持和培训（差旅费用须由客户承担）

开发工具是vs2012, 采用.net4.0,  asp.net mvc4 框架开发，项目工程结构如下图所示：

采用Nuget来管理项目依赖的lib库，非常方便，如下图所示：

代码注释风格如图所示，力求干净简洁：

目前整理了基于.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桌面客户端的部标平台开发-》GPS监控客户端设计

6.GPS部标监控平台的架构设计-基于WCF的平台数据通信设计

7.GPS.NET 地图应用程序架构设计

软件截图如下图所示：

(20601)

本版本是2015-2017年推出的最新稳定版本，是我工作的主流版本，相对于原来的2014年研发的旧版的struts版本，从性能和功能上有了较大的提升，融合了大量客户的需求意见，特点：

1）SpringMVC版本已经替代struts成为主流框架.

2）采用Netty框架替代原有的Mina框架，在服务器的并发性能上有了大幅提升，普通服务器单进程可以支撑到3万台终端；部标808服务器所支持的部标协议，旧版只支持jt/t 808 2011版本的协议，新版本全面支持jt/t 808 2013版本的协议，如定时拍照等新特性，增加了808协议数据实时转发的特性。

3） 采用Redis缓存服务器，支持多台808服务器集群，参见文章：基于Redis构建10万+终端级的高性能部标808Gps网关服务器

4）可以接收第三方的转发的数据，由于很多GPS平台所获得的数据都是从第三方平台而来，并不能得到一手的GPS终端数据，809模块增加了809政府运管服务器，用来接收第三方转发而来的数据。

5）采用Mybatis替代旧版本中已经淘汰的Ibatis框架，通过Mybatis的查询分页插件，可以很方便的支撑各种数据库的分页查询，代码可以支持Mysql, Sqlserver, 和Oracle三种数据库，利用Mybatis的批量插入特性，大幅提升了GPS数据入库的性能；

6）地图部分做了较大的优化，统一地图接口，支持百度、高德和四维三种地图；

7）新版本是基于saas的多租户架构设计，充分支持多公司，多集团，多代理的组织架构模式，不同企业实体的数据、权限进行完全的隔离，可以单独为每个企业分配企业管理员，企业管理员在自己的企业实体内，可以单独分配角色权限，建立部门和车队；

8）Spring框架从旧版的2.5升级到Spring4, 从原来的全xml配置，利用Spring4的注解特性，大幅削减了系统的xml配置，系统部署和配置更加方便，维护更加容易；

9)  SpringMVC4集成WebSocket，基于Websocket进行报警推送，大大提高报警推送的效率。

参见：基于Websocket+SpringMVC4推送部标Jt808终端报警

10） 使用阿里巴巴团队开源的Druid连接池，Druid是Java语言中最好的数据库连接池。能够提供强大的监控和扩展功能。

11) 对原有的代码做了大量的优化，性能做了较大的提升，代码进行了充分的重构，增加了大量的注释，设计文档进行了重写；

12) Android客户端跟随最新谷歌主流的Material Design设计思想，采用android studio和gradle3.0做开发工具，使用主流的框架retrofit 2.0网络库等框架开发，保证代码使用的是最新的主流技术，方便技术团队对接和消化。

13) 部标GPS平台可以单独付费升级为部标1077视频平台，支持符合部标视频Jt/t 1078协议标准的部标1076视频设备接入，在BS端通过HTML5 Video插件或者flash插件进行实时视频监控和录像回放、视频文件下载。

14）基于苏标Adas协议构建主动安全平台

2017年至2018年，主要做的重大版本更新有：

1.2017年增加部标1078协议支持，增加部标1077视频监控平台功能支持，相继有多家客户通过交通部过检机构中心的部标1077视频监控平台过检与认证,拿到了报告和公示；

2.2018年增加对江苏省的Adas标准的支持.

2019年主要做的重大更新：

1. 更新平台功能符合国标GB/T 35658-2017标准，新标准做了大量的增补, 由于《道路运输车辆卫星定位系统 平台技术要求》由部标796标准变为国标GB/T 35658-2017标准，信息中心的测试标准也按照GB/T 35658-2017标准来检。

   参见文章:GB∕T 35658平台过检 已通过最新的部标JT/T 808-2019, JT/T 809-2019标准 

2.基于部标1078视频协议和苏标Adas协议构建主动安全平台

基于Redis + RabbitMQ的苏标主动安全平台架构设计

通过增加1078视频服务器和web视频播放器，可以将GPS平台改进为符合部标1077的视频平台。当然视频开发的工作量和复杂度也是gps平台所不能比的。一个视频平台不是简简单单的播放视频就完事了，仔细阅读部标1077的文档的视频功能标准就可以看到，一个视频平台还要附加大量与视频相关的如视频报警、报警联动、服务器录像存储回放、视频参数设置、视频下载、报表统计等功能，有很多琐碎的功能细节需要全部实现，才能称为一个完整的部标视频平台。同时视频平台也需要与上级运管对接，为上级运管提供视频转发的服务器功能，1078协议在809协议上面又附加了大量与视频相关的指令，如实时播放、FTP上传、资源文件检索、回放、报警等功能。

GPS平台有了视频功能，平台监控手段地丰富性将大大增强，GPS报警，轨迹，报表等都可以和实时视频，视频录像文件进行深度的集成和关联，如视频报警联动等，如下图所示：

历史轨迹回放和视频回放的结合：

部标1077平台的核心是两个服务器模块，部标808网关服务器和部标1078视频服务器，其中部标808gps网关服务器提供指令服务，部标1078视频服务器主要为用户客户端提供基于RTSP协议标准实现的嵌入式的RTSP服务器功能，处理用户的RTSP视频实时播放和历史视频回放请求，还有流媒体服务的核心功能，如音视频的编解码和流媒体转发处理的核心模块，另外还有服务器连接管理，录像，下载，流量计算等附加功能。

如需购买，可以联系2379423771@qq.com, 本人可以去客户所在地，提供两天以内的免费培训和技术支持服务（差旅住宿费用由客户承担）。

旧版的基于struts2技术框架的平台源码仍然销售，但不再提供升级，参见基于Struts+Spring+Hibernate+Ibatis+Quartz+Mina框架构建部标监控平台

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

废话少说，我们现在构建基于BS网页Web模式的部标GPS监控平台，基于主流的J2EE三层模型，主要的技术选型如下：

1.基础容器框架 spring4

2.Web框架 Springmvc4

3.ORM实体与关系数据库映射框架 hibernate4

4.SQL查询框架 mybatis3

5.单元测试 junit4

6.日志   log4j

7.定时任务框架Quartz 

系统运行环境：tomcat7+ 、JDK7+、MySql 5.7/ SQSERVER2005/Oracle9

GPS监控的web平台对技术的要求如下：

1.实时监控和部标808协议的几十种终端指令的上传下达，百度地图车辆位置监控，地图操作等功能需要频发的对服务器发送基于ajax的request，返回json数据，基本上是重度使用ajax请求和Json传输。

2.Web服务器需要应对网页客户端重度的request请求，性能要求较高，在mvc框架开发的时候，一定要避免内存泄漏，因为在频繁的request请求调用之下，小小的内存泄漏，会一点一点积累，直至耗掉tomcat的内存。

Web框架我们采用sprngMVC4， 主要的考虑如下：

1.全注解环境，采用springmvc4，替xml配置，避免掉了一大堆的xml配置，对应URL的映射和request参数的映射直接在方法中通过注解配置；

2.spring mvc是基于方法的设计，controller是单例模式，而sturts是基于类，每次发一次请求都会实例一个action，每个action都会被注入属性，而spring基于方法，粒度更细，性能上更高一筹；

数据库ORM的框架要求如下：

1.能够比较灵活的适应主流的数据库，如mysql, mssqlserver, oracle等，现在的开发团队和开发人员在开发的时候，几乎没有人关注这个问题，基本都是在一个数据库上吊死，而作为一个平台的开发，为应对不同的客户要求，团队的开发力量有限，不能一个数据库一个版本，这样开发和维护、升级、测试成本就急速的升高，所以我们追求的是一下几个原则：

1）不用存储过程和触发器；

  很多开发团队都是重度的存储过程和触发器的使用者，连简单的查询分页都要用存储过程，一旦开发人员离职，这些存储过程和触发器都像天书一样，难以维护，一般我们的代码都是在SVN基于配置库进行版本管理，而存储过程和触发器却脱离这些之外，存储过程和触发器如果有bug出现问题，在生产环境上，很难进行跟踪，web容器的日志记录只能跟踪到java代码级别，剩下就需要DBA来配合了。

2）使用Hibernate4 框架，实体类和数据库的映射都在类和属性方法上完成；基于Hibernate的配置就可以轻松切换到其他数据库。

3）采用采用Mybatis的物理分页插件，通过拦截器的方式，在开发人员编写的SQL上进行拦截，并自动包装上各个数据库的物理分页代码，可以支持多个主流数据库的物理分页查询方法。

4）采用mybatis和log4j，可以很方便的打印SQL日志，方便调试跟踪。

5）采用阿里巴巴的开源连接池引擎，配置对spring service层的AOP监控，druid内置了后台监控页面，可以直接监控连接池的耗费情况，以及SQL的性能耗时监控，非常方便。

基于Maven构建多模块项目工程，打造干净的依赖库

  我们在开发GPS监控平台的时候，一般都是基于业务功能和职责，将业务分为多个模块，各个模块之间相互独立，每个模块可以独立运行或者作为独立的公共类库被其他模块所依赖如Dao、Service等。

  实际上一个部标GPS监控平台，里面包含了多个业务功能模块，如部标808GPS服务器，web网页客户端，809转发服务器，移动API，位置服务，计算服务等等。

  由于多个模块，都需要依赖这些开发框架，而开源框架又有各自的依赖的jar包，他们的版本搭配非常关键，例如springmvc4用的jackson框架是2.1， springmvc3 用的jackjson框架是1.x版本，你如果搭配错了，项目运行不起来了。再比如spring和mybatis, hibernate之间的无缝结合，虽然是互相搭配，但你如果用的版本不一致，也会造成项目出错。未来我们想升级某个框架，比如从spring4升级到spring5,也是不是单纯的只升级spring4, 而是要考虑hibernate, mybatis等框架的联动升级。

  所以采用Maven来提供工程的中央仓库，所有的子模块共享一个POM文件，避免各个子模块各自重复依赖一大堆jar包。Maven的多模块其实就是按照层级的管理构建，项目包含一个pom.xml文件和若干个模块，每个模块有一个单独的pom.xml文件，通过pom的依赖和继承关系来构建项目层次。一旦建好以后，就可以终身享用，工作量会大大降低，jar包版本不一致的造成的项目风险会大大降低。

  而整个项目工程的拷贝复制就更加简单，里面不再有大量的jar包，开发人员只需从配置库上更新最新的代码后，配置库中不再有大量的开源框架jar包，而是从Maven中央仓库中自动更新。建立工程的时候，直接选择导入Maven工程，一键将所有的模块导入到新的workspace当中，非常方便。

 购买GPS平台或GPS监控系统源码，联系我2379423771@qq.com

以下是在Myeclipse开发环境下的Maven工程截图

Maven的POM.xml文件配置：

以下是IntelliJ IDEA开发环境下的工程截图

使用IDEA的Maven插件，结合源码工程的POM文件中的现成的编译脚本，开发人员不用在做额外的工作，直接点击install，就可以一键打包部署，非常方便。

工程目录和包命名规范

我现在根据Spring的注释，包的命名，当然这首先建立在你对三层架构的熟悉上。

com.ltmonitor.jt808.app    808服务器应用程序

com.ltmonitor.jt809.app    808服务器应用程序

com.ltmonitor.web.vo       用于web页面传递的对象

com.ltmonitor.service.vo   用于服务传递的对象

com.ltmonitor.controller   MVC中的控制,Spring的注释@controller

com.ltmonitor.controller.map        地图表现层

com.ltmonitor.controller.terminalcommand 终端指令

com.ltmonitor.entity     实体类

com.ltmonitor.entity.jt808 专用于808gps服务器的实体类

com.ltmonitor.entity.jt809 专用于809服务器的实体类

com.ltmonitor.dao  Dao层

com.ltmonitor.servce service层

com.ltmonitor.server  gps服务器层

。。。

。。。。。

。。。。

完备的开发手册可以帮助开发者理解整个开发平台

数据字典：

主界面

支持百度高德地图聚合

支持海量车辆在地图上的位置显示和移动，通过颜色区分车辆的在线状态和停车行驶状态

支持车辆GPS状态和地图图标自定义：

(34475)

ü   附件2移动车辆选型

移动车载动态取证系统,在选择安装车辆时主要需要考虑云台摄像机安装后的视野效果,建议选择的车型如下:

上述表格中的车辆基本车身长度不超过4.7m[S9] ，车顶水平长度不超过2.8m。在车顶安装云台摄像机后，车顶前后沿对视野遮挡较少，这样云台摄像机在安装后其全方位视角比较好，并且大部分车辆都有后备箱，有足够空间放置车载主机，主机连接的线缆都可安装在不易碰触的位置，整套系统有良好的安装运行环境。。

(10694)

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

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

(10741)

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

(14682)

    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)部标检测-》交通部部标监控平台检测

(12433)

首先开发者要搞清楚，北斗技术是底层的定位导航系统技术，中国北斗卫星导航系统（BeiDou Navigation Satellite System，BDS）是中国自行研制的全球卫星导航系统。是继美国全球定位系统（GPS）、俄罗斯格洛纳斯卫星导航系统（GLONASS）之后第三个成熟的卫星导航系统。终端是通过植入北斗定位芯片来获取到北斗定位能力，北斗芯片，是包含了RF射频芯片，基带芯片及微处理器的芯片组，相关设备通过北斗芯片，可以接受由北斗卫星发射的信号，从而完成定位导航的功能。

部标808协议是终端和服务器之间的通信协议，两者是两码事，终端首先通过定位芯片获取到定位数据，然后再通过部标协议上传到服务器上。作为位置平台开发者，根本不需要关心你的终端是北斗的还是gps，需要关心你的终端上传数据采用的协议是不是交通部的部标而已。

因为部标的推出早于北斗的大规模民用化，所以现在推出的北斗终端主要是为了参与交通部管制的招投标项目，在协议标准上，都是以部标为标准。

所以只要是符合部标794标准的，jt/t 794标准要求终端的上传协议必须符合jt/t 808协议，所以肯定接入部标平台或部标808服务器是没有问题的。部标标准是2011年推出的，已经历经将近四年的市场化，应用已经非常普遍了。标准意义就在于此，所以再讨论是否能接入的问题，就显得很初级了。

(11923)

所以开发GPS平台的时候，必须要首先阅读交通部的jt/t 796 , jt/t808和jt/t809的文档，以此作为自己的功能设计的需求来源，行业需求或用户需求是排在后面的。很多开发团队做出来的平台为什么不能过检测，就是因为没有沉下心来，仔细阅读文档，以为是个概念，可以随性而来，在设计的时候，过于偏向行业需求，而对与交通部的标准制定，理解有偏差。其实在平台检测的时候，是一个标准化的检测过程，是以检测工具为准的，合不合要求，检测工具说了算。如果你没有严格的按照标准开发，哪里有什么机会让你解释：我这么做是因为考虑到什么原因等等。这样的思想等你过检测的时候，你自己会觉得很幼稚的。

交通部796的功能标准大致如下：

如需购买GPS平台源码+文档+服务，可以联系我2379423771@qq.com。

Java平台，参见：

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

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

(15657)

在当前很多的GPS平台当中，有很多是基于asp.NET+siverlight开发的遗留项目，代码混乱而又难以维护，各种耦合和关联，要命的是界面也没见到比Javascript做的控件有多好看，随着需求的增多，平台已经臃肿不堪。

设计基于.NET的GPS部标平台，我们坚定不移的选择了基于JQUERY+Asp.NET MVC来作为前端交互和后台处理的框架。选用一个灵活的脚手架，同时团队又能掌握这个脚手架为团队所用。

对于一个web应用项目，基于MVC的框架，前面文章提到过，最大的优点就是结构清晰，强制性的将繁乱的页面，请求，后台处理逻辑，划分成MVC三层结构，一层一层的做开发，一层一层的维护，同时层也不多，适可而止。通过MVC，高手和低手，在开发的初期基本上站在一个起跑线上，这个我认为很重要，特别是团队开发和维护，团队中的人开发水平各不一样，对于架构设计这种抽象到家的技术，理解也各不一样，每次项目启动的时候，都有各种各样的争论，都觉得自己是架构师，这是很要命的，很多人认为设计可以让开发效率更高，代码更容易扩展，后期更容易维护，性能更好更稳定，更易用。但糅合各种意见、评审、讨论、妥协的设计无一例外最终却走向反面。

很多人都是从asp.net web form过来的，对这个很不以为然，其实正是这种温吞水煮青蛙的开发技术，造成了部分人员留下了惨痛的后遗症，主要表现在：

1.首先就是学习能力差，其实也不是没学习能力，主要是看见新东西没兴趣，没动力，这个要命的缺点造成了后面的缺点

2.大量依赖于服务器端控件，对于前端的javascript以及js框架，css+div布局等技术，掌握很少，造成前端开发效率低下，出一点问题就调试老半天。技术太单一，在职场上可以说没有竞争力和吸引力。

3.写代码时，各种随意，有的不分层，各种逻辑都一股脑揉进UI，有的分层，但往往受PetStore的毒害，搞了很多层，画虎不成反类犬，为了重用，一层套一层，连环调用，看代码，需要运行打断点，一层一层往下看，就像进入十八层地狱，最后终于到底看到了SQL。代码中特别喜欢直接写SQL，各种insert,select满天飞，各种ifelse,各种重复，这些项目中代码量最大的地方，往往就在这个地方，而这个地方是最没技术含量的。

很多开发者经历过各种苦难，都想在下一次开发中不要这样，但如果出于对未来变数的恐惧而总是追求各种莫须有以后也从未发生过的扩展，在项目的初期就臆想各种高性能，高批量，大规模，因为抽象而引入各种抽象，因为架构设计就设计一个复杂的架构。那么开发者的宿命就是不断的轮回。

对于一个GPS的Web平台，设计的重心就是要回归到结构清晰，先谈结构，再谈架构，结构是扁平化，清晰化，一堆乱如麻的东西我们的目标就是消除臃肿，归类，分清楚，需用用的时候找得到，简洁化;架构是立体化，也是复杂化，多个子系统，多个接口，多个服务，多种面向服务的调用。

我们在设计的时候，总是先在文档中牛掰的写到设计原则与目标，但是往后面看，发现我们设计和开发的东西和我们写的原则没有一点毛关系。所以要想设计好，就要想清楚你得设计原则是不是有利于你的设计目标，你做的东西是不是奔着你设计的目标去了。

我们的设计原则就是追求结构清晰，说白了就是追求单一职责原则的最大化，无论前端还是后台。一个萝卜一个坑，一个萝卜坑里面就是一个萝卜，不能里面放一颗白菜。

1.MVC，三层够用，再多打屁屁。

2.追求命名具体而规范，特别是前端。看到命名，能知道功能，最好就像仓库的标签。看到名字，就知道是干什么的，在哪里放着，也知道应该在哪里放。

3.减少抽象， C#和java放弃了c++的多重继承，就是因为复杂度的增加，得不偿失。你要理解这个，多重接口你也不愿意用，看者都晕。我在看Ibatis的源码的时候，一个类后面继承了五六个接口，看到一个接口定义的变量后，如果不打上断点，都找不到实现类在哪里。很多代码都是如此，等项目结束了，回头看，好听点就是层层调用，通俗地说就是大方法里套小方法，小方法里调邻居方法，调的多了，复杂度就上来了，一个方法多个地方调用、重写(override)，等你想修改的时候，影响一大片。

4.追求单一职责，一个功能，或者逻辑紧密相关的功能，归结到一个类中。单一职责原则中对职责的理解各不一样，同时也可大可小，小到一个功能点，大到一个功能模块，子系统。这也是要求我们要把这个原则从小到大，从底向上，从前到后，贯穿始终。单一职责原则和命名规范结合一起，有利于维护结构的清晰。比如你看到GPS平台的车辆树菜单，想进入到js代码中调试，由于我们把关于车辆树的代码都写入到一个独立的vehicleTree.js中，那就直接找到了。看到前端代码后，我们想看看后端是怎么是怎么处理ajax 请求的，由于是采用MVC框架，处理前端请求的都是编写对应的controller类，我们命名是VehicelTreeController.cs文件，这样我们也快速的定位到代码，也明白了从前到后的调用路径和结构。同时这个里面的代码就是写的再乱，也不会传染给其他代码，所谓的传染就是一段复杂难理解、难调试、难维护的代码，不会造成其他文件或功能的代码难以理解、调试和维护。

5.减少装逼。在项目的前期，各种装逼，什么需求分析，概念设计，架构设计，UML等等时间杀手，装逼的成本高昂，代价惨重。我们追求的结构就是扁平化，不需要你装逼，整各种傻逼UML图，也不需要你写各种自己都不会去看的文档。一个excel就够了。

当然一个复杂的部标平台，不仅仅是web，还要部标808和809GPS服务器等，各个子系统之间也需要互联互通，压力最大的在于GPS服务器, 参见我前面的文章：

GPS部标监控平台的架构设计(八)-基于WCF的平台数据通信设计

不仅支持808服务器，809服务器和web平台的分布式部署，也支持gps网关基于负载平衡的多层部署，当车辆数超过5万台一上，可以部署任意多个gps网关（jt808服务器）来做负载均衡，采用一拖N的方式，即只部署一个web平台，但gps网关有多个，来满足GPS平台这种用户压力小，车载接入压力大，数据压力大的倒金字塔的压力模型。

最后的工程，如下图哦所示，相对于没有负载均衡的架构，增加了实时服务器中间层，多级808服务器自动会注册到中间层上面，保持双工连接，既可以接收数据，又可以反向，通过web平台，下发指令给指定的终端；

提供基于C#语言的Asp.NET MVC和WCF架构的部标平台源码，包括BS和CS系统，需要购买的请联系2379423771@qq.com，可以出差免费为客户提供技术支持和培训（差旅费用须由客户承担）

绿色通道： 好文要顶 关注我 收藏该文与我联系 

(15720)

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

在部标GPS软件平台中，由于部标过检的时候，指定要求在四维地图和高德地图中任选一家，必须要有审图号，也就是说必要购买，不能用免费的地图，年费三万起，这个无疑加大了运营成本，加重了企业负担，现在物流运输企业挣钱都是从车轱辘里蹦出来的，那些地图厂商坐地收费，因为是年费，要年年交，真是黑。

但是虽说是部标平台，过检是第一步，第二步要给客户用，很多客户由于在实际上网的过程中，对于百度地图已经很接受了，所以经常会指定要求用百度地图。所以我们在设计平 台的时候，考虑多个地图切换和兼容是顺理成章的事情。

百度地图的主要优势如下：
1) 卫星地图，百度的卫星地图虽然远不如谷歌的卫星地图，但是比国内这些四维之类的垃圾要强大多了，谷歌的服务经常被搞，所以忍痛放弃；
2) 百度的javascript SDK和手机SDK较其他地图要完善的多，升级较多;
3) API上要比其他厂商的API要丰富，出来Javascript API,也提供了web service API(高德地图目前不提供), 可以在后台使用C#或Java语言调用web服务接口进行坐标转换和位置解析服务。
5) 地图美观。这个美观主要是在地图图层优化上，不同的zoom下，显示不同的图层，这样地图加载的速度会比较流畅，显示也比较美观。我们自己在开发时，较少考虑这一点，比如车辆图标，当地图缩小到国家级的时候，车辆密密麻麻的显示在一起，实际上要根据不同的zoom进行优化。

因为地图SDK都是基于Javascript的SDK，所以设计主要集中在前端的Javascript的设计上。

主要设计模块分为:
1)地图主界面页面(jsp);
2)后台ajax数据调用接口;
3)地图接口js;
4)工具栏;

地图页面主要控制地图界面UI的布局和显示方式，主要的UI部分包括: 
1) 地图操作工具条；
2）中心地图DIV;
3) 历史轨迹查询工具条;
4) 实时数据显示栏;
5) 历史轨迹数据显示栏

地图接口js设计
首先根据部标要求的地图功能，我们来设计地图操作的放大、缩小、围栏、线路、标注、图层等接口等。

地图接口的核心就是对较复杂的围栏和线路操作进行一个封装，因为部标808不仅要求围栏和线路指令下发给终端，终端支持报警，还需要平台也能支持围栏报警和路线偏移报警，主要的操作如下：

1）地图上画出多边形、矩形和圆形围栏及线路，并持久化;

2)  绑定给车辆；

3) 下发绑定指令给终端；

4) 车辆进入围栏，触发报警; (这里可能是终端报警，平台也要支持报警)

5）报警后，显示车辆在地图中心;

ajax调用接口
1) 当初始化地图的时候，获取用户的权限，根据权限显示不同的地图操作工具;
2) 获取用户录入的各种图元并加载到地图上显示，如自定义标注、各种类型的围栏、线路等；
3) 实时监控时，不断获取实时数据，并刷新地图车辆位置，画出实时轨迹;
4) 历史轨迹回放时，获取历史数据，并刷新地图车辆位置，画出历史轨迹;
5) 持久化接口，将用户在地图上的标注、画出的围栏、线路等保存到后台数据库；

地图服务模块
1.位置解析模块，不断的解析车辆的坐标，转为地理位置描述，更新到系统中，并在前台显示；
2.加偏服务模块，根据前台的调用request,调用百度地图的加偏地址，转换坐标在前台地图上显示；

3.实时加偏，采用加偏算法和逆向纠偏算法，可以实时的进行百度地图的坐标系统转换，不需要百度自带的webservice服务，避免了百度调用接口的限制及性能的损失，因为每次远程调用http，都要耗费不固定的远程调用时间及调用超时的时间。

另外存在一个问题是，无论是那个地图，在地图上画的区域存储在数据库的都是自己地图坐标系统的经纬度节点，如果要进行电子围栏报警，下发给终端的时候，终端是百分百误报的，因为终端的坐标和地图坐标系统不符，需要在下发给终端前，还原成原始坐标再下发给终端。所以就需要逆向还原的纠偏算法。我们提供正向和反向的算法库。算法库代码参见：http://www.jt808.com/?p=552

需要购买C# .netframework2.0 离线版 DLL 的300元 算法源码600元，包含原始坐标加偏和逆向纠偏还原成原始坐标。提供火星坐标和百度坐标两种接口，不是数据库，提供的是算法源码，实时解析，需要的可以直接联系我(2379423771@qq.com)购买。

(14763)

  

  

  

(13794)

其实架构设计中有两个可扩展性要求：

一个是性能的可扩展，随着接入车辆压力的增大，不需要改动代码，只需要增加硬件配置，如增加服务器，增加软件运行的进程实例来达到要求；

一个是功能上的可扩展，在运营平台上，为不同的物流企业提供运营服务，各个企业必然有自己个性化的需求，想要吸引客户，销售上就得尽量答应客户的各种要求，技术上就要想办法实现客户的要求，但是其他企业客户八竿子用不着。很多运营平台都经历过功能弱智简单、功能丰富最后到臃肿再到最后推到重来这样的过程。

这两点明确后，我们知道自己的设计目标：

1) 性能可扩展方面

   首先要面向服务进行设计，对子系统当中的调用接口进行定义，在子系统中加以实现，形成服务。这些服务可以本地部署，可以分布式部署，服务的部署对于调用者来说是透明的，不影响的。做到了这一点，我们才可以在压力来临的时候，通过改变和增加服务器的配置，透明灵活的分布式部署方式，来缓解压力的上升。

   面向服务的开发中，对于远程方法调用的协议，Java的有RMI，DotNet的有WCF，都是非常好的可以基于TCP二进制交换数据的协议，远胜于webservice，但在设计的时候，可以完全不用考虑这些，在实现的时候，由于现在的Spring框架很强大，仅仅通过几行XML配置，就可以将一个接口透出变成一个RMI服务或者WCF服务。

  对于压力的处理，通过不同的服务，来分担压力，如解析后调用入库服务，解析程序只是简单调用入库服务的接口然后立即返回，而在入库服务内部，则会通过异步处理保证服务调用后能够立即返回，而不是阻碍整个处理流程。

2)功能可扩展方面

  这个其实是最难的，因为它的要求是比较抽象，就是软件要求能够修改完善添加现有的功能满足软件未来的成长，直白点将就是软件能够改动已满足用户新增的需求。一些人可能会问，只要有代码，可以随便改。如果是这样，为什么我们的客户提出需求后，我们总是拒绝。这是因为随着功能的增多，代码的增多，可维护性变差，修改某个功能的代码，或者添加某项功能，会耗费大量的人力和时间，拔出萝卜带出泥，打扫卫生把瓷器打碎，一句话，很难改。

 什么算是好的可扩展性，只能说，设计好的，代码容易改动，容易添加功能，设计的不好的，一个小小的功能，能改出一头汗，测试的时候，要回归测试一大片。

  软件功能可扩展性设计最理想的是基于插件化或者模块化的设计，通过动态加载、事件注册、功能回调等机制，来达到要求，当然插件化的设计的弊端就是复杂，以复杂为代价，甚至要牺牲部分性能，来达到软件的可扩展性。

  插件设计这个在部标GPS服务器的设计中用的比较多，对于不同的终端的协议，可以基于插件化的设计，不同的协议，按照插件标准进行编写，形成一个庞大的协议库，在系统运行的时候，可以静态配置，也可以动态加载，根据不同的车辆，不同的客户，不同的设备，不同的版本，来加载不同的协议插件进行解析。

   联系：2379423771@qq.com

(8685)

这种观点造成了业界内，很多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）我们根据功能，先规划了几个必选的、极简子系统，然后在增加候选的子系统，或者根据情况拆分原来的子系统，避免设计的复杂性。

(19244)

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

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与流程的软件安装完毕。

安装压力测试软件

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

(9484)

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

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

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

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

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

(15233)

GPS系统功能介绍：

   1.系统左侧菜单分为：车辆列表和加油站列表。

      车辆列表根据GPS上线车辆提醒是否上线：P图标为停车状态，绿色图标为GPS上线后行驶状态，黄色图标为GPS未上线状态，单击GPS上线车辆可以在地图中显示车辆标记位置，并显示车辆基本信息。

     车辆列表图标：每几分钟一刷新图标，更动态知道车辆是否行驶（车速）或停车状态。

     车辆列表提供右键菜单：开启实时监控，关闭实时监控。

     开启实时监控是指：监控车辆定位地点，根据上传GPS坐标，绘制路线和标记点位置。

    关闭实时监控是指：停止绘制车辆轨迹。

   
   2.车辆记录

     .车辆实时状态信息是指：当天车辆实时行驶状态和地址位子信息等内容。
     .实时报警记录是指：车辆当天上线后的运行状态报警记录显示，可及时知道车辆报警的详细位置和时间。
     .轨迹回放数据是指：当回放轨迹时，提供给用户查看的轨迹数据内容，如坐标点，位置信息，车辆名称等。
  

系统主要功能模块为：
  
一 GPS地图：
   
   1.支持图标标记：如车辆和加油站，加油站标注根据地图缩放大小显示。

   2.地图右键菜单：添加加油站标记，放大缩小地图等功能。

   3.实现地图鹰眼功能。

   4.提供用户测距尺功能。

   5.图层管理功能是指：根据选择图层复选框，来显示（车辆，加油站，轨迹标记）图层。

   6.电子围栏，圆形、矩形、多边形区域报警的功能。

   7.车辆轨迹回放功能

  8.部标808所要求的各种指令下发的功能。

二 油量统计

    针对车辆油耗管理推出的油量监测系统，主要监测汽车油量实时数值，实现车辆偷油报警、油耗报表统计、当前油量查看等功能。客户在车上安装车载终端之后，可以将油箱油量变化数据由车载终端通过GPRS传输到数据库，即会在网络货运车辆监控平台的车辆监控状态中显示车辆实时油量升数，并有油量分析报表等（所有报表可提供下载）。其中油量动态记录汇总表详细记录了车辆的加油量、加油时间、加油地点、行驶里程、预计耗油量、实际耗油量和耗油偏差等。车辆在每一时刻的油量情况，都可以在油量动态明细表里面进行查看。油量动态明细也可以曲线显示，车辆的油量升降情况一目了然，充分满足了客户对车辆油耗的监控需求，可有效防范司机油箱偷油的情况发生。

1)油量动态记录汇总表，显示详细的车辆加油量、行驶里程、预计耗油量、实际耗油量和耗油偏差。

2)车辆在每一时刻的油量情况，都可以在油量动态曲线里面进行查看，每一个记录点都有当前油量数值、日期时间和行驶里程显示，监控系统会自动分析油量曲线情况，一旦油量差异常，就会进行异常提示，并且油量异常的时间、地点、油量差数值都有准确记录，

3)全程监控系统的里程报表可以根据客户设置的在车辆实际百公里油耗和车辆GPS里程计算出车辆实际行驶里程的油耗参考基准量，对车辆油耗的控制提供一个可以参考的标准，里程报表提供下载，客户可根据在网车辆里程报表结合实际管理手段有效杜绝油卡卖油的“超油耗”现象。

4)车辆里程报表详细记录了车辆行驶的起始时间、起始里程、起始地点、结束时间、结束里程、结束地点、行驶里程，油耗等信息，

5)借助全程监控系统，可以对监控车辆设置停车未熄火报警、超速报警，对无效率的油耗浪费和超速带来的高油耗及不安全因素有很好的治理效果。

6)对车辆进行停车未熄火报警设置，车辆超出设置的停车时间系统就会报警，并在停车未熄火明细表中记录停车地点、停车时间等详细信息.

三 监控视频记录

   1）将车辆停车位置，如地点，时间，停车时常，是否是在加油站或油库停车等相关信息显示。

  2）提供视频回放、下载、实时监控的功能;

GPS系统主界面：

(12091)