CN110517084A - 车辆功能活跃度分析方法及系统 - Google Patents

Abstract

本发明的目的是提供一种汽车功能活跃度的分析方法及系统，包括原始数据采集、数据处理、数据分析及数据可视化，其利用现有的数据采集硬件，在不增加成本和人力的情况下，终端监听CAN总线数据，上传整车功能信号，后台接收和存储数据，经过数据运算，得到汽车功能的使用频次和时长，从而得出功能活跃度。本发明具备数据实时性和全样本量，可以反映实际用户的功能活跃情况，形成多种维度的分析，满足产品和运营人员的需求。

Description

车辆功能活跃度分析方法及系统

技术领域

本发明涉及车辆功能活跃度的分析技术。

背景技术

近年来，在整车厂从传统的造车企业转型成为服务型企业的过程中，数据的重要性越发凸显。车辆搭载的功能越来越多，用户面对如此繁杂的功能可能无所适从，整车厂为了搭载这些亮点功能也投入了大量的研发成本。但最终用户对这些功能的评价如何，使用是否如预期一样频繁，用户是否真正需要这些功能，是值得深入研究，以提升汽车的功能设计。目前整车厂大多采用线下调研的方式获取评价数据，这种方式存在样本量小、普适性差、费用高昂等缺点。

现有终端APP的数据分析理论非常成熟，产品和运营人员可通过数据埋点进行功能的活跃情况分析，发现用户喜爱的功能，挖掘用户喜爱功能背后的原因以及各功能是否存在潜在的关联性，指导产品设计和研发。

目前，整车厂面对整车CAN总线，已摸索出一套基于CAN总线庞大的数据分析整车功能活跃度的方法，利用实际用户的行为数据分析替代传统的用户调研，降低成本，极大的扩大了样本量，且保障了数据的真实性。

但是，现在基于CAN总线庞大的数据分析整车功能活跃度的方法，大都是采用本地存储、线下拷贝的离线方式传输数据，数据不具备实时性，样本量仍受到存储、拷贝能力的制约。

因此，如何实时、动态地掌握用户对车辆功能的需求和活跃情况，为用户提供更贴近需求的服务和功能，为整车厂从众多的功能中找出亮点与糟点功能，成为了整车厂在发展中需要面对的问题。

发明内容

本发明的目的是提供一种汽车功能活跃度的分析方法，其整车功能信号数据是由汽车CAN总线主动实时上传，后台接收和存储数据，经过数据运算，得到汽车功能的使用频次和时长，从而得出功能活跃度，具备数据实时性和全样本量，能帮助形成多种维度的分析结果，满足产品和运营人员的需求。

本发明的技术方案如下：

一种汽车功能活跃度的分析方法，其步骤如下：

步骤1、原始数据采集

原始数据源来自整车总线，由车端进行数据主动上报，其中数据包含信号名、信号状态、时间戳等；将原始数据定时同步到私有云的HDFS中，原始数据格式均为json。

步骤2、数据处理

原始数据落地到数据仓库之后，按每天一个分区映射成数据集（hive）表，供后续离线分析。

步骤3、数据分析

依据业务需求，对不同的指标进行次数和时长统计，每个指标都需要经过以下处理：将该指标的信号进行状态标记；将连续状态合并，保留状态的开始时间和结束时间；每天计算一次指标的使用次数和时长，形成结果。

4、数据可视化。

具体地，在所述步骤1中，获取数据方式是由Tbox对车辆信号进行监听，当监听到车辆信号状态发生变化时，Tbox采集信号并存储到本地，并周期性上传到云端，即车辆功能活跃度的原始数据会定时同步到私有云的HDFS中，原始数据格式均为json。

具体地，在所述步骤2中，每日的数据中存在当日数据和补发数据，云端获取到数据后，以服务器时间为准存储在每个分区，用sql程序处理分发补发数据到相应分区，并激活spark计算程序更新相应日期的计算结果。

具体地，所述步骤3数据分析具体包括：

3.1、在 spark 程序里面通过 hiveSql 关联各原始数据集（hive）表，并解析成一张宽表；宽表包含车型 seriescode、 VIN、时间戳 timestamp、报文数据 candata 形式的多条数据。即是通过 hiveSql 将一条原始数据格式化为车型 seriescode、 VIN、时间戳timestamp、报文数据 candata 形式的多条数据。

3.2、读取辅助表DW.dim_active_measure数据

将步骤3.1的多条数据进行状态切分，字段 state 关联指标切分状态，当 measure_type 为 1 或 3 表示次数统计，为 2 表示时长统计，通过 state 和 measure_type 可以得到唯一 measure_id。

3.3、整车功能信号消息分组

读取原始数据后，通过 vin 分组，并按整车功能信号消息发送的先后顺序排序。

进一步，所述步骤4数据可视化要区分手动触发和自动触发功能，对于手动触发功能，分析该功能是否有用户使用，从功能易用性、用户满意度等方面对低使用率功能进行分析，提高用户满意度；对于自动触发功能，分析该功能的使用频次，得到可靠性数据，反映该功能的耐久试验计划的合理范围；

所述可靠性数据包括：

功能活跃总次数：结合销量和搭载数据，反映功能的总体情况；

功能平均单车频次：排除销量和搭载的影响，反映功能的单车情况；

功能使用车辆总数：反映用户对功能的依赖程度；

功能使用趋势（日、周、月）：反映功能活跃的变化趋势；

功能客户年龄段分布：反映功能的用户年龄层次占比；

功能使用地区分布：反映功能的地域情况区别。

以上方法，利用现有的数据采集硬件，在不增加成本和人力的情况下，终端监听CAN总线数据，上传整车功能信号，后台接收和存储数据，经过数据运算，得到汽车功能的使用频次和时长，从而得出功能活跃度。

本发明进一步还提供一种汽车功能活跃度的分析系统，其包括：

采集模块：用于对原始数据进行采集，原始数据源来自整车总线，通过4G Tbox模块进行数据主动上报，其中数据包含信号名、信号状态、时间戳等；将原始数据定时同步到私有云的HDFS中，原始数据格式均为json；

数据处理模块：用于在原始数据落地到数据仓库之后，按每天一个分区映射成数据集（hive）表，供后续离线分析；

数据分析模块：用于依据业务需求，对不同的整车功能进行次数和时长统计，每个功能都需要经过以下处理步骤：将该指标的信号进行状态标记；将连续状态合并，保留状态的开始时间和结束时间；每天计算一次指标的使用次数和时长，形成结果；

数据可视化模块，用于各车辆功能的使用指标以可视化的形式展现出来，供公司产品和研发的数据分析，从各个维度对功能的使用情况和人群分布进行解读，指导产品设计和战略方向。

进一步，所述数据分析模块具体包括：

数据解析单元：在 spark 程序里面通过 hiveSql 关联各原始数据集（hive）表，并解析成一张宽表；宽表包含车型 seriescode、 VIN、时间戳 timestamp、报文数据 candata形式的多条数据。

读取辅助表数据单元：将数据解析单元的多条数据进行状态切分，字段 state 关联指标切分状态，当 measure_type 为 1 或 3 表示次数统计，为 2 表示时长统计，通过state 和 measure_type 可以得到唯一 measure_id。

整车功能信号消息分组单元：将读取的数据通过 vin 分组，并按整车功能信号消息发送的先后顺序排序。

本发明的优点如下：

1、本发明的数据是车端主动上报数据，即数据源来自整车总线，并实时上报，通过此数据可以反映实际用户的功能活跃情况，并对该数据进行加工处理，形成多种维度的分析，满足产品和运营人员的需求。

2、本发明的数据源来自整车总线，不同于对移动终端的功能活跃度采集，该数据经传整车、4G模块、后台，需在多轮数据传输同时保障数据实时性。本发明数据全程通过整车设备上传，上传周期可配置，可实现从终端设备信号产生到服务器端接收时长不超过1s，可保证数据的实时性和完整性。

3、本发明的方法简单，可靠可行，没有额外增加成本，利用现有的硬件设备，采集搭载Tbox的全量用户真实的行为数据，减少了获得调研结果的等待周期。

附图说明

图1为本发明的逻辑流程图；

图2为数据分析过程中的状态标记结果；

图3为数据分析过程中的状态合并结果；

图4为数据分析过程中的单车结果表；

图5为数据可视化的功能活跃总次数；

图6为数据可视化的功能平均单车频次；

图7为数据可视化的功能使用车辆总数；

图8为数据可视化的功能使用趋势 ；

图9为数据可视化的功能客户年龄段分布；

图10为数据可视化的功能使用地区分布。

具体实施方式

下面结合附图对本发明进行进一步的描述：

参见图1，本发明主要通过采集、处理、分析及可视化四个步骤共同协作完成汽车功能活跃度的分析：

一、原始数据采集，原始数据上传到hive：通过4G Tbox对车辆功能信号进行监听，当车辆功能信号满足条件时 ，Tbox采集信号并存储到本地，每10s上传到云端。

二、数据处理，通过hiveSql将原始数据格式化：每日的数据中存在当日数据和补发数据，云端获取到数据后，以服务器时间为准存储在每个分区，用sql程序处理分发补发数据到相应分区，并激活spark计算程序更新相应日期的计算结果。

对于异常数据的处理：

1、终端时间异常(时间超过当日服务器日期)

如果一条数据的终端时间为未来的时间， 这条数据不会被分发，还是保存在当前分区。 在每天的计算任务中， spark 会排除这些数据，只筛选当日数据进行计算。通过这种方式，既可以保证当日结果不会受到终端时间异常数据的影响，还能保存异常数据的原始数据，为后期异常数据排查留下证据。

2、canData 数据重复

这部分脏数据主要以在同一时间、同一辆车存在两条 canData 数据完全相同的形式存在。针对这部分数据，在 spark 调用 hiveSql 时进行去重处理。

3、 data 数组对象为 null、长度为 0：

针对部分上报数据中功能使用数据未上报的情况，这部分数据在 spark 计算过程中将被过滤掉，不参与最终结果的计算。

三、分析： 依据业务需求，对不同的整车功能进行次数和时长统计，每个功能都需要经过以下处理：将该指标的信号进行状态标记；将连续状态合并，保留状态的开始时间和结束时间；每天计算一次功能的使用次数和时长，形成结果。

1、在 spark 程序里面通过 hiveSql 读 ODS.log_data_uaes 表原始数据，并解析成一张宽表。

具体是通过 hiveSql 将一条原始数据格式化为车型 seriescode、 VIN、时间戳timestamp、报文数据 candata 形式的多条数据。

2、读取辅助表 DW.dim_active_measure 数据

该表用于将统计结果集映射到事时表,字段 state 关联指标切分状态，当 measure_type 为 1 或 3 表示次数统计，为 2 表示时长统计。通过 state 和 measure_type 可以得到唯一 measure_id。

3、消息分组

读取原始数据后，通过 vin 分组，并按消息发送的先后顺序排序。

以下通过具体指标-等离子发生器的活跃度来说明步骤三的分析统计方法：

指标：等离子发生器状态（仅支持自动空调） AC_PlasmaSt，使用次数： AC_PlasmaSt从 0x0 跳变到 0x1 的次数； 时长： AC_PlasmaSt 信号从激活（0x1）到非激活（0x0），为一次使用周期。

步骤：

（1）标记状态

等离子发生器状态（仅支持自动空调） AC_PlasmaSt 信号为 0x0，标记状态为 a1,信号为 0x2 时，标记状态为 a2。当信号由 0 跳变到 1 时， 表示开启一次；信号由 1 跳变到 0 时，为一次使用周期。

加载分组排序后的数据，解析每一条消息，首先对指标 AC_PlasmaSt 进行状态划分，当字段AC_PlasmaSt==0 时，将变量 state 设为 a1；如果 AC_PlasmaSt==2 时，将变量state 设为 a2。当解析所有消息后生成该指标的数组集合。如图2。

(2)状态切分

相同连续状态合并，如图3所示，开始状态 state=a1时,startTime=1544406765867，对数据集合循环遍历， 当 state=a2 时,设置 endTime=15444406785867。并生成一条切分记录： startTime=1544406765867,endTime=15444406785867,state=a1。依此类推，至到集合 length-1 条记录为止，同时如果 length-1 记录的 state 和上一帧数据的 state 相同，并且该状态用于统计次数，认为该片段无效。如果该状态用于统计时长，保留该片段。

（3）次数、时长统计

次数： state=a1 时，表示信号由 0 跳变到 1，那么切分后有几条 state=a1 的记录，我们就认为使用了几次。

时长： state=a2 时，表示信号由 1 跳变到 0， 那么每条记录的 endTime-startTime就表示这次开启的使用时长,将每天所有 state=a2 的记录（endTime-startTime）求和，统计出该设备今天总的使用时长。

（4）结果关联，生成结果集

关联辅助表 DW.dim_active_measure 属性 state, measure_type(1,3->表示次数，2 表示->时长)和图3统计表 state,找到属性 measure_id，生成统计结果数据。假设状态a1,次数统计关联 measure_id 为 1001，状态 a2， 时长统计关联 measure_id 为 1002，如图4所示。

四、 数据可视化

对于手动触发功能，分析该功能是否有用户使用，从功能易用性、用户满意度等方面对低使用率功能进行分析，提高用户满意度；对于自动触发功能，分析该功能的使用频次，得到可靠性数据，反映该功能的耐久试验计划的合理范围。

图5-图10就显示了汽车各功能的各种指标可视化数据，例如：

功能活跃总次数，如图5所示；

功能平均单车频次，如图6所示；

功能使用车辆总数，如图7所示；

功能使用趋势（日、周、月），如图8所示；

功能客户年龄段分布，如图9所示；

功能使用地区分布，如图10。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令和相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种汽车功能活跃度的分析方法，其特征在于，包括步骤如下：

（1）原始数据采集

原始数据源来自整车总线，由车端进行数据主动上报，其中数据包含信号名、信号状态、时间戳车辆运行所有数据；将原始数据定时同步到私有云的HDFS中，原始数据格式均为json；

（2）数据处理

原始数据落地到数据仓库之后，按每天一个分区映射成数据集表，供后续离线分析；

（3）数据分析

依据业务需求，对不同的整车功能进行次数和时长统计，每个功能都需要经过以下处理：将该指标的信号进行状态标记；将连续状态合并，保留状态的开始时间和结束时间；每天计算一次功能的使用次数和时长，形成结果；

（4）数据可视化。

2.根据权利要求1所述的汽车功能活跃度的分析方法，其特征在于，所述步骤（1）中，获取数据方式是由Tbox模块对车辆信号进行监听，当监听到车辆信号状态发生变化时，Tbox采集信号并存储到本地，并周期性上传到云端。

3.根据权利要求2所述的汽车功能活跃度的分析方法，其特征在于，所述步骤（2）中，每天的数据中存在当日数据和补发数据，云端获取到数据后，以服务器时间为准存储在每个分区，用sql程序处理分发补发数据到相应分区，并激活spark计算程序更新相应日期的计算结果。

4.根据权利要求3所述的汽车功能活跃度的分析方法，其特征在于，所述步骤（2）还包括对异常数据的处理，具体包括：

对时间超过当日服务器日期的终端时间异常数据的处理：如果一条数据的终端时间为未来的时间， 则这条数据不被分发，保存在当前分区，在每天的计算任务中， spark 会排除这些数据，只筛选当日数据进行计算；

对canData 数据重复的处理：若在同一时间、同一辆车存在两条 canData 数据完全相同，则为脏数据，在 spark 调用 hiveSql 时进行去重处理；

对data 数组对象为 null、长度为 0的数据，在 spark 计算过程中将会被过滤掉，不参与最终结果的计算。

5.根据权利要求1-4之任一项所述的汽车功能活跃度的分析方法，其特征在于，所述步骤（3）数据分析具体包括：

（3.1）在 spark 程序里面通过 hiveSql关联各原始数据集（hive）表，并解析成一张宽表；宽表包含车型 seriescode、 VIN、时间戳 timestamp、报文数据 candata形式的多条数据；

（3.2）读取辅助表数据

将步骤（3.1）的多条数据进行状态切分，字段 state 关联指标切分状态，当 measure_type 为 1 或 3 表示次数统计，为 2 表示时长统计，通过 state 和 measure_type 可以得到唯一 measure_id；

（3.3）整车功能信号消息分组

读取原始数据后，通过 vin 分组，并按整车功能信号消息发送的先后顺序排序。

6.根据权利要求1所述的汽车功能活跃度的分析方法，其特征在于，所述步骤（4）数据可视化具体包括：

区分手动触发和自动触发功能，对于手动触发功能，分析该功能是否有用户使用，从功能易用性、用户满意度等方面对低使用率功能进行分析，提高用户满意度；对于自动触发功能，分析该功能的使用频次，得到可靠性数据，反映该功能的耐久试验计划的合理范围；

所述可靠性数据包括：功能活跃总次数、功能平均单车频次、功能使用车辆总数、功能使用趋势（日、周、月）、功能客户年龄段分布、功能使用地区分布。

7.一种汽车功能活跃度的分析系统，其特征在于，包括：

采集模块：用于对原始数据进行采集，原始数据源来自整车总线，通过Tbox模块进行数据主动上报，其中数据包含信号名、信号状态、时间戳等；将原始数据定时同步到私有云的HDFS中，原始数据格式均为json；

数据处理模块：用于在原始数据落地到数据仓库之后，按每天一个分区映射成数据集（hive）表，供后续离线分析；

数据分析模块：用于依据业务需求，对不同的整车功能进行次数和时长统计，每个功能都需要经过以下处理步骤：将该指标的信号进行状态标记；将连续状态合并，保留状态的开始时间和结束时间；每天计算一次指标的使用次数和时长，形成结果；

数据可视化模块，用于各车辆功能的使用指标以可视化的形式展现出来。

8.根据权利要求7所述的汽车功能活跃度的分析系统，其特征在于，包括：所述数据分析模块具体包括：

数据解析单元：在 spark 程序里面通过 hiveSql关联各原始数据集（hive）表，并解析成一张宽表；宽表包含车型 seriescode、 VIN、时间戳 timestamp、报文数据 candata形式的多条数据；

读取辅助表数据单元：将数据解析单元的多条数据进行状态切分，字段 state 关联指标切分状态，当 measure_type 为 1 或 3 表示次数统计，为 2 表示时长统计，通过state 和 measure_type 可以得到唯一 measure_id；

整车功能信号消息分组单元：将读取的数据通过 vin 分组，并按整车功能信号消息发送的先后顺序排序。