CN111723135A - 一种车辆配置特征请求的处理方法及装置 - Google Patents

Abstract

本申请公开了一种车辆配置特征请求的处理方法及装置。对于同一车辆公司旗下每个子公司对应的配置特征库进行合并，获得该车辆公司的总特征库，即实现对所有车辆配置特征的统筹管控。当每个所述子公司或每个所述子公司下各个车辆配置项目发送配置特征请求时，利用车辆公司的总特征库处理配置特征请求。由于车辆公司的所有车辆配置特征均是汇集到总特征库统筹管控的，因此，面对配置特征请求时，能够较迅速地在所有子公司以及车辆配置项目中定位相关的配置特征，实现配置特征的准确追踪，并节约了追踪时间。可见，本申请能够避免处理车辆配置特征请求时的混乱，实现配置特征请求的高效处理。

Description

一种车辆配置特征请求的处理方法及装置

技术领域

本申请涉及车辆工程技术领域，特别是涉及一种车辆配置特征请求的处理方法及装置。

背景技术

目前，很多车辆公司的子公司开展车辆相关项目时，项目中涉及的车辆配置由项目内部独立管控，车辆配置的特征信息互不流通。然而在实际应用中，同一配置特征在不同项目或不同子公司内的名称可能存在差异，从而导致配置数据管理出现混乱。例如，当发现某一项目中配置特征A存在问题时，由于配置特征A在该子公司的其他项目中名称为配置特征A’，在总公司的其他子公司中名称为配置特征B，导致无法准确追踪到同一存在问题的配置特征。

可见，当前车辆配置数据独立管控，导致配置特征的准确性与可追踪性极差，处理车辆配置特征请求时容易发生混乱。

发明内容

基于上述问题，本申请提供了一种车辆配置特征请求的处理方法及装置，以实现对配置特征的准确追踪，解决处理车辆配置特征请求时发生混乱的问题。

本申请实施例公开了如下技术方案：

本申请第一方面，提供一种车辆配置特征请求的处理方法，包括：

获取同一车辆公司旗下每个子公司对应的配置特征库；

将每个所述子公司对应的配置特征库合并为总特征库；

利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求。

可选地，所述获取同一车辆公司旗下每个子公司对应的配置特征库，具体包括：

判断每个所述子公司是否具备对应的配置特征库，如果是，则获取所述子公司对应的配置特征库；如果否，则获取所述子公司下各个车辆配置项目使用的所有车辆配置，根据所述所有车辆配置建立所述子公司对应的配置特征库。

可选地，所述将每个所述子公司对应的配置特征库合并为总特征库，具体包括：

获取每个所述子公司对应的配置特征库中各项配置特征的描述和编码；

利用所述描述和/或所述编码，确定不同所述子公司对应的配置特征库中相互重叠的配置特征；所述相互重叠的配置特征具有唯一的所述编码；

对于每个所述子公司对应的配置特征库中各项配置特征取并集，获得所述总特征库，所述总特征库中各项配置特征互不重叠。

可选地，所述配置特征请求具体为配置特征新增请求，所述配置特征新增请求中携带请求新增的配置特征的关联数据；

所述利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求，具体包括：

确定所述请求新增的配置特征的关联数据符合初步校核条件；

对于每个所述子公司发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述子公司发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述子公司发送配置特征新增完成的通知；

对于每个所述子公司下各个车辆配置项目发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述车辆配置项目所属的子公司对应的配置特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述配置特征库中包含的所述请求新增的配置特征的通知；如果否，则根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述车辆配置项目所属的子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述车辆配置项目发送配置特征新增完成的通知。

可选地，所述配置特征请求具体为配置特征修改请求，所述配置特征修改请求中携带请求修改的配置特征的关联数据；

所述利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求，具体包括：

确定所述请求修改的配置特征的关联数据符合初步校核条件；

根据请求修改的配置特征的关联数据，确定所述车辆公司所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目；

向所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目，转发所述配置特征修改请求；

获取所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目反馈的消息，当所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目均同意所述配置特征修改请求时，在所述使用所述请求修改的配置特征的所述子公司对应的配置特征库以及所述总特征库中修改所述请求修改的配置特征。

可选地，所述配置特征请求具体为配置特征删除请求，所述配置特征删除请求中携带请求删除的配置特征的关联数据；

所述利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求，具体包括：

确定所述请求删除的配置特征的关联数据符合初步校核条件；

根据请求删除的配置特征的关联数据，确定所述车辆公司是否存在正在使用所述请求删除的配置特征的所述车辆配置项目；

如果否，则在所述总特征库以及所有包含所述请求删除的配置特征的配置特征库中删除所述请求删除的配置特征。

本申请第二方面，提供一种车辆配置特征请求的处理装置，包括：

配置特征库获取模块，用于获取同一车辆公司旗下每个子公司对应的配置特征库；

特征库合并模块，用于将每个所述子公司对应的配置特征库合并为总特征库；

配置特征请求处理模块，用于利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求。

可选地，所述配置特征库获取模块，具体包括：

第一判断单元，第一获取单元，第二获取单元和配置特征库建立单元；

所述第一判断单元用于判断每个所述子公司是否具备对应的配置特征库，如果是，则所述第一获取单元用于获取所述子公司对应的配置特征库；如果否，则所述第二获取单元用于获取所述子公司下各个车辆配置项目使用的所有车辆配置，所述配置特征库建立单元用于根据所述所有车辆配置建立所述子公司对应的配置特征库。

可选地，所述特征库合并模块，具体包括：

第三获取单元，第一确定单元和合并单元；

所述第三获取单元，用于获取每个所述子公司对应的配置特征库中各项配置特征的描述和编码；

所述第一确定单元，用于利用所述描述和/或所述编码，确定不同所述子公司对应的配置特征库中相互重叠的配置特征；所述相互重叠的配置特征具有唯一的所述编码；

所述合并单元，用于对于每个所述子公司对应的配置特征库中各项配置特征取并集，获得所述总特征库，所述总特征库中各项配置特征互不重叠。

可选地，所述配置特征请求具体为配置特征新增请求，所述配置特征新增请求中携带请求新增的配置特征的关联数据；

所述配置特征请求处理模块，具体包括：

第二确定单元，第一处理单元和第二处理单元；

所述第二确定单元，用于确定所述请求新增的配置特征的关联数据符合初步校核条件；

所述第一处理单元，用于对于每个所述子公司发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述子公司发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述子公司发送配置特征新增完成的通知；

所述第二处理单元，用于对于每个所述子公司下各个车辆配置项目发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述车辆配置项目所属的子公司对应的配置特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述配置特征库中包含的所述请求新增的配置特征的通知；如果否，则根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述车辆配置项目所属的子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述子公司发送配置特征新增完成的通知。

可选地，所述配置特征请求具体为配置特征修改请求，所述配置特征修改请求中携带请求修改的配置特征的关联数据；

所述配置特征请求处理模块，具体包括：

第三确定单元，第四确定单元，转发单元，第四获取单元和第三处理单元；

所述第三确定单元，用于确定所述请求修改的配置特征的关联数据符合初步校核条件；

所述第四确定单元，用于根据请求修改的配置特征的关联数据，确定所述车辆公司所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目；

转发单元，用于向所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目，转发所述配置特征修改请求；

所述第四获取单元，用于获取所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目反馈的消息；

所述第三处理单元，用于当所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目均同意所述配置特征修改请求时，在所述使用所述请求修改的配置特征的所述子公司对应的配置特征库以及所述总特征库中修改所述请求修改的配置特征。

可选地，所述配置特征请求具体为配置特征删除请求，所述配置特征删除请求中携带请求删除的配置特征的关联数据；

所述配置特征请求处理模块，具体包括：

第五确定单元，第六确定单元和第四处理单元；

所述第五确定单元，用于确定所述请求删除的配置特征的关联数据符合初步校核条件；

所述第六确定单元，用于根据请求删除的配置特征的关联数据，确定所述车辆公司是否存在正在使用所述请求删除的配置特征的所述车辆配置项目；

如果否，则所述第四处理单元用于在所述总特征库以及所有包含所述请求删除的配置特征的特征库中删除所述请求删除的配置特征。

相较于现有技术，本申请具有以下有益效果：

本申请提供的车辆配置特征请求的处理方法中，对于同一车辆公司旗下每个子公司对应的配置特征库进行合并，获得该车辆公司的总特征库，即实现对所有车辆配置特征的统筹管控。当每个所述子公司或每个所述子公司下各个车辆配置项目发送配置特征请求时，利用车辆公司的总特征库处理配置特征请求。由于车辆公司的所有车辆配置特征均是汇集到总特征库统筹管控的，因此，面对配置特征请求时，能够较迅速地在所有子公司以及车辆配置项目中定位相关的配置特征，实现配置特征的准确追踪，并节约了追踪时间。可见，该方法能够避免处理车辆配置特征请求时的混乱，实现配置特征请求的高效处理。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种车辆配置特征请求的处理方法的流程图；

图2为本申请实施例提供的另一种车辆配置特征请求的处理方法的流程图；

图3为本申请实施例提供的又一种车辆配置特征请求的处理方法的流程图；

图4为本申请实施例提供的再一种车辆配置特征请求的处理方法的流程图；

图5为本申请实施例提供的一种车辆配置特征请求的处理装置的结构示意图。

具体实施方式

正如前文描述，目前很多车辆公司的子公司之间配置数据互不流通，另外很多子公司也没有针对公司内开展的各项车辆配置项目建立配置特征库，项目独立管控项目相关的配置数据。如此，导致配置特征的准确性与可追踪性极差，处理车辆配置特征请求时容易发生混乱。

针对该问题，发明人经过研究，提供了一种车辆配置特征请求的处理方法及装置，通过统筹管控子公司以及子公司下各个车辆配置项目的配置特征，能够准确追踪配置特征，解决处理车辆配置特征请求时发生混乱的问题。

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

第一实施例

参见图1，该图为本申请实施例提供的一种车辆配置特征请求的处理方法的流程图。

如图1所示，本申请实施例提供的车辆配置特征请求的处理方法，包括：

步骤101：获取同一车辆公司旗下每个子公司对应的配置特征库。

对于车辆而言，其配置具体可能包含有配置特征和绑定关系等多方面的信息。为便于理解配置特征的含义，下面对配置特征进行举例说明。

作为一示例，车身颜色有蓝色、白色、黑色等，其中，车身颜色称为特征族，蓝色、白色、黑色分别为该特征族下的不同配置特征。作为另一示例，车辆的轮胎品牌有万力、韩泰等，其中，轮胎品牌称为特征族，万力、韩泰分别为该特征族下的不同配置特征。

可以理解的是，以上仅为配置特征的示例，在实际应用中还包括多种其他的配置特征，此处不一一枚举。

可以理解的是，在实际应用中，每个子公司均可能开展至少一个车辆配置项目，因此，在本实施例中，子公司对应的配置特征库中包含该子公司开展的所有车辆配置项目涉及的配置特征。然而，对于每一个车辆公司，其旗下的子公司建立配置特征库的情况可能存在差异。下面提供了车辆公司旗下子公司建立配置特征库的三种可能的情况：

1)所有子公司都建立有子公司对应的配置特征库。

2)所有子公司中，只有一部分子公司建立有子公司对应的配置特征库，而其他子公司未建立子公司对应的配置特征库。

3)所有子公司均未建立子公司对应的配置特征库。

本步骤中，为获取车辆公司旗下每个子公司对应的配置特征，需要针对上述第2种和第3中情况，获取未建立子公司对应的配置特征库的子公司下各个车辆配置项目使用的所有车辆配置，再根据所有车辆配置建立子公司对应的配置特征库。

因此，本步骤在具体实现时，可以首先判断每个所述子公司是否具备对应的配置特征库，以此确定配置特征库的建立情况。经过判断，如果是，则获取所述子公司对应的配置特征库；如果否，则获取所述子公司下各个车辆配置项目使用的所有车辆配置，根据所述所有车辆配置建立所述子公司对应的配置特征库。

通过执行以上操作，即可获得同一车辆公司旗下每个子公司对应的配置特征库。

步骤102：将每个所述子公司对应的配置特征库合并为总特征库。

需要说明的是，本步骤中将每个子公司对应的配置特征库进行合并时，并不是将每个子公司对应的配置特征库进行简单的汇总加和。这是由于，不同子公司对应的配置特征库中，很可能包含有相同的配置特征。这些配置特征可能本质相同，但是相关的数据存在些许差异。例如，同一配置特征在子公司A对应的配置特征库中的中文描述为第一描述，在子公司B对应的配置特征库中的中文描述为第二描述；同一配置特征在子公司A对应的配置特征库中的英文描述为Description_1，在子公司B对应的配置特征库中的英文描述为Description_2。

显然，将本质相同但是相关数据存在些许差异的配置特征分别记入总特征库中，很可能造成数据冗余，同时数据存储量大，存储器负担过高，导致处理配置特征请求时性能低下，处理速度过慢。为此，可以对不同子公司对应的配置特征库中本质相同的配置特征进行去重，即去掉相互重叠的配置特征，仅保留其中的一个配置特征及其相关数据，并入总特征库中。如此一来，最终获得的总特征库中，各项配置特征互不重叠。如此一来，能够有效避免总特征库中的数据冗余，同时提高配置特征请求的处理速度。

在具体实现时，可以通过执行下述S1021～S1023实现本步骤102。

S1021：获取每个所述子公司对应的配置特征库中各项配置特征的描述和编码。

需要说明的是，配置特征的描述包括：英文描述和/或中文描述。

S1022：利用所述描述和/或所述编码，确定不同所述子公司对应的配置特征库中相互重叠的配置特征。

需要说明的是，所述相互重叠的配置特征具有唯一的所述编码。也就是说，本质相同的配置特征，即便在不同子公司对应的配置特征库中描述存在差异，在不同的配置特征库中本质相同的配置特征其编码(code)也是唯一确定的。因此，仅依据编码即可确定出不同配置特征库中相互重叠的配置特征。

另外，仅通过配置特征的描述也可以确定相互重叠的配置特征。例如，可以识别描述中的文字或字符，利用识别结果将不同配置特征库中的配置特征进行匹配，比较识别结果的相似性，如果识别结果的相似度大于预设相似度阈值，即可以确定出不同配置特征库中匹配成功的配置特征为相互重叠的配置特征。可以理解的是，以上仅为通过描述确定相互重叠的配置特征的示例性实现方式，在实际应用中，还可采用其他手段通过描述确定出相互重叠的配置特征，此处对实现方式不加以具体限定。

S1023：对于每个所述子公司对应的配置特征库中各项配置特征取并集，获得所述总特征库，所述总特征库中各项配置特征互不重叠。

步骤103：利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求。

本实施例中，配置特征请求具体可以是配置特征新增请求，即子公司或车辆配置项目请求新增一项或多项配置特征；也可以是配置特征修改请求，即子公司或车辆配置项目请求修改一项或多项配置特征；还可以是配置特征删除请求，即子公司或车辆配置项目请求删除一项或多项配置特征。本实施例中，对于配置特征请求的具体类型不加以限定。

以上，即为本申请实施例提供的车辆配置特征请求的处理方法。该方法中，对于同一车辆公司旗下每个子公司对应的配置特征库进行合并，获得该车辆公司的总特征库，即实现对所有车辆配置特征的统筹管控。当每个所述子公司或每个所述子公司下各个车辆配置项目发送配置特征请求时，利用车辆公司的总特征库处理配置特征请求。由于车辆公司的所有车辆配置特征均是汇集到总特征库统筹管控的，因此，面对配置特征请求时，能够较迅速地在所有子公司以及车辆配置项目中定位相关的配置特征，实现配置特征的准确追踪，并节约了追踪时间。可见，该方法能够避免处理车辆配置特征请求时的混乱，实现配置特征请求的高效处理。

为便于理解对于不同类型的配置特征请求在处理过程中的差异，下面利用三个实施例分别描述三种不同类型的配置特征请求的具体处理方式。

第二实施例

参见图2，该图为本申请实施例提供的另一种车辆配置特征请求的处理方法的流程图。

如图2所示，本实施例提供的车辆配置特征请求的处理方法，用于处理配置特征新增请求。该方法包括：

步骤201：获取同一车辆公司旗下每个子公司对应的配置特征库。

步骤202：将每个所述子公司对应的配置特征库合并为总特征库。

本实施例中，步骤201和202的实现方式与前述实施例中步骤101和102的实现方式相同，关于步骤201和202的相关描述可参见前述实施例，此处不再赘述。

步骤203：确定所述请求新增的配置特征的关联数据符合初步校核条件。如果配置特征新增请求是由子公司发送的，则执行步骤204；如果配置特征新增请求是由子公司下车辆配置项目发送的，则执行步骤205。

针对接收到的配置特征新增请求，首先需要对这一请求进行初步校核。本实施例中，所述配置特征新增请求中携带请求新增的配置特征的关联数据。关联数据包括：请求新增的配置特征的中文描述、英文描述和编码，以上三者均是关联数据必须包含的。当然，关联数据还可能包含上述三者以外的其他数据，此处不做限定。

作为一种可能的实现方式，确定所述请求新增的配置特征的关联数据是否符合初步校核条件，具体为，确定配置特征新增请求中是否完整携带了请求新增的配置特征的中文描述、英文描述和编码，并且，子公司中配置特征库中是否包含与请求新增的配置特征同一特征族但中文描述或英文描述相同的配置特征。仅当配置特征新增请求中完整携带了请求新增的配置特征的中文描述、英文描述和编码，并且，子公司中配置特征库中不包含与请求新增的配置特征同一特征族但中文描述或英文描述相同的配置特征，才可确定请求新增的配置特征的关联数据符合初步校核条件。

对于符合初步校核条件的请求新增的配置特征，还需要进一步明确发送配置特征新增请求的主体。发送请求的主体有两种可能，一种是由子公司发送，另一种是由子公司下车辆配置项目发送。针对上述两种可能的主题，前一种发送的请求可采用步骤204的方式进行处理，后一种发送的请求可以采用步骤205的方式进行处理。

步骤204：根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则执行步骤206；如果否，则执行步骤207。

本实施例中，默认来自子公司的配置特征新增请求已经预先在子公司对应的配置特征库中查询过子公司对应的配置特征库中不包含该请求新增的配置特征。步骤204在具体执行时，可以利用关联数据中的以下至少一种确定总特征库中是否已然包含请求新增的配置特征：

请求新增的配置特征的中文描述、英文描述或编码。

例如，查找总特征库中是否存在与请求新增的配置特征编码一致的配置特征，查找总特征库中是否存在与请求新增的配置特征中文/英文描述的识别结果相互匹配的配置特征等。显然，如果总特征库中已然包含请求新增的配置特征，则直接沿用总特征库中的该配置特征即可，因此可以通过执行步骤206向所述子公司发送沿用所述总特征库中包含的所述请求新增的配置特征的通知，以便子公司调用该请求新增的配置特征。而如果总特征库中不包含请求新增的配置特征，则需要在总特征库以及该请求的子公司对应的配置特征库中新增这一配置特征，并在添加完成后及时通知子公司，以便其调用，参见步骤207。

步骤205：根据所述请求新增的配置特征的关联数据判断所述车辆配置项目所属的子公司对应的配置特征库中是否包含所述请求新增的配置特征，如果是，则执行步骤208；如果否，则执行步骤209。

区别于发送请求的主体是子公司的情况，由于发送请求的主体是子公司下的某一车辆配置项目，由于子公司内部各个车辆配置项目使用的配置特征不共享不互通，因此首先需要确认所属的子公司对应的配置特征库中是否包含所述请求新增的配置特征。具体确认方式与前述步骤204相似，即查找子公司对应的配置特征库中是否存在关联数据与请求新增的配置特征的关联数据相互匹配的配置特征，如果存在，则表明可以沿用述配置特征库中包含的所述请求新增的配置特征，参见步骤208，如果不存在，则还需查询总特征库，进一步确认总特征库中是否包含与请求新增的配置特征的关联数据相互匹配的配置特征，参见步骤209。

步骤206：向所述子公司发送沿用所述总特征库中包含的所述请求新增的配置特征的通知。

步骤207：在所述子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述子公司发送配置特征新增完成的通知。

步骤208：向所述车辆配置项目发送沿用所述配置特征库中包含的所述请求新增的配置特征的通知。

步骤209：根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则执行步骤210；如果否，则执行步骤211。

步骤210：向所述车辆配置项目发送沿用所述总特征库中包含的所述请求新增的配置特征的通知。

步骤211：在所述车辆配置项目所属的子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述车辆配置项目发送配置特征新增完成的通知。

以上即为本申请实施例提供的另一种车辆配置特征请求的处理方法。该方法以配置特征请求是配置特征新增请求为例进行说明，对这一请求的具体处理流程进行了详细说明。

下面将结合第三实施例对配置特征请求是配置特征修改请求的具体处理方式进行说明。

第三实施例

参见图3，该图为本申请实施例提供的又一种车辆配置特征请求的处理方法的流程图。

如图3所示，本实施例提供的车辆配置特征请求的处理方法，用于处理配置特征修改请求。该方法包括：

步骤301：获取同一车辆公司旗下每个子公司对应的配置特征库。

步骤302：将每个所述子公司对应的配置特征库合并为总特征库。

本实施例中，步骤301和302的实现方式与前述实施例中步骤101和102的实现方式相同，关于步骤301和302的相关描述可参见前述实施例，此处不再赘述。

步骤303：确定所述请求修改的配置特征的关联数据符合初步校核条件。

配置特征修改请求中携带请求修改的配置特征的关联数据。

与前述第二实施例相似地，在获得配置特征修改请求后，首先也需要对这一请求中请求修改的配置特征的关联数据进行初步校核。需要说明的是，本实施例中，由于需要处理的是配置特征修改请求，因此，初步校核条件可能与处理配置特征新增请求时的初步校核条件存在差异。

本实施例中，作为一种示例性的实现方式，初步校核条件包括：配置特征修改请求中完整携带了请求修改的配置特征的中文描述、英文描述和编码。

步骤304：根据请求修改的配置特征的关联数据，确定所述车辆公司所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目。

如果对某一配置特征进行修改，而发出该修改请求的主体以外的该配置特征的使用者未知的情况下，将影响使用使用者对这一配置特征的正常使用。为避免此问题，本步骤首先确认所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目。

步骤305：向所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目，转发所述配置特征修改请求。

转发配置特征修改请求，以使所有这一配置特征的使用者获知请求发送者的具体请求内容。可以理解的是，接收方接收这一转发的请求后，可以反馈同意修改或反对修改的消息。进而，以便综合多方反馈的消息最终对配置特征修改请求进行处理。

步骤306：获取所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目反馈的消息，当所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目均同意所述配置特征修改请求时，在所述使用所述请求修改的配置特征的所述子公司对应的配置特征库以及所述总特征库中修改所述请求修改的配置特征。

由于仅当所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目均同意所述配置特征修改请求时，才在使用所述请求修改的配置特征的所述子公司对应的配置特征库以及所述总特征库中修改这一配置特征，因此，即便修改了配置特征，也不会影响使用者的使用体验，避免造成使用者位置情况下配置特征发生变更的问题。

以上即为本申请实施例提供的又一种车辆配置特征请求的处理方法。该方法以配置特征请求是配置特征修改请求为例进行说明，对这一请求的具体处理流程进行了详细说明。

下面将结合第四实施例对配置特征请求是配置特征删除请求的具体处理方式进行说明。

第四实施例

参见图4，该图为本申请实施例提供的再一种车辆配置特征请求的处理方法的流程图。

如图4所示，本实施例提供的车辆配置特征请求的处理方法，用于处理配置特征删除请求。该方法包括：

步骤401：获取同一车辆公司旗下每个子公司对应的配置特征库。

步骤402：将每个所述子公司对应的配置特征库合并为总特征库。

本实施例中，步骤401和402的实现方式与前述实施例中步骤101和102的实现方式相同，关于步骤401和402的相关描述可参见前述实施例，此处不再赘述。

步骤403：确定所述请求删除的配置特征的关联数据符合初步校核条件。

配置特征删除请求中携带请求删除的配置特征的关联数据。

与前述第二和第三实施例相似地，在获得配置特征删除请求后，首先也需要对这一请求中请求删除的配置特征的关联数据进行初步校核。需要说明的是，本实施例中，由于需要处理的是配置特征删除请求，因此，初步校核条件可能与处理配置特征新增请求时的初步校核条件存在差异。

本实施例中，作为一种示例性的实现方式，初步校核条件包括：配置特征删除请求中完整携带了请求删除的配置特征的中文描述、英文描述和编码。

步骤404：根据请求删除的配置特征的关联数据，确定所述车辆公司是否存在正在使用所述请求删除的配置特征的所述车辆配置项目；如果否，则执行步骤405。

可以理解的是，如果当前有正在使用请求删除的配置特征的车辆配置项目时，删除这一配置特征显然会导致该车辆配置项目无法正常开展，因此，需要首先确定是否存在该配置特征的使用者，从而避免该问题的发生。

步骤405：在所述总特征库以及所有包含所述请求删除的配置特征的配置特征库中删除所述请求删除的配置特征。

由于已经预先通过步骤404确认了当前无正在使用该请求删除的配置特征的车辆配置项目，因此，可以顺利直接地在总特征库以及所有包含该配置特征的配置特征库中删除该配置特征。这一删除操作将不会影响任何子公司或车辆配置项目的使用。

以上即为本申请实施例提供的再一种车辆配置特征请求的处理方法。该方法以配置特征请求是配置特征删除请求为例进行说明，对这一请求的具体处理流程进行了详细说明。

需要说明的是，在前述第二、第三和第四实施例中，分别对不同种类的配置特征请求利用初步校核条件进行了初步校核，仅当符合初步校核条件时，执行后续的请求处理流程。在实际应用中，可能存在一些不符合初步校核条件的配置特征请求，对于这些请求，可以向请求发送者反馈请求未通过初步校核的通知，以便发送方知晓，进而根据该通知对配置特征请求进行修改，再重新发送过来，进行后续再一次的初步校核。

基于前述实施例提供的车辆配置特征请求的处理方法，相应地，本申请还提供了一种车辆配置特征请求的处理装置。下面结合实施例和附图对该装置的具体实现进行详细描述。

第五实施例

参见图5，该图为本申请实施例提供的一种车辆配置特征请求的处理装置的结构示意图。

如图5所示，本申请实施例提供的车辆配置特征请求的处理装置，包括：

配置特征库获取模块501，用于获取同一车辆公司旗下每个子公司对应的配置特征库；

特征库合并模块502，用于将每个所述子公司对应的配置特征库合并为总特征库；

配置特征请求处理模块503，用于利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求。

以上即为本申请提供的车辆配置特征请求的处理装置，该装置对于同一车辆公司旗下每个子公司对应的配置特征库进行合并，获得该车辆公司的总特征库，即实现对所有车辆配置特征的统筹管控。当每个所述子公司或每个所述子公司下各个车辆配置项目发送配置特征请求时，利用车辆公司的总特征库处理配置特征请求。由于车辆公司的所有车辆配置特征均是汇集到总特征库统筹管控的，因此，面对配置特征请求时，能够较迅速地在所有子公司以及车辆配置项目中定位相关的配置特征，实现配置特征的准确追踪，并节约了追踪时间。可见，该装置能够避免处理车辆配置特征请求时的混乱，实现配置特征请求的高效处理。

可选地，所述配置特征库获取模块501，具体包括：

第一判断单元，第一获取单元，第二获取单元和配置特征库建立单元；

所述第一判断单元用于判断每个所述子公司是否具备对应的配置特征库，如果是，则所述第一获取单元用于获取所述子公司对应的配置特征库；如果否，则所述第二获取单元用于获取所述子公司下各个车辆配置项目使用的所有车辆配置，所述配置特征库建立单元用于根据所述所有车辆配置建立所述子公司对应的配置特征库。

可选地，所述特征库合并模块502，具体包括：

第三获取单元，第一确定单元和合并单元；

所述第三获取单元，用于获取每个所述子公司对应的配置特征库中各项配置特征的描述和编码；

所述第一确定单元，用于利用所述描述和/或所述编码，确定不同所述子公司对应的配置特征库中相互重叠的配置特征；所述相互重叠的配置特征具有唯一的所述编码；

所述合并单元，用于对于每个所述子公司对应的配置特征库中各项配置特征取并集，获得所述总特征库，所述总特征库中各项配置特征互不重叠。

本实施例中，配置特征请求具体可以是配置特征新增请求，即子公司或车辆配置项目请求新增一项或多项配置特征；也可以是配置特征修改请求，即子公司或车辆配置项目请求修改一项或多项配置特征；还可以是配置特征删除请求，即子公司或车辆配置项目请求删除一项或多项配置特征。本实施例中，对于配置特征请求的具体类型不加以限定。

下面以所述配置特征请求具体为配置特征新增请求为例，描述配置特征请求处理模块503的一种可能的实现方式。

可选地，所述配置特征新增请求中携带请求新增的配置特征的关联数据；

所述配置特征请求处理模块503，具体包括：

第二确定单元，第一处理单元和第二处理单元；

所述第二确定单元，用于确定所述请求新增的配置特征的关联数据符合初步校核条件；

所述第一处理单元，用于对于每个所述子公司发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述子公司发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述子公司发送配置特征新增完成的通知；

所述第二处理单元，用于对于每个所述子公司下各个车辆配置项目发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述车辆配置项目所属的子公司对应的配置特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述配置特征库中包含的所述请求新增的配置特征的通知；如果否，则根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述车辆配置项目所属的子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述子公司发送配置特征新增完成的通知。

下面以所述配置特征请求具体为配置特征修改请求为例，描述配置特征请求处理模块503的另一种可能的实现方式。

可选地，所述配置特征修改请求中携带请求修改的配置特征的关联数据；

所述配置特征请求处理模块503，具体包括：

第三确定单元，第四确定单元，转发单元，第四获取单元和第三处理单元；

所述第三确定单元，用于确定所述请求修改的配置特征的关联数据符合初步校核条件；

所述第四确定单元，用于根据请求修改的配置特征的关联数据，确定所述车辆公司所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目；

转发单元，用于向所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目，转发所述配置特征修改请求；

所述第四获取单元，用于获取所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目反馈的消息；

所述第三处理单元，用于当所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目均同意所述配置特征修改请求时，在所述使用所述请求修改的配置特征的所述子公司对应的配置特征库以及所述总特征库中修改所述请求修改的配置特征。

下面以所述配置特征请求具体为配置特征删除请求为例，描述配置特征请求处理模块503的又一种可能的实现方式。

可选地，所述配置特征删除请求中携带请求删除的配置特征的关联数据；

所述配置特征请求处理模块503，具体包括：

第五确定单元，第六确定单元和第四处理单元；

所述第五确定单元，用于确定所述请求删除的配置特征的关联数据符合初步校核条件；

所述第六确定单元，用于根据请求删除的配置特征的关联数据，确定所述车辆公司是否存在正在使用所述请求删除的配置特征的所述车辆配置项目；

如果否，则所述第四处理单元用于在所述总特征库以及所有包含所述请求删除的配置特征的特征库中删除所述请求删除的配置特征。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及***实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述，仅为本申请的一种具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (10)

1.一种车辆配置特征请求的处理方法，其特征在于，包括：

获取同一车辆公司旗下每个子公司对应的配置特征库；

将每个所述子公司对应的配置特征库合并为总特征库；

利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求。

2.根据权利要求1所述的方法，其特征在于，所述获取同一车辆公司旗下每个子公司对应的配置特征库，具体包括：

判断每个所述子公司是否具备对应的配置特征库，如果是，则获取所述子公司对应的配置特征库；如果否，则获取所述子公司下各个车辆配置项目使用的所有车辆配置，根据所述所有车辆配置建立所述子公司对应的配置特征库。

3.根据权利要求1所述的方法，其特征在于，所述将每个所述子公司对应的配置特征库合并为总特征库，具体包括：

获取每个所述子公司对应的配置特征库中各项配置特征的描述和编码；

利用所述描述和/或所述编码，确定不同所述子公司对应的配置特征库中相互重叠的配置特征；所述相互重叠的配置特征具有唯一的所述编码；

对于每个所述子公司对应的配置特征库中各项配置特征取并集，获得所述总特征库，所述总特征库中各项配置特征互不重叠。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述配置特征请求具体为配置特征新增请求，所述配置特征新增请求中携带请求新增的配置特征的关联数据；

所述利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求，具体包括：

确定所述请求新增的配置特征的关联数据符合初步校核条件；

对于每个所述子公司发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述子公司发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述子公司发送配置特征新增完成的通知；

对于每个所述子公司下各个车辆配置项目发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述车辆配置项目所属的子公司对应的配置特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述配置特征库中包含的所述请求新增的配置特征的通知；如果否，则根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述车辆配置项目所属的子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述车辆配置项目发送配置特征新增完成的通知。

5.根据权利要求1-3任一项所述的方法，其特征在于，所述配置特征请求具体为配置特征修改请求，所述配置特征修改请求中携带请求修改的配置特征的关联数据；

所述利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求，具体包括：

确定所述请求修改的配置特征的关联数据符合初步校核条件；

根据请求修改的配置特征的关联数据，确定所述车辆公司所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目；

向所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目，转发所述配置特征修改请求；

获取所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目反馈的消息，当所述所有使用所述请求修改的配置特征的所述子公司与所述车辆配置项目均同意所述配置特征修改请求时，在所述使用所述请求修改的配置特征的所述子公司对应的配置特征库以及所述总特征库中修改所述请求修改的配置特征。

6.根据权利要求1-3任一项所述的方法，其特征在于，所述配置特征请求具体为配置特征删除请求，所述配置特征删除请求中携带请求删除的配置特征的关联数据；

所述利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求，具体包括：

确定所述请求删除的配置特征的关联数据符合初步校核条件；

根据请求删除的配置特征的关联数据，确定所述车辆公司是否存在正在使用所述请求删除的配置特征的所述车辆配置项目；

如果否，则在所述总特征库以及所有包含所述请求删除的配置特征的配置特征库中删除所述请求删除的配置特征。

7.一种车辆配置特征请求的处理装置，其特征在于，包括：

配置特征库获取模块，用于获取同一车辆公司旗下每个子公司对应的配置特征库；

特征库合并模块，用于将每个所述子公司对应的配置特征库合并为总特征库；

配置特征请求处理模块，用于利用所述总特征库处理每个所述子公司或每个所述子公司下各个车辆配置项目发送的配置特征请求。

8.根据权利要求7所述的装置，其特征在于，所述配置特征库获取模块，具体包括：

第一判断单元，第一获取单元，第二获取单元和配置特征库建立单元；

所述第一判断单元用于判断每个所述子公司是否具备对应的配置特征库，如果是，则所述第一获取单元用于获取所述子公司对应的配置特征库；如果否，则所述第二获取单元用于获取所述子公司下各个车辆配置项目使用的所有车辆配置，所述配置特征库建立单元用于根据所述所有车辆配置建立所述子公司对应的配置特征库。

9.根据权利要求7所述的装置，其特征在于，所述特征库合并模块，具体包括：

第三获取单元，第一确定单元和合并单元；

所述第三获取单元，用于获取每个所述子公司对应的配置特征库中各项配置特征的描述和编码；

所述第一确定单元，用于利用所述描述和/或所述编码，确定不同所述子公司对应的配置特征库中相互重叠的配置特征；所述相互重叠的配置特征具有唯一的所述编码；

所述合并单元，用于对于每个所述子公司对应的配置特征库中各项配置特征取并集，获得所述总特征库，所述总特征库中各项配置特征互不重叠。

10.根据权利要求7-9任一项所述的装置，其特征在于，所述配置特征请求具体为配置特征新增请求，所述配置特征新增请求中携带请求新增的配置特征的关联数据；

所述配置特征请求处理模块，具体包括：

第二确定单元，第一处理单元和第二处理单元；

所述第二确定单元，用于确定所述请求新增的配置特征的关联数据符合初步校核条件；

所述第一处理单元，用于对于每个所述子公司发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述子公司发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述子公司发送配置特征新增完成的通知；

所述第二处理单元，用于对于每个所述子公司下各个车辆配置项目发送的配置特征新增请求，根据所述请求新增的配置特征的关联数据判断所述车辆配置项目所属的子公司对应的配置特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述配置特征库中包含的所述请求新增的配置特征的通知；如果否，则根据所述请求新增的配置特征的关联数据判断所述总特征库中是否包含所述请求新增的配置特征，如果是，则向所述车辆配置项目发送沿用所述总特征库中包含的所述请求新增的配置特征的通知；如果否，则在所述车辆配置项目所属的子公司对应的配置特征库以及所述总特征库中添加所述请求新增的配置特征，并向所述子公司发送配置特征新增完成的通知。

Images