同时由于部标协议在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较796新增检测项如下表所示:

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

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

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

(22203)

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

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

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

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

(10514)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(17626)

(17905)

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

1.通信场景

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

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

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

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

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

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

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

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

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

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

2.应用场景

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

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

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

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

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

3.包含关系

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

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

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

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

4.消息包结构区别

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

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

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

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

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

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

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

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

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

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

6.通信链路的区别

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

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

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

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

7.版本变化

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

8.交通部要求

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

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

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

(62706)

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

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

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

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

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

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

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

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

          1.       实时性

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

          2.       数据的分析

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

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

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

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

          3.       存储和备份

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

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

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

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

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

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

(20958)

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

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

(26224)

gps监控平台是否符合部标808协议，需要有完善的部标协议测试工具和测试用例支持，才能进行充分的测试，很多gps软件开发速度缓慢，就是因为没有很好的测试工具和测试用例作为驱动，只是被动的实现功能，至于是否是严格符合标准，浑然不知。

如何设计一个模拟终端，可以参考一下功能列表来进行设计和开发。功能有很多可以借鉴的意义，

具体开发技术参见文章：部标808协议模拟终端的设计和开发

在开发一个gps车辆管理系统中，很多动态的数据不能都上路测试，这样测试的成本很高，比如冷链监控中的如何模拟温度来进行测试，不能只说简单的模拟温度，还要模拟温度的变化，不断的触碰程序的临界点，这样才能很好的测试，同理入油耗监控，还有模拟混凝土渣土车的正反转传感器功能等等。对应部标809协议的模拟和测试功能，参见：GPS部标809检测软件使用说明.。压测测试的模拟和功能参见：企业监控平台标准符合性压力检测实施细则

   1）C#版的808GPS服务器开发-》基于部标JT/T 808协议及数据格式的GPS服务器

   2）Java版的808GPS服务器开发-》基于Java Mina框架的部标808服务器设计和开发

  3)  基于Java Netty框架构建高性能的Jt808协议的GPS服务器

  4)  基于部标Jt/T809协议和Java Netty框架构建Gps位置监控平台

1.1 模拟终端操作说明

1.1.1  程序主界面介绍

模拟终端程序主界面如下图所示：

1.1.2  参数配置界面

通过主界面菜单栏-〉设置-〉参数设置菜单项可以启动参数配置对话框，如下图所示：

模拟终端程序必须同时与检测数据库以及被测平台建立连接才能正确运行，请正确配置您的数据库IP。模拟终端程序一般用于对用户平台进行检测，因此请将数据库名称设置为“gpscompany”。正确连接待测平台需要配置待测平台IP以及待测平台端口号，请根据待测平台实际的部署情况进行正确设置，并确保本机以及网络防火墙放行这些地址和端口。如果待测平台未提供短信网关，平台短信号码可以留空。

终端ID、车牌颜色代码、车牌号和终端手机卡号（SIM/USIM）填写请根据平台的注册信息进行填写，SIM卡号填写内容长度必须为12位，不足12位的须在前方补0，例如13912345678应当填写为013912345678;车牌颜色代码填写请参考JT/T415-2006标准5.4.12.3章节进行填写（常用代码：1蓝色，2黄色）。

省域ID、市域ID请参考GB2260国家标准进行填写，制造商ID与终端类型请按照检测平台的入网信息进行填写，如果待测平台没有特殊的要求，这些信息也可以留空或取默认值。

模拟终端程序的技术参数方面，通常将心跳时间设置为30秒，重发次数设置为3次，重发间隔时间为15秒，连接类型为1时使用TCP连接，为0时使用UDP连接，实际使用中请将此项设置为1。

1.1.3  开始测试

软件启动时序在窗口左上方进行用户登录，输入检测平台用户账户完成登录后即可使用主界面功能。点击左上方待测平台选择框，选择已登记的待测平台，点击“确定”按钮完成选择。按下“开始”按钮，此时模拟终端将尝试连接待测平台，右上方显示“正在连接”；如果连接成功，则右上方出现绿色图标，并显示“已连接”，稍待片刻便可看到日志栏中的通信日志。  

此时鼠标点击功能项与用例列表可在右方的用例详细信息框中查看该用例的详细信息，如果详细信息无法完整显示，可通过鼠标双击该详细项目查看完整内容，如下图所示：

各项测试用例均采取人工判定方式，检测员根据用例要求观察通信日志解析，看模拟终端与平台的交互是否正确，数据是否符合要求，鼠标右键单击功能项与用例列表中相应的检测项目，在右键弹出菜单中判定该项目是否通过。判定通过的项目将采用绿色图标标记，不通过的采用红色图标标记，未判定的项目采用灰色图标标记。测试完成后点击“结束”按钮保存结果并退出程序。

检测过程中检测日志信息是检测的核心依据，它将与检测结果一起保存于数据库中，对于无法完全显示的通信日志信息，鼠标双击日志列表项目可查看日志详细内容包括通信数据的16进制代码，如下图所示：

1.1.4  执行用例

检测用例可分为两类，一类是模拟终端需要主动发送指令的，另一类是被动接收平台下发指令的。

被动收取的平台指令后，模拟终端将自动根据内建用例予以回复，并记录到日志中；而由模拟终端主动上发的用例行为，则由用户在手动用例中自行触发，点击主界面上方“手动用例”按钮，程序会弹出手动用例的对话框如下图：

1.2 手动用例说明

1.2.1  终端注册

默认情况下，模拟终端会自动读取配置文件并尝试注册，但是该过程只会执行一次，并在下次发出注销指令前，不会再发生，因此程序提供了手动注册用例。可在手动用例对话框左上方的选择下拉框中选择“终端注册”项（如下图所示），配置注册所需的参数后点击“执行命令”按钮。此时会跳出确认对话框，点击确认即可完成用例发送。此后请查看日志栏中记录的解析日志，确认注册是否成功。 

1.2.2  终端鉴权

终端鉴权同样是模拟终端自动触发的，在实际测试时如有需要也可以通过手动用例再次尝试鉴权，在手动用例对话框左上方的下拉框中选择“终端鉴权”项，如果上次通过手动用例执行过注册流程，程序将自动把鉴权码填写到文本框内，否则请自行输入鉴权码，并点击“执行命令”按钮执行鉴权。

1.2.3  终端注销

注销操作将清空当前程序中所存储的所有鉴权信息，并可能导致服务器断开连接。在手动用例对话框左上方的下拉框中选择“终端注销”项，并点击“执行命令”按钮可完成注销。

1.2.4  手动位置上报

手动位置上报用例用于模拟真实GPS终端向待测平台发送定位信息，在手动用例对话框左上方的下拉框中选择“手动位置上报”项，经纬度信息中如出现西经、或南纬信息请勿使用负数表示，而应当在位置信息选项中点击单选按钮选择。“告警状态”栏可以根据需要进行勾选。填写完成后点击“执行命令”按钮上报位置信息。

1.2.5  定时位置上报

定时位置上报功能用于模拟GPS终端在正常工作状态下定时上报位置信息的行为，在手动用例对话框左上方的下拉框中选择“定时位置上报”项，程序默认调用内置的定位信息序列表（./GPSData/GPS_Pos_1.txt），如果用户需要使用自己的定位序列表也可重新指定新的序列表文件，序列表使用文本文件表述，每行一条数据格式为：“经度 + <Tab> + 纬度”，点击“执行命令”按钮执行定时上报。

1.2.6  驾驶员身份信息采集上报

该用例用于检测驾驶员信息主动上报功能，在手动用例对话框左上方的下拉框中选择“驾驶员身份信息采集上报”项，在“驾驶员身份信息”各栏中输入相应的参数信息，点击“执行命令”按钮上报驾驶员身份信息。

1.2.7  数据上行透传

在手动用例对话框左上方的下拉框中选择“数据上行透传”项，在“上行透传模拟数据”中输入相应参数，消息类型请根据待测平台的实际情况进行选择，并点击“执行命令”按钮执行数据透传。

1.2.8  多媒体事件信息上传

使用多媒体事件信息上传用例可立即向待测平台发送一个多媒体事件，在手动用例对话框左上方的下拉框中选择“多媒体事件信息上传”项，在“多媒体事件信息”区内输入相应参数，多媒体ID对应一个对媒体文件代号，应当为大于1的整数，通道ID应当输入大于1的整数，且建议该值小于5，点击“执行命令”按钮发送多媒体事件。

1.2.9  电子运单上报

电子运单上报用例用于编辑并发送一串电子运单文本上报待测平台，检测平台对电子运单的收取和管理。在手动用例对话框左上方的下拉框中选择“电子运单上报”项，输入电子运单文本信息后，点击“执行命令”按钮上报运单信息。

1.2.10 信息点播取消

信息点播用例用于测试平台信息点播功能，可根据平台下发的点播列表进行定制或取消，该项功能属于用户交互功能，实际应用中用户可以自由定制取消，或不进行任何操作，但是执行测试时应当通过此手动用例进行回应。在手动用例对话框左上方的下拉框中选择“信息点播取消”项，根据需要选择点播或者取消，并点击“执行命令”按钮发送定制信息。

1.2.11 事件报告，提问应答，数据压缩上传

事件报告、提问应答以及数据压缩上报三个用例包含于同一个功能选项卡中，可同时上报，亦可单独发送。在手动用例对话框左上方的下拉框中选择“事件报告，提问应答，数据压缩上传”项，提问应答和事件报告功能均为用户交互型功能，平台下发事件定制或提问后模拟终端立即发送通用应答，而实际交互的结果则是通过手动选择发回平台；压缩数据上报接受字符串数据输入。勾选需要上报的信息项，输入相应参数后点击“执行命令”按钮即可一次性执行完所勾选的所有项目发送。

1.3 模拟终端自动应答流程协议对照表