车辆管理方法及应用服务器
技术领域
本发明涉及车辆管理技术,尤其涉及一种车辆管理方法及应用服务器。
背景技术
现有技术中车辆(以下以共享单车举例说明)与应用服务器间采用基于蜂窝的窄带物联网NB-Iot(Narrow Band Internet of Things,简称“NB-IoT”)模式进行通讯,该通讯模式的网络信号覆盖范围广,使得共享单车可达区域广。
然而,由于NB-Iot的网络信号覆盖范围广,使得共享单车可以被随意停放。若停放在非规范区域,会给车辆运营造成负担;若停放在隐蔽区域还会给车辆使用者造成用车不便等问题。为了解决上述问题,目前通过在车锁上加装全球定位系统(Global PositioningSystem,简称“GPS”)或者通过客户端发送GPS坐标以使应用服务器对共享单车的停放区域是否规范进行判断。
然而,随着共享单车投放量的增大,其与应用服务器间的GPS坐标信息交互以及应用服务器对该GPS坐标信息进行运算处理的步骤,加重了彼此间信息量的处理复杂性,进而影响到共享单车的响应效率,例如,开/闭锁的时间被延长,用户体验不好。
发明内容
本发明提供一种车辆管理方法及应用服务器,用于解决现有技术中需要对车辆的定位信息进行运算处理,使得车辆管理效率不高的技术问题。
本发明一个方面提供一种车辆管理方法,包括:
应用服务器根据地理区域特征,确定网络信号的覆盖范围;
若接收到目标车辆发送的第一开锁请求或第一锁车请求,确定所述目标车辆位于所述网络信号的覆盖范围内,向所述目标车辆返回第一开锁响应或第一锁车响应。
可选的,所述应用服务器根据地理区域特征,确定网络信号覆盖范围,包括:
根据地理区域特征,确定车辆停放范围;
调节低功耗广域网LPWAN的发射信号强度,以使所述车辆停放范围内接收到的所述LPWAN的网络信号强度满足预设的信号强度阈值;
则确定所述网络信号覆盖范围为所述车辆停放范围。
可选的,所述方法,还包括:
接收用户的客户端发送的第二开锁请求,所述第二开锁请求中包含有用户标识、所述目标车辆的标识;
将所述用户标识与所述目标车辆的标识对应存储到开锁等候队列中;
根据所述用户标识,向所述客户端发送开锁指示消息,以使用户根据所述开锁指示消息触发所述目标车辆向所述应用服务器发送所述第一开锁请求;
若所述应用服务器在第一预设时长内未接收到所述目标车辆发送的所述第一开锁请求,则将所述目标车辆的标识从所述开锁等候队列中清除;
向所述用户的客户端发送取消开锁的提示消息。
可选的,所述将所述用户标识与所述目标车辆的标识对应存储到开锁等候队列中之后,还包括:
接收目标车辆在其各自的轮询时间段发送的所述第一开锁请求,所述第一开锁请求中包含:所述目标车辆的标识;
若所述目标车辆的标识存在于所述开锁等候队列中,则向所述目标车辆发送所述第一开锁响应;
若所述应用服务器在第二预设时长内未接收到所述目标车辆发送的所述第一开锁请求,则将所述目标车辆的标识从所述开锁等候队列中清除;
向所述用户的客户端发送取消开锁的提示消息。
可选的,所述方法,还包括:
接收用户的客户端发送的第二锁车请求,所述第二锁车请求中包含:用户标识、地理位置信息;
确定是否接收到与所述用户标识对应的目标车辆发送的所述第一锁车请求;
若未收到,根据所述地理位置信息,确定所述目标车辆是否位于所述网络信号的覆盖范围内;
若不在,向所述用户的客户端发送在所述网络信号的覆盖范围内锁车的提示消息。
可选的,所述第二锁车请求中还包含:锁车视频或至少一幅锁车图片;所述根据所述地理位置信息,确定所述目标车辆是否位于所述网络信号的覆盖范围内之后,还包括:
若接收到所述锁车视频,且所述目标车辆位于所述网络信号的覆盖范围内,则根据上下行数据传输时间间隔在所述锁车视频中获取至少两幅帧图像;
确定所述至少两幅帧图像中是否包含有锁车图像;
若包含,则确认车锁故障,向所述用户的客户端发送确认锁车的所述提示消息;
或者,
若接收到所述至少一幅锁车图片,且所述目标车辆位于所述网络信号的覆盖范围内,确认所述至少一幅锁车图片中是否包含有锁车图像,若包含,则确认车锁故障,向所述用户的客户端发送确认锁车的提示消息。
可选的,所述若接收到所述至少一幅锁车图片,且所述目标车辆位于所述网络信号的覆盖范围内,确认所述至少一幅锁车图片中是否包含有锁车图像,包括:
根据所述目标车辆的车锁类型,确定所述至少一幅锁车图片中是否包含有锁车图像;
若所述车锁类型为需要外力按住锁柄达到预设时长实现锁车的第一车锁类型,则在所述至少一幅锁车图片中根据上下行数据传输时间间隔确定至少两幅帧图像中包含有锁车图像,则确认车锁故障;
若所述车锁类型为无需外力按住锁柄实现锁车的第二车锁类型,则在一幅锁车图片中确定包含有锁车图像,则确认车锁故障。
可选的,所述锁车图像包括以下至少一种图像信息:
锁车灯标识图像、车锁锁柄位于闭合位置图像、用户锁车动作图像。
本发明另一个方面提供一种应用服务器,包括:
确定模块,用于根据地理区域特征,确定网络信号的覆盖范围;
接收模块,用于接收目标车辆发送的第一开锁请求或第一锁车请求;
所述确定模块,还用于当所述接收模块接收到目标车辆发送的第一开锁请求或第一锁车请求时,确定所述目标车辆位于所述网络信号的覆盖范围内;
发送模块,用于向所述目标车辆返回第一开锁响应或第一锁车响应。
可选的,所述确定模块,包括:
确定子模块,用于根据地理区域特征,确定车辆停放范围;
调节子模块,用于调节低功耗广域网LPWAN的发射信号强度,以使所述车辆停放范围内接收到的所述LPWAN的网络信号强度满足预设的信号强度阈值;
所述确定子模块,还用于确定所述网络信号覆盖范围为所述车辆停放范围。
可选的,还包括:
所述接收模块,还用于接收用户的客户端发送的第二开锁请求,所述第二开锁请求中包含有用户标识、所述目标车辆的标识;
存储模块,用于将所述用户标识与所述目标车辆的标识对应存储到开锁等候队列中;
所述发送模块,还用于根据所述用户标识,向所述客户端发送开锁指示消息,以使用户根据所述开锁指示消息触发所述目标车辆向所述应用服务器发送所述第一开锁请求;
清除模块,用于当所述接收模块在第一预设时长内未接收到所述目标车辆发送的所述第一开锁请求时,将所述目标车辆的标识从所述开锁等候队列中清除;
所述发送模块,还用于向所述用户的客户端发送取消开锁的提示消息。
可选的,所述接收模块,还用于接收目标车辆在其各自的轮询时间段发送的所述第一开锁请求,所述第一开锁请求中包含:所述目标车辆的标识;
所述发送模块,还用于当所述目标车辆的标识存在于所述开锁等候队列中时,向所述目标车辆发送所述第一开锁响应;
所述清除模块,还用于当所述应用服务器在第二预设时长内未接收到所述目标车辆发送的所述第一开锁请求时,将所述目标车辆的标识从所述开锁等候队列中清除;
所述发送模块,还用于向所述用户的客户端发送取消开锁的提示消息。
可选的,还包括:
所述接收模块,还用于接收用户的客户端发送的第二锁车请求,所述第二锁车请求中包含:用户标识、地理位置信息;
所述确定模块,还用于确定是否接收到与所述用户标识对应的目标车辆发送的所述第一锁车请求;若未收到,根据所述地理位置信息,确定所述目标车辆是否位于所述网络信号的覆盖范围内;
所述发送模块,还用于当所述确定模块确定所述目标车辆没有位于所述网络信号的覆盖范围内时,向所述用户的客户端发送在所述网络信号的覆盖范围内锁车的提示消息。
可选的,所述第二锁车请求中还包含:锁车视频或至少一幅锁车图片;还包括:
获取模块,用于当所述接收模块接收到所述锁车视频,且所述确定模块确定所述目标车辆位于所述网络信号的覆盖范围内时,根据上下行数据传输时间间隔在所述锁车视频中获取至少两幅帧图像;
所述确定模块,还用于确定所述至少两幅帧图像中是否包含有锁车图像;若包含,则确认车锁故障;
或者,
所述确定模块,还用于当所述接收模块接收到所述至少一幅锁车图片,且确定所述目标车辆位于所述网络信号的覆盖范围内时,确认所述至少一幅锁车图片中是否包含有锁车图像,若包含,则确认车锁故障;
所述发送模块,还用于在所述确定模块确定车锁故障后,向所述用户的客户端发送确认锁车的所述提示消息。
可选的,所述确定模块,具体用于根据所述目标车辆的车锁类型,确定所述至少一幅锁车图片中是否包含有锁车图像;若所述车锁类型为需要外力按住锁柄达到预设时长实现锁车的第一车锁类型,则在所述至少一幅锁车图片中根据上下行数据传输时间间隔确定至少两幅帧图像中包含有锁车图像,则确认车锁故障;若所述车锁类型为无需外力按住锁柄实现锁车的第二车锁类型,则在一幅锁车图片中确定包含有锁车图像,则确认车锁故障。
可选的,所述锁车图像包括以下至少一种图像信息:
锁车灯标识图像、车锁锁柄位于闭合位置图像、用户锁车动作图像。
本发明提供的车辆管理方法及应用服务器,该方法包括应用服务器根据地理区域特征,确定网络信号的覆盖范围;根据是否接收到目标车辆发送的第一开锁请求或第一锁车请求,确定目标车辆是否位于网络信号的覆盖范围内;若接收到,则向目标车辆返回第一开锁响应或第一锁车响应。该方法通过采用网络信号的覆盖范围对车辆规范停放的区域进行限定,使得仅有停放在规范区域内的车辆才能被正常的开锁或锁车,否则由于车辆不在规范停放区域而无法与控制该车辆开锁或锁车的应用服务器进行通讯,进而不能实现车辆的正常使用。该方法免去了现有技术中需要对车辆的地理位置信息进行运算处理的复杂步骤,减少了网络资源占用率,提升了车辆管理效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明一示例性实施例示出的车辆管理方法的流程图;
图2a为本发明另一示例性实施例示出的车辆管理方法的流程图;
图2b为图2a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的流程示意图;
图2c为图2a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的另一流程示意图;
图3a为本发明另一示例性实施例示出的车辆管理方法的流程图;
图3b为图3a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的流程示意图;
图4a为本发明另一示例性实施例示出的车辆管理方法的流程图;
图4b为图4a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的流程示意图;
图4c为图4a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的另一流程示意图;
图5为本发明一示例性实施例示出的应用服务器的结构示意图;
图6为本发明另一示例性实施例示出的应用服务器的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
图1为本发明一示例性实施例示出的车辆管理方法的流程图,本实施例中的车辆管理方法的执行主体为车辆管理方的应用服务器,其可以与车辆上配置的通信模块进行交互以对该车辆进行开锁和锁车的控制,其也可以与用户的客户端进行通讯,其中,用户的客户端可以设置在用户的移动设备内,例如,手机终端内,以实现接收客户端发送的用户的用车或锁车的指令。下文中的车辆包括但不限于机动车辆、自行车辆等,以下均已自行车为例进行方案的说明。具体的,如图1所示,本实施例中的车辆管理方法包括:
步骤101、应用服务器根据地理区域特征,确定网络信号的覆盖范围。
在本步骤中,所谓地理区域特征为车辆停放的实际地理区域的特征,例如,交通枢纽附近、公园门口、道路边等。根据车辆停放的实际场景,确定可以给予的网络信号的覆盖范围。例如,以地铁站为坐标中心,确定网络覆盖半径为10米,则在地铁站周边10米的范围内车辆与其后台的应用服务器之间可以进行通讯,该半径10米范围内为规范的车辆停放范围,超出该范围将没有网络信号的覆盖,从而基于网络信号的覆盖范围对车辆规范的停放范围进行限制。
步骤102、若接收到目标车辆发送的第一开锁请求或第一锁车请求,确定目标车辆位于网络信号的覆盖范围内。
在本步骤中,所谓目标车辆是指用户需要使用的车辆,通常来说,用户可以通过移动终端扫描车辆上的二维码或通过其他方式得到车辆的标识信息,并将该车辆的标识信息发送给应用服务器,应用服务器将用户的标识信息与该车辆的标识信息对应存储,则该车辆为目标车辆。以上为应用服务器与用户的客户端之间的交互,若要完成用户所希望的开锁或锁车的操作,需要目标车辆与应用服务器之间建立通讯连接,从而使得应用服务器下发的开锁或锁车指令可以传递给目标车辆。基于此,若目标车辆在前述的网络信号的覆盖范围内,则其可以与应用服务器建立网络通讯连接,若应用服务器接收其发送的第一开锁请求或第一锁车请求,则在确定满足开锁或锁车的条件后,可以指示目标车辆进行开锁或锁车的操作。但是,若目标车辆不在网络信号的覆盖范围内,则其无法与应用服务器建立网络通讯连接,应用服务器自然也不会接收到其发送的第一开锁请求或第一锁车请求,这样,如果目标车辆不在规范的车辆停放区域内,是无法执行开锁或锁车的操作的。
步骤103、向目标车辆返回第一开锁响应或第一锁车响应。
在本步骤中,应用服务器接收到目标车辆发送的第一开锁请求或第一锁车请求后,说明该目标车辆在规范的车辆停放区域内等待执行开锁或锁车操作,因此,应用服务器可以向其返回第一开锁响应或第一锁车响应,以使该目标车辆开锁或锁车。
在本步骤中,前述步骤102中阐述过,目标车辆是与用户有对应关系的车辆,因此,若应用服务器与目标车辆无法建立通讯连接,则其可能的原因包含该目标车辆不在网络信号的覆盖范围内的情况,应用服务器可以向用户的客户端发送提示消息,以告知用户本次用车被取消。其中,应用服务器与用户之间的通讯所基于的网络,和应用服务器与车辆之间的通讯所基于的网络不同。应用服务器与用户之间的通讯可以基于目前的移动互联网络,例如,第三代移动通信技术3G(3rd-Generation,简称“3G”)、第四代移动通信技术4G(the4th Generation mobile communication technology,简称“4G”)网络等。应用服务器与车辆之间的通讯可以基于分布式的信号覆盖范围可调节的网络进行通讯。
本实施例所提供的车辆管理方法,该方法包括应用服务器根据地理区域特征,确定网络信号的覆盖范围;根据是否接收到目标车辆发送的第一开锁请求或第一锁车请求,确定目标车辆是否位于网络信号的覆盖范围内;若接收到,则向目标车辆返回第一开锁响应或第一锁车响应;若未接收到,则向与目标车辆对应的客户端发送提示消息。该方法通过采用网络信号的覆盖范围对车辆规范停放的区域进行限定,使得仅有停放在规范区域内的车辆才能被正常的开锁或锁车,否则由于车辆不在规范停放区域而无法与控制该车辆开锁或锁车的应用服务器进行通讯,进而不能实现车辆的正常使用。该方法免去了现有技术中需要对车辆的地理位置信息进行运算处理的复杂步骤,减少了网络资源占用率,提升了车辆管理效率。
图2a为本发明另一示例性实施例示出的车辆管理方法的流程图,如图2a所示,在上一实施例的基础上,本实施例的车辆管理方法,具体包括:
步骤201、根据地理区域特征,确定车辆停放范围;调节低功耗广域网LPWAN(Low-Power Wide-Area Network,简称“LPWAN”)的发射信号强度,以使车辆停放范围内接收到的LPWAN的网络信号强度满足预设的信号强度阈值;则确定网络信号覆盖范围为车辆停放范围。
在本步骤中,根据地理区域特征,确定出车辆停放范围,然后调节LPWAN的发射功率,其中LoRaWan就是LPWAN的代表,具体可以通过调节LoRa基站的LoRa射频(RadioFrequency,简称“RF”)信号覆盖范围,使得信号仅在车辆停放范围内的强度满足预设的信号强度阈值,从而在该车辆停放范围外的网络信号强度不足以支持车辆与应用服务器之间的网络信号强度,使得车辆只能在信号覆盖范围内开关车锁,达到车辆管理的目的。
对于下行LoRa RF部分,可以根据所确定的车辆停放范围,设定几种不同的网络信号覆盖范围,例如,20m,50m,100m等。由于LoRa RF信号覆盖范围小,因此,功率小,能源消耗小,这就使得在车辆上所搭载的通讯模块的功耗较小,有利于节省车辆的耗电量,减少车辆维护的成本。
步骤202、接收用户的客户端发送的第二开锁请求,第二开锁请求中包含有用户标识、目标车辆的标识。
在本步骤中,用户需要用车时,可以通过客户端向应用服务器发送开锁请求(即该第二开锁请求),应用服务器可以基于3G/4G或者有线网络接收到用户的开锁请求,将请求中的用户标识,例如,用户注册该客户端时的账号或者用户的移动终端的号码(手机号码)等信息与目标车辆的标识对应存储。前面步骤102中已经阐述过目标车辆的标识可以由用户通过扫描车辆上的二维码等方式获取到。
步骤203、将用户标识与目标车辆的标识对应存储到开锁等候队列中。
在本步骤中,所谓开锁等候队列就是在应用服务器接收到用户的开锁请求后,将用户标识与目标车辆标识建立对应关系的队列。当应用服务器接收到车辆发送的开锁请求后,就可以到该队列中确定其是否有对应的用户标识,若存在,则向该目标车辆发送开锁指示,并启动对该用户标识对应用户的计费、用车计时等操作。
步骤204、根据用户标识,向客户端发送开锁指示消息,以使用户根据开锁指示消息触发目标车辆向应用服务器发送第一开锁请求。若应用服务器在第一预设时长内未接收到目标车辆发送的第一开锁请求,则执行步骤205和步骤206;若应用服务器在第一预设时长内接收到目标车辆发送的第一开锁请求,则执行步骤207。
在本步骤中,为了实现节能的目的,车辆上的通讯模块可以不采用轮询(Polling)的方式与应用服务器始终保持联系,而是仅在需要与应用服务器进行通讯时,才触发与其的连接。举例来说,车锁上可以设置有开锁键,当用户的客户端接收到应用服务器发送的开锁指示消息后,按动车锁上的开锁键,触发目标车辆向应用服务器发送开锁请求(第一开锁请求)。也就是说,在开锁键没有接收到用户的按压触发时,其不与应用服务器进行任何通讯,从而实现节约能耗的目的。上述通讯的建立可以基于LoRaWan网络的Class A通讯协议予以实现。使用LoRaWan中Class A协议,则必须等待车辆上传数据后,应用服务器才能对其下发数据,用户点按车锁的开锁键会触发上行数据传输,将车辆的信息和开锁触发信息通过LoRaWan发送至应用服务器,之后应用服务器根据是否存储有用户客户端发来的对应的开锁申请记录(第二开锁请求)来判断是否需要应答,如果车辆在随后接收到的下行传输内包含开锁的应答,则打开车锁,如果没有包含开锁应答,则不做任何操作。
步骤205、若应用服务器在第一预设时长内未接收到目标车辆发送的第一开锁请求,则将目标车辆的标识从开锁等候队列中清除。
步骤206、向用户的客户端发送取消开锁的提示消息。
在本步骤中,若应用服务器在一段时长范围内(第一预设时长)内未接收到目标车辆发送的第一开锁请求,则会将目标车辆的标识从开锁等候队列中清除。对于这种需要用户触发开锁键的情况,应用服务器未接收到目标车辆发送的第一开锁请求,可能是由于目标车辆不在网络信号的覆盖范围内,使得目标车辆的第一开锁请求不能到达应用服务器;也可能是用户改变用车主意未触发开锁键,或者车锁故障等原因,使得目标车辆的第一开锁请求未被发出;无论是哪种原因,若应用服务器在第一预设时长内未接收到车辆发送的第一开锁请求,则向用户的客户端发送提示消息,该提示消息可以包含有提示用户确认目标车辆是否为规范停放范围内的车辆的提示消息,并告知用户本次开锁被取消。
步骤207、若应用服务器在第一预设时长内接收到目标车辆发送的第一开锁请求,则向目标车辆返回第一开锁响应。
在本步骤中,若应用服务器在第一预设时长内接收到目标车辆发送的第一开锁请求,则检查开锁等候队列中是否有该目标车辆与用户标识之间的记录,若有,则返回第一开锁响应,该第一开锁响应通过LoRaWan下行传输至目标车辆,以使目标车辆解锁。同时,应用服务器可以向用户发送提示消息,提示用户开始计费。
图2b为图2a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的流程示意图,如图2b所示,其显示了目标车辆停放在网络信号覆盖范围内的情况下,三者的交互流程可以包括:
1、用户采用移动终端设备,如手机的扫描功能对目标车辆上的二维码进行扫描。
2、通过扫描获取到目标车辆的标识;
3、客户端向应用服务器发送开锁请求,开锁请求中包含有用户的标识以及目标车辆的标识;
4、应用服务器对用户的标识以及目标车辆的标识进行保存;
5、应用服务器提示用户可以触发车锁上的开锁键;
6、用户点击开锁键,目标车辆将车锁信息通过LoRaWan上行传输到应用服务器;
7、应用服务器根据用户发送的开锁请求查询记录;
8、若查询到目标车辆为用户请求开锁的车辆,则返回开锁命令;
9、向用户的客户端发送通知消息,提示用户开始计费。
图2c为图2a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的另一流程示意图,如图2c所示,其显示了应用服务器无法接收到目标车辆发送的锁车请求的情况下,三者的交互流程可以包括:
1、用户采用移动终端设备,如手机的扫描功能对目标车辆上的二维码进行扫描。
2、通过扫描获取到目标车辆的标识;
3、客户端向应用服务器发送开锁请求,开锁请求中包含有用户的标识以及目标车辆的标识;
4、应用服务器对用户的标识以及目标车辆的标识进行保存;
5、应用服务器提示用户可以触发车锁上的开锁键;
6、用户点击开锁键,但是目标车辆的车锁信息通过LoRaWan上行传输未达应用服务器;
7、应用服务器等待一段时间后,因未收到目标车辆发送的开锁请求,而将其从等待开锁的队列中清除,以使其他用户可以重新使用该目标车辆;
8、向用户的客户端发送通知消息,提示本次用车取消。
图3a为本发明另一示例性实施例示出的车辆管理方法的流程图,如图3a所示,在上述实施例的基础上,本实施例的车辆管理方法,具体包括:
步骤301、根据地理区域特征,确定车辆停放范围;调节低功耗广域网LPWAN的发射信号强度,以使车辆停放范围内接收到的LPWAN的网络信号强度满足预设的信号强度阈值;则确定网络信号覆盖范围为车辆停放范围。
步骤302、接收用户的客户端发送的第二开锁请求,第二开锁请求中包含有用户标识、目标车辆的标识。
步骤303、将用户标识与目标车辆的标识对应存储到开锁等候队列中。若应用服务器接收到目标车辆发送的第一开锁请求,则执行步骤304和步骤305;若应用服务器未接收到目标车辆发送的第一开锁请求,则执行步骤306和步骤307。
步骤301~步骤303与步骤201~步骤203的实现原理类似,在此不再赘述。
步骤304、接收目标车辆在其各自的轮询时间段发送的第一开锁请求,第一开锁请求中包含:目标车辆的标识。
在本步骤中,基于LoRaWan网络的Class B通讯协议,每个车辆与应用服务器之间都在其各自的轮询时间段保持上行通讯。所谓轮询也就是每个车辆在预定好的时间段依序与应用服务器联系,周而复始,每次到了自己的时间段就通过LoRaWan上行将自己的车辆标识传输至应用服务器。使用Class B通讯协议,其包含有Class A的随机接收窗口,还会在指定时间打开窗口,进行上下行数据传输,这种方式中车辆的车锁上可以不用设计开锁键,则其仅在各自预定好的时间段轮询向应用服务器发送检查请求;若车锁上安装开锁键,则其既可以在开锁键被触发时,采用Class A的随机窗口向应用服务器发送开锁请求,也可以等待自己的轮询时间段打开窗口向应用服务器发送开锁请求。应用服务器接收后会根据是否有用户客户端的开锁请求记录来判断是否下发开锁命令。Class B这种方式相较于上一实施例基于Class A通讯协议的方式,在节能方面稍欠;但是,通过始终与应用服务器保持通讯连接,可以使得管理方实时获知在规范停车区域内的车辆的数目信息,有利于车辆的管理。
步骤305、若目标车辆的标识存在于开锁等候队列中,则向目标车辆发送第一开锁响应。
在本步骤中,目标车辆轮询将标识信息通过LoRaWan上行传输至应用服务器后,应用服务器检查开锁等候队列中是否有目标车辆的标识,若有则向目标车辆返回第一开锁响应。同时,还可以向用户的客户端发送提示用户开始计费的提示消息。
步骤306、若应用服务器在第二预设时长内未接收到目标车辆发送的第一开锁请求,则将目标车辆的标识从开锁等候队列中清除。
在本步骤中,由于各个车辆在其轮询时间段与应用服务器通讯,因此,第二预设时长的设定可以参考车辆向应用服务器发送上行通讯消息的周期的时长。
步骤307、向用户的客户端发送取消开锁的提示消息。
在本步骤中,不同于基于Class A通讯协议的上一实施例,本实施例中目标车辆发送第一开锁请求不需要用户的触发,而是在各自轮询时间段自动发出,因此,若应用服务器没有在第二预设时长内接收到目标车辆的开锁请求,则说明两者间的通讯是断开的状态,则目标车辆很有可能是没有位于网络信号的覆盖范围内,应用服务器向与目标车辆对应的客户端发送提示消息,以提示用户确认目标车辆是否为规范停放范围内的车辆的提示消息,并告知用户本次开锁被取消。
图3b为图3a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的流程示意图,如图3b所示,三者在开锁过程中的交互流程可以包括:
1、用户采用移动终端设备,如手机的扫描功能对目标车辆上的二维码进行扫描。
2、通过扫描获取到目标车辆的标识;
3、客户端向应用服务器发送开锁请求,开锁请求中包含有用户的标识以及目标车辆的标识;
4、应用服务器对用户的标识以及目标车辆的标识进行保存;
5、目标车辆采用轮询将标识信息通过LoRaWan上行传输到应用服务器;
6、应用服务器根据用户发送的开锁请求查询记录;
7、若查询到目标车辆为用户请求开锁的车辆,则返回开锁命令;
8、向用户的客户端发送通知消息,提示用户开始计费。
图4a为本发明另一示例性实施例示出的车辆管理方法的流程图,如图4a所示,在上述实施例的基础上,本实施例的车辆管理方法,具体包括:
步骤401、根据地理区域特征,确定车辆停放范围;调节低功耗广域网LPWAN的发射信号强度,以使车辆停放范围内接收到的LPWAN的网络信号强度满足预设的信号强度阈值;则确定网络信号覆盖范围为车辆停放范围。
步骤402、应用服务器若接收到目标车辆发送的第一锁车请求,则确定目标车辆位于网络信号的覆盖范围内,向目标车辆返回第一锁车响应。
在本步骤中,应用服务器若接收到目标车辆发送的第一锁车请求,则说明目标车辆与应用服务器可以成功建立通讯连接,其在规范的停车范围内。应用服务器根据该第一锁车请求,可以检查在开锁过程中存储的目标车辆的标识与用户的标识,无论是否有记录,都返回第一锁车响应,以使目标车辆锁车。若有记录,则同时通知用户停止用车计费,若无记录,也发送锁车响应指示目标车辆锁车。
步骤403、应用服务器接收用户的客户端发送的第二锁车请求,第二锁车请求中包含有用户标识、地理位置信息。
在本步骤中,在步骤402中,第一锁车请求是由目标车辆发送给应用服务器的,但是若出现目标车辆不在网络覆盖范围内的情况,则该第一锁车请求无法到达应用服务器。若出现无法锁车的情况,用户可以向应用服务器发送第二锁车请求,以使应用服务器获知不能锁车的事件。该第二锁车请求中除了包含有用户标识,如手机号码、用户注册客户端的账号信息外,还可以包含有用户当前的地理位置信息;若用户开启了GPS定位功能,则该地理位置信息可由客户端从用户的手机终端内获取得到,并包含在该第二锁车请求中发送给应用服务器。
步骤404、确定是否接收到与用户标识对应的目标车辆发送的第一锁车请求。
在本步骤中,应用服务器根据第二锁车请求中的用户标识,确定与其对应的目标车辆的标识,进而可以对目标车辆是否发送了第一锁车请求进行判断。若确认收到了目标车辆发送的第一锁车请求,可以通知客户端再次触发锁车动作,以使目标车辆再次发送第一锁车请求。此种情况中说明目标车辆在网络覆盖范围内,其未接收到应用服务器的锁车响应可能是网络传输故障,也可能是车锁的接收装置发生故障,则可以通过用户锁车的再次触发,尝试与目标车辆相互通讯。无论是第一次未接收到,还是再次尝试后未接收到,都可以继续执行步骤405以确定发生何种故障。
步骤405、若未收到,根据地理位置信息,确定目标车辆是否位于网络信号的覆盖范围内;若不在,执行步骤406;若在,执行步骤407。
在本步骤中,地理位置信息可以被包含在第二锁车请求中发送,也可以通过应用服务器对未收到目标车辆的第一锁车请求进行确认后,提示用户发送的。该地理位置信息可以通过用户开启终端的GPS定位功能,客户端从用户的终端的GPS定位功能模块中获取到用户当前的位置信息,并将其包含在第二锁车请求中发送给应用服务器。
步骤406、向用户的客户端发送在网络信号的覆盖范围内锁车的提示消息。
若确定出用户当前所在位置不在规范停车的范围内,则向用户发送到指定的车辆规范停放地进行停车的提示消息。
步骤407、根据锁车视频或至少一幅锁车图片,确定是否车锁出现故障导致的无法锁车。
若用户当前地理位置在车辆规范停放地,则需要进一步对接收不到目标车辆发送的锁车请求的原因进行确认。如,是否用户未锁车而请求应用服务器为其停止计费,还是车锁发生锁车故障导致无法成功锁车。则此时需要用户上传锁车有关的视频或图片,以使应用服务器判断无法锁车的故障原因。
其中,该锁车视频或至少一幅锁车图片可以被包含在第二锁车请求中发送,也可以是应用服务器对目标车辆的地理位置信息确认后,提示用户发送的。
对于是接收锁车视频还是锁车图片可以根据车锁的类型予以判断,例如,若车锁类型为,需要外力按住锁柄达到预设时长实现锁车的第一车锁类型,则可以提示用户发送锁车视频;
锁车视频需要显示出用户手部持续按压在车锁的锁柄上,车锁处于闭合状态。但是由于视频的传输需要占用较多的网络资源,因此,可以由客户端对视频进行分帧操作,例如,根据上下行数据传输时间间隔,对客户端拍摄得到的锁车视频进行分帧操作,得到多幅锁车图片,以构成锁车视频的多幅帧图片取代视频发送给应用服务器。若客户端发送的是锁车视频,则上述分帧的操作也可以由应用服务器完成。其中,所谓上下行数据传输时间间隔是指,以LoRaWan的ClassA传输协议来说,节点从上行发送数据的时刻为起始时间点到节点留给下行返回数据的最后一个接收窗口的结束时刻为结束时间点,起始时间点与结束时间点之间的时间间隔;且上下行传输时间间隔内可以包含多个用于接收下行数据的接收窗口。也就是说,车锁得到用户锁车的触发后,其向应用服务器发出上行锁车请求消息后,会阶段性地打开几次时间窗口等待接收应用服务器向其返回的锁车响应,锁车响应可能在之后的任意一个接收窗口内被接收,接收后车锁才会执行锁车指令。因此,用户的锁车视频中所包含的锁车帧图像需要大于等于上下行传输间隔,以保证目标车辆确实没有接收到下行的锁车响应,以确定是车锁故障。具体的,应用服务器可以根据上下行数据传输时间间隔在锁车视频中获取至少两幅帧图像;确定至少两幅帧图像中是否包含有锁车图像;若包含,则确认车锁故障。还可以根据接收到的至少两幅锁车图片(该锁车图片为客户端对锁车视频进行分帧后发送的),确认至少两幅锁车图片中是否包含有锁车图像,若包含,则确认车锁故障。也就是说,对于获取至少两幅帧图像的情况,则两帧帧图像在锁车视频中的时间间隔大于等于上下行传输间隔且每帧中都包含锁车图像,若为三帧帧图像或三帧以上,则各个帧图像在锁车视频中的时间间隔之和大于等于上下行传输间隔,且每帧中都包含锁车图像。则可以确认用户正确锁车,车锁发生故障。
若车锁类型为无需外力按住锁柄实现锁车的第二车锁类型,则可以提示用户发送锁车图像;这类车锁其可以无需外力持续按压锁柄而自动落锁,但是,若其未接收到应用服务器发送的锁车响应,一段时间后又会弹开,因此,用户需要在锁住的瞬间拍到一张锁车图像即可。当然,若该车锁损坏,也可能出现完全无法落锁的情况,则该种情况下,可以采用前述方案,通过发送锁车视频,以使应用服务器判断是否车锁故障。
具体的,在锁车图片中确定是否包含有锁车图像,若包含,则确认车锁故障。
其中,锁车图像中可以包括以下至少一种图像信息:
锁车灯标识图像、车锁锁柄位于闭合位置图像、用户锁车动作图像。
例如,车锁上的指示灯在车锁闭合状态下以某种特定的颜色进行指示;还可以根据锁车图片中是否出现用户手部图像判断用户是否按压住了车锁,使其闭合等。
步骤408、确认车锁故障后向用户的客户端发送确认锁车的提示消息。
在本步骤中,应用服务器确定是车锁故障后,可以向用户的客户端发送提示消息,确认用户的锁车行为,停止对其进行计费。
上述方法可以有效地对车锁故障进行识别,且可以对用户是否真正实施了锁车进行甄别,以提升对车辆的有效管理。
图4b为图4a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的流程示意图,如图4b所示,针对需要外力按住锁柄的交互流程可以包括:
1、用户按住车锁,将目标车辆的标识通过LoRaWan上行传输至应用服务器;
2、锁车提示灯常亮或提示颜色以指示车锁位于锁车状态;
3、锁车响应通过LoRaWan下行传输至车锁;
4、车锁接收到锁车响应后,可以给予指示,例如,播放蜂鸣声,提示用户锁车成功;
5、目标车辆通过上行LoRaWan将锁车成功的消息传递给应用服务器;
6、查询目标车辆和用户的账号记录,停止计费;
7、向用户的客户端发送通知消息,提示用户已经停止计费。
图4c为图4a所示实施例的应用服务器、目标车辆的车锁、用户的客户端三者交互的另一流程示意图,如图4c所示,针对无需外力按住锁柄的交互流程可以包括:
1、用户按住车锁,将目标车辆的标识通过LoRaWan上行传输至应用服务器;
2、锁车提示灯常亮或提示颜色以指示车锁位于锁车状态;
3、检查是否有该目标车辆的相关记录,无论是否有记录都要返回锁车响应,有记录则同时停止计费;
4、锁车响应通过LoRaWan下行传输至车锁;
5、车锁接收到锁车响应后,可以给予指示,例如,播放蜂鸣声,提示用户锁车成功;
6、向用户的客户端发送通知消息,提示用户已经停止计费。
图5为本发明一示例性实施例示出的应用服务器的结构示意图,如图5所示,本实施例的应用服务器包括:
确定模块51,用于根据地理区域特征,确定网络信号的覆盖范围;
接收模块52,用于接收目标车辆发送的第一开锁请求或第一锁车请求;
确定模块51,还用于当所述接收模块52接收到目标车辆发送的第一开锁请求或第一锁车请求时,确定所述目标车辆位于所述网络信号的覆盖范围内;
发送模块53,用于向所述目标车辆返回第一开锁响应或第一锁车响应。
本实施例可用于执行前述图1所示的方法实施例,实现原理相似,在此不再赘述。
图6为本发明另一示例性实施例示出的应用服务器的结构示意图,如图6所示,本实施例的应用服务器包括:
确定模块51,包括:
确定子模块511,用于根据地理区域特征,确定车辆停放范围;
调节子模块512,用于调节低功耗广域网LPWAN的发射信号强度,以使所述车辆停放范围内接收到的所述LPWAN的网络信号强度满足预设的信号强度阈值;
确定子模块511,还用于确定所述网络信号覆盖范围为所述车辆停放范围。
可选的,还包括:
接收模块52,还用于接收用户的客户端发送的第二开锁请求,所述第二开锁请求中包含有用户标识、所述目标车辆的标识;
存储模块54,用于将所述用户标识与所述目标车辆的标识对应存储到开锁等候队列中;
发送模块53,还用于根据所述用户标识,向所述客户端发送开锁指示消息,以使用户根据所述开锁指示消息触发所述目标车辆向所述应用服务器发送所述第一开锁请求;
清除模块55,用于当所述接收模块52在第一预设时长内未接收到所述目标车辆发送的所述第一开锁请求时,将所述目标车辆的标识从所述开锁等候队列中清除;
发送模块53,还用于向所述用户的客户端发送取消开锁的提示消息。
可选的,接收模块52,还用于接收目标车辆在其各自的轮询时间段发送的所述第一开锁请求,所述第一开锁请求中包含:所述目标车辆的标识;
发送模块53,还用于当所述目标车辆的标识存在于所述开锁等候队列中时,向所述目标车辆发送所述第一开锁响应;
清除模块55,还用于当所述应用服务器在第二预设时长内未接收到所述目标车辆发送的所述第一开锁请求时,将所述目标车辆的标识从所述开锁等候队列中清除;
发送模块53,还用于向所述用户的客户端发送取消开锁的提示消息。
可选的,还包括:
接收模块52,还用于接收用户的客户端发送的第二锁车请求,所述第二锁车请求中包含:用户标识、地理位置信息;
确定模块51,还用于确定是否接收到与所述用户标识对应的目标车辆发送的所述第一锁车请求;若未收到,根据所述地理位置信息,确定所述目标车辆是否位于所述网络信号的覆盖范围内;
发送模块53,还用于当所述确定模块51确定所述目标车辆没有位于所述网络信号的覆盖范围内时,向所述用户的客户端发送在所述网络信号的覆盖范围内锁车的提示消息。
可选的,所述第二锁车请求中还包含:锁车视频或至少一幅锁车图片;还包括:
获取模块56,用于当所述接收模块52接收到所述锁车视频,且所述确定模块51确定所述目标车辆位于所述网络信号的覆盖范围内时,根据上下行数据传输时间间隔在所述锁车视频中获取至少两幅帧图像;
确定模块51,还用于确定所述至少两幅帧图像中是否包含有锁车图像;若包含,则确认车锁故障;
或者,
确定模块51,还用于当所述接收模块52接收到所述至少一幅锁车图片,且确定所述目标车辆位于所述网络信号的覆盖范围内时,确认所述至少一幅锁车图片中是否包含有锁车图像,若包含,则确认车锁故障;
发送模块53,还用于在所述确定模块51确定车锁故障后,向所述用户的客户端发送确认锁车的所述提示消息。
可选的,确定模块51,具体用于根据所述目标车辆的车锁类型,确定所述至少一幅锁车图片中是否包含有锁车图像;若所述车锁类型为需要外力按住锁柄达到预设时长实现锁车的第一车锁类型,则在所述至少一幅锁车图片中根据上下行数据传输时间间隔确定至少两幅帧图像中包含有锁车图像,则确认车锁故障;若所述车锁类型为无需外力按住锁柄实现锁车的第二车锁类型,则在一幅锁车图片中确定包含有锁车图像,则确认车锁故障。
可选的,所述锁车图像包括以下至少一种图像信息:
锁车灯标识图像、车锁锁柄位于闭合位置图像、用户锁车动作图像。
本实施例可用于执行前述各个方法实施例所述的方法,实现原理相似,在此不再赘述。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。