PARKTag: An AI–Blockchain Integrated Solution for an Efficient, Trusted, and Scalable Parking Management System

Abstract

The imbalance between parking availability and demand has led to a rise in traffic challenges in many cities. The adoption of technologies like the Internet of Things and deep learning algorithms has been extensively explored to build automated smart parking systems in urban environments. Non-human-mediated, scalable smart parking systems that are built on decentralized blockchain systems will further enhance transparency and trust in this domain. The presented work, PARKTag, is an integration of a blockchain-based system and computer vision models to detect on-field free parking slots, efficiently navigate vehicles to those slots, and automate the computation of parking fees. This innovative approach aims to enhance the efficiency, scalability, and convenience of parking management by leveraging and integrating advanced technologies for real-time slot detection, navigation, and secure, transparent fee calculation with blockchain smart contracts. PARKTag was evaluated through implementation and emulation in selected areas of the MIT Art Design Technology University campus, with a customized built-in dataset of over 2000 images collected on-field in different conditions. The fine-tuned parking slot detection model leverages pre-trained algorithms and achieves significant performance metrics with a validation accuracy of 92.9% in free slot detection. With the Solidity smart contract deployed on the Ethereum test network, PARKTag achieved a significant throughput of 10 user requests per second in peak traffic hours. PARKTag is implemented as a mobile application and deployed in the mobile application store. Its beta version has undergone user validation for feedback and acceptance, marking a significant step toward the development of the final product.

1. Introduction

Vehicle parking is a major problem in urban areas in both developed and developing countries. Following the rapid increase in vehicle ownership, many cities are suffering from a shortage of parking areas with an imbalance between parking supply and demand. This imbalance is partially due to ineffective land use planning and miscalculations of space requirements during the first stages of planning, shortage of parking space, high parking tariffs, and traffic congestion due to drivers in search of a parking place. To find a vacant parking slot, vehicles waste liters of gas [1,2]. Reports say that it often takes cars between 3.5 and 14 min to locate a vacant parking space, and 30% of all traffic bottlenecks 29 are typically brought on by drivers looking for parking spots [3]. Moreover, it leads to the depletion of air quality, energy consumption, and heavy traffic, which hampers environment-friendly and sustainable development [4]. Anonymous parking systems also result in an increase in hassles in the case of motorists who park their vehicles wrongly and create problems [5].

Autonomous parking space identification without human intervention involves alerting and directing about vacant parking spots beforehand. There are manual parking systems where a parking attendant helps the driver locate a vacant parking spot for the car. These solutions are non-scalable. The issues of determining when and where a parking space is currently vacant, navigating a car to the right parking space, and manually charging tickets only compound the difficulties already present in typical parking systems. Such issues can be solved by creating an intelligent, smart parking system [6].

One of the major smart city initiatives is the successful implementation of smart cities that would improve mobility and transportation [7]. Parking management systems involve free slot identification, route planning, vehicle identification management, and parking charge calculation. Potential applications of parking identification and prediction systems can be applied in (a) autonomous parking space identification without human intervention [8]; (b) control traffic density [9]; (c) identification of electric car charging spaces [10]; (d) available space in smart port for cargo storage [11]; and (e) vehicular identity management and non-mediated parking metering.

We propose the PARKTag framework, which assists the drivers with space-driven systems as well as with car-driven systems that can route to the nearest parking lot. Space-driven systems are based on the analysis that determines the occupancy of individual parking spaces. Car-driven systems are based on the detection of vehicles based on analysis of their location in parking spaces [12]. Smart cities utilizing space-driven systems based on deep learning solutions [13,14,15,16] impacted 45% of drivers in availing parking spaces successfully by using information related to the availability of parking spaces [17]. Thus, an intelligent, trusted, and efficient parking management system that helps drivers find a parking slot, guides the route efficiently, manages vehicle identity, and automates parking metering calculation is needed in time.

This work tries to identify various research gaps and challenges that open doors for future research and advancements in parking identification and prediction for space-driven systems through an extensive literature survey. Hence, the key contribution of this work is to provide an autonomous on-field parking assistant system, which is as follows:

• Unique identity management of vehicles using PARKTag;
• A decentralized application using blockchain and smart contracts for generating non-human-mediated parking tickets;
• Deep learning-based module to find free slots at a given parking slot integrated with central database connectivity;
• A routing module to route the vehicle to the nearest parking slot with free slots.

The proposed study is evaluated through the implementation of a pilot study built at the selected areas within the campus of MIT ADT University using a customized MIT-ADTU parking image dataset.

The rest of this paper is organized as follows: Section 2 introduces a literature review, providing a brief analysis of available parking lot datasets, feature-based and deep learning-based parking space classification, QR-based, blockchain, and smart contract vehicular identity management, and metrics used for performance evaluation of Smart Park Detector and Smart Park Ticketer. Section 3 explores the research gaps. Section 4 explains the proposed framework with the customized dataset. Section 5 explains the experimentation utilized, followed by results in Section 6. The conclusion and future work are presented in Section 7.

2. Literature Review

In this section, an extensive literature survey is conducted. The literature review is divided into the following:

• Study of popular parking lot image datasets in the literature for building pre-trained computer vision deep learning models for parking lot detection;
• Study of deep learning models used for parking lot detection;
• Study of sensor-based parking management systems;
• Quick Response (QR)-based vehicle identity management in the literature;
• Blockchain and smart contract-based parking management systems;
• Performance benchmarks for evaluation of smart parking systems.

2.1. Popular Parking Lot Datasets

To evaluate and validate the identification and prediction of vacant parking spaces, there are several main parking lot datasets. Table 1 provides a brief overview of some of the major parking lot datasets on which extensive study has been carried out.

Other datasets that have also been used for evaluation and validation are discussed as follows: PS2.0 [18] dataset consists of 9827 training images of parking lots and 9476 images of parking spaces. The images of this dataset are captured at Tongi University, Shanghai, China. The Sii-Mobility [19] dataset is collected from downtown hospitals and outskirt parks in Florence, Italy. The dataset contains images from 12 parking spaces. Birmingham [20] datasets consist of 29 parking spaces in Birmingham, U.K. The Melbourne [21] dataset contains 12,208,178 records of parking events from 75 streets in Melbourne’s central business district.

Table 1. Overview of datasets used for free parking lot classification.

Dataset	Author	No. of Parking Lots	Image Size	Total No. of Images	Labeled (Yes/No)	Weather Condition	Camera Orientation
PKLot	Almeida et al. (2015) [21]	2 with 3 cameras angles	1280 × 720	695,851 48.6% occupied 51.4% empty	Yes	Taken during daytime. Labeled as sunny, rainy and cloudy weather	Top view
CNRPark	Amato et al. (2016) [22]	1 with 2 cameras angles	150 × 150	12,584 33.2% are empty 66.8% occupied	Yes	Taken during daytime. Only sunny conditions considered	Top view
CNRPark-Ext	Amato et al. (2017) [23]	1 with 9 different camera angles	1000 × 750 resized to 150 × 150	4278 combined with CNRPark 44.3% empty 55.7% occupied	Yes	Taken under different weather conditions such as sunny, rainy, and overcast	Top view
PLds	Martin Nieto et al. (2019) [24]	1 with 3 cameras angles	1280 × 960	8340	No	Taken during daytime and nighttime. Labeled as sunny, rainy, snow, and cloudy	Top view

Table 1. Overview of datasets used for free parking lot classification.

Dataset	Author	No. of Parking Lots	Image Size	Total No. of Images	Labeled (Yes/No)	Weather Condition	Camera Orientation
PKLot	Almeida et al. (2015) [21]	2 with 3 cameras angles	1280 × 720	695,851 48.6% occupied 51.4% empty	Yes	Taken during daytime. Labeled as sunny, rainy and cloudy weather	Top view
CNRPark	Amato et al. (2016) [22]	1 with 2 cameras angles	150 × 150	12,584 33.2% are empty 66.8% occupied	Yes	Taken during daytime. Only sunny conditions considered	Top view
CNRPark-Ext	Amato et al. (2017) [23]	1 with 9 different camera angles	1000 × 750 resized to 150 × 150	4278 combined with CNRPark 44.3% empty 55.7% occupied	Yes	Taken under different weather conditions such as sunny, rainy, and overcast	Top view
PLds	Martin Nieto et al. (2019) [24]	1 with 3 cameras angles	1280 × 960	8340	No	Taken during daytime and nighttime. Labeled as sunny, rainy, snow, and cloudy	Top view

2.2. Deep Learning-Based Parking Space Classification

For efficient detection and utilization of available parking spaces, various approaches have been found in the literature. Sensor-based techniques such as ultrasonic sensors [25], magnetic sensors [26], or a combination of two sensors [27] helped in getting information about the vacant parking slot. These techniques had the major drawbacks of additional costs incurred in installing, maintaining, and purchasing sensors. To overcome these drawbacks, computer vision-based deep learning techniques were utilized for parking slot occupancy detection.

2.2.1. Feature Extraction Methods in Classification of Free Parking Space

Feature-based parking space classification utilizes the information about the occupancy of parking areas extracted from the images captured by cameras placed at certain viewpoints in parking areas.

Table 2. Comparison of feature extraction methods in parking space classification.

Author	Feature Extraction Method	Classifier	Accuracy	Dataset
Almeida et al. (2015) [21]	LBP/LPQ	Ensembles of SVM	99.3–99.6%	PkLot
Baroffioet at al. (2015) [29]	HSV histogram	SVM	87.0–96.0%	PkLot
Suwignyo et al. (2018) [30]	QLRBP	K-NN/SVM	92.2–99.4%	PkLot
Bohush et al. (2018) [31]	HOG	SVM	99.7%	PkLot (Subset)
Hammoudi, Melkemi et al. (2018) [32]	LBP-based features	K-NN	88.65%	PkLot (Subset)
Hammoudi et al. (2019) [33]	LBP-based features	K-NN	85.6%	PkLot, CNRPark-Ext (Subset)
Varghese and Sreelekha (2020) [34]	SURF	SVM	91.1–99.7%	PkLot, CNRPark-Ext
Mago and Kumar (2020) [28]	Texture and color features	Neural networks, K-NN, SVM, Naive Bayes	99.7%	PkLot

summarizes some of the feature-based techniques in the literature. The techniques used for feature extraction are Local Binary Pattern (LBP)/Local Phase Quantization (LPQ), Hue Saturation and Value (HSV) histogram, Quaternionic Local Ranking Binary Pattern (QLRBP), Histograms of Oriented Gradients (HOG), Speeded Up Robust Features (SURF). The different classifiers used for the study consist of Support Vector Machines (SVM), K-Nearest Neighbor (K-NN), Neural Networks, and Naive Bayes. From Table 2, it is understood that Mago and Kumar (2020) [28] have proposed the best feature-based parking space classification on the PKLot dataset with an accuracy of 99.70%.

2.2.2. Learning Models Used in Parking Space Classification

Amato et al. (2016) [22] tested CNRPark-EXT and PKLot on mini AlexNet and Mini LeNet based on LeNet-5. Amato et al. (2017) [23] proposed a mini AlexNet based on AlexNet for detecting parking lot occupancy in a decentralized way. Valipour et al. (2016) [35] proposed VGGNet-F for parking lot detection and got an accuracy in the range 99.6–100%. Understanding the demand and characteristics of parking systems in urban areas [36], Jensen et al. (2017) [37] proposed a custom CNN for parking lot detection and got an accuracy in the range of 99.7–99.9%. From

Table 3. Comparison of deep learning-based methods for parking space classification.

Author	Network	Dataset	Accuracy	Change in Camera Angle (Yes/No)	Change in Parking Lot (Yes/No)
Amato et al. (2016) [22]	mAlexNet	PkLot, CNR Park-Ext	89.8–99%	Yes	Yes
Valipour at al. (2016) [35]	VGGNet-F	PkLot	99.6–100%	Yes	Yes
Amato et al. (2017) [23]	mAlextNet	PkLot, CNR Park-Ext	90.1–98.1%	Yes	Yes
Jensen et al. (2017) [37]	custom CNN	PkLot	99.7–99.9%	Yes	Yes
Zang et al. (2019) [38]	custom VGG16 and custom CNN	PkLot, CNR Park-Ext	99.1–99.9%	No	No
Ding and Yang (2019) [39]	YoloV3	PkLot	93.3%	No	No
Chen et al. (2020) [40]	YoloV3	CNR Park-Ext	99.9%	No	No
Dhuri et al. (2021) [41]	VGG16	PkLot, CNR Park	95.7%	Yes	Yes
Nguyen et al. (2021) [42]	mAlexNet, AlexNet and MobileNet	CNR Park	95.5–97.3%	No	No

, the deep learning-based parking space classification is best provided by the method proposed by Zang et al. (2019) [38] for a combination of both PKLot and CNR Park-Ext datasets.

Unger C (2014) [43] proposed a dense motion-stereo utilizing disparity maps-based parking assistance. This method is affected by the shearing effects caused by rolling shutter cameras and the misalignment of interlaced cameras. Bura et al. (2018) [44] proposed a license plate number-based smart parking solution using a network of distributed cameras connected using a self-deployed Wi-Fi mesh.

Camero et al. (2018) [20] proposed a genetic algorithm-based Recurrent Neural Network (RNN) architecture optimizer and self-adjusted (1 + 1) ES-based RNN architecture optimizer for finding the best RNN architecture that can be used for car park occupancy prediction in smart cities. Purahoo et al. (2019) [45] proposed a UAV-assisted quick and efficient monitoring solution for real-time parking occupancy and car number plate detection. Table 3 compares some of the deep learning-based methods for parking space classification. For better mobility and transportation in smart cities, parking identification and prediction systems involve route planning and management of parking space.

Concerning this, Hassija et al. (2020) [46] proposed a distributed parking slot allocation framework based on an adaptive pricing algorithm and virtual voting. This approach provides a fair, fast, and cost-optimal parking slot allocation method. The perfect ordering of allocation requests is also maintained based on consensus timestamp.

Barriga et al. (2020) [47] proposed a handy and adaptable smart parking solution for mobile and web applications based on Long-Range Wide Area Network (LoRaWAN) sensors and a cluster of Kubernetes. Chand and Karthikeyan (2021) [48] presented a novel framework based on real-time monitoring and image recognition techniques. This approach provides hybrid feature extraction (local binary pattern) and pattern recognition (Bayes classifier) for preprocessing input images, followed by an image recognition technique to track the availability of parking spaces in any weather condition.

Balfaqih et al. (2021) [49] proposed a multi-layer IoT architecture-based smart parking system. The proposed work makes use of a parking-spot selection algorithm to manage the allocation and de-allocation of parking areas to the consumer. To improve revenue generation from parking spaces, a hybrid pricing algorithm is proposed. Manjula et al. (2022) [50] proposed a smart parking application based on Mask R-CNN for vacant parking space detection. It is integrated with IoT to capture live data from parking areas.

2.3. Sensor-Based Parking Management System

The work [51] presents an IOT sensor-based parking slot availability detection model that communicates the availability of the parking slot to the user with the IOT network. Although the work presents a cost-effective solution to parking management, its centralized architecture does not scale well. Another work [52] proposes the use of a motion sensor and range finder sensor for the dynamic allocation of the parking slot to the vehicle based on the car number plate reader. However, the presented solution cannot help with reservations or booking of the remote parking slot, which is significant before navigating to the appropriate parking slot.

2.4. Quick Response (QR)-Based Vehicular Identity Management

The work [53] proposes the development of a mobile application for capturing the QR code of the vehicle with a simple mobile camera and evaluates its efficacy and cost with integration. Of the image processing and machine learning approaches’ though decentralized computing is leveraged here, the database is centralized in nature. Another work [54] proposes a QR-based vehicle identity management with infrared sensors for parking slot identification. This work also relies on centralized data storage and is challenged by its scalability.

2.5. Blockchain and Smart Contract-Based Vehicle Parking Management

Blockchain is a decentralized ledger that is highly applicable for distributed identity management. A smart contract [55] in blockchain is a digital agreement between two parties for business transactions. The smart contracts in blockchain provide a tamper-proof record of transactions and hence are very applicable in smart parking systems. Smart contracts will allow the recording of all parking transactions and their metering in a trusted manner.

In [56], personal identity information was used to generate the unique identity of vehicles. In [57], smart contract-based vehicle identity management and user access control were carried out and evaluated for performance.

Blockchain platforms are of two main types: public and private [58]. However, for business applications like smart parking, we will prefer permissioned blockchain deployment, where role-specified access can be conferred to users, and certification-based vehicle registration can be performed with permissions. The three important business use cases for the parking management system have been independently discussed in the literature works earlier. Vehicle registration and identification with the blockchain-based smart parking system allows for secure and tamper-proof registration of vehicles, generating unique identities for each vehicle, as discussed in [59].

Parking payment and parking reservation enable automatic and secure payment for parking spaces using blockchain technology. This blockchain-based smart parking system aims to provide secure vehicle registration and identification, as well as automated and secure payment for parking spaces, as proposed in [60].

The blockchain-based smart parking system can also generate parking tickets securely and transparently, eliminating the need for physical tickets and reducing the risk of fraud or misuse, as put forth in [61].

For existing solutions in vehicular identity management systems, most of the vehicle identity management systems like [62] have been proposed with cloud infrastructure, which lacks the trust and transparency that blockchain-based systems promise. The identity management systems proposed are mostly heavy in terms of personal identity information, as in [63], and do not guarantee the dynamics required for smart parking in terms of driver and traffic change. As per the Government of India’s Smart India initiative [64], there is a need to implement a smart parking system that can provide a hassle-free smart parking system that will make it easy for citizens to easily find and reserve the nearest parking space to their destination.

2.6. Performance Metrics Used for Evaluation of Parking System in the Literature

Performance metrics are categorized in two ways:

• Deep learning-based accuracy metrics;
• Blockchain and smart contract-based parking ticket transactions.

2.6.1. Deep Learning-Based Accuracy Metrics

Different performance metrics used to measure the prediction and identification of free parking spaces are discussed below:

• Accuracy

$$Accuracy={\displaystyle \frac{n_p}{n_s}}$$

(1)

where $n_p$ represents the total number of correct predicted values and $n_s$ represents the total.

• Precision

$$Precision={\displaystyle \frac{T_p}{T_p+F_p}}$$

(2)

where $T_p$ represents the number of the positive values and $F_p$ represents the number of false positive values.

• Recall

$$Recall={\displaystyle \frac{T_p}{T_p+F_n}}$$

(3)

where $F_n$ represents the number of false negative values.

• Box-Loss

Object detection utilizes “box_loss” as a loss function. One commonly used box-loss in object detection is the smooth L1 loss (also known as the Huber loss). It is used to compute the difference between the predicted bounding box coordinates (such as the x, y coordinates of the box’s center, width, and height) and the corresponding ground truth box coordinates. The smooth L1 loss is particularly effective in handling small localization errors without being too sensitive to outliers.

• Object-Loss

The “obj_loss” primarily focuses on the localization aspect of object detection, aiming to minimize the error in predicting the bounding box coordinates. It encourages the model to predict the position and size of the objects accurately. One commonly used object-loss is the smooth L1 loss (or Huber loss) applied to the predicted bounding box coordinates. The smooth L1 loss helps mitigate the effect of outliers and is less sensitive to small localization errors.

• Class-Loss

Class-loss in vacant car parking detection serves to distinguish between occupied and unoccupied parking spaces by evaluating the confidence in the classification of each space, aiding in accurately identifying and monitoring vacant spots for efficient parking management systems.

The “cls_loss” quantifies how well the predicted probabilities align with the true labels.

• Mean Average Precision

In object detection, Mean Average Precision (mAP) measures the performance of a model in terms of both object localization and classification accuracy. It considers the precision and recall at various confidence thresholds and computes an average precision value.

2.6.2. Blockchain and Smart Contract-Based Performance Metrics

• Query response time in milliseconds

Query response time calculates the response time required for vehicle registration and vehicle parking transactions in our system. Lower response time will result in better throughput, especially during heavy traffic.

• Throughput (T)

Throughput (T) is the number of transactions completed per unit of time. It is cumulative time for on-chain consensus time and off-chain data upload time.

• Gas Cost (G)

The gas cost (G) on the transaction is a significant metric with blockchain-based implementation used to decide the efficiency of the smart contract. Gas cost is a transaction processing cost that is incurred with public blockchains but is also very relevant in permissioned blockchains with multiple participants.

3. Research Gaps

A detailed study of the literature on the existing smart parking solutions shows the presence of few significant gaps. The existing systems lacked several factors, such as the following:

• The works [47,48,49] only detect parking slots in a single parking area and do not consider the available parking slots in nearby parking areas;
• A lack of routing algorithm was provided to the driver to the allocated parking slot in the nearest parking area. There exists a need for guiding maps to the newest parking lot;
• The computer vision models based on deep learning models do not perform well with different conditions like shadows, rains, night times, occlusions, varied parking slot sizes, and abnormal parking behavior;
• There does not exist a decentralized vehicle identity management system that can offer economic solutions over centralized cloud-based solutions;
• Lack of integrated solution for vehicular identity management with efficient and cost-effective automated, non-human-mediated, and trusted parking metering and park ticketing systems;
• For existing solutions in vehicular identity management systems, most of the vehicle identity management systems have been proposed with cloud infrastructure [62], which lack the trust and transparency that blockchain-based systems promise;
• The identity management systems [63] proposed are mostly heavier in terms of personal identity information and do not guarantee the dynamics required for smart parking in terms of driver and traffic change.

4. Proposed Framework

The PARKTag system is an integration of the following systems:

▪

Smart Park Slot Detector: This is a deep learning-based parking slot detector based on computer vision-based techniques;

▪

Smart Park Router: This module routes the driver to the nearest free parking slot that is detected by the Smart Park Slot Detector. It is a system integrated with Google Maps for detecting the parking lot as the destination;

▪

Smart Park Tag: This module has a QR-based reader available at the registered parking area that is used for vehicular identity management. It is deployed on the decentralized ledger-based blockchain application;

▪

Smart Park Ticketer: This module is based on the decentralized ledger and a smart contract that automatically generates a parking ticket for the registered vehicles at the parking lot.

Figure 1 shows the overall framework of the intelligent parking system. The system has been integrated into the web and mobile applications. Users must verify themselves by registering on the website/app. All the user information (Name, mobile number, vehicle number, etc.) is embedded into a unique QR code. The parking lots must be registered with the application, and they are equipped with a 4mp Extended Infrared (EXIR) Varifocal (VF) Bullet camera and a 4mp Internet Protocol (IP) Bullet camera. Following that, the user’s current position is retrieved using the MapBox API, and nearby parking lots within a 5 km radius are shown on the map. The user then chooses the parking lot of their preference.

A registered vehicle will bear a visually clear Smart Park Tag code on the front windshield that will be automatically captured by the QR readers at the parking lots. Additionally, the application also requires location sharing with the Smart Park router module, which navigates the vehicle to the nearest parking lot. The QR reader logs the entry of the vehicle in a parking lot with the details on the slot number, lot number, time of the parking, etc., for the calculation of parking charges by Smart Park Ticketer. The Smart Park Slot Detector module, with its hardware-enabled computer vision module, updates the free slot status for the respective parking lot.

Figure 2 shows the detailed architecture diagram of PARKTag. The architecture shows the various components and devices deployed within the network with their connections and functionality. Following is the layered architecture of PARKTag:

1.

On-field Cameras: The parking lots are divided into demarked parking slots. They are equipped with a 4mp Extended Infrared (EXIR) Varifocal (VF) Bullet camera and a 4mp Internet Protocol (IP) Bullet camera. These devices capture the videos on the field, which are pre-processed into a series of images and sent to the pre-trained deep learning model;

2.

QR Scanner: The module comprises a Raspberry Pi, an LCD screen, and a camera, all working in perfect synergy. When a user scans the QR code using the module, it establishes a direct communication channel with the blockchain nodes, enabling real-time data exchange for parking slot allocation and de-allocation;

3.

Blockchain Node: The local blockchain node is interfaced with the QR scanner, and it is connected to the blockchain network. It is this peer that calls the appropriate smart contract on the blockchain network for parking allocation and de-allocation;

4.

Pre-Trained DL model: This is the pre-trained computer vision model that implements the deep learning-based image classification algorithm for the classification of the parking slot in a parking lot as full (F) or vacant (V);

5.

Database Aggregator: This node aggregates the status of the parking slots at all local lots and prepares an aggregated status table.

Full Blockchain Node: It stores the status of the parking lots on the ledger of the blockchain. The ledger could also be implemented as an off-chain database for better scalability in the future;

6.

The Router Module: It reads the parking status data from the database aggregator on client request and suggests appropriate parking lots depending on their locations and relative distance of the parking lot. It is interfaced with Google Maps for getting the appropriate location of the vehicle. The user’s current position is retrieved using the MapBox API, and nearby parking lots within a 5 km radius are shown on the map;

7.

The Client API: The client is connected to PARKTag with the client interface on a mobile application for three services: 1. vehicle registration, 2. parking slot search, and 3. parking ticket generation.

In the next sections, we will elaborate on the workings of the components with the experimentation details.

4.1. Dataset

Deep learning solutions heavily rely on the training dataset. For PARKTag, there is a need for a strong dataset that covers multiple angles to create a deep learning model for such a use case. There is a requirement for a large number of images for training deep learning-based models. The accuracy of the trained model is directly impacted by the richness of a dataset. To train the proposed parking management model, the PKLot dataset [65] was chosen.

PKLot dataset contains a total of 12,416 images and has marked 695,899 parking spaces. Out of 12,416 images, 8691 images are used for training, 2483 images are used for validation, and 1242 images are utilized as testing images. The images in the dataset were taken from two distinct parking lots and three different camera angles. Figure 3 depicts sample images from the PKLot dataset.

The customized dataset that was collected and curated for PARKTag comprises images of various parking lots, including perpendicular parking lots and angled parking lots. Images are captured from various angles, such as the top view of the parking lot and an elevated view. The significance of the dataset is that the images were taken in a variety of weather conditions, including sunny, cloudy, and rainy. The proposed work utilizes a custom dataset. Figure 4 shows a custom dataset captured using a 4mp Extended Infrared (EXIR) Varifocal (VF) Bullet camera and a 4mp Internet Protocol (IP) Bullet camera.

This customized dataset has 2290 images, of which 1814 images are utilized for training and the rest of the images are used for validation. These images were taken at MIT ADT University, Loni Kalbhor, from two different parking places from varied camera angles, including an elevated viewpoint and a top view of parking lots. The latitude and longitude details of the university are (18.561656, 73.965385).

Different types of camera positioning approaches ensure the dataset’s resilience and provide the opportunity to apply transfer learning to the model that was previously trained using the PKLot dataset. Images captured in a variety of weather conditions, including cloudy, rainy, and sunny, are included in the dataset. We included two cameras installed at each one of the parking lots to cover the entire parking area from more angles. The occlusion issues with the images were thus resolved, as shown in Figure 5. The cameras captured 2290 images per second. The Smart Park Tag dataset comprises 764 daytime, 763 nighttime images, and 762 images in cloudy, sunny, and rainy conditions to cover the climatic diversities in real time.

4.1.1. Dataset Preprocessing

The images for the custom MIT University dataset are captured from two locations. At parking site 1, Internet Protocol (IP) cameras are used to capture the dataset with a 40-degree field of view. At parking site 2, a 4mpIP Varifocal Camera has been used since the camera is placed on the fifth floor of a building. The recorded videos are accessed via the Network Video Recorder (NVR) and are stored on a local system.

These parking videos are converted to images through the following process:

▪

Using OpenCV, the frames of the video are read one by one. There are two frames that are stored, namely check frame and current frame;

▪

A comparison is made between the two frames using Mean Square Error (MSE) and Structural Similarity Index (SSIM) values between the two frames. MSE is used to calculate the overall difference in the images. This change may occur due to a new vehicle in the parking lot, weather, or reflections on the windows of vehicles. SSIM is generally used for Image Quality Assessment [66] of the same image before and after applying augmentations. Here, two images of the same area will have a high SSIM if there are no new vehicles or environmental changes in them. Using this analogy, the difference calculated in the images is checked if it is spread out in the image or if it is confined to a small area. Suppose the difference is due to small differences spread out in the entire image, e.g., shadows of objects on a sunny day. If the difference is confined to a small area, it may suggest a new vehicle in the parking lot. If the two frames are compared and they are found to be the same, then the current frame is replaced by the next frame of the video. If there is a difference between the two images, then the check frame is stored and replaced by the current frame, and the next frame is read into the current frame;

▪

This method is applied to generate a dataset that is unique and robust. This is essential since we have a dataset of parking lots with rough Indian terrain and dusty appearance. The demarcations are marked using White Thermoplastics Road Marking Powder;

▪

Once the frames are captured, they are given a unique name based on the following:

• Parking lot whose image is captured;
• Camera through which they were captured;
• Date, time of capture;
• Frame number of the image from the video.

▪

The images are labeled using the software “SuperAnnotate 1.1.0”. By default, it stores the annotations of the images in. json format. These labels are converted to the specific label format (.txt or. json), with crucial information such as x and y coordinates and the class of the bounding boxes of the image;

▪

The collected image dataset is stored on-premise local storage for privacy and security concerns. The images will undergo image processing techniques, especially face obscuring, access controls on attributes like masking car plates, hiding date and time, etc., before migrating to the public domain;

▪

Once the images and labels are generated, they are passed through a File Check code, which checks for missing images or labels. The output of this code is image-label pairs without any missing files;

▪

These images and labels are then shuffled and passed through a train–test–val split. In this way, the MITADT University dataset has been generated.

For detection in real time, the live video feed of the cameras is accessed via the Real-Time Streaming Protocol (RTSP) link [2]. It establishes and controls real-time synchronous streaming of single or multiple continuous media.

4.1.2. Data Augmentation

To increase the number of training samples, data augmentation is utilized, as shown in Figure 5. Every time a new training batch is created, YOLOv5 passes the training data through a data loader, which augments data online. Three different augmentations are made by the data loader, such as scaling, color space adjustments, and mosaic augmentation.

The most innovative of them is mosaic data augmentation, which turns four images into four random-ratio tiles. The mosaic data loader is available in the YOLOv3 PyTorch and YOLOv5 repo. For the well-known COCO object identification benchmark, mosaic augmentation is enormously beneficial as it teaches the model how to deal with the well-known “small object problem”, which is the issue that small objects are not as effectively detected as larger ones. Customized series of data augmentation can improve the performance of object detection models like YOLOv5.

4.2. Vehicle Routing Algorithm

Once the user selects the parking area, he is allocated a parking slot in that parking area. A routing algorithm (Algorithm 1) is designed to assist the user to the assigned parking slot in the selected parking area. First, information regarding parking lots is collected in terms of their name, availability, and coordinates.

Algorithm 1. Algorithm to navigate to destination to nearest slot with shortest route.

Require: Source, Destination Step 1: Use Google Maps API to get multiple routes from Source to Destination Step 2: Initialize variables to store information about the best parking spot Step 3: for Each route in routes to find the best parking spot do  Step 3.1: Initialize variables to store information about the shortest path  Step 3.2:   for Each route in routes to find the shortest path do    Step 3.21: Get distance and estimated time for the current route    Step 3.22: Consider traffic conditions and update estimated time if needed    Step 3.23: Check if the current route is shorter than the previous shortest path   end for end for Step 4: Get the parking areas near the destination for the shortest Path Step 5: Iterate through each parking area to find available slots for each parking Area in parking areas Step 6: Check if there are vacant slots and calculate time to reach the parking area Step 7: Update the best parking spot if the time is shorter Step 8: Provide navigation instructions to the user Step 9: Update the mobile application with parking information

The algorithm is designed to find the optimal parking spot for a user traveling from a source location to a destination. It utilizes the Google Maps API to obtain multiple routes between the source and destination. The algorithm then iterates through each route to determine the shortest path, considering distance, estimated time, and potential updates based on traffic conditions. The traffic issues can be securely addressed by emphasizing vehicle-to-vehicle communication [67].

For each identified shortest path, the algorithm retrieves parking areas near the destination. It further iterates through these parking areas to find available slots, calculating the time required to reach each parking area from the source. The algorithm updates the best parking spot if a shorter time to reach is found.

The algorithm also provides navigation instructions to the user for the optimal parking spot and updates a mobile application with relevant parking information, ensuring a seamless and efficient parking experience. This algorithm considers multiple routes, factors in real-time traffic conditions, and prioritizes the shortest path with available parking for an enhanced user experience. The pseudo-code for the above algorithm is Annexure.

4.3. Smart Contract for Blockchain-Based Vehicle Registration and Parking Ticket Generation

The algorithm (Algorithm 2) outlines the creation of a smart contract for managing vehicle parking and parking ticket generation in a transparent and non-human-mediated manner. The algorithm is used here with standard programming language constructs. The implementation is carried out with the most accepted Solidity [68] programming language.

Algorithm 2. Smart contract algorithm for blockchain-based vehicle registration and parking ticket generation.

Step 1: The contract is initialized with an owner, who is the sender of the deployment transaction. Step 2: Create structure “Vehicle” consisting of attributes registration number, model, owner name, registration timestamp, registration status. Step 3: Create a mapping to store vehicles for each owner, allowing multiple vehicles per owner Step 4: Define a function for registration of the vehicle that allows the owner to register a new vehicle. function REGISTERVEHICLE (registration number, model, owner name)    Assign vehicle registration number    Assign the model    Assign Owner to vehicle    Assign registration timestamp    Mark the vehicle is registered end function Step 5: Declare the event to notify whenever vehicle is registered Step 6: Implement modifiers  6.1. To ensure that only the contract owner can execute functions.   function ONLYOWNER    require (msg. sender == owner, “Not the contract owner”);   end function  6.2. To ensure that parking slots are available   function ENOUGHPARKINGSLOTS    require (availableParkingSlots > 0, “No available parking slots”);  end function  6.3. To ensure owner has registered vehicle before parking   function VEHICLEREGISTERED    require (vehicles [msg. sender]. length > 0, “No vehicles registered for the owner”);   end function Step 7: Functionality for parking the vehicle function PARK-VEHICLE    7.1. Accepts the index of the vehicle to park.    7.2. Check for valid index, sufficient payment for parking fee, and available parking slots.    7.3. Records the parked vehicle index for the owner.    7.4. Reduces available parking slots. end function Step 8: Functionality for de-allocating the parking slot assigned to a vehicle function UNPARK-VEHICLE    8.1. Check if the owner has a vehicle parked.    8.2. Clears the parked vehicle index.    8.3. Increases available parking slots. end function

The contract function is created by an owner who could be the administrator of the application and deployed on the decentralized network of nodes. The structure “Vehicle” is declared with attributes such as registration number, model, owner name, registration timestamp, and registration status. A mapping table or list is defined to relate vehicles to their owner for vehicle ownership management.

A registration function is defined, enabling the owner to register a new vehicle in vehicle identity management. The Smart Park Tag is a code generated with all vehicle and owner details, such as registration number, model, owner, and timestamp, and this marks the vehicle as registered. An event is declared to notify whenever a vehicle is registered.

Solidity function modifiers are implemented to enforce certain conditions of contract in the business logic:

• ONLYOWNER ensures that only the contract owner can execute functions;
• ENOUGHPARKINGSLOTS ensures that there are sufficient (at least 1) available parking slots;
• VEHICLEREGISTERED ensures the owner has registered a vehicle before attempting to park.

The algorithm includes functionality for parking a vehicle, which involves checking for a valid index, sufficient payment for parking, and available parking slots. The parked vehicle index is recorded for the owner, and available parking slots are reduced. For privacy concerns, the registered vehicle identity attributes like owner name and chassis number are not disclosed in the public domain.

Additionally, there is a functionality for de-allocating a parking slot assigned to a vehicle. This involves checking if the owner has a vehicle parked, clearing the parked vehicle index, and increasing available parking slots.

In summary, the algorithm defines a smart contract that facilitates vehicle registration, parking, and de-allocation of parking slots, with specific conditions enforced through modifiers for security and control.

5. Experimentation

5.1. Deep Learning Model

YOLO is a state-of-the-art, real-time object detection algorithm that is pre-trained on the COCO dataset. The image is segmented into sections, and the algorithm predicts probabilities and bounding boxes for each. In the proposed paper, we are using the fifth version of this algorithm called YOLOv5.

YOLOv5 has been widely adopted across numerous applications [69], earning a strong reputation for its efficiency and reliability, particularly in edge deployments crucial for real-time parking space detection and monitoring. At the start of our project, YOLOv5 had already been thoroughly tested and optimized, securing its position as a dependable choice for real-world implementation for lightweight nodes. The choice of YOLOv5 over the advanced YOLOv7 and YOLOv8 was made with the best accuracy results obtained on public datasets like in work [70]. This was also preferred because of the extensive developer support in YOLOv5.

A pre-trained network serves as the backbone and is used to extract rich feature representation for images. This aids in lowering the image’s spatial resolution and improving its feature (channel) resolution. Pyramidal feature extraction is performed using the model neck. The backbone of the model (0–10 layers) is frozen for transfer learning on the custom data. On the custom dataset, the neck and head are trained. The number of classes is reduced from 80 to 2 in the output layer (space-occupied, space-vacant).

5.2. Hyper Parameter Tuning of the Model

The model chosen is YOLOv5. It is pre-trained on the PKLot dataset before being trained on the MITADT University dataset using transfer learning. The metrics chosen for hyperparameter tuning are optimizer, learning rate, and number of epochs. Stochastic Gradient Descent (SGD), Adam optimizer, and AdamW optimizer are chosen as optimizers. The learning rate is set to (0.0075, 0.01, 0.015, 0.02), while the number of epochs is set to 15, 20, 25.

AdamW frequently resulted in fewer training losses and test errors. The outcomes for our novel Adam variant with decoupled weight decay (AdamW) AdamW largely decouples weight decay and learning rate. The results for the best hyperparameter settings were comparable to those of SGD and SGDW and significantly better than the best results of Adam with L2 regularization. These factors led to the selection of the mentioned three optimizers. These optimizers were demonstrated to be the best fit for the current situation because the training dataset for the model is unique and challenging to learn.

The hyperparameter tuning for the YOLOv5 model is displayed in

Table 4. Hyperparameter tuning for YOLOv5.

Performance Rank	Model Hyper Parameters		Performance Metrics
Optimizer	Learning Rate	Number of Epochs	Precision	Recall	mAP-0.5	mAP- 0.5:0.95	F1 Score
1       SGD	0.0075	25	0.92934	0.87844	0.91756	0.46768	0.90317
2       SGD	0.01	25	0.91278	0.87445	0.91189	0.47234	0.8932
3       SGD	0.0075	20	0.91346	0.86665	0.90485	0.44402	0.88944
4       SGD	0.01	20	0.9153	0.86054	0.89788	0.41598	0.88708
5       SGD	0.015	15	0.84972	0.83879	0.88232	0.42131	0.84422
6       SGD	0.02	15	0.86019	0.82741	0.85781	0.37657	0.84348
7       SGD	0.01	15	0.81191	0.81493	0.8357	0.36711	0.81342
8        Adam	0.01	20	0.78585	0.76478	0.78576	0.33361	0.77517
9       AdamW	0.01	15	0.49354	0.67132	0.59449	0.23207	0.56886
10          Adam	0.01	15	0.46902	0.63872	0.54164	0.21397	0.54087

. The model hyperparameters are selected based on performance measures like Mean Average Precision and F1 Score.

Following the effective application of the modifications, the optimizer SGD with a learning rate of 0.0075 and training over 25 iterations generates the best performance on the MITADT dataset. In terms of performance metrics, the results are as follows: precision, recall, mAP 0.5, mAP 0.5:0.95, val/box-loss, val/obj-loss, val/cls-loss, x/lr0, x/lr1, x/lr2, and train/obj-loss, train/cls-loss, train/obj-loss, and train/cls-loss.

5.3. Smart PARKTag QR Module for Vehicle Registration and Identification

This module focuses on a QR module specifically designed for a parking lot management application. This innovative QR module, as shown in Figure 6, serves as a crucial component for the allocation and de-allocation of parking spaces, providing seamless user experiences. The module comprises a Raspberry Pi, an LCD screen, and a camera, all working in perfect synergy. When a user scans the QR code using the module, it establishes a direct communication channel with the backend server, enabling real-time data exchange for parking slot allocation and de-allocation. To ensure optimal functionality, two QR modules are implemented within a given parking area: one dedicated to parking allocation and the other to parking de-allocation.

This division streamlines the process and enhances overall efficiency. With this system in place, users simply need to scan the QR code generated by the application, and the module swiftly transmits the necessary data to the backend server, promptly assigning a parking space to the user. Through the seamless integration of hardware and software, this QR module significantly simplifies parking management and contributes to a smoother overall parking experience.

5.4. Smart Park Blockchain and Smart Contract Configuration

We have deployed smart contracts to observe their performance for vehicle registration and parking. We have deployed smart contracts on the Sepolia test network [71] using Truffle v5.11.5 (core: 5.11.5) [72] along with MetaMask wallet 11.11.4 [73]. The user interface has been written in Hyper Text Markup Language (HTML) and collaborated with node JavaScript web3.js V1.10.0 [74]. Node version was V18.15.0. The user interface was provided through the Google Chrome browser with version 122.0.6261.112. We have used visual studio 1.85.2 as an editor for HTML and JavaScript. This deployment was performed on Windows 11 Education 64-bit operating system, 7.6 GB RAM, Intel processor (i5–8500 CPU @ 3.00 GHz).

6. Results

In this section, the performance of the Smart Park Slot Detector and decentralized application for PARKTag ticket generation with vehicular identity management is carried out.

6.1. Performance Evaluation of Smart Parklot Detector

To evaluate the performance of a classification model, a Confusion Matrix, also known as an Error Matrix, is used. It allows us to visualize the model’s performance by comparing the predicted labels with the actual labels. From

Table 5. Confusion Matrix for the accuracy in the classification of free vs. occupied slot.

Confusion Matrix
	Space-Empty	Predicted Space-Occupied	Background FN
Space-Empty	0.84		0.61
Predicted Space-Occupied		0.98	0.39
Background FN	0.16	0.02

, space-occupied and space-vacant have True Positive (TP) of 98% and 84%, respectively. This provides useful information on the model’s robustness on the custom dataset.

The graphical representation of the precision–confidence curve (PCC) shows the relationship between the precision of a classification model and the confidence of its predictions. Figure 7 shows that the precision of the space-empty class is lower than that of the space-occupied class. The precision–recall curve is a graphical representation that illustrates the trade-off between precision and recall for a binary classification model. It shows how the model’s performance varies as the classification threshold changes.

The space-empty class has a significant impact on the model’s overall performance, as seen in Figure 8. The prediction is 98% accurate for the space-occupied class. The best recall is obtained at a confidence of 0.45. After that, the recall effectiveness drops with increasing confidence in prediction. Figure 9 represents the performance of YOLOv5 on the SmartParkTag dataset for Stochastic Gradient Descent (SGD) for a learning rate of 0.075 and 25 epochs. The train loss function of the bounding boxes, the confidence that an object is present, and the predicted classes all drastically decrease in the model.

The reduced loss explains the model’s improved recall and precision. The following

Table 6. Changes observed between Epoch 0 and Epoch 25.

	Train Loss			Metrics				Validation Loss
epochs	box_loss	obj_loss	cls_loss	precision	recall	map_0.5	map_0.5:0.95	box_loss	obj_loss	cls_loss
0–5	0.0176↓	0.0521↓	0.00250↓	0.2893↑	0.2429↑	0.34564↑	0.15904↑	0.00819↓	0.01255↓	0.00022↓
5–10	0.0061↓	0.0082↓	0.00020↓	0.1464↑	0.1504↑	0.17009↑	0.07342↑	0.00261↓	0.01475↓	0.00049↓
10–15	0.0048↓	0.0076↓	0.00067↓	0.0021↑	0.0697↑	0.06319↑	0.04181↑	0.00203↓	0.00947↓	0.00115↓
15–20	0.0031↓	0.0030↓	0.00016↓	0.0827↑	0.0131↑	0.03506↑	0.04131↑	0.00118↓	0.00143↓	0.00016↓
20–25	0.0036↓	0.0033↓	0.00017↓	0.0672↑	0.0592↑	0.04878↑	0.06955↑	0.00279↓	0.00173↓	0.00011↓
0–25	0.0351↓	0.0742↓	0.00370↓	0.5877↑	0.5352↑	0.66276↑	0.38513↑	0.01681↓	0.03995↓	0.00115↓

and

Table 7. Percentage changes observed between Epoch 0 and Epoch 25.

	Train Loss			Metrics				Validation Loss
epochs	box_loss	obj_loss	cls_loss	precision	recall	map_0.5	map_0.5:0.95	box_loss	obj_loss	cls_loss
0–5	28.81%↓	42.3%↓	58.64%↓	84.68%↑	70.77%↑	135.70%↑	192.70%↑	20.170%↓	13.680%↓	11.560%↓
5–10	14.78%↓	12.09%↓	14.18%↓	30.27%↑	27.18%↑	31.430%↑	40.620%↑	07.800%↓	18.730%↓	28.980%↓
10–15	13.03%↓	12.49%↓	44.04%↓	00.30%↑	09.58%↑	09.37%↑	17.600%↑	06.740%↓	14.950%↓	83.640%↓
15–20	09.98%↓	05.51%↓	16.55%↓	09.94%↑	01.60%↑	04.02%↑	10.300%↑	04.560%↓	02.700%↓	16.960%↓
20–25	11.98%↓	06.43%↓	24.06%↓	07.33%↑	07.03%↑	05.40%↑	17.540%↑	10.300%↓	03.150%↓	13.870%↓
0–25	57.46%↓	60.25%↓	86.79%↓	172.0%↑	155.90%↑	260.10%↑	466.50%↑	41.410%↓	43.510%↓	60.340%↓

have been noticed between Epoch 0 and Epoch 25 with ↓ represents decreasing value as the epochs increases and ↑ represents increasing value as the epoch increases

The presented Smart Parklot Detector is trained on a customized MIT-ADTU image dataset along with pre-training performed on the PKLot [21] dataset. This dataset has images of multiple parking lots with different camera angles and weather conditions collected in real time to improve the variability of the dataset. The existing works in [22,23,35,37,38] present an evaluation of different learning networks that show good accuracy with the PKLot dataset up to 93% accuracy. However, they lack the generality of the datasets. Parklot Detector is more diverse for the parking lot images, which are collected in real time with a comparable accuracy of 92%. This makes this framework more promising in real-world scenarios. The recent works, as presented in [70], also support the choice of the YOLOV5 networks for better image recognition use cases.

6.2. Performance Evaluation of Smart PARKTag

We have considered the use case of MIT ADT University, Pune. We have collected the dataset of the registered vehicles on the campus. As per our dataset, there were a total of 2514 two-wheelers, 42 three-wheelers, 652 four-wheelers (cars), and 142 four-wheelers (buses), as shown in Figure 10. Figure 11 represents the per-day usage of vehicles. We have considered these vehicles for our project. For privacy concerns, the registered vehicle identity attributes like owner name and chassis number are not disclosed in the public domain.

We compared the performance of the decentralized PARKTag deployed on the blockchain network with the application deployed on the Amazon cloud services [75]. We selected AWS cloud service, which is the most prominent and top cloud service provider in the industry [75]. In blockchain-based applications, gas consumption varies with every execution of transactions because of the factors of network congestion, effort in mining, etc. Hence, with the principle of replication, every experiment is repeated with the same experimental conditions 10 times on the Ethereum Sepolia test network. We have compared the execution with SmartParkTag deployed on the centralized Amazon Dynamodb database service [75] for the registration and parking transactions in the cloud environment.

AWS guarantees higher availability of the resources; hence, results do not show significant variation in transaction response time for cloud-based deployment in 10 Asia AWS regions. Although read costs were invariable in deployment across any cloud region, we observed variations in the write cost as per the different data center regions. Figure 12 shows a comparison of blockchain transactions with AWS transactions with respect to write costs in different Asia regions.

To calculate the cost of the cloud-based transactions, we used the AWS calculator [76]. We used the DynamoDB provisioned capacity feature and standards table class, and the average item size was set to 129 bytes, which were kept similar to compare the cost of blockchain-based applications.

Write settings of the workload were set as follows:

• Percentage of non-transactional writes: 100;
• Percentage of transactional writes: 0;
• Baseline write rate: 2 per second;
• Peak write rate: 2 per second;
• Duration of peak write activity: 72 h per month;
• Percentage of baseline writes covered by reserved capacity: 100%;
• Write reserved capacity term: 1 year.

We have the price in USD. As the price is to be compared with the gas fee of the blockchain, we converted the USD in gas fee in Wei [77] with the following steps:

• Monthly write cost: 10.66 USD;
• Conversion of USD to INR: 10.66 USD 883.83;
• Per-day conversion 883.83/31 28.51;
• INR to Ether: 0.00011 Ether;
• Ether to Wei: 110,000,000,000,000 Wei.

The same procedure was observed for other regions as well. These values are plotted in Figure 12. With the same processing, we have also calculated the read cost of transactions executed in all the Asia regions. As there is no read cost for the blockchain, it is set to 0, as shown in Figure 13. There is a significant cost for the read operations in the AWS. Though the cost of read/write on Ethereum is much cheaper than the AWS DynamoDB, the throughput of read/write transactions is much higher in the AWS because of the high availability of resources. We can reach up to 100 read/write transactions per second in the AWS DynamoDB. We calculated the throughput of write transactions in Figure 14 and read transactions in Figure 15.

We collected information on the number of day-wise vehicles coming into the campus. We can observe that in Figure 11, there are much fewer vehicles on Saturday and Sunday, which is the weekend. So, the observation is that the read/write cost of the Ethereum is much less on Saturday and Sunday or on public holidays, or during academic breaks. The cost of application deployment is minimal during that period. However, with a cloud-based application like AWS DynamoDB, the cost will continue to remain persistent even during the slack period as there is a constant upfront cost for the AWS services. The decentralized blockchain-based solution is cost-effective.

Secondly, the privacy of the vehicular data is on the distributed ledger, which is managed by a few private miners as this is an Enterprise application. This is more privacy-preserving than a third-party administered cloud-based solution to parking management. This is also more attack-resilient than a cloud-based solution.

Thirdly, scaling this solution to a smart city initiative implies a system that is trustworthy and transparent. It could also be regulated by appropriate government bodies that will be participating in the system and monitoring all the operations for compliance. Hence, the blockchain-based PARKTag deployed at the university campus paves the way to an efficient, trustworthy, and non-mediated parking management system for any smart city.

6.3. User Validation

User validation means evaluating the system by the end user. To understand the user acceptance of the system, a survey was carried out with 100 participants at the university campus. These 100 participants were from diverse user groups. Out of the 100 participants, 60 were faculty, 25 were student members, and 15 were regular visitors and vendors.

The following questions were asked before using the app:

1.

Question: How often do you use commute?

Answer Alternatives: Once a day, several times a day, once a week.

2.

Question: How often do you get parking space near your destination?

Answer Alternatives: Always, usually, sometimes, never

3.

Question: Would you like to use a smartphone app that gives you information regarding the free parking spaces near destination?

Answer Alternatives: yes or no

4.

Question: Would you like the smartphone app to block the parking space prior reaching destination and provide you with the route to the allocated parking space?

Answer Alternatives: yes or no

Figure 16 represents the statistics of the number of users who commute daily, several times a day, or once a week. It was found that 50 faculty members commute to the university daily. Additionally, 18 out of 25 students also commute daily due to the hybrid class mode. Furthermore, 6 out of 15 visitors, specifically start-up research collaborators, visit the university once a day. Nine visitors visit the university once a week for academic and professional-related work. Figure 17 represents the statistics of the number of users who obtain parking space near their destination. It was observed that 8 faculty members consistently secured their desired parking spaces, while 33 occasionally did, and 12 never managed to do so. According to student feedback, 15 out of 25 sometimes found their preferred parking spaces, but only one always did. Additionally, 7 out of 15 visitors occasionally found their desired parking spaces.

Figure 18 represents the statistics of the number of users interested in using a smartphone app that would provide information regarding the free parking spaces near the destination. A very good positive response from 52 faculty members, 20 students, and 12 visitors was received for the usage of the smartphone application. Figure 19 shows the statistics of users interested in reserving available parking spaces in advance and being guided to them when near their destination. This includes 52 faculty members, 23 students, and 14 visitors.

The following questions were asked after using the app:

1.

Question: After using ParkTag App, how often did you get parking space near your destination?

Answer Alternatives: Always, usually, sometimes, never.

2.

Question: After using ParkTag App, were you able to block the parking space prior reaching your destination.

Answer Alternatives: Always, usually, sometimes, never

3.

Question: After using ParkTag App, were you provided with directions to the allocated parking space near your destination?

Answer Alternatives: yes or no

4.

Question: How many times have you used ParkTag App to search for a suitable parking area?

Answer Alternatives: Once a day, once a week, several times in a day.

5.

Question: Would you recommend another person to use ParkTag App?

Answer Alternatives: yes, maybe yes, no

6.

Question: What was your overall experience while using the ParkTag App?

(a)

Ease of use

(b)

Availability and Accuracy

(c)

Reservation Process

(d)

Notification System

(e)

Reliability

(f)

Battery Usage

(g)

Customer Support

(h)

Data Privacy and Security

7.

Question: Was parking ticket correctly generated?

Answer Alternatives: yes or no

8.

Question: Was your vehicle accurately identified?

Answer Alternatives: yes or no

Figure 20 represents the statistics of the number of users who obtained a parking space near their destination. Figure 21 represents the statistics of the number of users who were able to block the parking space near their destination. Figure 22 presents the statistics on the number of users who were provided with directions to their allocated parking space near their destination. It was found that 51 faculty members, 24 students, and 12 visitors received these directions.

Figure 23 represents the statistics of the number of times users have used the PARKTag app to search for a suitable parking area near their destination. Figure 24 represents the statistics of the number of times users would recommend another person to use the PARKTag app. Figure 25 represents the statistics of the number of times users received parking tickets correctly. It was found that 52 faculty members, 23 students, and eight visitors could receive parking tickets correctly.

Figure 26 represents the statistics of the number of times user’s vehicles are accurately identified. The statistics reveal that out of the 10 questions on the validation of the application by the end-users, 80% of responses are positive. However, there are few responses suggesting improvement in the interfaces and response time during weekdays, which need to be elevated in the new version of the application under progress.

7. Conclusions and Future Work

Smart Parking Managements contribute to the growth of sustainable smart cities. Although many projects have been presented earlier in the smart parking domain, an integrated solution that identifies a parking slot, routes the vehicle to the spot, identifies a vehicle with a unique identifier, and also helps with non-human-mediated and transparent parking ticket generation is needed for urban areas. The work presented here, PARKTag, is the miniature prototype of the entire integrated system, which can be scalable to smart cities.

ParkTag employs computer vision techniques and advancements in deep learning models that have enabled the image-based identification of a free parking slot in all real-world conditions, including weather, angles, variations in parking slots, etc. PARKTag brings the best of the state-of-the-art deep learning models for the effective identification of parking slots. The router module enables hassle-free navigation of the user to the parking slot. PARKTag proposes a unique identification of the registered vehicle, and the smart contract-based Smart Park Ticketer offers transparent, automated parking ticket generation. The efficacy and the user acceptance of the application at the university campus was around 80%. The work presents a comparative analysis of the application deployment on a permissioned blockchain network with public cloud implementations. For the scenario of the university parking management use case at hand, the permissioned blockchain-based implementations look cost lucrative in terms of read, write transactions. For a system with a larger scale, a decentralized architecture will also exhibit more promising features like transparency and trust in the entire parking management application.

The future work of the presented work is the development of a new version of the application that will focus on the enhanced usability of the application with better user acceptance of the interface. Future work will also focus on granting different access privilege levels and priority passes to registered, non-registered, and important users. We also aim to scale this decentralized architecture of a network of nodes that can deploy off-chain distributed ledgers storing higher velocity of parking transactions for better responsiveness and scalability.

Thus, conclusively, our presented framework, experimentations, prototype evaluations, and user validations indicate that PARKTag is a significant contribution to research in addressing parking management issues in smart cities.