GPS软件平台开发技术博客 http://www.jt808.com 帮助IT团队快速构建符合部标的GPS和视频平台(2379423771@qq.com) Sun, 03 Nov 2024 04:30:16 +0000 zh-CN hourly 1 http://wordpress.org/?v=3.4.1 如何用部标jt809协议接收苏标主动安全报警和报警附件信息 http://www.jt808.com/?p=1975 http://www.jt808.com/?p=1975#comments Sun, 03 Nov 2024 03:55:12 +0000 admin http://www.jt808.com/?p=1975

如何用部标jt809协议接收苏标主动安全报警和报警附件信息

   由于目前很多平台无法直接接入设备终端，而是通过第三方平台获取到部标数据，和第三方平台的对接多数都是通过部标809协议来完成的，对于主动安全报警数据，也是可以通过809协议来接收的。

苏标主动安全协议是目前所有地方性主动安全协议标准中最富有进取的标准，因为协议标准必须要持续迭代，从2017年发布第一版，2019年跟随部标808协议2019标准又发布了苏标2019版本，2024年第三个版本也在酝酿当中，明后年估计就要发布第三版。

苏标安全协议对原有的809协议进行了拓展，主要是在报警部分，特别是部标809协议中没有的苏标主动安全报警部分。通过809协议接收主动安全报警和附件数据，主要通过以下步骤进行。

1.1. 通过0×1402接收报警信息

首先对0×1402 UP_WARN_MSG_INFO 主动上报报警信息消息这个指令进行了改造，由于苏标主动安全报警的唯一标识是32位的字符串，而原有的809信息中的报警ID是四字节的整数，所有苏标809协议首先将报警信息的报警ID修改为32字节长度的字符串。并且丰富了原有的数据，增加了驾驶员信息和定位信息。

这样用原有的809协议程序就无法再正常解析和接收苏标809报警信息了，必须要进行兼容改造。这个0×1402指令非常重要，它是接收苏标主动安全报警数据的第一步，先收到报警信息，并获取到主动安全报警ID。

当接收到1402指令信息后，要先判断报警类型是否是苏标主动报警，如果是主动安全报警，则存入主动安全报警表中形成一条报警记录。在web界面上就显示报警报表记录。

 

如需购买部标809网关源码（支持上下级服务)，或者整个苏标主动安全平台源码,请联系2379423771@qq.com

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

 

1.2. 发送9404目录请求获取附件列表信息

下一步就是根据主动安全报警ID，向下级平台发送0×9404 主动安全报警附件目录请求信息消息，DOWN_WARN_MSG_FILELIST_REQ.

下级平台收到请求后，开始准备数据并向上级平台发送0×1404,主动安全报警附件目录请求应答UP_WARN_MSG_FILELIST_ACK。获取到附件列表后，存入附件记录报表中，准备开始下载的流程。入下图所示。

苏标协议附件上传

1.3. 通过FTP下载附件文件

上级平台收到应答后，可以根据应答中的FTP地址，向下级平台的FTP服务器发起请求，下载FTP文件到自己的服务器上面。

这个通过FTP形式访问附件的形式是一大弊病，在第三版中就会改掉，因为这需要上级平台浪费资源下载附件到自己的服务器上，然后才能在上级平台的web界面上显示出来，由于上级平台是一对多，接入海量下级车辆，上级平台需要浪费时间完成下载才能显示，而且上级平台也要耗费高昂的存储成本和带宽成本，对于下级平台也非常的麻烦，很多下级平台的主动安全报警文件是存放在阿里云，天翼云的OSS对象存储服务器上面，并没有存储在自己的本地服务器上面，无法在自己构建一个FTP服务器来满足上级平台的要求。所以FTP的设计明显是非常落后的。

现在其他的地方性标准，基本都提供了基于HTTP接口访问下级平台附件的形式，这样就不用下载了，直接在web平台上跨域访问并显示下级平台的HTTP URL就可以了。

 苏标报警附件

 

  java809版的参见:基于Java Mina或者NETTY 通信框架的JT/T809转发服务器设计

如果用809协议接收第三方平台转发的数据，并开发web系统进行数据展现、报警提示、地图监控、电子围栏等功能，参见文章（C#和Java都有)：基于部标Jt/T809协议和Java Netty框架构建Gps位置监控平台

C#版的交通部809服务器设计请参考：基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器

 

 

 

(4657)

]]> http://www.jt808.com/?feed=rss2&p=1975 0 JTT1078协议双向语音对讲和广播开发指南 http://www.jt808.com/?p=1956 http://www.jt808.com/?p=1956#comments Sun, 06 Oct 2024 08:31:15 +0000 admin http://www.jt808.com/?p=1956 部标JTT1078标准支持双向语音对讲和广播的功能，终端设备可以通过麦克风接收语音信息，并通过扬声器播放语音信息。这一功能使得驾驶员和监控平台之间可以实时进行语音沟通。

语音对讲是平台和设备终端之间的一对一的语音对讲。

广播是平向多个设备终端之间的单向语音传输；

无论是语音对讲或者是广播，都只能是平台用户发起请求，驾驶员司机不能通过设备终端主动发起请求。但是驾驶员可以通过终端发起紧急报警，监控人员收到紧急报警后可以调取视频画面，并发起语音对讲。

语音对讲在苏标主动安全平台中的应用场景。

苏标主动安全平台，虽然是基于短视频报警触发的主动安全管控机制，但它也需要实时监控和语音对讲功能的辅助，常规的功能是当前端收到主动安全报警辅助的时候，可以立即打开视频监控和语音对讲，对违规司机进行口头劝诫。如下图所示。

这也就是我们常说的报警联动功能的应用之一。

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

苏标主动安全报警

 

语音对讲面临的一些问题：

1) 语音对讲的通道是虚拟通道，不像摄像头所占用的通道是物理通道，原则上这个对讲的通道号是个什么数字都是无所谓的，但是很奇怪的是，很多厂家开发的时候，强制设定对讲的通道号只能是1，不是1，对讲就不可能成功。正常由于对讲是平台发起的，平台下发请求的对讲通道号是什么数字，那么终端按照这个数字来回复和打包RTP数据包就可以了；

2) 对讲和实时视频理论上不应该互相影响，但有些设备不支持一边看视频，一边对讲。这就造成了无法满足视频通话的需求；

3)   JT078的RTP包头并没有标记区分是实时视频，历史回放视频，和语音对讲数据包，这就造成了在同一个端口，同一个通道是无法同时传输这三个数据包，服务器必须要采用不同的端口来接收并区分这三个数据包；

广播这一块漏洞比较大，可能设计者觉得没有什么应用场景，就设计一个指令草草了事，实际上广播这块目前存在的问题如下：

1) 平台主动发起广播，很多厂家设备设计的时候，收到广播请求后，只是向服务器建立了一个空的数据连接，但是不发一个数据包，这样平台就不可能知道这个连接来自那个车辆设备的，就像开远程会议的时候，都不说话，也不知道谁连上了谁没有连接上，主讲者只顾自己开大会讲话；

2) 接入广播的设备如果来自不同的厂家，如果他们的设备只能接受不同音频的编码，如锐明只支持Adpcma, 有为支持G711, 海康支持G726, 那么下发给三家设备的广播语音，必须要三次编解码，这就是语音对讲不统一音频编码带来的麻烦；

综上，广播功能就是个摆设，没啥意义。

 

开发语音对讲和广播功能是开发部标1078视频监控平台非常繁琐的一个技术环节。开发者需要掌握一定的网络通信技术和音视频编码的技术。

主要的交互分为

1）指令交互，主要是在808网关构建的指令通道中完成交互；

2）双向音频流交互传输；

开发者主要解决的技术问题：

1）如何调用桌面麦克风获取用户录音的音频流；

2）获取设备段上传的音频流并推流到网页端播放；

3）如何编解码和传输;

 

  由于音频数据需要经历获取原始音频数据->编码压缩->传输->接收后解码还原的过程，所以开发者不仅仅需要了解基本的音视频编码基础知识和原理，还需要会进行音频编码和解码。

基本的音频编码知识

由于1078协议并没有对语音对讲的编码进行统一，实际上完全可以统一为AAC（Advanced Audio Coding），但是很遗憾就是没有，所以设备终端的语音压缩编码就是百花齐放，各自根据自己的设备芯片方案来决定编码，主要采用的编码如下：

1）G711A

2）G711U

3）G726, 最复杂，G.726 支持不同的比特率（如 16k、24k、32k、40k），需要判断终端采用什么比特率的编码；

4）Adpcma

5）AAC，最方便，对网站最有好的编码；

 

主要的参与脚色是平台1078视频服务器（中转分发), 网页前端（发起请求），终端（响应请求）

1）平台当中最核心的当然是JT1078视频服务器，视频服务器主要的职责是中转分发，音视频编码解码，连接管理，数据统计。 如需购买视频监控平台和主动安全平台源码，请联系2379423771@qq.com, 无意购买者勿扰。

部标1078视频播放器

 

2） 在网页前端需要开发者从抓取麦克风录音数据获得原生的音频数据开始，然后就是压缩，再通过websocket传输。需要开发一个复杂的播放器来完成此项工作，如下图所示：

Html5 部标视频播放器

基于spring4+springMVC4+mybatis3+Hibernate4+junit4框架构建高性能企业级的部标1078视频监控平台

前端简单DEMO代码示例如下(主要是为了说明技术流程，实际代码要远比这个复杂）：

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>麦克风录音并压缩传输</title>
  <script src="https://cdn.jsdelivr.net/npm/@ffmpeg-installer/ffmpeg"></script>
</head>
<body>
  <script>
    let audioContext;
    let mediaStream;
    let sourceNode;
    let scriptNode;
    const socket = new WebSocket('ws://your-server-url');

    async function startRecording() {
      audioContext = new AudioContext();
      mediaStream = await navigator.mediaDevices.getUserMedia({ audio: true });
      sourceNode = audioContext.createMediaStreamSource(mediaStream);
      scriptNode = audioContext.createScriptProcessor(4096, 1, 1);

      sourceNode.connect(scriptNode);
      scriptNode.connect(audioContext.destination);

      scriptNode.onaudioprocess = async (event) => {
        const pcmData = event.inputBuffer.getChannelData(0);
        const aacData = await compressPcmToAac(pcmData);
        socket.send(aacData);
      };
    }

    async function compressPcmToAac(pcmData) {
      const ffmpeg = FFmpeg.createFFmpeg({ log: true });
      await ffmpeg.load();

      ffmpeg.FS('writeFile', 'input.pcm', new Uint8Array(pcmData));
      await ffmpeg.run('-i', 'input.pcm', '-c:a', 'aac', 'output.aac');
      const aacData = ffmpeg.FS('readFile', 'output.aac');

      return aacData;
    }

    socket.addEventListener('open', (event) => {
      console.log('WebSocket连接已打开:', event);
      startRecording();
    });

    socket.addEventListener('message', (event) => {
      console.log('收到服务器消息:', event.data);
    });
  </script>
</body>
</html>

(5472)

]]> http://www.jt808.com/?feed=rss2&p=1956 0 部标jt809协议视频对接播放下级平台JT1078视频 http://www.jt808.com/?p=1937 http://www.jt808.com/?p=1937#comments Fri, 01 Jan 2021 00:00:00 +0000 admin http://www.jt808.com/?p=1937

  

部标809协议是部标协议中最复杂的协议，而其中的视频协议对接部分，又是809协议指令中最复杂的指令，也是技术实现最困难的部分。这个复杂有本身涉及上级，下级，和设备多环节交互的复杂，也有协议设计缺陷造成的复杂。 

809协议的视频指令也是一个闭环的交互流程，上级-》下级-》设备-》下级-》上级，完成指令的一个闭环操作。只不过指令应答环节有缺陷，当同时开一个车的多路视频请求的时候，多个指令并发下发给下级，造成下级应答给上级后，上级无从判断应答指令对应与开始的那路视频请求，只能强行的去尝试播放。这就给我们协议设计者一个警示，设计协议的时候，下发指令和应答一定要对应上，否则就给开发造成了逻辑上的混乱，虽然勉强能做，但是很麻烦。  

809协议指令在JT/T 1078协议文档中的第六章开始部分，分为下发指令和视频播放两个部分，两个请求环节，也就是说要先完成视频指令下发给设备的闭环操作，然后再开始请求视频播放的请求操作。这两个环节完成了上级平台播放下级企业平台的设备视频的流程。 

下级平台必须要实现1078协议中的809指令部分，必须要按照809协议的要求，提供接口，上级平台才能完成播放。所以双方对接的时候，首先要确认对方是否实现了809视频指令及接口。 

下级平台提供给上级平台的接口，按照规定下级平台要扮演Http Server的角色，提供Http API供上级平台调用指定的API，上级平台调用Http API接口获取到视频流，进行转发或者直接播放。所谓的HttpAPI接口，其实就是一个URL，上级平台要扮演一个Http Client的角色去调用这个URL，在Response中获取到视频数据进行播放处理。 

政府视频监管平台向企业视频监控平台发送实时预览或远程回放请求指令并得到成功应答后，获取到音视频流服务器的IP地址和端口号，由政府视频监管平台客户端直接向企业音视频流服务器发送URL指令，建立链接后获取音视频流数据，客户端通过浏览器插件或专用软件进行播放。

音视频流请求URL不应在界面中显示，指令格式具体定义如下：

http://［服务器IP地址］：［端口号］／［车牌号码］．［车牌颜色］．［逻辑通道号］．［音视频标志］．［时效口令］

 

虽然是基于Http的协议，但是一般的H5播放器是不能直接播放的，需要获取到数据后重新编码然后再喂给H5播放器才能直接播放。所以这个也是协议设计的一个缺陷，正常的视频协议设计的时候，对于视频的格式应该进行明确的定义，采用主流的格式，如flv或者fmp4格式，这样通用播放器就可以直接播放了。目前需要自己定制播放器进行开发。 

另外一种方式是由后台获取下级平台的视频数据，然后重新解码编码，封装成web播放器锁支持的格式进行播放，这种方式也是可行的。 

希望未来的协议设计的时候，能够有更多丰富经验的设计者参与进去，而不是降维设计，让大家都很痛苦。 

如果需要购买809平台，可以联系2379423771@qq.com

 java版的参见:基于Java Mina 通信框架的JT/T809转发服务器设计

如果用809协议接收第三方平台转发的数据，并开发web系统进行数据展现、报警提示、地图监控、电子围栏等功能，参见文章（C#和Java都有)：基于部标Jt/T809协议和Java Netty框架构建Gps位置监控平台

C#版的交通部809服务器设计请参考：基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器

 部标809播放JT1078协议视频

 

 

 部标809-2019上级平台政府运管服务器

 

 

 

 

 

 

(6729)

]]> http://www.jt808.com/?feed=rss2&p=1937 0 沪标主动安全平台系统架构和功能列表 http://www.jt808.com/?p=1921 http://www.jt808.com/?p=1921#comments Thu, 26 May 2022 10:56:22 +0000 admin http://www.jt808.com/?p=1921

上海市交通运输行业协会在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。

 

(5448)

]]> http://www.jt808.com/?feed=rss2&p=1921 0 Netty4 + SpringBoot2 + RabbitMq + Redis + AliOSS 构建高性能粤标主动安全平台 http://www.jt808.com/?p=1876 http://www.jt808.com/?p=1876#comments Wed, 31 Mar 2021 07:55:58 +0000 admin http://www.jt808.com/?p=1876         苏标主动安全协议在2021年迎来一个新的版本粤标主动安全协议标准, 这个标准是基于jt/t808-2019协议框架的. 作为一个面向全国的主动安全平台不可能只能接入粤标, 还要兼容苏标.苏标主动安全协议本身就是一个比较

复杂的混合协议, 将808协议指令和报警文件数据流混合在一起, 给开发者造成了不小的麻烦, 有点烧脑. 同时由于其本身业务的复杂度, 使得开发人员必须要有一定的开发经验, 结合比较好的设计模式才能构建出来性能良好的网

关. 一般需要几个版本的迭代, 必须要在实际的大规模车辆接入, 运营一段时间积累足够多的设备经验, 才能逐步的成熟稳定下来. 没有一定规模的设备接入, 就能做出高性能的网关是不可能的事情.单纯的采用SpringBoot + Netty,

只是一个基础, 后面的代码我们仍然要有扎实良好的设计功底,才能做出一个优秀的主动安全平台. 如需购买苏标或粤标主动安全平台源码,请联系2379423771@qq.com

        作为开发者我们必须要解决一下五个设计挑战:

        1) 高性能的主动安全协议通信网关通信框架设计

        2) 苏标主动安全协议和粤标主动安全协议的兼容性设计;

        3) 大数据量高并发存储设计;

        4) 及时的报警推送和处理;

 1.高性能的主动安全协议通信网关通信框架设计

        Netty框架当然是首选, 这个不用多言, 作为基础框架, 我们一般用SpringBoot2整合Netty4框架, 先为我们的平台打下一个坚实的基础.

       Netty4 + SpringBoot2 主动安全平台

 

       基于Netty4进行协议解析, 我们必须要清楚设备与服务器之间的通信协议, 及通信数据格式. 一个粤标设备一次报警, 可能与平台直接建立三个连接, 一个是指令连接, 两个是数据传输的连接.如下图所示:

设备与主动安全平台直接的连接

2.  苏标主动安全协议和粤标主动安全协议的兼容性设计;

        兼容性设计主要是对于接入设备的报文,由程序自动识别出协议的版本. 并以此来决定后续的报文数据解析和指令下发, 如果是粤标的设备,下发的指令亦应是粤标协议格式. 实际上苏标是采用jt/t 808-2013协议, 粤标是采用jt/t 808-2019协议, 所以就是要区分是2013版本还是2019版本.     

3.大数据量高并发存储设计

        粤标主动安全报警文件上传,本质上就是多个设备同时并发连续上传多个文件,对磁盘的IO操作非常的频繁.磁盘存储的成本也非常的昂贵.在阿里云上面扩容一个100G的硬盘每月的成本需要千元.而这对于海量的主动安全报警文件来说都不够塞牙缝.

        一次报警如果平均是4个文件,1M大小,则如果在线有1000台车, 则每天平均报警一次, 将会上传1G的文件. 如果每个车平均上报10次, 则每日有10G的存储需求. 如果有1万台车, 就自己算去吧.

        而目前的主动安全设备厂商来说芯片算法很多并不掌握, 报警的准确性和误报率非常的高. 如车道偏离报警, 车距过近报警等, 这些误报的报警文件,基本上都是垃圾数据, 却会占用服务器大量的带宽资源和存储成本.

对于平台不存也不行, 万一里面真有一次车辆碰撞事故呢? 为了节省存储成本, 采用云厂商提供的云存储服务, 阿里云,腾讯云,华为云的OSS云存储费用相对较低, 但是存储容量也不能一直增长, 如果一直增长,阿里云也不是活菩萨, 也会有很多收费陷阱. 最好30天的生命周期, 过期数据自动销毁,或者归档.

        所以在设计的时候,要提供和支持本地存储,本地访问,OSS存储和OSS服务.

       主动安全参数设置

4.报警消息的及时推送和报警数据的及时展现.

       这里用到及时, 是因为一次主动安全的报警, 我们需要等待所有的报警附件全部上传完毕后, 进行报警消息的推送. 做不到实时的推送, 只能在前端能够及时的展现出来, 这就要求我们不能等待数据存储完毕才进行消息推送, 我们在数据接收完毕后进行消息推送. 这就用到redis框架. 接收到数据后,及时的放入redis当中. 前端展现的时候, 从redis中获取, 而不从存储服务中获取.

 

 

 

(5987)

]]> http://www.jt808.com/?feed=rss2&p=1876 0 主动安全协议-广东标准(粤标)和江苏标准(苏标)的区别及平台开发 http://www.jt808.com/?p=1842 http://www.jt808.com/?p=1842#comments Sun, 07 Mar 2021 12:46:35 +0000 admin http://www.jt808.com/?p=1842 mso-pagination:none;line-height:150%;"> 广东省道路运输协会在2020-12底发 布,2021年1月1日实施的广东省主动安全标准, 全称是[道路运输车辆智能视频监控报警系统 通讯协议规范]. 这个标准经过多家单位参与制定, 相对于苏标,做了很多重大的变化. 苏标协议是2017年开始实施的, 经过4年的发展, 也应该有一些丰富和功能迭代. 至此主动安全协议已经有粤标、苏标、渝标、陕标、吉标、湘标、川标、浙标、沪标九家地方标准, 其他地区比如海南的做法, 还是让人很欣赏的, 萧规曹随, 比较仁慈和大气, 直接下文采用苏标主动安全标准, 大家都省事省心, 不折腾 这才是最好的.当然粤标的推出意味着主动安全实验区又多了一个, 对主动安全的探索和标准迭代也是有意义的.

1.参与单位

参与单位主要有:广东省道路运输协会、广东粤运交通股份有限公司、深圳市赤湾东方物流有 限公司、杭州海康威视数字技术股份有限公司、径卫视觉科技（上海）有限公司、深圳市锐明技术股 份有限公司、广州鹰瞰信息科技有限公司、深圳市有为信息技术发展有限公司、深圳前海车米云图 科技有限公司、深圳市华宝电子科技有限公司、深圳市首航电子有限公司、深圳腾视科技有限公司、 珠海骏驰科技有限公司、惠州市博实结科技有限公司、初速度（苏州）科技有限公司、江苏中天安驰 科技有限公司、上海通立信息科技有限公司、浙江大华汽车技术有限公司、浙江鼎奕科技发展有限 公司、交通运输通信信息工程质量检测中心、国家通信导航与北斗卫星应用产品质量监督检验中心、 重庆车辆检测研究院有限公司、中汽研汽车检验中心（广州）有限公司、工业和信息化部电子第五研 究所。

  首先从参与单位可以看出, 参与的多为深圳的硬件厂商和交通部的几家检测机构, 国内主流的运营平台几乎都没有被邀请参与, 忽略运营经验, 标准迭代的动力就不是很充足. 协议如果只是站在硬件厂商的角度, 只能是被硬件厂商利益驱动的一个东西,  只有运营平台方充分参与, 才能从行业用户的角度去思考和解决行业问题,才能真正为行业用户带来想要的东西.所以驱动的方向就是错误的, 应该是市场和行业用户驱动生产制造, 而不是生产制造自己围成一堆玩.硬件厂商怎么可能自己改变自己. 

广东省主动安全标准

2.采用部标808-2019标准作为基础指令集

由于部标2019标准已经颁布了, 所以没有办法, 新的协议标准只能从协议的通讯方式、数据类型、传输规则和消息组成按照 JT/T 808-2019 中 4 的要求。对于视频1078标准, 也不得不做改造, 将视频RTP协议中的Sim卡号由12位扩展到20位长度.

协议中报文分类参照 JT/T 1078-2016 中 4.3 分类方式。 协议中信令数据报文的通信连接按照 JT/T 808-2019 中 5 的要求。 协议中信令数据报文的消息处理机制按照 JT/T 808-2019 中 6 的要求。 协议中信令数据报文的加密机制按照 JT/T 808-2019 中 4.4.3.3 的要求。 协议中对平台和终端通信各方，应符合以下要求： ——除明确约定外，所有消息均应给予应答； ——对未明确指定专用应答消息的，应采用通用应答回复； ——对于存在分包的消息，应答方应对每一个分包消息进行逐包应答。 

3.与苏标的兼容性

苏标是基于部标808 2013标准, 所以粤标与苏标是不兼容的. 平台开发者要做大量的兼容性处理和判断.我对标准进行了对比分析, 并严格按照要求对现有的主动安全平台做了开发和兼容性处理.

 如需购买源码, 可以联系2379423771. 技术架构设计参见:Netty4 + SpringBoot2 + RabbitMq + Redis + AliOSS 构建高性能粤标主动安全平台

4.主动安全报警中苏标和粤标的区别

粤标中新增加了 实线变道和车厢过道行人检测报警;对于驾驶员的报警更多, 意味着监管更加严厉;增加了不目视前方报警, 探头遮挡报警; 超时驾驶报警; 未系安全带报警; 双脱把报警; 玩手机报警;其中玩手机报警和苏标的拨打电话报警在算法上是有重大区别的. 

主动安全平台报警类型

5.升级协议的区别

  粤标的升级协议做了重大改变, 没有采用808-2019标准中的0×8108的升级协议, 而是另辟道路, 通过 JT/T 808-2019 中的 8.16 终端控制 0×8105 指令, 强行改造, 增加命令字来完成对终端进行升级，因此它需要对 JT/T 808-2019 表 19 终 端控制命令字进行扩展, 扩展的字段又是参考了0×8108升级指令中的一些字段, 也是比较梦幻. 升级协议的亮点是增加了终端升级进度的报告, 终端可以定时上报升级的进度, 这也是弥补这个升级指令的缺陷, 改进升级时的平台用户体验.

苏标主动安全升级协议

6.粤标主动安全检测

主动安全的设备检测和平台检测主要是通过交通运输通信信息工程质量检测中心、国家通信导航与北斗卫星应用产品质量监督检验中心两家来进行检测.

苏标主动安全终端设备

 

(12684)

]]> http://www.jt808.com/?feed=rss2&p=1842 0 GB28181协议和JT1078视频服务器的区别和集成 http://www.jt808.com/?p=1833 http://www.jt808.com/?p=1833#comments Sun, 20 Dec 2020 07:56:01 +0000 admin http://www.jt808.com/?p=1833 GB28181的全称是指《公共安全视频监控联网系统信息传输、交换、控制技术要求》, JT1078主要是指交通部的车载视频监控协议, 两者适用于不同的领域, GB28181规定了城市监控报警联网系统中信息传输、交换、控制的互联结构、通信协议结构，传输、交换、控制的基本要求和安全性要求，以及控制、传输流程和协议接口等技术要求.主要是适用于公共场所的视频监控, 设计之初是适用于有线局域网环境, 2011发布的版本主要是UDP协议, 后来针对互联网的需求,进行了增补TCP的需求. 

1.过检认证需求:

两者都需要到主管部门指定的检测机构检测, GB28181是需要通过公安部一所、公安部三所的认证,

JT1078是需要通过交通部信息中心指定的几家检测机构,如交通运输通信信息工程质量检测中心,石家庄54所等机构检测认证. 

2.主要版本:

GB28181有2011版本, 和2016版本,

JT1078目前只有2017年发布的版本. 最近几年, 地方上开始有了2019版本的变体, 但是官方还没有正式的2019版本.

3.基于协议:

GB28181主要是以UDP为主, 多数设备以有线接入,面向局域网环境 少数手持执法设备以4G接入;

JT1078主要是以TCP为主, 由于车载设备多以无线4G接入. 

GB28181的指令协议是SIP协议,文本协议, 扩展性较强, 但是占用流量较大, 在内网无所谓, 在外网, 如果用于几千辆车带车队目录的同步, 每个车有四路摄像头, 这个流量还是比较大.

JT1078的指令协议是部标808协议, 二进制格式, 惜字如金, 适用于无线对流量费比较敏感的环境.

4.视频流格式:

GB28181的视频流比较复杂, 主要是RTP + PS + H.264的封装.

部标1078视频流的封装相对比较简单, 主要是RTP +H.264, 少了PS层. 

5.架构设计

两者在协议结构上都是类似的, 都是分为指令和数据两部分, 各自独立的两个通道, 一个长连接保持用于指令的交互, 一个数据连接用于流媒体上传, 生命周期随着用户指令结束播放而结束.

所以在架构设计上也是一样的, 需要两个子系统 : 一个网关, 一个流媒体服务器, 各司其职.

6.GB28181相对于JT1078的优势:

1. 有非常成熟的级联方案,上下级之间,同级之间都可以层层级联, 可以推送下级平台的组织架构目录树和设备及状态.

2. JT1078没有比较好的级联方案, 各级视频平台无法层层级联, 上级平台主要依托于JT/T 809协议 进行视频请求. 

由于GB28181的非常好的级联设计, 我们可以很方便的将部标企业平台的车辆树通过GB28181的SIP协议指令给同步过去, 对方的GB28181平台接收到同步数据后,自然就形成了一个组织架构树, 叶子节点为摄像头.

但由于要考虑级联,所以GB28181的视频请求流程相对于JT1078的指令来说 是根据复杂的, 详细的GB28181视频请求流程图如下:

GB28181视频请求流程

两者本来没有什么交集, 今年来, 有些地方标准如川标,要求将车载视频转入到公安部的GB28181平台进行监控, 两者慢慢发生了交集.两者以两种方式发生交集:

1. 一种是车载视频设备通过部标1078视频协议接入部标企业平台, 然后通过音视频转换和转发 转入GB28181平台.

2. 一种是固定场所的28181设备和车载设备一样,混合接入到部标企业平台当中.

 

两种方式都需要设计中间件,进行复杂的协议转换,音频编解码,以及数据转发, 在编解码及转发过程中, 要保持高性能的交换,避免产生视频延迟.

JT808.com在已有的视频服务器的基础之上, 增加了GB28181的协议转换, 使得视频服务器可以将1078视频流,转换为GB28181的PS流, 推流到GB28181视频监控平台.

主要的功能如下:

1) 平台间注册和鉴权

2) 自动定时推送设备列表和目录列表, 对车载设备和所属组织架构进行GB28181行业规范编码, 定时推送到GB28181监控平台, 监控平台自动形成监控层级目录, 并实时同步设备的上线下线状态.

3) 音频视频PS推流

如需购买视频平台源码, 请联系2379423771@qq.com

GB28181协议和JT1078协议

 

(9664)

]]> http://www.jt808.com/?feed=rss2&p=1833 0 基于Redis + RabbitMQ的苏标主动安全平台架构设计 http://www.jt808.com/?p=1808 http://www.jt808.com/?p=1808#comments Wed, 01 Jul 2020 01:48:35 +0000 admin http://www.jt808.com/?p=1808  

苏标主动安全智能防控系统是根据苏标主动安全协议开发的一个主动安全平台, GPS位置监控系统、视频监控系统、主动安全报警和司机考核系统，其核心的主动安全功能包括了ADAS：高级驾驶辅助系统、DSM：驾驶员状态监测系统、TPMS：轮胎气压监测系统、BSD：盲点监测系统..

依赖的苏标协议栈包括:

1) 部标808协议是设备与平台通信的协议基础;

2) 部标1078视频协议在部标808基础之上扩展视频指令和视频传输协议, 成为一个部标视频通信协议,它包含并依赖808协议;

3) 苏标主动安全协议包含808和1078, 在两者基础之上继续增加主动安全相关的指令和数据传输协议, 成为一个完整的苏标协议.

苏标协议分析

如需购买苏标平台源码, 联系邮箱: 2379423771@qq.com

2.对应的平台

1) 部标GPS平台 

基于部标808协议标准开发,只能显示车辆状态和位置信息,核心数据是车辆位置\速度\里程\附加数据

2) 视频平台

  基于部标808协议和1078协议标准开发,在GPS平台之上,扩充视频监控功能.将位置和视频集成在一起.

  核心数据: 车辆位置\视频\速度\里程

3) 主动安全平台

  基于部标808协议\1078协议标准和苏标主动安全标准开发,在视频平台之上, 继续扩充主动安全报警功能。

  核心数据：车辆位置\主动安全证据\实时视频

 

所以一个完整的主动安全平台应该是一个三合一的平台, 涵盖了GPS\视频\主动安全三大子系统功能, 是一个逻辑复杂功能密集的平台. 对于开发团队而言, 如果没有任何基础, 去开发一个主动安全平台,基本上是一个高风险的开发之路.

苏标主动安全平台架构设计

三个子系统集成在一个平台上面, 子系统之间的互联互通, 数据的互联互通主要有:

1) 静态信息的共享, 如数据字典, 车辆,司机,部门基础信息;

2) 动态数据传递或共享,如报警信息, 主动安全附件信息等;

通过Redis 可以构建一个分布式的缓存架构, 由web平台负责维护和管理基础信息, 其他子系统通过引入Redis客户端, 调取分布式缓存中的基础信息.

Reids不仅可以解决静态信息的缓存, 也可以接动态信息的缓存, 比如可以设置动态数据的存活时间, 来解决共享, 并减少随时间增长, 数据压力过大的问题. 例如报警详细数据,在产生后, 可能会在一天内会前端页面报警处理的时候, 被弹出展现, 这时候就可以设置热数据的存活时间, 过了时间阈值, 就移除, 只保留数据库的数据即可.

三个子系统和web平台之间交互最频繁的主要是实时数据和报警信息, 为了提高性能, 减轻web平台对数据库的查询压力, 实时数据的传递, 都通过RabbitMQ消息中间件, 利于消息中间件高性能的消息吞吐能力, 不仅对平台各个子系统解构, 解耦, 避免互相依赖, 分布式扩展能力, 也提高了实时性能.

 

苏标主动安全报警消息

 

苏标主动安全平台主界面

(5908)

]]> http://www.jt808.com/?feed=rss2&p=1808 0 基于Asp.NET MVC框架+SignalR +ActiveMQ + Ali OSS 服务构建苏标主动安全智能平台 http://www.jt808.com/?p=1780 http://www.jt808.com/?p=1780#comments Thu, 16 Apr 2020 09:49:51 +0000 admin http://www.jt808.com/?p=1780 苏标主动安全智能平台是基于江苏省地方标准《道路运输车辆主动安全智能系统技术规范》（以下简称《规范》）经省市场监督管理局正式批准发布。该《规范》作为团体标准的升级，对主动安全智能系统现有的技术和功能做了进一步完善，更加贴合重点营运车辆实际和企业安全管理需求。 

主动安全平台所基于的协议是苏标协议, 而苏标协议是基于部标808协议和部标1078协议的基础之上的构建的,  在这里不对部标808协议和1078协议的平台功能做过多阐述, 需要了解的可以参见文章:

 

主动安全服务端需要解决两个核心问题:

1.及时的报警投递

由于报警和报警产生的短视频等附件数据是由设备主动推送到平台上面, 做平台在消息的及时投递方面面临着一定的挑战. 由于涉及到安全等级较高的报警,比如前车碰撞, 车距过近, 司机抽烟打哈欠打电话等报警, 需要平台能够及时投递到监控用户端, 提醒监控人员第一时间处理. 

采用ActiveMQ + SignalR 的分布式架构来投递报警消息.采用阿里云的OSS的云存储服务来解决存储成本和流量成本的问题.

其中ActiveMQ主要用于后台不同服务端之间的消息发布和订阅通知功能, SignalR则用于web平台对当前在线注册用户消息投送.

采用Signal后,页面的工作就非常清爽了, 不再需要调用后台接口轮询数据了,直接通过SignalR的回调接口, 接收到基于Json的报警数据, 直接弹窗处理了.

基于SignalR的主动安全报警推送

如下图所示, 弹窗显示主动安全报警的视频图像及文字信息内容.

苏标主动安全报警

2.报警附件数据存储

报警附件数据存储是一个苏标主动安全平台的一个非常大的挑战, 从成本和IO性能上都是一个挑战.

一个苏标主动安全二级报警, 少的四个文件,多的7个文件,如果同步处理,有可能同一个车,一次报警附件文件还没处理完, 又一个报警附件文件数据又接踵而至.

为了加快报警附件数据的接收, 必须要提高服务的并发能力, 采用线程池, 每次一个报警数据的上传连接, 开辟一个单独的线程, 完成文件数据的IO写入处理和消息发布的工作,随后退出线程归还线程池.

 SignalR+AspNET.mvc构建主动安全平台

存储对磁盘容量的需求是非常大的, 一次报警如果平均是4个文件,1M大小,则如果在线有1000台车, 则每天平均报警一次, 将会上传1G的文件. 如果每个车平均上报10次, 则每日有10G的存储需求. 如果有1万台车, 就自己算去吧.

实际运营的时候, 由于设备性能原因, 往往有大量的误报, 如车道偏离报警, 车距过近报警等, 这些误报的报警文件,基本上都是垃圾数据, 却会占用服务器大量的带宽资源和存储成本. 

为了节省存储成本, 采用云存储方式, 阿里云的云存储费用相对较低, 但是存储容量也不能一直增长, 如果一直增长,阿里云也不是活菩萨, 也会有很多收费陷阱. 最好30天的生命周期, 过期数据自动销毁,或者归档. 

如下图所示,在代码中根据参数配置, 设置数据的生命周期规则.

基于阿里云OSs

 

 

(15794)

]]> http://www.jt808.com/?feed=rss2&p=1780 0 GB∕T 35658平台过检 已通过最新的部标JT/T 808-2019, JT/T 809-2019标准 http://www.jt808.com/?p=1692 http://www.jt808.com/?p=1692#comments Sun, 10 Nov 2019 07:57:58 +0000 admin http://www.jt808.com/?p=1692  2019年交通部GPS平台检测标准发生了重大变化, 原来的796平台功能标准, 变更为GB/T35658标准, 全称是<<GB∕T 35658-2017 道路运输车辆卫星定位系统 平台技术要求>> 这个标准其实2017年就公布了, 实际上还是796标准, 但是检测项目,以前是可选的, 现在统统变成了必选,检测标准比以前拔高了很多.但是由于是2017年的标准, 很遗憾没有与时俱进.但是要按照这个标准开发,即使有以前通过的gps平台, 由于增加了几十个功能点, 比较琐碎,改造开发的工作量是很大的.

同时由于部标协议在2019年推出了新标准, 所以协议上的变动,需要重新解读, 并按照2019标准开发,同时还要兼容旧标准, 从16年的部标1078视频标准, 17年的苏标,19年的部标协议2019标准, 也是让开发人员不得喘息的机会, 对开发人员要求具备必要的协议标准知识, 平台的功能复杂度也大大增加.平台过检,首先必须要符合这三个标准, 即GB/T35658平台功能标准,JT/T 808-2019, JT/T 809-2019部标协议标准.开发人员必须要先认真学习这三个文档,然后才能着手开发. 当然了还有一个<<道路运输车辆卫星定位系统平台检测方法>>可以参考, 但由于是文档,文字的二义性很容易让人掉沟里,开发的时候,也是很烧脑的.

过检本是一个十分低效的工作, 开发一个符合部标的软件是一个长周期的过程,目前我的平台( BS架构) 已经通过检测, 有需要过检或者购买源码的可以联系2379423771@qq.com, 明确说明来意, 无意购买者勿扰.

平台介绍参见文章:

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

GB/T 35658标准检测报告

 

 GB/T 35658较796新增检测项如下表所示:

 


序号

测试项目

要求（黄色为新增及之前未测试到的项目）

是否
必选

备注

1

报表导出

支持excel格式的报表导出

对查询、统计报表提供excel格式的报表导出

必选:

 

2

报警

紧急报警

通过终端触发的紧急报警上报到平台，报警方式通过声、光、图片和文字等方式提示；报警显示包括车辆动态信息和静态信息等；被检测平台具备正确保存报警信息。

必选:

 

3

报警

违规行驶报警

通过终端触发的违规行驶报警上报到平台，被检测平台正常显示各报警类型提示；报警显示车辆动态信息和静态信息；报警方式通过声、光、图片和文字方式提示。

必选:

厂家配合上报终端报警

4

报警

前撞报警

通过终端触发的前撞报警上报到平台

必选:

5

报警

胎压异常报警

通过终端触发的胎压异常报警上报到平台

必选:

6

报警

车道偏离报警

通过终端触发的车道偏离报警上报到平台

必选:

7

报警

偏离路线报警、超速报警、区域报警、疲劳驾驶报警、设备故障、断电报警、停车超时、电瓶欠压

通过终端触发的偏离路线报警、超速报警、区域报警、疲劳驾驶报警、设备故障、断电报警、停车超时、电瓶欠压报警上报到平台

必选:

 

15

报警

其他报警

通过终端触发的其他类型报警上报到平台

必选:

 

16

报警

平台报警

有平台产生的报警

必选:

 

17

报警

平台报警下发终端

平台产生的报警能可通过下发配置提供下发到终端的报警提示

必选:

平台报警设置界面

18

报警

终端上传报警提示

报警信息通过声、光、图片和文字等方式提示并显示

必选:

所有报警必须有声、光、图片和文字提示

19

报警

显示车辆动态位置信息

提供报警车辆动态位置在GIS地图上展示（定位信息、运行状态、人员、货物）

必选:

 

20

报警

显示车辆静态信息及相关信息

提供车辆详细静态信息展示（营运车辆、业户、从业人员、运营机构）

必选:

 

21

报警管理

报警处理、处置功能

提供报警信息确认、报警处置、报警处理功能
提供报警车辆处置包括监听、拍照、报警解除、下发信息

必选:

报警处理界面具备监听、拍照、报警解除、下发信息功能

23

报警管理

接收及处理终端报警信息

实现接收及处理对应警情信息流程。（809中测试）

必选:

通过809测试

24

报警管理

自动上报报警信息命令

企业平台应支持将报警信息实时传送到政府平台。（809中测试）

必选:

25

报警管理

主动报警处理结果信息上报消息(根据809标准表48改动，协议补遗)

下级平台主动向上级平台上报报警处理结果（809中测试）

必选:

26

报警管理

响应政府平台下发的报警处置请求

企业平台应能够支持政府平台的报警督办信息处理功能（809中测试）

必选:

27

报警管理

报警信息记录、查询功能。

平台能够记录、保存并查询报警信息

必选:

 

28

报警管理

报警处理信息记录、查询功能。

平台能够记录、保存并查询报警处理信息

必选:

JTT1120-2017 7.1.2.2

29

车辆监控管理

车辆上下线实时提醒

实时反映车辆上下线情况，通过声、光等形式进行提醒；

必选:

 

30

车辆监控管理

车辆调度

通过多种方式选择车辆，并向多车下发调度信息

必选:

JTT1120-2017 7.2.1.1

31

车辆监控管理

车辆监控

实时接收终端上传的动态信息，并在电子地图上显示其位置，并可根据需要显示车辆动态信息；

必选:

JTT1120-2017 7.2.1.2

32

车辆监控管理

车辆跟踪

以定时方法，在电子地图显示单车或多车实时位置和状态信息

必选:

JTT1120-2017 7.2.1.3

33

车辆监控管理

车辆点名

向指定车辆发送车辆点名命令，终端上报车辆位置信息，企业平台在电子地图上显示车辆位置；

必选:

JTT1120-2017 7.2.1.4

34

车辆监控管理

车辆查找

按照车牌号码、SIM卡号码、司机、企业和车队等条件查询车辆；

必选:

JTT1120-2017 7.2.1.5

35

车辆监控管理

区域查车

在电子地图上查询设定区域的当前车辆；

必选:

JTT1120-2017 7.2.1.6

36

车辆监控管理

车辆远程控制

将监听、解除监听、无线通信连接、图片抓拍等指令发送到终端，通过终端实现相应功能。

必选:

JTT1120-2017 7.2.1.7

37

车辆监控管理

车辆运营状态报备

平台应具备车辆运营状态报备登记功能

必选:

 

38

车辆监控管理

车辆长时异常离线提醒

平台应具备动态巡检车辆在线情况功能，对于长时异常离线车辆，采用声、光和文字形式对监控人员进行提醒，应上报动态信息上报异常报警

必选:

 

39

历史轨迹回放

历史轨迹回放

指定时间段内回放指定车辆历史轨迹的功能

必选:

JTT1120-2017 6.7.5

40

定时定位车辆查询

定时定位车辆查询

根据车辆的轨迹数据，查询在指定时间段内、经过指定区域的车辆信息的功能，并且应支持多区域多时间段的联合查询

必选:

JTT1120-2017 6.7.6

41

终端运行监控

终端运行监控

企业平台提供终端运行情况监控功能，能够实时监控终端在离线情况，并提供运行监控分析

必选:

 

42

车辆视频和图像监控

单车或多车的视频信号监控查看

检查单车或多车的视频数据

可选:

可选内容

43

车辆视频和图像监控

实时监控查看

要求显示指定车辆的实时视频

可选:

44

车辆视频和图像监控

历史视频数据调用查看

要求按指定时间显示指定车辆的历史视频

可选:

45

电子地图管理

漫游

检查平台软件是否具备移动地图操作，并能够正确显示结果。

必选:

JTT1120-2017 6.8

46

电子地图管理

放大

检查平台软件是否具备放大地图操作，并能够正确显示结果。

必选:

47

电子地图管理

缩小

检查平台软件是否具备缩小地图操作，并能够正确显示结果。

必选:

48

电子地图管理

全图

检查平台软件是否具备查看全图地图操作，并能够正确显示结果。

必选:

49

电子地图管理

拉框放大

检查平台软件是否具备鼠标拉框放大地图操作，并能够正确显示结果。

必选:

50

电子地图管理

拉框缩小

检查平台软件是否具备鼠标拉框缩小地图操作，并能够正确显示结果。

必选:

51

电子地图管理

距离量算

检查平台软件是否具备在电子地图上自定义绘制路线，包括计算路线长度操作，并能够正确显示结果。

必选:

52

电子地图管理

比例尺显示

检查平台软件是否具备显示地图当前比例尺的功能

必选:

53

电子地图管理

打印

检查平台软件是否具备打印当前显示地图操作，并且能够正常打印。

必选:

54

电子地图管理

当前屏幕图像保存

检查平台软件是否具备保存当前地图镜像操作，并且能够正常保存。

必选:

55

电子地图管理

鹰眼

检查平台软件是否具备显示地图缩略图功能，并能够正确显示结果。

必选:

56

电子地图管理

标注

检查平台软件是否具备移动地图操作，并能够正确显示结果。

必选:

57

电子地图管理

图层控制

检查平台软件是否具备电子地图图层控制操作，并能够正确显示结果。

必选:

58

电子地图管理

面积量算

 

必选:

60

电子地图管理

路径分析

 

必选:

61

电子地图管理

电子围栏设置

 

必选:

62

电子地图管理

行驶区域设置

检查平台软件是否具备设置设定车辆越界区域功能，检查被测平台是否能够正确显示车辆动态信息、静态信息及相关信息结果，包括至少具备声、光、图片和文字等方式进行显示等功能。

必选:

63

电子地图管理

行驶路线设置

检查平台软件是否具备提供对行驶路线信息设置功能，包括行驶路线的新增、修改、删除和查询等功能，并能显示正确结果。

必选:

64

电子地图管理

地理信息查询

具备对设施、地名、道路和行政区域的模糊检索功能

必选:

65

电子地图管理

GB-20263的规定

导航电子地图安全处理技术基本要求（GB-20263—2006）

必选:

66

平台接口功能

与政府平台信息交互

具备与上级政府平台的信息交换的功能，包括车辆动态信息、静态信息和跨域信息的交换（809中测试）

必选:

809中测试

67

平台接口功能

具备具备自动补传或按上级要求补传动态位置信息

补报定位信息（809中测试）

必选:

68

平台接口功能

具备接收上级政府平台下发通知并进行醒目显示的功能

能够接收政府平台下发的通知，并显示（809报文、查岗、督办）

必选:

69

平台接口功能

具备下发上级政府平台指令到车载终端的功能

809中测试

必选:

70

平台接口功能

具备与上级平台间数据同步功能

809中测试

必选:

71

监控平台间连接情况

监控自身与上级政府平台间连线情况功能

跟踪监控企业平台自身与政府平台间连线情况功能，在掉线状态下应以声、光等信息提示用户，直至恢复连接。

必选:

 

72

监管功能

监管巡查

应政府平台下发的岗位巡检指令，并将巡检结果上报到政府监管平台。

必选:

 

73

监管功能

监管平台实时数据交换

收到车辆上报动态位置信息后，应立刻向政府平台实时上报车辆的位置、状态信息和报警信息，响应政府平台对车辆的拍照和监听等车辆远程控制指令，显示政府平台下发信息。（809中测试）

必选:

809中测试

74

统计分析功能

报警信息统计

各种类型报警及报警处理结果统计

必选:

JTT1120-2017 7.5.1

75

统计分析功能

行驶里程统计

具备行驶里程统计功能

必选:

JTT1120-2017 7.5.2

76

统计分析功能

车辆上线率统计

具备车辆上线率统计功能

必选:

JTT1120-2017 7.5.3

77

统计分析功能

历史轨迹有效性

车速、里程异常统计

必选:

 

78

管理功能

终端管理

终端开户

必选:

JTT1120-2017 7.7.1.1

79

管理功能

终端管理

终端销户

必选:

JTT1120-2017 7.7.1.2

80

管理功能

终端管理

车辆停用

必选:

JTT1120-2017 7.7.1.3

81

管理功能

终端管理

车辆转组

必选:

JTT1120-2017 7.7.1.4

82

管理功能

终端管理

终端转车

必选:

 

83

管理功能

终端参数配置管理

终端参数配置

必选:

JTT1120-2017 7.7.1.5

84

管理功能

基础信息管理

SIM卡管理

必选:

JTT1120-2017 7.7.2.1

85

管理功能

基础信息管理

终端管理

必选:

 

86

管理功能

基础信息管理

从业人员管理

必选:

JTT1120-2017 7.7.2.3

87

管理功能

基础信息管理

车队、运输企业管理

必选:

JTT1120-2017 7.7.2.4

 

管理功能

基础信息管理

车辆综合信息查询

 

JTT1120-2017 7.7.2.5

88

管理功能

预设信息管理

区域和线路设置信息的管理

必选:

 

89

管理功能

行驶记录管理

行驶记录管理对应的是终端要求中终端必须具备的行驶记录功能，能够随时远程调用车载终端上的行驶记录，并查询、分析和打印。

必选:

JTT1120-2017 7.7.3

90

管理功能

多媒体信息管理

终端上传的音频、视频、图片等信息的检索上传、存储及查询等功能

必选:

 

91

平台管理

用户管理

检查平台软件是否具备用户管理功能，包括提供对用户信息的新增、修改、删除和查询功能，并能够正确显示结果。

必选:

JTT1120-2017 6.9.1

92

平台管理

角色管理

检查平台软件是否具备角色信息管理功能

必选:

JTT1120-2017 6.9.2

93

平台管理

权限管理

功能清单;检查平台软件是否具备权限管理功能

必选:

JTT1120-2017 6.9.3

94

平台管理

日志管理

检查平台软件是否具备提供对用户操作日志信息的导出、打印和查询功能，并能够正确显示结果。

必选:

JTT1120-2017 6.9.4

95

平台管理

报警控制配置

具备对报警声、光提示可控配置

必选:

 

96

平台运行监控管理

服务器状态监控

能监控各种服务状态

必选:

 

97

平台运行监控管理

平台资源监控

能监控各种服务器资源消耗情况，可显示资源消耗情况

必选:

 

98

业务功能

偏离路线报警

平台报警

必选:

JTT1120-2017 7.8.1

99

业务功能

线路关键点监控

平台报警

必选:

JTT1120-2017 7.8.2

100

业务功能

区域报警

平台报警

必选:

JTT1120-2017 7.8.3

101

业务功能

分路段限速监控

平台报警

必选:

JTT1120-2017 7.8.5

102

业务功能

疲劳驾驶报警

平台报警

必选:

JTT1120-2017 7.8.4

103

业务功能

驾驶员身份识别

将驾驶员身份有效性信息下传到终端

必选:

JTT1120-2017 7.8.7

104

班线客运特殊业务功能

营运线路查询

对班线客运线路查询功能

必选:

 

105

班线客运特殊业务功能

乘客超员监控

对车载终端直接通话功能

必选:

 

106

班线客运特殊业务功能

乘客超员监控

对超员车辆进行警告、记录、处理报表

必选:

 

107

业务功能

ACC信号异常报警

平台报警

必选:

测试期间时间可设置1分钟

108

业务功能

位置信息异常报警

平台报警

必选:

109

系统总体性能

上报动态数据时间间隔

车载终端在非休眠状态下上报车辆动态信息数据时间间隔不大于60秒

必选:

压力测试

110

平台车辆接入性能

海量定位数据高并发处理能力

 

必选:

111

平台车辆接入性能

终端接入能力

 

必选:

112

平台车辆接入性能

动态目标监控能力

 

必选:

113

平台安全要求

平台间数据交换加密传输

满足JT/T809标准的加密功能

必选:

 

809协议的变化参见文章:部标809协议2019版本与2011版本的区别

 JT/T 808-2019协议标准,是唯一有改进的一个标准,首先非常值得赞赏的就是他去掉了一些经过时间证明,没有用的协议指令,虽然不多,但是已经不容易了, 其他两个标准,完全没有这样做, 只是一味的加大复杂度, 在这些设计编纂者眼里,似乎是越全面越好,越严厉,越复杂越好.

 JT/T808 2019标准相对于2011标准,主要变化的技术内容如下:

部标808协议2019标准的主要变化

 

 

 

 

(22007)

]]> http://www.jt808.com/?feed=rss2&p=1692 0 部标809协议2019版本与2011版本的区别 http://www.jt808.com/?p=1677 http://www.jt808.com/?p=1677#comments Sun, 03 Nov 2019 13:42:15 +0000 admin http://www.jt808.com/?p=1677 mso-pagination:none;line-height:150%;">今年交通部通信信息中心一口气推出了三个新标准, GB/T35658 道路运输车辆卫星定位平台技术要求, 部标808-2019协议标准, 部标809-2019协议标准, 将GPS监控平台的标准由原来的部标变为国标, 在2019年7月1日开始强制执行, 2019年6月份过检的,需要重新再次按照新标准通过后才给公示.搞的大家焦头烂额, 动荡不安.

这次变化中,变化最大的就是809协议,基本完全不考虑兼容了,本来希望jt/t809-2019标准能够改变以往2011版晦涩难懂的风格,结果大失所望, 相比以往复杂度大幅增加, 更令人痛苦的是二义性,一段不准确的文字,可以有多种理解, 开发的时候痛苦无比, 但是为了过检,只能硬着头皮去开发, 其实我自己非常不喜欢在809协议上面浪费时间, 觉得人生非常的无趣, 由于晦涩难懂, 又没有解释说明, 完全是人为制造出来的泥沼,让人泥足深陷,开发效率非常低.

由于809协议需要上级平台做测试,否则不知道对错, 所以不得已又回头先开发809-2019版本的上级平台模拟服务器,用来模拟政府运管平台, 这个又花费了好多时间才搞完. 这个是开发之前没有想到的.

部标809-2019上级平台政府运管服务器

一直到9月份开发完毕,10月份一整月都在过检, 10月底终于通过.真是红军过草地走出沼泽地的感觉, 人生好无趣! 虽然过检通过,但心绪难平,希望分享一些新标准的变化,提供有偿的过检咨询服务或购买完整的新标准平台源码. 如需购买部标2019标准源码请联系2379423771, 套资料的勿扰, 我是开发人员不是销售.

GB/T 35658标准检测报告

部标809协议2019版本与2011版本的变化差异总结如下:

    


新旧标准差异

差异解读及备注

2019版

2011版

章节号

内容

章节号

内容

修改了上级平台、下级平台的术语和定义

定义更清晰、更精准

3.1.2

上级平台：提供其他平台接入的监管平台，包含更低一级的监管平台

3.1.2

上级平台：提供其他平台接入的政府监管平台

3.1.3

下级平台：监控平台、监管平台中接入上级平台的监管/监控平台

3.1.3

下级平台：企业监控平台、政府监管平台中接入上级平台的监管/监控平台

修改了业务类型标识和子业务类型标识

新增了命令字常量定义，详见“命令字差异”页

4.1

主业务类型常量定义

5.1

主业务类型常量定义

4.2

子业务类型常量定义

5.2

子业务类型常量定义

修改了报警类型编码表

详见“报警定义差异”页

4.3

1）、区分为“与位置相关”（随终端位置信息上报）和“非位置相关”两类报警（企业平台识别并上报）；
2）、“路段堵塞报警”和“危险路段报警”定义为“非位置相关报警”；

5.3

详见“报警定义差异”页

增加了平台间消息处理和重传机制的要求

重大修改（要求非常严！！）：
1）、每条上报到上级平台的消息都必须确保不丢失，若丢失必须补传；
2）、每条消息的流水号要根据子业务类型逐条编码，从0开始，中间有任何一条丢失，如流水号为6，则必须补传上流水号为6的报文；
3）、上下行报文丢失情况要统计；

7

 

 

 

修改了发送车辆动态定位信息数量通知的方向要求

上级平台统计发送数量，改为下级平台发送统计数量。——政府监管，企业上报

8.1.2

a)下级平台统计发送到上级平台的车辆定位信息数量，并定期给上级平台发送通知该统计数据。
b）上、下级平台根据此数据进行车辆定位信息接收与发送数量核对。

4.3.2

a)上级平台将收到来自下级的车辆定位信息数量定期予以统计，并定期给下级平台发送通知该统计数据；
b）上下级平台根据此数据进行车辆定位信息接收与发送数量核对。

增加了平台链路连接情况与车辆定位消息传输情况上报的业务流程

上级平台请求，下级平台上报

8.1.2.2

上级平台请求，下级平台上报：平台链路连接情况、车辆定位消息传输情况

 

 

修改了上传车辆注册信息业务流程，增加了上级平台对上传车辆注册信息的应答要求

增加了上级平台应答和车辆注册信息发生变化时上报

8.1.3.1

终端鉴权或车辆注册信息发生变化时上报

4.3.3.1

终端鉴权时上报

修改了上报驾驶员身份识别信息业务流程，增加了主动上报驾驶员身份识别信息的业务流程

增加了下级平台主动上报：司机登录时和信息变化时主动上报

8.1.3.5

司机登录或身份识别时，下级平台收到即主动上报到上级平台；下级平台司机信息变化时，下级平台主动上报；上级平台缺失时，上级平台请求，下级平台上报

4.3.3.7

上级平台请求，下级平台上报

修改了主动上报车辆电子运单信息业务流程，增加了主动上报车辆电子运单信息业务流程

同司机信息：增加了下级平台主动上报，电子运单上报和信息变化时主动上报

8.1.3.6

同司机信息：下级平台收到车辆上报的电子运单，和电子运单有变化时，下级平台主动上报；上级平台缺失时，上级平台请求，下级平台上报

4.3.3.8

上级平台请求，下级平台上报

增加了上报车辆行驶路线信息业务流程

新增：下级平台主动上报；上级平台请求，下级平台上报

8.1.3.7

下级平台主动上报；上级平台缺失时，上级平台请求，下级平台上报；车辆首次跨域或路线信息有变化时，上级平台向跨域的下级平台交换一次路线信息，下级平台更新并保存；

 

 

修改了车辆报警信息交互类流程

增加并区分了“平台报警”和“终端报警”，以及“非位置报警”

8.1.5

增加并区分了“平台报警”和“终端报警”，以及“非位置报警”

4.3.5

主要是终端报警

增加了下发车辆信息服务业务流程，增加了平台可按区域、车辆组别下发车辆信息服务的要求

增加了上级平台报文/信息下发到终端

8.1.6.3

新增了“上级平台通过企业平台下发报文信息到车载终端”的功能，要求可以群发

 

 

修改了车辆动态信息和静态交互业务流程

“交换”和“交互”重新梳理了下，旧版本描述紊乱，新版本表述更清晰。——仅文字梳理，没有特别要注意的地方

8.1.7

把“定位上报”、“车辆注册信息上报”等“交互”类功能归类到“8.1.3 车辆动态信息交互业务类流程”

 

 

8.1.8

内容没变

 

 

增加了基础数据交换业务流程描述

新增

8.1.9

包括“车辆静态信息”、“非位置相关的报警信息”、“路线信息”等

 

 

修改了消息数据头格式定义，增加了消息发送时间字段

重大变更：消息数据头格式变更，导致新旧标准无法兼容

8.2.6

数据头

4.4.6

数据头

修改了报文序列号字段的注释

重大变更：每条消息的流水号要根据子业务类型逐条编码

8.2.6

数据头

4.4.6

数据头

修改了平台加密算法

加密算法的代码部分有变化，新版本要按新标准来

8.2.7

数据加密

4.4.7

数据加密

修改了数据校验部分的描述

明确了CRC16码的生成函数

8.2.8

 

4.4.8

数据校验

增加了平台间消息应答超时机制

新增

8.2.9

协议中除明确说明无需应答的消息外，其余消息均应按照一请求一应答的消息来使用。如在约定的重传时间内未收到应答消息，请求方将视为超时，此后收到的对应应答消息视为无效。

 

 

增加了平台链路连接情况与车辆定位消息传输情况上报请求消息和应答消息数据体格式

新增报文

8.3.2.2

平台链路连接情况与车辆定位消息传输情况上报请求消息

 

 

8.3.2.3

平台链路连接情况与车辆定位消息传输情况上报应答消息

 

 

修改了上传车辆注册信息消息数据体格式，增加了车载终端通讯模块IMEI字段要求

重要！车辆注册消息数据体格式新旧标准不同，不兼容

8.3.3.1.2

上传车辆注册信息消息

4.5.3.1.2

上传车辆注册信息消息

修改了数据实体格式内有关于车辆定位信息字节数长度

重要！车辆定位信息数据体格式新旧标准不同，不兼容

8.3.3.1.3

实时上传车辆定位信息消息

4.5.3.1.3

实时上传车辆定位信息消息

8.3.3.1.4

车辆定位信息自动补报请求消息

4.5.3.1.4

车辆定位信息自动补报请求消息

8.3.3.2.3

交换车辆定位信息消息

4.5.3.2.2

交换车辆定位信息消息

8.3.3.2.4

车辆定位信息交换补发消息

4.5.3.2.3

车辆定位信息交换补发消息

8.3.6.1.3

车辆拍照应答消息

4.5.6.1.3

车辆拍照应答消息

修改了应答消息的数据实体格式要求

重要！各指令的应答消息的数据体格式新旧标准不同，不兼容

8.3.3.1.5

启动车辆定位信息交换应答消息

4.5.3.1.5

启动车辆定位信息交换应答消息

8.3.3.1.6

结束车辆定位信息交换应答消息

4.5.3.1.6

结束车辆定位信息交换应答消息

8.3.3.2.9

申请交换指定车辆定位信息应答消息

4.5.3.2.7

申请交换指定车辆定位信息应答消息

8.3.3.1.10

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

4.5.3.1.10

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

8.3.3.1.11

上报车辆电子运单应答消息

4.5.3.1.11

上报车辆电子运单应答消息

8.3.3.2.10

取消申请交换指定车辆定位信息应答消息

4.5.3.2.8

取消申请交换指定车辆定位信息应答消息

8.3.3.2.11

补发车辆定位信息应答消息

4.5.3.2.9

补发车辆定位信息应答消息

8.3.4.1.3

下发平台间报文应答消息

4.5.4.1.3

下发平台间报文应答消息

8.3.6.1.4

下发车辆报文应答消息

4.5.6.1.4

下发车辆报文应答消息

8.3.6.1.5

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

4.5.6.1.5

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

8.3.6.1.6

车辆应急接入监管平台应答消息

4.5.6.1.6

车辆应急接入监管平台应答消息

8.3.7.1.3

补报车辆静态信息应答消息

4.5.7.1.2

补报车辆静态信息应答消息

修改了上报驾驶员身份信息应答消息数据体格式，增加了证件有效期字段

驾驶员身份信息格式变化

8.3.3.1.10

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

4.5.3.1.10

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

增加了主动上报驾驶员身份信息消息数据体格式

新增

8.3.3.1.12

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

 

 

增加了主动上报车辆电子运单信息消息数据体格式

新增

8.3.3.1.13

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

 

 

增加了主动上报车辆行驶路线信息消息数据体格式

新增

8.3.3.1.14

主动上报车辆行驶路线信息消息

 

 

增加了车辆注册信息应答消息数据体格式

新增

8.3.3.2.2

车辆注册信息应答消息

 

 

修改了交换车辆定位信息消息描述

同前：车辆定位信息数据体格式新旧标准不同，不兼容

8.3.3.2.3

交换车辆定位信息消息

4.5.3.2.2

交换车辆定位信息消息

增加了交换车辆行驶路线信息消息数据体格式

新增

8.3.3.2.5

交换车辆行驶路线信息消息

 

 

修改了上报驾驶员身份信息请求消息数据体格式，增加上传标识

增加了上传标识：0×00:最近收到的消息；0×01:从终端获取

8.3.3.2.12

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

4.5.3.2.10

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

增加了上报车辆行驶路线请求消息

新增

8.3.3.2.14

上报车辆行驶路线请求消息

 

 

增加了上报车辆行驶路线应答消息

新增

8.3.3.2.15

上报车辆行驶路线应答消息

 

 

增加了平台间消息补传请求消息数据体格式

新增

8.3.4.1.4

上传平台间消息补传请求消息

 

 

新增

8.3.4.2.4

下发平台间消息补传请求消息

 

 

修改了平台查岗应答消息数据体格式，增加了查岗对象类型、查岗应答人姓名、查岗应答人联系方式、查岗对象ID字段

修改

8.3.4.1.2

平台查岗应答消息

4.5.4.1.2

平台查岗应答消息

修改了车辆报警信息交互业务类名称

去掉了“车辆”两字：报警类业务在新标准中不仅仅指车辆报警，还包括企业平台识别的报警

8.3.5

报警信息交互业务类

4.5.5

车辆报警信息交互业务类

修改了主、从链路的数据体描述，删除了车牌号码和车牌颜色两个字段

数据体结构有变化，新旧标准不兼容

8.3.5.1.1

主链路报警信息数据体

4.5.5.1.1

主链路报警信息数据体

8.3.5.2.1

从链路报警信息数据体

4.5.5.2.1

从链路报警信息数据体

修改了上报报警信息消息数据体格式

数据体结构有变化，新旧标准不兼容

8.3.5.1.3

上报报警信息消息

4.5.5.1.3

上报报警信息消息

增加了主动上报报警处理结果消息数据体格式

新增

8.3.5.1.4

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

 

 

增加了上报报警督办应答消息数据体格式

新增

8.3.5.1.5

上报报警督办应答消息

 

 

修改了报警预警消息业务名称，修改了报警预警消息数据体格式

调整了字段内容和顺序，新旧标准不兼容，与报警整体调整相一致

8.3.5.2.3

下发报警预警消息

4.5.5.2.3

下发报警预警消息

修改了实时交换报警信息消息数据体格式

同上

8.3.5.2.4

实时交换报警信息消息

4.5.5.2.4

实时交换报警信息消息

增加了上报报警预警消息数据体格式

新增

8.3.5.2.5

上报报警预警消息

 

 

增加了上报报警督办请求消息数据体格式

新增

8.3.5.2.6

上报报警督办请求消息

 

 

修改了上报车辆行驶记录请求消息数据体格式，增加了命令字字段

增加了命令字字段

8.3.6.2.5

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

4.5.6.2.5

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

增加了补报车辆行驶路线信息请求消息

新增

8.3.7.1.2

补报车辆行驶路线信息应答消息

 

 

修改了车辆定位信息数据体格式，有关于车辆位置信息部分，增加了每一级平台的报警标识字段

重要！车辆定位信息数据体格式新旧标准不同，不兼容

8.3.8.1

车辆定位信息数据体

4.5.8.1

车辆定位信息数据体

修改了车辆静态信息数据体格式

车辆静态信息按照最新标准实施：JT/T 697.7

8.3.8.2

车辆静态信息数据体

4.5.8.2

车辆静态信息数据体

修改了链路管理类业务流程

按新标准实施

8.1.1

链路管理类流程

4.3.1

链路管理类流程

增加主业务业务流程图

关注即可

 

 

 

 

 

 

 

  

(10315)

]]> http://www.jt808.com/?feed=rss2&p=1677 0 出租车jt/t 905协议与部标1078协议融合的网约车视频监控平台 http://www.jt808.com/?p=1632 http://www.jt808.com/?p=1632#comments Sat, 18 May 2019 10:02:31 +0000 admin http://www.jt808.com/?p=1632

出租车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升级协议的的升级服务器；

jt/t 905协议的网约车平台 

 

 

 

 

 

 

 

 

(10619)

]]> http://www.jt808.com/?feed=rss2&p=1632 0 基于JT/T 1078协议设计和开发部标视频服务器 http://www.jt808.com/?p=1584 http://www.jt808.com/?p=1584#comments Sun, 07 Apr 2019 09:21:47 +0000 admin http://www.jt808.com/?p=1584   交通部与2016年10月份推出了JT/T 1078-2016标准，全称是<道路运输车辆卫星定位系统视频通信协议>。该标准将改变以往两客一危车辆的视频监控设备通信协议都是设备厂商私有协议的局面。标准起草单位：交通通信信息中心、北京国交信通科技发展有限公司、江苏威森通讯科技有限公司、大连信开数码软件有限公司、深圳市锐明视讯技术有限公司、广州亿程交通信息有限公司、深圳市瑞信视讯技术有限公司、吉林省寰旗卫星导航通信集团有限公司、杭州海康威视数字技术股份有限公司、大连鼎视科技有限公司。这里面真正做视频老牌厂商也就是海康、大华这两家公司。 

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框架构建高性能企业级的部标视频监控平台

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

    部标1078视频播放器

 

3.界面设计

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

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

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

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

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

 部标1078视频服务器界面

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

Html5 部标视频播放器

 

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

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

6.上级监管平台的转发

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

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

部标1078视频压力测试

(26710)

]]> http://www.jt808.com/?feed=rss2&p=1584 0 基于部标1078视频协议和苏标Adas协议构建主动平台 http://www.jt808.com/?p=1564 http://www.jt808.com/?p=1564#comments Sun, 03 Mar 2019 09:22:39 +0000 admin http://www.jt808.com/?p=1564  

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

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

道路运输车辆主动安全智能防控终端设备参数表

 

如需购买苏标平台源码,请联系2379423771@qq.com

苏标平台架构设计参见文章:基于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卡与驾驶员不对应时，则平台记录一条驾驶员身份不匹配的报警信息，同时提醒企业监控人员进行处理。

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

(23535)

]]> http://www.jt808.com/?feed=rss2&p=1564 0 部标1077视频平台过检和压力测试经验分享 http://www.jt808.com/?p=1448 http://www.jt808.com/?p=1448#comments Mon, 23 Jul 2018 01:13:37 +0000 admin http://www.jt808.com/?p=1448 部标1077视频平台标准是在2016年10月份发布的，2017年1月1日开始实施，由于两客一危行业车辆如果做视频运营，必须要通过1077检测，所以现在两客一危平台检测默认是包含部标796GPS平台检测和部标1077视频平台检测。当然现在已有的两客一危平台肯定已经通过了部标796GPS平台的检测。但是对于市场新进入者，部标1077视频平台不能单独过检，需要先过部标796平台检测，通过796平台检测后，才能再进行部标1077视频平台检测； 虽然视频平台检测相比GPS平台检测，要多一个视频压力测试，但是视频平台的检测费用上面相比796平台过检，价格略低，检测费是3万元。796平台检测费是3.8万。不过如果以前没有过过796，则两次检测报名费用合计是6.8万。

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.统计结束后，截屏上传到检测系统当中，生成压测报告。

 部标1078视频压力测试

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

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

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

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

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

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

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

部标1078视频压力测试报告

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

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

 

1077视频平台检测

(17408)

]]> http://www.jt808.com/?feed=rss2&p=1448 0 基于Html5+HLS协议播放符合部标1078协议的实时流媒体视频 http://www.jt808.com/?p=1401 http://www.jt808.com/?p=1401#comments Tue, 05 Jun 2018 11:33:38 +0000 admin http://www.jt808.com/?p=1401     由于现在主流的部标GPS和1077视频监控平台，都是BS架构，在网页上播放视频，早期的很多平台用的都是ActiveX控件的形式，依赖于IE浏览器，需要降低浏览器的安全设置，而且非常难用。同时由于win10以后的操作系统上的浏览器，对于安全的把控非常严格，ActiveX插件做成的播放器嵌入到网页当中的形式，基本上要被扫入到历史的垃圾堆里面了。

    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>

 

1078视频服务器架构

     

    

(14323)

]]> http://www.jt808.com/?feed=rss2&p=1401 0 锐明部标视频设备和博实结设备对部标1078协议支持程度评测对比 http://www.jt808.com/?p=1350 http://www.jt808.com/?p=1350#comments Wed, 31 Jan 2018 03:08:56 +0000 admin http://www.jt808.com/?p=1350 我的一个客户，现在需要上线部标视频设备，但是对于锐明和博实结两家的视频设备，不知道哪家对部标1078协议支持的更好。希望我能帮他测一测。

对此次评测结果的总结：

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协议设计和开发部标视频服务器

jt1078视频服务器

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

客户首先给我的是博实结的一款设备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设备，并安装上车，怎么退货更换？ 客户的客户都饶了客户吗？

(18365)

]]> http://www.jt808.com/?feed=rss2&p=1350 0 驾培计时培训终端TCP通信协议和jt808协议的区别 http://www.jt808.com/?p=1331 http://www.jt808.com/?p=1331#comments Tue, 26 Dec 2017 02:11:41 +0000 admin http://www.jt808.com/?p=1331 交通部颁发的《机动车驾驶员计时培训系统平台技术规范》中的驾培TCP协议和jt808协议虽然很像，但有本质的不同，很多人以为就是部标808协议，这个认识是错误的，驾培协议是驾培协议，jt808协议是jt808协议，不能混淆，两者也并不兼容，从协议，终端设备到软件平台功能，都不兼容。当然你可以从jt808的代码上改造，但仍然需要花费很大精力。

 

 

机动车驾驶员计时培训系统符合性过检认证计时模拟终端的设计和开发

计时终端TCP服务器的开发，参见：机动车驾驶员计时培训系统符合性检测平台TCP服务器设计和开发

两者的开发框架和技术当然都是一样的，都可以用netty来做为通信框架，参见：基于Java Netty框架构建高性能的jt808协议的GPS服务器

基于Redis构建10万+终端级的高性能部标JT808协议的Gps网关服务器

 

基于部标JT/T 808协议及数据格式的GPS服务器

主要有以下的不同：

1）消息头

驾培协议消息头中终端手机号定位为16位，而jt808协议中的终端手机号为12位，首先消息头就要比jt808协议的长4位，从一开始就不兼容了。

驾培协议消息头

2）终端注册鉴权流程

驾培协议终端注册时，增加了IMEI号，这样设计方便了平台通过识别IMEI号，判断设备来源，比如很多平台都是和终端绑定的，使用我的平台，必须是我家的终端才能接入。

注册应答也有很大的差别，由于驾培是要求驾培数据加密传输的，所以需要平台在注册成功的时候，将加密证书下发给终端，由终端加密后，进行鉴权。

 

终端注册

终端在注册应答中，获取鉴权码和证书及口令，然后对鉴权码进行加密后，发起鉴权请求。平台获取到鉴权码，需要解密后，才能验证鉴权是否成功。由下图中可以看出鉴权指令和jt808有很大的不同，鉴权的目的是为了保证安全，所以鉴权码首先就要是加密的。

计时终端鉴权

3）加密传输

因为驾培是基于加密传输的，而jt808协议，传输并不加密。在发送驾培数据的时候，终端需要使用计时终端证书对整个扩展驾培消息（不含校验串）进行加密后生成，采用2048位证书时，长度为256byte。平台下发的应答数据不需要加密，但需要对终端的驾培数据验证签名是否正确。

4）拍照指令

照片是驾驶员培训审核的主要依据，所以照片功能是驾培计时终端和平台的核心功能，这块驾培协议中的拍照指令和流程，相对于jt808协议的拍照更加完善，当然也更加复杂。

拍照流程有了很大的区别，多了照片上传初始化的环节，便于平台在初始化环节就知道照片要上传的基本信息。

主要流程是是平台下发拍照-》终端应答-》终端照片上传初始化-》平台应答-》终端分包上传照片

由于照片数据是分包上传的，为了识别分包是同一个照片的，在协议中增加了照片编号的字段信息，这个也是jt808协议中所没有的，弥补了808协议照片上传的缺陷。

驾培照片数据上传

5）驾培指令

驾培指令是新增加的指令，学员培训过程相关信息的传输消息采用JT/T 808标准0×8900透传数据下行和0×0900透传数据上行进行扩展形成。透传消息类型定义为0×13。

 

6）驾培TCP服务器

相对于jt808服务器，计时培训系统平台TCP服务器的解析更加复杂，由于驾培协议对对部标808协议进行了大量的变动，由于808协议中增加了基于SHA256加密解密的规定，系统需要首先获得终端证书，计时平台新增计时终端时，全国平台会返回证书的base64编码以及证书的密码，在计时终端接入的时候，终端对鉴权请求进行了加密，系统需要获取X509Certificate证书对象，然后对终端的鉴权请求和驾培拓展协议数据的加密串进行验证签名。只有验证通过的数据，不仅要做正常的808服务器的数据入库功能和报警解析功能，还要将数据转发给监管服务平台。

如需购买驾培tcp服务器源码（含省平台对接和转发功能），请联系: 2379423771@qq.com

驾培tcp服务器

 

(24574)

]]> http://www.jt808.com/?feed=rss2&p=1331 0 基于Redis构建10万+终端级的高性能部标JT808协议的Gps网关服务器 http://www.jt808.com/?p=1282 http://www.jt808.com/?p=1282#comments Wed, 18 Oct 2017 14:02:04 +0000 admin http://www.jt808.com/?p=1282        在开发一个大规模的部标GPS监控平台的时候，就算我们花费再多的时间设计和规划，我们也并不能准确的预测出自己未来的车载终端接入量有多大，而且一开始就为了我们宏伟的设计蓝图，投入大规模的服务器硬件设备和网络带宽，这会带来极高的成本投入，也会在早期造成大马拉小车，空耗+复杂度过高。所以大多数的平台一定是从一两台服务器搭建运营环境， 随着车载终端量级越来越大，并发越来越高，业务模式也越来越复杂，我们需要将程序解构，从一个模块拆出多个模块，从单机运行变成多台服务器分布式部署，从单进程变成多服务模式。所以我们设计的时候，就必须要构建这种可扩展的由1变成N的架构，必须要有一个可扩展的高可用的基于部标jt808协议的服务器。

      我们这里所说的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服务器

     基于Redis的高性能部标808服务器

     在Web平台给终端下发指令的时候，如何知道终端是在那一台服务器上，这个是通过在Redis中缓存一个Sim卡号和部标808服务器Id的映射关系表，当终端接入的某台服务器的时候，808服务器会自动在Redis上更新映射表，这样web平台下发指令的时候，就知道通过那个部标808服务器下发指令。

     由于Redis有消息队列的功能，对于报警推送等实时性要求高的场合，当部标808服务器解析报警后，可以直接推送给Redis队列，然后web平台通过订阅消息队列，获取报警消息，然后再经由Websocket推送给前端平台。可以看出整个报警的推送路径发生了重大改变，不再是从数据库读取出来，而是通过典型的分布式内存，不断的推送。不单提高了报警响应的速度，更重要的是，大部分的GPS平台，报警误报频繁，频繁的插入数据库，对数据库压力非常的大。

   基于redis的部标808报警推送

(23710)

]]> http://www.jt808.com/?feed=rss2&p=1282 0 基于Websocket+springMVC4推送部标jt808终端报警 http://www.jt808.com/?p=1263 http://www.jt808.com/?p=1263#comments Wed, 09 Aug 2017 07:39:35 +0000 admin http://www.jt808.com/?p=1263 在开发部标监控平台的时候，我们要及时的将部标终端报警推送到web界面上，以弹窗的形式提供给用户显示，要将报警显示在界面上，部标808协议文档中规定的报警类型，如下图所示：

表 18     报警标准位定义

 


位

定义

处理说明

0

1：紧急报警，触动报警开关后触发

收到应答后清零

1

1：超速报警

标志维持至报警条件解除

2

1: 疲劳驾驶

标志维持至报警条件解除

3

1：预警

收到应答后清零

4

1：GNSS模块发生故障

标志维持至报警条件解除

5

1：GNSS天线未接或被剪断

标志维持至报警条件解除

6

1：GNSS天线短路

标志维持至报警条件解除

7

1：终端主电源欠压

标志维持至报警条件解除

8

1：终端主电源掉电

标志维持至报警条件解除

9

1：终端LCD或显示器故障

标志维持至报警条件解除

10

1：TTS模块故障

标志维持至报警条件解除

11

1：摄像头故障

标志维持至报警条件解除

 

 

 

从部标808协议文档中对于报警的定义可以看出，一个定位包要承载多个报警，具体对应到数据库记录，一条定位记录要对应多条报警记录，在GPS部标监控平台车辆数到达一定的规模的时候，特别是很多平台的终端在安装的过程中接线松动，造成频繁误报，报警记录就会急剧的增多，如果采用轮询的方式，客户端定时向服务器发送Ajax请求，服务器接到请求后马上返回响应信息并关闭连接。优点：后端程序编写比较容易。 缺点：请求中有大半是无用，浪费带宽和服务器资源。 只能适于小型应用。车辆规模达到一定数量的时候，数据库压力比较大，报警查询性能下降，难以及时的将报警显示在客户端的页面上。

 

而WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。依靠这种技术可以实现客户端和服务器端的长连接，双向实时通信。基于事件驱动能够实现真正意义上的推送功能。在客户端与服务器端交互的web应用中，websocket最适合在高频率低延迟的场景下，进行事件的交换和处理。所以特别适合车辆终端报警信息低延迟，短消息高频率的推送场景。

 

各种浏览器对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文件

springmvc+websocket

 

 

(19035)

]]> http://www.jt808.com/?feed=rss2&p=1263 0 基于Android平台开发jt808协议Gps终端App http://www.jt808.com/?p=1239 http://www.jt808.com/?p=1239#comments Thu, 06 Jul 2017 02:53:52 +0000 admin http://www.jt808.com/?p=1239 android系统的推出，可以说大大方便了部标808Gps终端开发的开发效率，现在招聘一个会c语言开发的人很难，但是招聘一个会java语言开发的人却很容易，从开发成本和开发效率上，都是有一个革命性的提升，现在的汽车电子，慢慢都会逐渐的转移到android平台上。调试也非常方便。剩下的工作就是刻苦钻研jt808协议文档，调试和开发协议栈，然后封装业务逻辑，最后再移植到嵌入式平台上了。如需购买源码，可以联系2379423771@qq.com.

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

808Mina客户端

主要工作有：

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

808协议Mina解码器

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

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

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

             ——数据通信链路断开；

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

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

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

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

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

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

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

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

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

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

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

(16328)

]]> http://www.jt808.com/?feed=rss2&p=1239 0 交通运输部办公厅关于印发《道路运输车辆卫星定位系统车载终端和平台标准符合性技术审查工作规范》的通知 http://www.jt808.com/?p=1215 http://www.jt808.com/?p=1215#comments Sat, 06 May 2017 12:03:47 +0000 admin http://www.jt808.com/?p=1215

部标符合性检测审查规范

交通运输部办公厅关于印发《道路运输车辆卫星定位系统车载终端和平台标准符合性技术审查工作规范》的通知  

 
 

交通运输部办公厅

交办运〔2016〕138号

　

关于印发《道路运输车辆

卫星定位系统车载终端和平台标准

符合性技术审查工作规范》的通知

各省、自治区、直辖市、新疆生产建设兵团交通运输厅（局、委）：

经交通运输部同意，现将修订后的《道路运输车辆卫星定位系统车载终端和平台标准符合性技术审查工作规范》印发给你们，请遵照执行。

             交通运输部办公厅

              2016年10月25日

道路运输车辆卫星定位系统车载终端

和平台标准符合性技术审查工作规范

第一章 总　　则

第一条 为规范道路运输车辆卫星定位系统车载终端和平台标准符合性技术审查（以下简称标准符合性技术审查）工作，确保标准符合性技术审查工作的顺利实施，根据《道路运输车辆动态监督管理办法》（交通运输部、公安部、国家安全监管总局2016年令第55号）及有关规定，制定本规范。

第二条 本规范所称道路运输车辆卫星定位系统标准规范主要包括《道路运输车辆卫星定位系统车载终端技术要求》（JT/T 794）、《道路运输车辆卫星定位系统平台技术要求》（JT/T 796）、《道路运输车辆卫星定位系统终端通讯协议及数据格式》（JT/T 808）、《道路运输车辆卫星定位系统平台数据交换》（JT/T 809）、《机动车运行安全技术条件》（GB7258）、《汽车行驶记录仪》（GB/T19056）以及相关技术规范。

第三条 标准符合性技术审查工作应当遵循公平、公正、公开和便民的原则。

第四条 交通运输部负责标准符合性技术审查工作的监督管理；对通过标准符合性技术审查的产品公告。

第五条 受交通运输部委托，中国交通通信信息中心（以下简称通信信息中心）为标准符合性技术审查提供技术支持，主要包括：

（一）组织制定标准符合性技术审查相关工作制度；

（二）负责对申请标准符合性技术审查单位的资质进行审核；

（三）负责建设和维护标准符合性技术审查信息查询网站，提供标准符合性技术审查工作咨询服务。

第六条 申请从事标准符合性检测的检测机构应具有《中华人民共和国计量法》、国家质量监督检验检疫总局发布的《实验室和检查机构资质认定管理办法》等有关法律法规及规章规定的基本条件和能力，并依法取得相关实验室资质认定证书。同时具有承担卫星定位系统车载终端或系统平台检测活动相应的计量设备、设施及软件检测系统，其性能、精度及软件的测试内容和功能应符合标准要求。

检测机构应当向通信中心备案。

检测机构依据实验室管理规定独立开展标准符合性检测工作，对出具检测报告的真实性和准确性负责，并承担相应的法律责任。

第七条 标准符合性技术审查工作程序主要包括：

申请车载终端或平台标准符合性检测的单位（以下简称申请单位）自主选择检测机构，检测机构根据标准和规程进行检测，并向申请单位出具检测报告。

通信信息中心对申请单位提交的材料进行资质审核，形成审核意见，按季度报送交通运输部。

交通运输部对审核通过的产品进行公示、公告。

第二章 标准符合性检测

第八条 申请单位可以自主选择具有相应资质的检测机构。

第九条 申请标准符合性检测，应提交以下材料及实物：

（一）车载终端。

1.车载终端产品完整设计文件；

2.送样型号的中文使用说明书；

3.车载终端产品出厂检测合格证；

4.车载终端产品入网设置及操作说明；

 5.同一型号检测样品不少于5套。

（二）平台。

平台的总体技术方案、用户手册。

第十条 车载终端标准符合性检测应在受理之日起3个月内完成检测工作。检测严格按照测试规程执行，如实记录检测结果，出具统一格式的检测报告。检测报告内容完整，数据真实，并经有关人员签字和检测机构盖章。

第十一条 检测报告一式三份，一份由检测机构存档，一份由申请单位留存，一份由检测机构在检测工作完成后10个工作日内，将检测报告交通信信息中心。

第十二条 检测机构应将检测过程的原始记录、检测报告和实物进行存档，其中样品留样不得少于5年。

每年6月30日和12月31日，检测机构向通信信息中心报送检测工作简报。

第三章 资质审核及公告

第十三条 申请单位在收到检测报告后，可及时向通信信息中心提出资质审核申请，提交下列材料（纸质材料、电子版材料各一份）：

（一）车载终端。

1.车载终端标准符合性技术审查申请书；

2.营业执照、中国国家强制性产品认证证书（3C证书：其中申请检测的车载终端型号必须与证书保持一致）；

3.检测报告。

（二）平台。

1.系统平台标准符合性技术审查申请书；

2.营业执照;道路运输企业自建非经营性企业监控平台须提供道路运输经营许可证。

3.检测报告。

第十四条 通信信息中心自收到申请材料之日起5个工作日内做出是否受理的决定。不予受理的，应书面告知，并说明理由。

第十五条 通信信息中心对申请单位提交的资料按照本规范等有关要求进行资质审核。

在审核过程中发现检测数据不完整或阶段性结论不正确、不符合标准要求的，中止资质审核并告知申请单位。

在审核过程中发现检测报告存在问题的，可要求原检测机构进行整改，直至原检测机构或第三方检测机构出具复检或补充报告。检测机构有义务免费承担车载终端和平台的复检工作。

在部公示前20个工作日未提交完整的审核资料的申请单位，顺延至下批次进行资质审核。

审核合格的，汇总报交通运输部。

第十六条 自主申请退出交通运输部道路运输车辆卫星定位系统公告名录的终端产品所属企业和平台所属企业，可及时向通信信息中心提出申请，提交道路运输车辆卫星定位系统产品退出公告目录申请书和营业执照。

第十七条 交通运输部对通过标准符合性技术审查及申请退出道路运输车辆卫星定位系统公告目录的产品进行公示、公告，原则上每季度发布一次。

第十八条 已公告的车载终端和平台，有下列情况之一的，应按新产品申请标准符合性技术审查。

（一）车载终端。

1.更换微处理器、卫星定位芯片、通信模块的；

2.变更设备适用终端类别的；

3.涉及车载终端能够影响设备性能和可靠性的其他重大技术性变更。

（二）平台。

1.平台系统架构、服务软件的性能发生变化的；

2.涉及平台能够影响系统性能和可靠性的其他重大技术性变更。

第十九条 已公告的车载终端和平台，有下列情况之一的，应向通信信息中心备案，提交变更申请且审核合格后报交通运输部公告，其变更详细信息将由通信信息中心发布：

（一）车载终端和平台产品申请单位名称信息、法定代表人发生变更的；

（二）平台产品变更平台名称及IP地址的。

第四章 监督管理

第二十条 具有下列情形之一的，通信信息中心对相关检测报告不予认可：

（一）检测结果不准确的；

（二）检测结论系伪造或者虚假检测报告；

（三）检测机构未经检测出具检测报告；

（四）检测机构被依法暂停、撤销检测资质的；

（五）其他违反法律、法规行为的。

第二十一条 经检查发现有下列情况之一的，将产品从公告目录中撤销，并将企业及其法定代表人信息向社会公布：

（一）伪造资质和相关法定证明材料的，伪造数据和记录的；

（二）销售或安装与通过标准符合性技术审查不一致车载终端的；

（三） 对车载终端设置技术壁垒，阻碍车辆正常转网的；

（四）通过不正当手段，骗取列入公告目录的；

（五）产品监督检查中发现的不符合标准或不符合质量要求的；

（六）其他违反法律、法规要求的。

第二十二条 从公告目录中撤销的车载终端产品，自撤销之日起不得以新增、替换等方式，再用于道路运输动态监控工作。

第二十三条 从公告目录中撤销的产品，其所属企业应依法进行整改，整改合格后，可申请标准符合性检测和审查工作。

重新申请恢复公告目录的车载终端产品，其组成配件应与原档案记录的配件信息一致。

第五章 附　　则

第二十四条 本规范由交通运输部运输服务司负责解释。

第二十五条 本规范自2017年1月1日起施行，有效期5年。2015年1月28日印发的《交通运输部办公厅关于进一步做好道路运输车辆卫星定位系统车载终端和平台标准符合性技术审查工作的通知》（交办运〔2015〕18号）中的《道路运输车辆卫星定位系统车载终端和平台标准符合性技术审查工作规范》同时废止。

(17751)

]]> http://www.jt808.com/?feed=rss2&p=1215 0 部标808协议、809协议、796标准、794标准的区别 http://www.jt808.com/?p=1178 http://www.jt808.com/?p=1178#comments Sun, 16 Apr 2017 03:03:09 +0000 admin http://www.jt808.com/?p=1178

通信协议是通信双方进行交互时所约定的标准语言，部标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消息头内容如下表所示：

 

起始字节

字段

数据类型

描述及要求

0

消息ID

WORD

  

2

消息体属性

WORD

消息体属性格式结构图见图2  

4

终端手机号

BCD[6]

根据安装后终端自身的手机号转换。手机号不足 12

位，则在前补充数字，大陆手机号补充数字0，港澳

台则根据其区号进行位数补充。  

10

消息流水号

WORD

按发送顺序从0开始循环累加  

12

消息包封装项

 

如果消息体属性中相关标识位确定消息分包处理，则该项有内容，否则无该项  

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

 

15  

14  

13  

12  

11  

10

 9

 8

 7  

6  

5  

4  

3  

2  

1  

0  

保留  

分包  

数据加密方式

消息体长度  

  

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

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

 jt809消息结构

 809消息头结构

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

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

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

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

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

808协议校验码算法

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

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年底前完成。

 

(62383)

]]> http://www.jt808.com/?feed=rss2&p=1178 0 机动车驾驶员计时培训系统符合性过检认证计时模拟终端的设计和开发 http://www.jt808.com/?p=1169 http://www.jt808.com/?p=1169#comments Thu, 13 Apr 2017 01:01:08 +0000 admin http://www.jt808.com/?p=1169 机动车驾培计时终端是具备视频监控和指纹认证等功能的车载驾培系统终端。结合了3G（wcmda、evdo）无线通信、GPS定位、RFID识别技术、IC卡识别功能、指纹采集认证功能、视频拍照摄像监控、语音监听处理等功能，充分实现了驾培过程中的实时监控、培训学时、培训里程、教练员/学员身份区别的功能。是一个复杂的硬件设备，针对此设备开发机动车驾驶员计时培训系统，供驾校人员和学员使用。

开发机动车驾驶员计时培训系统，开发效率低的其中一个原因就是需要不断和硬件设备，也就是教练车上的计时终端不断的交互联调，既然不能随心所欲，测试就容易草草了事，不充分，最后的问题就等着上战场，检测的时候一一暴露出来，开发前期暴露问题和检测的时候暴露问题，所付出的成本代价是不一样的，所以设计和开发者必须要重视此问题，越是测试不到的地方，越是问题集中的地方。

      作为有经验的软硬件一体化的平台开发者，都很清楚，无论是视频监控平台、GPS监控平台、驾培计时平台等等，还有很多行业如电力行业的实时监控系统，这样是这些软硬件一体化的平台开发工作量比较大、成本比较高的原因，一个是开发工作量大，一个是测试工作量大，测试成本比较高。在开发前期，都是非常注重模拟系统的开发。一个模拟系统所起的作用，很多人很容易忽视，这就是很多项目开发悲剧的原因。比如开发过程中出现问题，硬件团队和软件团队，或者软件开发公司和硬件供应商，常常扯皮闹矛盾，就是没有一个标准的模拟系统做比对，常常是软件认为硬件有问题，硬件认为软件有问题，这个扯皮造成的项目效率极其低下，沟通成本很高。    

我们根据2016年的机动车驾驶员计时培训系统符合性检测细则中的检测用例，设计和开发了模拟的计时终端，全方位的模拟机动车驾驶员计时培训系统平台技术规范，主要的功能特色有：

1）               可以在内网联调测试，不需要平台架设在互联网服务器上测试，开发者可以直接在本地基于开发环境Debug联调；

2）               测试数据的记忆功能，由于测试总是不断的重复测试，每次测试都需要录入繁琐无味的测试数据，如学员编号、车牌号、终端编号等等，耽误时间，所以将数据直接记忆在软件中，下次打开后，不再重新录入；

3）               大量的定时功能，如定时心跳，定时上报位置，定时上报学时记录，定时拍照等，真实模拟实车测试的路程；

4）               上行和下行的报文日志详细记录，不仅记录16进制的报文，也记录报文的解析数据。

         5)                  严格符合规范当中的数据加密和签名的要求，模拟终端实现了协议当中所要求的SHA256加密算法，通过加密算法将data、timestamp以及密钥做为参数生成的一串加密字符串，测试驾培平台对加密数据的验证签名功能；

6）               拍照是协议当中比较复杂的功能，真实模拟协议的复杂的拍照流程，方便开发者充分测试拍照。

 

驾培模拟计时终端符合性检测规范

驾培服务器如下图所示（有C#和Java两种版本源码可选其一，如需购买可以联系2379423771@qq.com) 

驾培符合性检测

完整详细的上行和下行日志报文记录，方便调试和分析。

驾培符合性检测协议报文日志

(11643)

]]> http://www.jt808.com/?feed=rss2&p=1169 0 基于部标jt/t809协议和Java Netty框架构建Gps位置监控平台 http://www.jt808.com/?p=1116 http://www.jt808.com/?p=1116#comments Sun, 05 Mar 2017 03:15:02 +0000 admin http://www.jt808.com/?p=1116 现在地方上由于运输车辆的GPS数据都分散在地方上已有的各种企业平台上面，不利于大数据的分析和智能应用，而开发智能的基于大数据的Gps监控平台，往往需要和各种第三方的部标GPS监控平台对接，获取到第三方的企业平台转发的数据，然后进行大数据的分析和应用，经过分析、统计和梳理后的数据，在web页面上进行各种复杂的地图、报表统计等功能的展现。

由于各地的企业平台基本都是符合交通部部标标准的，都具备809协议的转发功能，要和这些企业平台对接，不需要再一个一个的敲定接口标准了，只需要开发出809协议的网关应用，接入各地分散的企业平台的接入请求，就可以收集到车辆的位置数据了。

JT809网关数据接口服务系统，是基于TCP协议开发的部标809协议服务软件系统。系统利用高并发的Netty通信框架，采用通信双方约定的809协议规范，完成对协议数据的解析、拦截、数据入库、报警分析和转发的工作。并实现协议数据与上级平台、下级平台（多方企业运营服务平台）之间的数据通信桥梁。从而实现多部标企业平台车辆动态数据通过拦截、转发、存储的功能推送至自有企业平台。

 

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

         如需购买平台源码，请联系邮箱: 2379423771@qq.com

基于809的web平台，相对于一般的企业平台，有不同的复杂性：

1.由于多个第三方的企业平台的gps数据同时接入，相对于一般的gps平台，数据体量比较大，接入的车辆数多在几万台车甚至十几万台，对于网关的接入、分析、处理性能要求比较高。

jt809

2.连接维护的复杂性，由于809协议设计者设计了双链路的通信连接机制，主链路和从链路，还有数据加密的机制，加大了通信连接的复杂性，数据在传输过程中的断线重连，心跳机制是必须要考虑的，否则一旦数据中断了，第二天才发现，就会丢失大量的定位数据。

   针对以上特点，jt809平台的架构设计需要做到一下几点：

          1.       实时性

 网关接收到实时的定位数据后，实时位置数据和经过分析后的最新报警直接在内存中推送给web服务器，然后由web服务器推送到web页面上显示。

          2.       数据的分析

 海量的数据进入内存当中，等待分析和入库，所以分析和入库的速度必须要快，另外操作必须是异步的，不能堵塞通信连接和数据接收。

 基本的分析工作有：上线下线分析、各种终端报警分析、平台报警分析等工作；

 基于业务智能分析工作有：位置和运输业务结合的智能分析工作等；

 统计工作有：里程油量统计，上线率统计，其他结合业务的统计工作等；

          3.       存储和备份

 由于数据体量比较大，每天的定位数据记录都在百万级别以上，所以在系统运行前，存储和备份的规划工作必须要做在前面，否则后面数据库体积越来越大，难以维护和备份，另外数据库压力大，速度越来越慢也会影响web平台的正常运行。 存储和备份规划，影响着入库模块的设计以及web查询模块的设计，必须要做在最前面。对于海量的数据必须要分库分表设计。历史数据和报警数据分表设计如下图所示：

 

Gps历史轨迹数据分库分表设计

 

809网关服务器监控界面(界面采用swing开发，参见809转发服务器博客文章)

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

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

 

809数据网关

web系统 对809服务器连接和日志状态的监控

部标809监控

web界面上809消息通知和报警消息通知

809报警消息通知

809报警处理

(20780)

]]> http://www.jt808.com/?feed=rss2&p=1116 0 软件服务的价值 http://www.jt808.com/?p=1033 http://www.jt808.com/?p=1033#comments Mon, 26 Dec 2016 03:12:33 +0000 admin http://www.jt808.com/?p=1033       软件界面的功能，以及背后支撑的源码和体系，都来自我长期在GPS行业里的浸润，来自背后扎实的行业经验和知识，这些东西既不是我一朝一夕的来的，也不是是简简单单的一些文档都能描述和展现出来了。这些行业经验都是通过技术支持，与客户的技术问题沟通中，慢慢的服务于客户当中，解决客户在实际业务中一个又一个问题，这些问题有大有小，但是往往在QQ上的一句话，就能帮助客户少走弯路，少写无效的代码，这就是服务的价值。我给客户的作用，最保守的讲，起码相当于一个紧急项目中，空降了一个有经验的开发人员。这个作用，很多人应该能理解，总比招聘一个新人要强吧。

      技术人员也是公司的一员，多少也要站在公司全盘利益去思考问题，项目伊始，不能总是一根筋的乐观吧，怎么着也要掂量掂量项目烂尾的概率有多大，如果烂尾了对于公司的风险有多大，我的建议是，在项目开发中，无论做什么决定或者决策，都要有基本的担当，只有具备为自己的决策负责到底的精神，才能慎重思考开发的风险，不至于到后面项目收尾的时候，难以收尾和交付，严重延期或者直接辞职跳槽留下个烂摊子不管了，这无论是对公司还是对自己职业生涯，都是一种伤害。

      多数人长期被项目所累，没有闲心关注公司的成本结构，也没有觉察到人力短缺、人工工资成本增长的长期趋势已经形成，在人工成本高企的时代，如果不能大幅缩短项目开发周期，仍然沉浸在免费的喜悦当中，做温水里的青蛙，这些对于企业运作都是死局，看得见的成本，其实不是风险，因为你已经做了预算，看不见的成本，就是一把不见血的刀，如项目一拖再拖，不到项目彻底交付，你就不知道具体的成本代价有多高昂，错失掉的时间机会窗口有多痛心。对于什么带宽、服务器、电脑、工资等固定成本，无论多少，大家都很容易接受，对于通过购买源码，大幅缩短项目周期，挽救公司团队与水火之中的小额开支，反而很难接受，痛苦的不得了。其实做企业的，不是激情百米赛跑，而是马拉松或是穿越沙漠，困难重重，要清楚自己的力量是非常有限的，要节省体力和资源，用在最重要的方面，而不是迷失在岔路上，企业项目开发因小失大的案例太多了，根本不值得举例子。企业的掌舵人并不能真正理解，企业生存靠的是人才和核心技术，缺的也是核心技术，要通过购买核心技术快速弥补自己的短板，而不仅仅是拥有一堆带宽电脑服务器等固定资产。

      互联网上有很多人习惯于一句谢谢礼貌用语就想把别人辛辛苦苦的劳动成果拿到手，然后再也不联系了，总想着不花钱还能办成事，很滑稽，要是这样能行，为啥老板们还发工资干啥，弯腰鞠躬道声谢谢辛苦了就完事了。还有一些人贪图便宜不知道从哪里买的烂东西，遇到问题了，反过来让我提供免费技术帮助，我都很惊讶，这些人的思维怎么了，别人获利，让我提供技术支持，怎么想的？ 可是在现实生活中，恰恰是反过来的，有谁不重视服务呢？请个装修队给自己家装修，不仅是正常支付装修费用，装修期间还要买几条烟，买饮料给那些工人，生怕人家打马虎眼，应付了事。请个搬家公司，搬完家，还知道买几瓶饮料给大汗淋漓的师傅解渴。生病住院动手术，追在人家屁股后面塞红包给主刀医生和麻醉师。教师节，要给自己小孩的老师送去实打实的礼物，这才是真正对老师的尊重，一个班几十个同学，一个老师在8个小时之内不可能惠及所有同学。

     为什么给公司申请下费用都十分不情愿，一定要靠假意购买来达到目的呢，很多人在公司内都是项目经理乃至部门经理技术总监之类的，这不是低了自己的身份吗？本质上老板是想让你们把事情做好要的是最后的结果，不是让你来表忠心替老板省这三瓜两枣的，项目进度耽误一个月的花费比这个大多了。我平时都在上班做软件开发谋生存，全部时间都投在了付费用户的技术支持服务上面，哪里会有时间和这些假意购买的人打游击？通常我都是埋头做开发，大家各忙各的，既然无法杜绝，那就和谐共存吧。

     服务是无形的，而无形的价值，最容易被忽略，价格是敏感的，更容易被关注而导致走偏，忘记自己高昂的开发成本，比如让你购买一个808服务器源码，虽然只有1200元，跟割了自己的肉一样，很不情愿，如果反过来你们老板只给你1200元的月工资，你估计一句话不说拎起包都辞职了吧，你会觉得这简直对你是人格的侮辱啊。 所以要公平客观的思考下，源码对自己的价值，是否要远大于这点钱，特别是加快项目进度方面，购买源码后，立即就可以接入终端，数据入库了，有充足的时间可以做更上层的应用了。自己从头开发多长时间理论上谁也不好说；现在的人工成本，如果在项目开始时，设计阶段，拖拖拉拉犹犹豫豫，随随便便耽误几天的费用也远远大于这点钱。还有的客户因为自己在做部标系统的时候，做了一半，有些核心的问题处理不好，整个系统别别扭扭的，这种情况就非常尴尬了，项目进度很紧张了，再要时间很难了，进退两难，天天加班，一个月休息四天，装作很忙很累的样子，硬着头皮闭眼抹黑走哪算哪儿，怎么着也得混个没有功劳也有苦劳的结果。很明显是对于一个项目，购买源码如果能够大幅推进项目进度，挽救项目于水火之中，我敢说花费多少钱都值，再说了老司机们都知道，新开发的项目没有不严重延期的，做项目计划拍胸脯保证按期交付的都是睁眼说瞎话糊弄上级的，上级心知肚明再糊弄老板，全公司就老板一人天真的相信了，还问能不能再快点，盼星星盼月亮，准备好各种商业模式企划案，就等着产品出来，撸着袖子准备大干一番，这种长周期高成本试错的结局，如果这都看不清楚，还是不要坐在管理决策的位置上好，如果是创业者还是不要创业开公司了，多磨练捶打几年，再去开公司创业，否则学费也交的太昂贵了。     

     我是个人，为什么能服务很多大公司的客户，还有一些是A股的上市公司，如银江，大华等？因为再有实力的公司，也不可能无所不能，也不会傻到什么都要自己做，如果真正的给客户解决他们项目进度的问题，给他们提供解决方案，降低成本，又有那个老板人会拒绝同意呢？所以本质上甲方乙方是平等的关系，并不是你有钱你就牛逼，我有技术我就很拽，而是乙方的产品对甲方很有用，给甲方生产运营以实际有效的作用，大幅降低了成本，缩短了周期，而甲方当然愿意付钱，这是互联网经济下的双赢的合作。 现在一些客户喜欢和大公司合作，反而得不到应有的服务，为什么呢，流程繁琐周期长，签个烂合同就得个把月审批，其实大部分公司，搞技术的也就那么几个人，真正懂得更少了，当你需要服务的时候，还要从外围开始，从客服电话或者发送一个不知道什么时候回复的邮件申请开始，中间还可能走几天若干个部门的流程，电话或邮件被转来转去，最后历经艰辛，终于到达那个真正能够解决你问题的技术人员手里，先不要击掌庆贺，因为大公司业务繁杂，事情多，还得排队。如果把所有能解决问题的技术人员人数除以需要解决问题的客户人数，你所得到的服务资源，简直就是零点几几了。再看看很多公司的百年不变的企业网站上，说我公司有博士硕士本科高工多少人云云，简直就是笑话。

      我是地地道道搞技术的，我所有的时间都用在软件开发上面，在公司上班的时候，我就推崇各种加速效率的工具，极其讨厌开会扯皮磨洋工三拳打不出个闷屁，讨厌各种假大空，讨厌各种浪费时间的行为。我深知进得庙门来不都是烧香人，我的QQ上，我也并没有去说服别人改变思想，我比较坚信一点，愿意买的，自然会买，因为对他有用处。不愿意买的，你就是把源码给他，他也一分钱不会买，他连给领导提个申请打个报告的想法都没有。这个经验我想对于很多公司也是一个借鉴，很多公司的销售成本很高，给销售人员各种激励，许诺各种档次的提成，机票酒店出差补助等差旅费也很高，吃饭请客送礼喝的昏天黑地，这些营销成本变相加在产品价格里面，抬高了销售价格，动辄几十万的价格，反而增加了客户成本，哪里是真正为客户利益着想，所以结果并不好，还是要苦练内功把自己的产品做好，对人家有真正的帮助，自然会有人买。所以我的售前总是节奏明快，对于并不想购买的客户，不会扯太多口舌和时间在上面，愿意慢慢开发承受项目高昂成本和巨大进度压力，谁也拦不着；我竭力把宝贵时间放在售后服务上面，对于真正已经购买的客户提供更多的支持和帮助。            

      我创办网站的初衷就是为了降低企业的成本，而且里面包含有免费的技术支持，而技术支持才是最有价值的，我做过公交、冷链、驾培、物流、车载视频，可以帮助你快速理解我的代码和设计思想，在后续的二次开发过程中，帮助你顺利进行功能的调整和增加新功能，会写代码的多了去了，但是有设计能力，能遇到问题雪中送炭快速解决问题想出一个较好的解决方案的人不多。真诚的希望大家都关注下自己公司的项目开发成本，在这么高的成本之下，只有提高开发效率，缩短项目周期一条道，如果效率提不上去，项目进度反复延期，这对于公司是致命的。

(9215)

]]> http://www.jt808.com/?feed=rss2&p=1033 0 基于C#和Asp.NET MVC开发部标视频和苏标主动安全监控平台 http://www.jt808.com/?p=993 http://www.jt808.com/?p=993#comments Wed, 19 Oct 2016 12:21:49 +0000 admin http://www.jt808.com/?p=993 基于交通部796标准开发部标监控平台，选择开发语言和技术也是团队要思考的因素，其实这由团队自己擅长的技术来决定，如果擅长C#和Asp.NET, 当然开发效率就高很多。当然了技术选型一定要选用当前主流的技术，现在Asp.NET技术已经发展到5.0, 如果你还是用旧的ASP技术写程序，无疑是为以后的项目维护埋下地雷，后面新来人手学习不到技术，没有兴趣去改进，不愿意维护，没有人愿意接手。代码最关键的是要不断的重构，保持与当前的技术和需求同步，平台才有生命力，否则就会越来越臃肿而变得难以维护。开发一个基于Asp.NET MVC和C#语言的部标平台，主要应用的技术如下：

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平台所不能比的。

jt1078视频服务器

 

6) 根据苏标主动安全协议中的平台功能要求和苏标终端通信协议要求,增加苏标主动安全平台功能和苏标报警解析及附件上传功能.

详见: 

基于Asp.NET MVC框架+SignalR +ActiveMQ + Ali OSS 服务构建苏标主动安全智能平台

 

提供基于C#语言的Asp.NET MVC和WCF架构的部标平台源码，需要购买的请联系2379423771@qq.com，可以出差免费为客户提供技术支持和培训（差旅费用须由客户承担）

jt/t 1078协议历史视频回放指令和功能

asp.net 部标平台

开发工具是vs2012, 采用.net4.0,  asp.net mvc4 框架开发，项目工程结构如下图所示：

jt808项目结构

采用Nuget来管理项目依赖的lib库，非常方便，如下图所示：

使用nuget管理依赖的包

代码注释风格如图所示，力求干净简洁：

jt808源代码注释风格

目前整理了基于.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 地图应用程序架构设计

 

软件截图如下图所示：

部标gps监控平台主界面

支持百度高德地图聚合

百度高德地图聚合

支持海量车辆在地图上的位置显示和移动，通过颜色区分车辆的在线状态和停车行驶状态

海量车辆GPS位置地图显示

 

海量车辆位置在百度地图上显示

(20385)

]]> http://www.jt808.com/?feed=rss2&p=993 0 如何提高生产力-软件的开发与采购 http://www.jt808.com/?p=980 http://www.jt808.com/?p=980#comments Tue, 11 Oct 2016 03:06:18 +0000 admin http://www.jt808.com/?p=980 随着薪酬上升、劳动力人口萎缩以及文化变迁，公司利用廉价并卖力工作的员工获得优势的日子已经过去了。对于工厂制造企业连招聘一个技工都是很困难的事情，而软件企业招聘一个熟练技术的程序员更是很难。

人工成本的上升已经让行业感受到了很大的压力，制造企业的做法一般是：

1.将工厂迁往内地和东南亚等地；

2.引进先进自动化生产线，减少用工，采用机器人；

3.将非核心零部件交付第三方工厂采购，这样可以降低员工人数，提高生产效率，降低整个产品的生产成本；

4.对业务进行重构，将模块业务通过ODM的方式打包交给第三方工厂生产，自己主导产品设计、市场营销和用户体验；

而对于软件企业，还是停留在无奈抱怨发牢骚的阶段，离职多，招人难，员工要钱高不出活，眼睁睁的看着企业低效率高成本的运作，制造企业还可以升级生产线，用机器人等来提高自动化程度，软件公司却不能用机器人来替代程序员编程，也需要未来有可能。软件企业要想降低成本，唯有提高生产力，在提高软件质量的同时，还能缩短软件交付的时间，和时间赛跑，才能制胜。

很多企业虽然不是软件企业，但是有软件开发和团队，他们的企业是通过软件团队开发一款软件产品，然后再通过运营团队来运营获取利润的，简单的两步棋，第一步没走完，就死掉了，为什么？一支军队携带的粮草供应是有限的，在长途奔袭的情况下，如果贪恋中间一座城池，又久攻不下，就得玩完。所以不要低估软件开发的凶险，很多公司都是软件还没开发出来就结束了。

软件开发的凶险从在于其属于慢性毒药，开始并未引起足够的注意，进度一拖再拖，勉强交付后又不断的改版，每个月的成本老板都可以承受，但是时间长了，就受不了，开始压缩外围成本，如办公耗材福利奖金等成本，人心开始涣散，此时已晚，进退两难，领导或者老板的耐心终将慢慢的消磨掉。很多传统行业的老板手里有个千万或上亿的资产，挟上个行业成功的余威，进入软件行业，被软件团队搞的欲仙欲死的，每年都亏的不多，亏个百八十万的，但年年亏，又拉不下脸面承认失败关闭公司，当然软件团队也不是故意的。

软件企业为什么一直没有应对成本上升好的办法？

1）软件企业老板总是把眼光放在薪酬上，其实项目的成本是有薪资*时间来决定了，时间才是大头，软件老板，对于软件开发效率大多没有深入研究，软件开发的周期都是拍脑袋决定的，而实际的开发周期总是温水炖青蛙一般，缓慢而坚定的一拖再拖，为什么会这样？因为软件开发是比较特殊的抽象工作，有一个可怕的现象就是埋地雷，老板和市场压得紧了，就给你埋地雷，就是埋地雷，这个是老板们知道也不敢面对的事情，一个项目，你催的太急了，下来死任务，必须要在某年某月某日上线，那就给你买地雷，偷工减料，该是混凝土浇筑的，给你塞秸秆，先上线，后续再慢慢整改，造成任务交付的假象，我们称之为虚假交付，也就是第一个版本几乎是不能给用户使用的，强行交付给用户也会造成大量的投诉，抱怨，给公司产品形象造成很坏的影响。

2）由于没有企业制造的概念，没有采购意识，所有的工作都是从无到有的开发，所有的弯路都要从头至尾的摸索，成本自然高。关键是大家都习以为常，潜意识的认为向外采购，是增加了企业的开支，即使是买包卫生纸，都觉得增加了成本，而由于自己开发增加了开发周期，加大了项目成本，则没有人关心，老板对于人力递交的工资表，每个月少则几万元，多则几十万元的工资支出，都是没有任何反对意见的签字的。我们可以思考下小米手机，如果它像我们软件企业一样所有的东西都自己搞，黄花菜都凉了。

3）项目风险评估往往走形式，项目吃紧的时候就增加人手已经被证明是个愚蠢的办法，属于火上浇油添乱，现在就更加愚蠢了，因为前几年还勉强可以招到人，现在根本招不到人，临时加急招人属于痴人说梦话。但是我们仍然可以在项目会上听到有人这么说，明知道自欺欺人，领导也是没办法，总不能来个项目，对老板说做不了吧，只能硬着头皮做，后面的事再说吧。

4) 软件开发不同于工厂制造的一个因素就是预热时间长，项目虽然启动了，但是一大堆人迟迟进入不了状态，表面上很忙，实际上一行代码都没有写或者写了个Hello word，各种开会，写各种垃圾文档，ppt, 没有思路便在网上查阅各种技术文章，构思所谓的设计和技术选型，开会推倒再设计，这种低效状态能惊人的持续几个月，这几个月的人吃马喂的成本有多大，没人关心。做项目最怕犹犹豫豫，放屁一样的小事，要审批开发走流程好几周，反反复复，当断不断，拖拖拉拉，这是很可怕的，因为天上一天，地上一年，公司耽误一天的费用，也许够一个开发人员吃上一年。

所以软件企业要提高生成力，必要对于薪资*时间这个公式要花点时间进行一个深入的思考，学习制造企业，无时无刻的关注自己的生产效率。否则项目失控，则成本上升，最后就是白忙活一场，不该省钱的，不想掏钱，该控制成本的却失控了，搬石头砸自己脚。

软件企业应该通过以下手段来应对成本上升：

1）提高软件开发效率，如果交付周期缩短1/3，就可以应对薪资上涨的压力了；

2）通过模块化采购，来降低软件开发成本，缩短交付周期。

    在制造企业里，为什么要采购？

    1）有技术门槛或者含量的，自己没有能力生产的，或者生产的质量赶不上供应商的，比如三星手机，高端机的CPU芯片用的是高通骁龙820芯片，低端机用的是自家工厂生产的；

    2）没有技术门槛的，但是自己如果生产，由于没有规模效应，无法摊低成本，如饮料瓶，产品外包装等，再例如戴尔早期都是自己工厂生产，后来抵不过竞争压力，也交给台湾代工厂代工；

     软件企业的采购也是要秉持这两点，不是说没有技术门槛的，就自己搞，自己团队实在不能搞的再想办法找人开发，这种观点大错特错，很多项目经理之所以错误估计软件开发周期，就是因为觉得这个功能简单，那个功能容易，结果看上去容易简单的事情，要想做的一点毛病没有也不是三两天就能搞定的事情。要想一想自己公司为什么不用一个正式员工来天天帮你们打扫卫生？ 虽然容易但是琐碎、耗费时间的事情，正好是必须要交给别人做，而你正好抽出时间来做有价值的工作。很多项目计划的技术方案都是高大上，为什么做出来的都是普普通通的？这就是因为他们没有意识到时间是有限的，团队的时间都浪费在普通功能上和天天修改这些bug的上面了，那就没有时间去做更复杂和更有创意和挑战性的工作了，这就是我说的打仗的时候长途奔袭的战略了，如果在其中一个小城池上久攻不下，后面就要完蛋。

     我以前在已经公司里做技术总监，公司仓库需要一个库存管理系统，老板非要我们开发，我相信很多开发人员也觉得很简单。我说我们的开发人员，一个人一个月的工资成本至少要1万元以上，而市面上的成熟的库存管理软件只要5000元就搞定了，而且人家的是买回来安装上业务部门马上就可以用了。自己开发的库存管理软件，灰头土脸的开发很长时间，中间还要加班，出来第一版是不敢直接拿来用的，美其名曰试用。库存统计是与财务有关的关键业务，前面有一点bug算错后面全部都是错误的，如果库存统计有错误，那对于生产经营的损失，开发团队也承担不起。

     采购，其实不是网上随便抓个供应商就可以的，也不是价格越低就用谁的，我们原来做车载视频监控，车载摄像头是通过采购零件自己组装的方式生产的，外壳、机芯、电源线、铜柱等8家供应商，都是经过不断的试探，建立起来稳定而又长期的关系的，不会轻易换其他家的。软件的采购也是如此，需要寻找的是对于行业理解较深的，来建立自己长期而又稳定的关系的。很多人不理解这一点，动不动就找个外行的外包公司，这些外包公司里全是没有行业经验的低工资的软件开发人员，连需求和他们沟通起来都费劲，你想想他们能够给你开发出来什么好的软件产品？

  最有效率的采购和雇佣，本质上都应该是解决你的业务短板，有明显的互补作用，而不是简单的扩大的团队的规模，如果你找了个人和你一样是个不太了解行业，那他只会加大你的成本，而无助于提高生产力。行业门槛深似海，里面有很多坑，如果你不熟悉，一个坑一个坑的填，你的成本不高才怪呢？我以前的一家公司的老板就很聪明，公司当时做一个财务软件，一帮开发人员搞了几个月，进展缓慢，老板就直接从外面挖了一个专业会计人员，和开发人员直接一对一互助，这个项目做完后，那个会计人员本来是以兼职的身份，也不会编程，但后面还是被老板留下来了。

3）通过兼职或者雇佣专业人员来减少空转维持人力弹性

    软件企业很大的成本就是空转的成本，有的时候没有项目，工资还是要照付，所以为了寻找心里安慰，经常老板制造一些奇葩的思路，花样翻新的让团队忙起来，但并不创造效益。制造企业如果市场需求量不大的时候，可以停掉生产线，员工放假、半薪等方式来避免空转造成的损失，软件企业可不敢。专业人员是一种稀缺资源，薪资待遇要求又非常高，我们通常招聘不到，招聘来了老板又呲牙咧嘴觉得养不起，但是我们可以通过市场化来共享资源，在有项目的时候，可以利用一下，则没有项目的时候，就不再花钱，这样保持一个较好的人力弹性，避免空转。阿里云就是一个很好的高弹性高效率低成本的例子，我需要做测试的时候，就开一个服务器实例，临时用几天，不用了就直接关闭掉，需要的时候再开。需要做压力测试，网络要200M带宽的时候，就临时加开200M带宽，开3个小时是几十元钱，测试完毕再降低到2M带宽。但是如果按照以前的机房套路，开一个月的200M带宽，一个月的成本就要上万元。

      不要过于关注外购成本，而忽略自己开发成本，外购的目的就是为了大幅缩短自己内部的成本。要知道时间才是最大的成本，比如：我的部标808GPS服务器源码只不过卖1200元，而且是完整实现808协议栈的，很多人一看到源码是收费的，就痛苦的不得了，或者举棋不定，犹豫不决，说实在话我很难理解，别说一个完整的GPS部标平台了，单独开发一个完整808协议的GPS服务器，没有三个月根本搞不定，而我的部标808服务器源码只要1200元，又是经过很多人使用和锤炼过的，价格只相当于一个程序员三天的工资成本，更关键的是可以获得我的专业的技术支持，少走弯路，这么简单的帐都算不明白，很多人在互联网上翻箱倒柜的查阅资料，一直无法进入状态，所耗费的时间×工资成本，也远远大于这点钱吧。在公司里如果你们老板别说少发给你一个月的钱，就是晚两天发，你就要跳起来了。

      做项目就像下棋一样，比赛结束输赢已定，只能复盘获得经验教训而不能吃后悔药改变结果，如果项目结束后，我们知道自己开发成本至少十几万元，就不会不舍得购买只有部标平台了，钱是小事，时间荒废掉是大问题，你顶着进度的压力，也许还要加班，至少要忙乎一年，在这么长的时间里其他市场业务部门就等这你的平台上线而无所作为。肯定如不如购买部标平台源码，马上就有一个部标平台了，业务部门马上可以行动了，而技术部门可以集中精力开发与行业相关的，有差异化竞争力的功能和特性了。

productivity

(15048)

]]> http://www.jt808.com/?feed=rss2&p=980 0 基于Java Netty框架构建高性能的jt808协议的GPS服务器 http://www.jt808.com/?p=971 http://www.jt808.com/?p=971#comments Thu, 15 Sep 2016 13:28:23 +0000 admin http://www.jt808.com/?p=971 使用Java语言开发一个高质量和高性能的jt808 协议的GPS通信服务器，并不是一件简单容易的事情，开发出来一段程序和能够承受数十万台车载接入是两码事，除去开发部标jt808协议的固有复杂性和几个月长周期的协议Bug调试，作为大批量794车载终端接入的服务端，需要能够处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理等。如果没有足够的网络编程经验积累和深入了解部标jt808协议文档，自研的GPS服务器往往需要半年甚至数年的时间才能最终稳定下来，这种成本即便对一个大公司而言也是个严重的挑战。

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

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

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

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

高性能的部标808GPS服务器的三个主题

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管理。

部标808服务器

基于netty和mina的部标808gps通信服务器

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

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

部标808gps服务器主界面

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

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

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

808服务器主要用的库表： 

部门表

车辆表

终端表

实时表

历史轨迹表

驾驶员表

电子运单表

报警统计报表

报警推送表

电子围栏表

线段表

终端命令表

终端参数表

基础数据表

多媒体上传记录

行驶记录仪表

里程统计中间表

部门上线率统计表

油量变化记录

油量和里程统计表

车辆上线率统计表

五分钟一次油量和里程记录

 

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

 

序号

项目名称

触发条件

预期回应

01

终端心跳

根据设定的心跳时间参数，定时自动上报

主动上发，需要平台提供通用应答，长时间无法获得应答将导致程序自动断开重连。

02

设置终端参数

平台下发

回复通用应答，可设置的参数参考行标协议文本8.8

03

超速设置

平台下发

回复通用应答

04

疲劳驾驶设置

平台下发

回复通用应答

05

超时停车设置

平台下发

回复通用应答

06

查询终端参数

平台下发

回复0×0104应答参照行标协议文本8.10描述，回复的参数信息包含前述设置指令所设定修改的内容

07

终端控制

平台下发

回复通用应答

08

位置信息查询

平台下发

回复固化的位置信息：26.033435N，119.139317E

高度23.59，速度0，角度0

09

临时位置跟踪控制

平台下发

回复通用应答

10

文本信息下发

平台下发

回复通用应答

11

追加事件

平台下发

回复通用应答

12

删除特定事件

平台下发

回复通用应答

13

更新事件

平台下发

回复通用应答

14

修改事件

平台下发

回复通用应答

15

删除全部事件

平台下发

回复通用应答

16

追加新事件

平台下发

回复通用应答

17

提问下发

平台下发

程序立即回复通用应答，稍后由用户手动操作回复提问

18

信息点播菜单追加

平台下发

回复通用应答

19

信息点播菜单修改

平台下发

回复通用应答

20

信息点播菜单更新

平台下发

回复通用应答

21

信息点播菜单删除

平台下发

回复通用应答

22

信息点播菜单追加

平台下发

回复通用应答

23

信息点播菜单修改

平台下发

回复通用应答

24

信息点播菜单更新

平台下发

回复通用应答

25

信息服务

平台下发

回复通用应答

26

电话回拨

平台下发

回复通用应答，不触发任何逻辑动作，请关注日志

27

电话回拨_监听

平台下发

回复通用应答，不触发任何逻辑动作，请关注日志

28

设置电话本_删除

平台下发

回复通用应答

29

设置电话本_更新电话本

平台下发

回复通用应答

30

设置电话本_追加电话本

平台下发

回复通用应答

31

设置电话本_修改电话本

平台下发

回复通用应答

32

车辆控制_车门解锁

平台下发

回复通用应答

33

车辆控制_车门加锁

平台下发

回复通用应答

34

更新圆形区域

平台下发

回复通用应答

35

删除圆形区域

平台下发

回复通用应答

36

更新矩形区域

平台下发

回复通用应答

37

删除矩形区域

平台下发

回复通用应答

38

更新多边形区域

平台下发

回复通用应答

39

删除多边形区域

平台下发

回复通用应答

40

更新路线

平台下发

回复通用应答

41

删除所有路线

平台下发

回复通用应答

42

行驶记录仪数据采集命令

平台下发

根据形式记录议命令字发回测试数据，数据可能会产生分包

43

行驶记录仪参数下传命令

平台下发

回复通用应答

44

抓拍立即上传

平台下发

回复通用应答，随后分包上发固化的多媒体数据，上发数据与多媒体通道有关*

45

录像立即上传

平台下发抓拍指令附带录像提示

回复通用应答，随后分包上发固化的多媒体数据，上发数据与多媒体通道有关*

46

检索多媒体列表

平台下发

根据查询的多媒体类型回复固化的多媒体列表数据，参考行标协议8.46，通道与时间参数将被解析于日志中，但是不会影响列表内容

47

存储多媒体上传

平台下发

根据通道*和多媒体类型定义回传多媒体数据，时间和事件等参数将被正确解析与日志中，但是不会影响上发的多媒体内容

48

录音32Kbps立即上传

平台下发

回复通用应答

49

数据下行透传

平台下发

回复通用应答

50

平台RSA公钥

平台下发

回复终端RSA公钥，本软件将把平台下发的RSA公钥回发以验证协议的正确性

 

 

 

 

 

(30186)

]]> http://www.jt808.com/?feed=rss2&p=971 0 部标808协议模拟终端的设计和开发 http://www.jt808.com/?p=964 http://www.jt808.com/?p=964#comments Thu, 25 Aug 2016 14:38:37 +0000 admin http://www.jt808.com/?p=964 围绕车载部标GPS硬件开发的各种企业部标监控平台，如油耗、冷链运输、公交、危险品运输等平台，在开发过程中，都面临一个很重要的问题就是如何测试。因为整个软件平台的数据都是来自于车载GPS，我们不能在开发阶段，在几百辆或几千辆车上去实弹测试。即使在一台车上安装一个GPS来配合我们测试，成本也是非常高的。

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

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

部标808模拟终端源码

(26022)

]]> http://www.jt808.com/?feed=rss2&p=964 0