所以必须要能够开发一款模拟软件来配合我们进行软件开发，可以精确的模拟车辆运行的实际环境，可以能够控制终端进行复杂的测试环境的临界点模拟。很多时候所谓复杂场景指的是各种类型的数据交错综合在一起的场景，在平台监控车辆行为的时候，并不仅仅监控的就是车辆的位置，而是其他方面的数据，所以在测试的时候，需要将位置数据和其他附加数据进行配合的一种模拟，如：

1）在加油站进行加油，首先就需要模拟车辆的位置数据使其进入加油站，Acc熄火，同时还要发送油量数据来模拟加油过程中邮箱油量上升的过程；

2）冷链运输中，需要结合测试用例，来模拟位置，Acc熄火，温度还有车辆冷柜门的开关量等多种数据在不同场景下的临界点模拟；

3）还有一种就是模拟数据触发报警，然后报警触发的各种动作，如模拟速度数据，触发超速报警，超速报警触发终端拍照等；

还有很多的测试用例场景，都不一一列举。

这些测试，传统的测试人员仅仅靠鼠标点击，是做不出来这样的测试的，性能测试也是很难去测试的，常规的web压测工具如loadrunner等无法应用到基于socket通信的808GPS服务器上面。

我们需要开发一个完整的GPS模拟终端，模拟GPS终端的数据发送和接收各种指令并进行应答的行为。需要开发一个完整808协议的模拟终端，实现录音、拍照、参数设置、位置等功能，来对我们的平台进行充分的测试。

开发这样一个工具，需要我们对JT/T 808协议文档进行认真阅读和充分了解，开发一个808GPS服务器，是对数据按照协议格式进行解析，开发一个808模拟终端则是反过来，将数据按照协议格式进行封装并发送给服务器。虽然是一正一反，但是在协议这块难度要大的多，主要的难点如下：

1）模拟808协议所要求的分包；

2）模拟位置数据中的各种附加数据，如里程、油量、温度等；

3）模拟开关量；

4）模拟多媒体上传数据；

我们提供了部标808GPS服务器套装源码4000元，主要包含了808模拟终端源码和808GPS服务器，Socket测试工具源码，如果单独只购买808服务器源码1200元，方便你进行GPS软件平台的快速开发，提高你的开发效率。

部标808GPS服务器源码说明参见：基于部标JT/T 808协议及数据格式的GPS服务器

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

socket测试工具源码说明参见：C# Socket TCP和UDP报文及端口测试工具的开发

(25795)

本版本是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状态和地图图标自定义：

(34035)

显然如果直接将一个以后台数据展现为主的GPS管理平台集成到这样一个物流网站中，会造成界面的不和谐。

我理解客户需求其实主要的要求是简洁，浸入式设计的风格。这一点和我追求的界面设计风格其实是一致的，我觉得监控软件的特点是长时间对着电脑屏幕监控，也就是看的多，所以界面风格要追求保守、简洁，清晰，避免使用3D突起、渐变、五颜六色等风格，更要避免使用动图，造成视觉疲劳，过度追求炫酷界面，则用户体验不持久，时间长了容易审美疲劳。

GPS软件开发者在界面设计的时候，容易与一线用户脱钩，很少有一种简洁、直接、朴素、持久的设计风格，首先考虑的不是信息的组织、用户的体验，而是如何的炫，如何能表现自己很高的设计水平，动感，渐进、半透明、滑门、延迟、手风琴、背景图片等效果，总想用上一用，滥用颜色，这些除了造成视觉疲劳、操作繁琐外，起不到真正的用户体验。

动手前，我确定了GPS部标监控平台的界面设计规范如下：
1.工作区要尽可能大，能够全屏设置，并且能够调整区域大小，同时用户需要看的信息要尽量组合分区集中在一屏当中，避免左右上下拖动；
2.尽量使用鼠标事件来代替按钮，如鼠标移动到某一对象时，显示对象的详细数据，双击对象或记录显示信息等；
3.当数据信息多时，尽量使用标签页，而不是弹出窗口，避免窗口杂乱或信息重复加载；
4.分区: 顶部工具栏，左侧导航区，底部数据信息显示区，中间是监控工作区，右下是报警信息区。
5.界面色调采用灰色、白色和蓝色三种色调。

6.菜单设计，大量增加了快捷菜单，主菜单采用css多层级联的菜单，但是增加了快捷菜单、地图工具栏和终端指令操作命令工具栏，使得用户的常用操作不需要去层层点击主菜单。

如下图所示，采用蓝色图标，白色背景，蓝白相间，正是BootStrap框架的流行色，也和客户物流云平台的网站Theme贴合。

 需要购买源码,用来降低开发成本，加快开发进度的企业用户请联系2379423771@qq.com。

其他版本和不同风格界面的版本的参见一下链接：

Java平台，参见：

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

基于Struts+Spring+Hibernate+Ibatis+Quartz+Mina框架构建部标监控平台

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

(10252)

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

(14440)

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

(12134)

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

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

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

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

(11690)

所以开发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部标平台

(15287)

在当前很多的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，可以出差免费为客户提供技术支持和培训（差旅费用须由客户承担）

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

(15488)

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

(8926)

地图是客户端中不可缺少的一个模块，很多人在设计和画图时候，喜欢加上地图引擎这样高大上的字眼，显得自己的平台有内涵，说白了就是用第三方的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)购买。

(14563)

  

  

  

(13593)

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

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

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

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

1) 性能可扩展方面

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

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

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

2)功能可扩展方面

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

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

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

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

   联系：2379423771@qq.com

(8526)

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

(18751)

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

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

安装压力测试软件

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

(9203)

在开发部标GPS平台中，部标808GPS服务器是系统的核心关键，决定了部标平台的稳定性和行那个。Linux服务器是首选，为了跨平台，开发语言选择Java自不待言。需要购买808GPS服务器源码+808模拟测试终端工具+压力测试工具(1200元)可以联系我: 2379423771@qq.com；jt808服务器代码都是经过众多客户使用检验过的千锤百炼的成熟的版本，协议解析、命令下发、报警解析、数据库入库、数据统计、压力测试等各方面都考虑的非常充分完善，808协议全协议栈的实现，拿到手后，直接就可以使用了，带有库表文档和字段说明。

我们为客户开发的部标服务器基于Mina + Spring + Hibernate + Swing桌面系统开发(基于Netty框架的GPS服务器参见:基于Java Netty框架构建高性能的部标808协议的GPS服务器)，整个服务器的架构特点：

1.通信层：基于Java Mina通信框架进行GPS服务器开发，可以使得整个系统架构清晰，开发者可以专注于协议解析、业务和数据处理；

2.GPS终端协议层：而为了对于扩展终端的接入能力，协议层要具有很好的扩展能力，在解析的时候，根据不同的协议的时候，根据不同的协议同，而决定调用不同的协议解析插件。很多开发者，采用工厂模式是必不可少的，但是代码都是写死的，实际上引入Spring框架，通过良好的接口设计，通过简单的XML配置，就可以接入到系统当中；

3.业务层：对于底层转来的GPS数据，进行分层处理，实时数据入库、32种报警分析、各种报表统计等操作，这些操作，在超过5000台的大规模终端接入的情况下，变得异常复杂，即要保证系统的实时性，必须要提高处理能力，特别是报警分析的能力。

4.内嵌转发服务，支持服务器端的808协议双向转发，服务器接收数据后，还可以将gps数据以808协议的格式转发给其他第三方的平台，也可以接收第三方平台的指令，下方给终端。

5.完整的实现部标808协议的全部协议栈的解析，不是仅仅实现部分协议命令。

6.内嵌808TCPServer和808UDPServer两个Server监听，同时支持TCP和UDP两种协议制式的接入，这样无论终端是UDP协议，还是TCP协议，都可以顺利接入。

808服务器主要用到的库表:

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

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

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

本808服务器对于部标808全部协议栈都进行了充分的支持：

(22367)

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

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

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

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

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

(14734)

(46971)