劉湘煜,唐 倫,羅花芝
(1.湖南汽車工程職業學院信息工程學院,株洲 412001;2.湖南汽車工程職業學院車輛工程學院,株洲 412001)
隨著汽車的進一步普及,停車已經變成許多城市的一大難題。立體停車應運而生。大型的立體停車庫雖然好用,也可提供很多停車位,但因所需初期投資較多,同時多數情況下也不需要,因而產生了比較簡單的雙層立體停車庫。張濤等設計了三層停車庫;王中原等設計了基于ADAMS 的無避讓側方位立體停車設備升降機構。這些設計均已經對側方位立體停車庫的機械設計進行了分析,本文基于無避讓側方位智能停車設備的嵌入式智能控制系統軟件進行分析和設計。
基于無避讓智能立體停車設備的智慧停車系統分為三部分,分別是車庫管理云平臺,智慧停車App 以及智能立體停車裝置,作為Iot(internet of things,物聯網)系統,其架構如圖1所示。

圖1 智慧停車系統架構
系統開發分為前端智慧停車App 以及后臺車庫管理云平臺,同時針對后臺平臺管理的Web頁面。
其中,車庫管理云平臺作為整個停車服務的中心,承接了App 與立體停車設備間的通信,停車流程如下:
(1)當用戶發起停車請求時,服務器生成訂單,記錄起始時間。
(2)服務器對指定停車設備下達指令,同時監測停車設備狀態。
(3)當停車設備正確打開且車輛停入后,服務器收到反饋,對數據庫中該設備狀態進行更新。
(4)當用戶停車結束后,將車輛駛離停車設備。
(5)服務器監聽到設備狀態發生改變,對該次服務的訂單進行更新,記錄結束時間。
(6)服務器推送賬單信息給用戶。
流程簡圖如圖2所示。

圖2 停車流程簡圖
服務器后臺采用Spring+SpringMVC+MyBatis的經典SSM 框架。由Spring 統一所有實體類的創建與使用,SpringMVC 攔截用戶請求并處理,再通過MyBatis對數據庫表進行更新。
考慮到服務器需要對多個停車設備硬件下達指令,并且接收到反饋結果更新設備狀態,輪詢對服務器壓力過大,因此需要建立服務器與終端間的TCP 長連接,通過心跳檢測來確保連接狀態,同時還需要對不同的設備指令進行異步處理。
因此在SSM 框架的基礎上,整合了Netty 開源框架,由Netty 專門處理對于長連接的異步通信及狀態更新。它提供了對TCP、UDP、HTTP(S)等幾乎所有的通用協議以及文件傳輸的強大支持。在保證應用程序安全性、健壯性的同時又隱藏了其API 的復雜性,為不同傳輸類型提供了幾乎完全一致的API接口。
停車設備通信與服務器流程如圖3 所示。NettySocketListener 對服務器與停車設備的TCP連接進行監聽,心跳包中包括了當前停車設備的狀態,這些數據在專有的通道Channel 中傳輸。如果停車設備狀態發生改變,NettyServer ChannelInitalizer 將 通 知TCPServer Handler 把 這次數據更新,并交給Spring 生成相應容器,同時在SpringMVC 中進行處理,由Mybatis 更新數據庫該設備狀態和本次服務訂單詳情。

圖3 SSM+Netty框架下停車設備與服務器通信流程
如果是用戶主動發起請求,通過Netty Util與服務器建立連接、發出請求,請求由SpringMVC 攔截進行處理,通過Spring 生成具體指令,交由TCPServerHandler執行。
車庫管理云平臺作為智慧停車App 和智能停車設備的后臺服務器,同時對用戶及停車設備進行管理模塊。
云平臺主要分為3個模塊,分別是用戶管理模塊,訂單管理模塊和停車設備管理模塊。
(1)用戶管理模塊。用于用戶登錄,包括注冊功能和信息查詢。
(2)訂單管理模塊。訂單中包含停車設備id,用戶id,起始時間與結束時間。用戶發起的初始訂單不包含結束時間,當停車服務結束后,訂單更新并推送給用戶。
(3)停車設備管理模塊。僅對管理員開放,可以查看所有設備的狀態,添加新設備與刪除設備。同時可以對設備直接下達指令進行狀態更改。車庫管理云平臺用例圖如圖4所示。

圖4 車庫管理云平臺例圖
數據庫設計分為停車場信息表(Car_Park),停車設備信息表(Pillar_info),訂單表(Order),以及用戶表(User)。
其中停車場信息表包含其本身編號C_id,以及所在省市地區。
停車設備信息表包含設備編號P_id 以及所處停車場編號C_id,校驗碼crc,登記時間setup_time,以及status 狀態,其中0 代表關閉,1代表正在使用,2表示故障其他。
用戶表包含用戶登錄基本信息以及用戶編號,同時需要記錄用戶手機號碼與車牌信息。為方便管理,將管理員也加入到User 表中,用permission 來表示權限,0 為用戶,1 為管理員。管理員可對后臺的web 端進行操作,而用戶只可使用App前端。
訂單表包含本身訂單編號O_id,發起的用戶U_id,使用的停車設備P_id,訂單狀態status,起始時間startTime,以及結束時間endTime。
其中O_status 用于表示訂單當前狀態,0 為進行中,1為結束,2為異常申報。
新生成的訂單endTime為空,當停車服務結束后,對該次訂單結束時間進行更新,便于計算賬單。
其中,訂單表Order結構見表1。

表1 訂單表(Order)
智慧停車App 功能劃分為三個部分,分別是“我的”,“停車”和“歷史”。
功能結構圖如圖5所示。

圖5 App功能結構圖
(1)“我的”用于用戶登陸后顯示自己信息,可對資料進行完善,也可看到自己當前是否在停車狀態中。
(2)“停車”是主要功能模塊,根據移動設備的LBS 定位獲取經緯度信息,使用百度定位SDK 獲取具體所在地區,并在數據庫中與停車場信息表進行匹配,顯示附近的停車場位置。
到達停車場后,停車設備上貼有二維碼,用戶掃碼獲取停車設備信息,并發起停車請求,生成訂單。
通過停車結束功能結算當前訂單,訂單更新結束時間,用戶需要在五分鐘內完全駛離該停車樁。
(3)“歷史”功能可以查詢歷史停車記錄,包括所處停車場,使用的停車設備信息以及起止時間和支付金額。同時可以對有異議的訂單進行申報。
為了方便用戶使用停車功能,使得用戶不用下車也能便捷停車,采用App 掃描二維碼來發起訂單請求。二維碼生成基于Zxing 的開源庫。
二維碼包含該停車設備編號P_id,停車場編號C_id,上次維護時間maintenance_time 以及校驗碼,以Json 數據的格式編譯為二維碼張貼在停車設備上。
當用戶掃碼之后獲取Json 數據,App 使用Google 的開源庫Gson 工具對數據進行解析,驗證校驗碼,并確定該設備在使用年限中。然后獲取停車設備編號P_id,將自己的編號U_id 加上當前時間current_time 打包成新的Json 數據,并向服務器發送訂單請求。
服務器接到用戶請求,向指定停車設備下達指令,并且生成訂單。
流程圖如圖6所示。

圖6 掃碼停車流程圖
本文完成了基于無避讓智能立體停車設備的智慧停車系統,該系統包含一個車庫管理云平臺以及智慧停車App,結合智能立體停車設備可以大大提高停車場的空間利用率,使得停車更加規范化,緩解道路壓力,同時使用戶停車過程更加便捷,具有良好的經濟效益和社會效益。