北京汽车行驶记录仪交通部平台过检JT/T 1120-2017标准

道路运输车辆卫星定位系统架构
4.1道路运输车辆卫星定位系统山**平台、企、Ik平台、车载终端、计算机通信网络等组成。通过系统 各组成部分之间的互联互通，实现业务管理以及数据交换和共享。
4.2**平台通过平台接II及统计分析功能•主要实现对上级平台的数据报送、对下级**平台的管 理和对企业平台的监管和服务。
4.3企业平台接人到**平台•主要通过对车载终端的控制•实现对背运车辆安全运背的监控，并实时 上报各项数据给**平台。
4.4**平台之间通过专线网络或互联网*方式进行连接•企业平台与**平台可以通过互联网 或专线网络方式进行连接•车载终端与企业平台或**平台之间通过尤线通信网络进行连接。
5**监管平台
5.1 基本功能 5.1.1接入平台管理
接入平台管邵应具备接入▼•台配置管珂、信息查询和考核等功能，体功能要求如下：
a） 配咒管理，包括接入平台参数配汽、接人平台参数杳间及接入平台参数统il•等基本功能；
b） 信息杏询•包括平台基本情况、平台在线车辆、平台运行日志和平台巡检日忐等卉询功能；
c） 考核，包括平台自动杳W、平台丁• I:杳W、平台动态数据传输情况、平台链路通断情况、平台个: 辆上线情况、平台车辆历史在线情况和动态数据传输及质量情况等•具备对接人平台按日、周、 月、季和年进行考核的功能；
GB/T 35658—2017
d）数据补传指令•对接人平台动态数据传输屮存在断线或数据确实怡况的.应具备针对中.车、多 车或幣个平台在某时间段内数据的补传指令下发功能。
5.1.2报表导出功能
平台中所有仵询结果及统计分析结果均应支持excel格式的报表导出功能。
5.1.3车辆数据定时同步功能
平台应具备平台间午辆数据定吋N步功能。
5.1.4报警
**平台应具备接收山接入平台上报的报箬信息的功能.包括紧急报筲、偏离路线报筲、**速报警、 区域报警、疲劳驾驶报警、边规行驶报警、前撞报警、胎爪异常报警、车道偏离报警、动态信息上报异常报 警等。产也报警时，pj•通过声、光、图片和文字等方式提示并M示车辆动态位ft.信息、静态信息和相关 信总。
5.1.5 报警管理
**平台应具备接收接人平台上报的报警信息及对应的报警处理倍息的功能。如下级监管平台或 企业甲台米在约定时间内i•.报报警处现信息，监管平台应能手动或n动向j<:发送报筲处置请求指令。
5.1.6基本资料管理
基本资料管理位具谷对接入平台的各种车辆、从业人M和运输企业等基本资料的查询管理功能。
5.1.7危险品车辆/企业管理 5.1.7.1危险品车辆管理
危险品车辆管理应具备查询和统计功能，具体要求如下：
a） 危险品车辆查洵.包括在线危险品车辆查询、I:线危险品车辆查询、跨域危险品车辆查洵、运输 危险品货种信息査询、危险品运输线路奄询和报警愤况查询等；
b） 危险品车辆统计.包括危险品1•:辆在线情况统计、危险品车辆h线情况统计、危险品跨域（不M 地区监管平台间）怙况统计、危险品车辆报警悄况统计和危险品车辆分布惜况统计等。
5.1.7.2危险品运输企业管理
危险品运输企、Ik管理；iZ具备查洵、统il•及考核功能，具体要求如K:
a） 危险品运输企业査询，包括危险品运输企业详细情况查询；
b） 危险品运输企业统il•，包括危险品企、Ik分布愔况统il•、危险品运输企业所属个:辆存:线情况统ih 和危险品运输企业所属车辆报警情况统计等；
c） 危险品运输企业考核，包括危险品运输企业的月度、手•度和年度考核。
5.1.8班线客运车辆/企业管理 5.1.8.1班线客运车辆管理
班线客运车辆管理应具备查询和统计功能，具体要求如下：
a）班线车辆查询•包括在线班线车辆査询、上线班线车辆查询、跨域班线车辆査询、营运线路査 询、夜间非法营运查询和报警情况查询等；
GB/T 35658—2017
b）班线车辆统计•包括班线车辆在线怙况统计、班线车辆上线怙况统计、班线车辆跨域（不N地区 监管平台间）情况统汁、班线车辆报筲情况统计和班线车辆分布情况统计等。
5.1.8.2 班线客运企业管理
班线奔运企业管理应具备仵询、统计及芩核功能•具体要求如下：
a） 班线客运企、Ik杳洵，包括班线客运企、Ik详细惜况杳洵和班线客运线路杳洵；
b） 班线客运企业统计•包括班线客运企业分布情况统计、班线客运企业所MV辆在线情况统计、 班线客运企业所属车辆报警情况统计等；
c） 班线客运企业考核•包括班线客运企业的月度、季度和年度考核。
5.1.9旅游包车车辆/企业管理 5.1.9.1旅游包车车辆查管理
\电子地图管理 5.1.13.1电子地图基本功能
电子地1冬1应具备包括漫游、放大、缩小、全1別、拉框放大、拉框缩小、距离贵算、比例显示、打印和当 前屏幕图像保存等基本操作；具备电了•地图的鹰眼功能、标注功能、图层控制功能、M算功能、地观信息 査询功能和路径分析功能；具备对电了•围栏设置、行驶区域设置和行驶路线设置功能。
地理信息仵询具备对设施点、地名、道路和行政区域的模糊检索功能。
5.1.13.2电子地图表达
电子地图表达应符合GB 20263的规定。
5.1.13.3目标影像展现
**平台应支持车辆等动态0标、自定义设施和点线面叠加；支持地图显小•、影像显示、影像和地图 叠加显示。

为规范产业发展，引导行业有序提升，交通部颁发了《关于认真贯彻<道路运输车辆卫星定位系统平台技术要求>和<道路运输车辆卫星定位系统车载终端技术要求>两项标准的通知》（交运发〔2011
〕158号），并相续出台了《道路运输车辆卫星定位系统终端通讯协议及数据格式》(JT/T 808)、《道路运输车辆卫星定位系统平台数据交换》(JT/T 809)和《道路运输车辆卫星定位系统平台技术要求
》（GB/T 35658-2017）部级标准，又称“国标”。 “部标”是交通部制定的行业较高标准，是为了落实国家《十二五》关于物流的规划，加快物流信息化建设，推动物流技术创新， 增强跨地区道路
运输安全管理、市场监管和服务能力而设立的**标准。 要达到“部标”标准必须通过JT/T808-2019、JT/T 809-2019和GB/T 35658-2017三大标准的符合性检测及符合性企业资质审查，并接入到全
国营运车辆联网联控系统。其技术要求与世界接轨，可以实现跨地区、跨国界的物流信息无缝对接，**了物流行业的信息化的方向，开启了行业标准化的新篇章。
“部标”作为行业的**标准，对各项指标有着较高的要求，要想通过“部标”，绝非易事。标准一出，全国数千家运营商纷纷“应考”，但通过认证的了了无几。 国家交通通信信息中心对系统平
台进行五个阶段的符合性检测和企业符合性资质审查，对送检企业的系统平台及GPS硬件设备进行严格检测测试，确保平台达到功能完备、高安全性、高稳定性、高可靠性，确保部标的高标准、高技术
、高规范。
良好GPS EDI技术：
良好GPS EDI技术，覆盖车辆整个运输业务过程的精细化管理，实现物流运输的智能化，且具备强大的兼容性、扩展性。
三级安全保护：
利用先进的安全技术架构确保数据信息的安全，安全标装达《国家计算机信息系统安全等级保护》三级，等同银行信息系统安全级别。
**信息处理：
定制的数据库应用，具备**以上终端接入能力，实现跨平台、跨区域间交互性通信，自动将业务数据同步至数千种移动计算设备和远程办事处。
高稳定高可靠达99.99%标准：
采用国家*加密互联网电子地图，信息平台7X24小时不间断运行，达到系统可靠性较高的99.99%标准。
“部标”对企业的研发技术与实力进行了全方面的考核与检验

为什么部标平台的开发周期长？
1.首先对于交通部部标标准文档的阅读、理解和消化需要很长时间，你面对的是冷冰冰的交通部信息中心颁发的GB/T 35658-2017、808、809协议文档，面对文字的歧义，这个消化、曲解、走弯路的时
间成本，伴随在整个软件开发周期当中，一直到你进京赶考，进行部标检测，较终过检。所以这个时间是无法估计的，理解完毕，将理解的文档转化成开发团队必须要完成的功能用例，中间的误差较
大，这也是很多开发者*自信、乐观冒进的原因。
你必须需要阅读和理解的协议文档有四份：GB/T 35658-2017文档、808协议文档、809协议文档、GB19056文档。参见交通部道路运输车辆卫星定位系统部标JTT808、809、GB/T 35658-2017标准大全
2.对于标准的严酷性准备不足，正常自己公司开发一个系统，功能标准是自己的写的，差不多，八九不离十就行了。很多开发者用这种习惯开发部标平台，很多功能看似都是八九不离十，结果到较后
，结局就是通不过。在检测中心，检测人员进行检测主要是依靠检测工具和检测用例文档，特别是测试用例文档，比自己公司测试部门写的黑盒测试用例都写的细致和充分，可惜你看不到这个文档，
开发人员就像一个瞎子不断的拿着自己脑袋硬碰才找到门在那里。
3.联调难度大
考不容易开发出来一个东西，需要测试，从客户端到服务器再到gps终端这样一个双向联调测试，服务器有服务器的问题，客户端有客户端的问题，网络通讯有网络通讯的问题，合在在一起联调，就像
一群坏孩子集中在一个班里，乱成一锅粥了。由于互相影响，耽误的时间都是叠加在一起的，而不是并行开发所能解决的了得。
4.前面问题，是部标平台开发不同于常规的信息化软件开发之处，这些不同之处加大或者恶化了计划失真的问题，就是无知者无畏，*乐观、轻视、冒进、准备不足，反而更*拖延整个开发交付
的周期。我增经见过一个较激进的部标监控平台的开发计划，整个平台计划50多天完成，设计一周时间，部标808gps服务器一个月完成，web客户端20多天就要完成，809运管平台接入10多天就完成，
留给测试的时间就5天。当时我就**了。估计是**根据市场情况强加的，这简直是要人命的。项目经理很据**或自己的意志写项目计划，反正计划归计划，让写几天就写几天吧，到时间完不成，
就继续延期呗，难不成还开除不成？
5.企业在运作过程中，刻舟求剑的静态思维往往低估软件项目开发的复杂性，待到项目开发周期**出原来的乐观估计的时候，往往温水煮青蛙，原来的3个月变成6个月，6个月变成年底，年底变成过完
春节，这个时候进退两难，停止开发又难以交代，继续开发，还要继续投入成本。企业的目的并不是为了要开发一款软件产品，而是要用这款软件产品进行运营或者做某种业务，但是往往软件还没开
发完，已经元气大伤，后面的事情就不用说了，就算开发出来，十几个月都过去了，黄花菜都凉了。

部标1077视频平台标准是在2016年10月份发布的，2019年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网页架构版本的平台。
视频平台检测的主要难点是压力测试，主要的流程如下：
相对于796平台检测的压测的主要区别是：
1.gps压测相对于796多了1000台，压测结果是对比发送的和接收的是否一致，一条也不能少；
2.gps压测通过后，3000台车保持在线，但停止发送定位，开始视频200辆车压测；
3.视频压测的时候，200路的视频连接和对应的200路上级监管平台的转发连接都保持稳定后才开始统计码流；
如果不够200路，压测直接就失败了，因为没有码流统计数字，无法统计结果；
4.200路转发成功后，任意选择一路播放视频，如果有黑屏，卡顿或者无法打开播放的情况，则视为失败；
5.视频播放的时候如果声音不连续也不行，这也说明了卡顿；
6.测试卡顿使用的视频，是一个座钟秒针转动的画面，如果有卡顿，秒针走的时候也会一顿一顿，很明显能够看出来。如果有丢包或者跳帧，则秒针就会时快时慢，或者跳跃前进。
7.测试30分钟，然后统计终端发送的码流，和上级监管平台接收的码流，两者的数字相加要大于11M。视为压测通过。
8.统计结束后，截屏上传到检测系统当中，生成压测报告。
检测标准
GB/T 35658-2017协议中规定，平台车辆接入性能的要求为：监控平台需满足具有海量定位数据高并发能力；平均500条/秒，峰值1000条/秒；企业平台能支持至少10000台终端接入，支持**过10000个
动态目标的监控能力。
依据上述要求，对于企业平台的压力检测采用TCP方式进行，分为两个部分进行；动态目标压力为检测和定位数据压力检测。
如何开发高性能的部标监控平台的GPS服务器，参见：基于部标JT/T 808协议及数据格式的GPS服务器.
二、检测要求
首先进行动态目标压力检测，主要对企业平台的动态目标监控能力进行检测，检测方法为，模拟10000个车辆按照jt/t808协议，进行注册、鉴权后，发送GPS定位数据，发送数据频率为500条/秒，该部
分检测时间为1小时。
然后进行定位数据压力检测，主要对企业平台对海量定位数据的处理能力进行检测，检测方法为，模拟2000个车辆进行注册、鉴权，发送GPS定位数据。发送数据频率为1000条/秒，以达到标准中峰值
1000条/秒的性能要求。该部分检测时间为15至30分钟。考虑到检测机器的性能，将发送频率实际设置为200条/200毫秒。
四、压力检测步骤
4.1 检测软件的使用
将被测平台的IP地址以及端口正确填入更改车牌号及终端手机号信息，点击确定
软件界面输入用户名（admin）以及密码（admin），点击“登录”
在如上图的待测平台下拉列表中随意选择一个（被测平台的IP、端口信息已经在之前的步骤中写好，这里选择的检测平台不会对其存在任何影响），然后点击确定。
然后点击“开始”按钮，开始压力测试。
在测试过程中可随时在下方的日志查看当前的连接以及GPS数据发送情况。
点击“打印”可在“…\Release\Report\”目录下生成压力测试报告的EXCEL文档。请注意，在每次打印文件后，需将文件进行重命名并妥善保存，以免造成无法恢复的文件覆盖。
4.2 检测流程
考虑到检测机器的性能。
**个环节的检测分为三台机器同时运行压力检测软件，分别模拟3333辆、3333辆、3334辆，共计10000辆车对待测平台进行压力检测。设置发送数据频率为500条/秒，检测时间为1小时，需要检测链
接建立线程时间都小于10分钟。
*二个环节的检测在单台机器上进行，检测2000辆车，设置发送数据频率为1000条/秒，检测时间为15至30分钟，其中全部检测建立链接的时间小于5分钟。
其中，考虑到时间以及鉴权情况，注册、鉴权发送时间间隔为1秒。
需要注意的是，为了保证检测的发送 ，检测软件在鉴权
首先发送注销，接收到通用应答后，再发送注册请求。
4.3 抽样对比
检测接收后，对每个环节下的数据均需抽样比对，取样如下：
对上述取样进行比对，每个部分结束后均需进行（产生主动、被关闭的除外），每一对比对结果均保存截图备查。
4.4 结果判定
在检测即将结束时手动查看链接总数，若模拟车机仍未全部链接完成，判定检测平台不通过压力检测。
在检测即将结束时手动查看发送GPS数据的频率，若GPS数据发送的频率仍然不到当前部分的频率；**部分500条每秒（即每台机器167条每秒），*二部分1000条每秒，判定监控平台不通过压力检测
。
检测期间在任意机器中发现任何连接的主动、被动关闭，均应全部停止检测，等待至少两分钟后，进行*二次检测，若在检测过程中再次出现主动或关闭，随机选择一台压力检测 机器tracert指令。
当有本机返回域名访问时间小于500ms时，可直接判定检测平台不通过压力检测，保存当前检测报告，并对软件打印界面截图；否则，立即停止当前的全部压力检测，检测时间另行通知
。
五、结果判定
压力检测进行时允许送检单位不安排人员至检测现场，而采用远程配合的方式，但需在检测正式开始前至少1个工作日提交“检测声明”，否则不予安排检测。
不论现场检测与远程配合检测，均需按要求提供真实有效的检测。