Lights on parking

Concept

Lights on Parking is a project created to monitor the availability of parking spaces and consequently, if they are free, indicate them to the citizen through an app / web page, optimizing the traffic of those looking for a lot.

Nowadays to find a parking lot is a very big problem in the most of the cities: population of cities (and in particular in the big towns) is always growing up, and so the demand for available parking spaces is growing. The main problem is that the space in a town is limited and so the demand has exceeded the availability of parking lots, and so the research of a free car parking is very difficult. This problem has a big impact on the world under a lot of aspect: from the study conducted by INRIX in 2017, it is possible to see that this problem in UK causes a cost of £23.3 Billion a Year, and in particular for each citizen 44 hours wasted and £733 every year. So to find a parking lot is a big problem that has a big impact in the world.

Through a network of intelligent devices we can monitor the current state of a parking lot (we can check if it is free or occupied) and aggregate this data to generate a centralized and complete knowledge on the real time situation of the parking lots in the city.

The prototype

In order to do our measurements for the project we built this simple prototype that allows us to simulate the real situation of a parking lot:

In this prototype we use the following components:

STM-32 LoRaWAN Discovery Board:

The B-L072Z-LRWAN1 LoRa®/Sigfox™ Discovery kit is a development tool to learn and develop solutions based on LoRa®, Sigfox™, and FSK/OOK technologies. This Discovery kit features the all-in-one CMWX1ZZABZ-091 open module by Murata. The module is powered by an STM32L072CZ microcontroller and SX1276 transceiver. The transceiver features the LoRa® long-range modem, providing ultra-long-range spread-spectrum communication and high interference immunity, minimizing current consumption.

The databrief is available here:

https://www.st.com/resource/en/user_manual/dm00329995-discovery-kit-for-lorawan-sigfox-and-lpwan-protocols-with-stm32l0-stmicroelectronics.pdf

Ultra sonic sensor:

Ultrasonic sensor HC-SR04: The HC-SR04 ultrasonic sensor uses sonar to determine distance to an object like bats or dolphins do. It offers excellent non-contact range detection with high accuracy and stable readings in an easy-to-use package. It operates in a distance range going from 2cm to 400 cm. Its operation is not affected by sunlight or black material.

Datasheet is available here:

https://cdn.sparkfun.com/datasheets/Sensors/Proximity/HCSR04.pdf

Wiring:

These components are wiring like in the following diagram.

How it works

Our device wants to check the state of a parking lot, in order to see if it is free or occupied, and to send this current state to the cloud that show to the user this state.

The device is positioned on every parking lot of a street, and it works in the following way:

• If the parking lot is free, it checks the state every 30 seconds.
• If the parking lot is occupied, it checks the state every 10 minutes.

When there is a change of the state (from occupied to free for example), by means of Lora it send the data to the cloud to report to the user.

In order to send the messages from the board to AWS we followed a well-defined pattern: the devices communicate via the LoraWan protocol with the gateways positioned in the area, which collect the information and send it via the MQTT protocol to the cloud which stores it inside a database, specifically DynamoDB. Finally, through a lambda function, a service offered by AWS, we work on our entries, extrapolating the data relating to the status of the parking lot, which will then modify our Web App in real time.

Web app:

It is a simple web page through which the user can interact with the system. Here you can monitor the situation of an area of the city, seeing how many parking spaces are available in that area.

Evaluation

The major constraint we have is about energy consumption: once the device is installed, it is difficult to maintain it so we want that the battery life to be as long as possible. We analyzed this problem trying to reduce the energy consumption as much possible, activating the device at specific time intervals. In fact, continuously checking if the parking space is occupied, when it already is, is not an efficient solution, because the situation will hardly change in a short time and so it is an unnecessary wast of energy. Furthermore we also want to optimize energy consumption for sending data to the cloud.

Sensor sampling frequency:

Therefore we decided to check the parking status, varying the measurement time intervals, putting the device in sleep-mode between one data measurement and another; we believe it is a good compromise between energy consumption and data availability. From the proportion time, the cars spend on average 4, 4% of the time driving and the 95, 6% parked. The analysis is revealed in Standing Still – a new report by the RAC Foundation – which looks at data provided by the leading net zero data analytics consultancy Field Dynamics and the Ordnance Survey, as well as government statistics.

So from these data we based our assumption with regard to how many times to measure the current state of a determinate parking lot: we want to measure the state more frequently when it is free, because it is more probable that there will be a change from free to occupied.

• If the parking space is free, it's easier to be occupied in a short time, so let's measure the situation with a higher frequency through the sensor.
• If the parking space is occupied, there are less chances that it being vacated in a short time, so measurement is less frequent.

Radio usage:

In addition to analyzing the consumption related to the electronic part, we also investigated on the activity of sending data, in order to optimize battery life.

We want to display to the user if a determine parking lot is free or not, so it is a big waste of energy to send to cloud the same data of the previous one. So we done the following assumption. The data are not sent at each measurements, but only when there is a change in the parking status:

• Empty parking space -> Occupied parking space.
• Occupied parking space -> Empty parking space.

This greatly reduce energy consumption, and it is perfect for our interest. In this way we can also be compliant with the LoRa duty cycle restrictions.

Results of analysis:

Initially we thought to measure every 1 minute if the parking lot is free, so doing a simple calculation (4, 4 : 95, 6 = 1 : x) we measure if a it is occupied every 22 minute. After some simulations we saw that in this way we don’t have much accuracy, because measure every 22 minute is cause of a lot error data. So we reduce these times of measure and we check the state of a parking every 30 seconds if it is free and every 10 minutes if it is occupied. This is the best compromise between accuracy and energy consumption.

We have chosen 3 specific cases:

1. Constantly connected device:

• In 1 hour it consumes (15 + 12.7) mA = 27.7mA
• In one day it consumes 664.8mA
• The device discharges after approximately 21 days.

2. Device with always free parking (worst case):

• We check parking status 30s.
• 58s sleep mode in a minute. -> 3480s of sleep mode in a hour -> consumes 0.79mA in one hour.
• 2s run mode in a minute. -> 120s of run mode in a hour -> consumes 0.42mA in one hour
• Overall in 1 hour it consumes (0.79 + 0.42) mA = 1.21mA.
• In one day it consumes 29.04mA.
• The device discharges after approximately 482 days.

3. Device with always occupied parking (best case):

• We check parking status every 10 minutes.
• 3594s of sleep mode in 1 hour -> consumes 0.818mA in one hour
• 6s of run mode in 1 hour -> consumes 0.046mA in one hour
• Overall in 1 hour it consumes (0.818 + 0.046) mA = 0.864mA
• In one day it consumes 20.736mA.
• The device discharges after approximately 675 days.

So in a real operating situation of the device, the battery life varies from a minimum of 482days to a maximum of 675days, against only 21days if the device is constantly in run mode.

Latency

In order to have a real time update we focused on analyzing the latency time between the measurement and the receiving the message. The time interval is composed by:

• Time of the Ultrasonic sensor: the time needed to compute the measurements of the current state.
• Time send Message: the time needed to send a message.
• Time on Air: the time needed to a message to go from the board to the LoRa gateway.
• Time of Cloud: the time from the LoRa gateway to the end-user.

So to measure the time from the measurement to the moment where the data are available (and so the latency) we have to do the sum of these values.

Let's see in detail the values of these parameters:

• Time of the Ultrasonic sensor = 1s because the system performs the measurement for one second.
• Time send Message = 0.05s because the board dose not take more that 0.05ms to compute the measurement and send it on the network.
• Time on Air = 0.07s - 0.08s. To compute this value we use the tools available here. The messages we send are occupied and free so they have respectively 8 and 4 bytes of payload, and the header packet of Lora is 13 bytes. So the input bytes is of 21 size, the speeding factor is 7, the region is EU868 and the bandwidth is 125hHz, and from this values we compute the airtime from the board to the gateway.
• Time of Cloud = 2s this is the time needed on the cloud to process the data and it does not take more than 2s.

So:

1s + 0.05s + 0.08s + 2s ≃ 3s

Future plans for technology improvements

Edge computing:

For the moment our project show to the user if a parking lot is free or occupied, and not the state of an entire street for example. For the future we want to implement this functionality that allows to the user to check how many parking lots are free or not in a certain street, not only the state of one parking lot.

Solar energy:

We could add a solar panel to reduce the size of the needed battery (and remove so the powerbank that supplies the system) and increase the lifetime.

Electromagnetic sensor:

This is the most important future plane for our project.

This sensor, once positioned and calibrated, allows to detect the presence of vehicles parked in the car park. The technology used is able to record the variation of the earth's magnetic field in a solenoid induced by the presence of the ferrous mass of the vehicle. The requirements of this sensor are the following:

• The installation is extremely economical and practical as it is not necessary to intervene on the roads to lay cables;
• It also helps to ensure greater safety for pedestrians;
• Maximum privacy protection, infact the sensor records an anonymous data based on the variation of the earth's magnetic field;
• Easier maintenance;
• Improved aesthetics;
• The device turns on only when a vehicle is positioned on the free stall and so low battery consumption.

This device is extremely versatile, with a very high level of efficiency and an unparalleled performance / price ratio. With this sensor is possible also to have an accuracy of 100%.

Conclusion

Here is possible to watch a little demo of our prototype.

Here is the repository of our project.

Check our LinkedIn profiles:

• Stefano Rucci - Linkedln Profile
• Alessia Santamaria - LinkedIn Profile
• Andrea Scalera - LinkedIn Profile