CN116224977A - 车辆故障的诊断方法、装置、车辆及存储介质 - Google Patents

Abstract

本申请提供了一种车辆故障的诊断方法、装置、车辆及存储介质，涉及自动控制技术领域，该方法包括：在车辆出现故障的情况下，获取车辆的故障数据；基于故障数据对车辆进行故障诊断，得到车辆中出现故障的目标部件；在虚拟空间中对三维车辆模型中的目标部件进行突出显示；其中，三维车辆模型为车辆的三维模型。通过上述技术方案，在车辆出现故障时，能够对车辆进行故障诊断，并且在虚拟空间中的三维车辆模型中突出显示出故障部件，使得用户直观地感受到车辆出现故障的部分，有利于提高车辆的维修效率。

Description

车辆故障的诊断方法、装置、车辆及存储介质

技术领域

本申请涉及自动控制技术领域，尤其涉及一种车辆故障的诊断方法、装置、车辆及存储介质。

背景技术

随着社会发展，汽车已经成为人们日常出行常用的交通工具，汽车的家庭保有量也极为可观。这就导致汽车的维修需求成为消费者的一个日常需求之一。

然而，现有的汽车维修方式一般是在汽车的数字仪表或者中控屏幕出现故障码，或者是汽车固件肉眼可见的损坏，再或者车辆不能行驶的情况下，由车主主动联系汽车销售售后服务（Automobile Sales Service Shop，4S）店或者去维修点维修。这种维修方式中车主往往是被动的，并不知道汽车具体哪里出问题了，即便联系上4S店之后也很难描述清楚具体问题。因此，导致维修效率较低，进而影响用户体验。

发明内容

本申请的目的在于提供一种车辆故障的诊断方法、装置、车辆及存储介质，能够在虚拟空间中对三维车辆模型中的故障部件进行突出显示，有利于提高车辆的维修效率。

第一方面，本申请提供了一种车辆故障的诊断方法，包括如下的步骤。

在车辆出现故障的情况下，获取所述车辆的故障数据；基于所述故障数据对所述车辆进行故障诊断，得到所述车辆中出现故障的目标部件；在虚拟空间中对三维车辆模型中的所述目标部件进行突出显示；其中，所述三维车辆模型为所述车辆的三维模型。

第二方面，本申请提供了一种车辆故障的诊断装置，包括如下的模块。

获取模块，用于在车辆出现故障的情况下，获取所述车辆的故障数据；处理模块，用于基于所述故障数据对所述车辆进行故障诊断，得到所述车辆中出现故障的目标部件；显示模块，用于在虚拟空间中对三维车辆模型中的所述目标部件进行突出显示；其中，所述三维车辆模型为所述车辆的三维模型。

第三方面，本申请提供一种车辆，包括：存储器，用于存储可执行程序代码；处理器，用于从所述存储器中调用并运行所述可执行程序代码，使得所述车辆执行上述方法中的步骤。

第四方面，本申请提供一种计算机存储介质，所述计算机可读存储介质存储有一个或者多个程序，该一个或者多个程序可被一个或者多个处理器执行，以实现上述方法中的步骤。

本申请提供了一种车辆故障的诊断方法，该方法包括：在车辆出现故障的情况下，获取车辆的故障数据；基于故障数据对车辆进行故障诊断，得到车辆中出现故障的目标部件；在虚拟空间中对三维车辆模型中的目标部件进行突出显示；其中，三维车辆模型为车辆的三维模型。通过上述技术方案，在车辆出现故障时，能够对车辆进行故障诊断，并且在虚拟空间中的三维车辆模型中突出显示出故障部件，使得用户直观地感受到车辆出现故障的部分，有利于提高车辆的维修效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种车辆故障的诊断方法的流程示意图。

图2是本申请实施例提供的一种突出显示目标部件的示意图。

图3是本申请实施例提供的另一种车辆故障的诊断方法的流程示意图。

图4是本申请实施例提供的一种显示目标部件的基础信息的示意图。

图5是本申请实施例提供的一种显示目标部件的建议维修方案的示意图。

图6是本申请实施例提供的又一种车辆故障的诊断方法的流程示意图。

图7是本申请实施例提供的一种车辆故障的诊断装置的结构示意图。

图8是本申请实施例提供的一种车辆的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

为了解决上述问题，本申请实施例提供一种车辆故障的诊断方法，该方法包括：在车辆出现故障的情况下，获取车辆的故障数据；基于故障数据对车辆进行故障诊断，得到车辆中出现故障的目标部件；在虚拟空间中对三维车辆模型中的目标部件进行突出显示；其中，三维车辆模型为车辆的三维模型。通过上述技术方案，在车辆出现故障时，能够对车辆进行故障诊断，并且在虚拟空间中的三维车辆模型中突出显示出故障部件，使得用户直观地感受到车辆出现故障的部分，有利于提高车辆的维修效率。

需要说明的是，本申请实施例中提供的车辆故障的诊断方法应用于智能诊断系统。本申请实施例中，智能诊断系统是由穿戴设备和车载终端设备组成的系统，其中，穿戴设备包括增强现实（augmented reality，AR）或者虚拟现实（virtual reality，VR）眼镜或者头盔、手机、智能手表、智能手环等，车载终端设备为搭载有车机系统应用的终端设备。

下面，将结合附图对本申请实施例的车辆故障的诊断方法的技术方案进行详细的说明。

图1是本申请实施例提供的一种车辆故障的诊断方法的流程示意图。

参见图1所示，应用于上述智能诊断系统，该车辆故障的诊断方法包括以下步骤。

步骤S101、在车辆出现故障的情况下，获取车辆的故障数据。

可选的，故障数据包括控制器局域网络（Controller Area Network，CAN）总线数据和控制器内部数据。

可选的，故障数据包括车辆出现故障时，车辆各个部件的运行参数，例如发动机的运行参数。

在一些实施例中，步骤S101之前，上述方法还包括：在车辆的各部件处包括带有数据传输功能的传感器（包括温度传感器、压力传感器、位置传感器等），该传感器用于实时采集各部件的数据，进而监视车辆运行过程中各部件运行状况。平时的日常行驶过程中，周期性检测车辆传感器回传的数据，通过与预留正常的车辆标准参数对比，判断车辆是否出现故障。例如，根据火花塞处的压力传感器传输的压力数据，判断火花塞是否松脱。在本申请实施例中，各项传感器指标范围，即车辆标准参数，由维修售后中心进行维护更新。

可选的，确定车辆为故障状态之后，还可以包括：在数字仪表或者车机系统上输出故障提示。其中，该提示还可以是点亮故障灯或检查发动机警告灯。

这样，当车辆出现故障时，车主看到在数字仪表或者车机系统上给出提示后，可以及时地了解故障情况，进而及时对车辆进行检修。

在一些实施例中，步骤S101之前，上述方法还包括：用户通过手机应用软件（Application，APP）给车辆中的智能车载终端（Telematic BOX，T-BOX）发送车辆诊断指令，智能车载终端运行车载终端中的诊断程序，通过控制器控制车辆的相关部件执行检测动作，如控制车灯按照顺序闪亮以及控制车窗的升降等，以完成对车辆故障的检测，最后，智能车载终端再将诊断结果返回至用户的手机APP。其中，该车辆可以是之前与手机构建无线连接或者有线连接的车辆。

或者，在车辆启动之后，运行诊断程序通过控制器控制车辆的相关部件执行检测动作，以完成对车辆故障的检测，最后，智能车载终端再将诊断结果通过车机系统输出。

可选的，在步骤S101中获取车辆的故障数据之后，可以将故障数据通过CAN总线传输至智能车载终端。这样，智能车载终端能够非常方便快捷地获取到车辆的状态信息，有利于之后对车辆进行故障诊断。

步骤S102、基于故障数据对车辆进行故障诊断，得到车辆中出现故障的目标部件。

其中，目标部件可以是发动机、车载空调、车灯、车轮等，本申请实施例对此不做限定。

在一些实施例中，步骤S102包括：通过车载诊断系统OBD对故障数据进行分析，确定目标部件。

本申请实施例中，OBD用于监控车辆基本参数，例如监控里程、车速、油门踏板位置、冷却液温度等参数。

可选的，步骤S102还可以包括：通过通用诊断系统（Unifieddiagnosticservices，UDS）对故障数据进行分析，确定目标部件。

本申请实施例中，UDS是一个在整车系统上经常使用的设备维护协议，经常应用在整车的各种电子控制单元（Electronic Control Unit，ECU）上面。UDS既可以在CAN线上实现，甚至也能在以太网（Ethernet）上实现。并且，UDS提供的是一个诊断服务的基本框架，主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来。这样，方便了生产线检测设备的开发，有利于售后维修保养和车联网的功能实现。

通过上述技术方案，利用OBD确定出现故障的目标部件，无需增加其他设备，实现了低成本、高效率地对车辆故障进行诊断。

在另一些实施例中，步骤S102包括如下的步骤。

将故障数据发送至维修售后中心；获取维修售后中心返回的诊断结果；其中，诊断结果携带有目标部件。

可选的，将故障数据发送至维修售后中心的同时，将车辆标识也发送至维修售后中心。其中，车辆标识可使用车辆识别码（Vehicle Identification Number，VIN）、物联网用户身份识别模块（Subscriber IdentityModule，SIM）卡号及车载终端T-BOX的身份识别码（Identity，ID）等，来唯一标识车辆。

需要说明的是，维修售后中心是能够根据车辆标识来配置诊断信息的云服务器，例如，维修售后中心配置需要诊断哪些控制器，需要控制车辆的哪些部件执行哪些检测动作，以及智能车载终端和控制器交互时需要用到的安全算法、配置信息等。其中，诊断信息基于车辆车型建立，同一车型可使用配置相同的诊断信息，诊断信息中用到的车型相关信息，可通过整车厂商的研发生产系统提供的车辆配置清单信息及通过其他渠道和方式来获取。此外，维修售后中心可以通过注册认证的方式来对需要进行故障诊断的车辆进行管理，例如，当车辆在出厂下线后，即可以通过车辆的标识如车辆VIN、物联网SIM卡号及T-BOX的ID等，将车辆在维修售后中心进行注册认证，在注册认证成功后，该车辆即可享受维修售后中心提供的故障诊断服务。

可以理解的是，在本申请实施例中维修售后中心针对每一型号的车辆，在数据库中预先存储好对应车辆及该型号车辆正常工作的标准车辆参数以及各特殊情况所对应的部件数值与处理方法。

这样，通过维修售后中心返回的诊断结果确定出现故障的目标部件，无需增加其他设备，实现了低成本、高效率地对车辆故障进行诊断。

步骤S103、在虚拟空间中对三维车辆模型中的目标部件进行突出显示。

其中，三维车辆模型为车辆的三维模型。

本申请实施例中，该虚拟空间是将现实世界中车辆的组成结构，通过模拟仿真的方式映射到虚拟世界中得到的，同时，现实世界的操作也能够映射到该虚拟空间中。

在一些实施例中，步骤S103之前，上述方法还包括：收集车辆的硬件信息；其中，硬件信息是划分车辆的组成结构得到的车辆零件分布的模型；在虚拟空间对硬件信息立体成像，得到车辆的三维模型。

本申请实施例中，步骤S103可以利用AR技术实现对目标部件进行突出显示，也可以利用VR技术实现对目标部件的突出显示，还可以利用其他技术实现对目标部件的突出显示，本申请实施例对此不做限定。

例如，对目标部件进行突出显示可以是：在虚拟空间中，通过虚拟叠加信息为用户高亮显示目标部件。其中，虚拟叠加信息是利用AR技术将填充了特定颜色的目标部件与三维车辆模型叠加得到的虚拟模型信息。

又如，对目标部件进行突出显示可以是：在车辆的三维模型上叠加文本和选中框的形式突出显示目标部件。参见图2所示，在步骤S102确定目标部件为车辆的右前轮之后，通过文本201和选中框202突出显示目标部件。

本申请实施例提供一种车辆故障的诊断方法，该方法包括：在车辆出现故障的情况下，获取车辆的故障数据；基故障数据对车辆进行故障诊断，得到车辆中出现故障的目标部件；在虚拟空间中对三维车辆模型中的目标部件进行突出显示；其中，三维车辆模型为车辆的三维模型。通过上述技术方案，在车辆出现故障时，能够对车辆进行故障诊断，并且在虚拟空间中的三维车辆模型中突出显示出故障部件，使得用户直观地感受到车辆出现故障的部分，有利于提高车辆的维修效率。

图3是本申请实施例提供的另一种车辆故障的诊断方法的流程示意图。

参见图3所示，步骤103之后，上述车辆故障的诊断方法还可以包括以下步骤。

步骤S301、响应于针对目标部件的触发操作，在虚拟空间中显示目标部件对应的基础信息和建议维修方案。

其中，基础信息包括部件名称、相关参数、用途和使用操作规范。

本申请实施例中，相关参数是用于判断目标部件的性能的基本技术参数。

例如，目标部件为发动机时，相关参数包括：缸数、发动机冷却方式、气门数、缸径×行程、发动机排量、动机功率、发动机转矩、最大功率、最大转矩以及压缩比。

又如，目标部件为车轮，相关参数包括：断面宽、扁平比、子午线结构、轮廓直径、承载指数、最高单后承载以及速度标志。

再如，目标部件为车载空调，相关参数包括温度、湿度、空气的流动性、换气性能以及空气质量。

可选的，该触发操作可以是移动操作或者拖拽操作，该触发操作也可以是点击操作，例如双击或者单击等，本申请实施例对此不做限定。

示例性的，如果目标部件为右前轮，如图4所示，在虚拟空间中显示的内容包括部件名称401、相关参数402、用途403以及使用操作规范404。参见图5所示，目标部件对应的建议维修方案501包括：更换新的轮胎。

这样，通过数字孪生和虚实世界再现技术，在虚拟空间中展现出现故障的目标部件对应的基础信息和建议维修方案，能够给用户带来全新的用车和维修体验，实现了车辆维修的智能化。

可选的，建议维修方案可以包括更换该目标部件或者目标部件中的某个零件，建议维修方案也可以包括自行前往指定维修点或者发起拖车服务，建议维修方案还可以包括上门维修，本申请实施例对此不做限定。

示例性的，如果维修方案可以包括更换该目标部件或者目标部件中的某个零件，车主可以在虚拟空间中的商城进行选购，维修售后中心生成购买订单。

在一些实施例中，步骤S301之后，上述方法还包括：在虚拟空间中显示有针对技术支持人员的呼叫请求选项。其中，该呼叫请求选项用于触发呼叫请求，以使得执行上述方法的智能诊断系统建立与技术支持人员对应的终端进行语音通信的通道。

可选的，步骤S301之后上述方法还包括：响应于针对目标部件的互动操作，调整车辆三维模型和目标部件的角度和位置。这样，车主能够从各个角度查看目标部件的细节。

可选的，步骤S301之后上述方法还包括：响应于针对目标部件的互动操作，在虚拟空间中显示目标部件对应的说明书。

步骤S302、在接收到对建议维修方案的确认操作的情况下，向维修售后中心发送维修订单生成请求，维修订单生成请求携带建议维修方案。

其中，对建议维修方案的确认操作可以是双击操作，对建议维修方案的确认操作也可以是单击操作，对建议维修方案的确认操作还可以是触控车载终端上的确认按钮，本申请实施例对此不做限定。

本申请实施例中，维修售后中心是4S店或者维修点对应的云服务器，维修售后中心可以基于维修订单生成请求中携带的建议维修方案，生成对应的维修订单。

可选的，向维修售后中心发送维修订单生成请求中也携带有车辆标识。

步骤S303、获取维修售后中心返回的维修订单。

其中，维修订单是基于维修订单生成请求生成的。

可选的，维修订单包括订单生成时间、维修点信息、车辆基础信息和建议维修方案；其中，车辆基础信息包括车辆型号和出现故障的目标部件。

这样，能够基于建议维修方案生成维修订单，车主无需另行下单，简化了维修流程，提高了维修效率。

步骤S304、接收维修售后中心发送的维修节点。

其中，维修节点为车辆在维修流程中处于的阶段。

本申请实施例中，维修售后中心按照维修过程不同的阶段，上传维修节点，方便车主通过智能诊断系统查询维修节点。

步骤S305、在虚拟空间中同步显示维修节点。

本申请实施例中，可以在虚拟空间实时查看车辆的维修状态。

可选的，步骤S305之后，上述方法还包括：车辆维修过程结束后，车主可以在虚拟空间完成评价操作。

这样，在虚拟空间实现了车辆维修所需要的功能，比如虚拟车辆信息、后市场服务打通和操作功能，配件预定功能、功能讲解等功能，能够实现车辆维修的智能化。

图6是本申请实施例提供的又一种车辆故障的诊断方法的流程示意图。

参见图6所示，步骤S301之后，上述车辆故障的诊断方法还可以包括以下步骤。

步骤S601、在通过呼叫请求选项触发呼叫请求的情况下，将呼叫请求转发给技术支持人员对应的终端。

其中，呼叫请求用于请求技术支持人员加入虚拟空间。

本申请实施例中，虚拟空间中显示有针对技术支持人员的呼叫请求选项。

可选的，技术支持人员是维修售后中心按照预设的排班计划确定的特定人员，能够确保呼叫请求触发之后，该技术支持人员能够成功加入虚拟空间。

可以理解的是，技术支持人员在加入虚拟空间之后，能够看到跟车主一样的界面，技术支持人员和车主在一个虚拟空间，就像面对面在一起一样，进行各种问题的探讨，最终解决用户的疑问和不解。

这样，将呼叫请求转发给技术支持人员，技术支持人员可以加入虚拟空间，使得车主和技术支持人员沟通问题。

可选的，步骤S601之前上述方法还包括如下的步骤。

维修售后中心接收技术支持人员在自身终端发起的注册请求；其中，注册请求携带有技术支持人员的排班时间；维修售后中心为技术支持人员注册虚拟身份，并将排班时间录入。

这样，在技术支持人员在自身终端上注册之后，可以生成虚拟身份，提供了将虚拟空间中的呼叫请求转发到技术支持人员对应的终端中的基础。

步骤S602、在技术支持人员加入虚拟空间的情况下，建立与技术支持人员对应的终端进行语音通信的通道。

可以理解的是，本申请实施例中建立用于语音通信的通道之后，车主可以通过该通道和技术支持人员讨论步骤S301得到的建议维修方案，咨询目标部件相关的问题。在技术支持人员为车主答疑解惑之后，车主对建议维修方案进行确认。

可选的，针对每个智能诊断系统对应的虚拟空间，为了方便数据传输，维修售后中心为其分配对应的渠道ID；为了保证数据传输的安全性，每个渠道传输的数据都通过密钥加密；维修售后中心为在各个虚拟空间分配对应的渠道ID和密钥后，将这些渠道ID和密钥存储至自身内存。当技术支持人员加入虚拟空间后，可以基于该渠道ID和密钥建立语音通道，方便车载和技术支持人员进行语音通信。

这样，车主和技术支持人员能够在虚拟空间中直接进行语音沟通，共同商讨维修方案，简化了车辆维修的流程，实现了车辆维修的智能化。

步骤S603、响应于技术支持人员针对目标部件的互动操作，调整目标部件的角度和位置。

其中，互动操作可以是点击操作，互动操作还可以是拖拽操作，本申请实施例对此不做限定。

可选的，技术支持人员还可以利用VR设备，在虚拟空间中对三维车辆模型进行维修操作演示。

可选的，步骤S603之后，上述方法还可以包括：获取技术人员针对目标部件进行互动时产生的交互数据；根据三维车辆模型和交互数据，生成三维演示动画；将三维演示动画存储在智能诊断系统的内存中。这样，将技术支持人员对目标部件的演示存储在智能诊断系统中，方便车主前往维修点后向维修人员解释车辆的故障情况。

通过上述技术方案，在显示建议维修方案之后，车主还能够呼叫技术支持人员，与技术支持人员语音沟通维修方案，实现了远程答疑解惑，提高了维修效率，优化了车主的维修体验。

需要说明的是，上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请的方法实施例。

图7是本申请实施例提供的一种车辆故障的诊断装置的结构示意图。

参照图7所示，该车辆故障的诊断装置700可以应用于图1对应的实施例提供的方法，该车辆故障的诊断装置700包括如下的模块。

获取模块701，用于在车辆出现故障的情况下，获取所述车辆的故障数据；处理模块702，用于基于所述故障数据对所述车辆进行故障诊断，得到所述车辆中出现故障的目标部件；显示模块703，用于在虚拟空间中对三维车辆模型中的所述目标部件进行突出显示；其中，所述三维车辆模型为所述车辆的三维模型。

在本申请其他实施例中，基于上述方案，处理模块702，还用于：通过车载诊断系统对故障数据进行分析，确定目标部件；或者，将故障数据发送至维修售后中心；获取维修售后中心返回的诊断结果；其中，诊断结果携带有目标部件。

在本申请其他实施例中，基于上述方案，显示模块703，还用于：响应于针对目标部件的触发操作，在虚拟空间中显示目标部件对应的基础信息和建议维修方案；其中，基础信息包括部件名称、相关参数、用途和使用操作规范。

在本申请其他实施例中，基于上述方案，处理模块702，还用于：在接收到对建议维修方案的确认操作的情况下，向维修售后中心发送维修订单生成请求，维修订单生成请求携带建议维修方案；获取模块701，还用于获取维修售后中心返回的维修订单；其中，维修订单是基于维修订单生成请求生成的。

在本申请其他实施例中，基于上述方案，处理模块702，还用于接收维修售后中心发送的维修节点；其中，维修节点为车辆在维修流程中处于的阶段；显示模块703，还用于在虚拟空间中同步显示维修节点。

在本申请其他实施例中，基于上述方案，处理模块702，还用于：在通过呼叫请求选项触发呼叫请求的情况下，将呼叫请求转发给技术支持人员对应的终端；其中，呼叫请求用于请求技术支持人员加入虚拟空间。

在本申请其他实施例中，基于上述方案，处理模块702，还用于：在技术支持人员加入虚拟空间的情况下，建立与技术支持人员对应的终端进行语音通信的通道；响应于技术支持人员针对目标部件的互动操作，调整目标部件的角度和位置。

需要说明的是：上述实施例提供的车辆故障的诊断装置在车辆故障的诊断时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将计算机设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的车辆故障的诊断装置与车辆故障的诊断方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图8是本申请实施例提供的一种车辆的结构示意图。

参照图8所示，该车辆800可以应用于图1对应的实施例提供的方法，该车辆800包括：处理器801、存储器802和通信总线803，其中：通信总线803用于实现处理器801和存储器802之间的通信连接；处理器801用于执行存储器802中存储的通信交互程序，以实现如下的步骤。

在车辆出现故障的情况下，获取车辆的故障数据；基于故障数据对车辆进行故障诊断，得到车辆中出现故障的目标部件；在虚拟空间中对三维车辆模型中的目标部件进行突出显示；其中，三维车辆模型为车辆的三维模型。

本申请实施例提供的一种车辆，通过在车辆出现故障的情况下，获取车辆的故障数据；基于故障数据对车辆进行故障诊断，得到车辆中出现故障的目标部件；在虚拟空间中对三维车辆模型中的目标部件进行突出显示；其中，三维车辆模型为车辆的三维模型；通过上述技术方案，在车辆出现故障时，能够对车辆进行故障诊断，并且在虚拟空间中的三维车辆模型中突出显示出故障部件，使得用户直观地感受到车辆出现故障的部分，有利于提高车辆的维修效率。

本申请的实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有一个或者多个程序，该一个或者多个程序可被一个或者多个处理器执行，以实现如图1对应的实施例提供的车辆故障的诊断方法中的实现过程，此处不再赘述。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

上述计算机存储介质/存储器可以是只读存储器（Read OnlyMemory，ROM）、可编程只读存储器（ProgrammableRead-Only Memory，PROM）、可擦除可编程只读存储器（ErasableProgrammable Read-Only Memory，EPROM）、电可擦除可编程只读存储器（Electrically Erasable Programmable Read-Only Memory，EEPROM）、磁性随机存取存储器（FerromagneticRandom Access Memory，FRAM）、快闪存储器（FlashMemory）、磁表面存储器、光盘、或只读光盘（Compact Disc Read-Only Memory，CD-ROM）等存储器；也可以是包括上述存储器之一或任意组合的各种终端，如移动电话、计算机、平板设备、个人数字助理等。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”或“本申请实施例”或“前述实施例”或“一些实施例”或“一些实施方式”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”或“本申请实施例”或“前述实施例”或“一些实施例”或“一些实施方式”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器（Read Only Memory，ROM）、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机、服务器、或者网络设备等）执行本申请各个实施例方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

值得注意的是，本申请实施例中的附图只是为了说明各个器件在终端设备上的示意位置，并不代表在终端设备中的真实位置，各器件或各个区域的真实位置可根据实际情况（例如，终端设备的结构）做出相应改变或偏移，并且，图中的终端设备中不同部分的比例并不代表真实的比例。

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

Claims (10)

1.一种车辆故障的诊断方法，其特征在于，所述方法包括：

在车辆出现故障的情况下，获取所述车辆的故障数据；

基于所述故障数据对所述车辆进行故障诊断，得到所述车辆中出现故障的目标部件；

在虚拟空间中对三维车辆模型中的所述目标部件进行突出显示；其中，所述三维车辆模型为所述车辆的三维模型。

2.根据权利要求1所述的车辆故障的诊断方法，其特征在于，所述基于所述故障数据对所述车辆进行故障诊断，得到所述车辆中出现故障的目标部件，包括：

通过车载诊断系统对所述故障数据进行分析，确定所述目标部件；

或者，将所述故障数据发送至维修售后中心；获取所述维修售后中心返回的诊断结果；其中，所述诊断结果携带有所述目标部件。

3.根据权利要求1所述的车辆故障的诊断方法，其特征在于，所述在虚拟空间中对三维车辆模型中的所述目标部件进行突出显示之后，所述方法还包括：

响应于针对所述目标部件的触发操作，在所述虚拟空间中显示所述目标部件对应的基础信息和建议维修方案；其中，所述基础信息包括部件名称、相关参数、用途和使用操作规范。

4.根据权利要求3所述的车辆故障的诊断方法，其特征在于，所述响应于针对所述目标部件的触发操作，在所述虚拟空间中显示所述目标部件对应的基础信息和建议维修方案之后，所述方法还包括：

在接收到对所述建议维修方案的确认操作的情况下，向维修售后中心发送维修订单生成请求，所述维修订单生成请求携带所述建议维修方案；

获取所述维修售后中心返回的维修订单；其中，所述维修订单是基于所述维修订单生成请求生成的。

5.根据权利要求4所述的车辆故障的诊断方法，其特征在于，所述获取所述维修售后中心返回的维修订单之后，所述方法还包括：

接收所述维修售后中心发送的维修节点；其中，所述维修节点为所述车辆在维修流程中处于的阶段；

在所述虚拟空间中同步显示所述维修节点。

6.根据权利要求1所述的车辆故障的诊断方法，其特征在于，所述虚拟空间中显示有针对技术支持人员的呼叫请求选项，所述在虚拟空间中对三维车辆模型中的所述目标部件进行突出显示之后，所述方法还包括：

在通过所述呼叫请求选项触发呼叫请求的情况下，将所述呼叫请求转发给所述技术支持人员对应的终端；其中，所述呼叫请求用于请求所述技术支持人员加入所述虚拟空间。

7.根据权利要求6所述的车辆故障的诊断方法，其特征在于，所述将所述呼叫请求转发给所述技术支持人员对应的终端之后，所述方法还包括下述至少一项：

在所述技术支持人员加入所述虚拟空间的情况下，建立与所述技术支持人员对应的终端进行语音通信的通道；

响应于所述技术支持人员针对所述目标部件的互动操作，调整所述目标部件的角度和位置。

8.一种车辆故障的诊断装置，其特征在于，包括：

获取模块，用于在车辆出现故障的情况下，获取所述车辆的故障数据；

处理模块，用于基于所述故障数据对所述车辆进行故障诊断，得到所述车辆中出现故障的目标部件；

显示模块，用于在虚拟空间中对三维车辆模型中的所述目标部件进行突出显示；其中，所述三维车辆模型为所述车辆的三维模型。

9.一种车辆，其特征在于，包括：

存储器，用于存储可执行程序代码；

处理器，用于从所述存储器中调用并运行所述可执行程序代码，使得所述车辆执行如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序被执行时，实现如权利要求1至7中任一项所述的方法。

Images