发明内容
本申请的目的在于提供一种提示方法、装置、电子设备和存储介质。
在一些实施例中,一种提示方法,包括:
获取各运维终端发送的车辆维修数据;车辆维修数据中携带有被维修车辆的维修部件标识信息;
根据维修部件标识信息,生成运维提示信息;
向被提示终端发送运维提示信息。
在一些实施例中,根据维修部件标识信息,生成运维提示信息,包括:
根据维修部件标识信息,计算当前车辆部件损坏量;
根据当前车辆部件损坏量,生成携带有车辆部件采购量的运维提示信息。
在一些实施例中,运维提示信息包括车辆使用提示信息;
根据维修部件标识信息,生成运维提示信息,包括:
根据维修部件标识信息,计算当前车辆部件损坏量;
根据当前车辆部件损坏量,生成车辆使用提示信息。
在一些实施例中,车辆维修数据中还携带有被维修车辆的车辆位置信息;
根据维修部件标识信息,计算当前车辆部件损坏量,包括:
根据车辆位置信息和维修部件标识信息,确定每个服务地区的车辆部件损坏量;
根据当前车辆部件损坏量,生成车辆使用提示信息,包括:
针对每个服务地区,根据该服务地区的车辆部件损坏量,生成该服务地区的车辆使用提示信息。
在一些实施例中,被提示终端包括被提示客户端;向被提示终端发送运维提示信息,包括:
根据被提示客户端的历史使用地区和每个服务地区的匹配程度,从多个服务地区中选择目标服务地区;
向被提示客户端发送目标服务地区的车辆使用提示信息。
在一些实施例中,被提示终端包括被提示客户端;向被提示终端发送运维提示信息,包括:
获取被提示客户端所发出的车辆使用请求;车辆使用请求中携带有待使用车辆的位置信息;
根据待使用车辆的位置信息和每个服务地区的匹配程度,从多个服务地区中选择目标服务地区;
向被提示客户端发送目标服务地区的车辆使用提示信息。
在一些实施例中,方法还包括:
若接收到被提示客户端所发出的关于车辆使用提示信息的确认信息,则生成远程解锁指令;
向待使用车辆发送远程解锁指令,以使待使用车辆解锁。
在一些实施例中,车辆维修数据中还携带有车辆位置信息;运维提示信息包括推荐服务地区提示信息;
根据维修部件标识信息,生成运维提示信息,包括:
根据车辆位置信息和维修部件标识信息,确定每个服务地区的车辆部件损坏量;
根据每个服务地区的车辆部件损坏量,从多个服务地区中选择推荐服务地区;
根据推荐服务地区,生成推荐服务地区提示信息。
在一些实施例中,被提示终端包括被提示客户端;向被提示终端发送运维提示信息,包括:
向每个被提示客户端发送推荐服务地区提示信息。
在一些实施例中,被提示终端包括被提示客户端;向被提示终端发送运维提示信息,包括:
获取被提示客户端所发出的车辆使用请求;车辆使用请求中携带有待使用车辆的位置信息;
根据待使用车辆的位置信息,判断待使用车辆是否在推荐服务地区中;
若待使用车辆不在推荐服务地区中,则向被提示客户端发送推荐服务地区提示信息。
在一些实施例中,运维提示信息包括以下的任意一种或多种:
语音提示信息、震动提示信息、弹窗提示信息、文字提示信息。
在一些实施例中,根据维修部件标识信息,生成运维提示信息,包括:
根据维修部件标识信息,计算当前车辆部件损坏量;
根据当前车辆部件损坏量,生成表示对车辆部件进行改进的运维提示信息。
在一些实施例中,一种提示装置,包括:
第一获取模块,用于获取各运维终端发送的车辆维修数据;车辆维修数据中携带有被维修车辆的维修部件标识信息;
第一生成模块,用于根据维修部件标识信息,生成运维提示信息;
第一发送模块,用于向被提示终端发送运维提示信息。
在一些实施例中,第一生成模块,包括:
第一计算单元,用于根据维修部件标识信息,计算当前车辆部件损坏量;
第一生成单元,用于根据当前车辆部件损坏量,生成携带有车辆部件采购量的运维提示信息。
在一些实施例中,运维提示信息包括车辆使用提示信息;
第一生成模块,包括:
第二计算单元,用于根据维修部件标识信息,计算当前车辆部件损坏量;
第二生成单元,用于根据当前车辆部件损坏量,生成车辆使用提示信息。
在一些实施例中,车辆维修数据中还携带有被维修车辆的车辆位置信息;
第二计算单元,包括:
第一确定子单元,用于根据车辆位置信息和维修部件标识信息,确定每个服务地区的车辆部件损坏量;
第二生成单元,包括:
第一生成子单元,用于针对每个服务地区,根据该服务地区的车辆部件损坏量,生成该服务地区的车辆使用提示信息。
在一些实施例中,被提示终端包括被提示客户端;第一发送模块,包括:
第一选择单元,用于根据被提示客户端的历史使用地区和每个服务地区的匹配程度,从多个服务地区中选择目标服务地区;
第一发送单元,用于向被提示客户端发送目标服务地区的车辆使用提示信息。
在一些实施例中,被提示终端包括被提示客户端;第一发送模块,包括:
第一获取单元,用于获取被提示客户端所发出的车辆使用请求;车辆使用请求中携带有待使用车辆的位置信息;
第二选择单元,用于根据待使用车辆的位置信息和每个服务地区的匹配程度,从多个服务地区中选择目标服务地区;
第二发送单元,用于向被提示客户端发送目标服务地区的车辆使用提示信息。
在一些实施例中,方法还包括:
第二生成模块,用于若接收到被提示客户端所发出的关于车辆使用提示信息的确认信息,则生成远程解锁指令;
第二发送模块,用于向待使用车辆发送远程解锁指令,以使待使用车辆解锁。
在一些实施例中,车辆维修数据中还携带有车辆位置信息;运维提示信息包括推荐服务地区提示信息;
第一生成模块,包括:
第一确定单元,根据车辆位置信息和维修部件标识信息,确定每个服务地区的车辆部件损坏量;
第三选择单元,用于根据每个服务地区的车辆部件损坏量,从多个服务地区中选择推荐服务地区;
第三生成单元,用于根据推荐服务地区,生成推荐服务地区提示信息。
在一些实施例中,被提示终端包括被提示客户端;第一发送模块,包括:
第三发送单元,用于向每个被提示客户端发送推荐服务地区提示信息。
在一些实施例中,被提示终端包括被提示客户端;第一发送模块,包括:
第二获取单元,用于获取被提示客户端所发出的车辆使用请求;车辆使用请求中携带有待使用车辆的位置信息;
第一判断单元,用于根据待使用车辆的位置信息,判断待使用车辆是否在推荐服务地区中;
第四发送单元,若待使用车辆不在推荐服务地区中,则用于向被提示客户端发送推荐服务地区提示信息。
在一些实施例中,运维提示信息包括以下的任意一种或多种:
语音提示信息、震动提示信息、弹窗提示信息、文字提示信息。
在一些实施例中,第一生成模块,包括:
第三计算单元,用于根据维修部件标识信息,计算当前车辆部件损坏量;
第四生成单元,用于根据当前车辆部件损坏量,生成表示对车辆部件进行改进的运维提示信息。
在一些实施例中,一种电子设备,包括:处理器、存储介质和总线,存储介质存储有处理器可执行的机器可读指令,当电子设备运行时,处理器与存储介质之间通过总线通信,处理器执行机器可读指令,以执行时执行如提示方法的步骤。
在一些实施例中,一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如提示方法的步骤。
本申请所提供的提示方法,在接收到运维人员操作运维终端发送的车辆维修数据之后,可以根据车辆维修数据中携带的被维修车辆的维修部件标识信息来生成运维提示信息,而后再将运维提示信息发送给指定的提示终端,以使用户在看到运维提示信息后可以帮助用户抉择使用车辆的策略;或者是在技术人员看到运维提示信息后可以及时的对车辆部件进行改进;或者是在采购人员看到运维提示信息后可以及时的采购车辆部件。这种生成运维提示信息,并将运维提示信息发送给指定终端的方式,提高了车辆维护系统整体联动工作的效率。
在一些实施例中,本申请所提供的提示方法中,可以根据维修部件标识信息,计算当前车辆部件损坏量,而后根据所述当前车辆部件损坏量,生成车辆使用提示信息,并将车辆使用提示信息提供给用户进行参考,使得用户在使用车辆的时候可以注意车辆损坏的部件,提高了使用车辆的安全程度。
在一些实施例中,本申请所提供的提示方法中,可以根据用户所在的服务地区,向用户提供该服务地区所对应的车辆使用提示信息,以使向用户提供的车辆使用提示信息更有针对性。
在一些实施例中,本申请所提供的提示方法中,可以根据每个服务地区的所述车辆部件损坏量,从多个所述服务地区中选择推荐服务地区,向用户提供推荐服务地区,以使用户可以到车辆状况更好的地区使用车辆,提高了用户选择车辆的准确度。
为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
具体实施方式
下面将结合本申请实施例中附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
车辆是经常在日常的生产生活中是经常被使用到的工具,按照车辆的动力来源进行区分,车辆可以分为机动车和非机动车。机动车是指以动力装置驱动或者牵引,上道路行驶的供人员乘用或用于运送物品以及进行工程专项作业的轮式车辆。具体的,机动车又可以分为汽油车、柴油车、电动车和新能源汽车等。非机动车主要是指以人力作为动力来源的车辆,非机动车通常是按照车轮量进行划分的,比如可以分为两轮车(如自行车)、三轮车等。
不论是何种车辆,随着使用时间的延长和使用次数的增加,都会发生老化、损坏的问题。此时,就需要对车辆进行维修。车辆的维修有两种形式,分别是上门修理和维修站修理。一般来说,如果车辆的故障较小,就会采用上门修理的方式来处理(运维人员到车辆所在地进行修理);如果车辆的故障较大,则会采用维修站修理的方式来处理(运维人员或者车辆所有者将车辆运送至维修站,并由运维人员进行修理)。
通常情况下,车辆的运维人员只是单纯的负责对车辆进行修理,而没有根据车辆的修理结果进行进一步的处理。针对这种情况,本申请发明人认为,可以采用将车辆修理结果进行汇总的方式来指导后续的工作。
由此,本申请提供了一种提示方法,如图1所示,该提示方法包括:
S101,获取各运维终端发送的车辆维修数据;车辆维修数据中携带有维修部件标识信息;
S102,根据维修部件标识信息,生成运维提示信息;
S103,向被提示终端发送运维提示信息。
步骤S101中,运维终端通常是指车辆的运维人员(维修、维护人员)所使用的终端,通过使用该运维终端,车辆的运维人员可以将车辆的修理情况进行上报。需要说明的是,运维终端的使用者并不必然只是专门对车辆进行维修、维护的人员,还可以是车辆的使用者(即用户)。也就是,获取各运维终端发送的车辆维修数据不仅可以是运维人员通过操作运维终端发出的,也可以是车辆的使用者通过操作运维终端发出的。
此处,车辆维修数据不必然是运维人员将车辆进行维修之后才发出的,也可以是相关人员(车辆的运维人员或车辆的使用者)在发现车辆处于损坏状态,且车辆未被维修之前发出的。
进而,车辆维修数据可以是由运维人员在对车辆(至少一个车辆部件有损坏的车辆)进行维修前,通过操作运维终端(如手机)发出的;
车辆维修数据也可以是由运维人员在对车辆(至少一个车辆部件有损坏的车辆)进行维修后,通过操作运维终端发出的;
车辆维修数据还可以是由车辆的使用者在发现车辆中某一个部件处于损坏状态后,通过操作运维终端发出的。
具体的,本申请所提供的方法中,运维终端所发出的车辆维修数据中,需要携带的是维修部件标识信息。可以了解到的是,车辆必然是由大量的部件所组成的,车辆在损坏的时候,通常不会是组成车辆的所有部件都发生了损坏,而是组成车辆的一部分部件(某一个部件或某多个部件)发生了损坏。因此,在运维终端上报车辆维修数据的时候,就可以只上报损坏的车辆部件,而不需要上报良好的车辆部件。在上报的时候,可以是将损坏的车辆部件的编号上传到服务器,也可以是直接将损坏的车辆部件的名称上传到服务器。
至于如何发现损坏的部件,可以是用户或运维人员在尝试使用车辆后确定的(如车辆无法正常使用,则说明车辆中必然有至少一个部件处于损坏状态,此时可以进行逐个部件的排查)。也可以是用户或运维人员直接通过肉眼观察的方式来确定哪个车辆部件是处于损坏状态的(如某个车辆部件的外观发生了形变,则可以推断该车辆部件发生了损坏)。
服务器(本申请所提供的方法的执行主体)在接收到车辆维修数据之后,在步骤S102中,就可以根据维修部件标识信息来生成运维提示信息了,并在步骤S103中向指定的被提示终端发送该运维提示信息了。此处运维提示信息是关于维修部件(损坏的车辆部件)的信息,运维提示信息的种类比较多,比如,可以是用于提示用户注意安全的信息(某个部件损坏,使用车辆的时候应当注意的信息);还可以是提示用户优选使用地区的信息(建议使用车辆部件损坏较少的地区的车辆);还可以是在部件损坏之后,提示采购人员及时采购车辆部件的信息;还可以是在部件损坏之后,提示技术人员及时对车辆部件进行改进的信息。
对应的,如果是提示用户注意安全性的信息,或者是提示用户优选使用地区的信息,则步骤S103中就应当发送给用户所使用的客户端;如果是提示采购人员及时采购车辆部件的信息,则在步骤S103中就应当将该信息发送给采购人员所使用的采购终端;如果是提示提示技术人员及时对车辆部件进行改进的信息,则在步骤S103中就应当将该信息发送给技术人员所使用的技术终端。
本申请所提供的方法可以应用于每个种类的车辆,用以对各个车辆的使用情况进行监控。本申请所提供的方案优选应用于共享车辆。下面将主要以本申请所提供的方法是针对共享车辆来实现的情况进行介绍,此时,车辆维修数据就是针对共享车辆生成的维修数据了。
具体的,如前文中的说明,运维提示信息有4中形式,进而运维提示信息可以有如下四种使用方式,分别是:第一种使用方式,将运维提示信息发送给用户,以提示用户车辆可能有故障(让用户在使用车辆的时候注意);第二种使用方式,将运维提示信息发送给用户,以说明推荐用户到哪个地区使用车辆(推荐用户去故障车辆较少的区域使用车辆);第三种使用方式,将运维提示信息发送给采购人员,以使采购人员及时采购损坏的车辆部件;第四种使用方式,将运维提示信息发送给技术人员,以使技术人员从技术角度对车辆部件进行改进,以降低车辆的故障率。
下面,分别对这几种运维提示信息的使用方式进行分别说明。
第一种运维提示信息的使用方式,即将运维提示信息发送给采购人员,以使采购人员及时采购车辆部件。此时,本申请所提供的方案中,如图2所示步骤S102可以按照如下方式实现:
S1021,根据维修部件标识信息,计算当前车辆部件损坏量;
S1022,根据当前车辆部件损坏量,生成携带有车辆部件采购量的运维提示信息。
此处,维修部件标识信息的主要作用是标识出说明哪个车辆部件损坏了,也可以是反映了哪个车辆部件在损坏后被修理好了。整体来看维修部件标识信息是用来区分不同种类的车辆部件的,其存在形式可以是某种编号。由于在步骤S101中所获取到的是各车辆的维修部件标识信息,因此,在将各车辆的维修部件标识信息进行统计之后,就可以得到当前车辆部件损坏量了。此处,统计的当前车辆部件损坏量通常是需要分别对每个类型的车辆部件统计损坏量。
通常车辆维修数据中应当携带有至少一个维修部件标识信息,还可以是在携带有维修部件标识信息的基础上还携带有每个维修部件标识信息所对应的数量。比如可以在车辆维修数据中携带如下表1的表格:
表1
编号 |
维修部件标识信息 |
数量 |
1 |
AAA |
5 |
2 |
BBB |
7 |
3 |
CCC |
2 |
4 |
DDD |
3 |
如果车辆维修数据中携带有表1式的表格,就可以确定,在某个车辆上AAA(如某个型号的螺母)的维修部件损坏了5个,BBB的维修部件损坏了7个,CCC的维修部件损坏了2个,DDD的维修部件损坏了3个。
进而,在获取到多个车辆维修数据后,就可以得知目前已经损坏的车辆部件的总量(车辆部件损坏量)了。
此处,可以认为车辆部件在损坏之后都是要通过更换损坏部件的方式来进行维修,因此,每有一个损坏的车辆部件就需要使用一个新的车辆部件进行替换。进而,当接收到一个车辆部件的维修部件标识信息后,就可以确定必然要使用一个同类型的车辆部件来替换该维修部件标识信息所对应的损坏的车辆部件了。
进而,接收到车辆维修数据后,就可以根据维修部件标识信息来确定出当前车辆部件损坏量了。此处的损坏量可以是指某一种车辆部件的损坏量,也可以是不特指某一种车辆部件的损坏量。在确定了损坏量之后,就可以进一步确定出需要采购的车辆部件的数量了,也就是确定出车辆部件采购量了。
确定了车辆部件采购量之后,通常是需要将该车辆部件采购量发送给部件采购部门,因此,在生成携带有车辆部件采购量的运维提示信息之后,步骤S103需要按照如下方式执行:
向采购终端(采购人员所使用的终端)发送携带有车辆部件采购量的运维提示信息。
具体的,在计算车辆部件采购量的时候,可以结合当前库存量进行计算,也就是当维修部件标识信息表示的是未进行维修的部件的标识信息时,本申请所提供的方法中,步骤S1022可以按照如下方式实现:
根据当前车辆部件损坏量和当前库存量,生成携带有车辆部件采购量的运维提示信息。
此处,采购部件终端指的是采购部件的部门人员所使用的终端。当前车辆部件损坏量表示了进行维修时所实际要使用的车辆部件的数量;当前库存量表示了目前已经购买的(持有的)部件的数量,因此,当车辆部件损坏量远小于当前库存量的时候,就可以暂缓生成(不生成)携带有车辆部件采购量的运维提示信息。也就是在从当前库存量中减去当前车辆部件损坏量后,剩余的部件量还很多的时候,就可以暂缓生成(不生成)携带有车辆部件采购量的运维提示信息。
反之,当当前车辆部件损坏量接近当前库存量的时候,就需要立即生成携带有车辆部件采购量的运维提示信息,并在步骤S103中,将生成的携带有车辆部件采购量的运维提示信息发送给采购部件终端。此处,运维提示信息中可以携带有具体需要采购的车辆部件的数量。
或者是,在从当前库存量中减去当前车辆部件损坏量后,剩余的部件量很少的时候,就需要立即生成携带有车辆部件采购量的运维提示信息,并在步骤S103中,将生成的携带有车辆部件采购量的运维提示信息发送给采购终端(采购部门的人员所使用的终端)。
此处,采购终端和运维终端可以是指同一个终端。
第二种运维提示信息的使用方式,即将运维提示信息发送给技术人员,以使技术人员从技术角度对车辆部件进行改进,此时本申请所提供的方案中,如图3所示,步骤S102可以按照如下方式实现:
S1023,根据维修部件标识信息,计算当前车辆部件损坏量;
S1024,根据当前车辆部件损坏量,生成表示对车辆部件进行改进的运维提示信息。
步骤S1023的实现方式与步骤S1021的实现方式相同,均是统计数量,此处步骤S1023的实现方式可以参照步骤S1021的实现方式,此处不再重复说明。
在确定了当前车辆部件损坏量之后,就可以根据损坏量来决定是否要对车辆部件进行改进了。此处,生成的运维提示信息可以只是提示哪个部件应当进行改进了;还可以是在此基础上,在运维提示信息中携带上标识改进紧迫性(改进优先级)的消息,以表示部件是否需要尽快被改进。
如果运维提示信息可以只是提示哪个部件应当进行改进,则可以直接将当前车辆部件损坏量和预定的阈值大小进行比较,当当前车辆部件损坏量过大(当前车辆部件损坏量大于预定阈值)的时候,就生成携带有对车辆部件进行改进的运维提示信息。
也就是,步骤S1024可以按照如下方式实现:
判断当前车辆部件损坏量是否大于预设的数量阈值;
若当前车辆部件损坏量大于预设的数量阈值,则生成表示对车辆部件进行改进的运维提示信息。
如果是在运维提示信息中还携带了标识改进紧迫性(改进优先级)消息的话,则步骤S1024在实现时,可以是按照如下方式执行:
根据当前车辆部件损坏量,生成携带有表示对车辆部件进行改进的改进优先级的运维提示信息。
具体的,如下表2所示,示出了在某个运维提示信息中所携带的表格。
表2
编号 |
维修部件标识信息 |
改进优先级 |
1 |
AAA |
1 |
2 |
BBB |
2 |
3 |
CCC |
4 |
4 |
DDD |
3 |
表2中示出了4对AAA的车辆部件进行改进的优先级是第一高的(优先级最高),对BBB的车辆部件进行改进的优先级第二高。类似的,对CCC的车辆部件进行改进的优先级是第三高;对DDD的车辆部件进行改进的优先级最低。
也就是,在具体实现时,可以根据当前车辆部件损坏量生成改进优先级,并将该改进优先级携带在运维提示信息中。具体的,当前车辆部件损坏量越大,则改进优先级越高。改进优先级越高,则技术人员应当越迅速的对车辆部件进行改进。
不论生成的运维提示信息如何,在生成运维提示信息后,都需要将运维提示信息发送给对应的终端,第二种运维提示信息的使用方式中,运维提示信息的作用是提示技术人员对车辆部件进行改进,则该运维提示信息就应当发送给研发部门,进而,在此种情况下,步骤S103可以按照如下方式实现:
将生成的表示对车辆部件进行改进的运维提示信息发送给研发终端(研发部门的人员所使用的终端),此处,研发终端和运维终端可以是指同一个终端。
第三种运维提示信息的使用方式,发送给用户的运维提示信息是为了提示用户车辆可能有故障。此种情况下,运维提示信息包括车辆使用提示信息,如图4所示,步骤S102可以按照如下方式实现:
S1025,根据维修部件标识信息,计算当前车辆部件损坏量;
S1026,根据当前车辆部件损坏量,生成车辆使用提示信息。
此处,步骤S1025的实现方式可以参照步骤S1021的实现方式,此处不过多说明。在确定当前车辆部件损坏量之后,步骤S1026中就可以根据当前车辆部件损坏量来生成车辆使用提示信息。此处,车辆使用提示信息作用主要是提示用户车辆当前某些部件存在故障,在使用车辆的时候需要注意这些部件,或者是车辆的某些部件容易出现损坏的情况,请慎重使用,尽量不要损坏这些容易损坏的车辆部件。
也就是,具体实现的时候,车辆使用提示信息中可以携带有三种内容,分别是:第一种,某个车辆部件容易损坏的提示信息,以提示用户车辆的某个部件容易损坏,请谨慎使用;第二种,车辆部件当前处于损坏状态的提示信息,以告知用户车辆的某个部件当前处于损坏状态,请谨慎使用;第三种,同时包含车辆部件容易损坏的提示信息和车辆部件当前处于损坏状态的提示信息。
具体的,在生成车辆使用提示信息的时候可以根据损坏量的不同来确定提示的严重程度,比如,可以是损坏量越高,则提示的严重程度就越高。
具体实现时,可以预先建立如下表3的表格。
表3
编号 |
损坏量 |
提示内容 |
1 |
1-10 |
XXX部件可能损坏 |
2 |
11-30 |
XXX部件可能损坏,请谨慎使用车辆 |
3 |
31-70 |
XXX部件可能损坏,请尽量避免使用 |
4 |
71-100 |
XXX部件可能损坏,请停止使用 |
由表3可见,当损坏量较低的时候,提示内容相对简单,当损坏量较高的时候,提示内容的语言就会更严重,以起到对用户进行警示的作用。
除了使用列表的形式来生成提示内容以外,还可以是采用阈值判断的形式来生成车辆使用提示信息。
也就是,步骤S1026可以按照如下方式实现:
判断当前车辆部件损坏量是否超过预定的数量阈值;
若当前车辆部件损坏量超过预定的数量阈值,则生成车辆使用提示信息;
若当前车辆部件损坏量未超过预定的数量阈值,则终止当前流程。
类似的,步骤S1026还可以按照如下方式实现:
判断当前车辆部件损坏量是否超过预定的数量阈值;
若当前车辆部件损坏量超过预定的数量阈值,则按照预定的第一提示信息生成策略生成车辆使用提示信息;
若当前车辆部件损坏量未超过预定的数量阈值,则按照预定的第二提示信息生成策略生成车辆使用提示信息;
此处,第一提示信息生成策略和第二提示信息生成策略是不同的生成策略,也就是,使用第一提示信息生成策略生成的车辆使用提示信息和使用第二提示信息生成策略生成的车辆使用提示信息应当是不同的。这两个生成策略的具体内容可以视具体的使用情况来设定。比如,第一提示信息生成策略可以是用来生成较为严重的提示信息,第二提示信息生成策略可以是用来生成普通的提示信息。
此处,需要对损坏量进行说明,损坏量可以是一个绝对的数值,比如损坏量可以用于表征某种部件损坏了多少个;也可以是一个相对数值,比如,比如损坏量可以用于表征该区域中的A部件共有X%处于受损状态,又比如,一号区域中的A部件的损坏量比二号区域中的损坏量多2个,或多2%。类似的,本申请所提供的方案中,损坏量都可以按照上述方式理解成是一个绝对数值(如损坏了多少个),也可以理解成一个相对数值。
在生成了携带有车辆使用提示信息之后,就可以将该车辆使用提示信息向指定的一个终端发送了(如向使用车辆的用户所使用的用户端发送,以使用户了解到车辆的当前状态,以进一步决定是否使用车辆;也可以向运维人员所使用的运维终端所发送,以使运维人员及时了解车辆的当前状态,以确定维修时所携带的用具)。
也就是,步骤S103可以按照如下方式实现:
向被提示客户端或运维终端发送车辆使用提示信息。
实际上,不同地区的车辆在损坏的时候通常是具有一定的特点的,比如,在路况较差的地区(如偏远地区)上行驶的车辆,轮胎的损坏概率较高;在经常有急弯的地区上行驶的车辆,转弯系统的损坏概率较高。
因此,在生成和向指定的终端进行提示的时候,为了使提示的更为精确,可以在生成车辆使用提示信息的时候,区分下不同的地区。也就是,在进行提示之前首先要分别生成不同地区的提示信息,而后,在将指定的一个或多个地区的提示信息发送给指定的终端,以达到提示的目的。
进而,在此种情况下,车辆维修数据中还携带有被维修车辆的车辆位置信息,S1025可以按照如下方式实现:
步骤10251,根据车辆位置信息和维修部件标识信息,确定每个服务地区的车辆部件损坏量;
S1026可以按照如下方式实现:
步骤10261,针对每个服务地区,根据该服务地区的车辆部件损坏量,生成该服务地区的车辆使用提示信息。
步骤10251中,维修部件标识信息说明了故障车辆中的哪个部件需要维修,或者是已经维修完成,车辆位置信息说明了故障车辆的位置。也就是车辆位置信息和维修部件标识信息均是用来描述被维修车辆的信息;换个角度来看,车辆位置信息也就反应了被维修部件所在的地区(携带被维修部件的车辆所在的地区也就是被维修部件所在的地区)。
进而,在知晓这两个信息之后,就可以使用车辆位置信息来将车辆进行按照地区的分类。比如,在按照地区进行分类的时候,可以形成如下表格4:
表4
地区编号 |
车辆编号 |
A |
1,5,8,9 |
B |
2,3,4,10 |
C |
6,7,11,12 |
D |
13,14,15 |
由表3可见,在地区A中的车辆有1,5,8,9;在地区B中的车辆有2,3,4,10;在地区C中的车辆有6,7,11,12;在地区D中的车辆有13,14,15;也就是,一个车辆只能归属于一个地区。
而后,在确定了每个地区的车辆之后,就可以进一步根据该地区中的维修部件标识信息(说明哪个车被维修了)来确定每个地区中有多少个被维修部件了,此处每个地区有多少个被维修部件也就是每个服务地区的车辆部件损坏量。
步骤10261中,就可以分别针对每个地区,根据该服务地区的车辆部件损坏量,生成该服务地区的车辆使用提示信息。生成的车辆使用提示信息的方式可以与步骤S1026相同,区别在于步骤10261中是在计算某个地区的车辆使用提示信息的时候,只使用该地区的车辆部件损坏量作为计算基础,其他计算方式可以参照步骤S1026,此处不再重复说明。
在确定了每个地区的车辆使用提示信息之后,可以直接将每个地区的车辆使用提示信息都发送给指定的终端(客户端或运维终端)。但为了提高消息发送的准确率,在将车辆使用提示信息发送给客户端之前,还可以区分一下客户端的常用地区,以针对性的发送车辆使用提示信息。
也就是,用户经常在哪个服务地区使用车辆就将哪个地区的车辆使用提示信息发送给该用户。此种情况下,被提示终端包括被提示客户端;步骤S103可以按照如下方式执行:
步骤1031,根据被提示客户端的历史使用地区和每个服务地区的匹配程度,从多个服务地区中选择目标服务地区;
步骤1032,向被提示客户端发送目标服务地区的车辆使用提示信息。
其中,历史使用地区反映了被提示客户端的使用者(用户)曾经使用车辆的地点。被提示客户端可以是指任意的一个客户端,也可以是指当前处于在线状态(激活状态)的客户端。
具体从多个服务地区中选择目标服务地区的方式有如下两种:
第一种选择目标服务地区的方式,分别统计用户在每个服务地区的车辆使用次数,而后选择车辆使用次数最高的服务地区作为目标服务地区。
第二种选择目标服务地区的方式,分别统计用户在每个服务地区的车辆使用次数,而后选择车辆使用次数高于预定阈值的服务地区作为目标服务地区。
在确定了目标服务地区之后,就可以直接向被提示客户端发送目标服务地区的车辆使用提示信息了。
其中,采用第二种选择目标服务地区的方式,所确定出的目标服务地区可能是多个,那么在向被提示客户端发送车辆使用提示信息的时候,就需要每个目标服务地区的车辆使用提示信息都发送给被提示客户端。
除了采用上述这种无差别的向每个被提示客户端都发送车辆使用提示信息的方式以外,还可以采用更有针对性的发送方式,也就是,只有客户请求使用车辆的时候,才向用户发送车辆使用提示信息。
此种情况下,被提示终端包括被提示客户端;步骤S103可以按照如下方式实现:
步骤1033,获取被提示客户端所发出的车辆使用请求;车辆使用请求中携带有待使用车辆的位置信息;
步骤1034,根据待使用车辆的位置信息和每个服务地区的匹配程度,从多个服务地区中选择目标服务地区;
步骤1035,向被提示客户端发送目标服务地区的车辆使用提示信息。
步骤1033中,被提示客户端就是指全部客户端中发出车辆使用请求的客户端了。客户端发出车辆使用请求的目的是请求服务器同意使用某个车辆。在车辆使用请求中所携带的待使用车辆的位置信息可以是经纬度信息,或者是在某个坐标系下的位置信息,但应当保证的是,使用该位置信息可以确定出车辆所在的服务地区。
进而,步骤1034中,根据待使用车辆的位置信息,就可以确定出待使用车辆所在服务地区,并将该待使用车辆所在的服务地区作为目标服务地区。
步骤1035中,可以直接向被提示客户端发送关于目标服务地区的车辆使用提示信息。此处,发送车辆使用提示信息的某方面作用是让用户判断自己是否要使用车辆。某些情况下,用户在看到了目标服务地区的车辆使用提示信息之后,认为该地区的车辆状态不理想,可能就放弃使用该地区的车辆了。此种情况下,用户可以通过操作被提示客户端发送取消使用车辆请求给服务器,服务器就可以终止当前流程了。
在某些情况下,用户在看到了目标服务地区的车辆使用提示信息之后,认为该地区的车辆状态扔在可以接受的范围内,此时,用户依旧会使用该地区的车辆。这种情况下,用户就可以操作被提示客户端给服务器返回确认信息,以表示用户在阅读了车辆使用提示信息后,依然决定使用该地区的车辆。此时服务器就可以控制车辆解锁,以使用户可以使用车辆。
进而,本申请所提供的方法还包括如下步骤:
步骤201,若接收到被提示客户端所发出的关于车辆使用提示信息的确认信息,则生成远程解锁指令;
步骤202,向待使用车辆发送远程解锁指令,以使待使用车辆解锁。
步骤201中,被提示客户端所发出的关于车辆使用提示信息的确认信息是在用户操作下所发出的。用户发出该信息就表明用户认为可以使用地区中的车辆。
进而,步骤202中,服务器就可以向车辆发送远程解锁指令,以使待使用车辆解锁。在待使用车辆解锁之后,用户就可以正常使用车辆了。
第四种运维提示信息的使用方式,发送给用户的运维提示信息是为了提示用户到哪个地区使用车辆比较好。此种情况下,车辆维修数据中还携带有车辆位置信息,运维提示信息包括推荐服务地区提示信息;步骤S102可以按照如下方式实现:
步骤1027,根据车辆位置信息和维修部件标识信息,确定每个服务地区的车辆部件损坏量;
步骤1028,根据每个服务地区的车辆部件损坏量,从多个服务地区中选择推荐服务地区;
步骤1029,根据推荐服务地区,生成推荐服务地区提示信息。
步骤1027中,维修部件标识信息说明了故障车辆中的哪个部件需要维修,或者是已经维修完成,车辆位置信息说明了故障车辆的位置。也就是车辆位置信息和维修部件标识信息均是用来描述被维修车辆的信息;换个角度来看,车辆位置信息也就反应了被维修部件所在的地区(携带被维修部件的车辆所在的地区也就是被维修部件所在的地区)。
进而,在知晓了每个车辆的维修部件标识信息和车辆位置信息后,就可以知晓每个服务地区的车辆部件损坏量了。而后,在步骤1028中,可以直接根据每个服务地区的车辆部件损坏量,从多个服务地区中选择推荐服务地区。通常情况下,步骤1028在实现的时候,是选择将车辆部件损坏量最小的一个或几个服务地区作为推荐服务地区;也可以是选择车辆部件损坏量小于预设数值的服务地区作为推荐服务地区。
进而,在确定了推荐服务地区之后,就可以生成推荐服务地区提示信息了。此处的推荐服务地区提示信息的主要作用是引导用户到推荐服务地区中去使用车辆,因此推荐服务地区提示信息中通常至少应当携带有推荐服务地区的地址信息,或者是携带有推荐服务地区中车辆的停放位置。
如果是推荐服务地区提示信息中携带有推荐服务地区中车辆的停放位置。则用户可以通过设置在客户端(如手机)中的导航,来生成从用户的当前位置到达车辆停放位置的导航线路,而后,用户可以按照导航线路来移动到车辆停放位置处。
进一步,在生成了推荐服务地区提示信息之后,同样有两种发送给用户的方式,第一种发送给用户的方式是将推荐服务地区提示信息广泛的发送给用户;第二种发送给用户的方式是在用户请求使用车辆的时候,才向用户发送推荐服务地区提示信息。
具体的,针对第一种发送给用户的方式,被提示终端包括被提示客户端;步骤S103可以按照如下方式实现:
向每个被提示客户端发送推荐服务地区提示信息。
也就是,第一种发送给用户的方式下,推荐服务地区提示信息的发送方式是每个用户都发送一次,以使用户在想使用车辆的时候,可以优先考虑使用推荐服务地区中的车辆。
具体的,针对第二种发送给用户的方式,被提示终端包括被提示客户端;步骤S103可以按照如下方式实现:
步骤1036,获取被提示客户端所发出的车辆使用请求;车辆使用请求中携带有待使用车辆的位置信息;
步骤1037,根据待使用车辆的位置信息,判断待使用车辆是否在推荐服务地区中;
步骤1038,若待使用车辆不在推荐服务地区中,则向被提示客户端发送推荐服务地区提示信息。
步骤1036中,被提示客户端就是指全部客户端中发出车辆使用请求的客户端了。客户端发出车辆使用请求的目的是请求服务器,同意使用某个车辆。在车辆使用请求中所携带的待使用车辆的位置信息可以是经纬度信息,或者是在某个坐标系下的位置信息,但应当保证的是,使用该位置信息可以确定出车辆所在的服务地区。
步骤1037中,根据待使用车辆的位置信息,就可以确定出待使用车辆所在的服务地区,如果待使用车辆所在的服务地区不是推荐服务地区的话,则在步骤1038中,就需要向被提示客户端发送推荐服务地区提示信息了。此处,发送推荐服务地区提示信息的目的仍然是引导用户到推荐服务地区使用车辆。
对应的,如果待使用车辆所在的服务地区是推荐服务地区的话,则可以终止流程,正常让用户使用待使用车辆即可。
某些情况下,用户在看到了推荐服务地区提示信息之后,可能户选择到推荐服务地区中使用车辆,此时,用户可以通过操作被提示客户端发送取消使用车辆请求给服务器,服务器就可以终止当前流程了。
在某些情况下,用户在看到了推荐服务地区提示信息之后,认为直接使用当前的待使用车辆就可以,不需要到推荐服务地区使用车辆,这种情况下,用户就可以操作被提示客户端给服务器返回确认信息,以表示用户在阅读了车辆使用提示信息后,依然决定使用该地区的车辆。此时服务器就可以控制车辆解锁,以使用户可以使用车辆。
进而,本申请所提供的方法还包括如下步骤:
步骤301,若接收到被提示客户端所发出的关于推荐服务地区提示信息的确认信息,则生成远程解锁指令;
步骤302,向待使用车辆发送远程解锁指令,以使待使用车辆解锁。
步骤301中,被提示客户端所发出的关于车辆使用提示信息的确认信息是在用户操作下所发出的。用户发出该信息就表明用户认为可以使用该步骤1036中的待使用车辆了。
进而,步骤302中,服务器就可以向车辆发送远程解锁指令,以使待使用车辆解锁。在待使用车辆解锁之后,用户就可以正常使用车辆了。
上述内容中,介绍了四种不同的运维提示信息的使用方式,在具体实现时通常是选择这4中实现方式中的一种来执行。不论是采用何种实现方式,在步骤S103中,均需要将运维提示信息发送给指定的终端(如客户端或者是运维终端等),以达到提示的目的。
在进行提示的时候,可以有四种提示的形式,分别是语音提示、震动提示、弹窗提示和文字提示。也就是,运维提示信息包括以下的任意一种或多种:
语音提示信息、震动提示信息、弹窗提示信息、文字提示信息。
运维提示信息的内容已经在前文中进行了描述,此处,这四种提示的形式是指输出运维提示信息的几种形式。对于表3中编号为1的提示内容“XXX部件可能损坏”,如果运维提示信息包括语音提示信息,就可以是接收到运维提示信息的终端采用语音的形式播放“XXX部件可能损坏”;如果运维提示信息包括文字提示信息,就可以是接收到运维提示信息的终端采用文字的形式在其显示屏上显示“XXX部件可能损坏”。
具体的,文字提示信息如:在终端的显示界面上显示类似于“XXX部件可能损坏”的文字内容,以对用户进行提示。
震动提示信息如:在终端接收到运维提示信息后,使终端持续的进行震动,并在用户手动按下停止震动的按钮时,终端停止震动。此处,如果运维提示信息中携带有车辆使用提示信息,则终端在收到车辆使用提示信息之后,就可以开始震动了。
语音提示信息如:在终端接收到运维提示信息之后,就需要采用语音的方式播放运维提示信息的具体内容。
弹窗提示信息如:在终端的显示界面中的弹窗内容显示类似于“XXX部件可能损坏”的文字内容,以对用户进行提示。
具体实现时,这四种提示形式中,可以只使用一种,也可以同时使用至少两种。比如在终端震动的时候,终端同时播放语音提示信息;比如在终端震动的时候,同时播放语音信息和在终端的当前显示界面上显示文字,也可以是同时使用这四种方式进行提示。
与上述方法相对应的,本申请还提供了一种提示装置,包括:
第一获取模块,用于获取各运维终端发送的车辆维修数据;车辆维修数据中携带有被维修车辆的维修部件标识信息;
第一生成模块,用于根据维修部件标识信息,生成运维提示信息;
第一发送模块,用于向被提示终端发送运维提示信息。
在一些实施例中,第一生成模块,包括:
第一计算单元,用于根据维修部件标识信息,计算当前车辆部件损坏量;
第一生成单元,用于根据当前车辆部件损坏量,生成携带有车辆部件采购量的运维提示信息。
在一些实施例中,运维提示信息包括车辆使用提示信息;
第一生成模块,包括:
第二计算单元,用于根据维修部件标识信息,计算当前车辆部件损坏量;
第二生成单元,用于根据当前车辆部件损坏量,生成车辆使用提示信息。
在一些实施例中,车辆维修数据中还携带有被维修车辆的车辆位置信息;
第二计算单元,包括:
第一确定子单元,用于根据车辆位置信息和维修部件标识信息,确定每个服务地区的车辆部件损坏量;
第二生成单元,包括:
第一生成子单元,用于针对每个服务地区,根据该服务地区的车辆部件损坏量,生成该服务地区的车辆使用提示信息。
在一些实施例中,被提示终端包括被提示客户端;第一发送模块,包括:
第一选择单元,用于根据被提示客户端的历史使用地区和每个服务地区的匹配程度,从多个服务地区中选择目标服务地区;
第一发送单元,用于向被提示客户端发送目标服务地区的车辆使用提示信息。
在一些实施例中,被提示终端包括被提示客户端;第一发送模块,包括:
第一获取单元,用于获取被提示客户端所发出的车辆使用请求;车辆使用请求中携带有待使用车辆的位置信息;
第二选择单元,用于根据待使用车辆的位置信息和每个服务地区的匹配程度,从多个服务地区中选择目标服务地区;
第二发送单元,用于向被提示客户端发送目标服务地区的车辆使用提示信息。
在一些实施例中,方法还包括:
第二生成模块,用于若接收到被提示客户端所发出的关于车辆使用提示信息的确认信息,则生成远程解锁指令;
第二发送模块,用于向待使用车辆发送远程解锁指令,以使待使用车辆解锁。
在一些实施例中,车辆维修数据中还携带有车辆位置信息;运维提示信息包括推荐服务地区提示信息;
第一生成模块,包括:
第一确定单元,根据车辆位置信息和维修部件标识信息,确定每个服务地区的车辆部件损坏量;
第三选择单元,用于根据每个服务地区的车辆部件损坏量,从多个服务地区中选择推荐服务地区;
第三生成单元,用于根据推荐服务地区,生成推荐服务地区提示信息。
在一些实施例中,被提示终端包括被提示客户端;第一发送模块,包括:
第三发送单元,用于向每个被提示客户端发送推荐服务地区提示信息。
在一些实施例中,被提示终端包括被提示客户端;第一发送模块,包括:
第二获取单元,用于获取被提示客户端所发出的车辆使用请求;车辆使用请求中携带有待使用车辆的位置信息;
第一判断单元,用于根据待使用车辆的位置信息,判断待使用车辆是否在推荐服务地区中;
第四发送单元,若待使用车辆不在推荐服务地区中,则用于向被提示客户端发送推荐服务地区提示信息。
在一些实施例中,运维提示信息包括以下的任意一种或多种:
语音提示信息、震动提示信息、弹窗提示信息、文字提示信息。
在一些实施例中,第一生成模块,包括:
第三计算单元,用于根据维修部件标识信息,计算当前车辆部件损坏量;
第四生成单元,用于根据当前车辆部件损坏量,生成表示对车辆部件进行改进的运维提示信息。
与上述方法相对应的,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如提示方法的步骤。
如图5所示,为本申请实施例所提供的电子设备示意图,该电子设备1000包括:处理器1001、存储器1002和总线1003,存储器1002存储有执行指令,当电子设备运行时,处理器1001与存储器1002之间通过总线1003通信,处理器1001执行存储器1002中存储的提示方法的步骤。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应所述以权利要求的保护范围为准。