一种立体车库控制装置及方法与流程

1.本发明涉及信息与通信领域，尤其涉及一种立体车库控制装置及方法。


背景技术：

2.随着人们生活水平的提高，汽车越来越来普及，给老百姓们带来出行的便利的同时，也造成汽车停车位供不应求，尤其是一二线城市极为紧张的问题。立体停车位就是为了解决这类问题而产生的。现有的很多立体停车位由于安装价格太贵，并且施工不便捷，所以在推广使用上较为受限。同时，现有的立体停车位/立体车库为了确保安全性，都采用人工干预的方式，即在立体停车区域有专门的人(至少1人)进行人工排查、指挥和调度。由此带来了效率低、运营成本高、便捷度低、用户体验差等技术问题。


技术实现要素：

3.本发明的目的是解决现有技术中立体车库需要人员干预，效率低的技术问题，达到对立体车库高效控制的技术效果。
4.实现本发明目的的技术方案是提供了一种非机动车管理装置及方法。
5.第一方面，本发明提供了一种立体车库控制方法，用于服务器端，所述方法包括接收客户端发送的存车申请；所述存车申请包括车库端信息和客户端信息；
6.判断所述客户端发送的存车申请是否合法；所述判断所述客户端发送的存车申请是否合法包括对车库端信息和客户端信息的判断；
7.向客户端发送允许或不允许存车的响应；
8.接收客户端发送的生成存车订单的请求；
9.生成订单并向客户端发送授权密文；
10.进行第二安全移动判断，根据所述第二安全移动判断结果以及车库端做出的第一安全移动判断结果，向客户端发送权限开放确认请求；
11.接收客户端发送或者车库端上传的客户确认指令；
12.接收在车辆存车成功后车库端或者客户端发送的存车信息；
13.存车订单开始计费。
14.进一步的，还包括
15.接收车库端上传的客户存车命令。
16.进一步的，还包括
17.向客户端发送存车成功的提示信息。
18.进一步的，还包括
19.接收车库端上传的出入口位置的载车板信息。
20.进一步的，还包括
21.向车库端发送客户确认指令。
22.进一步的，还包括
23.接收取车请求；所述取车请求包括车库端信息和客户端信息；
24.判断是否有需付款的订单信息；
25.向客户端发送付款指令；
26.接收客户端发送的付款信息；
27.判断是否允许取车；
28.向客户端发送允许或不允许取车的响应；
29.进行第四安全移动判断，根据所述第四安全移动判断结果以及车库端做出的第三安全移动判断结果，向客户端发送权限开放确认请求；
30.接收客户端发送或者车库端上传的客户确认指令；
31.接收在车辆取车成功后车库端或者客户端发送的取车信息。
32.进一步的，还包括
33.向客户端发送取车成功的提示信息。
34.进一步的，所述进行第二安全移动判断包括：
35.用户安全判断；所述用户安全判断包括用户是否离开载车板到安全区域，车辆是否停稳，是否超越水平或垂直移动的边界；
36.用户主动操作判断；所述用户主动操作判断包括用户是否主动申请存车，用户是否正在现场。
37.第二方面，提供一种能够高效控制立体车库停车取车的管理装置，用于服务器端，包括
38.第一接收模块；用于接收客户端发送的存车申请；所述存车申请包括车库端信息和客户端信息；
39.第一判断模块；用于判断所述客户端发送的存车申请是否合法；所述判断所述客户端发送的存车申请是否合法包括对车库端信息和客户端信息的判断；
40.第一发送模块；用于向客户端发送允许或不允许存车的响应；
41.第二接收模块；用于接收客户端发送的生成存车订单的请求；
42.第一订单模块；用于生成订单并发送授权密文；
43.第二判断模块；用于进行第二安全移动判断，根据所述第二安全移动判断结果以及车库端做出的第一安全移动判断结果，向客户端发送权限开放确认请求；
44.第三接收模块；用于接收客户端发送或者车库端上传的客户确认指令；
45.第四接收模块；用于接收在车辆存车成功后车库端或者客户端发送的存车信息；
46.第一计费模块；用于存车订单开始计费。
47.第三方面，提供一种立体车库控制装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于：用于服务器端，所述处理器执行所述程序时实现前述的步骤。
48.采用了上述技术方案后，本发明具有以下的积极的效果：
49.本发明通过采用移动智能设备，如手机来进行操作，一方面方便用户使用，另一方面当车库端和服务器端进行了安全移动判断后，可以实现由用户进行确认，确保是本人操作，由此实现无需借助他人人工干预的、便捷的、高效的停车驱车控制。
附图说明
50.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
51.图1为本发明的方法在存车场景下的流程图。
52.图2为本发明的方法在存车场景下的另一个流程图。
53.图3为本发明的方法在取车场景下的流程图。
具体实施方式
54.上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
55.本发明提供了一种立体车库的控制方法，用于解决现有技术中立体位需要人工干预、智能化程度低的技术问题，为了解决上述问题，本发明的总体思路如下：
56.一种立体车库控制方法，用于服务器端，所述方法包括
57.接收客户端发送的存车申请；所述存车申请包括车库端信息和客户端信息；
58.判断所述客户端发送的存车申请是否合法；所述判断所述客户端发送的存车申请是否合法包括对车库端信息和客户端信息的判断；
59.向客户端发送允许或不允许存车的响应；
60.接收客户端发送的生成存车订单的请求；
61.生成订单并向客户端发送授权密文；
62.进行第二安全移动判断，根据所述第二安全移动判断结果以及车库端做出的第一安全移动判断结果，向客户端发送权限开放确认请求；
63.接收客户端发送或者车库端上传的客户确认指令；
64.接收在车辆存车成功后车库端或者客户端发送的存车信息；
65.存车订单开始计费。
66.通过采用移动智能设备，如手机来进行操作，一方面方便用户使用，另一方面当车库端和服务器端进行了安全移动判断后，可以实现由用户进行确认，确保是本人操作，由此实现无需借助他人人工干预的、便捷的、高效的停车驱车控制。
67.首先需要说明的是，在本发明各个实施例中，所涉及的术语为：
68.客户端：能够安装运营商app或者能够提供扫码功能或者能够有键盘输入功能的智能设备，比如用户的手机，具有蓝牙通信和远程通信模块，能够与车库端蓝牙或其他短距离通信，并能与服务器端远程通信。
69.车库端：具有运算、传输能力的立体车库，一般可以固定在地面，至少有两层。它至少具有：分布于各层的用于停车的车位空间、与车位空间数量对应的载车板、举升下降移动载车板的移动升降机构(包含驱动机构)、分布于立体车库空间内的采集车库内信息的信息采集机构(比如各种传感器/接近开关/限位开关等，并包含对应的采集检测电路)、中央控制器、短距离模块(用于与客户端通信)、gprs模块(用于与服务器端通信)。在立体车库的一
楼设置至少一个进出口位置，用于车辆的进出，该进出口位置所处的空间至少能容纳一个载车板。当车辆驶入载车板时，能够通过比如霍尔元件等方式判断车辆是否已停放到位，能够通过比如光电传感器等判断车辆是否满足长宽高的要求，当车辆驶离载车板时，能够判断车辆是否完全驶离。中央控制器用于前述部件的控制。在车库端上一般设有二维码(粘贴、印刷等方式)，可以粘贴在载车板上、专门的立柱上、移动升降机构上等等都可以。贴在前述各个位置的二维码可以一致，也可以各个载车板上的二维码分别唯一，且与贴在车库其他位置的不同。当二维码不同时，扫描车库端除载车板以外的二维码，上传给后端的信息就是整个车库端的信，扫描载车板上的二维码，上传给后端的信息则是车库端的编号以及该载车板的信息，包括该载车板为空车位的信息。在车库端会设置很多个信息采集机构，下面仅仅列举一下：在出入口位置处设置多组对射的光电传感器，可以判断车辆是否进入载车板，是否超长、超高、超宽等；在移动升降机构的举升下降载车板的抬升杆上也设置光电传感器，从而可以用于判断是否是空的载车板；在每个车位处都设置接近开关，从而用于判断是否停车到位；在需要测算距离的地方设置编码器来将距离测量精确度提升。还设置限位开关来控制载车板必须达到预设高度后才可以进行移动，避免损坏车库内停放的车辆。这些信息采集机构采集到的信息都与车库端的中央控制器进行交互，然后上传到后台服务器确保同步。同时，在本实施例中，为了确保车库端、服务器端的信息准确，且当出现类似突然断电等故障后再恢复时，立体车库能够准确工作，所有的信息采集机构都设置双份，一个坏了之后立即使用另一个，同时上报损坏信息，提醒运营商进行维修更换。
70.服务器端：运营商远程的服务器或者云服务器，作为总控中心。
71.车辆：客户自有车辆。
72.车位编号：车库端可以有多个车位，每个车位有唯一编号，用于身份区分。
73.载车板编号：每个载车板有唯一编号，用于身份区分。
74.用户编号：使用者通过在运营商app或者官网或者其他途径注册成为合法用户后的唯一编号，用于身份区分。
75.本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。同时，下述的各个实施例中，当有判断的情况下，下一步的触发都源自上一步的判断获得正向的结果。
76.下面，通过几个具体的实施例对本发明的技术方案进行详细介绍和说明。
77.(实施例1)
78.本发明一个实施例提供的立体车库控制装置，用于服务器端，包括：
79.第一接收模块；用于接收客户端发送的存车申请；服务器端接收的存车请求的方式有多种，比如由客户端app扫描车库端上的二维码后，向服务器端发送存车请求；也可以利用客户端微信公众号、微信小程序、支付宝app，输入车库编号，点击“存车”按钮的方式，向服务器端发送存车请求；还可以是通过编辑短信的方式(短信编辑方式可以贴在车库端)，且不限于前述的方式，只要是由客户端发送，由服务器端接收即可。存车请求包括车库端的信息(如车库编号，或带有该信息的识别码)和客户端的用户信息(如用户编号)；
80.第一判断模块；用于判断所述客户端发送的存车申请是否合法；所述判断所述客户端发送的存车申请是否合法包括对车库端信息和客户端信息的判断；车库端信息包括车
库设施是否运行正常、是否有空的车位等；客户端信息包括用户是否有存车权限(用户因失信列入存车黑名单等)、用户是否合法(用户没有注册相关账户等)以及用户是否超限(比如对一个用户名下关联的车辆数有限制)、用户用户账号是否结清历史停车费等。同时，本实施例的立体车库还允许用户采用包月等预留车位的方式，因此在计算是否有空车位的时候，需要排除预留车位。在此种情形下，在车库端可在预留车位初进行显示提示。预留车位可以是预留固定位置也可以预留随机位置。当车库和用户状态都为正常，则判断返回值为允许，有任一不符合，则判断返回值为不允许，在此的判断是与运算模式，任何一个不正常都代表请求不合法，都得到不允许的判断返回值。
81.第一发送模块；用于向客户端发送允许或不允许存车的响应；
82.第二接收模块；用于接收客户端发送的生成存车订单的请求；
83.第一订单模块；用于生成订单并发送授权密文；服务器端新增一个订单号并存储在数据库中，同时新增一个授权密文，并发送给手机，手机收到授权密文后，将该授权密文通过蓝牙等发送给车库端。
84.第二判断模块；用于进行第二安全移动判断，根据所述第二安全移动判断结果以及车库端做出的第一安全移动判断结果，向客户端发送权限开放确认请求；
85.第一安全移动判断和第二安全移动判断整体包括用户安全判断和用户主动操作判断，主要目的在于判断用户及其车辆所处的环境是否适合移动载车板，以及是否是用户本人主动申请，且用户当前正在现场，能够确保对现场设备的使用及运动有知情。
86.其中用户安全判断包括用户是否离开载车板到安全区域，车辆是否停稳，是否超越水平或垂直移动的边界；
87.用户主动操作判断判断包括用户是否主动申请存车，用户是否正在现场。
88.在本实施例中，服务器端的第二安全移动判断的内容是可以调整的，根据车库端的功能配置情况，可以是车库端只负责采集相关数据，其他判断全部由服务器端完成；也可以是车库端采集相关数据也做一部分判断，其余运算判断由服务器端完成；总之，车库端和服务器端需要完成前述全部的判断，以达到确保安全移动的目的。
89.具体来说，实现方式可以有很多种，比如在车库端借助车位传感器，红外线，雷达，机器视频、图像视觉、ai等来判断用户是否离开载车板到安全区域，车辆是否停稳，是否超越水平或垂直移动的边界；借助客户端的移动终端的gps定位判断与车库位置的距离，或通过移动终端与车库端的中央控制器的蓝牙通信，或通过移动终端与车库端的中央控制器的nfc通信，或用户在车库端上进行人脸识别，或车库端现场的摄像头ai识别等来判断用户是否是主动申请存车，且用户当前正在现场，对现场设备的使用及运动有知情的条件。
90.第三接收模块；用于接收客户端发送或者车库端上传的客户确认指令；
91.第四接收模块；用于接收在车辆存车成功后车库端或者客户端发送的存车信息；有两种方式可以接收存车信息，第一种存车信息通过车库端自带的gprs模块上传；第二种则是通过客户端上传；存车信息包括：存车时间、用户编号、车库编号、载车板编号中的至少一种，当然全部包含为最佳。
92.第一计费模块；用于存车订单开始计费。可以设置不同的计费模式。
93.见图1和图2，本实施例构建了立体车库控制系统，系统包括客户端、车库端和服务器端，前述介绍的立体车库控制装置就用于服务器端。立体车库控制系统包括客户端、车库
端和服务器端三者之间进行信息的交互和处理。
94.图1和图2清楚地展示了存车的场景下的控制方法，首先，关于图1的控制方法：
95.在图1展示的存车场景为：在用户进入立体车库准备停车时，进出口位置处没有载车板，用户先在车里进行类似扫码等操作，将相关需求传递给服务器端。
96.首先客户端发送存车请求，服务器端接收前述存车请求；比如用户在其手机上安装了运营商的app，并在app上注册账号，成为合法的停车用户，服务器端中存储用户的编号信息(注册时填的相关信息结合服务器端给与用户的id信息)。当他需要对自己车辆选择停车位时，将车辆开至立体车库处，打开app后，扫描立体车库处粘贴或者印刷的二维码，则建立起手机与车库端蓝牙的一对一连接，从而可以得到该车库端的编码以及车库端有无空车位的信息等，然后通过用户的手机的网络链接到远程服务器端，向服务器端发送存车申请。存车申请包括车库端信息(至少包含车库编号)和客户端信息(至少包含用户编号信息)。当然车库端也会在每次有变化后或者定期的向后台服务器端上传相关信息。也可以是当各载车板上的二维码分别唯一时，用户扫描无车的载车板上的二维码，与车库端建立联系，获取载车板和车库端的其他信息，然后通过用户的手机的网络链接到远程服务器端，向服务器端发送存车申请。
97.服务器端进行存车请求判断；包括对车库端信息和客户端信息的判断；车库端信息包括车库设施是否运行正常、是否有空的车位等；客户端信息包括用户是否有存车权限(用户因失信列入存车黑名单等)、用户是否合法(用户没有注册相关账户等)以及用户是否超限(比如对一个用户名下关联的车辆数有限制)、用户用户账号是否结清历史停车费等。同时，本实施例的立体车库还允许用户采用包月等预留车位的方式，因此在计算是否有空车位的时候，需要排除预留车位。在此种情形下，在车库端可在预留车位初进行显示提示。预留车位可以是预留固定位置也可以预留随机位置。当车库和用户状态都为正常，则判断返回值为允许，有任一不符合，则判断返回值为不允许，在此的判断是与运算模式，任何一个不正常都代表请求不合法，都得到不允许的判断返回值。在前述场景下，该用户为合法注册的用户，若其信用良好，未被列入黑名单，则用户判断为正常。若车库未损坏且至少一个空的载车板未损坏(服务器端中前述损坏的记录)，且至少有一个载车板是空的。当各载车板上的二维码分别唯一时，用户是扫描的无车的载车板上的二维码，但服务器端仍需进行判断，避免出现虽然载车板上无车，但服务器端的记录停放有车的情况。
98.服务器端向客户端返回允许或者不允许存车的响应，用户手机上显示允许停车或者下一步操作提示或者显示可停位置数量等等，告知用户得到了系统的允许。此后，用户手机会向服务器端发送生成存车订单的请求，服务器端接收到该存车订单请求后，即可生成订单，服务器端新增一个订单号并存储在数据库中，同时新增一个授权密文，并发送给手机，手机收到授权密文后，将该授权密文(也即存车命令)通过蓝牙等发送给车库端。车库端会将客户端确认发送了存车命令这一情况上传给服务器端。
99.接下来则车库端进行第一安全移动判断，同时服务器端进行第二安全移动判断。安全移动判断的主要目的在于判断用户及其车辆所处的环境是否适合移动载车板，以及是否是用户本人主动申请，且用户当前正在现场，能够确保对现场设备的使用及运动有知情。这样进行判断的目的是杜绝用户远程操作设备，从而引发安全隐患。
100.当安全移动的判断结构为允许安全移动时，则向客户端发送权限开放确认请求；
101.客户端向车库端发送确认指令，车库端将该指令上传给服务器端，或者由客户端直接将该指令上传给服务器端，然后服务器端将指令发送给车库端，总之，要确保指令到达车库端，并同时后台服务起知道客户已经发送了确认指令。用户可以是在手机上控制车库端，也可以是在车库端上点操控按钮。
102.随后车库端开始计算并确定最佳空车位，并控制该最佳空车位上的载车板移动到出入口位置处。在本实施例中的最佳空车位是指移动该车位的载车板到目标位置的移动时间最短。车库端可以是在有用户存车需求时临时计算并将该车位载车板移动到方便泊车的位置，也可以是设备在没有存车需求的空闲状态下，提前计算并准备好空车位，将该车位载车板移动到方便泊车的位置，大幅度节省用户泊车时等待设备移动载车板的时间，比如用户在进行前述操作时，车库端知道有存车申请时开始，就进行载车板的移动动作。
103.随后，用户将车辆倒车进入出入口位置处的空载车板，车库端设置的各个信息采集机构开始工作和判断，比如入口处的光电传感器对射被覆盖，表明车尾进来了，当位于空车位中间、尾部的光电传感器陆续被覆盖，且入口处光电传感器保持，则判断为全车已经进入载车板。随后会进行限高，限长的光电传感器判断。进行一些语音提示，包括提醒用户进行驻车制动(拉手刹)、折叠反光镜等。随后用户会下车，当由尾部-》中-》前的光电传感器被陆续被触发，则判断是有用户下车且不处于出入口位置了。如果没有，则不进行后续的载车板的举升。车库端和或服务器端可以预设一个时间阈值，比如5分钟，如果超过这个阈值，依然没有得到用户下车且不在出入口位置的判断，默认为出入口被占用或系统级故障，报警给服务器端。
104.随后，载车板被移动到之前选定的最佳空车位处。车库端向客户端发送存车成功的信息，同时将相关存车信息上传给服务器端。存车信息包括：存车时间、用户编号、车库编号、载车板编号中的至少一种，当然全部包含为最佳。或者是客户端向服务器端发送存车信息。
105.服务器端开始对存车订单计费。
106.图1的控制方法特别适合取车高峰期时，在进出口位置处无空载车板，更能节省取车时间。用户可以做到直接取车。否则在取车命令后，需要先将空载车板归位，再去取车。
107.图2展示的也是存车的流程，但与图1的场景有不同，在图2展示的存车方法中，在用户进入立体车库时，出入口位置是有载车板的，故至少有一个空车位，由于载车板和车位数量一致，载车板的目的地就是确定的。
108.因此用户可以先将车辆倒车进入载车板，同样的，车库端设置的各个信息采集机构开始工作和判断，比如入口处的光电传感器对射被覆盖，表明车尾进来了，当位于空车位中间、尾部的光电传感器陆续被覆盖，且入口处光电传感器保持，则判断为全车已经进入载车板。随后会进行限高，限长的光电传感器判断。进行一些语音提示，包括提醒用户进行驻车制动(拉手刹)、折叠反光镜等。随后用户会下车，当由尾部-》中-》前的光电传感器被陆续被触发，则判断是有用户下车且不处于出入口位置了。如果没有，则不进行后续的载车板的举升。车库端和或服务器端可以预设一个时间阈值，比如5分钟，如果超过这个阈值，依然没有得到用户下车且不在出入口位置的判断，默认为出入口被占用或系统级故障，报警给服务器端。
109.随后客户端发送存车请求，服务器端接收前述存车请求；服务器端进行存车请求
判断；服务器端向客户端返回允许或者不允许存车的响应，用户手机上显示允许停车或者下一步操作提示或者显示可停位置数量等等，告知用户得到了系统的允许。此后，用户手机会向服务器端发送生成存车订单的请求，服务器端接收到该存车订单请求后，即可生成订单，服务器端新增一个订单号并存储在数据库中，同时新增一个授权密文，并发送给手机，手机收到授权密文后，将该授权密文(也即存车命令)通过蓝牙等发送给车库端。车库端会将客户端确认发送了存车命令这一情况上传给服务器端。之后同样的进行第一安全移动判断，同时服务器端进行第二安全移动判断。安全移动判断的主要目的在于判断用户及其车辆所处的环境是否适合移动载车板，以及是否是用户本人主动申请，且用户当前正在现场，能够确保对现场设备的使用及运动有知情。当安全移动的判断结构为允许安全移动时，则向客户端发送权限开放确认请求；客户端向车库端发送确认指令，车库端将该指令上传给服务器端，或者由客户端直接将该指令上传给服务器端，然后服务器端将指令发送给车库端。用户可以是在手机上控制车库端，也可以是在车库端上点操控按钮。随后车库端控制载车板移动到之前没有载车板的空车位处。
110.之后，车库端将任意一个空载车板移动到出入口位置处，同时向服务器端上传该移动的载车板信息。
111.图2的控制方法尤其适合存车高峰期，车库端在进行任何操作后的最后一步骤，都是取一个空载车板放在进出口位置，以便下一个用户存车。
112.图3清楚地展示了取车的场景下的控制方法：
113.首先客户端发送取车请求，服务器端接收前述取车请求；当用户需要取走自己停放的车辆时，可来到车库端附近，打开app后，点击诸如“取车”界面，由此借由他的手机的网络链接到远程云服务器，向服务器端发送取车请求，这种情形下，服务器端将取车请求信息返回(即告诉车库端)给车库端，以确保取车请求的同步性。或者用户通过车库端链接到服务器端发送取车请求，亦或者直接找到停放有自己车辆的载车板前，在客户端app或微信公众号、微信小程序、支付宝上扫描载车板上的二维码，然后借由他的手机的网络链接到远程云服务器，向服务器发送取车请求。取车请求包括车库编号和用户编号信息。
114.服务器端首先判断是否有需付款的订单信息；在这个判断里，与存车请求判断类似，服务器端会进行车库端是否正常以及用户是否正常的判断。包括对车库端信息和客户端信息的判断；车库端信息包括车库设施是否运行正常、是否停放有用户的车等；对客户端信息判断包括用户是否合法(用户没有注册相关账户等)、用户是否有取车权限(用户账号是否与存车账号一致，或用户输入的车牌号是否与存储的车牌号一致)以及用户是否超限(比如对一个用户名下关联的车辆数有限制)、用户用户账号是否结清历史停车费等。在以上判断都被通过后，还有用户付费方面的判断，包括是否需要付费及费用多少：比如有无用户订单信息、有无账号特权(比如vip账号、年租、月租账号等)、有无优惠券、有无免费情形(比如可以设置30分钟内免费等)。
115.服务器端向客户端发送付款指令；
116.接收客户端发送的付款信息；
117.同时服务器端是否允许取车的判断；比如付款是否成功等。
118.服务器端向客户端发送允许或不允许取车的响应；
119.服务器端进行第四安全移动判断，根据所述第四安全移动判断结果以及车库端做
出的第三安全移动判断结果，向客户端发送权限开放确认请求；安全移动的判断与存车时的安全移动的判断是一样的。
120.当安全移动的判断结构为允许安全移动时，则向客户端发送权限开放确认请求；
121.客户端向车库端发送确认指令，车库端将该指令上传给服务器端，或者由客户端直接将该指令上传给服务器端，然后服务器端将指令发送给车库端，总之，要确保指令到达车库端，并同时后台服务起知道客户已经发送了确认指令。用户可以是在手机上控制车库端，也可以是在车库端上点操控按钮。
122.车库端控制载车板移动到出入口位置，用户上车，将车开走。
123.同样的，车库端会结合信息采集机构来进行取车是否成功的判断：带车辆的载车板(比如通过光电传感器确保不是空的载车板)到达出入口位置，同时车辆从出入口位置的光电传感器陆续离开(和入库时相反)。
124.车库端向客户端发送取车成功的信息，并向服务器上传取车信息以确保同步；或者客户端向向服务器上传取车信息以确保同步。
125.基于与上述装置和方法同样的发明构思，本发明还提供一种立体车库控制装置，设置在服务器中，其上存储有计算机程序，该程序被处理器执行时实现前文所述的立体车库控制方法中的任一方法的步骤。
126.(实施例2)
127.本发明另一个实施例提供的立体车库控制装置，用于车库端。
128.包括：
129.第一接收模块，用于接收客户端发送的存车命令；所述存车命令来自于服务器端发送给客户端的授权密文；
130.第一安全移动判断模块，用于进行第一安全移动判断，根据所述第一安全移动判断结果以及服务起端做出的第二安全移动判断结果，向客户端发送权限开放确认请求；
131.第二接收模块，用于接收客户端发送的客户确认指令；
132.第一选择模块，用于进行最佳空车位的选择；
133.第一控制模块，用于控制载车板移动到进出口位置；
134.第一判断模块，用于判断车辆是否已经完成进入载车板的动作；
135.第二控制模块，用于控制载车板移动到所述的最佳空车位处；
136.第一发送模块，用于向客户端发送存车成功的信息。
137.第一安全移动判断和第二安全移动判断整体包括用户安全判断和用户主动操作判断，主要目的在于判断用户及其车辆所处的环境是否适合移动载车板，以及是否是用户本人主动申请，且用户当前正在现场，能够确保对现场设备的使用及运动有知情。
138.其中用户安全判断包括用户是否离开载车板到安全区域，车辆是否停稳，是否超越水平或垂直移动的边界；
139.用户主动操作判断判断包括用户是否主动申请存车，用户是否正在现场。
140.在本实施例中，车库端的第一安全移动判断的内容是可以调整的，根据服务器端的功能配置情况，可以是车库端只负责采集相关数据，其他判断全部由服务器端完成；也可以是车库端采集相关数据也做一部分判断，其余运算判断由服务器端完成；总之，车库端和服务器端需要完成前述全部的判断，以达到确保安全移动的目的。具体来说，实现方式可以
有很多种，比如在车库端借助车位传感器，红外线，雷达，机器视频、图像视觉、ai等来判断用户是否离开载车板到安全区域，车辆是否停稳，是否超越水平或垂直移动的边界；借助客户端的移动终端的gps定位判断与车库位置的距离，或通过移动终端与车库端的中央控制器的蓝牙通信，或通过移动终端与车库端的中央控制器的nfc通信，或用户在车库端上进行人脸识别，或车库端现场的摄像头ai识别等来判断用户是否是主动申请存车，且用户当前正在现场，对现场设备的使用及运动有知情的条件。
141.见图1和图2，本实施例构建了立体车库控制系统，系统包括客户端、车库端和服务器端，前述介绍的立体车库控制装置就用于车库端。立体车库控制系统包括客户端、车库端和服务器端三者之间进行信息的交互和处理。
142.图1和图2清楚地展示了存车的场景下的控制方法，首先，关于图1的控制方法：
143.在图1展示的存车场景为：在用户进入立体车库准备停车时，进出口位置处没有载车板，用户先在车里进行类似扫码等操作，将相关需求传递给服务器端。
144.一种立体车库控制方法，用于车库端，所述方法包括
145.接收客户端发送的存车命令；所述存车命令来自于服务器端发送给客户端的授权密文；
146.进行第一安全移动判断，根据所述第一安全移动判断结果以及服务起端做出的第二安全移动判断结果，向客户端发送权限开放确认请求；
147.接收客户端发送的客户确认指令；
148.进行最佳空车位的选择；
149.控制载车板移动到进出口位置；
150.判断车辆是否已经完成进入载车板的动作；
151.控制载车板移动到所述的最佳空车位处；
152.向客户端发送存车成功的信息。
153.也可以在向客户端发送存车成功的信息后向服务器端上传存车信息。
154.也可以在接收客户端发送的客户确认指令后向服务器端上传确认指令。
155.在图2展示的存车场景为：在用户进入立体车库准备停车时，进出口位置处有载车板，用户先将车倒车进入载车板，然后再下车进行类似扫码等操作，将相关需求传递给服务器端。
156.一种立体车库控制方法，用于车库端，所述方法包括
157.判断车辆是否已经完成进入载车板的动作；
158.接收客户端发送的存车命令；所述存车命令来自于服务器端发送给客户端的授权密文；
159.进行第一安全移动判断，根据所述第一安全移动判断结果以及服务起端做出的第二安全移动判断结果，向客户端发送权限开放确认请求；
160.接收客户端发送的客户确认指令；
161.进行最佳空车位的选择；
162.控制载车板移动到所述的最佳空车位处；
163.向客户端发送存车成功的信息。
164.也可以在向客户端发送存车成功的信息后向服务器端上传存车信息。
165.也可以在接收客户端发送的客户确认指令后向服务器端上传确认指令。
166.图3则展示的是取车的流程，用在车库端。
167.接收取车请求；所述取车请求包括客户端发送的取车请求或者由服务器端返回的客户端的请求；
168.进行第三安全移动判断，根据所述第三安全移动判断结果以及服务器端做出的第四安全移动判断结果，向客户端发送权限开放确认请求；
169.接收客户端发的客户确认指令；
170.控制载车板移动到出入口位置；
171.等待用户取车；
172.判断取车是否成功；
173.向客户端发送取车成功的信息。
174.也可以在向客户端发送取车成功的信息后向服务器端上传取车信息。
175.进行第一安全移动判断以及第三安全判断包括：
176.用户安全判断；所述用户安全判断包括用户是否离开载车板到安全区域，车辆是否停稳，是否超越水平或垂直移动的边界；
177.用户主动操作判断；所述用户主动操作判断包括用户是否主动申请存车，用户是否正在现场。
178.详细来说，首先客户端发送存车请求，服务器端接收前述存车请求；比如用户在其手机上安装了运营商的app，并在app上注册账号，成为合法的停车用户，服务器端中存储用户的编号信息(注册时填的相关信息结合服务器端给与用户的id信息)。当他需要对自己车辆选择停车位时，将车辆开至立体车库处，打开app后，扫描立体车库处粘贴或者印刷的二维码，则建立起手机与车库端蓝牙的一对一连接，从而可以得到该车库端的编码以及车库端有无空车位的信息等，然后通过用户的手机的网络链接到远程服务器端，向服务器端发送存车申请。存车申请包括车库端信息(至少包含车库编号)和客户端信息(至少包含用户编号信息)。当然车库端也会在每次有变化后或者定期的向后台服务器端上传相关信息。也可以是当各载车板上的二维码分别唯一时，用户扫描无车的载车板上的二维码，与车库端建立联系，获取载车板和车库端的其他信息，然后通过用户的手机的网络链接到远程服务器端，向服务器端发送存车申请。
179.服务器端进行存车请求判断；包括对车库端信息和客户端信息的判断；车库端信息包括车库设施是否运行正常、是否有空的车位等；客户端信息包括用户是否有存车权限(用户因失信列入存车黑名单等)、用户是否合法(用户没有注册相关账户等)以及用户是否超限(比如对一个用户名下关联的车辆数有限制)、用户用户账号是否结清历史停车费等。同时，本实施例的立体车库还允许用户采用包月等预留车位的方式，因此在计算是否有空车位的时候，需要排除预留车位。在此种情形下，在车库端可在预留车位初进行显示提示。预留车位可以是预留固定位置也可以预留随机位置。当车库和用户状态都为正常，则判断返回值为允许，有任一不符合，则判断返回值为不允许，在此的判断是与运算模式，任何一个不正常都代表请求不合法，都得到不允许的判断返回值。在前述场景下，该用户为合法注册的用户，若其信用良好，未被列入黑名单，则用户判断为正常。若车库未损坏且至少一个空的载车板未损坏(服务器端中前述损坏的记录)，且至少有一个载车板是空的。当各载车
板上的二维码分别唯一时，用户是扫描的无车的载车板上的二维码，但服务器端仍需进行判断，避免出现虽然载车板上无车，但服务器端的记录停放有车的情况。
180.服务器端向客户端返回允许或者不允许存车的响应，用户手机上显示允许停车或者下一步操作提示或者显示可停位置数量等等，告知用户得到了系统的允许。此后，用户手机会向服务器端发送生成存车订单的请求，服务器端接收到该存车订单请求后，即可生成订单，服务器端新增一个订单号并存储在数据库中，同时新增一个授权密文，并发送给手机，手机收到授权密文后，将该授权密文(也即存车命令)通过蓝牙等发送给车库端。车库端会将客户端确认发送了存车命令这一情况上传给服务器端。
181.接下来则车库端进行第一安全移动判断，同时服务器端进行第二安全移动判断。安全移动判断的主要目的在于判断用户及其车辆所处的环境是否适合移动载车板，以及是否是用户本人主动申请，且用户当前正在现场，能够确保对现场设备的使用及运动有知情。这样进行判断的目的是杜绝用户远程操作设备，从而引发安全隐患。
182.当安全移动的判断结构为允许安全移动时，则向客户端发送权限开放确认请求；
183.客户端向车库端发送确认指令，车库端将该指令上传给服务器端，或者由客户端直接将该指令上传给服务器端，然后服务器端将指令发送给车库端，总之，要确保指令到达车库端，并同时后台服务起知道客户已经发送了确认指令。用户可以是在手机上控制车库端，也可以是在车库端上点操控按钮。
184.随后车库端开始计算并确定最佳空车位，并控制该最佳空车位上的载车板移动到出入口位置处。在本实施例中的最佳空车位是指移动该车位的载车板到目标位置的移动时间最短。车库端可以是在有用户存车需求时临时计算并将该车位载车板移动到方便泊车的位置，也可以是设备在没有存车需求的空闲状态下，提前计算并准备好空车位，将该车位载车板移动到方便泊车的位置，大幅度节省用户泊车时等待设备移动载车板的时间，比如用户在进行前述操作时，车库端知道有存车申请时开始，就进行载车板的移动动作。
185.随后，用户将车辆倒车进入出入口位置处的空载车板，车库端设置的各个信息采集机构开始工作和判断，比如入口处的光电传感器对射被覆盖，表明车尾进来了，当位于空车位中间、尾部的光电传感器陆续被覆盖，且入口处光电传感器保持，则判断为全车已经进入载车板。随后会进行限高，限长的光电传感器判断。进行一些语音提示，包括提醒用户进行驻车制动(拉手刹)、折叠反光镜等。随后用户会下车，当由尾部-》中-》前的光电传感器被陆续被触发，则判断是有用户下车且不处于出入口位置了。如果没有，则不进行后续的载车板的举升。车库端和或服务器端可以预设一个时间阈值，比如5分钟，如果超过这个阈值，依然没有得到用户下车且不在出入口位置的判断，默认为出入口被占用或系统级故障，报警给服务器端。
186.随后，载车板被移动到之前选定的最佳空车位处。车库端向客户端发送存车成功的信息，同时将相关存车信息上传给服务器端。存车信息包括：存车时间、用户编号、车库编号、载车板编号中的至少一种，当然全部包含为最佳。或者是客户端向服务器端发送存车信息。
187.服务器端开始对存车订单计费。
188.图1的控制方法特别适合取车高峰期时，在进出口位置处无空载车板，更能节省取车时间。用户可以做到直接取车。否则在取车命令后，需要先将空载车板归位，再去取车。
189.图2展示的也是存车的流程，但与图1的场景有不同，在图2展示的存车方法中，在用户进入立体车库时，出入口位置是有载车板的，故至少有一个空车位，由于载车板和车位数量一致，载车板的目的地就是确定的。在图所示的场景下，第三安全移动判断和第四安全移动判断与第一安全移动判断和第二安全移动判断相同。
190.因此用户可以先将车辆倒车进入载车板，同样的，车库端设置的各个信息采集机构开始工作和判断，比如入口处的光电传感器对射被覆盖，表明车尾进来了，当位于空车位中间、尾部的光电传感器陆续被覆盖，且入口处光电传感器保持，则判断为全车已经进入载车板。随后会进行限高，限长的光电传感器判断。进行一些语音提示，包括提醒用户进行驻车制动(拉手刹)、折叠反光镜等。随后用户会下车，当由尾部-》中-》前的光电传感器被陆续被触发，则判断是有用户下车且不处于出入口位置了。如果没有，则不进行后续的载车板的举升。车库端和或服务器端可以预设一个时间阈值，比如5分钟，如果超过这个阈值，依然没有得到用户下车且不在出入口位置的判断，默认为出入口被占用或系统级故障，报警给服务器端。
191.随后客户端发送存车请求，服务器端接收前述存车请求；服务器端进行存车请求判断；服务器端向客户端返回允许或者不允许存车的响应，用户手机上显示允许停车或者下一步操作提示或者显示可停位置数量等等，告知用户得到了系统的允许。此后，用户手机会向服务器端发送生成存车订单的请求，服务器端接收到该存车订单请求后，即可生成订单，服务器端新增一个订单号并存储在数据库中，同时新增一个授权密文，并发送给手机，手机收到授权密文后，将该授权密文(也即存车命令)通过蓝牙等发送给车库端。车库端会将客户端确认发送了存车命令这一情况上传给服务器端。之后同样的进行第一安全移动判断，同时服务器端进行第二安全移动判断。安全移动判断的主要目的在于判断用户及其车辆所处的环境是否适合移动载车板，以及是否是用户本人主动申请，且用户当前正在现场，能够确保对现场设备的使用及运动有知情。当安全移动的判断结构为允许安全移动时，则向客户端发送权限开放确认请求；客户端向车库端发送确认指令，车库端将该指令上传给服务器端，或者由客户端直接将该指令上传给服务器端，然后服务器端将指令发送给车库端。用户可以是在手机上控制车库端，也可以是在车库端上点操控按钮。随后车库端控制载车板移动到之前没有载车板的空车位处。
192.之后，车库端将任意一个空载车板移动到出入口位置处，同时向服务器端上传该移动的载车板信息。
193.图2的控制方法尤其适合存车高峰期，车库端在进行任何操作后的最后一步骤，都是取一个空载车板放在进出口位置，以便下一个用户存车。
194.图3清楚地展示了取车的场景下的控制方法：
195.首先客户端发送取车请求，服务器端接收前述取车请求；当用户需要取走自己停放的车辆时，可来到车库端附近，打开app后，点击诸如“取车”界面，由此借由他的手机的网络链接到远程云服务器，向服务器端发送取车请求，这种情形下，服务器端将取车请求信息返回(即告诉车库端)给车库端，以确保取车请求的同步性。或者用户通过车库端链接到服务器端发送取车请求，亦或者直接找到停放有自己车辆的载车板前，在客户端app或微信公众号、微信小程序、支付宝上扫描载车板上的二维码，然后借由他的手机的网络链接到远程云服务器，向服务器发送取车请求。取车请求包括车库编号和用户编号信息。
196.服务器端首先判断是否有需付款的订单信息；在这个判断里，与存车请求判断类似，服务器端会进行车库端是否正常以及用户是否正常的判断。包括对车库端信息和客户端信息的判断；车库端信息包括车库设施是否运行正常、是否停放有用户的车等；对客户端信息判断包括用户是否合法(用户没有注册相关账户等)、用户是否有取车权限(用户账号是否与存车账号一致，或用户输入的车牌号是否与存储的车牌号一致)以及用户是否超限(比如对一个用户名下关联的车辆数有限制)、用户用户账号是否结清历史停车费等。在以上判断都被通过后，还有用户付费方面的判断，包括是否需要付费及费用多少：比如有无用户订单信息、有无账号特权(比如vip账号、年租、月租账号等)、有无优惠券、有无免费情形(比如可以设置30分钟内免费等)。
197.服务器端向客户端发送付款指令；
198.接收客户端发送的付款信息；
199.同时服务器端是否允许取车的判断；比如付款是否成功等。
200.服务器端向客户端发送允许或不允许取车的响应；
201.服务器端进行第四安全移动判断，根据所述第四安全移动判断结果以及车库端做出的第三安全移动判断结果，向客户端发送权限开放确认请求；安全移动的判断与存车时的安全移动的判断是一样的。
202.当安全移动的判断结构为允许安全移动时，则向客户端发送权限开放确认请求；
203.客户端向车库端发送确认指令，车库端将该指令上传给服务器端，或者由客户端直接将该指令上传给服务器端，然后服务器端将指令发送给车库端，总之，要确保指令到达车库端，并同时后台服务起知道客户已经发送了确认指令。用户可以是在手机上控制车库端，也可以是在车库端上点操控按钮。
204.车库端控制载车板移动到出入口位置，用户上车，将车开走。
205.同样的，车库端会结合信息采集机构来进行取车是否成功的判断：带车辆的载车板(比如通过光电传感器确保不是空的载车板)到达出入口位置，同时车辆从出入口位置的光电传感器陆续离开(和入库时相反)。
206.车库端向客户端发送取车成功的信息，并向服务器上传取车信息以确保同步；或者客户端向向服务器上传取车信息以确保同步。
207.基于与上述装置和方法同样的发明构思，本发明还提供一种立体车库控制装置，设置在服务器中，其上存储有计算机程序，该程序被处理器执行时实现前文所述的立体车库控制方法中的任一方法的步骤。
208.以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。