表 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文件

(19340)

(18013)

通信协议是通信双方进行交互时所约定的标准语言，部标808协议和809协议、796和794标准虽然都是交通部主持设计的，但是单从这个数字代码，让人迷惑，理解这两个协议和两个标准，对于掌握整套部标标准，起着至关重要的作用。

1.通信场景

他们是基于不同的通信场景，不同的通信对象，不同的设计目的和目标而制定出来的。首先要知道这些标准的全称是什么意思，Jt808标准的全称是《道路运输车辆卫星定位系统终端通讯协议及数据格式》,jt809标准的全称是《道路运输车辆卫星定位系统平台数据交换》，796标准的全称是《道路运输车辆卫星定位系统平台技术要求》，794标准的全称是《道路运输车辆卫星定位系统车载终端技术要求》，从字面意思就很容易理解到：808协议适用于GPS定位车载终端和监控平台之间的通信。通信协议采用 TCP或 UDP，平台作为服务器端，终端作为客户端，而809协议则是适用于企业的GPS监控平台与政府运管平台之间的交互通信，通信协议限定为TCP协议，企业监控平台明确为协议中的下级平台，政府运管平台明确为上级平台。交通部796标准是软件平台的功能标准，794则是终端的功能标准。

具体每个标准的详细内容，参见：交通部道路运输车辆卫星定位系统部标JTT808、809、796标准大全 

2019年交通部GPS平台检测标准发生了重大变化, 原来的796平台功能标准, 变更为GB/T35658标准, 全称是<<GB∕T 35658-2017 道路运输车辆卫星定位系统 平台技术要求>>, 参见文章:

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

苏标协议是江苏省交通厅发布的道路运输车辆主动安全智能防控系统的平台技术规范，现有的设备厂商如海康、经纬视觉、锐明，有为等厂商已经支持，都已经接入我的主动安全平台运营。苏标平台，依赖于具有主动安全防控终端设备，一般是通过加装特制摄像头或者雷达等外设来达到主动安全功能的。苏标本身仍然是基于部标808协议的基础上递增起草的，增加了主动安全报警和报警附件上传的协议和功能规范，所以它还是部标的范畴，一个基于苏标的平台，必然是一个符合部标808协议的gps部标平台,同时也必须是一个1077部标视频平台,参见文章:

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

交通部与2016年10月份推出了JT/T 1078-2016标准，全称是<道路运输车辆卫星定位系统视频通信协议>。该标准将改变以往两客一危车辆的视频监控设备通信协议都是设备厂商私有协议的局面。标准起草单位：中国交通通信信息中心、北京国交信通科技发展有限公司、江苏威森通讯科技有限公司、大连信开数码软件有限公司、深圳市锐明视讯技术有限公司、广州亿程交通信息有限公司、深圳市瑞信视讯技术有限公司、吉林省寰旗卫星导航通信集团有限公司、杭州海康威视数字技术股份有限公司、大连鼎视科技有限公司。这里面真正做视频老牌厂商也就是海康、大华这两家公司。 部标1078协议和808协议的区别参见文章:

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

2019年, 交通部通信信息中心又推出了部标808-2019版本和部标809-2019版本, 与2011版本的区别参见:

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

2.应用场景

如果你获取GPS定位数据，是从终端接入获取的，就使用或者开发808Gps服务器，参见:基于Java Netty框架构建高性能的部标808协议的GPS服务器

如果你需要从第三方平台获取GPS定位数据，即接入第三方平台，就需要使用或者开发809Gps服务器。参见:基于部标Jt/T809协议和Java Netty框架构建Gps位置监控平台

如果需要给其他平台转发数据，则可以根据双方约定，可以使用809协议转发，也可以用808协议转发，协议本来就是双方约定遵守的规则，只要双方同意，即使不用808809，自己设计协议也可以。

如果你是开发终端，需要阅读794标准和808协议文档。

如果你是开发平台的，需要阅读796功能标准和808协议、809协议文档，通常一个标准的796平台，包含808服务器，809服务器和web平台，参见：交通部796部标平台开发索引

3.包含关系

既然796是平台的全面综合功能标准，则其中的一项要求必然是符合808协议标准，能够接入符合808协议的车载终端，所以796标准是包含808协议标准，符合796标准的平台必然能够接入符合808协议的车载终端，但反过来能接入部标终端的平台不一定是符合796的功能标准，特别是web平台的功能标准，需要经过部标平台检测后，才能认定为796平台。

794是终端硬件设备的全面综合功能标准，必然也是包含808协议标准，必须能够接入部标平台当中。

由于现在终端设备都是GPS和行车记录仪是一体化的一体机，所以在808协议中，对记录仪协议的标准进行了封装，即消息体用的是记录仪标准19056. 也就是说部标终端必然是符合GB/T 19056  汽车行驶记录仪  标准的终端。

部标协议和北斗标准的区别，参见文章：北斗和交通部部标808的关系

4.消息包结构区别

808消息头内容如下表所示：

消息体属性格式结构图如图 2所示：

808协议的数据报文的标示是0x7E开头和0x7E结束的报文。808协议只有一层，命令类型是靠消息Id来区分的。

809的协议结构比较复杂，采用多层结构，有主消息Id，主消息下面还有子分类，子分类靠子消息Id进行区别。区分808协议报文的标示是0x5B开头，0x5D结束的报文。

5.加密机制和校验码的区别

808协议和809协议都有加密机制，但是各不相同，在部标检测和实际运用中，终端发送数据都不加密，部标808协议设计的加密机制也不可行，经过加密后，数据体超大，耗费流量，不适合无线GPRS通信。

但是809协议，在部标检测中是肯定要测试加密解密的，实际运用中有的平台加密，有的平台不加。

808协议和809协议的校验码的算法不同，809协议的校验机制更复杂一点。

808协议的数据报文校验码算法如下：

809协议的数据报文校验码算法如下：

6.通信链路的区别

部标808协议是一个链路全双工通信，连接的维持，靠心跳包，实际上都是这么设计的也没有什么可说的。

唯独809协议的设计者估计是个纸上谈兵的家伙，设计一个变态的双链路机制，设计了主链路和从链路，设计比较复杂，实现难度也比较大，部标检测中这一环节耗时最多，也最容易失败。

实际开发过程中，主从链路的建立、维持、管理以及那些命令从主链路下发，那些命令从从链路下发，都容易把开发者搞的七荤八素的，耗费了不少的时间。如果是开发上级平台，更加麻烦，一个上级平台对应多个下级平台，每个交互都要构建两个连接。809的缺点是设计太过于复杂，前戏太多，很多政府运管平台都特别的不稳定，三天两头的重启，坑苦了下级的企业平台接入。

双链路的设计也是非常滑稽的，一个链路本来就是全双工通信，两个链路并不能增加平台的通信连接稳定。因为如果两侧无论那一侧挂机，再多的链路设计也是白扯，都会断掉。

7.版本变化

808协议和809协议基本都是同步的，2011年第一个版本，2012年做了补充，2013在2011、2012补充的基础上，再次做了新的修订，作为一个新版本2013版本，这个版本比较稳定，一直用到现在，没有再做变动。 

8.交通部要求

《JT/T 794 道路运输车辆卫星定位系统车载终端技术》要求如下：

对于已经取得道路运输证但尚未安装车载终端的营运车辆，道路运输管理部门要督促道路运输企业按照规定加装符合标准的车载终端，并接入全国重点营运车辆联网联控系统。从2012年1月1日起，没有按照规定安装车载终端或未接入全国重点营运车辆联网联控系统的运输车辆，道路运输管理部门暂停其资格审验。

从2011年7月1日起，所有新安装的车载终端必须接入符合技术要求的系统平台。系统平台如不符合《796平台标准》的，要按《796平台标准》技术要求尽快进行改造。在系统平台改造过程中要采取有效措施，确保现有业务不受影响，并确保各级系统平台之间的互联互通。各系统平台的改造工作，要在2011年底前完成。

(62885)

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

(30628)

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

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

(26364)

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

(34583)

显然如果直接将一个以后台数据展现为主的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部标平台

(10538)

   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 子业务类型名称标识对照表