我们这里所说的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平台，报警误报频繁，频繁的插入数据库，对数据库压力非常的大。

(23788)

在android平台开发终端，首先构建的是Socket通信框架，我们可以选择mina框架作为与部标808服务器通信的全双工socket客户端。

主要工作有：

1.接收数据，基于jt808协议，进行编码和解码，构建解码器和编码器，对收到的字节流进行解析；

2.监听连接状态，当连接断开后，自动进行断线重连；

              终端判断 TCP 连接断开的方法主要有三种：

             ——根据 TCP 协议判断出平台主动断开；

             ——数据通信链路断开；

            ——数据通信链路正常，达到重传次数后仍未收到应答。

3.记录和跟踪日志报文，方便调试；

然后在此基础上，封装一个终端服务TerminalService, 负责与部标808服务器进行逻辑交互。并提供外部接口，供其他模块触发和调用。

1.按照部标808协议文档的要求，完成注册鉴权流程；

     终端在未注册状态下，应首先进行注册，注册成功后终端将获得鉴权码并进行保存，鉴 权码在终端登录时使用。车辆需要拆除或更换终端前，终端应该执行注销操作，取消终端和 车辆的对应关系。

     终端注册后每次在与平台建立连接后，应立即进行鉴权。鉴权成功前终端不得发送其它 消息。终端通过发送终端鉴权消息进行鉴权，平台回复平台通用应答消息。

2.基于SQLite存储终端参数数据，并读取到内存中构建终端参数模型，随时调用和更新终端参数配置；

3.按照参数配置的间隔要求，发送定位数据,并在连接断开的时候，将数据保存在队列中，在指定的时间内，恢复连接后，自动补发给jt808服务器

4.按照参数配置的定时拍照参数要求，调用摄像头，定时拍照上传；

5.按照参数配置的间隔要求，发送心跳；

6.接收平台下发的各种指令，并进行应答；

(16411)

(17813)

1）我们在开发部标协议的GPS服务器，需要解决以下几个问题：

1.      通信服务器固有的连接管理，能够处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理；

2.      海量终端接入的高并发性能；

3.      良好的内存管理，车载终端的连接本事是基于GPRS的无线连接，车辆在野外高速移动过程中，信号处于不稳定状态，虽然是基于长连接，但是这种连接不断的中断和接入，服务器在处理终端接入，数据解析，报警分析，批量入库的时候，能够内存分配合理，不会造成内存泄漏，在百万次的调用中不会造成内存累计上升；

2）要开发一个高性能的GPS服务器的三个主题：

1) 传输：用什么样的通道将数据发送给对方，BIO、NIO或者AIO，IO模型在很大程度上决定了框架的性能。 

2) 协议：采用什么样的通信协议，HTTP或者内部私有协议。协议的选择不同，性能模型也不同。相比于公有协议，内部私有协议的性能通常可以被设计的更优。 

3) 线程：数据报如何读取？读取之后的编解码在哪个线程进行，编解码后的消息如何派发，Reactor线程模型的不同，对性能的影响也非常大。

Netty是业界最流行的NIO框架，可以很好的解决上面三个问题，它的可靠性、高性能和可扩展性已经得到了上百上千的商用项目验证，相对于.NET中的基于完成端口的通信框架，它要优越的多，它的优点总结如下：

1.      API使用简单，开发门槛低；

2.      功能强大，内聚了很多实用的功能，简化用户的开发；

3.      定制性好，通过ChannelPipeline机制可以灵活的进行功能定制和扩展；

4.      性能高；

5.      成熟稳定，社区活跃，Bug的修复周期比较短，新功能不断的被加入，用户可以体验到更多、更实用的功能。

6.      经历了大规模不同行业的商用考验，架构质量得到了充分的验证。

Netty为了向使用者屏蔽NIO通信的底层细节，在和用户交互的边界做了封装，目的就是为了减少用户开发工作量，降低开发难度。ServerBootstrap是Socket服务端的启动辅助类，用户通过ServerBootstrap可以方便的创建Netty的服务端。

3）编码器和解码器的设计

对于jt808协议的解析处理，需要编写自定义的解码器了，目前Netty提供了多个基础编码器可以供开发者进行继承和拓展，开发的时候，需要了解这几个解码器的主要作用，主要用于那些通信数据传输的场景。

为了降低用户的开发难度，Netty对常用的功能和API做了装饰，以屏蔽底层的实现细节。编解码功能的定制，对于熟悉Netty底层实现的开发者而言，直接基于ChannelHandler扩展开发，难度并不是很大。但是对于大多数初学者或者不愿意去了解底层实现细节的用户，需要提供给他们更简单的类库和API，而不是ChannelHandler。

Netty在这方面做得非常出色，针对编解码功能，它既提供了通用的编解码框架供用户扩展，又提供了常用的编解码类库供用户直接使用。在保证定制扩展性的基础之上，尽量降低用户的开发工作量和开发门槛，提升开发效率。

通常我们也习惯将编码（Encode）称为序列化（serialization），它将对象序列化为字节数组，用于网络传输、数据持久化或者其它用途。

反之，解码（Decode）/反序列化（deserialization）把从网络、磁盘等读取的字节数组还原成原始对象（通常是原始对象的拷贝），以方便后续的业务逻辑操作。

Netty预置的编解码功能列表如下：base64、Protobuf、JBoss Marshalling、spdy等。

在GPS行业当中，对于终端通信协议的设计有多种：

1）基于字符串设计的方式，这种方式就是终端发送一个ASCII字符串，然后服务器获取后基于约定的分隔符分割为一个数组，再依次从数组中获取对应下标的数据，这种方式通常是深圳小的硬件公司的技术水平较低的开发团队喜欢采用，这种方式容易理解，但传输字节较多，效率较低，比较占用流量，不适用于基于流量套餐的无线卡传输。

2）基于定长协议的传输。

①　消息定长，例如每个报文的大小为固定长度200字节，如果不够空位补空格。 ②　在包尾增加回车换行符进行分割，例如FTP协议。

③　将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体总体长度） 的字段，通常涉及思路为消息头的第一个字段使用init32来表示消息的总长度。

④　更复杂的应用层协议，例如部标808协议

部标协议数据包设计的特点：

1) 基于分隔符，包头和包围用0x7E来区分一个完整的数据包；

2) 动态包头，不想其他协议在设计的时候，包头长度都是固定长度，而808协议的包头长度是不固定的；

3) 包体是动态长度，长度从包头中读取。

 解码器就是要根据协议设计的数据包的规则，来对字节流进行解析，解码成完整的数据包。Netty提供了一下几种基础的解码器提供给我们，供继承或直接使用：

1）LineBasedFrameDecoder的工作原理是它依次便利ByteBuf中的可读字节，判断看是否有“\n”或者“\r\n”，如果有就以此位置为结束位置，从可读索引到结束位置区间的字节就组成了一行。他是以换行符为结束标志的解码器，支持携带结束符或者不携带结束符两种解码方式，同时支持配置当行的最大长度。如果连续读取带最大长度后任然没有发现换行符，就会抛出异常，同时忽略掉之前读到的异常码流。

2）StringDecoder的功能非常简单，就是将接收到的对象转换成字符串，然后继续调用后面的handler。LineBasedFrameDecoder+StringDecoder组合就是按行切换的文本解码器，它被设计用来支持TCP的粘包和拆包。

3）DelimiterBasedFrameDecoder特殊符号解码器，其已经过滤掉了分隔符。

4）FixedLengthFrameDecoder固定长度解码器，它能够按照指定的长度对消息进行自动解码。利用FixedLengthFrameDecoder解码器无论一次接受到多少数据报，它都会按照构造函数中设置的固定长度进行解码，如果是半包消息，FixedLengthFrameDecoder会缓存半包消息并等待下个包到达后进行拼包，直到取到一个完整的包。

4）基于Netty开发一个部标808协议的服务器，具体的步骤如下：

1）我们使用Netty要做的工作就是编写编码器和解码器，然后按照Netty的要求来编写调用，最后得到一个完整的jt808协议的数据包。

2）按照数据处理链条，分工职责，为了提高终端接入能力和数据分析、入库能力，将终端消息的处理分成独立的五级处理模块，每个处理模块都是异步独立的，每个模块内都含有独立的处理队列，互不影响，提高数据的吞吐量和系统的响应能力。

1）第一级：实时数据解析入库，入库能力决定了客户端所看到的实时数据是否延迟；

2）第二级：报警分析并入库（包括32种jt808协议规定的报警、停车报警和路线偏移报警)，报警分析只有快速分析才能快速的推送到前端客户端；

3)  第三级：消息应答和指令下发，应答可以有一定的延迟，而不影响整个系统性能。

4）第四级：报表统计，由于油量统计、里程统计、上线率统计，需要定时扫描数据库，生成每个时段的数据统计提供给报表查询使用.

5）第五级：日志记录和显示

由于netty和Mina都能非常好的和spring容器集成在一起，引入spring框架，基于面向接口编程，系统可以同时支持netty和mina两种通信框架，用户可以根据自己的环境，通过配置决定是用mina或者是netty。

基于IDEA Maven管理。

5）连接管理和日志报文监控

在windows系统，可以运行swing界面进行监控，如果运行在阿里云的linux系统上，可以直接编写java shell脚本，基于后台服务运行，通过java 命令来调用当前的连接，日志监控，主要依赖于log文件。

6) jt808系统源码易于和第三方系统如PHP平台进行集成，提供了接口和清晰的数据库文档。

jt808服务器代码都是经过众多客户使用检验过的千锤百炼的成熟的版本，协议解析、命令下发、报警解析、数据库入库、数据统计、压力测试等各方面都考虑的非常充分完善，808协议全协议栈的实现，拿到手后，直接就可以使用了，带有库表文档和字段说明。

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

808服务器主要用的库表： 

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

(30295)

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

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报文及端口测试工具的开发

(26099)

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

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

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

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

JT/T 808标准若干问题的补充说明

1.        

消息ID：0×0100。

终端注册消息体数据格式见表6。

表6终端注册消息体数据格式

2.        

表11 终端参数设置各参数项定义及说明

3.        

表20附加信息定义

4.        

8.42多媒体数据上传

消息ID：0×0801。

多媒体数据上传消息体数据格式见表66。

表66多媒体数据上传消息体数据格式

5.        

表71多媒体检索项数据格式

6.        

8.49单条存储多媒体数据检索上传命令

消息ID：0×8805

单条存储多媒体数据检索上传命令消息体数据格式见表74。

表74 单条存储多媒体数据检索上传命令消息体数据格式

关于对JT/T 809标准若干问题的补充说明

1.        

4.3.1.1.2 主链路保持流程

c)在没有应用数据包往来的情况下，下级平台连续3min未收到上级平台发送的主链路保持应答数据包，则认为与上级平台的连接中断，将主动断开数据传输主链路。

2.        

4.3.3.7 上报驾驶员身份信息

a)    上级平台通过向下级平台发送某车辆上报驾驶员身份信息的请求，下级平台接收到请求后，应将指定车辆的当前营运驾驶员身份信息上报给上级平台。上级平台接收到驾驶员身份消息后，进行入库记载。

b)    下级平台在接收到车载终端上传的驾驶员身份信息后，进行合法性验证并将结果主动向上级平台上报。上级平台接收到驾驶员身份消息后，进行入库记载。

3.        

4.3.3.9 主动上报车辆电子运单信息消息

下级平台在车辆电子运单信息更新时，立即向上级平台上报车辆当前电子运单信息。上级平台接收到电子运单信息后，进行入库记载。

4.        

4.4.6 数据头

表3 数据头格式

5.        

4.4.8 数据校验

从数据头到校验码前的CRC16-CCITT的校验值，遵循大端排序方式的规定。CRC16-CCITT码生成多项式为x¹⁶+x¹²+x⁵+1，简记式1021。

6.        

4.4.7.3 加密算法

加密解密为同一算法，见表5。

表5 加密算法

7.        

4.5.3.1.2 上传车辆注册信息消息

子业务类型标识：UP_EXG_MSG_REGISTER。

描述：监控平台收到车载终端鉴权信息后，启动本命令向上级监管平台上传该车辆注册信息，各级监管平台再逐级向上级平台上传该信息，其数据体规定见表19。本条消息服务端无需应答。

表19上传车辆注册信息消息数据体

8.        

4.5.3.1.10 上报驾驶员身份信息识别应答消息

子业务类型标识：UP_EXG_MSG_REPORT_DRIVER_INFO_ACK。

描述：下级平台应答上级平台发送的上报驾驶员身份识别信息请求消息，上传指定车辆的驾驶员身份识别信息数据，其数据体规定见表27。

表27 上报驾驶员身份识别信息应答消息数据体

9.        

4.5.3.1.12 主动上报驾驶员身份信息消息

子业务类型标识：UP_EXG_MSG_REPORT_DRIVER_INFO。

描述：下级平台在接收到车载终端上传的驾驶员身份信息后，主动向上级平台上报该信息，其数据体规定见表29。本条消息客户端无需应答。

表29主动上报驾驶员身份信息消息数据体

10.   

4.5.3.1.13 主动上报车辆电子运单信息消息

子业务类型标识：UP_EXG_MSG_REPORT_EWAYBILL_INFO。

描述：下级平台主动上报车辆电子运单信息，向上级平台上报车辆当前电子运单，其数据体规定见表30。

表30主动上报车辆电子运单信息消息数据体

11.   

4.5.3.2.2 交换车辆定位信息消息

子业务类型标识：DOWN_EXG_MSG_CAR_LOCATION。

描述：上级平台在以下四种情况下通过该消息不间断向下级平台发送车辆定位信息。

(1)   车辆跨域时，上级平台通过该消息不间断地向车辆进入区域所属的下级平台发送车辆定位信息，直到该车辆离开该区域；

(2)   人工指定车辆定位信息交换时，上级平台通过该消息不间断地向指定交换对象下级平台发送车辆定位信息，直到人工指定交换车辆定位信息结束；

(3)   下级平台向上级平台申请交换指定车辆定位信息成功后，上级平台通过该消息不间断地向交换对象下级平台发送车辆定位信息，直到申请交换指定车辆定位信息结束；

(4)   应急状态监控车辆时，上级平台向车辆归属下级平台通过该消息不间断地发送车辆定位信息，实现车辆定位信息回传。

12.   

4.5.3.2.10 上报驾驶员身份识别信息请求消息

子业务类型标识：DOWN_EXG_MSG_REPORT_DRIVER_INFO

描述：上级平台向下级平台下发上报车辆驾驶员身份识别信息的请求消息，其数据体规定见表40。

表40 上报驾驶员身份识别信息请求消息数据体

13.   

4.5.4.1.2 平台查岗应答消息

子业务类型标识：UP_PLATFORM_MSG_POST_QUERY_ACK。

描述：下级平台根据查岗对象的类型将上级平台发送的不定期平台查岗消息发送到不同的查岗对象，并将不同查岗对象的应答分别转发给上级平台，其数据体规定见表43。

表43 平台查岗应答消息数据体

14.   

表44 查岗对象类型定义表

15.   

4.5.4.1.3 下发平台间报文应答消息

子业务类型标识：UP_PLATFORM_MSG_INFO_ACK。

描述：下级平台收到上级平台发送的下发平台间报文请求消息后，根据相应的下发报文对象类型，进行转发，并向上级平台发送应答消息，其数据体规定见表45。

表45 下发平台间报文应答消息数据体

16.   

4.5.4.2.2 平台查岗请求消息

子业务类型标识：DOWN_PLATFORM_MSG_POST_QUERY_REQ。

描述：上级平台不定期向下级平台发送平台查岗信息，其数据体规定见表47。

表47 平台查岗请求消息数据体

17.   

4.5.4.2.3 下发平台间报文请求消息

子业务类型标识：DOWN_PLATFORM_MSG_INFO_REQ。

描述：上级平台不定期向下级平台下发平台间报文，其数据体规定见表48。

表48 下发平台间报文请求消息数据体

18.   

表49 下发报文对象类型定义表

19.   

4.5.5.1.4 主动上报报警处理结果信息消息

子业务类型标识：UP_WARN_MSG_ ADPT _TODO_INFO。

描述：下级平台向主动向上级平台上报报警处理结果，其数据体规定见表53。本条消息上级平台无需应答。

表53 主动上报报警处理结果信息消息数据体

20.   

表60 车辆拍照应答消息数据体

21.   

4.5.6.1.5 上报车辆行驶记录应答消息

子业务类型标识：UP_CTRL_MSG_TAKE_TRAVEL_ACK。

描述：下级平台应答上级平台下发的上报车辆行驶记录请求消息，将车辆行驶记录数据上传至上级平台，其数据体规定见表62。

表62 上报车辆行驶记录应答消息数据体

22.   

4.5.6.2.5 上报车辆行驶记录请求消息

子业务类型标识：DOWN_CTRL_MSG_TAKE_TRAVEL_REQ。

描述：上级平台向下级平台下发上报车辆行驶记录请求消息，其数据体规定见表68。

表68 上报车辆行驶记录请求消息数据体

23.   

4.5.6.2.6 车辆应急接入监管平台请求消息

子业务类型标识：DOWN_CTRL_MSG_EMERGENCY_MONITORING_REQ。

24.   

表79 子业务类型名称标识对照表

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

(25952)

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

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

(10646)

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

(14607)

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

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

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

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

(11861)

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

(13417)

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

(14711)

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

(19108)

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

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

安装压力测试软件

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

(9410)

在开发部标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全部协议栈都进行了充分的支持：