智能车载终端检测报告怎么办理

道路运输车辆卫星定位系统
终端通讯协议及数据格式
1 范围
本规范规定了道路运输车辆卫星定位系统北斗兼容车载终端(以下简称终端)与监管/监
控平台（以下简称平台）之间的通讯协议与数据格式，包括协议基础、通信连接、消息处理、
协议分类与说明及数据格式。
本规范适用于道路运输车辆卫星定位系统北斗兼容车载终端和平台之间的通信。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本
适用于本文件。凡是不注日期的引用文件，其新版本（包括所有的修改单）适用于本文件。
GB/T 2260 中华人民共和国行政区划代码
GB/T 19056 汽车行驶记录仪
JT/T 415-2006 道路运输电子政务平台 编目编码规则
JT/T 794 道路运输车辆卫星定位系统 车载终端技术要求 
集成测试是为了构建一个更大的系统或平台，这个系统的几个部分通常是由不同的团队或甚至不同的公司开发的，以前在做信息化的软件开发时，面临的集成测试通常是不同软件子系统之间的集成测试，往往被这一阶段的测试搞得人仰马翻的，在从事了四年的视频监控和GPS软件开发之后，才知道，软硬件系统之间的集成测试更加折磨人的脆弱的神经。两者本质上都是一样，软硬件系统集成实际上是嵌入式软件系统和常规的PC软件系统直接的集成。集成测试常常成为压垮复杂项目的后一根稻草。主要存在的问题如下：


1.嵌入式软件开发团队和常规的软件开发团队，风格差别很大，从开发语言和技术，到思考处理问题的方式都有很大区别。从一开始，如何保证两个团队之间的充分沟通并相互信任是个问题，团队之间互相推诿，不担当的情况常常发生；


2.系统集成必然基于同一个约定，如软件接口，通信协议或规约，如果是次的合作开发，那么如何制定并保证接口和通信规约的稳定性，这个其实很难除非是我们都遵循成熟的国家标准或通用行业标准，如GPS通信协议JT/T808标准，否则研发初始自制的API和协议都是简单甚至是弱智的，随着软件开发的深入，对于功能和需求理解的越来越透彻，接口和协议不断的膨胀和变化，这种变化是那个团队发起的，如何和另一个团队进行协商，对于一个团队是否可行，在嵌入式系统上增加一个功能和在后端平台上增加一个功能所面临的的难度是一个天上一个地下，如何及时的固化到文档中去，如何制定一个合理有效的协商机制，都是在项目初始要确定下来的。


3.两个团队往往是并行开发，因为同属于一个大系统，有一个共同的项目计划和进度，大家在竭力完成自己的任务的时候，往往顾不得那边的情况，在节点汇合的时候，大家都声称自己完成了计划上的任务，开始测试了，实际情况是大家根本没有准备好，各自的单元测试和功能测试，进行的非常不充分，而留给双方共同的集成测试时间又非常的乐观。没有充分测试过的子系统在进行集成测试的时候，必然会暴露大量的问题，这显得集成测试很必要，这些问题暴露的有点晚了，再返工修改，Rework的工作量很大，进度更加吃紧，有些问题本来可以避免掉，无须拿到成本昂贵的集成测试上进行。


4.集成测试并不意味着测试更充分或者覆盖面加大，我们拿到一个硬件系统，并不能像软件一样可以随心所欲的制造出一个有效用例来并且进行大量重复使用，例如要测试一个GPS软件的超速报警的功能，那测试用例设计时，必须要创造出一个车辆超速的动作环境，并触发终端报警上传到软件平台，这样一个用例还需要能够供测试人员反复调用。其他还有很多复杂的测试，如视频监控功能等测试。


5.压力不够。由于测试环境的搭建，都是基本单一的软硬件对测，再加上硬件测试环境搭建的成本和复杂性，难以模拟出真实大规模业务并发的环境，造成压力测试不够，很多都是测试人员骗领导，走走过场，真实的问题往往后在上线后，接入大规模业务时出现。