CN110889513A - 维修保养的监管方法及车辆 - Google Patents

Abstract

本申请涉及一种维修保养的监管方法，所述方法应用于车辆或服务器，所述方法包括获取并存储车辆最后一次进行维修保养的时间；判断是否满足再次进行维修保养的条件，再次进行维修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程；若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息。本申请还涉及一种维修保养的监管方法及车辆。本申请的维修保养的监管方法及车辆能自动提醒用户进行维修保养，避免车辆错过维修保养时机，提高了车辆的使用寿命和行车安全性。

Description

维修保养的监管方法及车辆

技术领域

本申请涉及物联网技术领域，具体涉及一种维修保养的监管方法及车辆。

背景技术

车辆在运用过程中，零部件会逐渐磨耗、腐蚀和损伤，为使车辆经常处于质量良好状态，确保行车安全并延长车辆使用寿命，必须对车辆进行各种维修和保养工作。

按维修保养内容分为定期维修保养和日常维修保养两类。所谓定期维修保养，是指对运用中的车辆，每隔一定时间或每行驶一定里程，进行一次具有一定内容的维修保养工作。定期维修保养能有计划地使车辆恢复运用功能，保持良好的技术状态，并保证在到达下一个定期检修以前，不出现重大故障。但用户常常忘记对车辆进行维修保养，严重影响了车辆的使用寿命和行车安全。

因此，需提供一种维修保养的监管方法，能适时提醒用户进行维修保养。

发明内容

本申请的目的在于，提供一种维修保养的监管方法及车辆，其可以解决上述技术问题，能自动提醒用户进行维修保养，避免车辆错过维修保养时机，从而提高车辆的使用寿命和行车安全性。

为解决上述技术问题，本申请提供一种维修保养的监管方法，所述方法应用于车辆或服务器，所述方法包括获取并存储车辆最后一次进行维修保养的时间；判断是否满足再次进行维修保养的条件，再次进行维修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程；若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息。

在一实施方式中，所述方法还包括若不满足再次进行维修保养的条件，则返回判断是否满足再次进行维修保养的条件的步骤，和/或使得终端展示再次进行维修保养的剩余时间或剩余里程。

在一实施方式中，若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息的步骤之后包括使得所述终端展示至少一条维修保养推荐店铺信息，每条维修保养推荐店铺信息均包括店铺地点信息和/或店铺工作人员信息和/或可预约时间信息中的至少一项；在所述终端接收到关于一条维修保养推荐店铺信息的确认指令时，发送所述车辆的停车位置信息和/或车辆的开锁验证码至与所述确认指令对应的维修保养推荐店铺的通信地址。

在一实施方式中，使得所述终端展示维修保养推荐店铺信息的步骤之前包括获取根据所述车辆的停车位置的距离和/或大众评分进行加权计分后得分排在前n位的维修保养店铺信息，以生成所述维修保养推荐店铺信息，其中，n为预设的大于或等于1的正整数；将所述维修保养推荐店铺信息发送至所述终端。

在一实施方式中，所述维修保养的监管方法还应用于终端；其中，发送所述车辆的停车位置信息和/或车辆的开锁验证码至与所述确认指令对应的维修保养推荐店铺的通信地址的步骤之后包括所述终端展示车辆的实时地理位置信息和/或维修保养状态信息；和/或在所述车辆的实时地理位置偏离所述车辆的停车位置与此条维修保养推荐店铺信息的店铺地点的导航路线时，所述终端展示报警提醒信息。

在一实施方式中，所述方法还包括在获取到所述车辆的配件的维修通知信息时，获取所述车辆的配件的维修日志，所述车辆的配件的维修日志包括维修时间、维修店铺、维修工作人员中的至少一项。

在一实施方式中，在获取到所述车辆的配件的维修通知信息时，获取所述车辆的配件的维修日志的步骤之后还包括获取所述车辆的配件的运行参数信息，以将所述运行参数信息与根据大数据学习得到的运行参数信息进行比对，从而检测所述车辆的配件是否正常运行；在所述车辆的配件未正常运行时，使得所述终端展示所述车辆的配件的维修日志。

本申请还提供一种维修保养的监管方法，所述方法应用于车辆、服务器及终端之间，所述方法包括所述服务器接收并存储所述车辆或所述终端发送的车辆最后一次进行维修保养的时间；所述服务器判断是否满足再次进行维修保养的条件，再次进行维续修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程；若满足再次进行维修保养的条件，则所述终端展示维修保养提醒信息。

本申请还提供一种车辆，所述车辆包括存储器和处理器；所述存储器用于存储可执行程序代码；所述处理器用于调用所述存储器中的可执行程序代码，以执行如下步骤获取并存储车辆最后一次进行维修保养的时间；判断是否满足再次进行维修保养的条件，再次进行维修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程；若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息。

在一实施方式中，所述终端为车载终端或移动终端。

申请的维修保养的监管方法及车辆能自动提醒用户进行维修保养，避免车辆错过维修保养时机，提高了车辆的使用寿命和行车安全性。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举较佳实施例，并配合附图,详细说明如下。

附图说明

图1为本申请第一实施例的维修保养的监管方法的流程示意图。

图2为本申请第二实施例的维修保养的监管方法的流程示意图。

图3为本申请如图2的维修保养的监管方法的应用环境示意图。

图4为本申请第三实施例的车辆的结构示意图。

具体实施方式

为更进一步阐述本申请为达成预定申请目的所采取的技术手段及功效,以下结合附图及较佳实施例，对依据本申请智能车辆及其维修保养的监管方法的具体实施方式、方法、步骤、结构、特征及其效果，详细说明如下。

有关本申请的前述及其它技术内容、特点及功效,在以下配合参考图式的较佳实施例的详细说明中将可清楚呈现。通过具体实施方式的说明,当可对本申请为达成预定目的所采取的技术手段及功效得以更加深入且具体的了解，然而所附图式仅是提供参考与说明之用,并非用来对本申请加以限制。

图1为本申请第一实施例的维修保养的监管方法的流程示意图。如图1所示的维修保养的监管方法可以应用于如图4所示的车辆，也可以应用于服务器。如图1所示，维修保养的监管方法包括如下步骤：

步骤S11：获取并存储车辆最后一次进行维修保养的时间；

具体地，车辆可以通过车载终端接收用户的输入，以获取车辆最后一次进行维修保养的时间，也可以通过接收服务器发送的维修保养信息以获取车辆最后一次进行维修保养的时间，还可以通过设置在车辆内的监控设备获取车辆最后一次进行维修保养的时间等等。

具体地，服务器可以通过移动终端或车载终端等接收并存储车辆最后一次进行维修保养的时间。

步骤S12：判断是否满足再次进行维修保养的条件；

其中，再次进行维修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程；

在一实施方式中，最后一次进行维修保养的时间间隔大于预设时长，或进行最后一次维修保养后的行驶里程大于预设里程时，则判断满足再次进行维修保养的条件。在其它实施方式中，也可以仅仅对其中一项进行判断，也就是说例如仅仅对最后一次进行维修保养的时间间隔是否大于预设时长进行判断，还可以仅仅在进行最后一次维修保养后的行驶里程是否大于预设里程进行判断等等。当然，与可以最后一次进行维修保养的时间间隔大于预设时长，且进行最后一次维修保养后的行驶里程大于预设里程时，判断满足再次进行维修保养的条件。

在其它实施方式中，再次进行维修保养的条件还可以为某部件或模块例如发动机的运行参数异常等等。

步骤S13：若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息。

在一实施方式中，展示维修保养提醒信息的终端可以为车载终端，也可以为与车辆关联的移动终端等。

在一实施方式中，维修保养提醒信息可以但不限于包括进行提醒的原因例如距离上次维修保养已经5个月了，和/或进行上次维修保养后行驶了5500公里了，和/或发动机运行异常等等。

在一实施方式中，步骤S13：若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息的步骤之后包括：

步骤S14：使得终端展示至少一条维修保养推荐店铺信息；

其中，每条维修保养推荐店铺信息均包括店铺地点信息和/或店铺工作人员信息和/或可预约时间信息中的至少一项；

具体地，终端可以在接收到车辆或服务器发送的维修保养推荐店铺信息后，展示至少一条维修保养推荐店铺信息。此外，终端例如车载终端也可以自动展示存储在存储器中的至少一条维修保养推荐店铺信息等等。

具体地，可预约时间信息可以为推荐店铺的可预约时间，或者店铺工作人员的可预设预约等等。

在一实施方式中，步骤S14：使得终端展示维修保养推荐店铺信息的步骤之前可包括：获取根据车辆的停车位置的距离和/或大众评分进行加权计分后得分排在前n位的维修保养店铺信息，以生成维修保养推荐店铺信息，其中，n为预设的大于或等于1的正整数；将维修保养推荐店铺信息发送至终端。也就是说，终端展示的维修保养推荐店铺信息可以是根据车辆的停车位置的距离和/或大众评分进行加权评分后得分较高的店铺。在其他实施方式中，终端展示的维修保养推荐店铺还可以推荐用户自己评分较高的维修保养店铺信息，或者存储在收藏夹中的维修保养店铺信息等等。

步骤S15：发送车辆的停车位置信息和/或车辆的开锁验证码至与确认指令对应的维修保养推荐店铺的通信地址。

其中，在终端接收到关于一条维修保养推荐店铺信息的确认指令时，发送车辆的停车位置信息和/或车辆的开锁验证码至与确认指令对应的维修保养推荐店铺的通信地址。

具体地，车辆的开锁验证码可以但不限于为临时开锁验证码，即仅仅在维修保养期间能开启车门的验证码。其中，维修保养期间可以根据用户输入的设置指令进行设置，也可以为预约的维修保养时间等等。

在一实施方式中，在发送车辆的停车位置信息和车辆的开锁验证码至与确认指令对应的维修保养推荐店铺的通信地址后，推荐店铺指派的维修人员或用户通过确认指令指定的维修人员可以直接通过验证码开启车门，从而将车辆直接开到店铺后进行维修保养，避免了需要拿到车辆的钥匙才能进行后续动作的麻烦，缩短了车辆进行维修保养的时间。

在一实施方式中，为了避免非维修人员通过临时验证码开启车辆的车门，车辆可以在接收到临时验证码及指定的维修人员的生物特征时，才进行开锁动作。

在一实施方式中，步骤S15：发送车辆的停车位置信息和/或车辆的开锁验证码至与确认指令对应的维修保养推荐店铺的通信地址的步骤之后还可以但不限于包括：

终端展示车辆的实时地理位置信息和/或维修保养状态信息；和/或

在车辆的实时地理位置偏离车辆的停车位置与此条维修保养推荐店铺信息的店铺地点的导航路线时，终端展示报警提醒信息。

具体地，展示车辆的实时地理位置信息和/或维修保养状态信息的终端可以为与车辆关联的移动终端，这样使得用户在于车辆不在同一地点时，也能远程监控车辆的地理位置和/或状态。

在一实施方式中，方法还包括：

步骤S16：在获取到车辆的配件的维修通知信息时，获取车辆的配件的维修日志；

其中，车辆的配件的维修日志包括维修时间、维修店铺、维修工作人员中的至少一项。

在其它实施方式中，维修日志还可以但不限于包括维修价格等等。

在一实施方式中，在获取到车辆的配件的维修通知信息时，获取车辆的配件的维修日志的步骤之后还包括：

步骤S17：获取车辆的配件的运行参数信息，并将运行参数信息与根据大数据学习得到的运行参数信息进行比对，以检测配件是否正常运行；

步骤S18：在车辆的配件未正常运行时，使得终端展示车辆的配件的维修日志。

在其它实施方式中，车载终端或移动终端也可以在接收到用户输入的关于配件的维修日志展示指令时，展示对应配件的维修日志等等。

在一实施方式中，方法还包括：

若不满足再次进行维修保养的条件，则返回步骤S12：判断是否满足再次进行维修保养的条件；

在其它实施方式中，若不满足再次进行维修保养的条件，也可以使得终端展示再次进行维修保养的剩余时间或剩余里程。

图2为本申请第二实施例的维修保养的监管方法的流程示意图。图3为本申请如图2的维修保养的监管方法的应用环境示意图。如图3所示，维修保养的监管方法应用于车辆、服务器及终端之间。请参考图2，维修保养的监管方法包括如下步骤：

步骤S21：服务器接收并存储车辆发送的车辆最后一次进行维修保养的时间；

在其它实施方式中，服务器也可以接收终端发送的车辆最后一次进行维修保养的时间。

步骤S22：服务器判断是否满足再次进行维修保养的条件；

其中，再次进行维续修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程。

步骤S23:若满足再次进行维修保养的条件，则终端展示维修保养提醒信息。

在一实施方式中，方法还包括：

若不满足再次进行维修保养的条件，则返回步骤S22：服务器判断是否满足再次进行维修保养的条件。

在其它实施方式中，若不满足再次进行维修保养的条件，也可以使得终端展示再次进行维修保养的剩余时间或剩余里程。

值得说明的是，图1所示的维修保养的监管方法中的步骤S14至S18可以是车辆或服务器执行，因此，图3所示的维修保养的监管方法也可以包括如图1所示的步骤S14至S18中的任意一个步骤，其具体工作原理请参考图1对应的描述，在此不再赘述。

图4为本申请第三实施例的车辆的结构示意图。如图4所示，车辆40包括存储器401和处理器402。存储器401用于存储可执行程序代码。处理器402用于调用存储器401中的可执行程序代码，以执行如下步骤获取并存储车辆40最后一次进行维修保养的时间；判断是否满足再次进行维修保养的条件，再次进行维修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程；若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息。

在一实施方式中，终端为车载终端或移动终端。

申请的维修保养的监管方法及车辆能自动提醒用户进行维修保养，避免车辆错过维修保养时机，提高了车辆的使用寿命和行车安全性。

以上，仅是本申请的较佳实施例而已，并非对本申请作任何形式上的限制，虽然本申请已以较佳实施例揭露如上，然而并非用以限定本申请,任何熟悉本专业的技术人员，在不脱离本申请技术方案范围内,当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例,但凡是未脱离本申请技术方案内容，依据本申请的技术实质对以上实施例所作的任何简单修改、等同变化与修饰,均仍属于本申请技术方案的范围内。

Claims (10)

1.一种维修保养的监管方法，其特征在于，所述方法应用于车辆或服务器，所述方法包括：

获取并存储车辆最后一次进行维修保养的时间；

判断是否满足再次进行维修保养的条件，再次进行维修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程；

若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息。

2.如权利要求1所述的维修保养的监管方法，其特征在于，所述方法还包括：

若不满足再次进行维修保养的条件，则返回判断是否满足再次进行维修保养的条件的步骤，和/或使得终端展示再次进行维修保养的剩余时间或剩余里程。

3.如权利要求1所述的维修保养的监管方法，其特征在于，若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息的步骤之后包括：

使得所述终端展示至少一条维修保养推荐店铺信息，每条维修保养推荐店铺信息均包括店铺地点信息和/或店铺工作人员信息和/或可预约时间信息中的至少一项；

在所述终端接收到关于一条维修保养推荐店铺信息的确认指令时，发送所述车辆的停车位置信息和/或车辆的开锁验证码至与所述确认指令对应的维修保养推荐店铺的通信地址。

4.如权利要求3所述维修保养的监管方法，其特征在于，使得所述终端展示维修保养推荐店铺信息的步骤之前包括:

获取根据所述车辆的停车位置的距离和/或大众评分进行加权计分后得分排在前n位的维修保养店铺信息，以生成所述维修保养推荐店铺信息，其中，n为预设的大于或等于1的正整数；

将所述维修保养推荐店铺信息发送至所述终端。

5.如权利要求3所述维修保养的监管方法，其特征在于，所述维修保养的监管方法还应用于终端；其中，发送所述车辆的停车位置信息和/或车辆的开锁验证码至与所述确认指令对应的维修保养推荐店铺的通信地址的步骤之后包括：

所述终端展示车辆的实时地理位置信息和/或维修保养状态信息；和/或

在所述车辆的实时地理位置偏离所述车辆的停车位置与此条维修保养推荐店铺信息的店铺地点的导航路线时，所述终端展示报警提醒信息。

6.如权利要求1所述维修保养的监管方法，其特征在于，所述方法还包括：

在获取到所述车辆的配件的维修通知信息时，获取所述车辆的配件的维修日志，所述车辆的配件的维修日志包括维修时间、维修店铺、维修工作人员中的至少一项。

7.如权利要求6所述维修保养的监管方法，其特征在于，在获取到所述车辆的配件的维修通知信息时，获取所述车辆的配件的维修日志的步骤之后还包括：

获取所述车辆的配件的运行参数信息，以将所述运行参数信息与根据大数据学习得到的运行参数信息进行比对，从而检测所述车辆的配件是否正常运行；

在所述车辆的配件未正常运行时，使得所述终端展示所述车辆的配件的维修日志。

8.一种维修保养的监管方法，其特征在于，所述方法应用于车辆、服务器及终端之间，所述方法包括：

所述服务器接收并存储所述车辆或所述终端发送的车辆最后一次进行维修保养的时间；

所述服务器判断是否满足再次进行维修保养的条件，再次进行维续修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程；

若满足再次进行维修保养的条件，则所述终端展示维修保养提醒信息。

9.一种车辆，其特征在于，所述车辆包括存储器和处理器；

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

所述处理器用于调用所述存储器中的可执行程序代码，以执行如下步骤：

获取并存储车辆最后一次进行维修保养的时间；

判断是否满足再次进行维修保养的条件，再次进行维修保养的条件包括与最后一次进行维修保养的时间间隔大于预设时长，和/或进行最后一次维修保养后的行驶里程大于预设里程；

若满足再次进行维修保养的条件，则使得终端展示维修保养提醒信息。

10.如权利要求9所述的车辆，其特征在于，所述终端为车载终端或移动终端。

Images