1.部标1078协议和808协议的区别

  部标1078协议文档明确说明了，协议是在JT/T 808协议的基础上进行增加了大量的视频指令，以前的终端32位报警，由于增加了视频报警，拓展为64位报警。终端参数中也增加了大量与视频相关的参数设置。协议的通信方式、数据类型、传输规则和消息组成按照 JT/T 808-2011中第 ４ 章的要求。协议中信令数据报文的通信连接方式按照 JT/T 808-2011中第 ５ 章的要求。协议中信令数据报文的消息处理机制按照 JT/T 808-2011中第 ６ 章的要求。协议中信令数据报文的加密机制按照 JT/T 808-2011中第 ７ 章的要求。

  可见1078协议仍然是基于部标808协议继续拓展的协议指令集，不过在1078协议中分为信令和数据两个独立的通道，也就是视频设备与视频平台的服务器之间是建立两个通道：

  1）信令数据通道：数据格式应符合 JT/T 808-2011的规定，并在其协议格式的基础上添加新的协议指令及数据格式。 报文通信应使用车载视频终端和企业视频监控平台之间已建立的、用于传输定位信息的链路，不应新建链路。

  2)码流数据通道：用于网络实时音视频传输、网络录像回放、语音对话、语音监听、语音广播等。报文通信应新建链路，而不使用传输定位信息的链路。 

2.开发语言和架构设计

  语言的选择对于视频服务器的性能并不是决定性的,因为语言层面的性能的高低还轮不到我们一般的开发者指指点点,我们做的软件还不是阿里巴巴腾讯百度那种访问量级别的东西,软件出问题了,肯定是人写的有问题,你总不能对老板说这是由于我们没有采用某种牛逼的语言,没有采用某种牛逼的操作系统,其实我们都明白重要的是开发者自己是否对流媒体技术经验有长期的积累.但为了提高开发效率,避免重复造轮子,流媒体开发的第一语言首先还是c++.

  从协议中可以看出，视频的查看，需要平台下发给设备，完成一连串的指令交互，待指令交互完成后，由设备再和平台的视频服务器建立视频数据通道，开始传递视频数据。

  所以视频服务器需要两个服务器子系统，一个是视频的信令服务器，我们可以在部标808GPS网关服务器的基础上增加视频的信令和相关的逻辑处理、视频报警分析、视频参数设置等功能。对于流媒体数据解析这块，需要单独增加一个流媒体服务器，来进行流媒体的数据解析、编解码处理、录像存储、数据转发等工作。 

   开发一个高性能的完整的流媒体转发服务器，从架构设计上面分为五层：

   1）视频连接接入、管理、流量计算；

   2）RTP包数据解析，计算丢包率，提取音视频裸码流，根据RTP包的音视频类型格式，进行不同的编解码转换；

   3）转发层：根据用户端的播放请求和用户所能接受的音视频编码格式，匹配设备的音视频数据转发给指定的用户端，转发是视频服务器中最复杂的一环，不仅包括对企业平台用户的转发，还包括对上级监管平台用户的转发，两种转发基于不同的协议，需要做单独的处理。

   4）日志层：记录码流，记录音频数据为wav文件，方便进行调试； .

          5）界面层：进行视频设备连接监控和数据包监控

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

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

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

如需购买部标1077视频平台或苏标平台，可联系2379423771@qq.com

基于此视频服务器可以开发1077视频平台或苏标主动安全平台：基于Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架构建高性能企业级的部标视频监控平台

 在服务器端，内嵌了一个视频播放器，可以直接在视频服务器上面，双击视频连接查看视频，这样有助于调试设备视频。

3.界面设计

视频服务器由于是接入全国几十家过检的设备厂商，不同的设备厂商采用不同的音频编码，视频数据流又非常庞大复杂，需要有非常友好的界面，方便设备调试，视频连接管理，丢包监控等。如下图所示，在视频服务器界面上能够做到以下监控：

1）当前的视频连接，音频编码，流量，丢包率，传输速度，时长；

2）可以查看某一个视频连接的RTP数据包；

3）可以监控当前的对讲和广播数据包；

4）对上级监管平台的转发数据包监控； 

4.Html5播放器

视频服务器支持RTMP/HLS/HTTP-FLV/Websocket-FLV, 可以采用支持Http-Flv的Html5播放器 播放音视频数据. 

它的工作原理是将 FLV 文件流转码复用成 ISO BMFF（MP4 碎片）片段，然后通过 Media Source Extensions 将 MP4 片段喂进浏览器。

1) 具有 H.264 + AAC 编解码器播放功能

2) 多部分分段视频播放

3) HTTP FLV 低延迟实时流播放

4) FLV 也可以通过 WebSocket 实时流播放

5) 兼容 Chrome, FireFox, Safari 10, IE11 和 Edge

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

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

6.上级监管平台的转发

            对上级监管平台的交互，也是分为指令通道和数据通道，首先要基于809部分中的视频指令协议，完成视频指令交互应答后，为上级监控平台提供Http服务器接口，上级监控平台用户按照视频协议的HttpURL格式要求，发起Http请求，企业平台返回指定的设备的视频数据，上级监控平台获取数据后自行解码播放。

部标视频的压测文章参见：部标1077视频平台过检和压力测试经验分享

(26213)

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

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

(23094)

796平台检测和1077平台，如果是不同的平台，架构必须要一致，796是BS网页版本的，则1077视频平台也必须要是BS网页版本的，不能是CS桌面版本的。 由于很多厂商老旧的视频平台都是桌面客户端程序，不是真正意义的BS网页版本的程序，所以不得不做成假的BS程序，通过ActiveX控件，只能使用低版本的IE7,8，9等，依赖IE减低安全等级设置。所以如果是开发平台，最好是一步到位选择真正的BS网页架构版本的平台。 

BS版本架构的部标1077视频平台参见：

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

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

视频平台检测的主要难点是压力测试，主要的流程如下： 

相对于796平台检测的压测的主要区别是：

1.gps压测相对于796多了1000台，压测结果是对比发送的和接收的是否一致，一条也不能少；

2.gps压测通过后，3000台车保持在线，但停止发送定位，开始视频200辆车压测；

3.视频压测的时候，200路的视频连接和对应的200路上级监管平台的转发连接都保持稳定后才开始统计码流；

如果不够200路，压测直接就失败了，因为没有码流统计数字，无法统计结果；

4.200路转发成功后，任意选择一路播放视频，如果有黑屏，卡顿或者无法打开播放的情况，则视为失败；

5.视频播放的时候如果声音不连续也不行，这也说明了卡顿；

6.测试卡顿使用的视频，是一个座钟秒针转动的画面，如果有卡顿，秒针走的时候也会一顿一顿，很明显能够看出来。如果有丢包或者跳帧，则秒针就会时快时慢，或者跳跃前进。

7.测试30分钟，然后统计终端发送的码流，和上级监管平台接收的码流，两者的数字相加要大于11M。视为压测通过。

8.统计结束后，截屏上传到检测系统当中，生成压测报告。

压测的时候，对于带宽的要求显然要高于796平台的检测要求。

播放视频的时候，播放的那一路最好不要断开连接，否则容易出现卡顿或者黑屏的情况；

交通部测试终端的出口带宽感觉在100M一下，在家里做测的时候，用10M带宽对100M服务器测试的时候，2分钟3000个连接都建立了。在交通部测试的时候，需要3,4分钟才建立完毕。

码流统计标准，之所以设计为11M，估计是一个经验值，200路如果每一路都保证画面播放流畅，则码流必须要良好才行。进而累计200路的码流值必须要是一个合理的数字。

总之要想过检，压测是重中之重，必须要认真对待。

视频平台的检测难度无论从功能细节上面还是压测强度方面，都是要高于GPS平台检测的，本平台已经通过部标1077视频平台检测，提供有偿收费检测服务，如需购买源码或购买代理过检服务，请加QQ：2379423771，注明购买源码或购买部标过检服务；我不是销售，作为一个忙碌的开发人员哪里有时间在网上瞎扯淡，目前只针对真正想降低成本，提高效率，诚意购买的人提供服务。

压力测试结果后，会打印压测数据结果，存档备案，压测结果如下图所示：

我是提供源码的，少走弯路，降低成本对公司是好事情，光明正大的给公司申请下有什么不好，自己开发，无论你多牛逼，你都绕不过漫长的开发周期和测试稳定周期，公司也必须要承担长周期带来的不可预估的失败风险和高昂的开发成本，只有血气方刚没经验的新手才会给自己或者公司挖坑，要么没有时间观念无所作为每天荒废于互联网搜索免费资源当中，要么设定激进的开发进度计划和交付时间点，给自己以极大压力。时间是后知后觉者的高昂的成本，也是市场先行者构筑竞争的砝码和壁垒，购买源码，在短时间就拥有了视频平台开发技术，瞬间有一个较高的起点才是上上之策。

很多团队为什么宁愿让公司置于项目不断延期的风险之中，就在很多负责人都是技术人员出身，过于理性，做事思虑过多，瞻前而顾后，多谋而不善断，格局太小，只关注局部的成本开支，不以完成交付为第一目标，不重视项目高效推进落实，听不得收费服务，一听到要收费就痛苦的不得了，自己都不想想自己一个月多少工资成本，自己团队一个月多少工资成本，随便一个项目，几个月都难以交付，其实作为每个月要支持高昂开发成本的软件公司，在开发上是不能慢下来的，必须要杀伐决断，立即行动。我提供的平台代码和技术支持可以让技术团队快速聚焦，不再东一榔头西一棒槌，而是脚踏实地，拧成一股绳向前推进。

(17130)

    HTML5虽然日臻成熟，VIDEO标签，可以播放服务器的视频文件，实现了真正的网页播放视频，但是原则上只能播放服务器上面的文件流，不能播放实时的视频流, 也就是不支持常说的live streaming。

   不过，HLS协议出现了，而HTML5是支持HLS协议格式的。通过HTML5 + HLS实现了网页实时视频监控的功能。

   HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8)playlist文件，用于寻找可用的媒体流。

HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。

  所以实时模式下，HLS就是实时生成M3u8文件和ts文件。它的索引文件一直处于动态变化的，HTML5播放的时候需要不断下载二级index文件，以获得最新生成的ts文件播放视频。

     如果想让HTML5播放器支持部标1078协议的视频，其实本质上就是协议数据格式转换，由于部标JT/T 1078协议文档中，视频编码格式仍然是H.264, 但对于实时的音视频进行了RTP包的封装，也就是按照RTP协议传输视频数据，需要开发流媒体服务器，接收RTP包，并提取出音视频的h.264原始数据流，然后将实时的数据流，按照HLS协议格式，实时切片，转换成HLS协议格式的数据就可以了。

如需购买符合部标1077功能标准和部标1078协议标准的B/S架构的平台，请参考文章：

 1）Asp.NET版的部标平台开发-》基于Asp.NET MVC构建BS架构的GPS视频部标平台

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

3) 部标1077视频平台过检和压力测试经验分享

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

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

     在部标1078协议的RTP包格式中，可以获取到设备的Sim卡号和逻辑通道号，服务器在切片的时候，就可以用Sim卡号和逻辑通道号作为HLS协议中的M3u8索引文件的文件名，如设备的Sim卡号是013200000008，通道1的视频，切片的时候，索引文件就是013200000008_1.m3u8。这样在web端播放视频的时候，双击车辆的通道的时候，就可以设置VIDEO标签的src属性为这个索引文件名就可以播放指定车辆的实时视频了。

    <video src="013200000008_1.m3u8" controls></video>

(14046)

对此次评测结果的总结：

1.部标视频协议的支持程度，锐明和博实结支持的都比较糟糕，不知道他们是怎么过检的，大面积的不符合1078协议指令，锐明还是第一批过检，也是部标1078协议标准的起草单位之一，自己参与撰写的自己都支持的不完善。博实结开始只给客户看证书，没有量产设备，从GF-01到GF-02,给客户换了两次设备，都测试有毛病，最后还要换设备，客户也没耐心了去他妈的换货不换了也不用了。车载视频做的最好的几家公司，主要是在视频领域有一定研发积累，研发实力较强的，比如海康、大华等几家浙江的上市公司，锐明和这两家比起来还差点，但在车载领域做的还可以。博实结只是在GPS上做设备，做视频还很弱。视频设备的研发还是需要有一定的实力积累的，如果仅是买了块板子，用了几个海思芯片SDK开发包，就像你用百度SDK包开发地图一样，技术能力肯定比不上专业搞GIS地图的，后劲肯定不足，技术细节处理不到位，处理问题的能力也很差。

    1）在部标1078协议中，对于终端参数设置和查询，增加了大量的音视频参数设置，这块锐明和博实结的都没有支持，也就是说还无法通过部标参数设置命令，设置视频设备的音视频参数,特别是码流，字幕叠加等功能，都无法通过远程设置，给锐明售后反馈过，这块锐明的研发速度特别慢，一直到现在大半年了也没有新的版本支持。

    2） 视频报警这块，视频报警也是在部标0×0200定位包中，进行了扩展，增加了视频丢失、视频遮挡还有ADS驾驶行为等指令，可以监控到各个视频通道的摄像头状态，但是这块锐明和博实结都没有完整严格的按照部标1078协议进行支持。无法在平台上展现各个通道的状态。

   3） UDP协议支持方面，部标要求TCP和UDP，终端都应该支持，但博实结不支持UDP协议传输，锐明的设备TCP和UDP都支持。我们知道流媒体协议传输的时候，由于由于UDP的传输时延低于TCP，能与视频和音频很好匹配。因此，在实际应用中，RTP/RTCP/UDP用于音频/视频媒体，而TCP用于控制信令的传输。 

   4）FTP上传， 博实结和锐明的都支持FTP上传，博实结的文件格式.avi格式，用常规的播放器都可以播放。锐明的是.264格式，264格式不符合部标1078协议要求，部标要求格式是avi或mp4格式。另外博实结FTP上传的指定文件目录名的时候，有一个明显的bug。

       锐明对于FTP上传的支持也有很大的缺陷，仅仅支持上传，但上传过程中取消不了，不支持0×9207文件上传控制指令，上传完毕后也不发送0×1206文件上传完成通知指令，结果就是服务器无法知道上传是否成功或失败。

   5）录像回放这块，锐明的不支持跨天回放，只能在当天时间段内回放，竟然不支持1078协议中要求的快进，快退回放这种视频监控中的基本功能。

   6）部标1078协议要求终端对平台下发的指令，都要给予应答。目前博实结的GF-02设备存在严重bug，收不到应答，导致平台无法判断指令是否正确执行；

   7）博实结和锐明的设备，都不带RJ45网口，这点就不如大华的设备方便，导致测试的时候，不能用网线连接，必须要插卡测试，浪费流量。WIFI是外置插件，需要单独购买，非常不好用。

   8）两家用的芯片是一样的，所以音视频编码都是一样的，视频是h.264编码, 音频编码是ADPCMA编码。

   9）两家都有自己的软件平台，功能非常弱，虽然是设备厂商，重心不在这里，但是两家的平台也有客户，也不应该如此的糊弄，一个平台仅仅能放个实时视频，其实视频功能多了去了。

2.技术支持服务，因为测试时锐明问题很少，没有和锐明技术服务体系直接打过交道，无法对比。博实结的从购买GF-01设备开始到最后客户终止购买，从17年10月24日，到最后18年1月29日，处理周期是3个月，时间大部分耽误在查找问题，来回物流快递设备换货上面了（换货时必须要先退货那边收到后才发新货）。要是你在参与项目市场竞争，估计菜都凉了。

3.两家设备价格一模一样，裸机对外报价暂时都是1300元，没有价格优势对比，配件中普通摄像头和高清摄像头价格有差异，没有可比性，锐明多了个70元钱的运维宝，不过可以不用。

4.设备质量，运行稳定性上面，没有经过上路测试和实际运营，无法给出对比，这个也不是我搞软件平台开发的职责范畴。博实结的设备问题到最后撕破脸也没查出问题，或许研发知道但不告诉你。他们惯用的招数就是换货。很多人觉得换货就很满足了，这在车载终端领域，换货的成本要多高，很多人都是无知的状态，一台设备安装到车上，人工安装成本、差旅成本是多少？ 然后再拆下来，拆卸成本是多少？ 需要发回原厂，物流成本是多少，然后对方再发货给你（需要注明的是厂家发货，运费都是到付，快递到付的成本比现结的成本要高很多），最后你重新再安装上去，整个处理过程的周期是多长？ 这么长的时间成本是多少？通过这几个问题，你应该知道换货的成本有多高，而设备厂商呢就是发了一个设备而已，还是到付。

如需购买符合部标1077功能标准和部标1078协议标准的B/S架构的平台，请参考文章：

 1）Asp.NET版的部标平台开发-》基于Asp.NET MVC构建BS架构的GPS视频部标平台

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

3) 部标1077视频平台过检和压力测试经验分享

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

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

下面说下两个设备的评测的详细过程：

客户首先给我的是博实结的一款设备GF-01的设备，博实结的销售说是支持部标1078协议的，经过我测试，发现报文还是博实结的私有协议，我告诉了客户，他还不信，说博实结的销售给他说这款是过检的设备。还展示证书给我看。我说这款设备完全不支持部标。加了他们的技术支持，他们的技术支持开始还不敢承认此事和担当责任，让我们客户从销售买的自行去联系销售。

最后承认设备不支持，后续答应给升级，至于什么时候能升级能出来就不知道了。问有没有最新支持部标1078协议的视频设备，答复是没有。客户虽然很愤怒，但也没办法。因为只买了一台，犯不上和他们较劲，虽然想投诉他们的销售，但是他们的网站上也没有投诉的入口，也没有投诉电话。

过了一个多月，因为不想这个设备报废，就又联系博实结的技术支持，他们捣鼓半天，回复说这个设备GF-01的设备，升不了级，不过答应说给更换一台GF-02的设备，说是GF-02的设备符合1078协议。客户没办法，自己掏腰包把设备顺丰快递到深圳，然后那边收到退货设备后，他们用了个最慢的快递宅急送给送过来了，一来一回又小半个月过去。

GF-02设备接电，连接到我的部标1078视频服务器上面，测试发现服务器下发的所有的1078协议指令，都没有收到终端的应答，而下发808指令如拍照、查询终端参数等，可以收到终端的应答。搞开发的都知道，这明显就是个bug。而这个明显的bug，竟然和他们纠缠了好多天，耽误了我宝贵的开发时间，让我极度恼火，最后也让我撕破脸在QQ上怼了他们领导。我还原一下和他们纠缠的过程，让大家深刻理解这个过程又多艰难。

说别人有问题，首先要确定自己是干净的没问题的，第一步就是记录原始报文，看看报文里面有没有终端上来的1078应答，结论是没有终端应答。第二部是用wireshark, 抓包，结论也是没有。第三步，确定平台下发指令是正确无误的，其实基于部标协议，如果下发指令是不正确的，终端都必须要应答，回复终端指令不正确或者不支持。通过分析指令，确定指令是正确无误的，因为设备在收到指令后确实是执行了，但就是没有回复应答，这样服务器无法知道指令是否成功。因为客户手里还有锐明的最新款的部标视频设备D5M，上电连接后，下发指令完全支持。

首先对锐明的设备，下发各种1078指令，服务器都正常能收到应答：

联系他们的技术支持，他们在设备上抓取报文后，发现有设备有应答的日志，然后就坚持认为设备没有问题，我说这个逻辑不成立，设备有没有发送应答，应该以平台是否收到为准，你的设备记录了日志，不代表你最后成功发送出去了。为了这个逻辑，反复纠缠，最后他们才答应联系他们的3G终端开发人员，成立了一个群。没有人给你反馈这个问题，他们内部各个部门好像谁都不愿意联系谁，你还要自己重新和群里的人，再重复一遍问题的现象，再贴图，再说明其他厂家的设备，都没有此问题，他们好像也不听你的，仍然又回到原点，他们说设备有日志记录，设备没有问题。

最后他们同意再接一台设备到我服务器上验证此事，结果他们接的那台设备是正常的，这次他们稍微重视了这个问题，后面又升级折腾了一天，客户的设备还是不行，就是没有应答。他们自己实验室的设备究竟和我客户手里的设备有何不同，他们也没有说明。

他们的一个经理装模作业的答应换货，还精描淡写的说前面的工作都是他们配合我的，我一下子怒了，出了问题，自己不主导各个部门去解决问题，让我一个陌生人自己从销售到支持服务，到研发工程师，每个衙门都要转一圈，每个地方都要重新说明一遍问题，反复纠缠，他们就简单拉了群，还是是为了配合我，难道还要我感谢他们?

因为耽误了我好几天的时间，我情绪失控，在QQ上怼了他们的一个小经理的领导，由于我的情绪失控的代价就是，他们在他们也不换货，也不退款，设备算是白买了，好在就这一台设备，不买他们家的设备就行了。

后面我又测试了一些其他的设备功能，还有一些问题，因为客户不打算用他们家设备了，也就此打住了。

锐明的设备，我测试了一遍， 在指令上支持还是相对比较完善，不过也有小的瑕疵，在部标1078协议中，对于终端参数设置和查询，增加了大量的音视频参数设置，这块锐明和博实结的都没有支持，也就是说还无法通过部标参数设置命令，设置视频设备的音视频参数，另外一个就是视频报警这块，视频报警也是在部标0×0200定位包中，进行了扩展，增加了视频丢失、视频遮挡还有ADS驾驶行为等指令，可以监控到各个视频通道的摄像头状态，但是这块都没有支持。无法在平台上展现各个通道的状态。

教训总结：

1.由于博实结没有自己的部标1078视频调试服务器，无法在他们的服务器端看到原始报文。本来这块问题很简单，我只需要把设备接入到他们的视频服务器上，能不能收到应答，一下子就看出来了，结果呢他们只负责看终端，这块让我对他们的视频研发实力很是怀疑。没有1078视频调试服务器，他们是怎么调试终端程序的，怎么交互的，我很难以理解。如果没有调试服务器，他们的测试肯定不方便，就不可能进行充分的测试，必须会有问题出现，这是IT开发的规律。就像你是羽毛球选手，没有陪练的一样，你的水平高低自然可知。

2.和公司做生意，如果有问题，最麻烦最头疼的就是在商务销售、技术支持、研发部门绕来绕去，互相推诿，没有担当，没有人给你出头，把这个事情给你解决了，需要你自己挨个联系，经常是你口干舌燥的说完问题（为了把问题说清楚，必须要长篇大论），他告诉你，你去联系谁谁谁。经过此事，我唯一得到的是了解了博实结的处理的组织架构。

3.博实结这件事最没担当最混账的就是他们的商务，先是在没有部标1078设备量产的情况下，欺骗客户购买了GF-01的设备，不符合标准后，说是给升级，到后来又说不能升级，最后换来的GF-02 设备还是有毛病，他不负责，不去协调自己内部各个部门去解决问题。

4.博实结公司，没有投诉反应他们人员问题的入口，这些人的行为得不到惩罚，问题只能继续存在下去，得不到解决，由于得不到任何的惩罚处理，他们也绝不会意识到错误，没有人觉得事情这严重，都是云谈风轻，轻描淡写的，谁管你Y的是干啥的。这件事由于客户幸好只购买了一台GF-01设备，没有造成更大的经济损失，试想如果大批量购买了GF-01设备，并安装上车，怎么退货更换？ 客户的客户都饶了客户吗？

(17922)

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

(33853)

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

(15225)