近年来, 随着我国经济的发展, 中国民用汽车保有量持续高速增长. 据统计^[1], 1995至2016年, 中国民用汽车拥有量由1040万辆剧烈增加到19 440万辆, 年均增长率高达14.96%. 2012年, 中国民用汽车保有量更是首次突破1亿辆大关. 而大城市市中心的停车场却已几乎接近饱和, 难以大规模扩大停车位规模. 汽车保有量持续增长与停车位数量停滞之间的矛盾急待解决.

为此, 北京、上海等多个城市推出立体车库^[2], 商场车位共享利用^[3], 老旧小区改造等提高公共资源利用效率的方案, 取得了一定成效, 但仍有不足, 例如立体车库的建设成本较高, 停车不便利, 对车主车技有一定要求; 老旧小区改造, 还是受有限的物理空间的限制, 缓解程度很有限; 商场车位共享在居民区相对远离商业区的情况, 可操作性并不强. 相对这些通过增加车位来缓解矛盾的方法之外, 我们还会注意到, 现实生活中还存在大量空闲车位, 因不方便被发现, 或不能分时共享而造成的变相浪费. 于是, 我们提出了一种基于app的共享车位系统的解决方案, 配合智能车位锁, 让车位主在车位空闲时, 将车位信息动态发布, 供有停车需求的人发现, 通过app控制智能车位锁, 实现车位分时共享, 及时发现.

1 智能车位系统构思

为实现共享车位的信息实时发布、发现、租赁、归还和计费, 在车位主和车位需求者搭起沟通的桥梁, 我们将业务功能分割成如图1所示三种不同用户功能. 主要覆盖以下内容:

1.1 车位主用例

(1)个人车位实时发布: 车位主可以在车位闲置期间, 将车位发布, 供有需要的车主发现可用信息.

(2)个人车位停止发布: 车位主不想把车位出租出去时, 在app上点击停止发布后, 车位将不再显示在app上.

(3)盈利结算: 按车主租用费用按一定比例付与车位拥有主.

1.2 车主用例

(1)个人车位实时发现: 车位能够在app上的地图看到附近可用车位, 并导航到车位位置.

(2)车位租用: 车主在app上点击开锁即可打开智能车位锁.

(3)计费和付费: 车主在使用结束后, 在app上点击关锁即可锁起智能车位锁, 系统自动按使用时间乘以单价计费计算出此次租用价格, 使用时间为智能车位锁开启的时间到关闭的时间, 此后可利用微信和支付宝等电子支付工具进行支付.

1.3 管理员用例

(1)车位状态实时监控: 管理员能够监控各个区域实时的车位情况, 剩余可用车位数量等.

(2)订单管理: 数据库会记录所有用户的每次租赁的情况(例如开始时间, 结束时间, 租用车位号, 总价等等), 如产生异议, 管理员可对其追溯.

(3)用户管理: 为了防止不付款等恶意行为, 我们会给予每个用户信用分评价, 管理员能够将禁止分数过低的用户使用app上的功能.

2 软件系统架构选型

随着“Web 2.0”概念的提出, Web Services已经在互联网的方方面面广泛使用, 目前Web Services有两种主流架构, 分别是面向服务的SOAP架构和面向资源的REST架构.

从基本原理上看, SOAP架构是一个严格定义的信息交换协议, 用于在Web Service中封装成机器可读的格式化数据. REST架构则是一种轻量级的架构, 完全基于http协议本身来实现^[4].

在具体的协议上, SOAP架构采用应用程序自定义协议的方式, 其中WS-*一系列协议是最为广泛使用的, 但其缺乏统一的标准. REST架构采用http协议.

原生提供的GET、POST、PUT和DELETE四个方法, 分别正好对应获取、创建、修改和删除四种对资源的操作. 并把符合REST架构设计的应用编程接口称作RESTful api.

实现方式上, SOAP架构是是基于wsdl描述, 然后通过UDDI注册发布, 从而再被调用者发现, 实现调用. REST架构通过url来定义因特网上独一无二的一个资源, 所谓资源, 就是指网络上一个实体, 或者说是网络上的一个具体信息, 通过设计RESTful api来使用四种http方法来改变这个资源的状态, 完成相关业务逻辑.

在使用场景上, SOAP架构适合复杂的非功能性的需求以及端到端之间的交互, 例如银行ATM机对数据库中用户金额的读写操作REST架构适合无状态, 多个终端之间的简单交互, 例如对数据表单的简单增改删查^[5,6].

虽然REST架构在处理大规模复杂问题上不如SOAP架构, 但REST架构简单, 系统性能高. 数据量越大时REST架构的服务性能越优于SOAP架构^[7]. 此外, REST架构具有耦合度低, 易于扩展等优点, 智能共享车位系统具有交互简单, 资源清晰, 状态明确的特点, 非常适合选用REST架构.

3 基于REST架构的共享车位系统逻辑框架

结合架构选型, 综合考虑系统待完成的功能, 本文设计的系统架构如图2所示. 架构将整个系统的逻辑结构分为四个组成部分, 分别是: 客户端app, 后台管理系统, 智能车位锁和中央服务器.

3.1 客户端app

客户端app作为提供给车位主和车主的主要终端交互方式, 具有注册登录, 地图上标记车位, 导航, 控制智能车位锁打开/关闭以及显示计费等主要功能.

3.2 后台管理系统

后台管理系统是提供给管理员的终端, 实现管理员对车位主, 车主的集中管理. 界面实时显示车位状态, 可用车位数量, 订单记录, 用户记录, 并建立相应的数据库保存所有历史记录, 方便运营维护和责任追究.

3.3 智能车位锁

智能车位锁是由车位锁服务器和车位锁两个部分组成的.

车位锁采用Aithinker7模块, 可以进行GSM/GPS/GPRS通信, 实时上传车位信息, 包括设备号(如0001), 经度, 纬度, 锁的状态(0,1), 是锁否被锁定(0,1). 车位锁的通讯情况较为复杂, 且若在信号不好的地方(如地下室等)较容易断开连接, 此时需要重连.

为了降低耦合度, 车位锁不与中央服务器直接通信, 而是与车位锁服务器建立基于TCP/IP的socket长连接通信. 车位锁服务器是车位锁和中央服务器的中介, 将连接的具体细节屏蔽后, 提供开锁和关锁的RESTful api给中央服务器调用, 将复杂的通信变为请求-等待-回应的简单模型, 即中央服务器向车位锁服务器请求开锁或关锁, 等待处理, 车位锁服务器返回结果(成功或失败).

3.4 中央服务器

中央服务器是全系统的核心, 提供了数十个RESTful api实现与app、后台管理系统以及车位锁服务器的连接. 为了保持数据和状态的统一性, 各部分都只和中央服务器交互, 由中央服务器统一将数据保存在数据库中.

在app侧的RESTful api主要实现用户的登陆、短信验证码获取及注册、获得该用户所有订单历史记录、查询附近车位并计算距离、发布车位、取消发布车位、开启智能车位锁并创建订单和关闭智能车锁并结束订单等功能.

在后台管理系统侧, 管理员拥有比普通用户更高的权限, 这一侧的RESTful api主要实现查看订单记录并进行筛选、监视车位状态和查看用户历史记录等功能.

在智能车位锁一侧, 也是采用REST架构对开锁、关锁这两个核心交互的业务逻辑进行封装和抽象, 从而实现在app和智能车位锁之间达到了双向透明传输的效果. 于是, app不需要知道智能车位锁具体的通信方式, 智能车位锁也不需要知道app上层的业务逻辑. 以app上打开车锁并创建一个订单开始计费的一个智能车位锁侧的RESTful api为例, 其定义如下:

创建订单的api

/order [POST]

·请求

-head

·Authorization [必填][token]

-body

·parkingSpace_id [必填][车位id]

·回应

-状态码200: 示例返回数据格式:

{

"result":[ {

"id": 48,

"user_id": 2,

"parkingSpace_id ": 1,

"parkingSpace _name": "1号",

"address": "第二小区左侧",

"price": 10,

"status": 1,

"status_name": "已创建",

"start_time": "2017-07-19

22:23:43"

}]

}

-状态码401错误 token错误

-状态码404错误 没有这个车位

-状态码403错误 车位状态不是空闲

4 REST架构下的核心代码实现

几乎所有主流开发语言都支持REST架构, 其中nodejs是基于事件循环的异步非阻塞I/O模式, 在以被访问为主要功能的服务器中效率较高, 因此我们选用的服务器端程序是基于nodejs的express框架, 在这种框架下, 一个RESTful api恰好对应一个中间件, 每个中间件都是一个独立的模块.

在上述RESTful api定义基础上, 以下给出部分api代码实现.

4.1 车位信息获取api

车位信息获取api是在app加载完成后自动调用, 从而获取信息的. 服务器会根据用户请求的区域, 以及用户提供的经度和纬度, 在数据库查询相应的车位并计算距离, 然后按距离从小到大的排序, 返回查询结果.

代码示例:

var querySql='Select… From …

Order By

calculateDisdance(request.latitude,request. longitude,latitude,longitude) ;';

//根据车位和用户距离排序的sql代码, 查询部分具体代码省略

var [result]= await mysqlQuery(querySql);return response(result);

4.2 创建订单的api

在app上点车位开锁, 首先app会发一个http请求给中央服务器, 此时中央服务器进行一些业务处理(例如检查是否登陆, 检查车位是不是已经被占用了) 之后, 向车位锁服务器发一个开锁的http请求, 这时候车位锁服务器会向智能地锁发一个tcp包检查当前智能地锁是否在线, 是否能打开, 如果正确打开, 智能地锁向车位锁服务器回发一个tcp包, 车位锁服务器再向中央服务器返回一个成功的http状态, 中央服务器将这次行为包装成一个订单后记录进数据库后, 向app返回一个成功的信息. 如果有任何一个环节出错, 就会向app返回一个拒绝的信息, 不会开始收费, 这样保障了系统的健壮性.

代码示例:

//查询车位状态

var querySql='Select… From … ';

Where parkingSpace.id=request.parkingSpace_id'

var [parkingSpace]=await mysqlQuery(querySql);

//具体没有该车位id, 返回错误

if(!parkingSpace){

return response('no such parkingSpace');

}

//具体该车位状态不是空闲, 返回错误

if(!parkingSpace.status!==1){

return response('status invalid');

}

//向车位锁服务器发送开锁请求

try {await middleServerPost(parkingSpace.lock_id,'open')}

//如果开锁失败, 返回错误

catch(e){return response('fail to open')};

//向数据库插入新的数据

var insertSql='Insert Into order … Values …;

Select … From … Where id=last_insert_id();';

var [result]= await mysqlQuery(insertSql);

//如果一切正常, 返回正确结果

return response(result);

4.3 后台管理系统获取地区状态的api

管理员登录后会定时轮询这个api以获得最新的动态情况, 在服务器中计算出每个地区的车位数量及可用车位数量后返回给浏览器.

代码示例:

var querySql='Select totalParkingSpace,

availableParkingSpace … From …

Where … Group By region.id';

var [result]= await mysqlQuery(querySql);return response(result);

5 原型系统展示

以车主用户为例, 打开app后, 附近的可用停车位用P图标在地图上标识, 如图3(a)初始可用车位标记页面所示.

此时用户可以选择预停的车位, 点击地图上的图标后将自动生成导航路线, 如图3(b)所示, 待用户到达指定车位后, 可以看到智能车位锁处于图4(b)点击开锁图标即可进入开锁界面, 如图3(c)所示. 点击开锁后, 智能车位锁将会自动打开, 如图4(c)所示, 用户此时可以实现停车.

停车结束后, 用户将车开走, 然后点击app的结束停车图标, 如图4(a)所示, 智能车位锁将会自动关闭, 如图4(b)所示, 同时结算本次计费, 对接用户账户完成扣款.

​以体育馆门前某一个停车位为例, 原来没有任何信息化管理, 该车位长期处于空闲状态, 增加智能停车锁后, 统计该车位一天内的使用情况, 如图5所示, 可以看出, 使用频次明显增加, 这在无形中就拓展了可用车位, 缓解了车位难求的困境.

6 结束语

本文利用REST架构模块化, 易扩展, 无状态等优点, 提供了基于REST架构的智能车位锁物连网解决方案, 可以将分时可用车位信息集中发布, 并共享给手机用户, 用户借助手机app可以发现, 查找, 预约和导航到对应车位, 并可以实现车位锁开启和闭合控制等操作, 有效提升了车位管理水平和车位使用效率.

该系统在今年的全国移动创新大赛, 全国iCAN大赛决赛以及上海市的创造杯大赛中都取得不错的成绩. 在第十九届中国国际工业博览会上展示, 也得到了来自物业、停车场行业相关企业以及市民的广泛好评和热切关注.