上海市交通运输行业协会在2019年发布的主动安全平台标准, 简称沪标, 沪标也是以苏标主动安全标准为基础做了进一步的改造,  但改动地方相对多一些, 特别是有重点的对驾驶员监管方面, 比如人脸识别, 超载等方面做了加强. 主要包含以下四个标准规范,

1) T/SHJX 012—2019《道路运输车辆主动安全智能防控系统 （平台技术规范）》

2) T/SHJX 013—2019《道路运输车辆主动安全智能防控系统 （平台通讯协议规范）》

3) T/SHJX 014—2019《道路运输车辆主动安全智能防控系统 （终端技术规范）》

4) T/SHJX 015—2019《道路运输车辆主动安全智能防控系统 （终端通讯协议规范）》

主要规范了道路运输车辆主动安全智能防控系统架构，以及道路运输车辆主动安全智能防控系统中上海市重点营运车辆联网联控系统和道路运输企业监控平台的功能要求、性能要求与技术要求等内容，以指导道路运输车辆主动安全智能防控系统上海市重点营运车辆联网联控系统和道路运输企业监控平台的建设，特制定本标准。

参与制定的会员企业

本标准主要起草单位：上海英迪信息技术有限公司上海中安电子信息科技有限公司上海赛格车圣导航科技有限公司上海英杰特信息技术有限公司上海卫脉信息技术有限公司. 这些公司基本都是第一批就过了沪标检测.

规范要求平台需要支持以下几种部标标准协议要求:

1) GB/T 35658智能运输车辆卫星定位系统平台技术要求

2) JT/T 808 道路运输车辆卫星定位系统终端通讯协议及数据格式

3) JTT 809 道路运输车辆卫星定位系统–平台数据交换

4) JT/T 1077 道路运输车辆卫星定位系统车载视频平台技术要求

5) JT/T 1078 道路运输车辆卫星定位系统车载视频通信协议

道路运输车辆主动安全智能防控系统的架构设计

道路运输车辆主动安全智能防控系统包含卫星定位子系统、视频子系统、主动安全报警子系统，其中卫星定位子系统和视频子系统应符合JT/T808、JT/T809、GB/T35658、JT/T1077及JT/T1078等标准中的要求。

主动安全报警子系统包含上海市重点营运车辆联网联控系统、道路运输企业监控平台、主动安全智能防控终端以及主动安全智能防控平台与主动安全智能防控终端间的通讯网络。通过各组成之间的互联互通，实现卫星定位、视频监控、主动安全智能防控管理以及数据存储、分析、交换和共享。主动安全智能防控平台与用于位置监控和视频监控的平台在实际应用中可以是同一软件系统的不同功能模块。

上海市重点营运车辆联网联控系统与道路运输企业监控平台之间通过原联网联控通信链路进行连接，主动安全智能防控终端与道路运输企业监控平台之间通过无线通信网络单链路连接，实现对车载主动安全智能防控终端所采集的报警数据进行查询、统计、分析以及管理等功能。道路运输车辆主动安全智能防控系统主动安全报警子系统架构如图1所示

平台需要通过沪标检测认证,

目前检测单位主要是:交通部信息中心指定的几家检测机构,如交通运输通信信息工程质量检测中心,石家庄54所等机构检测认证. 

本平台已经通过沪标的检测, 如需购买源码, 可以联系2379423771@qq.com

5上海市重点营运车辆联网联控系统

5.1基础功能

上海市重点营运车辆联网联控系统基本功能应满足GB/T35658和JT/T 1077相关功能。

5.2扩展功能

5.2.1用户管理

用户管理应满足JT/T 1077中第5章5.2用户管理中描述的功能。

5.2.2.报警类型

上海市重点营运车辆联网联控系统可接收接入平台上报的报警主要包含车辆前向碰撞报警、车道偏离报警、车距过近报警、疲劳驾驶报警、分神驾驶报警、抽烟报警、接打电话报警、驾驶员异常报警、DSM摄像头被遮报警等。

5.2.3.报警管理

上海市重点营运车辆联网联控系统应具备接收接入平台上报的车辆报警信息及对应的报警处理信息的功能。

5.2.4.报警信息分析

5.2.4.1报警展示

报警展示功能可具备根据不同分类对接入平台上报的报警信息进行处理功能，支持按照报警类型、车辆类型、企业对报警信息进行分类汇总、展示分析，并支持将汇总结果、分析结果以直观统计图表展现。

5.2.4.2驾驶员分析

上海市重点营运车辆联网联控系统可具备通过报警数据分析对驾驶员的驾驶行为进行统计分析的功能，能够按照不同报警类型、报警数量、报警等级等相关信息，按照管理规定生成驾驶员驾驶行为统计报表，也可具备用户按照驾驶员信息字段进行查询的功能。

5.2.5企业运营分析

5.2.5.1企业车辆数据分析

上海市重点营运车辆联网联控系统应能够实现对所有入网企业的车辆数据进行分析，按照需求生成不同类型的分析报表，支持显示企业当前车辆入网数量、在线数量、入网率、在线率等相关信息，能够以图表等直观形式显示企业一段时间内在线率等相关信息的变化规律。

5.2.5.2企业报警处理情况分析

企业报警处理情况分析主要包含对所有入网企业报警信息处理、处理情况的分析，应能按照用户需求生成不同类型的分析报表。支持显示企业所有报警信息的处理响应时间和结果等相关信息，并支持按照分析选定时间段、报警等级、车辆类型分类方式分析企业报警处理响应时间、处理率等指标。

5.2.5.3企业运营管理统计分析

上海市重点营运车辆联网联控系统可具备对所有入网企业运营管理情况进行统计的功能，支持按照车辆入网率、在线率、报警处理响应时间、处理率等相关指标综合评价企业一定时间内的运营管理情况，并生成企业运营管理统计分析结果。统计分析规则应根据管理部门相关管理办法进行。

5.2.6.信息管理与发布

上海市重点营运车辆联网联控系统应当能够向接入平台发布相关信息、政策。

6道路运输企业监控平台功能

6.1基础功能

企业安全监管平台基本功能应满足GB/T35658和JT/T 1077相关功能。

6.2扩展功能

用户管理用户管理应满足JT/T 1077中第5章5.2用户管理中描述的功能。

6.2.2.报警类型

道路运输企业监控平台应支持接收由主动安全智能防控终端触发前向碰撞报警、车道偏离报警、车距过近报警、疲劳驾驶报警、分神驾驶报警、接打电话报警、抽烟报警、驾驶员异常报警、DSM摄像头被遮报警等。报警信息实时监控及处理道路运输企业监控平台应实现对车辆主动安全报警信息的实时处理，终端根据车速与报警参数将报警分为一级报警和二级报警，具体分级策略参见终端技术规范，平台接收到报警时应可分析并对报警级别进行分析处理，具体措施如下：

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

b) 如车辆在单位时间内上报报警达到一定数量，平台应产生一条驾驶员主动安全的高级别报警

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

d) 平台应支持监控人员对主动安全报警进行实时处理，记录报警处理结果信息并存档。道路运输企业监控平台应能够存储平台内车辆的主动安全智能防控相关信息，报警信息包含报警类型，报警等级，报警开始时间，报警结束时间，报警时车速，经纬度，高程。

6.2.4.报警远程调视频（危险品）

当危险品车辆发生超速、出入禁行区域报警、JT/T 808规定的疲劳驾驶报警，平台应通过远程调阅视频方式或终端主动将报警发生前后5秒（时间可设定）视频保存平台。

6.2.5.报警远程调视频（客车）

当客车车辆发生2-5点报警、超速、JT/T 808规定的疲劳驾驶报警，平台应通过远程调阅视频方式或终端主动将报警发生前后5秒（时间可设定）视频保存平台。

6.2.6.报警查询

道路运输企业监控平台应能够实现对所有相关企业车辆报警信息的查询，按照需求生成不同类型的查询报表，具体要求如下：

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

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

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

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

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

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

6.2.7.报警信息统计与分析

道路运输企业监控平台应能够实现对所有相关企业车辆报警信息的分析，按照需求生产不同类型的分析，具体要求如下：

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

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

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

6.2.8超员检测（客车）

车辆运营过程中，企业平台具备接受车载终端定时抓拍的车厢照片，并通过图像算法分析客车是否超员，并提供相关的报表查询功能。

6.2.9.驾驶员档案管理

道路运输企业监控平台应当设立驾驶员档案库。支持将驾驶员信息录入驾驶员档案库的功能。驾驶员档案库信息应包含驾驶员个人信息、驾照信息等相关信息，同时支持建立包含正面照在内的驾驶员人脸库。

6.2.10.司机身份识别

企业平台应能够接收来自终端设备定时抓拍司机正脸图片，通过人脸识别算法，以及平台存储的司机人脸库信息，识别出司机身份。

6.2.11.非法司机报警

企业平台应能够通过人脸识别技术，鉴别司机是否合法合规，一旦判定司机不合法合规，即时报警。

6.2.12.驾驶员分析

道路运输企业监控平台应支持根据驾驶员相关驾驶行为数据对驾驶员驾驶行为进行综合分析的功能，平台应能够按照相应指标对驾驶员驾驶行为进行周期性统计，平台用户可按照不同标准对驾驶员驾驶行为进行统计分析。

6.2.13.车辆终端信息管理

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

6.2.14.接收信息与展示

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

6.2.15.终端在线升级

道路运输企业监控平台应支持对车载终端的在线升级推送功能，当有车载终端软件升级包时，平台向终端发起在线升级指令，终端根据平台提供的升级包下载地址获取升级包进行自动升级，并在升级成功后向平台发送升级成功指令，平台同时记录升级后的终端软件版本信息。平台支持在线升级策略管理，包含单位批次数量、定时升级任务以及选定设备手动升级等功能。

6.2.16.移动终端支持

企业平台应提供移动终端接入展示功能，至少提供实时位置和轨迹回放、视频点播和回放、报警展示，移动端产品形式可以为手机APP或微信公众号等方式。

7主动安全智能防控平台性能与技术指标

7.1主动安全智能防控平台总体性能

主动安全智能防控平台总体性能应至少满足以下要求：

a) 支持平台7×24h不间断运行；

b) 在没有外部因素影响的情况下，故障恢复时间不超过120min；

7.2应急与报警信息响应时间

报警及报警信息处理至少满足以下要求：

a) 应急与报警信息响应时间不超过10min；

b) 优先保证报警信息及报警处理信息显示。

7.3主动安全智能防控平台

车辆接入性能主动安全智能防控平台车辆接入系统应满足以下要求：

a) 具有主动安全报警数据高并发处理能力：平均1000条/s、峰值3000条/s。

b) 道路运输企业监控平台能支持至少10，000台主动安全智能防控终端接入。

c) 上海市重点营运车辆联网联控系统能支持至少100，000台主动安全智能防控终端接入。

7.4主动安全智能防控平台响应时间

最大并发用户数达到其系统设计要求时，各事务平均响应时间不应超过单用户平均响应时间的五倍。

7.5网络传输网络传输环境应满足以下要求：

a) 上海市重点营运车辆联网联控系统之间支持专线网络或互联网VPN连接；

b) 道路运输企业监控平台支持互联网或专线网络等方式连接上海市重点营运车辆联网联控系统。

7.6报警数据存储

主动安全智能防控相关数据存储及备份要求如下：

a) 报警信息数据存储时间不得少于183天；

b) 报警多媒体附件数据存储时间不得小于90天；

c) 上海市重点营运车辆联网联控系统离线保存的报警多媒体数据存储时间不得小于365天。

d) 建立报警信息数据备份机制，每周对数据进行增量备份，每月对报警信息数据进行全量备份，备份报警数据时间不得小于1年，系统数据恢复时间不超过12h。

7.7安全要求平台部署环境

安全应满足以下要求：

a) 满足GB 17859第3级及以上安全要求；

b) 数据库中关键数据加密存储，用户密码加密存储；

c) 采用日志对操作和接受及发送的数据记录，至少存储183天日志数据；

d) 采用备份平台，主平台出现问题能自动切换到备份平台；

e) 平台间数据交换采用加密传输方式，具体要求应符合道路运输车辆卫星定位系统平台数据交换的相关规定。

7.8主动安全智能防控平台运行环境运行环境应满足以下要求：

a) 通信网关、应用服务器和数据库服务器独立部署；

b) 数据库服务器能支持大数据量存储于检索；c)局域网网络数据交换速度应不低于1Gbps。

(5253)

出租车jt/t 905协议，是jt/t 808协议的一个变种，设计者将部标808协议拿过来，并不是单纯的增加网约车相关的指令集，而且对原有的指令如定位0×0200指令也进行了修改，经过一通剧烈的修改，面目全非，协议已经与808协议本身并不兼容，这是比较失败的地方，保持兼容性，才能使协议更加让硬件和网约车平台接受和开发推广，没有经验的协议设计者和标准制定者高高在上不考虑兼容性，给硬件厂家和平台开发人员造成很大的麻烦，也增加了成本。 

部标1078协议是在部标808协议的基础上，继续增加指令，并不修改原有的指令，这样也使得协议更加容易让人接受和推广。 

在部标1078视频协议推出后，905终端就相对比较尴尬，以前的905协议本身没有视频指令和功能，很多厂家就集成基于私有协议的视频模块，五花八门，现在部标视频标准一出，就面临一个视频标准统一的问题，原有的私有协议需要抛弃掉，修改成1078协议。但是1078协议是基于808协议的指令集，并不是基于905协议的指令集，本质上不是为905协议终端设备设计的。这就需要硬件和平台后端都需要做一定的工作，才能让一个905网约车平台具备1078视频功能。 

一种比较理想的方案是深度集成，将1078协议中的指令集添加到905的指令集中，这样使得905协协议赋予了视频指令交互的能力，这种方案好的地方在于它仍然保持了一个指令通道，一个视频数据通道，但是需要硬件开发人员一定的工作量。 

另一种方案就是粗暴简单，905模块和1078模块，分别与平台后端建立独立的指令交互的连接，905的连接只交互905的指令，1078的连接只交互1078的指令，各自为战，这种方案的优势在于硬件拿来即用，不需要过多的开发，但是后遗症很多，苦了平台开发人员，设计两个指令网关，一个是905指令网关，一个是1078指令网关，在平台上下发指令的时候，需要判断指令类型，来决定指令的走向，是下给905网关，还是下给1078网关。

还有一个麻烦的地方，就是上线和离线不同步，比如1078连接断开了，而905的连接还是正常，这就在前端界面的上线状态上给用户容易造成困惑，有时候905明明在线，但是视频指令却下发失败，无法看到视频。 

在上级平台对接方面，也是麻烦，首先要基于905协议第四部分中数据交互与共享单元中的数据交换协议（是809协议的变种，做了修改，不兼容809），开发转发服务器，将数据转发给出租车监管平台。

但是还要基于原有的809协议，开发转发服务器，将数据转发给省级监管平台。 

这样开放下来，一个网约车后端，就有N多的服务器模块了，主要有：

1）905协议网关；

2）1078协议网关；

3）基于905协议数据交换部分的上级平台转发服务器；

4）基于809协议的转发服务器；

5）基于905 UDP升级协议的的升级服务器；

(10511)

苏标是江苏省交通厅发布的道路运输车辆主动安全智能防控系统的平台技术规范，现有的设备厂商如海康、经纬视觉、锐明，有为等厂商已经支持，都已经接入我的平台运营。苏标平台，依赖于具有主动安全终端设备，一般是通过加装特制摄像头或者雷达等外设来达到主动安全功能的。目前运营的效果来看，由于径卫视觉的设备比较麻烦，直接用的是博实结的部标视频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卡与驾驶员不对应时，则平台记录一条驾驶员身份不匹配的报警信息，同时提醒企业监控人员进行处理。

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

(23392)

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

(23573)

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

主要工作有：

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

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

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

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

             ——数据通信链路断开；

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

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

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

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

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

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

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

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

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

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

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

(16162)

(17640)

通信协议是通信双方进行交互时所约定的标准语言，部标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年底前完成。

(62150)

由于各地的企业平台基本都是符合交通部部标标准的，都具备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消息通知和报警消息通知

(20667)

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 地图应用程序架构设计

软件截图如下图所示：

(20252)

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

(30012)