揭阳交通部1076认证

交通部：

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

规范所称道路运输车辆卫星定位系统标准规范主要包括《道路运输车辆卫星定位系统车载终端技术要求》（JT/T 794）、《道路运输车辆卫星定位系统平台技术要求》（JT/T 796）、《道路运输车辆卫星定位系统终端通讯协议及数据格式》（JT/T 808）、《道路运输车辆卫星定位系统平台数据交换》（JT/T 809）、《机动车运行安全技术条件》（GB7258）、《汽车行驶记录仪》（GB/T 19056）以及相关技术规范。（其中交通部检测中心进行的检测为JT/T 794和JT/T 808两项标准的检测，而GB/T 19056属于CCC认证的检测标准）

企业确保产品满足交通部所要求的标准，且有对应的检测报告及认证证书，即可凭相关资料，向交通部符合性审查办公室进行符合性技术审查，审查通过后，对通过标准符合性技术审查的产品公告（即厂家可满足各省市交通部门针对此类产品的招标认证要求）。

由于交通部部标平台过检的标准信息相对不是很透明，大家对794标准和jt/t 808 协议、jt/t809协议都是通过文档的字面意思各自去理解的，误差难免，误差大的，到北京过检的时候，就要耽误的时间长，过的就非常不顺，花费的差旅费和检测费就很大，得不偿失。很多去过检的企业都不是北京公司，在北京检测要背负额外的时间成本和费用成本，所以要追求较高的成功率，不然遇到问题，要面临两难选择，要么回来，改完了再坐一趟飞机去检测，要么呆在酒店里，改完了，重新预约下次检测时间，一直到过了为止。过完检的人都会感慨良多，不过不知道，过了感觉里面全是大坑，仅靠理解简单的功能列表是不行的，差的太远。

为什么去检测的企业非常不顺呢？

这是由于打铁需要自身硬，去过检的企业有很大一部分都是自己，本身就一堆毛病，没有给大量用户用过，也没有经过时间的考验。内部测试是不可能代替用户各种长时间使用的。由于按照部标协议完整开发的GPS软件平台开发周期都是在一年多以上（为什么大家愿意自己开发，就是因为不相信会花费这么长时间，开发完回头一看二年都过去了），已经耗尽了**的耐心，按照计划，早该去过检测了，成为一个通过认证的部标平台是一个商务性质的，是需要配合市场竞争要求的，不可能在那里像温水煮青蛙一样慢慢搞的，所以很多平台都是迫于时间压力，仓促迎战。

如何才能快速的过检呢，很多事情都是前车之鉴，部标2011年推出，到现在已经四年，翻一翻部标过检名单，已经过了几千余家，别人已经走过的弯路，你还在那里用人民币铺路，使蛮劲吭哧吭哧的走，是不是有点滑稽，缺乏智慧。过检完全是一个经验主义的事情，你的能力再大，也不可能在一年内开发出一个部标平台并过检，前面有没有坑，和你的能力智商及公司团队的实力一毛钱关系都没有，要花时间和精力走过去才知道。如果能够给过检的企业提供专业全面的指导，从部标808和809协议测试、部标796功能测试、运行测试和压力测试，各个环节，在过检前，就填掉大坑，到北京再去过检测，就是直通车了，避免头撞南墙起大包后再修改，无疑是较大的提高检测效率，节省一大笔支出。

选择跟我们合作可以大幅降低成本，因为检测的功能、时间都是可以确定的，要是企业自己去申请时间就不好说了，成本就更难以控制。

我们给企业客户提供的服务：

1.检测指导服务，用较少的时间完成检测出具报告

2.企业只需要提供样品测试，提供相关技术资料，不需指派相关技术人员到北京配合现场测试。

3.我们在实验室全程配合实验室现场测试，实现全包服务。

开发企业级的部标GPS监控平台，投入的开发力量很大，开发周期也很长，选择主流的开发语言以及成熟的开源技术框架来构建基础平台，是较恰当不过的事情，在设计之初就避免掉了技术选型的风险，避免以后在开发过程中，不断的填坑走弯路，以至于整个团队被坑埋掉。做GPS平台这么多年，以前就了解到一些开发团队过于关注某一种语言的优势，比如过于选用GO，Erlang，python,php等技术，较后团队熟悉这些技术的关键人员离职了，都没人接手，不能不说是个悲剧。所以说平台的技术架构选型要注重的是稳健，均衡而不是偏激，而SpringMVC4, Mybatis4, Hibernate4就是GPS监控平台软件开发的理想框架选择。

基于交通部796标准开发部标监控平台，选择开发语言和技术也是团队要思考的因素，其实这由团队自己擅长的技术来决定，如果擅长C#和, 当然开发效率就高很多。当然了技术选型一定要选用当前主流的技术，现在技术已经发展到5.0, 如果你还是用旧的ASP技术写程序，无疑是为以后的项目维护埋下地雷，后面新来人手学习不到技术，没有兴趣去改进，不愿意维护，没有人愿意接手。代码较关键的是要不断的重构，保持与当前的技术和需求同步，平台才有生命力，否则就会越来越臃肿而变得难以维护。开发一个基于 MVC和C#语言的部标平台，主要应用的技术如下：1）服务器通信技术：因为C#中，基于.NET4.0的异步通信框架，还是非常不错的。不过编程模式也是比较复杂的，不像Java的NIO框架Mina和Netty那样方便省力,但是一样可以开发出高性能的jt808GPS服务器和jt809服务器。2）分布式服务：对于高性能的平台，服务一定是要求分布式部署和调用的，以应对压力，比如jt808GPS服务器、存储转发缓存服务器和web服务器，都是部署在不同机子上面，对于远程服务调用

使用Java语言开发一个高质量和高性能的jt808 协议的GPS通信服务器，并不是一件简单*的事情，开发出来一段程序和能够承受数十万台车载接入是两码事，除去开发部标808协议的固有复杂性和几个月长周期的协议Bug调试，作为大批量794车载终端接入的服务端，需要能够处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理等。如果没有足够的网络编程经验积累和深入了解部标808协议文档，自研的GPS服务器往往需要半年甚至数年的时间才能较终稳定下来，这种成本即便对一个大公司而言也是个严重的挑战。