苏标是江苏省交通厅发布的道路运输车辆主动安全智能防控系统的平台技术规范，现有的设备厂商如海康、经纬视觉、锐明，有为等厂商已经支持，都已经接入我的平台运营。苏标平台，依赖于具有主动安全终端设备，一般是通过加装特制摄像头或者雷达等外设来达到主动安全功能的。目前运营的效果来看，由于径卫视觉的设备比较麻烦，直接用的是博实结的部标视频1078模块，再加上自己模块，售后就经常需要博实结的人参与，两家一块找问题，维护起来就不是那么容易。

下图是海康威视的苏标主动安全终端设备的配置。

苏标平台架构设计参见文章:基于Redis + RabbitMQ的苏标主动安全平台架构设计

沪标主动安全平台系统架构和功能列表

Netty4 + SpringBoot2 + RabbitMq + Redis + AliOSS 构建高性能粤标主动安全平台

主动安全协议-广东标准(粤标)和江苏标准(苏标)的区别及平台开发

如需增加GB28181的视频转发功能, 可以参阅文章

GB28181协议和JT1078视频服务器的区别和集成

苏标的主动性，在于通过视频算法分析，主动判断出司机驾驶行为是否违反驾驶行为规范，并触发报警，如前向碰撞报警、车道偏离报警、车距过近报警、疲劳驾驶报警、分神驾驶报警、接打电话报警、抽烟报警、驾驶员异常报警、胎压异常报警等。在发生报警的时候，可以上传违章证据到服务器平台，如视频，图片和记录仪数据等。

可以看到苏标平台，增加了大量的报警，每个报警还继续细分为一级和二级报警。企业安全监控平台应实现对车辆主动安全报警信息的实时处理，终端根据车速与报警参数将报警分为一级报警和二级报警，具体分级策略参见终端技术规范，平台接收到报警时应区分报警级别进行处理，具体措施如下：

a)  平台接收到一级报警时，应当记录报警信息并存档；

b)  如车辆在单位时间内上报一级报警达到一定数量，平台应产生一条驾驶员分神驾驶的二级报警。

c)  平台接收到二级报警时，应记录报警信息并存档，同时应以声音或图像的方式提醒监控人员。

与常规报警不同的是，苏标Adas报警在产生等级较高的报警的时候，会在终端产生报警时主动记录前后几秒钟的视频录像文件，拍照和行车数据文件，上传给平台后，又有体积较小，可以快速的传递给平台。一般在报警的时会产生7个附件，三个图片，三个通道的mp4录像文件，一个记录仪的二进制文件。苏标协议要通过附件指令，要求设备按照苏标的附件上传协议，上传附件到指定的服务器接收，所以必须要开发一个专用的苏标附件服务器，这个服务器的职责就是解析附件数据，附件协议的复杂性在于附件的高频上传，一次报警会产生N个文件列表，当车辆规模达到一定程度的时候，在同一秒，对于一个普通的万辆车规模的监控平台，将可能有几百辆车在同时报警并上传附件数据，特别是像车道偏离这样高频报警，对附件服务器的解析性能，存储性能都有极大的挑战。

 报警的时候，将会产生比GPS定位记录还有多的数据，一次报警，将会产生至少一个报警记录，四到7个附件记录。

附件上传完毕后的消息推送，可以采用ActiveMQ, 或RabbitMQ的消息队列，将附件数据和报警信息糅合成一个苏标报警消息快速的传递给前端展示。所以苏标报警信息的展示的信息量是很丰富的，有文字，图片和视频同时展示给用户。如需购买平台源码, 请联系2379423771@qq.com

        苏标设备产生的数据、报警关联的报警附件等也需要通过809协议上传到运管平台上面去，为此苏标也对809协议进行了扩展，增加多个指令，以支持企业平台上传报警文件和报警消息。

        所以一个主动安全平台，本身是一个三合一的平台，包含了GPS、视频和主动安全三大功能体系以及相互联动衍生的功能，所以架构也更加复杂，在后端服务器模块，需要构建同时  兼容部标808协议指令、视频1078指令和苏标协议指令的网关服务器、部标1078视频服务器和苏标Adas服务器等多个子系统。苏标在部标1077视频平台基础之上，又额外提了对于主动安全、驾驶员考核与分析的新的功能要求。

       由于苏标协议已经运行一年多, 从设备厂商到平台软件开发者对于苏标的支持力度都很大, 苏标协议标准实际上已经成为其他各省仿效的标准, 目前陕标和川标浙标都是直接拿来主义,  将苏标作为自己的标准使用,  设备厂商从开发成本的角度也不可能原因每个省都标新立异搞一个自己的标准, 目前全国各地基本上在主动安全上面, 都已经将苏标标准作为一个核心标准, 在第三方平台接入\设备接入\招投标方面, 都是以苏标文档中要求的功能标准和协议标准作为门槛准入的最低条件.

苏标主要的功能列表如下所示：        

1企业安全监控平台功能

1.1  基础功能

企业安全监管平台基本功能应满足JT/T 796 中第6章描述的所有功能。

1.2  扩展功能

1.2.1  用户管理

第5章5.2 用户管理中描述的功能。

1.2.2  报警类型

企业安全监控平台应支持接收由主动安全智能防控终端触发前向碰撞报警、车道偏离报警、车距过近报警、疲劳驾驶报警、分神驾驶报警、接打电话报警、抽烟报警、驾驶员异常报警、胎压异常报警等。

报警信息实时监控及处理

a)  平台接收到一级报警时，应当记录报警信息并存档；

b)  如车辆在单位时间内上报一级报警达到一定数量，平台应产生一条驾驶员分神驾驶的二级报警。

c)  平台接收到二级报警时，应记录报警信息并存档，同时应以声音或图像的方式提醒监控人员。

企业安全监控平台应能够存储平台内车辆的主动安全智能防控相关信息，报警信息包含报警类型，报警等级，报警开始时间，报警结束时间，报警时车速，经纬度，高程。

1.2.4  报警查询

a)  支持按驾驶员查询报警信息。

b)  支持按车辆牌照查询报警信息。

c)  支持按照报警类型、报警等级查询报警信息。

d)  支持按时间段查询报警信息。

e)  支持对所查询报警信息相关音视频、照片证据的回放及导出。

f)  支持查询信息报表生成功能，生成包含查询时间段、查询发起方身份、详细报警信息等在内的查询报表，并应支持报表的导出功能。

1.2.5  报警信息统计与分析

a)  支持对企业报警类型进行统计分析，可直观展现各种类型报警变化趋势和相对比例。

b)  支持对企业内驾驶员关联报警进行分析，可形成驾驶员驾驶行为统计报表。

c)  支持对企业内车辆关联报警进行分析，行成车辆报警统计分析图。

1.2.6  驾驶员档案管理

企业安全监控平台应当设立驾驶员档案库。支持将驾驶员信息录入驾驶员档案库的功能。驾驶员档案库信息应包含驾驶员个人信息、驾照信息、正面照等相关信息。

驾驶员分析

企业安全监控平台应支持根据驾驶员相关驾驶行为数据、百公里报警数据对驾驶员驾驶行为进行综合分析及评价的功能，平台应能够按照相应指标对驾驶员驾驶行为进行周期性评分，评分结果应能保存到驾驶员档案库中，平台用户可按照不同标准对驾驶员评分进行排序、筛选操作。

1.2.8  车辆终端信息管理

企业安全监控平台应当支持对主动安全智能防控终端安装信息的管理。所有入网车辆所安装的主动安全智能防控终端品牌及型号应当在企业安全监控平台中详细记录。平台应支持按照车牌号、所安装主动安全智能防控终端的品牌型号等条件查询相关车辆信息，且支持对于车辆安装信息的更新、修改及删除。

1.2.9  接收信息与展示

企业安全监控平台应具备接收政府监管平台下发的信息，并能够提示企业管理人员。

1.2.10  终端在线升级

企业安全监控平台应支持对车载终端的在线升级推送功能，当有车载终端软件升级包时，平台向终端发起在线升级指令，终端根据平台提供的升级包下载地址获取升级包进行自动升级，并在升级成功后向平台发送升级成功指令，平台同时记录升级后的终端软件版本信息。

平台支持在线升级策略管理，包含单位批次数量、定时升级任务以及选定设备手动升级等功能。

1.2.11  驾驶员身份识别功能

企业安全监控平台应支持人脸识别功能，当车载终端发送驾驶员身份识别指令时，平台应根据指令上报的驾驶员IC卡号以及驾驶员照片进行比对，当驾驶员IC卡与驾驶员不对应时，则平台记录一条驾驶员身份不匹配的报警信息，同时提醒企业监控人员进行处理。

当上报的驾驶员照片信息无法识别，则平台提醒企业监控人员进行人工核对。

(23025)

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

(23233)

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

主要工作有：

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

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

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

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

             ——数据通信链路断开；

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

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

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

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

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

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

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

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

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

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

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

(15862)

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

(29263)