CN111915403A - 共享车辆状态检测方法及装置 - Google Patents

Abstract

本公开实施例提供一种共享车辆状态检测方法及装置，该方法包括：获取共享车辆发送的共享车辆的状态信息。根据共享车辆的状态信息，得到共享车辆的疑似异常次数。当共享车辆的疑似异常次数大于或等于预设阈值时，确定共享车辆为故障车辆，并发送针对故障车辆的预警信息。通过根据共享车辆的状态信息实时的、主动的更新车辆的疑似异常次数，从而可以在车辆的疑似异常次数大于或等于预设阈值时，将共享车辆确定为故障车辆，通过对每个共享车辆均执行上述流程，从而可以实现对路面上的共享车辆的状态的全面检测。

Description

共享车辆状态检测方法及装置

技术领域

本公开的实施例涉及计算机技术，尤其涉及一种共享车辆状态检测方法及装置。

背景技术

随着共享车辆的不断发展，为了保证用户出行的安全性，需要对于投放到路面上的共享车辆进行车辆状态的检查。

目前，现有技术在对共享车辆的状态进行检查时，通常是在用户骑行某个车辆之前或者骑行结束之后，通过客户端向用户发送问卷调查，接着通过用户反馈的问卷调查的信息，实现对车辆状态的检查。

然而，用户是否填写问卷信息完全取决于用户的意愿，因此现有技术的实现方案无法实现对车辆状态的全面检测。

发明内容

本公开的实施例提供一种共享车辆状态检测方法及装置，用以解决无法实现对车辆状态的全面检测的问题。

一方面，本公开的实施例提供一种共享车辆状态检测方法，包括：

获取共享车辆发送的所述共享车辆的状态信息；

根据所述共享车辆的状态信息，得到所述共享车辆的疑似异常次数；

当所述共享车辆的疑似异常次数大于或等于预设阈值时，确定所述共享车辆为故障车辆，并发送针对所述故障车辆的预警信息。

另一方面，本公开的实施例提供一种共享车辆状态检测装置，包括：

获取模块，用于获取共享车辆发送的所述共享车辆的状态信息；

处理模块，用于根据所述共享车辆的状态信息，得到所述共享车辆的疑似异常次数；

确定模块，用于当所述共享车辆的疑似异常次数大于或等于预设阈值时，确定所述共享车辆为故障车辆，并发送针对所述故障车辆的预警信息。

另一方面，本公开的实施例提供一种共享车辆状态检测设备，包括：存储器和处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令执行如上第一方面所述的方法。

另一方面，本公开的实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序；所述计算机程序被执行时，实现如上第一方面所述的方法。

本公开实施例提供一种共享车辆状态检测方法及装置，该方法包括：获取共享车辆发送的共享车辆的状态信息。根据共享车辆的状态信息，得到共享车辆的疑似异常次数。当共享车辆的疑似异常次数大于或等于预设阈值时，确定共享车辆为故障车辆，并发送针对故障车辆的预警信息。通过根据共享车辆的状态信息实时的、主动的更新车辆的疑似异常次数，从而可以在车辆的疑似异常次数大于或等于预设阈值时，将共享车辆确定为故障车辆，通过对每个共享车辆均执行上述流程，从而可以实现对路面上的共享车辆的状态的全面检测。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1为本公开实施例提供的共享车辆的开锁系统示意图；

图2为本公开实施例提供的共享车辆的关锁系统示意图；

图3为本公开其中一实施例提供的共享车辆状态检测方法的流程图；

图4为本公开实施例提供的疑似异常次数的一种确定方式示意图；

图5为本公开实施例提供的疑似异常次数的另一种确定方式示意图；

图6为本公开实施例提供的疑似异常次数的又一种确定方式示意图；

图7为本公开实施例提供的共享车辆状态检测的流程示意图；

图8为本公开实施例提供的共享车辆状态检测装置的结构示意图；

图9为本公开实施例提供的共享车辆状态检测设备的硬件结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

下面以具体地实施例对本公开的实施例的技术方案以及本公开的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开的实施例的实施例进行描述。

首先结合图1和图2对本公开中的系统进行介绍，图1为本公开实施例提供的共享车辆的开锁系统示意图，图2为本公开实施例提供的共享车辆的关锁系统示意图。

如图1所示，该系统包括：

终端设备101、服务器102、以及车辆103。

其中，终端设备101例如可以是计算机设备、平板电脑或移动电话(或称为“蜂窝”电话)等，终端设备还可以是便携式、袖珍式、手持式、计算机内置的移动装置或设备，此处不做特别限制。

在本实施例中，终端设备101和服务器102之间，以及服务器102与车辆103之间会进行交互，其中交互的方式例如可以通过无线网络，该无线网络可以是2G网络、3G网络、4G网络或者5G网络、无线保真(Wireless Fidelity，简称WIFI)网络等。

本实施例对交互的具体类型或者具体形式并不做限定，只要其能够实现服务器和终端设备交互的功能即可。

在一种可能的实现方式中，可以参照图1中的实现，车辆103上可以设置有二维码和电子锁，用户可以通过终端设备101扫描车辆103的二维码，并根据扫描的二维码得到的信息生成开锁请求，其中开锁请求中例如可以携带有车辆103的标识信息，并且终端设备101向服务器102发送该开锁请求。

服务器102在接收到终端设备101发送的开锁请求之后，可以根据开锁请求确定车辆103的标识信息，并根据车辆103的标识信息向车辆103发送开锁指令。

此时车辆103的电子锁可以根据该开锁指令进行开锁，在开锁之后向服务器102返回开锁成功的信息。

接着服务器102可以向终端设备101发送可以开始使用车辆103的指示信息，此时用户就可以正常使用该车辆了，并且在终端设备101上还可以显示有计时、计费等信息。

并且，车辆还可以向服务器发送车辆的状态信息，其中，车辆的状态信息例如可以包括车辆定时上报的心跳数据，还例如可以包括车辆在骑行过程中上报的车辆骑行的相关数据。

上述结合图1介绍了共享车辆的开锁流程，下面结合图2对共享车辆的关锁流程进行介绍：

参见图2，该系统包括：

终端设备201、服务器202、以及车辆203，各个设备的实现方式以及互相之间的交互方式与上述图1介绍的类似，此处不再赘述。

在一种可能的实现方式中，可以参照图2中的实现，用户可以通过终端设备201生成关锁请求，例如可以通过终端设备点击客户端中的关锁按钮，其中关锁请求中例如可以携带有车辆203的标识信息，并且终端设备201向服务器202发送该关锁请求。

服务器202在接收到终端设备201发送的关锁请求之后，可以根据关锁请求确定车辆203的标识信息，并根据车辆203的标识信息向车辆203发送关锁指令。

此时车辆203的电子锁可以根据该关锁指令进行关锁，在关锁之后向服务器102返回关锁成功的信息。

以及，服务器202可以向终端设备201的客户端返回关锁成功，以使得用户确定车辆关锁完成。

在上述介绍的系统的基础上，下面对本公开涉及的背景技术进行进一步的介绍：

随着共享技术的不断发展，共享车辆也成为了一种非常普遍的出行方式，当共享车辆被投放到路面上以后，为了保证车辆的可用性以及用户骑行的安全性，还应该对共享车辆的状态进行检测，针对存在故障或者问题的共享车辆进行及时的检查和维修，因此对各个共享单车的状态进行检测就显得尤为重要。

目前，现有技术中对共享单车的状态进行检测时，通常有以下两种实现方式：

一种是在用户骑行某一个车辆之前或者骑行结束之后，通过客户端向用户提供调查问卷，以询问用户当前车辆是否存在故障，从而收集用户提供的数据，以确定车辆的状态。

然而，当前这种实现方式中，是否要填写调查问卷完全取决于用户的意愿，通常用户在发现一辆存在故障的车辆之后，都会急于寻找下一辆可用的车，因此依赖于用户上报以确定车辆状态，无法实现对共享单车的状态的全面检测。

另一种实现方式是通过维修人员对路面上的车辆进行抽检，以确定车辆的状态。

然而，这种实现方式中人员也是只能进行抽检，无法实现对共享单车的状态的全面检测，同时维修人员一般是在晚上作业，在调度和换电的同时对车辆进行检测，因此缺乏实时监测的能力。

基于上述介绍的内容，可以确定的是，现有技术的实现方式无法实现主动的实现对共享车辆的状态的全面检测。

针对现有技术中的问题，本公开提出了如下技术构思：利用用户的骑行行为产生的数据进行分析，从而主动全面的实现对车辆状态的检测。

下面结合具体的实施例对本公开提供的共享车辆状态检测方法进行详细介绍，首先结合图3进行介绍，图3为本公开其中一实施例提供的共享车辆状态检测方法的流程图。

如图3所示，该方法包括：

S301、获取共享车辆发送的共享车辆的状态信息。

在本实施例中，共享车辆会向云端服务器上报自身的状态信息，其中共享车辆的状态信息用于指示共享车辆的骑行状态、电子锁状态等。

在一种可能的实现方式中，共享车辆的状态信息例如可以包括开锁信息，其中开锁信息例如可以为上述图1中的“返回开锁成功”的信息，其中开锁信息是在共享车辆确定电子锁打开之后发送的；以及共享车辆的状态信息还例如可以包括关锁信息，其中关锁信息例如可以为上述图2中的“返回关锁成功”的信息，其中关锁信息是在共享车辆确定电子锁关闭之后发送的。

在另一种可能的实现方式中，共享车辆例如可以在骑行期间发送车辆骑行的相关状态信息，其中共享车辆的状态信息例如可以包括如下中的至少一种：全球定位系统(Global Positioning System，GPS)位置、骑行速度、骑行加速度、骑行距离、是否触发刹车、踏板的踩踏情况等。

在再一种可能的实现方式中，共享车辆例如可以在定时上报心跳数据，此时服务器可以根据心跳数据，获取共享车辆的状态数据，可以理解的是，无论共享车辆是否处于骑行状态，共享车辆均会定时上报心跳数据，其中，心跳数据例如可以包括如下中的至少一种：GPS位置、电量。

本实施例对共享车辆的状态信息的具体实现方式不做特别限制，凡是用于指示共享车辆的状态的信息均可以作为本实施例中的状态信息，其各种可能的实现方式可以根据实际需求进行扩展。

S302、根据共享车辆的状态信息，得到共享车辆的疑似异常次数。

在本实施例中，共享车辆的状态信息可以指示共享车辆的状态，当共享车辆的状态信息指示共享车辆的状态不正常是，例如可以更新共享车辆的疑似异常此时。

例如，当共享车辆的加速度超过正常加速度的范围时，例如加速度过大或者加速度过小，可以表明当前的共享车辆可能存在故障，则可以将共享车辆的疑似异常次数加1。

或者，当共享车辆的骑行距离过短时，则表明用户骑行这个车辆只骑了很短的一段距离，则表明这辆车可能存在故障，同样可以将共享车辆的疑似异常次数加1。

在其余可能的实现方式中，还可以根据具体的故障情况更新共享车辆的疑似异常次数，例如共享车辆发生较为严重的故障时，比如说没有触发刹车，则可以将共享车辆的疑似异常次数加5或者加10，以快速将该车辆确定为疑似故障的车辆。

在实际实现过程中，根据共享车辆的状态信息更新共享车辆的疑似异常次数的实现方式可以根据实际需求进行扩展，只要共享车辆的状态信息指示车辆存在异常，就可以累加共享车辆的疑似异常次数。

S303、当共享车辆的疑似异常次数大于或等于预设阈值时，确定共享车辆为故障车辆，并发送针对故障车辆的预警信息。

通过主动的、实时的更新共享车辆的疑似异常次数，从而在共享车辆的疑似异常次数大于或等于预设阈值时，确定共享车辆为故障车辆，其中，预设阈值可以根据实际需求进行选择，本实施例对此不做限制。

在本实施例中，在确定当前的共享车辆为故障车辆之后，可以发送针对当前故障车辆的预警信息，在一种可能的实现方式中，例如可以在用户针对当前共享车辆进行扫码之后，向用户的客户端发送当前故障车辆的预警信息，以告知用户当前车辆为故障车辆，建议用户寻找其余正常车辆。

或者在另一种可能的实现方式中，还可以通过向管理人员或者维修人员发送故障车辆的预警信息，以使得管理人员或者维修人员对故障车辆进行及时的检查和维修。

本公开实施例提供的共享车辆状态检测方法，包括：获取共享车辆发送的共享车辆的状态信息。根据共享车辆的状态信息，得到共享车辆的疑似异常次数。当共享车辆的疑似异常次数大于或等于预设阈值时，确定共享车辆为故障车辆，并发送针对故障车辆的预警信息。通过根据共享车辆的状态信息实时的、主动的更新车辆的疑似异常次数，从而可以在车辆的疑似异常次数大于或等于预设阈值时，将共享车辆确定为故障车辆，通过对每个共享车辆均执行上述流程，从而可以实现对路面上的共享车辆的状态的全面检测。

在上述实施例的基础上，下面对根据共享车辆的状态信息，得到共享车辆的疑似异常次数的几种可能的实现方式进行说明，

首先结合图4进行说明，图4为本公开实施例提供的疑似异常次数的一种确定方式示意图。

如图4所示，该方法包括：

S401、在获取到共享车辆的关锁信息后，判断共享车辆是否存在骑行距离，若是，则执行S402，若否，则执行S405。

其中，当服务器接收到共享车辆发送的关锁成功的信息时，可以获取到共享车辆的关锁信息，可以理解的是，当获取到共享车辆的关锁信息时，表明当前用户针对这辆共享车辆的骑行已经结束了。

其中，当用户在扫码解锁这辆共享车辆之后，若完全没有骑行就立即扫码锁车了，则有可能是用户扫码解锁之后，发现车辆损坏，因此本实施例中在获取到共享车辆的关锁信息后，判断共享车辆是否存在骑行距离。

S402、判断共享车辆的骑行距离是否小于预设距离，若是，则执行S403，若否，则执行S404。

在一种可能的情况下，若共享车辆存在骑行距离，则表明用户骑行共享车辆移动了一段距离，然而，若共享车辆的骑行距离比距较短，则表明有可能是用户扫码用车时，车辆没有肉眼可见的故障，但是在用户骑行了很短的一段距离后，发现车辆有损坏，从而进行扫码还车，在这种情况下，共享车辆仍然可能存在故障。

因此本实施例中进一步判断共享车辆的骑行距离是否小于预设距离，其中，预设距离的具体设置可以根据实际需求进行选择，本实施例对此不做特别限制。

S403、将共享车辆的疑似异常次数加N，其中，N为大于等于1的整数。

在一种可能的实现方式中，若共享车辆的骑行距离小于预设距离，则表明当前共享车辆可能存在故障，因此将该共享车辆的疑似异常次数加N，其中，N为大于等于1的整数，N的具体实现可以根据实际需求进行选择，N例如可以为1。

S404、将共享车辆的疑似异常次数减N。

在另一种可能的实现方式中，若共享车辆的骑行距离不小于预设距离，则表明用户这次扫码换车的过程是正常的使用了这个共享车辆，为了保证疑似异常次数的准确性，减少误检测，可以将该共享车辆的疑似异常次数减N，从而有效提升故障车辆确定的准确性。

S405、将共享车辆的疑似异常次数加N。

其中，若共享车辆不存在骑行距离，则表明共享车辆是在开锁之后没有骑行就关锁了，则表明共享车辆可能存在故障，从而将共享车辆的疑似异常次数加N。

本公开实施例提供的共享车辆状态检测方法，包括：在获取到共享车辆的关锁信息后，判断共享车辆是否存在骑行距离，若是，则判断共享车辆的骑行距离是否小于预设距离，若是，则将共享车辆的疑似异常次数加N。若否，则将共享车辆的疑似异常次数减N。若共享车辆的骑行距离不小于预设距离，则将共享车辆的疑似异常次数减N。通过根据共享车辆的骑行距离，更新共享车辆的疑似异常次数，从而能够针对性的判断车辆是否存在骑行，以及车辆的骑行距离是否正常的情况，以有效保证疑似异常次数的确定的准确性。

在上述实施例的基础上，本公开实施例提供的共享车辆状态检测方法，还可以通过判断各个状态信息是否存在异常从而更新疑似异常次数，下面结合图5进行说明，图5为本公开实施例提供的疑似异常次数的另一种确定方式示意图。

如图5所示，该方法包括：

S501、判断各状态信息是否存在异常，若是，则执行S502，若否，则执行S503。

在一种可能的实现方式中，共享车辆在骑行期间上报的某个状态信息的数值一直保持不变，或者达不到预期的值，则表明共享车辆可能存在故障。

例如共享车辆在正常骑行时，加速度都会有一个合理且固定的加速度范围，但是在存在故障的车辆在骑行期间，加速度可能始终达不到上述的加速度范围，或者加速度很大，则很有可能是车辆的电池或者驱动电机存在问题，此情况表明该值所对应的硬件设备存在问题，尽管这时车辆不影响骑行，但是车辆会存在安全隐患，因此同样需要更新疑似异常次数。

可以理解的是，各个状态信息均存在各自的正常情况，因此本实施例中，因此可以通过判断各个状态信息是否存在异常，从而对车辆的疑似异常次数进行更新。

例如针对骑行加速度，可以实时判断车辆的骑行加速度是否在预设加速度范围内；再例如针对骑行速度，可以实时判断车辆的骑行速度是否在预设速度范围内；再例如可以判断是否触发刹车、踏板是否接收到踩踏等；再例如电量是否

在实际实现过程中，各个状态信息对应的正常情况可以根据实际需求进行设定，例如预设加速度范围、预设速度范围均可以根据实际情况选择，本实施例对各个状态信息的正常情况不做限制。

S502、将车辆的疑似异常次数加N，其中，N为大于等于1的整数。

在一种可能的情况下，若任一个状态信息存在异常，则将车辆的疑似异常次数加N。

S503、保持疑似异常次数不变。

在另一种可能的情况下，若各个状态信息均不存在异常，则可以确定当前车辆暂时不存在故障，从而保持疑似异常次数不变。

本公开实施例提供的共享车辆状态检测方法，包括：判断各状态信息是否存在异常，若是，则将车辆的疑似异常次数加N。若否，则保持疑似异常次数不变。通过判断车辆的状态信息是否存在异常，更新共享车辆的疑似异常次数，从而能够针对性的判断可以骑行，但是硬件可能存在故障的车辆，以实现对车辆状态的精确检测，以有效保证疑似异常次数的确定的准确性。

在上述实施例的基础上，可以理解的是，若在一片停车区域中，大部分的车辆都在被骑出骑进，但唯独有少部分车辆始终没有被骑行，则这一部分没有被骑行的车辆很有可能存在故障。

基于此，本公开实施例提供的共享车辆状态检测方法，还可以通过判断当前共享车辆所在停车区域的各个车辆是否刷新，从而确定当前共享车辆的周边车辆的疑似异常次数，从而能够实现对投放在路面上的车辆的全面检测，下面结合图6进行说明，图6为本公开实施例提供的疑似异常次数的又一种确定方式示意图。

如图6所示，该方法包括：

S601、在获取到共享车辆的开锁信息后，若共享车辆所在的停车区域存在未刷新的车辆，则判断未刷新的车辆是否为新进入当前停车区域的车辆，若是，则执行S602，若否，则执行S601。

在本实施例中，当车辆向服务器发送开锁信息或者关锁信息之后，服务器均会对共享车辆进行刷新，以表明当前车辆被使用了，因此在获取到针对当前共享车辆的开锁信息之后，服务器可以判断当前共享车辆所在的停车区域的其余车辆是否被刷新，在一种可能的实现方式中，例如可以判断是否存在预设时长内未被刷新的车辆，从而判断是否存在长时间未被骑行的车辆。

例如当前获取到共享车辆A的开锁信息，其中共享车辆A位于停车区域1,则可以判断停车区域1中的其余共享车辆是否被刷新，若停车区域1中存在未被刷新的车辆，则表明当前停车区域存在长时间未被骑行的车辆。

此时可以进一步地判断未刷新的车辆是否为新进入当前停车区域的车辆，其中，当一个车辆被新投放到一个停车区域时，因为是新进入停车区域的，因此暂时没有被刷新可以认为是正常状态。

S603、保持疑似异常次数不变。

在一种可能的实现方式中，若未刷新的车辆是新进入当前停车区域的车辆，则可以认为这部分车辆暂时还没有刷新是正常的，因此可以保持疑似异常次数不变。

S602、将未刷新的车辆的疑似异常次数加N，其中，N为大于等于1的整数。

在另一种可能的实现方式中，若未刷新的车辆不是新进入当前停车区域的车辆，则表明当前未刷新的车辆长时间的存在于当前的停车区域，并且长时间未被骑行，则这部分未刷新的车辆很有可能存在故障，从而可以将未刷新的车辆的疑似异常次数加N。

本公开实施例提供的共享车辆状态检测方法，包括：在获取到共享车辆的开锁信息后，若共享车辆所在的停车区域存在未刷新的车辆，则判断未刷新的车辆是否为新进入当前停车区域的车辆，若是，则保持疑似异常次数不变。若否，则将未刷新的车辆的疑似异常次数加N。通过对开锁的共享车辆周围的其余车辆的刷新状态进行判断，从而可以有效识别出停车区域中长时间未被骑行的车辆，并将这部分车辆的疑似异常次数进行累加，以实现后续根据疑似异常次数确定故障车辆，从而能够有效保证对共享车辆的状态的全面性检测。

上述实施例介绍了根据共享车辆的状态信息确定疑似异常次数的几种可能的实现方式，上述介绍的更新疑似异常次数，均是将疑似异常次数加N，其中，N为大于等于1的整数，N的具体实现可以根据实际需求进行选择。

以及，还可以根据状态信息的异常情况的程度，增加不同数量的疑似异常次数，其实现方式可以根据实际需求进行扩展，以及根据状态信息确定疑似异常次数的实现方式同样可以根据实际需求进行扩展。

例如状态信息中不包括骑行距离时，例如可以根据开锁时的GPS位置和关锁时的GPS位置确定车辆是否被骑行，以及车辆的骑行距离是否小于预设距离，各种可能的实现方式可以根据实际需求扩展，只要在状态信息指示车辆可能存在异常时，将车辆的疑似异常次数累加即可。

本公开实施例中通过累加疑似异常次数，在疑似异常次数大于或等于预设阈值时，才将共享车辆确定为故障车辆，从而能够有效提升确定故障车辆的准确性，以避免频繁的将共享车辆确定为故障车辆，导致确定的准确性较低的问题。

在上述实施例的基础上，下面结合图7对本公开实施例提供的各种可能的判断情况结合在一起进行说明，图7为本公开实施例提供的共享车辆状态检测的流程示意图。

参见图7：

可以在检测到关锁事件时，判断车辆是否存在骑行距离，若没有，则将疑似异常次数累加，若有，则进一步判断车辆的骑行是否为短距离骑行，若是，则将疑似异常次数累加，若否，则将疑似异常次数递减，其具体的实现方式与上述图4实施例介绍的内容相同，此处不再赘述。

以及可以根据车辆上报的状态数据，判断各个状态数据是否存在异常，若存在异常的状态数据，则将当前车辆的疑似异常次数进行累加，其实现方式与上述介绍的图5实施例的实现方式相同，此处不再赘述。

进一步地，当疑似异常次数达到预设阈值时，将当前的共享车辆确定为故障车辆，并针对故障车辆进行预警。

可以理解的是，服务器对于投放在路面上的每一辆车辆均执行上述的判断流程，从而能够实现主动、实时、全面的对共享车辆的状态进行检测。

在上述实施例的基础上，为了进一步地提升车辆状态检测的准确率，本公开提供的共享车辆状态检测方法还可以包括：

在确定共享车辆为故障车辆之后，当接收到针对故障车辆的开锁请求信息或者关锁请求信息时，向发送请求信息的终端设备发送询问信息，询问信息用于确定故障车辆是否存在异常。

其中，假设当前将共享车辆A确定为故障车辆，则在用户对车辆A进行扫码开锁或者进行关锁时，可以通过客户端向用户发送询问信息，以询问用户当前车辆是否损坏，通过收集用户信息，可以进一步地提升车辆状态检测的准确率。

或者，还可以在疑似异常的情况发生时，立即通过客户端向用户发送询问信息，比如说车辆A被多次开锁之后的短时间内进行关锁，则此时可以向用户发送询问信息，以询问当前的车辆是否发生故障，从而提升收集到的信息的实时性和准确性。

在上述实施例的基础上，为了进一步的车辆状态的检测的准确率以及及时的维修故障车辆，本公开提供的共享车辆状态检测方法还可以包括：

当共享车辆的疑似异常次数大于或等于预设阈值的第一倍数时，触发生成检查故障车辆的工单。

例如共享车辆的疑似异常次数大于或等于预设阈值的0.8倍时，可以触发生成检查故障车辆的工单，从而使得维修人员针对性的检查该故障车辆，以提升故障车辆检测的准确性，同时在该车辆的确发生故障时，也可以及时的保证车辆的维修，从而有效提升车辆的可用性。

在上述实施例的基础上，为了进一步提升车辆状态的检测准确性，本公开提供的共享车辆状态检测方法还可以包括：

若所述故障车辆周围存在至少一个正常车辆，则当接收到针对所述正常车辆的开锁请求时，向发送所述开锁请求的终端设备发送当前正常车辆不可用的提示信息。

其中，当确定了某个故障车辆时，为了进一步保证确定的准确性，可以在该故障车辆的周围存在至少一个正常车辆时，当用户针对正常车辆进行扫码开锁时，向用户的终端设备发送当前的正常车辆不可用的提示信息，其中提示信息例如可以为当前的正常车辆已被预订的提示信息。

从而可以引导用户对故障车辆进行扫码开锁，当用户对故障车辆进行扫码开锁之后，又立即进行关锁了，或者骑行了很短的距离之后就关锁了，则可以确定当前故障车辆的确存在异常，则可以针对性的对这辆车辆进行快速的维修，从而提升确定故障车辆的准确性，以及提升故障车辆维修的效率。

图8为本公开实施例提供的共享车辆状态检测装置的结构示意图。如图8所示，该装置80包括：获取模块801、处理模块802以及确定模块803。

获取模块801，用于获取共享车辆发送的所述共享车辆的状态信息；

处理模块802，用于根据所述共享车辆的状态信息，得到所述共享车辆的疑似异常次数；

确定模块803，用于当所述共享车辆的疑似异常次数大于或等于预设阈值时，确定所述共享车辆为故障车辆，并发送针对所述故障车辆的预警信息。

在一种可能的设计中，所述状态信息包括如下中的至少一种：全球定位系统GPS位置、电量、骑行速度、骑行加速度、骑行距离、是否触发刹车、关锁信息、开锁信息。

在一种可能的设计中，所述状态信息为所述共享车辆在骑行期间发送的；或者，

所述状态信息为所述共享车辆定时发送的。

在一种可能的设计中，所述处理模块802具体用于：

在获取到所述共享车辆的关锁信息后，判断所述共享车辆是否存在骑行距离；

若不存在，则将所述共享车辆的疑似异常次数加N，其中，N为大于等于1的整数。

在一种可能的设计中，若所述共享车辆存在骑行距离，则所述处理模块802还用于：

判断所述共享车辆的骑行距离是否小于预设距离；

若是，则将所述共享车辆的疑似异常次数加N；

若否，则将所述共享车辆的疑似异常次数减N。

在一种可能的设计中，所述处理模块802具体用于：

判断各所述状态信息是否存在异常；

若是，则将所述车辆的疑似异常次数加N，其中，N为大于等于1的整数。

在一种可能的设计中，所述处理模块802还用于：

在获取到所述共享车辆的开锁信息后，若所述共享车辆所在的停车区域存在未刷新的车辆，则判断所述未刷新的车辆是否为新进入当前停车区域的车辆；

若否，则将所述未刷新的车辆的疑似异常次数加N，其中，N为大于等于1的整数。

在一种可能的设计中，所述处理模块802还用于：

在所述确定所述共享车辆为故障车辆之后，当接收到针对所述故障车辆的开锁请求信息或者关锁请求信息时，向发送所述请求信息的终端设备发送询问信息，所述询问信息用于确定所述故障车辆是否存在异常。

在一种可能的设计中，所述处理模块802还用于：

当所述共享车辆的疑似异常次数大于或等于所述预设阈值的第一倍数时，触发生成检查所述故障车辆的工单。

在一种可能的设计中，所述处理模块802还用于：

若所述故障车辆周围存在至少一个正常车辆，当接收到针对所述正常车辆的开锁请求时，向发送所述开锁请求的终端设备发送当前正常车辆不可用的提示信息。

在一种可能的设计中，所述不可用的提示信息为所述正常车辆已被预订的提示信息。

本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

图9为本公开实施例提供的共享车辆状态检测设备的硬件结构示意图，如图9所示，本实施例的共享车辆状态检测90包括：处理器901以及存储器902；其中

存储器902，用于存储计算机执行指令；

处理器901，用于执行存储器存储的计算机执行指令，以实现上述实施例中共享车辆状态检测方法所执行的各个步骤。具体可以参见前述方法实施例中的相关描述。

可选地，存储器902既可以是独立的，也可以跟处理器901集成在一起。

当存储器902独立设置时，该共享车辆状态检测设备还包括总线903，用于连接所述存储器902和处理器901。

本公开实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上共享车辆状态检测设备所执行的共享车辆状态检测方法。

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

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本公开各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本公开附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开的实施例旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。

Claims (24)

1.一种共享车辆状态检测方法，其特征在于，包括：

获取共享车辆发送的所述共享车辆的状态信息；

根据所述共享车辆的状态信息，得到所述共享车辆的疑似异常次数；

当所述共享车辆的疑似异常次数大于或等于预设阈值时，确定所述共享车辆为故障车辆，并发送针对所述故障车辆的预警信息。

2.根据权利要求1所述的方法，其特征在于，所述状态信息包括如下中的至少一种：全球定位系统GPS位置、电量、骑行速度、骑行加速度、骑行距离、是否触发刹车、关锁信息、开锁信息。

3.根据权利要求1或2所述的方法，其特征在于，所述状态信息为所述共享车辆在骑行期间发送的；或者，

所述状态信息为所述共享车辆定时发送的。

4.根据权利要求3所述的方法，其特征在于，所述根据所述共享车辆的状态信息，得到所述共享车辆的疑似异常次数，包括：

在获取到所述共享车辆的关锁信息后，判断所述共享车辆是否存在骑行距离；

若不存在，则将所述共享车辆的疑似异常次数加N，其中，N为大于等于1的整数。

5.根据权利要求4所述的方法，其特征在于，若所述共享车辆存在骑行距离，则所述方法还包括：

判断所述共享车辆的骑行距离是否小于预设距离；

若是，则将所述共享车辆的疑似异常次数加N；

若否，则将所述共享车辆的疑似异常次数减N。

6.根据权利要求3所述的方法，其特征在于，所述根据所述共享车辆的状态信息，得到所述共享车辆的疑似异常次数，包括：

判断各所述状态信息是否存在异常；

若是，则将所述车辆的疑似异常次数加N，其中，N为大于等于1的整数。

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

在获取到所述共享车辆的开锁信息后，若所述共享车辆所在的停车区域存在未刷新的车辆，则判断所述未刷新的车辆是否为新进入当前停车区域的车辆；

若否，则将所述未刷新的车辆的疑似异常次数加N，其中，N为大于等于1的整数。

8.根据权利要求1所述的方法，其特征在于，所述确定所述共享车辆为故障车辆之后，所述方法还包括：

当接收到针对所述故障车辆的开锁请求信息或者关锁请求信息时，向发送所述请求信息的终端设备发送询问信息，所述询问信息用于确定所述故障车辆是否存在异常。

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

当所述共享车辆的疑似异常次数大于或等于所述预设阈值的第一倍数时，触发生成检查所述故障车辆的工单。

10.根据权利要求1所述的方法，其特征在于，若所述故障车辆周围存在至少一个正常车辆，所述方法还包括：

当接收到针对所述正常车辆的开锁请求时，向发送所述开锁请求的终端设备发送当前正常车辆不可用的提示信息。

11.根据权利要求10所述的方法，其特征在于，所述不可用的提示信息为所述正常车辆已被预订的提示信息。

12.一种共享车辆状态检测装置，其特征在于，包括：

获取模块，用于获取共享车辆发送的所述共享车辆的状态信息；

处理模块，用于根据所述共享车辆的状态信息，得到所述共享车辆的疑似异常次数；

确定模块，用于当所述共享车辆的疑似异常次数大于或等于预设阈值时，确定所述共享车辆为故障车辆，并发送针对所述故障车辆的预警信息。

13.根据权利要求12所述的装置，其特征在于，所述状态信息包括如下中的至少一种：全球定位系统GPS位置、电量、骑行速度、骑行加速度、骑行距离、是否触发刹车、关锁信息、开锁信息。

14.根据权利要求12或13所述的装置，其特征在于，所述状态信息为所述共享车辆在骑行期间发送的；或者，

所述状态信息为所述共享车辆定时发送的。

15.根据权利要求14所述的装置，其特征在于，所述处理模块具体用于：

在获取到所述共享车辆的关锁信息后，判断所述共享车辆是否存在骑行距离；

若不存在，则将所述共享车辆的疑似异常次数加N，其中，N为大于等于1的整数。

16.根据权利要求15所述的装置，其特征在于，若所述共享车辆存在骑行距离，则所述处理模块还用于：

判断所述共享车辆的骑行距离是否小于预设距离；

若是，则将所述共享车辆的疑似异常次数加N；

若否，则将所述共享车辆的疑似异常次数减N。

17.根据权利要求14所述的装置，其特征在于，所述处理模块具体用于：

判断各所述状态信息是否存在异常；

若是，则将所述车辆的疑似异常次数加N，其中，N为大于等于1的整数。

18.根据权利要求14所述的装置，其特征在于，所述处理模块还用于：

在获取到所述共享车辆的开锁信息后，若所述共享车辆所在的停车区域存在未刷新的车辆，则判断所述未刷新的车辆是否为新进入当前停车区域的车辆；

若否，则将所述未刷新的车辆的疑似异常次数加N，其中，N为大于等于1的整数。

19.根据权利要求12所述的装置，其特征在于，所述处理模块还用于：

在所述确定所述共享车辆为故障车辆之后，当接收到针对所述故障车辆的开锁请求信息或者关锁请求信息时，向发送所述请求信息的终端设备发送询问信息，所述询问信息用于确定所述故障车辆是否存在异常。

20.根据权利要求12所述的装置，其特征在于，所述处理模块还用于：

当所述共享车辆的疑似异常次数大于或等于所述预设阈值的第一倍数时，触发生成检查所述故障车辆的工单。

21.根据权利要求12所述的装置，其特征在于，所述处理模块还用于：

若所述故障车辆周围存在至少一个正常车辆，当接收到针对所述正常车辆的开锁请求时，向发送所述开锁请求的终端设备发送当前正常车辆不可用的提示信息。

22.根据权利要求21所述的装置，其特征在于，所述不可用的提示信息为所述正常车辆已被预订的提示信息。

23.一种共享车辆状态检测设备，包括：存储器和处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令执行如权利要求1-11任一项所述的方法。

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

Images