CN115185252A - 基于汽车故障灯的远程诊断方法及装置 - Google Patents

Abstract

本申请涉及一种基于汽车故障灯的远程诊断方法及装置，其中，方法包括：接收用户在车辆提示故障灯时发送的远程故障诊断请求；获取在故障发生之前预设时长的历史数据，并根据历史数据识别车辆的至少一个故障灯的每个故障灯对应的故障原因；以及匹配每个故障灯对应的故障原因的故障等级，并基于每个故障灯对应的故障原因和/或故障等级生成对应的维修建议。本申请可以基于故障灯和故障发生前的历史数据，完成故障类型识别、故障原因判断、故障风险分级和故障维修建议，实现快速的故障检测快、准确的故障定位准，从而提高故障维修效率，增加用户的使用体验。

Description

基于汽车故障灯的远程诊断方法及装置

技术领域

本申请涉及汽车故障远程诊断技术领域，特别涉及一种基于汽车故障灯的远程诊断方法及装置。

背景技术

随着汽车在国内的普及，汽车的功能日趋复杂，相应的，用户在驾驶汽车过程中遇到的故障也随之增多，对于缺少汽车专业知识和故障维修经验的大众用户来说，在汽车故障灯示警后，普遍存在着以下几个问题：一是不清楚故障灯含义，二是不明白故障发生原因，三是不确定是否影响驾驶安全，四是不知道是否需要及时送修。因此，当故障灯出现后，若能够快速准确地定位故障原因并给出针对性的维修建议，将有效地改善用户维修体验。

相关技术中，用户可以利用移动终端扫描与故障灯对应的二维码或拍摄故障灯的图像，通过服务器获取与二维码或图像对应的故障信息，进而根据故障信息获取车辆的故障解决方案，服务器将故障解决方案发送至车载终端和/或与车载终端关联的移动终端。

然而，相关技术中依赖移动端对故障灯进行扫描和拍照，在复杂的光线环境下有一定几率误识别或漏识别，且缺少对故障误报情况的识别与解决，对高风险故障的解决方案缺少人工审核的环节，可能会对用户产生误导而影响用户体验，有待改进。

发明内容

本申请提供一种基于汽车故障灯的远程诊断方法及装置，以解决相关技术中，在复杂光线环境下故障灯识别困难，缺乏对故障误判的应对，同时对高风险故障的解决方案缺少人工审核的环节的技术问题。

本申请第一方面实施例提供一种基于汽车故障灯的远程诊断方法，包括以下步骤：接收用户在车辆提示故障灯时发送的远程故障诊断请求；获取在故障发生之前预设时长的历史数据，并根据所述历史数据识别所述车辆的至少一个故障灯的每个故障灯对应的故障原因；以及匹配所述每个故障灯对应的故障原因的故障等级，并基于所述每个故障灯对应的故障原因和/或所述故障等级生成对应的维修建议。

根据上述技术手段，本申请实施例可以在车辆提示故障灯时，接收用户发送的远程故障诊断请求，并获取在故障发生之前的历史数据，从而识别所述车辆的每个故障灯对应的故障原因，匹配对应的故障等级，生成对应的维修建议，完成故障类型识别、故障原因判断、故障风险分级和故障维修建议，实现故障检测快、故障定位准、故障维修少，对普通用户而言，解决了对未知故障发生时的困惑和无助感，对维修人员而言，通过提供系统预诊断的故障原因能够减少检测时间，更快定位故障原因。

可选地，在本申请的一个实施例中，在基于所述每个故障灯对应的故障原因和/或所述故障等级生成对应的维修建议之前，还包括：判断所述故障等级是否大于或等于预设等级；如果所述故障等级大于或等于所述预设等级，则提示人工审核建议。

根据上述技术手段，本申请实施例可以在故障等级较大，即故障较为复杂、难以处理时，通过人工审核提供维修建议，从而增加故障检测的准确性和故障维修的效率。

可选地，在本申请的一个实施例中，还包括：采集所述用户的反馈意见；根据所述反馈意见优化相应算法模型。

根据上述技术手段，本申请实施例可以根据用户反馈进行模型优化，从而提高用户的使用体验。

可选地，在本申请的一个实施例中，还包括：根据所述反馈意见识别所述用户的实际需求；根据所述实际需求生成远程清理故障灯的指令和/或联系最近维修站点的指令。

根据上述技术手段，本申请实施例可以基于用户的实际需求，生成相应的指令，进而提高用户的使用体验。

可选地，在本申请的一个实施例中，所述历史数据包括车况数据、环境数据、用户反馈数据和/或故障灯信号。

根据上述技术手段，本申请实施例可以通过车况数据、环境数据、用户反馈数据和/或故障灯信号，从而识别故障灯对应的故障原因，便于后续进行故障原因判断、故障风险分级和故障维修建议。

本申请第二方面实施例提供一种基于汽车故障灯的远程诊断装置，包括：接收模块，用于接收用户在车辆提示故障灯时发送的远程故障诊断请求；获取模块，用于获取在故障发生之前预设时长的历史数据，并根据所述历史数据识别所述车辆的至少一个故障灯的每个故障灯对应的故障原因；以及诊断模块，用于匹配所述每个故障灯对应的故障原因的故障等级，并基于所述每个故障灯对应的故障原因和/或所述故障等级生成对应的维修建议。

可选地，在本申请的一个实施例中，还包括：判断模块，用于判断所述故障等级是否大于或等于预设等级；人工模块，用于当所述故障等级大于或等于所述预设等级时，提示人工审核建议。

可选地，在本申请的一个实施例中，还包括：采集模块，用于采集所述用户的反馈意见；优化模块，用于根据所述反馈意见优化相应算法模型。

可选地，在本申请的一个实施例中，还包括：识别模块，用于根据所述反馈意见识别所述用户的实际需求；生成模块，用于根据所述实际需求生成远程清理故障灯的指令和/或联系最近维修站点的指令。

可选地，在本申请的一个实施例中，所述历史数据包括车况数据、环境数据、用户反馈数据和/或故障灯信号。

本申请第三方面实施例提供一种车辆，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如上述实施例所述的基于汽车故障灯的远程诊断方法。

本申请第四方面实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储计算机程序，该程序被处理器执行时实现如上的基于汽车故障灯的远程诊断方法。

本申请实施例的有益效果：

(1)本申请实施例可以基于车辆故障灯及故障发生前的历史数据，实现故障类型识别、故障原因判断、故障风险分级和故障维修建议，进而实现对车辆的远程故障诊断及维修建议；

(2)本申请实施例可以基于用户指令进行远程故障诊断及维修建议，并针对用户反馈实现算法模型优化，从而解决了用户对未知故障发生时的困惑和无助感，且增加了针对性，更能满足用户需求，提高用户的使用体验；

(3)本申请实施例可以在故障等级较高时，进行人工审核，从而增加故障检测的准确性以及故障维修建议的可靠性。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本申请实施例提供的一种基于汽车故障灯的远程诊断方法的流程图；

图2为根据本申请一个实施例的基于汽车故障灯的远程诊断方法的原理示意图；

图3为根据本申请一个实施例的基于汽车故障灯的远程诊断方法的流程图；

图4为根据本申请实施例提供的一种基于汽车故障灯的远程诊断装置的结构示意图；

图5为根据本申请实施例提供的车辆的结构示意图。

其中，10-基于汽车故障灯的远程诊断装置；100-接收模块、200-获取模块、300-诊断模块。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的基于汽车故障灯的远程诊断方法及装置。针对上述背景技术中心提到的相关技术中，在复杂光线环境下故障灯识别困难，缺乏对故障误判的应对，同时对高风险故障的解决方案缺少人工审核的环节的技术问题，本申请提供了一种基于汽车故障灯的远程诊断方法，在该方法中，可以在车辆提示故障灯时，接收用户发送的远程故障诊断请求，并获取在故障发生之前的历史数据，从而识别所述车辆的每个故障灯对应的故障原因，匹配对应的故障等级，生成对应的维修建议，能够完成故障类型识别、故障原因判断、故障风险分级和故障维修建议，实现故障检测快、故障定位准、故障维修少，对普通用户而言，解决了对未知故障发生时的困惑和无助感，对维修人员而言，通过提供系统预诊断的故障原因能够减少检测时间，更快定位故障原因。由此，解决了相关技术中，在复杂光线环境下故障灯识别困难，缺乏对故障误判的应对，同时对高风险故障的解决方案缺少人工审核的环节的技术问题。

具体而言，图1为本申请实施例所提供的一种基于汽车故障灯的远程诊断方法的流程示意图。

如图1所示，该基于汽车故障灯的远程诊断方法包括以下步骤：

在步骤S101中，接收用户在车辆提示故障灯时发送的远程故障诊断请求。

在实际执行过程中，当车辆的故障灯出现后，用户可以选择在设备端，如车载终端或与车辆相关联的移动终端，申请进行远程故障诊断，无需用户自行查阅说明书，寻找故障灯含义，节约用户查找并理解说明书的时间，缓解用户面对未知故障的紧张情绪，从而提高用户的使用体验。

在步骤S102中，获取在故障发生之前预设时长的历史数据，并根据历史数据识别车辆的至少一个故障灯的每个故障灯对应的故障原因。

作为一种可能实现的方式，本申请实施例可以在接收到远程故障诊断请求后，获取在车辆发生故障前一段时间的历史数据，进而将历史数据与车辆正常行驶数据对比，从而查找出历史数据中的异常，识别车辆的至少一个故障灯的每个故障灯对应的故障原因，包括但不限于规则算法和机器学习算法，组合判断得到最有可能导致故障发生的Top N原因，实现基于故障灯和历史数据的故障检测，此外，当历史数据中不存在异常数据时，可以判断为故障灯的误报，即故障灯发生故障，由此可以降低故障误报的概率。

需要注意的是，预设时长可以由本领域技术人员根据实际情况进行相应设置，在此不做具体限制。

在步骤S103中，匹配每个故障灯对应的故障原因的故障等级，并基于每个故障灯对应的故障原因和/或故障等级生成对应的维修建议。

进一步地，本申请实施例可以匹配每个故障灯对应的故障原因的故障等级，其中故障等级可以根据故障维修难易程度划分，也可以根据故障严重程度划分，并基于每个故障灯对应的故障原因和/或故障等级生成对应的维修建议，实现故障类型识别、故障原因判断、故障风险分级和故障维修建议，便于维修人员通过提供系统预诊断的故障原因能够减少检测时间，更快定位故障原因。

可选地，在本申请的一个实施例中，在基于每个故障灯对应的故障原因和/或故障等级生成对应的维修建议之前，还包括：判断故障等级是否大于或等于预设等级；如果故障等级大于或等于预设等级，则提示人工审核建议。

举例而言，本申请实施例可以将故障原因进行风险分级，以4级为例，1级和2级可以由本申请实施例自动给出预设的针对性维修建议给用户，3级和4级转由人工进行复核后输出维修建议给用户，超过4级，则可以通过远程求助，呼叫附近维修人员提供维修帮助，从而增加故障检测的准确性和故障维修的效率。

可选地，在本申请的一个实施例中，还包括：采集用户的反馈意见；根据反馈意见优化相应算法模型。

在实际执行过程中，本申请实施例可以利用云端保存每次用于故障诊断的车况数据和用户对检测结果的反馈数据，形成数据闭环，用于算法迭代优化，从而提高用户的使用体验。

可选地，在本申请的一个实施例中，还包括：根据反馈意见识别用户的实际需求；根据实际需求生成远程清理故障灯的指令和/或联系最近维修站点的指令。

举例而言，若用户的反馈意见为故障已解决，本申请实施例则可以根据用户需求，将故障灯恢复成原始状态，若用户反馈意见为故障未解决，本申请实施例可以重新匹配故障原因，按照故障可能性排序依次筛选，若用户反馈意见为不存在故障维修方案，或当前无法进行故障维修，本申请实施例可以联系最近维修站点提供维修服务。

可选地，在本申请的一个实施例中，历史数据包括车况数据、环境数据、用户反馈数据和/或故障灯信号。

可以理解的是，本申请实施例可以通过车况数据、环境数据、用户反馈数据和/或故障灯信号，从而识别故障灯对应的故障原因，便于后续进行故障原因判断、故障风险分级和故障维修建议。

结合图2和图3所示，以一个实施例对本申请实施例的基于汽车故障灯的远程诊断方法进行详细阐述。

如图2所示，本申请实施例可以分为三个部分：设备端、云端系统和数据仓库。

其中，设备端可以是车端的仪表盘或移动端的APP或小程序，当车机屏幕或仪表盘出现故障灯提示后，主要完成三方面的功能：第一，向云端申请进行远程故障诊断；第二，展示识别结果、故障原因及维修建议等信息；第三，收集并上传用户反馈数据。

云端系统由两部分组成：诊断后台和算法后台。诊断后台包含了故障识别、故障诊断和故障分级三种模块，输入待检测的车端数据，输出故障的类别、原因及维修建议。算法后台包含了算法训练平台和算法部署平台，完成算法的训练、迭代和部署，提供核心的算法能力支持。

数据仓库里面保存了用于算法训练的故障灯数据集和用户反馈数据(如识别是否准确，维修建议是否有用等)，和用于故障诊断的车况数据和环境数据等。

上述实施例的应用过程可以如图3所示：当车机仪表盘上出现故障灯后，用户通过设备端进行故障确认，然后申请进行故障远程诊断。

以移动端为例，用户打开与车机配套的APP，进行一键“远程诊断”操作，诊断后台在收到请求后，读取故障车辆历史数据发送给故障识别模块，并保存进数据仓库，用于下一次算法的迭代训练。

车端可能会同时出现多个故障灯，也就是同时存在着多个故障，故障之间可能相互独立，也可能是由相同原因导致，因此，针对每种故障，需要进行综合诊断以判断是否是不同的故障原因导致的，利用诊断算法池，对故障灯发生前的车况数据、环境数据、DTC(Diagnostic Trouble Code，诊断故障代码)故障码数据等云端历史数据作为算法输入，同时使用多种算法进行组合判断，得到最有可能导致当前一个或多个故障发生的Top N原因。

对得到的诊断原因进行故障分级，利用专家经验，预先对各种故障原因进行危害等级划分和对应的维修建议，故障分为4级：1级，无故障，属于异常原因导致误报；2级，低级，可授权用户进行处理；3级，中级，不影响正常驾驶，提示用户近期进行维修保养；4级，高级，驾驶影响安全，需要尽快维修。故障分级模块对所有有可能导致故障的原因进行等级判断，若存在着中级及以上的故障原因，则提交给维修人员人工进行审核，再输出维修建议，其它情况则由系统自动给出维修建议。最后诊断后台将识别到的故障类型、对应的故障原因和维修建议汇总后返回给设备端。整个诊断后台中，除了复核中高风险故障需要人工参与外，其余时间均采用自动流水线模式，故障识别、故障诊断、故障分级串行执行，多个故障同时诊断采用并行处理。

设备段展示诊断结果并收集用户的反馈意见，包括但不限于：是否申请远程清理故障灯；是否需要联系最近维修站点；维修建议是否解决了实际问题等。收集和上传用户的反馈意见，一方面完成数据采集的闭环，用于持续提升算法性能，另一方面用于分析用户需求，持续改善用户的维修体验。

算法后台提供了算法训练、部署和监控功能，定期利用新增的数据进行训练，得到迭代优化的算法模型，并上线至算法部署平台，完成算法性能的持续提升，同时逻辑结构上与诊断后台进行分离，便于监控和管理。

根据本申请实施例提出的基于汽车故障灯的远程诊断方法，可以在车辆提示故障灯时，接收用户发送的远程故障诊断请求，并获取在故障发生之前的历史数据，从而识别所述车辆的每个故障灯对应的故障原因，匹配对应的故障等级，生成对应的维修建议，能够完成故障类型识别、故障原因判断、故障风险分级和故障维修建议，实现故障检测快、故障定位准、故障维修少，对普通用户而言，解决了对未知故障发生时的困惑和无助感，对维修人员而言，通过提供系统预诊断的故障原因能够减少检测时间，更快定位故障原因。由此，解决了相关技术中，在复杂光线环境下故障灯识别困难，缺乏对故障误判的应对，同时对高风险故障的解决方案缺少人工审核的环节的技术问题。

其次参照附图描述根据本申请实施例提出的基于汽车故障灯的远程诊断装置。

图4是本申请实施例的基于汽车故障灯的远程诊断装置的方框示意图。

如图4所示，该基于汽车故障灯的远程诊断装置10包括：接收模块100、获取模块200和诊断模块300。

具体地，接收模块100，用于接收用户在车辆提示故障灯时发送的远程故障诊断请求。

获取模块200，用于获取在故障发生之前预设时长的历史数据，并根据历史数据识别车辆的至少一个故障灯的每个故障灯对应的故障原因。

诊断模块300，用于匹配每个故障灯对应的故障原因的故障等级，并基于每个故障灯对应的故障原因和/或故障等级生成对应的维修建议。

可选地，在本申请的一个实施例中，还包括：判断模块，用于判断故障等级是否大于或等于预设等级；人工模块，用于当故障等级大于或等于预设等级时，提示人工审核建议。

可选地，在本申请的一个实施例中，基于汽车故障灯的远程诊断装置10还包括：采集模块。

其中，采集模块，用于采集用户的反馈意见；优化模块，用于根据反馈意见优化相应算法模型。

可选地，在本申请的一个实施例中，基于汽车故障灯的远程诊断装置10还包括：识别模块和生成模块。

其中，识别模块，用于根据反馈意见识别用户的实际需求。

生成模块，用于根据实际需求生成远程清理故障灯的指令和/或联系最近维修站点的指令。

可选地，在本申请的一个实施例中，历史数据包括车况数据、环境数据、用户反馈数据和/或故障灯信号。

需要说明的是，前述对基于汽车故障灯的远程诊断方法实施例的解释说明也适用于该实施例的基于汽车故障灯的远程诊断装置，此处不再赘述。

根据本申请实施例提出的基于汽车故障灯的远程诊断装置，可以在车辆提示故障灯时，接收用户发送的远程故障诊断请求，并获取在故障发生之前的历史数据，从而识别所述车辆的每个故障灯对应的故障原因，匹配对应的故障等级，生成对应的维修建议，能够完成故障类型识别、故障原因判断、故障风险分级和故障维修建议，实现故障检测快、故障定位准、故障维修少，对普通用户而言，解决了对未知故障发生时的困惑和无助感，对维修人员而言，通过提供系统预诊断的故障原因能够减少检测时间，更快定位故障原因。由此，解决了相关技术中，在复杂光线环境下故障灯识别困难，缺乏对故障误判的应对，同时对高风险故障的解决方案缺少人工审核的环节的技术问题。

图5为本申请实施例提供的车辆的结构示意图。该车辆可以包括：

存储器501、处理器502及存储在存储器501上并可在处理器502上运行的计算机程序。

处理器502执行程序时实现上述实施例中提供的基于汽车故障灯的远程诊断方法。

进一步地，车辆还包括：

通信接口503，用于存储器501和处理器502之间的通信。

存储器501，用于存放可在处理器502上运行的计算机程序。

存储器501可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

如果存储器501、处理器502和通信接口503独立实现，则通信接口503、存储器501和处理器502可以通过总线相互连接并完成相互间的通信。总线可以是工业标准体系结构(Industry Standard Architecture，简称为ISA)总线、外部设备互连(PeripheralComponent，简称为PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture，简称为EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选地，在具体实现上，如果存储器501、处理器502及通信接口503，集成在一块芯片上实现，则存储器501、处理器502及通信接口503可以通过内部接口完成相互间的通信。

处理器502可能是一个中央处理器(Central Processing Unit，简称为CPU)，或者是特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上的基于汽车故障灯的远程诊断方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或N个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“N个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或N个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或N个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，N个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种基于汽车故障灯的远程诊断方法，其特征在于，包括以下步骤：

接收用户在车辆提示故障灯时发送的远程故障诊断请求；

获取在故障发生之前预设时长的历史数据，并根据所述历史数据识别所述车辆的至少一个故障灯的每个故障灯对应的故障原因；以及

匹配所述每个故障灯对应的故障原因的故障等级，并基于所述每个故障灯对应的故障原因和/或所述故障等级生成对应的维修建议。

2.根据权利要求1所述的方法，其特征在于，在基于所述每个故障灯对应的故障原因和/或所述故障等级生成对应的维修建议之前，还包括：

判断所述故障等级是否大于或等于预设等级；

如果所述故障等级大于或等于所述预设等级，则提示人工审核建议。

3.根据权利要求1所述的方法，其特征在于，还包括：

采集所述用户的反馈意见；

根据所述反馈意见优化相应算法模型。

4.根据权利要求3所述的方法，其特征在于，还包括：

根据所述反馈意见识别所述用户的实际需求；

根据所述实际需求生成远程清理故障灯的指令和/或联系最近维修站点的指令。

5.根据权利要求1-4任一所述的方法，其特征在于，所述历史数据包括车况数据、环境数据、用户反馈数据和/或故障灯信号。

6.一种基于汽车故障灯的远程诊断装置，其特征在于，包括：

接收模块，用于接收用户在车辆提示故障灯时发送的远程故障诊断请求；

获取模块，用于获取在故障发生之前预设时长的历史数据，并根据所述历史数据识别所述车辆的至少一个故障灯的每个故障灯对应的故障原因；以及

诊断模块，用于匹配所述每个故障灯对应的故障原因的故障等级，并基于所述每个故障灯对应的故障原因和/或所述故障等级生成对应的维修建议。

7.根据权利要求6所述的装置，其特征在于，还包括：

判断模块，用于判断所述故障等级是否大于或等于预设等级；

人工模块，用于当所述故障等级大于或等于所述预设等级时，提示人工审核建议。

8.根据权利要求6所述的装置，其特征在于，还包括：

采集模块，用于采集所述用户的反馈意见；

优化模块，用于根据所述反馈意见优化相应算法模型。

9.一种车辆，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如权利要求1-5任一项所述的基于汽车故障灯的远程诊断方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行，以用于实现如权利要求1-5任一项所述的基于汽车故障灯的远程诊断方法。

Images