Free up to 1MM monthly messages. No credit card required.
How many times have you gone around a parking lot more than twice looking for a space for your vehicle? You and I are not alone in this quest. Every time it happens, I keep wondering why there isn’t a smart way to reserve a parking spot in real time and pay automatically when you leave. Until now, when we took it upon ourselves at PubNub to build this.
In this blog post, we will demonstrate how to build a prototype of an IoT-enabled smart parking meter application using IBM Bluemix and PubNub. This application can assist the driver in reserving a parking space and the system can also automatically track billing based on the driver’s actions when the vehicle pulls in or out of the space.
IBM Bluemix provides the platform over which this application can be built, hosted and managed. PubNub powers the real-time communication between the different components of the application like the sensors, mobile application and the server application. This way IBM Bluemix and PubNub go hand in hand to create a dynamic real-time IoT application that is easy to build and scale.
There are three components of this application:
The PMS application server is hosted on the IBM Bluemix cloud platform and the entire communication between PMS to hardware and PMS to the mobile app is powered by PubNub’s real-time Data Stream Network.
The complete source code of the bluemix-parking-meter project can be found on Github.
Refer to the build instructions and readme file for detailed steps, right from configuring the hardware to hosting and running the application.
For hosting this application, you will need to create a Bluemix and PubNub account. Visit the IBM Bluemix signup page and PubNub add-on page to create your respective accounts. Both of the services offer a free tier account to play around with their offerings.
The following is the list of hardware components used for this project:
A sample setup on a breadboard is shown below:
And the associated schematic diagram for the hardware circuit is below:
There are three functional parts of the hardware:
The PMS is written in Python and can be installed as a IBM Bluemix hosted service. IBM Bluemix provides the computing horsepower for the PMS to monitor hardware devices and manage parking metering and billing for the users. Additionally you will need to associate the PubNub add-on service with your IBM Bluemix account for the PMS to work with PubNub. Refer to the steps in README.md to understand how to setup and host a Python application under Bluemix with PubNub.
The source code for PMS is located under the parking-meter directory in the GitHub repository.
The mobile app is a standard Cordova based Android app. It displays a map of the parking area with color coded parking spaces to assist the user in choosing a vacant space.
The source code for mobile app is located under MobileApp directory in the GitHub repository.
PubNub acts as the communication middleware for the entire system. It provides a cloud-based real-time Data Stream Network which supports more than 70+ SDKs, such that it can enable any device to communicate with any other device on the Internet. This application uses three of PubNub’s SDKs for all components to seamlessly communicate with each other. These are:
This application relies on several PubNub channels to enable communication between the components, as depicted below:
The <private-channel> in the above diagram refers to a dedicated channel between the PMS and the mobile app. All messages exchanged through the PubNub channels are in JSON format. For every mobile app requesting for parking reservation, the PMS initiates messages through this channel for that particular mobile app. The significance of all the channels will be clarified in the next section.
The complete operation of this system can be divided in following five scenarios.
When the mobile app is launched for the first time after installation, it asks for the license plate/registration number of the user’s vehicle. This acts as a unique identifier for the PMS to track the app for billing purposes.
Subsequently, the app sends a request to the PMS to get the status of all the parking spaces. This is used to display the map, where each space is identified with a slot number (001, 002 and 003). Here is how the message exchange takes place between the PMS and mobile app:
The JSON request from the app contains a parameter RequestType with the value ‘1’ to indicate a request for fetching the bulk status of all parking spaces. The JSON response from PMS contains the parking space’s slot number as the parameter and its status as either ‘0’ or ‘1’ , to indicate that the space is either vacant or occupied.
For the map display in mobile app, parking spaces which are currently vacant are indicated as green, whereas the ones that are occupied or reserved are indicated as red.
Whenever the parking space detects presence or absence of a vehicle, it immediately signals the PMS.
001 identifies the slot identification number of the space and the value ‘1’ indicates that the parking space is occupied. Alternately, a value of ‘0’ indicates that the space is vacant. The PMS also relays this information on a global PubNub channel
parkingapp-resp so that all apps can update their parking map display.
A user approaching a vacant parking space can reserve it in advance by tapping on a desired vacant parking slot on the app. This prompts the PMS to initiate a billing session for the user. PMS sends a message to the app on its private channel to initiate the start of billing. Along with this, PMS also starts a timer.
Here is a closer look at the format of JSON messages in this interaction:
RequestTypewith a value ‘2’ indicates a request for reservation
sessionTypewith value ‘0’ indicates the start of billing session for the user who has reserved the slot number identified by the value of deviceID.
Upon receiving the message on its private channel, the mobile app displays a message to the user to confirm his parking reservation request:
Additionally, the PMS also sends an update on the channel
parkingapp-resp to inform all mobile apps that the said parking space is now occupied.
After reserving, when the user finally pulls in and parks his vehicle in the designated parking space, the hardware sends a status update to the PMS to indicate reservation confirmation. At this moment, the PMS stops the timer.
Later, when the user pulls out his vehicle from the parking space, the hardware device again senses this and sends a status update to PMS indicating that the space is now vacant. Upon receiving this update, PMS calculates the bill for the user and sends a billing session stop message along with bill details to the mobile app via its private channel.
The JSON message received by the mobile app contains the parameters for the bill details:
Finally, the mobile app displays the bill details on the screen as follows:
PMS is programmed to charge $10 for every sixty minutes of parking.
In case the user reserves the parking space but does not show up, the PMS timer, which is started in scenario 3, counts down from 60 seconds to 0 and then finally performs scenario 5 without the hardware trigger. In this case the the user is charged with a minimum bill $10.
Further, this application does not have any provision to authenticate the user during parking (as part of scenario 4), so as to ensure that the user who reserved the parking space is the one who actually parks his vehicle in that space. This is left as an exercise for the readers who would want to further enhance this application and make it feasible for a “closer to real life” deployment.
We had a great time building and playing with this application and testing the end-to-end scenario was quite interesting, considering that there are quite a few subsystems involved.
Using IBM Bluemix & PubNub services greatly simplifies the developmental challenges as the developer can focus on the application logic without worrying about how to make the communication work between different subsystems. Apart from this, both the services are capable of handling massive scale which can be leveraged to build similar real world applications which require 24×7 uptime and thousands of users coming in.
Stay tuned for more demos and application use cases using IBM Bluemix & PubNub!
A Notice of Privacy Practices (NPP) is one of the requirements of HIPAA and helps patients understand their personal data rights.
HIPAA violations can be financially expensive and devastating to a brand. Examine some examples of HIPAA violations, and learn...
HIPAA covered entities must follow the five technical safeguards to achieve HIPAA compliance and prevent data corruption.