Smart Parking IoT Solution based on AWS Web Services

Solutions Overview

The city of Roundabout has decided to attack the problem associated with the street parking,
where motorists struggle to find vacant parking spaces in the downtown area. They contacted
AWS Professional Services for a solution using Amazon AWS Technologies.

Following is the Technical Solution proposal developed for this customer.

Architecture and Design description

The main idea of this solution consist on having the parking meters connected to the AWS
Platform to update the current state of the parking slot. This detection is based on sensor
technology that informs the meter when a car is parked or the spot is empty. With this
information in the AWS Platform, the users (motorists) can use an Apps (from 3rd party
developers) to query the platform for available spots in the current location. Additionally, the city
parking management could gather useful information for management, analysis and control.
Following is the proposed Architecture for the solution:
In the above architecture diagram, the parking meters are connected to AWS IoT Core via an
appropriate connectivity technology (see Connectivity technology options below), and sending
an update to a mqtt topic including deviceID (unique device identifier), a timestamp and the
state (Occupied/Free). Additional, other meter’s parameters such as payment status, battery
level, signal level (RSSI wireless signal indicator), etc., could also be sent for monitoring
purposes. The deviceID is unique and it’s associated with a location, address and meter number
(any specific address may have many parking meters, so the number identify each one for that
address). Since this association is in the datastore, there is no need to re-send for each packet
minimizing transmission costs and power (shorter messages).

A Rule configured in AWS IoT Core will monitor this update topic and trigger a lambda function
which will eventually update the information in the datastore, keeping the meter’s information
updated.

The datastore is implemented with DynamoDB so the solution can scale without problems.
Since the intention is to provide motorists with information of available parking near to their
current location, the datastore needs to process requests with the current location and a radius
to indicate an area around this central point. For this particular geolocation problem, we use the
Geo Library for DynamoDB (dynamodb-geo) which creates Geohash indexes for fast and
efficient execution of location-based queries over DynamoDB items representing the parking
meter location around the downtown.

There is an initial task to populate this datastore with the parking meter information and
associated Geohashes, using a node.js code (​import.js​ - see appendices for the code) which
imports the meter data from a json file provided by the city. This code can also be used to
maintain (add or delete meters) in the datastore. These JSON files can be uploaded to S3 to
maintain a reference, in case there is a need to re-create the datastore.

Once the datastore is in place, the ​parkingUpdate.js​ code (triggered by a Rule, as described
above) will update the corresponding record to keep the meter state current (occupied/vacant).
This code uses parameters such as deviceID, location, state and timestamp passed by the
JSON file published by the device in the mqtt topic. The location is needed to calculate the
hashKey (partition key of the table) while the deviceID is used as the rangeKey (sort.key).

An additional datastore can be created with the historical data for each device. This is
implemented in DynamoDB with the deviceID as the primary partition-key and timestamp as
sort-key. This datastore can be used for management or control purposes, providing an history
of activity from each meter (every time was occupied and busy with the corresponding
timestamp, as well as knowing if the user paid or not, while the car was occupying the spot).
At this point, the location datastore is up and current, so in order to retrieve the meters close to
a specific location, a ​parkingQuery.js​ is used which uses location (latitude/longitude) and a
Radius (in meters) to delimit the area of interest. This code is exposed through the API Gateway
which is used by the Apps to retrieve the requested information.

In a typical scenario, a motorist looking for parking in the city, would use the Apps (from 3rd
party developers) which will take the current location and suggest a Radius of search (the user
can change this) and use Amazon Cognito to authenticate with API Gateway and send the
request. This request is processed by API Gateway triggering and passing the parameters to
parkingQuery.js​ which will retrieve the information. The Apps will use this information to show
in a map, the available parking spots around the current location.

The following sections will provide detailed information for each specific topic of the solution.

Hardware/Sensor technology

In order to detect if the parking space is occupied (by a vehicle) or vacant, a sensor must be
used. Different options exist with cost and accuracy differences;

- Magnetic sensor:​ it’s a passive sensing technology that detects large ferrous objects
(like a car) by measuring the change in the ambient magnetic field. These sensors are
installed in the floor of the parking slot, so when a vehicle parks on it, it alters the
magnetic field and the sensor detects those changes. Even when this type of sensor
requires more labor for installation, accuracy is very good so it’s one of the best options.
Some sensors might have cellular connectivity so they can work independently of the
meter, while others might have low power wireless (such as BLE) connectivity to connect
them to the meter, being forwarded to the cloud using the meter cellular connectivity.

- Ultrasonic sensor:​ this sensor uses sound waves to detect objects. Although it’s a better
option to use indoor (mounted on the ceiling to detect a vehicle in the parking space
below), it could be used as a cheap option mounted on the meter pole, or even better, in
 the parking space floor; as in the first case, a person standing in front would block the
sensor. This sensor is very cheap but accuracy is not as good as the magnetic sensor.

- Video camaras​ using object detection techniques could also be an option in the near
future, as currently the cost of implementing could be much higher than the above
options, while providing the same information (occupancy).

Connectivity technology options

Regarding connectivity suitable for this solution, following are the options;

- Cellular data communication:​ GSM modems for cellular (3G/2G) data communications
are readily available and might be the best option considering most of the parking meters
installed today are already using these channels for payment authorization. Unless the
sensor includes this communication and operates independently, it would be convenient
to connect the sensor to the meter to re-use this communication channel.

- LoRA (Long-Range) communication:​ as an option, this LPWAN technology is being used

in many outdoor use cases, so it could be a good alternative to the cellular technology,
in terms of cost and power consumption (as most of the meters operates from batteries
with solar panels for rechargement).

- Other technologies:​ NB-IoT, LTE-M and 5G might be a good option in the near future.

Scalable Data Processing architecture

In order for this solution to deliver reliable performance at any scale, we chose DynamoDB - a
fully managed, multi-region, multi-master database - as the datastore; and Lambda which
allows to run code without provisioning or managing servers, paying only for the consumed
compute time. AWS IoT Core service allows an easy and secure connection and management
of billions of devices. API Gateway complements the solution allowing access to the data in a
fast, reliable and secure way using Cognito service.
Geolocation technology

In order to support geospatial indexing on AWS DynamoDB datasets, we use Geo Library for
Amazon DynamoDB, which takes care of managing Geohash indexes. Giving the library the
user information (including localization) to populate into a table, the library will create a Geohash
and Geohash-key and create the table with the appropriate setup, suitable for fast and efficient
queries for records with location points close to the provided location.

Interface for 3rd Party Apps developers

The solution interfaces with 3rd Party Apps via AWS API Gateway, which uses Lambda to query
and retrieve the requested information from the datastore. This datastore, the ​parkingMeters
DynamoDB table, is configured to search the available parking meters in a radius and location
specified in the Request. The Response will contain number, address and location of all
available parking meters in the specified radius.

For security purposes, the access to the API Gateway requires AWS Credentials given to the
App once it signs-in in AWS Cognito and exchanges tokens to get the credentials.

Access to Historical data

In order to keep track of the activity of a specific parking meter, a second DynamoDB table is
created (​parkingActivity​ table), using the deviceID as partition key and the timestamp
(provided in the JSON message of the update operation) as the sort key. Via API Gateway, after
validating access though AWS Cognito, the user (mainly the parking system supervisor) can
retrieve the requested information.
Platform Security and Data Protection

The security is ensured in the following ways;

- All communication from the parking meters to the AWS IoT Core is secure with TLS 1.2
(or greater) with mutual authentication (meaning the device - the client - needs to
present it’s digital certificate to the server to be validated).
- Communications between Mobile Apps and AWS API Gateway is via HTTPS (TLS), and
Authentication is made via AWS Cognito.
- The Data Protection in the datastore can be achieved using encryption provided by
DynamoDB.

Implementation details

Once the datastores are setup, operations occur in two ways; ​update​ (from the parking meters)
and ​query​ (from the users through the Mobile Apps).

Update operation​:

Every parking meter will publish an update to the ​‘parkingMeters/update’​ mqtt topic, with the
following JSON format;
A Rule implemented in AWS IoT Core will monitor the mentioned topic, and trigger two lambda
functions (​parkingUpdate​ and ​parkingActivity)​ to update both tables; ​parkingMeters​ and
parkingActivity​. The code is printed in the appendices. Following is the Rule configuration;
Query operation:

The Mobile Apps will sign-in with AWS Cognito to get the AWS Credentials necessary to access
the AWS services. Once the access is granted, a HTTPS Request is issued to the API Gateway,
including the Query parameters (current Location - latitude and longitude - with the Radius to
consider in the search). The API Gateway will pass the parameters to the​ parkingQuery
lambda function which after execution, will return the requested information. See appendices for
the code of the ​query.js.​ Following is the configuration of the API Gateway (note: in order to
simplify the testing, authorization is not enabled in this demo).
Once API Gateway is configured and deployed, an access point (http:// address) is generated
for public access. This can be tested from the web browser or used as the access point to the
REST call from the application;

API Gateway documentation:

This service will provide information for all vacant parking spaces in a specified radius from a
specified location (latitude, longitude).

Method: HTTPS GET

Path: Production/queryparking
Parameters (query string):

● Latitude:
● Longitude
● Radius (in meters)

Example:

https://b37408j2nb.execute-api.us-west-2.amazonaws.com/Production/queryparking?radius=10
0&latitude=-32.8645&longitude=25.9577

Possible Enhancements to the Solution

An interesting enhancement could be consider if the parking sensors and logic are integrated
with the parking meter payment system, as in this case it would be possible to detect when the
parking slot is being used and checking if payment is valid. Otherwise, a notification could be
issued to the parking enforcement authorities to notify for this situation.
Appendix A - Code implemented for ​import.js
Appendix B - Code implemented for ​update.js
Appendix C - Code implemented for ​query.js
Appendix D - Update & Query operations testing

The implemented solution was tested querying the vacant parking spaces for a particular
location/radius before and after an update operation in one of the parking meters in this area.

1 - Query operation for location (-32.8645,25.9577) and radius of 100 meters: this brings 3 vacant parking spaces;

2 - Update operation simulated with MQTT.fx utility, declaring deviceID = ABC105 (corresponding to parking meter
number 2 of location (-32.8645,25.9577) , address “093 Harris Parkway, XYZ, AB”) changed its state from vacant to
occupied;

3 - Refreshing the browser, now we get only two vacant parking spaces (number 2 is now occupied);
Appendix E - JSON file format used with​ import.js

There are 31 parking meters located in 10 addresses.

Appendix F - API Gateway for Meter Activity information

API Gateway documentation:

This service will provide activity information for a specified device, in a specified timeframe.

Method: HTTPS GET

Path: Production/getparkingactivity
Parameters (query string):
 ● deviceID:
● ts1: (Timestamp1)
● ts2: (Timestamp2)

Example:

https://lh3zobggjd.execute-api.us-west-2.amazonaws.com/Production/getparkingactivity?deviceI
D=ABC105&ts1=1538875900&ts2=1538975930

Test result;

Datastore for activity;