车联网-Telematics测试技术及应用案例分析

发布人：李东武发布时间：2017-05-17 浏览次数:3294

【摘要】文章系统阐述了车联网（Telematics）系统测试的一般流程及主要测试方法。通过具体Telematics系统测试实例详细介绍测试过程中关键技术应用、主要测试问题及其原因分析并取得了较好的测试结果。Telematics后台信息应用服务平台为问题高发区，车载终端问题主要为本地功能无法实现，无线通信网络问题为小概率事件。另外，在测试过程及时截取并准确分析log文件可以高效定位问题根源，提高测试效率。

1.车联网Telematics概念

1.1定义

车联网是以车内网、车际网和车载移动互联网为基础，按照约定的通信协议和数据交互标准，在车-X（X：车、路、行人及互联网等）之间，进行无线通讯和信息交换，以实现智能化交通管理、智能动态信息服务和车辆智能化控制的一体化网络，是物联网技术在交通系统领域的典型应用。

图1 Telematics系统架构

车载信息终端：采集CAN网络数据及GPS数据等信息，经过处理打包，通过无线通信网络传送给后台信息服务平台。

无线通信网络：应用3G/4G、Wi- Fi等现代网络通信的技术与手段,实现车载终端与后台服务平台的信息传输。

后台信息服务平台：借助互联网技术整合第三方内容和数据并对海量信息进行融合处理,以实现车辆检测、道路救援、实时交通、网上预约等服务与应用。

2.Telematics测试技术

2.1 Telematics系统特点

• 车载信息终端集成多种通信与数据IO硬件，并提供对多种通信协议、数据处理及应用服务的支持，系统非常复杂。

• Telematics具有多设备组成性，涉及众多厂商，信息数据流转链路复杂、网络异构且涉及海量信息整合，数据挖掘、大规模数据计算。

• 实时性、可靠性要求：网络节点（车辆）具有高动态性、拓扑变化频繁，且受到的干扰因素较多包括路边建筑物、天气状况、道路交通状况等。

2.2 Telematics测试方法

Telematics系统的复杂性决定了测试过程必需从多角度、多维度对系统进行综合性测试，主要测试技术如图所示，

图2 Telematics测试方法

从系统整体实现角度出发，需要进行功能、及性能测试。其中，功能测试涵盖功能实现、需求验证、用户体验（功能合理性）；性能测试包括稳定性、可靠性、安全性、压力测试（负载）。

测试周期的不同阶段需要对系统进行单元测试、集成测试、系统测试。如：车载终端单元测试，车内网集成测试，接入系统平台进行系统化测试。

从被测对象的特性及运行状况，又可灵活采用动态测试、静态测试、白盒测试、黑盒测试等。

2.3 Telematics测试流程

测试流程遵循通用测试流程：测试需求分析、测试策略分析（用例设计）、测试环境搭建、测试执行、系统测试回归。

图3 Telematics 测试流程

测试策略分析以测试需求说明为输入，通过对功能逻辑分析、特性分析、因果分析、场景分析、优先级分析等加工输出系统测试用例。

图4 Telematics测试策略分析

3.测试案例

某合资厂某车型Telematics系统级测试，该系统采用NGTP架构，车载终端为WinCE系统与车身BodyCAN链接并集成GPS通讯模块；无线通讯modem通过嵌入SIM卡接入中国联通3G网络，后台服务平台为Microsoft 云计算平台，并接入第三方服务机构如E-call。整个系统采用松耦合设计，可扩展性比较高。

3.1系统介绍

1、系统结构

图5 Telematics测试案例系统架构

2、功能图

图6 测试案例系统功能

3.2、测试策略分析、测试用例设计

测试策略分析以测试需求说明为输入，通过对功能逻辑分析、特性分析、因果分析、场景分析、优先级分析等加工输出系统测试用例。

输入文档主要包含系统方案，功能定义文档，CAN网络结构文档，通信矩阵，信号DBC，各种测试所需数据，应用服务类型定义等。

1、系统数据流转图

图7 系统数据流转图

数据流转主要分为车内网（CAN）数据流转与车际网数据流转。车际网数据

基于NGTP协议，以请求（request）—响应（response）服务的形式与server进行交互传输。

2、策略、特性分析

Telematics功能实现依赖于数据的可靠性传输，不同的功能服务对应不同的数据链路。为此，按数据在系统中流转的方向不同我们将测试分为如下三部分：

1）单向上行服务测试：主要为本地CAN网络数据的采集打包上传server以便对车辆状况进行统计分析。

2）单向下行服务测试：主要为server推送至车载终端的信息服务。如：保养预约提醒、车辆健康度结果、驾驶安全性经济性指数、天气信息等。

3）双向request-response服务测试：由终端发起请求，server根据请求信息到数据库调用相关数据必要时进入第三方平台调取数据并对数据进行加工处理，最后反馈给终端结果信息。

3、测试形式

考虑Telematics测试复杂性，兼顾测试效率采用静态测试与动态测试相结合的方式。测试周期各阶段包含终端单元测试、CAN网络集成、终端与server集成测试，实车系统测试。

• 静态测试主要为台架测试：通过CANoe工具模拟CAN网络，主要实现终端本地功能、车内网控制器间交叉、车辆数据相关功能、及极端状况下测试如E-call测试。

• 动态道路实车测试主要实现基于位置（GPS）的信息服务如实时交通、智能停车；不同路况下的无线通信及系统功能可靠性、稳定性、时效性测试；以及对时效性较高的互联网服务进行现场验证。

4、测试工具

1）CANoe：用于采集CAN网络车辆数据。

2）终端log分析工具：分析request、response包内数据。

3）3Gmodel解析工具：实时监控3G连接及服务数据的传输状态。

4）web服务推送工具：用于集成测试阶段模拟server推送服务信息。

5、测试用例示例

测试用例需明确：前提条件、测试步骤、期望结果、实际结果、测试状态。

图8 测试用例开发

3.3测试环境搭建

测试环境主要分为两部分：实验室台架测试见图6、道路实车路试见图7。

实验室台架测试环境：BCM与IC为真实控制器，其余（含PTCAN）控制器为CANoe模拟，车载终端与IC由privateCAN连接，车载终端外接GPS天线与3Gmodel。

道路实车测试携带独立导航仪、GPS定位仪、联通3G手机等辅助设备对实时行车信息进行验证。

图9 Telematics台架测试实施图10 Telematics实车道路测试实施

3.4测试实施

测试实施阶段主要工作如下：执行测试用例、详细记录测试结果及bug列表、截取log文件、借助测试工具及log文件对问题原因分析及定位、缺陷跟踪。

测试结果分析与评价工作中的重点是问题定位，明确的问题定位有利于高效的问题解决。因为Telematics功能的实现依赖于数据流转多个环节，测试问题的原因究竟归于哪个环节的判定尤为重要，这也是Telematics测试的难点，故在测试过程中对log的有效准确分析非常必要。

问题Log分析举例：

1）问题描述：**餐厅预订失败。

2）NGTP协议Log文件：

图11 原始log

3）log解析：

解析后的数据描述代码：

图12 解析后的log

红色标注内容经过解码后为：‘当前预订失败’，即server餐饮预订服务没有成功，问题出在远程应用服务程序。

3.5系统回归测试

回归测试工作的主要内容如下：

• 历史复测问题；

• 记录复测问题状态及信息

• 确认问题关闭与重开；

3.6测试结果及评价

本地终端常见问题为功能实现错误，重启、死机，车载数据上传失败等占比约18%，发生频率中等。

网络通信类问题如：GPS无信号、通信网络无信号、网络超时严重、数据丢失、信号差等约占10%属低频问题，常见的原因有：a、路况原因（如：建筑物遮挡）b、通信模块性能（如：长时间工作后10h以上性能下降）c、通信网络覆盖盲区（山区）、信号漫游临界区域（城市边界）。

应用服务类问题：实时交通、智能停车信息与实际不符，酒店、餐饮预订失败，信息服务如天气信息无法获取，驾驶数据或第三方数据偏差严重，网络超时等，占比63%为高频问题。可能的原因比较多，如应用服务功能本身无法实现，第三方数据整合丢失，数据融合或算法错误，系统性能低，服务数据分发错误，网络原因等。此类问题一般涉及多节点、流转复杂，且原因排查比较困难，这也同样为系统集成及测试提出了更高要求。

车载CAN网络内交叉功能，接口和功能合理性、用户体验度等问题分别为占比为6%与3%属小概率事件。

图13 测试案例问题分布图

4 总结及展望

本文结合具体测试案例系统分析了车联网的测试技术、方法，并在实际测试中取得了较满意的测试结果。车联网测试问题原因分析及定位比较困难，及时记录并分析各环节log文件会大大提高测试效率。测试问题高发于信息服务功能、阶段上处在数据融合及流转环节，一方面印证了车联网技术复杂、网络异构、融合多方参与的特点；另一方面，也对车联网架构及通信协议向统一化、标准化方向发展有一定促进意义。

车联网的海量信息及数据流转复杂等特点预示着自动化测试技术也是未来车联网测试技术的一个发展方向。

本文来源：恒润科技，http://www.hirain.com/sts/142/530