一种共享汽车的实时维护方法、装置及系统与流程

本申请涉及数据处理技术领域，尤其涉及一种共享汽车的实时维护方法、装置及系统。

背景技术：

随着共享汽车的普及和发展，共享汽车的安全问题成为人们越来越关注的焦点。

通常共享汽车的维护方法为，用户或维修人员发现共享汽车出现故障时，向服务器发送提示信息。维修人员确定故障原因后，将共享汽车开往4s店。

然而，上述方法需要共享汽车运营商雇佣大量维修人员以保证共享汽车能够及时维修，消耗大量人资源，从而降低了维护效率。

技术实现要素：

为了解决上述问题，第一方面，本申请提出了一种共享汽车的实时维护方法，包括：

服务器接收来自终端的故障维修请求消息，所述故障维修请求消息包括终端用户对应的目标共享汽车的地理位置信息、所述目标共享汽车的车辆型号和所述目标共享汽车的第一故障数据；其中，所述第一故障数据是由所述终端用户确定的故障数据；

所述服务器通过所述目标共享汽车的车载诊断设备，采集所述目标共享汽车的第二故障数据；

所述服务器根据所述第一故障数据和/或所述第二故障数据，确定所述目标共享汽车的故障类型；

所述服务器根据所述目标共享汽车的故障类型、所述目标共享汽车的地理位置信息、所述目标共享汽车的车辆型号中的一个或多个，确定所述目标共享汽车对应的维修节点；

所述服务器将所述目标共享汽车的故障类型、所述目标共享汽车的地理位置信息、所述目标共享汽车的车辆型号中的一个或多个发送给所述维修节点。

一个示例中，所述服务器根据所述目标共享汽车的故障类型、所述目标共享汽车的地理位置信息、所述目标共享汽车的车辆型号中的一个或多个，确定所述目标共享汽车对应的维修节点，包括：

所述服务器根据所述目标共享汽车的地理位置信息，确定所述目标共享汽车对应的预设区域标识；

所述服务器根据所述目标共享汽车的故障类型和/或所述目标共享汽车的车辆型号，在所述预设区域标识对应的区域内，确定维修节点集合，所述维修节点集合包括：多个维修节点；

所述服务器分别确定所述维修节点集合中各维修节点的地理位置信息；

所述服务器根据所述目标共享汽车的地理位置信息，以及维修节点集合中各维修节点的地理位置信息，确定距离所述目标共享汽车最近的维修节点。

一个示例中，所述服务器根据所述故障类型、所述目标共享汽车的地理位置信息、所述目标共享汽车的车辆型号中的一个或多个，确定所述目标共享汽车对应的维修节点，包括：

所述服务器根据所述地理位置信息，确定所述目标共享汽车对应的预设区域标识；

所述服务器根据所述故障类型和/或所述车辆型号，在所述预设区域标识对应的区域内，确定维修节点集合，所述维修节点集合包括：多个维修节点；

所述服务器向所述维修节点集合中各个维修节点广播维修订单；

所述服务器接收来自所述维修节点集合中的一个或多个维修节点的接单数据，确定最先接收到的接单数据对应的维修节点。

一个示例中，所述方法还包括：

所述服务器从所述目标共享汽车上的行车记录设备获取多个行驶路线数据以及各个所述行驶路线数据对应的行驶时间；

所述服务器将所述第一故障数据和/或第二故障数据、所述行驶路线数据、所述行驶时间以及驾驶员身份信息对应存储；

所述服务器根据所述驾驶员信息，将对应的已存储的数据发送至对应的终端，并接收来自所述对应的终端的用户签名数据。

一个示例中，所述方法还包括：

所述服务器接收来自所述维修节点的车辆维修完成信息；

所述服务器通过所述目标共享汽车上的车载诊断设备，采集所述目标共享汽车的状态数据；

所述服务器根据所述状态数据和所述第一故障数据和/或第二故障数据，确定所述目标共享汽车的维修结果，并将所述维修结果发送给所述维修节点。

一个示例中，在所述服务器将所述维修结果发送给所述维修节点之后，所述方法还包括：

所述服务器接收来自所述维修节点的维修账单数据；

所述服务器确定所述终端用户是否完成所述目标共享汽车的保险交易过程；

在所述终端用户已经完成所述保险交易过程之后，所述服务器根据所述故障类型，所述维修账单数据以及所述保险的类型，计算所述目标共享汽车的维修费用。

一个示例中，在所述确定所述目标共享汽车对应的维修节点之后，所述方法还包括：

所述服务器确定所述维修节点的地理位置信息；

所述服务器根据所述维修节点的地理位置信息和所述目标共享汽车的地理位置信息，确定所述维修节点到所述目标共享汽车的路线数据，并将所述路线数据发送给所述维修节点。

一个示例中，所述服务器根据所述第一故障数据和/或所述第二故障数据，确定所述目标共享汽车的故障类型，包括：

所述服务器从所述第一故障数据和/或所述第二故障数据中提取多个故障特征数据；

所述服务器将所述多个故障特征数据分成多个故障数据集合，其中，各个所述故障数据集合的初始元素个数等于1；

所述服务器两两确定所述多个故障数据集合之间的欧氏距离；

所述服务器将所述欧氏距离最小的两个故障数据集合合并；

所述服务器重复所述确定欧氏距离的步骤和所述合并集合的步骤，直至任意两个所述故障数据集合之间的欧氏距离达到预设阈值；

所述服务器根据合并后的至少一个故障数据集合中每个故障数据集合中的故障特征数据，确定所述并后的至少一个故障数据集合对应的故障类型。

第二方面，本申请实施例中提出了一种共享汽车的实时维护装置，包括：接收模块，采集模块、数据处理模块和发送模块；

所述接收模块用于接收来自终端的故障维修请求消息，所述故障维修请求消息包括终端用户对应的目标共享汽车的地理位置信息、所述目标共享汽车的车辆型号和所述目标共享汽车的第一故障数据；其中，所述第一故障数据是由所述终端用户确定的故障数据；

所述采集模块用于通过所述目标共享汽车的车载诊断设备，采集所述目标共享汽车的第二故障数据；

所述数据处理模块用于根据所述接收模块接收到的所述第一故障数据和/或所述采集模块采集到的所述第二故障数据，确定所述目标共享汽车的故障类型；

所述数据处理模块还用于根据所述目标共享汽车的故障类型、所述目标共享汽车的地理位置信息、所述目标共享汽车的车辆型号中的一个或多个，确定所述目标共享汽车对应的维修节点；

所述发送模块用于将所述目标共享汽车的故障类型、所述目标共享汽车的地理位置信息、所述目标共享汽车的车辆型号中的一个或多个发送给所述维修节点。

第三方面，本申请实施例提出了一种共享汽车的实时维护系统，包括：至少一个终端、至少一辆共享汽车至少一个维修节点以及第二方面中所述的实时维护装置。

通过本申请提出的共享汽车的实时维护方法能够带来如下有益效果：

1.根据终端用户提供的第一故障数据并结合车载诊断设备采集的第二故障数据，能够准确地确定出共享汽车出现的故障类型，从而提高了维护效率；

2.终端用户提供的第一故障数据和车载诊断设备采集的第二故障数据均能通过网络传输至服务器，因此可以用在线检测的方式代替人工检测，从而提高了维护效率；

3.将目标共享汽车的故障类型、地理位置信息、车辆型号中的一个或多个发送给维修节点，让维修节点将目标共享汽车取回对应的4s店或维修店，减少了共享汽车运营商的维修人员雇佣量，从而提高了维护效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提出的一种共享汽车的实时维护方法的流程图；

图2为本申请实施例提出的一种共享汽车的实时维护装置的结构示意图；

图3为本申请实施例提出的一种共享汽车的实时维护系统的结构示意图。

具体实施方式

为了更清楚的阐释本申请的整体构思，下面结合说明书附图以示例的方式进行详细说明。

本申请的实施例公开了一种共享汽车的实时维护方法，如图1所示，包括以下步骤：

步骤101，服务器接收来自终端的故障维修请求消息。

在本申请实施例中，故障维修请求消息包括终端用户对应的目标共享汽车的地理位置信息、目标共享汽车的车辆型号和目标共享汽车的第一故障数据；其中，第一故障数据是由终端用户确定的故障数据。例如，用户通过手机向服务器发送“车辆损坏”、“车辆未熄火”、“车胎异常”、“无法启动”等文字，同时将相应的照片发送给服务器，以作为第一故障数据。此外，用户可以向服务器发送目标共享汽车的车牌号，以便于服务器确定目标共享汽车的地理位置信息和目标共享汽车的车辆型号。

步骤102，服务器通过目标共享汽车的车载诊断设备，采集目标共享汽车的第二故障数据。

在本申请实施例中，车载诊断设备能够进入发动机、变速箱、防抱死等系统的电控单元中读取故障码和其它相关数据，并利用车载通讯系统，例如gps(globalpositioningsystem，全球定位系统)导航系统或无线通信方式将车辆的身份代码、故障码及所在位置等信息自动发送给服务器。

第二故障数据包括但不限于：车辆动力总成中各轴承的振动信号，油耗参数，节气门温度参数，进气管压力参数，进气温度参数，进气流量、冷却液温度中的一个或多个。其中，各轴承的振动信号用于表征轴承的磨损程度，这是因为轴承经过长时间运转，轴承表面会因疲劳产生不同程度的损毁，例如裂痕、表面脱落，而轴承表面的损毁能够引发轴承振动。

步骤103，服务器根据故障维修请求消息中的第一故障数据和/或第二故障数据，确定目标共享汽车的故障类型。

通常共享汽车上的主控设备会提示车辆的某个部位出现故障，但不能指示故障原因，需要维修人员进行全面的检查，从而降低了共享汽车的实时维护效率。为了解决上述问题，在本申请实施例中，服务器根据第一故障数据和/或第二故障数据，确定目标共享汽车的故障类型，使得维修人员可以根据故障类型判断故障原因。

根据步骤102可知，第一故障数据的数据类型可以为文字、图片，第二故障数据的数据类型可以为振动信号、故障码以及其他传感器对应的信号等。因此，服务器不能直接利用第一故障数据和/或第二故障数据进行数据处理，需要从第一故障数据和/或第二故障数据提取出多个故障特征数据。

为了能够比较准确地确定故障类型，需要获取多个维度的故障特征数据。但是多维度会极大增加数据处理的难度，因此，在本申请实施例中，需要通过合并故障数据集合来降低维度，以降低数据处理难度，具体步骤如下：

先将每一个故障特征数据视为一个故障数据集合，服务器两两确定多个故障数据集合之间的欧氏距离，例如，存在故障数据集合a、b、c，那么服务器分别取定a与b的欧氏距离、b与c的欧氏距离以及a与c的欧氏距离。再将欧氏距离最小的两个故障数据集合合并。

服务器重复执行确定欧氏距离的步骤和合并集合的步骤，直至任意两个故障数据集合之间的欧氏距离达到预设阈值。在上述循环过程中，每一次循环过程只合并两个故障数据集合，且被合并的两个故障数据集合之间的欧氏距离最小，以保证故障数据集合中元素的单一性。例如，存在四个故障特征数据1、2、3、4分别对应四个故障数据集合a、b、c、d，如果集合a与集合b之间的欧氏距离最小，且没有达到预设阈值，那么合并后得到e、c、d三个集合，其中，集合e中的元素为1，2。此时，如果集合c与集合e之间的欧氏距离最小，且没有达到预设阈值，那么合并后得到f、d两个集合，其中，集合f中的元素为1，2，3。

通过上述方法各个故障特征数据与故障类型的对应关系转化成故障数据集合与故障类型的对应关系，从而降低了数据处理的维度。最后，服务器利用合并后的各个故障数据集合中的故障特征数据，确定各个故障数据集合对应的故障类型。例如，利用故障数据集合构造人工神经网络的训练向量，以使得人工神经网络根据故障数据集合，确定故障类型。训练完成后，在人工神经网络会对接收到的第一故障数据和/或第二故障数据对应的输入向量时，人工神经网络会自动确定目标共享汽车对应的故障类型。

步骤104，服务器根据目标共享汽车的故障类型、故障维修请求消息中的目标共享汽车的地理位置信息、故障维修请求消息中的目标共享汽车的车辆型号中的一个或多个，确定目标共享汽车对应的维修节点。

本申请实施例中，如果只考虑目标共享汽车的地理位置信息，服务器可以选择距离最近的维修节点，维修节点包括但不限于：专门提供车辆维修服务的个人、企业以及4s店。此外，本申请实施例还给出了另外两种确定维修节点的方法：

第一种方法，服务器根据目标共享汽车的地理位置信息，确定目标共享汽车对应的预设区域标识，其中，区域标识可以为自己设定的，如，a、b、c区，也可以是行政区域对应的标识，例如各省，各地级市，各区县对应的标识。

服务器根据目标共享汽车的故障类型和/或目标共享汽车的车辆型号，在预设区域标识对应的区域内，确定由多个维修节点组成的维修节点集合。服务器在特定的区域内确定一个维修节点的选择范围，以减少数据处理量，从而提高车辆维护效率。例如，目标共享汽车车辆型号为北京现代，如果不限定搜索区域，服务器会搜索全国范围内的现代4s店，如果限定搜索区域为北京，服务器只会搜索北京范围内的现代4s店，从而极大减少了服务器的工作量。

服务器分别确定维修节点集合中各维修节点的地理位置信息，再根据目标共享汽车的地理位置信息，以及维修节点集合中各维修节点的地理位置信息，确定距离目标共享汽车最近的维修节点。

与第一种方法相比，第二种方法服务器同样需要限定地域，并根据目标共享汽车的故障类型和/或目标共享汽车的车辆型号确定维修节点集合。之后，服务器不会根据距离在指定维修节点，而是以抢单的方式选择维修节点。例如，维修节点集合中存在a、b、c三个维修节点，服务器向a、b、c三个维修节点广播维修订单，如果a维修节点收到维修订单并最先向服务器发送接单数据，那么服务器会选择a维修节点。

可以理解的是，第一种方法侧重于节省将目标共享汽车送到维修节点的时间，第二种方法侧重于让维修节点根据自身的业务繁忙情况选择是否接单，以减少共享汽车在维修过程中的等待时间。在实际应用中，服务器可以根据实际场景，利用第一种方法或第二种方法来选择维修节点，从而提高维修效率。

步骤105，服务器将目标共享汽车的故障类型、目标共享汽车的地理位置信息、目标共享汽车的车辆型号中的一个或多个发送给维修节点。

综上所述，本申请实施例提供的技术方案，从故障诊断、维修节点选择等方面来提高维修效率。

为了便于维修节点快速接收目标共享汽车，在本申请实施例中，服务器对维修节点的取车路线进行导航。例如，服务器在确定a修车厂为维修节点后，确定a修车厂的地理位置信息；再根据a修车厂的地理位置信息和目标共享汽车的地理位置信息，确定a修车厂到目标共享汽车的路线数据；最后服务器将路线数据发送给a修车厂。

有时候共享汽车的故障是由用户造成的，为便于确定责任方，在本申请实施例中，服务器从目标共享汽车上的行车记录设备获取多个行驶路线数据以及各个行驶路线数据对应的行驶时间，即获取目标共享汽车在各个时间段内的行驶轨迹，各个时间段可以用停车时间节点来划分；服务器将第一故障数据和/或第二故障数据、行驶路线数据、行驶时间以及驾驶员身份信息对应存储，即将第一故障数据和/或第二故障数据、行驶路线数据、行驶时间与驾驶员身份信息绑定，以明确责任方；服务器根据驾驶员信息，将对应的已存储的数据发送至对应的终端，并接收来自对应的终端的用户签名数据，让用户确认存储的数据，进一步明确责任方。

在共享车辆完成维修后，共享汽车的运营公司通常会派维修人员去修车厂或4s店验看车辆是否完成维修，占用了维修人员的工作时间，为了解决上述问题，在本申请实施例中，在服务器接收来自维修节点的车辆维修完成信息之后，服务器通过目标共享汽车上的车载诊断设备，采集目标共享汽车的状态数据；服务器根据状态数据和第一故障数据和/或第二故障数据，确定目标共享汽车的维修结果，并将维修结果发送给维修节点。由此可见，本申请实施例提出的技术方案能实现远程在线检测共享车辆的维修结果，从而提高了维修人员的工作效率。

在本申请实施例中，在用户使用共享汽车之前，服务器会向用户推荐车辆保险以及附加险，例如，车损险、不计免赔险。在共享车辆完成维修后，服务器会接收到来自维修节点的维修账单数据。此时，服务器确定终端用户是否购买相应的保险；在确定用户购买保险交易之后，服务器根据故障类型，维修账单数据以及保险的类型，计算目标共享汽车的维修费用。

如图2所示，本申请实施例提供了一种共享汽车的实时维护装置，包括：接收模块201，采集模块202、数据处理模块203和发送模块204；

接收模块201用于接收来自终端的故障维修请求消息，故障维修请求消息包括终端用户对应的目标共享汽车的地理位置信息、目标共享汽车的车辆型号和目标共享汽车的第一故障数据；其中，第一故障数据是由终端用户确定的故障数据；

采集模块202用于通过目标共享汽车的车载诊断设备，采集目标共享汽车的第二故障数据；

数据处理模块203用于根据接收模块201接收到的第一故障数据和/或采集模块202采集到的第二故障数据，确定目标共享汽车的故障类型；

数据处理模块203还用于根据目标共享汽车的故障类型、目标共享汽车的地理位置信息、目标共享汽车的车辆型号中的一个或多个，确定目标共享汽车对应的维修节点；

发送模块204用于将目标共享汽车的故障类型、目标共享汽车的地理位置信息、目标共享汽车的车辆型号中的一个或多个发送给维修节点。

如图3所示，本申请实施例提拱了一种共享汽车的实时维护系统，包括：至少一个终端301、至少一辆共享汽车302、至少一个维修节点303以及上述实施例所述的实时维护装置304。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。