Digital Twinning Mechanism and Building Information Modeling for a Smart Parking Management System

Highlights

What are the main findings?

• This study demonstrates a developmental framework for a smart parking management system (SPMS) digital twinning capability through a cross-platform-based digital twinning mechanism using machine vision and building information modeling for the spatial visualization of parking occupancy data within the built environment.
• The digital twin (DT) system streamlines You Only Look Once version 7 (YOLOv7), Object Detection (OD), and Deep Text Scene Text Recognition Inferences (DTR-STR) into a database pipeline, supporting automated vehicle profiling (VP) and data analytics on vehicle activity within the built environment.

What is the implication of the main finding?

• The DT framework explored in this study aligns with existing and emerging smart city trends such as artificially intelligent buildings in integrating building information models (BIMs) with building data, potentially facilitating facility management and data-driven decision-making.
• This study serves as a demonstration of how existing parking infrastructures can receive automation interventions and have their capabilities scaled up for applying BIM-based DT models to broader urban contexts.

Abstract

Parking space shortages are attributed to an increased density of vehicle presence in the urban context, necessitating the implementation of effective parking management strategies, especially in areas where facility expansion is constrained by limited land availability. Many parking facilities remain operationally inefficient and underutilized due to manual VP methods and having little access to parking resource utilization data. This study develops a DT-based SPMS integrating machine vision, data modeling, and DT technology to automate facility management operations. The system uses YOLOv7 for vehicle and License Plate Detection (LPD), and Deep Text Recognition–Scene Text Recognition (DTR-STR) for license plate recognition (LPR). The findings indicate an 89.89% accuracy for VP- and LPR-based occupancy tracking tasks, and 94.86% for vehicle detection or VD-based occupancy tracking. The system in the built environment comprises three features: (1) automated VP at parking entry and exit points, (2) occupancy monitoring through LPR, (3) Object Detection (OD) for occupancy tracking. The 3D BIM DT model in Autodesk Revit processes inference data from machine vision models to visualize parking activity.

1. Introduction

As the global population is expected to exceed 9 billion by 2040, urban infrastructure development should emphasize efficient mobility and transportation [1] in anticipation of the worsening traffic congestion brought about by an increased private vehicle population, urbanization, industrialization, and economic development [2,3]. These problems can only be addressed through joint cooperation between local and national stakeholders through the prompt implementation and integration of relevant technologies aimed at making mass transportation more sustainable and accessible [4,5,6], thereby improving overall mobility efficiency [7]. The structured integration of these tools in the transportation sector is commonly referred to as Intelligent Transportation System (ITS) development [8,9]. ITS tools uses a combination of emerging technologies ranging from information and communications technology (ICT) [10], Internet of Things (IoT) [11,12], and artificial intelligence (AI) [1,13] to address transportation and mobility problems.

In the recent literature, most ITS development initiatives place their focus on traffic control and management applications. Notably, fewer studies have explored the role and impact of ITS infrastructure deployment in parking facilities and parking management contexts [2,14]. Traffic control and management studies have reported that a source of worsening traffic conditions is brought about by limited parking availability in parking facilities. This is especially true in urban areas where drivers continue to cruise in search for available curb-side parking slots, or they occupy public roads, waiting for an opening into a parking facility [15,16]. Moreover, cruising affects the environment through increased CO₂ emissions [17]. As there is a direct linkage between traffic monitoring and parking management to help decongest traffic, this further underscores the need for ITS development and integration into parking management contexts [18]. Parking facility management can be systematically improved through automaton by implementing smart parking management systems (SPMS) capable of real-time VP and activity monitoring within parking facilities [2,19]. While SPMS development studies are available in the literature, few have explored using cyber–physical systems (CPS), particularly DT systems, for automative and monitoring functions.

SPMS implementations such as AI-driven surveillance, LPR, and video footage collection present significant concerns over data collection [20,21]. In contrast to traditional implied data collection consent in retail, which assumes that a user’s presence signifies agreement [22], modern data protection regulations such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) mandate explicit consent for collecting and processing personal data [20,21]. Despite emerging data privacy concerns, SPMS development initiatives continue to persist through struct adherence to transparent data policies, anonymization techniques, and stringent access controls [23]. SPMS frameworks aim to improve operational efficiency while complying with data privacy laws [24,25].

Most CPS research leans towards developing DT models through a BIM framework for parking facilities. Current SPMS-BIM implementations face challenges in delivering an intuitive and encompassing visualization platform that effectively reflects the real-time status of the facility [26]. Conventional monitoring systems depend on surveillance camera networks to provide comprehensive coverage throughout the facility. While camera networks allow managers to monitor vehicle parking activities remotely, it requires manual switching between various camera feeds, rendering the process laborious and inefficient, especially in facilities with extensive camera networks. DT models (2D or 3D) address this challenge by integrating real-time data into a cohesive visualization platform to help improve decision-making capabilities [27].

While 2D models offer an organized framework of understanding, they often oversimplify geometric features. The level of detail is lesser, necessitating relevant personnel to mentally interpret flat and simplified 2D representations [28]. In SPMS contexts, this poses a challenge in effectively evaluating real-time occupancy, vehicle flow, and congestion points, thereby reducing monitoring efficiency. In contrast, 3D DT models closely represent the actual facility layout and provide a more user-friendly and immersive depiction. Three-dimensional models can optimize facility management by combining real-time data streams using machine vision and sensor data. This improves situational awareness and lowers the cognitive burden for facility managers [29,30]. This study focuses on developing an SPMS development framework integrating a 3D BIM interface platform for a 3D spatial understanding of the built environment. The system is a dynamic and interactive 3D BIM DT model sourced from video data streams for improved monitoring.

The primary contribution of this study is creating a dynamic DT interface to demonstrate a proof-of-concept remote parking occupancy monitoring system through a 3D BIM visualization interface. The developed SPMS combines OD, STR, and data processing algorithms to profile vehicles and analyze occupancy statistics from surveillance video footage. A Light Detection and Ranging- or LiDAR-based point cloud model was used to create a 3D Revit model, ensuring an accurate geometric depiction of the parking facility environment. The Dynamo plugin in Autodesk Revit dynamically updates the model by attaching it to the system’s backend, allowing recorded occupancy changes to be visually represented. This study demonstrates a scalable framework for smart infrastructure and how several smart applications can be used to improve facility management operations.

2. Smart Parking Management Systems

The design and implementation of an SPMS attempts to resolve the vehicle congestion issues caused by the inefficiencies of manually operated parking facilities [31]. By integrating advanced technologies, parking processes are optimized to ensure that the timely service of providing parking spaces to vehicles is made more efficient and straightforward [32]. SPMS facilities provide occupancy statistics on mobile applications, online digital viewing platforms, or public displays, thereby improving the user experience of drivers in search for parking spaces. The commuting public can access the data remotely, navigate the parking area or nearby facilities, and search for vacant slots using their hand-held devices [33,34].

Vision-driven systems in SPMS are used to perform automated facility activity monitoring by acquiring a scene understanding of vehicle parking activity events that are occurring by utilizing real-time or recorded video streams [35,36]. This can be performed through VD [37,38], vehicle tracking [33,39], and LPR [36,40]. Computer vision tools can expedite facility monitoring and management processes provided that the built environment is SPMS-compliant for its hardware and software components, although some challenges still remain [40,41].

Several OD architectures are clustered into two types: single-stage detectors (SSDs) and two-stage detectors (TSDs) [42]. SSD architectures include EfficientDet, RetinaNet [42], and the YOLO architectures [43]. TSDs include some convolutional neural networks (CNNs) such as Faster R-CNN [44], Mask R-CNN [38], and SSD Mobilenet [45]. There are two OD-based methods for determining parking occupancy. One approach is to develop a model capable of classifying between occupied and vacant parking spaces. Automated parking occupancy determination (POD) is facilitated by this method, eliminating the need for predefined parking spaces. Another method is to first predefine the regions in an image frame where parking spaces are located. VD models will be used to detect vehicles, which are then passed to an algorithm to validate if the detected vehicle is located within the tolerance bounds of the predefined parking spaces. The study by [46] gives an implementation of OD that used the PKLot online dataset by detecting between “vacant” and “occupied” parking spaces.

System developers may find the first implementation method more versatile as the model, upon system deployment, can immediately discern between vacant and occupied parking spaces. This implementation approach is rather restrictive if scaling directions were to be pursued by the facility managers [47]. Comparing the inference location of VD inferences to predefined parking space ground truths is a safer and more consistent basis as this approach actively checks for the presence of vehicles and may rule out other objects that may occupy the parking space, but are only considered as noise, such as pedestrians and temporary fixtures. Adopting VD technology allows for further classification tasks. This data can be used in conjunction with algorithms that account for known parking space regions to accommodate potential future features [48,49]. In OD-based SPMS applications, the YOLOv7 OD architecture is preferred due to its proven and consistent performance [50,51,52], as well as efficiency [43,53].

Another core feature in SPMS is the capacity to perform LPR. Through LPR-based VP, SPMS-equipped facilities can recognize alphanumeric characters and symbols in license plates. This information serves as distinctive vehicle identifiers, which are crucial for security, invoicing, and tracking [8,36]. For LPR implementations, the hardware infrastructure must be considered. Using high-quality and noise-free camera hardware will ensure that images and videos are conducive for accurate inferences [54]. Additionally, each country may have different shapes and form for their vehicle license plates, necessitating the training of localized models for both LPD and STR [36,55,56]. Image datasets for training these models must include country-specific license plate images, with precise annotation and labeling, to guarantee the accuracy and reliability of LPR systems [55,57].

Conventional optical character recognition (OCR) AI models are not sufficient for SPMS contexts as commercial environments such as parking facilities cannot guarantee clean and noise-free images of license plates. These license plates may be curved, titled, and warped. OCR models exhibit high performance in controlled and noise-free environments [54]. In contrast, STR models are more versatile as they can analyze through image noise and distortions to obtain an accurate inference despite the images being plagued by occlusions, excessive glare or dimming due to lighting and weather conditions, and other external factors [41,58]. DTR is an STR architecture that extracts alphanumeric characters from objects found in noise-filled environments [59,60].

3. BIM and Digital Twins

Across several studies, DT models exhibit varying features and modeling complexities [61,62]. The DT model is a virtual replica of a real-world system, with the physical and digital models synchronized through a twinning mechanism. A DT is a model system representation located in the digital space. It reflects the real-world section or the physical system of interest. To produce a dynamic model of the physical system in the digital space, a twinning mechanism is needed to keep both spaces in sync with one another. The virtual twin commonly includes behavioral and structural dynamic CAD models. Analysis, forecasting, and optimization are made possible by constantly updating these models’ using information from the real world [62,63].

The four DT categories are as follows: (1) Component Digital Twins (C-DTs), which model individual machine parts or sensors to improve their performance and maintenance; (2) Asset or Machine Digital Twins (AM-DTs), which offer a digital representation of entire machines or equipment, allowing for improvements in operational efficiency and predictive maintenance; (3) System or Plant Digital Twins (SP-DTs), which simulate a network of interconnected assets that are not limited to a factory production line; (4) Enterprise-wide Digital Twins (EW-DTs), which are high-level organizational models intended to provide end-to-end visibility into operational metrics, resource allocation, and overall business performance. EW-DTs combine many digital and physical processes, offering a thorough business intelligence framework for data-driven decision-making [64].

A 3D BIM-based SPMS is an EW-DT based on functional design behavior. The BIM unifies several process metrics into a single, interactive platform, including vehicle movement analysis, occupancy tracking, and facility-wide performance indicators. Despite many parking facilities already relying on a variety of equipment hardware to report the availability of parking spaces, these systems often provide shallow data analytics [2,65]. DT technology facilitates a better understanding of collected data. DT models reflect real-time events in parking facilities and provide the avenue of simulating a specific set of proposed actions based on calculated facility metrics. Facility managers can exploit the advantages of automated data pipelines that provide a more comprehensive understanding of parking activity patterns to facilitate strategic decision-making and predictive analysis [66,67].

A clear and concise overview of available parking spaces is provided by 2D DT models with a representation of parking occupancy and facility layout. A 3D BIM approach provides advantages that address 2D modeling constraints, which include the tendency to oversimplify the geometrical and contextual features of an environment or space [30]. These 3D models accurately replicate the structure and environment of the parking facility by capturing intricate details using scanning technologies, such as laser scanning, LiDAR, and point cloud data [30,68]. The BIM workflow uses the 3D models stored within the Autodesk Revit 23.1.80.30 BIM software through a digital twinning mechanism [69]. This mechanism integrates information with the data processed within the SPMS’s backend data warehouse. It updates the model regularly to account for any new developments [30,70]. Facility administrators can improve their comprehension of operations and devise effective management strategies by visualizing the layout, real-time parking events, and traffic patterns of key performance indicators (KPIs) in their supplementary data dashboards through a dynamic 3D DT [63].

4. System Design Architecture

This study demonstrated the design, development, and testing of a non-real-time proof-of-concept SPMS with DT-BIM integration. The primary system design components included the construction of three critical modules: (1) the intelligent inference module (I2M), (2) the storage module (SM), (3) the digital twin module (DTM). The system’s machine learning and inference processing are managed by I2M. The SM oversees data transmission, primarily consisting of the raw and processed data outputs of the I2M module. Lastly, the DTM retrieves data from the SM and transmits it to a 3D DT model through Autodesk Revit, a type of BIM modeling software.

4.1. The Intelligent Inference Module

The I2M, shown in Figure 1, facilitates two primary tasks: POD and VP. YOLOv7 was used for vehicle OD, whereas for LPR, YOLOv7 and DTR were used for the LPD and STR sub-tasks, respectively.

The POD algorithm uses OD to automate the determination of parking occupancy changes across different video frames. This algorithm involves two Coordinates of Interest (COIs): the predefined center coordinate of each parking slot ($C_x$, $C_y$) and the center of the bounding box (Bbox) of each detected vehicle (${\mathit{Bbox}}_x$, ${\mathit{Bbox}}_y$). Equation (1) defines the Euclidean Pixel Distance (EPD) between these coordinates. The primary metric for evaluating parking occupancy is through the system calculation of distance, which determines the detected vehicle’s proximity to a predefined parking slot center. After the EPD for all detected vehicles is computed, the results are organized into an $N\times M \mathit{EPD} \mathit{Matrix} 2D \mathit{array}$. Here, $N$ represents the total number of parking spaces (seven in this instance), and $M$ represents the number of detected vehicles. Denoted as $d_{nm}$, each element in this matrix represents the EPD between the center of a specific parking slot and a detected vehicle, as formally defined in Equation (3).

The system employs the Python 3.7.13 NumPy module to implement a thresholding process for the $\mathit{EPD} \mathit{Matrix} \mathit{Array}$, thereby determining whether a detected vehicle (indexed as $M$) occupies a specific parking slot (indexed as $N$). A threshold value, ${tv}_{nm}$, is created and set to 1, indicating occupancy if the EPD $d_{nm}$ is 80 pixels or less. Otherwise, it remains zero, as defined in the piecewise function in Equation (4). The $\mathit{TV} \mathit{Matrix} \mathit{Array}$ is subsequently defined in Equation (5), which is composed of multiple ${tv}_{nm}$ values. This matrix filters out vehicles too far from a parking slot to be considered occupants. After thresholding, the $\mathit{TV} \mathit{Matrix} \mathit{Array}$ is flattened into a one-dimensional occupancy or $\mathit{Occ} \mathit{State} \mathit{Array}$. Each element ${os}_n$, as defined in Equation (6), represents the occupancy status of a parking slot: a Boolean value of 1 if occupied, and 0 if vacant. This array provides a direct, simplified representation of the parking lot’s real-time status.

The system maintains a $\mathit{Change} \mathit{State} \left(CS\right) \mathit{Checker} \mathit{Array}$ to monitor changes over time. The $\mathit{CS} \mathit{Checker} \mathit{Array}$ is initialized as an exact copy of the $\mathit{Occ} \mathit{State} \mathit{Array}$ if the current frame is the first processed frame. The system updates the $\mathit{CS} \mathit{Checker} \mathit{Array}$ for all subsequent frames by subtracting the $\mathit{Occ} \mathit{State} \mathit{Array}$ from the previous frame’s CS checker values, as shown in Equation (7). The array values, Equation (8), can assume three states: 0 if the parking slot’s status remains unchanged, −1 if a previously occupied slot is now unoccupied, and 1 if an empty slot has recently been occupied. The system proceeds to evaluate the values of the $\mathit{CS} \mathit{Checker} \mathit{Array}$ to determine which parking locations have undergone state changes after it has been updated. The system updates the parking occupancy records by communicating with the database if any modifications are detected. No data transmission occurs if no changes are observed. This algorithm is repeated on a loop, dynamically iterating through each phase and returning to VD in the subsequent frame. The algorithm guarantees the precise, real-time monitoring of parking availability by consistently monitoring changes in occupancy states across video frames. The VD-based POD algorithm is summarized in

Table 1. VD-based POD algorithm.

Step 1:	Perform VD on video frame.
	$\mathit{EPD}=\sqrt{{({\mathit{Bbox}}_x-C_x)}^2+{({\mathit{Bbox}}_y-C_y)}^2}$	(1)
Step 2:	$\mathrm{Generate} \mathrm{the} \mathit{EPD} \mathit{Matrix} \mathit{Array}$ accounting for seven parking spaces.
	$\mathit{EPD} \mathit{Matrix} \mathit{Array}=\left[\begin{array}{c}\begin{array}{ccc}[d_{11}& \dots & d_{1m}]\end{array}\\ \begin{array}{ccc}⋮& \ddots & ⋮\end{array}\\ \begin{array}{ccc}[d_{71}& \dots & d_{7m}]\end{array}\end{array}\right]$	(2)
	$d_{nm}=\sqrt{{({\mathit{Bbox}}_{X_m}-C_{X_m})}^2+{({\mathit{Bbox}}_{Y_m}-C_{Y_m})}^2}$	(3)
Step 3:	$\mathrm{Perform} \mathrm{NumPy} \mathrm{thresholding} (80 \mathrm{pixels}) \mathrm{to} \mathrm{obtain} \mathrm{the} \mathit{TV} \mathit{Matrix} \mathit{Array}$.
	${tv}_{nm}=\left\{\begin{array}{c}\begin{array}{cc}0,& d_{nm}>80\end{array}\\ \begin{array}{cc}1,& d_{nm}\le 80\end{array}\end{array}\right.$	(4)
	$\mathit{TV} \mathit{Matrix} \mathit{Array}=\left[\begin{array}{c}\begin{array}{ccc}[{tv}_{11}& \dots & {tv}_{1m}]\end{array}\\ \begin{array}{ccc}⋮& \ddots & ⋮\end{array}\\ \begin{array}{ccc}[{tv}_{71}& \dots & {tv}_{7m}]\end{array}\end{array}\right]$	(5)
Step 4:	$\mathrm{Generate} \mathrm{the} \mathrm{Flattened} 1\mathrm{D} \mathrm{Occ} \mathrm{State} \mathrm{Array}$ for the current frame.
	$\mathit{Occ} \mathit{State} \mathit{Array}=\begin{array}{cc}\left[\begin{array}{ccc}{os}_1& \dots & {os}_7\end{array}\right],& {os}_n\in \left\{0,1\right\}\end{array}$	(6)
Step 5:	Determine if the current inference is the first detection since initialization. IF first,   $\mathrm{THEN} \mathit{CS} \mathit{Checker} \mathit{Array}=\mathrm{Flattened} 1\mathrm{D} \mathrm{Occ} \mathit{State} \mathit{Array}$ ELSE   $\mathit{CS} \mathit{Checker} \mathit{Array}=\mathit{CS} \mathit{Checker} \mathit{Array}- \mathrm{Occ} \mathrm{State} \mathrm{Array}$ WHERE:
	$\mathit{CS} \mathit{Checker} \mathit{Array}=\left[{cs}_1 \dots {cs}_7\right], { cs}_n\in \{-\mathrm{1,0},1\}$	(7)
	${cs}_n=\left\{\begin{array}{c}\begin{array}{cc}\mathit{Occ} \mathit{State},& \mathit{first} \mathit{frame}\end{array}\\ \begin{array}{cc}\mathit{CS} \mathit{Checker}-\mathit{Occ} \mathit{State},& \mathit{other} \mathit{frames}\end{array}\end{array}\right.$	(8)
Step 6:	$\mathrm{Examine} \mathrm{all} \mathrm{column} \mathrm{elements} \mathrm{in} \mathrm{the} \mathit{CS} \mathit{Checker} \mathit{Array}$ to determine which parking spaces had changes in their occupancy state.
Step 7:	$\mathrm{Push} \mathrm{updated} \mathrm{data} \mathrm{to} \mathrm{the} \mathrm{database} \mathrm{depending} \mathrm{on} \mathrm{each} {cs}_n$$\mathrm{value} \mathrm{in} \mathrm{the} \mathit{CS} \mathit{Checker} \mathit{Array}$.
Step 8:	Return to Step 1.

. This algorithm accounts for seven parking spaces, from parking spaces #1 to #7.

For the algorithm for determining the state of parking occupancy based on LPR inferences, modifications to the previous algorithm, particularly the classification of detected objects and the number of parking spaces constrained to two slots, parking spaces #8 and #9, were adopted. The algorithm is shown in

Table 2. LPR-based POD algorithm.

Step 1:	Perform LPD on video frame.
Step 2:	$\mathrm{Generate} \mathrm{the} \mathit{EPD} \mathit{Matrix} \mathit{Array}$ for the two parking spaces.
Step 3:	$\mathrm{Perform} \mathrm{NumPy} \mathrm{thresholding} (70 \mathrm{pixels}) \mathrm{to} \mathrm{obtain} \mathrm{the} \mathit{TV} \mathit{Matrix} \mathit{Array}$.
Step 4:	$\mathrm{Generate} \mathrm{the} \mathit{Flattened} 1D \mathit{Occ} \mathit{State} \mathit{Array}$ for the current frame.
Step 5:	Determine if the current inference is the first detection since system initialization. IF first,   $\mathrm{THEN} \mathit{CS} \mathit{Checker} \mathit{Array}=\mathrm{Flattened} 1\mathrm{D} \mathrm{Occ} \mathit{State} \mathit{Array}$ ELSE   $\mathit{CS} \mathit{Checker} \mathit{Array}=\mathit{CS} \mathit{Checker} \mathit{Array}- \mathrm{Occ} \mathrm{State} \mathrm{Array}$
Step 6:	$\mathrm{Examine} \mathrm{all} \mathrm{column} \mathrm{elements} \mathrm{in} \mathrm{the} \mathit{CS} \mathit{Checker} \mathit{Array}$ to determine which parking spaces had changes in their occupancy state.
Step 7:	$\mathrm{Perform} \mathrm{corresponding} \mathrm{action} \mathrm{for} \mathrm{each} \mathrm{element} \mathrm{found} \mathrm{in} \mathrm{the} \mathit{CS} \mathit{Checker} \mathit{Array}$. $\mathrm{IF} {cs}_n= 1:$    THEN Perform LPR and Extract LPR Reading. ELSE:    Do not perform LPR.
Step 8:	Return to Step 1.

.

4.2. The Storage Module

The SM operates on a Structured Query Language or SQL-based relational database framework. The module uses SQLite3 Studio to manage the database and establishes connections with different SPMS modules through the SQLite3 Python Module. The first database records parking activity using VD-based POD, the second database manages LPR-based POD with VP, and the third database monitors vehicle entry and exit at access points through LPR. Supplementary Files S1 shows the SQL database schema of the three databases.

The first database, see Supplementary File S1, organizes live occupancy data in the pklot_overview table by automating value assignments using SQLite3’s generated expressions. Whether a space is ‘occupied’ (1) or ‘vacant’ (0) is determined by a Boolean occupancy_state attribute. The pklot_1 to pklot_7 tables record the timestamps of each parking event, with park_start being recorded upon entry and park_end being amended upon exit. The park_duration in hours is calculated using integer-converted timestamps and stored as a float with two decimal places, with a unique occurrence_index serving as the primary key (PK).

The next database, see Supplementary File S1, incorporates occupancy data with LPR-based VP data through an added LPR_reading attribute. In the pklot_overview table, PKs represent designated parking slots, ensuring each row displays the latest occupancy state and profiling information. The pklot_overview and pklot_n tables are updated automatically using the built-in function feature of SQLite3 Studio for Generated Values (GVs) to refresh the occupancy_text and parking_duration attributes based on the occupancy status attribute’s value. The Mirroring Value (MV) mechanism copies the most recent LPR readings from pklot_8 and pklot_9 into pklot_overview, maintaining the synchronization of occupancy and profiling data. When a slot is vacant, the license_plate is assigned a null value, and the occupancy_state is reset to 0.

The third database, see Supplementary File S1, has three tables that house vehicle entry and exit data: the vehicle_flow_timestamp_log table documents entry and exit times, parking duration, and billing information. To ensure data organization, the tables 进_car_record (table for entry records) and 出_car_record (table for exit records) contain LPR readings, timestamps, reading scores, and image file paths linked to the main table through foreign keys (FKs).

The database management process relies on the outputs of the LPR feature of the SPMS. Upon entry, the system captures an LPR reading and creates a record in 进_car_record, with the timestamp stored as an MV in the vehicle_flow_timestamp_log table. Upon exit, a new record is added to 出_car_record, and the system correlates it with the latest entry in 进_car_record. The exit timestamp is subsequently reflected in vehicle_flow_timestamp_log, establishing a connection between both records through FKs, denoting a complete vehicle entry–exit cycle. SQLite3’s GV feature automates the calculation of parking duration and billing through timestamps. Integrating MV and GV enhances data management by removing the necessity for manual record searches in bill generation.

Table 3. LPR entry/exit DBMS data processing algorithm.

Step 1:	LPR during Vehicle Entry: The vehicle is subjected to LPR upon entry.
Step 2:	Entry Record Creation: A new row is generated in the 进_car_record table to record the entry, which includes the entry timestamp, the LPR reading, and the reading score output by the system’s model.
Step 3:	Creation of Flow Log: In the vehicle_flow_timestamp_log table, a row entry is generated in to start the cycle record of the vehicle’s activity within the facility.
Step 4:	Mirrored Entry Timestamp and FK: The 进_timestamp from 进_car_record is mirrored in vehicle_flow_timestamp_log, which also stores the 进_car_record PK as an FK.
Step 5:	Vehicle Exit and LPR: When the vehicle departs, the system records an exit LPR reading and timestamp in a new 出_car_record table row.
Step 6:	Entry Record Matching: The system retrieves the latest matching PK from the 进_car_record table based on the vehicle’s LPR reading at exit, ensuring accurate tracking of the most recent entry, even with multiple visits per day.
Step 7:	Linking to Flow Log: The entry FK of the identified PK from the 进_car_record table is then used to locate it within the vehicle_flow_timestamp_log table. This ensures the entry and exit data belong to the exact vehicle instance.
Step 8:	Mirroring Exit Timestamp and FK: The exit record’s PK is stored an FK in the vehicle_flow_timestamp_log table, and the exit timestamp (出_timestamp) is mirrored into the vehicle_flow_timestamp_log table.
Step 9:	Automatic Calculations: SQLite3 value expressions compute total parking duration (in seconds and hours) and invoicing based on pricing, using timestamps from the vehicle_flow_timestamp_log table.

presents the sequential algorithm for LPR and database updates within the third system feature.

4.3. The Digital Twin Module

Two design phases are involved in developing the DTM as shown in Figure 2. The initial phase consists of preparing and collecting the materials required to construct a 3D model for the first and second system features. The next phase starts after the static 3D model in Autodesk Revit. The primary objective of the second phase is to integrate the twinning mechanism feature of Autodesk Revit with components from the I2M and the SM. The model will become dynamic upon the completion of this integration, allowing it to reflect changes in parking occupancy and serve as a digital counterpart of the parking facility.

In phase 1 of developing the DTM, a 3D LiDAR scan of a parking facility was conducted utilizing Polycam on an iPhone 14 Pro device. The point cloud data, shown in Figure 3, illustrates the facility’s vehicular flow, encompassing entry and exit roadways, a two-way driveway, and designated loading and unloading areas. The facility can accommodate 30 four-wheeled vehicles. As stated in the literature, the scanning accuracy of the Polycam mobile application is ±5 cm [71].

The scanned data was exported as a .pts file, processed in Autodesk Recap Pro, and converted to .rcp format for importing into Autodesk Revit. In Revit, 3D toposolid components, including walls, columns, parking curbs, and spaces, were aligned with the geometries of the point cloud (Figure 4a). Parking spaces were modeled as Revit family objects, which were then placed onto the toposolid ground surface of the model to facilitate enhanced attribute appearance flexibility for the Revit object (Figure 4b).

A 3D Revit object of a Land Rover SUV from [72] was placed into each parking space. The parked_car graphic attribute controls vehicle visibility. The vehicle is displayed when assigned a True value, indicating an occupied slot. Conversely, the car is concealed when set to False, signifying a vacant slot. Figure 5a demonstrates the toggling of this attribute, whereas Figure 5b presents a detailed view of the imported Revit SUV objects.

In the final phase of DTM development, Autodesk Revit Dynamo was used to bridge together the I2M and DTM. An Excel file, managed through the Python openpyxl library, toggles the cell AI between a True and False to reflect POD algorithm occupancy updates. Revit Dynamo receives the toggle state changes and processes it through block functions. Supplementary File S2 shows the Revit Dynamo script used in the DTM.

Various system metrics are used to gauge the state of the parking facility at a given period. Data was pulled from the SQLite Database using Microsoft Excel’s built-in ODBC API. Metrics are computed using custom-built Excel functions, and certain metrics were supplemented with visual charts. Below is the list of metrics used to describe the state of parking occupancy for the DTM’s data dashboard component.

4.3.1. Individual and Gross Revenue from Parking Fare Matrix

The parking operator applies a minimum parking charge in Philippine pesos of PHP 50.00, with an hourly charge of PHP 20.00. Hourly fees will start to be applied for parking durations exceeding three hours (10,800 s) as shown in Equation (9), where $t_m$ represents the parking time duration of a vehicle in seconds.

$$\mathrm{Total} {\mathit{Fare}}_r=\left\{\begin{array}{cc}50,& t_m<\mathrm{10,800}\\ 50+20·⌈{\displaystyle \frac{t_m-\mathrm{10,800}}{3600}}⌉,& t_m\ge \mathrm{10,800}\end{array}\right.$$

(9)

The system generates gross profit reports for specified periods, summarizing all collected parking fees. The total revenue is calculated using Equation (10).

$$\mathit{Total} \mathit{Revenue}={\sum }_{r=1}^r{\mathit{Total} \mathit{Fare}}_r$$

(10)

4.3.2. Parking Occupancy Duration of Each Parking Space

Equation (11), the parking occupancy duration, measures the time between a vehicle’s entry and exit. The average duration, which is the mean of all occupancy durations across different cars occupying a parking space, is determined by Equation (12). A box plot can visually represent the average parking duration per space, emphasizing both typical durations and any unusually lengthy stays as outliers [73,74].

$${\mathit{Parking} \mathit{Duration}}_i={\mathit{timestamp}}_{i,\mathit{start}}-{\mathit{timestamp}}_{i,\mathit{end}}$$

(11)

$$\mathit{Mean} \mathit{Parking} \mathit{Duration}={\displaystyle \frac{{\sum }_{i=1}^i{\mathit{Parking} \mathit{Duration}}_i}{\mathit{Total} \mathit{Number} \mathit{of} \mathit{Parked} \mathit{Vehicles}}}$$

(12)

4.3.3. Parking Occupancy Rate

The parking occupancy rate is used to evaluate the facility efficiency through parking space utilization, which, as defined in Equation (13), is the ratio of the parking duration available for a single space to the total occupancy duration of parked vehicles. In this context, $t_h$ denotes the occupancy duration for parking lot index h, while $x_h$ is a binary variable that indicates whether parking lot h is occupied. In Equation (14), the variable $x_h$ can accept only two values. The observed duration for slot h is denoted by the variable ${\mathit{observed} \mathit{time}}_h$. Equation (15), the facility’s overall occupancy rate, is the ratio of the cumulative parking duration to the total occupancy duration of all parking spaces [74].

$$\mathit{Individual} \mathit{Occupancy} \mathit{Rate}={\displaystyle \frac{t_h·x_h}{{\mathit{observed} \mathit{time}}_h}}$$

(13)

$$x_h=\left\{\begin{array}{cc}1,& {\mathit{slot}}_h \mathit{is} \mathit{occupied}\\ 0,& {\mathit{slot}}_h \mathit{is} \mathit{vacant}\end{array}\right.$$

(14)

$$\mathit{Overall} \mathit{Occupancy} \mathit{Rate}={\displaystyle \frac{{\sum }_{h=1}^h{t}_h·x_h}{{\sum }_{h=1}^h{\mathit{observed} \mathit{time}}_h}}$$

(15)

4.3.4. Parking Turnover Rate

The parking turnover rate quantifies the frequency with which parking spaces transition from occupied to vacant states within a predetermined time frame. It may or may not be desirable to have parking spaces left vacant for protracted periods, depending on the purpose of the facility. In an ideal scenario, a vehicle should promptly occupy the space that a vehicle has vacated. Effective space utilization, reduced congestion, and improved parking management efficiency may be indicative of a high turnover rate. Nevertheless, it may also indicate an excessive demand for parking, which can result in heightened traffic congestion as vehicles attempt to locate available spaces. In contrast, a low turnover rate may be more advantageous in long-term parking scenarios, as it can indicate reduced congestion and stability for vehicle owners, who are guaranteed a parking space without the need to conduct an exhaustive search. The individual turnover rate is the ratio of the frequency of vehicle turnover to the total observation time, as delineated in Equation (16). The sum of all individual turnover rates is the overall turnover rate, as defined in Equation (17). Lastly, Equation (18) determines the average turnover rate by dividing the overall turnover rate by the total number of observed parking spaces [74].

$${\mathit{Individual} \mathit{Turnover} \mathit{Rate}}_h={\displaystyle \frac{\mathit{total} \mathit{turnover} \mathit{frequency} \mathit{for} {\mathit{slot}}_h}{{\mathit{observed} \mathit{time}}_h}}$$

(16)

$$\mathit{Overall} \mathit{Turnover} \mathit{Rate}={\sum }_{h=1}^h{\mathit{Individual} \mathit{Turnover} \mathit{Rate}}_h$$

(17)

$$\mathrm{Average} \mathrm{Turnover} \mathrm{Rate}={\displaystyle \frac{\mathit{Overall} \mathit{Turnover} \mathit{Rate}}{\mathit{Total} \mathit{Observed} \mathit{Parking} \mathit{Slots}}}$$

(18)

4.3.5. Peak Occupancy Periods

Peak occupancy period graphs offer a visually intuitive method of interpreting parking trends over time. A high y-value at a given timestamp indicates a higher occupancy rate, while lower values suggest greater availability. The graph’s peak corresponds to the time of highest occupancy, indicative of periods of peak demand for facility resources [75].

4.3.6. Dwell Time Distributions

Parking dwell time distributions provide insights into vehicle occupancy patterns within a parking facility. In this type of graph, the x-axis depicts specific parking durations, while the height of each column denotes the frequency or quantity of vehicles parked within those time frames. This distribution emphasizes typical parking durations, enabling the identification of peak usage periods and the overall utilization of parking spaces. This information can inform strategies for optimizing space allocation and enhancing the efficiency of parking facility management operations [76].

5. Materials, Methods, and the Study Environment

This section discusses the physical implementation of the hardware components of the developed SPMS. The hardware configuration of the system, with a particular focus on camera positioning and setup, and the methods employed for dataset acquisition to facilitate model training are among the most significant topics of discussion. Furthermore, this section explores the methodology for dataset processing, model training, and selecting the best models for integration into the previously discussed I2M. Supplementary File S3 shows the budget expenditure for the implementation of the study.

5.1. Hardware Design Considerations

Security cameras are installed at critical points throughout the building complex to facilitate various system functions. Supplementary File S4 shows the floor plan in the building complex with the camera positions together with fields of view. Each of the four cameras is represented through a color-coded node, with each color being a cluster of a specific system feature of the I2M. A green node indicates a ceiling-mounted fisheye lens Closed-Circuit Television (CCTV) camera responsible for monitoring the parking spaces, supporting the first system feature. The blue node is for a fixed bullet turret CCTV camera positioned at a height of 1.2 m from the ground. The camera’s field of view is restricted to two parking spaces, angled to capture the license plates of parked vehicles for the second system feature. The Pan–Tilt–Zoom (PTZ) cameras, for the third system feature, are installed at entry and exit points at a height of 1.7 m from the ground to record vehicle movement.

5.2. Dataset Collection and Processing

A trained OD model was created for VD as a requirement of the I2M’s VD-based POD algorithm. The dataset was retrieved from fisheye camera footage in the parking facility, extracting one frame every 60 s from 44 h of 1080p video, resulting in 2326 images. Roboflow, a web-based annotation platform, was used to annotate all four-wheeled motor vehicles and label them as “cars”. The image augmentations for VD are listed in Supplementary File S5. It outlines the Roboflow image augmentations used to enhance dataset quality and increase its size to 4998. The dataset followed an 80-10-10 train–validation–test split partitioning for model training purposes.

Two datasets were used to train this study’s LPD model, which is used to enable the LPR-based POD monitoring of the system. The De La Salle University’s Intelligent Systems Laboratory (DLSU ISL) Research Unit provided the annotated CATCH-ALL dataset, containing 3212 images [55]. A second dataset was generated from the sampled frames captured by security cameras near the building’s entrance and exit driveways. To capture a variety of weather conditions, frames were selected from 12 h of 1080p footage, which included daytime, afternoon, nighttime, and post midnight images. A custom dataset of 676 images was generated by capturing fifteen frames for each vehicle that entered and exited. To increase variability, Roboflow was used to perform image augmentations on both the CATCH-ALL and the custom LPD datasets, expanding the datasets to 6886 and 1448 images, respectively. Single-class labeling was implemented in the custom dataset, with all license plate annotations being tagged as ‘license_plate.’ Training, validation, and testing were conducted using an 80-10-10 split. The image augmentations for LPD are listed in Supplementary File S5. The DTR model was also trained using the CATCH-ALL dataset in CVAT [36].

5.3. Model Training and Evaluation Methods

A Windows 11 OS-based local machine device was used to train inference models for VD, LPD, and DTR. The hardware specifications of the local machine are listed in Supplementary File S6. To select the optimal VD model for integration into the parking management system’s I2M, several YOLOv7 architecture variants were trained, each with different performance trade-offs. Certain architectures prioritize high precision, providing exceptional detection accuracy but with slower inference speeds. In contrast, others offer faster inference at the expense of some accuracy suited for real-time processing needs [53]. The training involved both base training and finetuning processes. The base training process refers to a transfer learning approach where the publicly available YOLOv7 pre-trained weights (trained using MS COCO) were used as initial weights and trained using the locally procured image datasets. Finetuning is then applied using a different set of training hyperparameters on the same dataset. Decreasing both the learning rate and the number of epochs was observed during the finetuning process. Each YOLOv7 model architecture variant employed specific training hyperparameter sets, as outlined in the Supplementary File S7.

Model fitness, defined in Equation (19), was used to evaluate the trained models using the mean average precision (mAP) at an Intersection Over Union (IOU) threshold of 50% (${\mathit{mAP}}_{50}$) and from 50% to 95% (${\mathit{mAP}}_{0.5:0.95}$). The model with the highest score was selected for system integration to enable the VD-based POD. ${\mathit{mAP}}_{50}$ is regarded as the primary evaluation metric.

$$\mathit{Model} \mathit{Fitness} \mathit{Score}=0.1{\mathit{mAP}}_{50}+0.9{\mathit{mAP}}_{0.50:0.95}$$

(19)

LPD model training was performed in two phases. In phase 1, the CATCH-ALL dataset was used to train a YOLOv7 base model through transfer learning using open-source YOLOv7 pre-trained weights. Phase 2 refines the base model by using a custom dataset from the parking facility’s surveillance cameras, training on footage exhibiting site-specific factors such as lighting, glare, distance, and resolution in another transfer learning process. The training hyperparameters used in each phase of the LPD model training procedure are listed in Supplementary File S7. The ${\mathit{mAP}}_{50}$ metric was used to assess the LPD performance.

The training hyperparameters for DTR model training are listed in Supplementary File S7. The publicly available DTR pre-trained models (trained from the MJSynth and SynthText datasets) were used as initial training weights for transfer learning-based model training. The final model was refined from this base. The main evaluation metric, which is the Character Error Rate (CER), measures character-level errors in substitution, deletion, and insertion. A 0% CER suggests that the recognition is highly accurate.

The training script does not explicitly provide a CER score; instead, it outputs the Euclidean Distance (ED) to assess the performance of newly trained text recognition models [59]. ED measures the geometric distance between the ground truth labels in the test set and predicted text sequences, serving as the accuracy metric. A lower ED score indicates a higher accuracy [36,77]. CER, defined in Equation (20), is derived from the CER.

$$\mathit{CER} (\%)=100\%-\mathit{ED} \mathit{Score}$$

(20)

A unified metric is required to quantify the extent to which individual model metrics contribute to the performance and reliability of each I2M feature. The combined overall feature performance of each I2M system feature, as defined in Equation (21), is the product of the primary assessment metrics of each trained model.

$$\mathit{Feature} \mathit{Performance}={\prod }_{i=1}^i{\mathit{Assessment} \mathit{Metric}}_i$$

(21)

6. Results and Discussion

The model performance and the calculated feature performance metric for each I2M feature are presented in this section. The 3D BIM, designed and developed in Autodesk Revit and Dynamo, and the system database contents and structure are used to analyze the output data extracted from the VD- and LPR-based POD algorithms. The DTM data dashboard component is also presented based on sample processed data.

6.1. Model and System Feature Performances

6.1.1. VD-Based POD Feature

The initial system feature uses VD inference to determine the occupancy state changes in parking spaces. The ${\mathit{mAP}}_{0.5:0.95}$ and ${\mathit{mAP}}_{50}$ metrics, inference speed, and fitness score for each trained YOLOv7 model are presented in

Table 4. Trained VD models: metrics of assessment and model fitness scores.

Model Type	$\mathit{m}\mathit{A}\mathit{P}$	${\mathit{m}\mathit{A}\mathit{P}}_{50}$	Inference Speed	Model Fitness Score
YOLOv7 Base	72.39%	94.90%	4.80 ms/img	74.64%
YOLOv7 Finetuned	72.60%	95.01%	4.70 ms/img	74.84%
YOLOv7-d6 Base	64.82%	90.98%	8.50 ms/img	67.43%
YOLOv7-d6 Finetuned	65.78%	91.69%	8.30 ms/img	68.37%
YOLOv7-e6 Base	66.51%	93.57%	7.10 ms/img	69.22%
YOLOv7-e6 Finetuned	67.80%	93.58%	6.90 ms/img	70.38%
YOLOv7-e6e Base	68.25%	93.56%	10.00 ms/img	70.78%
YOLOv7-e6e Finetuned	68.62%	93.77%	9.90 ms/img	71.14%
YOLOv7-w6 Base	64.55%	92.74%	5.00 ms/img	63.37%
YOLOv7-w6 Finetuned	65.56%	92.75%	5.30 ms/img	68.28%
YOLOv7-Tiny Base	63.83%	91.70%	2.90 ms/img	66.62%
YOLOv7-Tiny Finetuned	64.24%	92.12%	2.40 ms/img	67.03%
YOLOv7-x Base	73.83%	94.86%	6.30 ms/img	75.94%
YOLOv7-x Finetuned	73.78%	94.71%	6.10 ms/img	75.87%

. The YOLOv7-x base VD model was chosen for system integration as it obtained the highest fitness score of 75.94%, as calculated using Equation (19). Moreover, only one model was used for this system feature. The performance is evaluated using ${\mathit{mAP}}_{50}$, which reached 94.86%. Sample VD inferences are provided in Supplementary File S8. These inferences operate under a 50% minimum IOU and confidence threshold.

6.1.2. LPR-Based POD Feature

Two LPD and two DTR models were trained. The assessment of the ${\mathit{mAP}}_{50}$ performance metric of the LPD models showed that there was a significant improvement in training the base model with the custom dataset. Conversely, for the DTR-STR models, the finetuned model showed a slightly better accuracy. The metrics are listed in

Table 5. Trained LPD and DTR models: metrics of assessment.

Model Type	Function	$\mathit{m}\mathit{A}\mathit{P}$	${\mathit{m}\mathit{A}\mathit{P}}_{50}$	Inference Speed
CATCH-ALL Model	LPD	74.58%	97.71%	4.50 ms/img
Custom Dataset Model	LPD	85.24%	99.27%	4.40 ms/img
Base DTR Model	DTR	4.00%	90.32%	5.40 ms/img
Finetuned DTR Model	DTR	4.00%	90.50%	5.50 ms/img

below.

The custom-trained LPD model was integrated with the finetuned DTR model for a single inferencing LPR pipeline. The pipeline’s feature performance score is 95.24%. Sample LPD inferences are provided in Supplementary File S9.

6.1.3. LPR-Based Facility Entry/Exit Feature

The models used for the second system feature are also implemented in the third system feature. LPD is essential for the localization of license plates of entering and exiting vehicles. Simultaneously, the database stores all LPR inferences. As the models used are the same as the previous system feature; it follows that this system’s feature performance metric is also 95.24%. Figure 6 shows sample inferences under different lighting conditions at different times of the day. The model shows a consistent performance, effectively detecting license plates in standard and low-light conditions at both driveways.

6.2. Three-Dimensional BIM Digital Twin Implementation

The POD algorithms from the I2M and connected to the SM comply with a standardized parking space numbering system. Subscribing to this numbering system allows facility managers to refer to the parking slot numbering in the database, obtain information on the occupancy state of parking space resources relative to the slot number, and cross-validate it with the 3D BIM DT. Figure 7 provides the standardized parking occupancy designation convention for the selected parking spaces used in this study.

6.2.1. VD-Based POD Digital Twin

The Revit model is modified constantly using data from the primary feature system’s database file. The occupancy_text column of the pklot_overview table is retrieved by Revit Dynamo, which then processes the data to represent vehicles located in spaces monitored by the system. The visualization promptly reflects the database’s overview display that all seven parking spaces are occupied, as demonstrated in Figure 8.

6.2.2. LPR-Based POD Digital Twin

Data from the second feature’s database can also be used to update the DT model. Similarly to the initial system, Dynamo processes data from the occupancy_text column of the pklot_overview table to show the vehicles parked in locations that are monitored and accounted for by the LPR component of the system. Alternative scenario examples can be found in Supplementary File S10.

6.3. Database Model Implementation

The pklot_overview table in the database is the sole table that is continuously overwritten to provide the most recent occupancy status of the presently processed video in both POD algorithm-driven system features. New data entries are appended to all other pklot_n tables, and no deletions or overwrites occur. Across all POD systems, an entry is generated for each vehicle iteration entering and exiting a parking space. This entry includes the index ID, the entry and exit timestamps, the parking duration in hours, and the LPR reading (for the VD-based POD system, no LPR reading is included in the database). The pklot_overview table summarizes the current occupancy status by reflecting the most recent row entry from each pklot_n table. The parking space is considered occupied if the park_end column of the most recent entry in the pklot_n table contains a NULL value. Otherwise, the parking space is declared vacant if park_end is not null.

The third system feature is demonstrated by analyzing the contents of the output database. The 进car_record and 出car_record tables in the third database are where each vehicle entry and exit event is recorded. The figures can be found in Supplementary File S11. The ID attribute identifies each vehicle’s entry into and exit from the parking facility. The score attribute stores the inference confidence score associated with the text string produced by the trained DTR model, displayed by the lpr_reading attribute. The tables contain two file path columns: lpd_filepath and cropped_lpd_file_path. The string file paths to the cropped license plate image and the full-frame image acquired during each vehicle entry and exit event are stored in these columns.

6.4. DTM Data Dashboard Implementation

Video surveillance feeds were collected on and at a variety of dates and times, with footage being recorded on Sundays, of which SPMS metrics from the processed VD- and LPR-based POD algorithms and parking monitoring data were derived. The first and second feature systems in the parking facility were analyzed using a total of seven hours of surveillance footage, while the vehicle entry and exit driveways each involved the processing of 7.5 h of footage. The processed data is extracted from the database management systems associated with each feature system using the Power Query function in Microsoft Excel. The data is then retrieved directly from the SQLite3 local database system into Microsoft Excel using the ODBC API. The graphical charts and a quantitative report summarizing the computed metrics are automatically updated whenever the spreadsheet is refreshed, ensuring that the Microsoft Excel spreadsheet file consistently reflects the most recently documented data. This effectively functions as a dynamic data metrics-based digital twin dashboard that offers valuable insights into parking trends captured by the system’s machine learning models and algorithms, facilitating a more transparent comprehension of critical metrics and vehicle parking activity. Moreover, the metrics dashboard lets users specify the starting and ending observation periods in green highlighted cells, enabling targeted analysis within customized timeframes. This feature also allows flexible data filtering. The data dashboard’s usability is improved through the filtering capability, which offers targeted insights that are customized to specific time intervals.

6.4.1. VD-Based POD Data Dashboard System

The metrics dashboard provides insights into driver–vehicle activity within the facility and their utilization of parking space resources. The interface is shown in Figure 9 below, which provides a macro-level understanding of the utilization of parking spaces within the specified time frame by providing combined graphs for the occupancy step function, turnover rate, occupancy rate, and parking dwell time distributions.

For example, a rising occupancy rate and step function will indicate an increased demand for a specific time interval. At the same time, rapid turnover cycles in individual spaces are reflected in brief, abrupt shifts in turnover. Throughout the observation period, this graph allows for the intuitive monitoring of utilizing the facility’s seven parking spaces. In this simulation, the overall occupancy rate refers to the average occupancy rate of only seven parking spaces. This does not refer to the overall occupancy of all 30 parking spaces, as the developed POD algorithm was not applied to all parking spaces within the facility during system testing.

The dwell time distribution is a column chart with box-and-whisker plots that summarize the occupancy lengths of various locations to investigate parking duration further. It is also provided within the same dashboard. These plots assist managers in the rapid identification of spaces with a high turnover versus those with extended occupancy by displaying the data distribution and outliers. This perspective facilitates a more thorough comprehension of parking dynamics in the facility. The data presented in the overview interface is derived from each parking space’s vehicle parking activity data. The dashboard platform also provides each parking slot with a sub-dashboard containing four graphical charts. These graphs capture the occupancy step function, turnover rate, dwell time distribution, and recorded occupancy rate over time for each slot, offering granular insights into parking patterns at the individual space level.

6.4.2. LPR-Based POD Data Dashboard System

The data dashboard for the LPR-based POD system is structured similarly to the previous system, with an overview dashboard and sub-dashboards for each parking space. As the graph types have not changed, the analytical principles governing such charts’ analysis are still applicable. The contents of the tabulated data dashboard generated during system testing using processed surveillance footage are delineated in

Table 6. Metric summary for the LPR-based POD system.

Category	Occupancy Rate	Turnover Rate	Average Parking Duration
Parking Space #8	56.21%	1 vehicle/h	0.56 h
Parking Space #9	73.91%	0.71 vehicle/h	1.03 h
Combined Overview	65.06%	1.71 vehicle/h	0.74 h

.

6.4.3. Facility Entry and Exit Data Dashboard System

Table 7. Metric summary for the facility entry–exit monitoring system.

Metric	Metric Score
Total Revenue	Php 1550.00
Average Revenue/Hour	Php 206.67
Average Parking Duration	1.39 h
Average Occupancy Rate	122.84%
Average Turnover Rate	4.13 Cars/h

Average currency conversion rate (year 2025): 1.00 USD = 58.10 PHP.

lists the computed metrics processed by the SM and DTM based on stored database contents for the facility entry and exit monitoring feature system. Visual charts also provide the historical progression of recorded metric values throughout the observation period; an example is shown in Supplementary File S12. The charts display the facility’s vehicle parking activity, including the overall occupancy rate, turnover rate, occupancy step function, and dwell time distribution.

The occupancy step function graph and occupancy rate reported by the developed system exceeded their anticipated resource utilization limits. The step function reported more than 30 parked vehicles (with 30 available positions), while the occupancy utilization rate exceeded 100%. This discrepancy may result from two potential scenarios: (1) a continuous flow of vehicles moving through the facility in search of available parking spaces, (2) the inaccurate reporting of vehicle exits. Hardware limitations prevent the system’s inability to profile departing vehicles accurately. Having a low FPS capture capability brings forth motion distortion caused by high-speed vehicles during departure and exit, as shown in Figure 10.

Consequently, the system incorrectly assumes that the vehicles are still present for cars successfully profiled during entry but not during exit. As a result, the feature system encounters difficulty in capturing the corresponding departures despite the high volume of vehicle entries. The dwell time distribution suggests that approximately 25 vehicles remained in the facility for 5 to 6 h. This indicates that many of these vehicles likely exited without being profiled, potentially impacting the integrity of the system’s reported metrics, such as the revenue, average parking duration, and turnover rate.

7. Design and Implementation Challenges for the System

The feature systems developed in this study are entirely functional and effectively achieve their intended functional design. In conjunction with the SM and DTM, the digital twinning mechanism effectively replicates dynamic changes from the video broadcast on the 3D BIM DT model and the data dashboard. Nevertheless, errors in the data persist even though the I2M system effectively executes the relevant algorithms and conducts its intended intercommunication tasks with other modules. Two primary factors are responsible for these system discrepancies: the hardware limitations and the misalignment between the current facility operations and the optimal conditions necessary for AI-driven operational automation. During the design, development, and testing of the proposed SPMS, the following factors were encountered, resulting in three primary issues: (1) low-FPS hardware combined with barrierless VP, which prevented the cameras from capturing clear license plate images by allowing vehicles to pass without obstruction; (2) camera placement that exposed the system to intense sunlight glare, making license plates unreadable; (3) the inaccuracy of LPR inference due to the movement of people obstructing vehicle license plates, which impacted the POD algorithms. All of these contribute to the performance and reliability of the system, along with the challenges the system faces in potential scalability and commercialization.

7.1. Low Camera FPS and Barrierless VP at Entrance and Exit Driveways

A data disparity was revealed by the facility’s occupancy measurements, which showed that over 30 vehicles were using a parking lot that could only accommodate 30 vehicles. The natural consequence of this was that parking occupancy rates soared over 100%. As previously mentioned in previous sections, the reasons for the erroneous presentation of data in the DTM data dashboard are influenced by limitations in the system’s current hardware configuration, along with the absence of dedicated infrastructure equipment designed to maximize the added value brought forth by the newly designed LPR parking entry and exit monitoring feature of the SPMS. The camera’s 30 FPS frame rate capture specification restricts its ability to capture sharp images of fast-moving vehicles, resulting in motion blur that renders consistent LPR-based VP nearly impossible, especially when vehicles continue to enter and exit the parking facility at high speeds. Such a limitation poses challenges for the system, which relies on precise LPR readings to accurately log vehicle entries and exits.

The system could overcome some hardware constraints by adding gate barriers that compel vehicles to pause momentarily. For instance, setting gate barriers at entry and exit points would minimize motion distortion and enable more accurate VP regardless of the camera’s frame rate. There are currently no gate barriers in the facility, so vehicles leave without stopping for a clear capture, resulting in incomplete or unsuccessful LPR readings. This can inflate the occupancy statistics and increase the errors in real-time occupancy data. Alternatively, purchasing cameras with a higher frame rate could improve the quality of the images captured by fast-moving vehicles. However, the system design and continuing maintenance costs would rise if cameras with better technical specifications were upgraded. Installing barriers and speed bumps may present a better economic advantage. They are generally cheaper and are a practical solution that will compel drivers to slow down during entry and exit, enabling the system to capture clear, unblurred license plates and obtain precise LPR readings.

7.2. Sunlight Glare and Camera Placement for LPR-Based POD Algorithm Feature

On the ground floor of the building complex, the parking facility that is being moniotred for the LPR-based POD system is exposed to natural sunlight. The surface of the license plates, which are frequently quite bright during the daytime and in fair weather conditions, reflects the extreme sunlight glare caused by light exposure. Because of the optical occlusions induced by such glare, the I2M’s trained DTR model has trouble in performing LPR readings reliably. Examples of situations where the system’s performance is impacted by severe sunlight are shown in Figure 11.

7.3. Inaccuracy of Output LPR-Based POD Data Due to License Plate Occlusions

There are instances in the data dashboard where the parking occupancy data suggest that several parking space turnovers have occurred in between short periods. This is partly characterized by rapid consequential turnovers in the turnover graph and short-lived occupancy duration in the step function graph for individual parking slots. This is especially true when analyzing processed data from the LPR-based POD data feature system. When the system designers cross-checked the raw video footage, it was discovered that despite only one vehicle occupying the parking space for an extended period, it was recorded that the exact vehicle had entered and exited the parking space in multiple successions. An account of the events is shown in Supplementary File S13.

The investigation revealed that pedestrians briefly block license plates while walking past cars, leading to flawed recorded turnovers. The LPR-based POD system incorrectly perceives a pedestrian passing by as the vehicle leaving when this action momentarily obscures the license plate. The system records the exact vehicle as re-entering the space once the person moves, making the license plate visible again.

A more reliable way to address this problem would be to switch from an occupancy model that relies on LPR to one based on VD. More reliable occupancy detection is ensured since, unlike license plates, the vehicle chassis is always visible, even when a person is walking in front of it. In this alternative method, VD would verify that a parking space is occupied. LPR would be a conditional process that is only utilized to profile a parked vehicle when it is initially detected in a new parking space. This system adjustment could preserve the LPR function for precise VP while removing mistakes caused by fleeting license plate occlusions.

The placement of the camera is another problem associated with occlusion. Due to the low camera positioning, the system may lose track of occupancy if pedestrians or passing cars block the view of parked cars. The passing people and vehicles would still cause errors any time the view of the parked car is obscured, even if the system were to switch to a VD-based POD algorithm. Hence, the best camera placement is necessary to minimize these mistakes. To guarantee an unhindered field of view and reduce the possibility of visual access being blocked by passing objects or people, cameras should be installed at higher elevations near the ceiling.

7.4. System Scalability Challenges

The 3D BIM model cannot comprehensively monitor all vehicle activity and parking occupancy changes due to the limited camera coverage and insufficient high-performance computational resources. This study has presented a framework for integrating a BIM model into an SPMS, demonstrating the feasibility of incorporating digital twinning technology in smart parking facilities through a proof-of-concept prototype. As observed, its performance and reliability are limited to regulated settings where the actions of vehicles, drivers, and pedestrians are predictable. In practical deployment settings, uncontrolled variables introduce noise into the system’s data stream, diminishing accuracy and complicating scalability intentions. Commercial parking facilities introduce additional complexities that necessitate specific design considerations beyond those applicable to controlled environments. Addressing scalability challenges is imperative and crucial, as such systems aim to increase business value.

Commercial parking facilities differ from controlled environments due to their design and complicated management operations, including but not limited to multiple entry and exit points, varied parking orientations, and multi-level structures. The variability in foot traffic, inconsistent vehicle movements, facility-specific operational policies, and diverse customer behaviors complicate the understanding of how the system should work. Moreover, technical challenges such as variable vehicle flows, physical obstructions, inconsistent lighting conditions, and regulatory constraints impede the accuracy of system modeling. Improving monitoring capabilities necessitates a comprehensive camera network throughout the facility and a strategic placement method to enhance visibility and inference accuracy in the presence of pedestrian and vehicle occlusion interferences. Optimal camera placement is crucial for achieving high-quality visual inputs in machine vision models that facilitate OD and tracking. In addition to hardware factors, computational optimizations significantly enhance system responsiveness and reliability.

Integrating multiprocessing techniques in intelligent systems improves real-time inference by allowing the simultaneous processing of multiple camera streams and image-based occupancy detection tasks. Conventional sequential processing techniques frequently result in latency during vehicle movement analysis, causing delays in decision-making. Multiprocessing enhances computational efficiency by distributing tasks across multiple CPU cores, significantly decreasing the processing time for VD, LPR, and space occupancy assessment. This is advantageous in commercial parking settings, where extensive monitoring requires ongoing data collection from various sources. Multiprocessing enhances load balancing across different image processing tasks, ensuring optimal computational resource utilization. The system achieves real-time responsiveness under high-demand conditions by concurrently executing occupancy detection, vehicle tracking, and anomaly identification. Process synchronization and data sharing protocols mitigate errors in concurrent execution while ensuring consistency in identified occupancy states. Multiprocessing offers practical advantages such as enhanced system scalability, accommodating growing data volumes through additional processing cores, and improved operational efficiency by reducing inference delays [78].

In addition to computational optimizations, system reliability is contingent upon addressing environmental factors that influence model performance. Lighting inconsistencies can be mitigated through the installation of supplementary lighting to achieve uniform illumination, the augmentation of datasets with diverse lighting conditions, and the application of image processing techniques to improve visibility before inferencing [35]. These optimizations enhance the DT’s capacity for accurate occupancy monitoring, facilitating informed decision-making and management operations in practical applications.

A cost–benefit analysis for this study is also presented in Supplementary File S14 to help guide cost decisions in scaling the proposed implementation.

8. Conclusions and Recommendations

This study presented an SPMS development framework that used machine vision, machine learning, and digital twinning to dynamically model vehicle parking activity within a parking facility. Using YOLOv7 for vehicles and LPD, and DTR for LPR, the system was able to demonstrate a reliable modeling performance under varying situations, demonstrating the promise of DTs in merging facility surveillance with modern data analytics. The developed enterprise-wide 3D BIM DT model in Autodesk Revit offers a visually intuitive data-driven viewing interface that informs users of parking activity in each parking facility. As the developed model was in 3D, viewers of the model need not mentally interpret and correlate 2D-style information into a 3D spatial understanding. The DT model is built in a geometrically similar way to the built environment, thus allowing for information to be intuitively understood, potentially improving the parking management decision-making processes for parking facility managers and serving as a baseline model for comparable deployments in future smart city initiatives involving intelligent systems and parking management. A summary of the key performance metrics of the developed system and its capabilities are provided in

Table 8. Feature performance summary for the developed SPMS.

System Feature		Feature Capability	Performance Metric
1	VD-based POD 3D DT SPMS	Vehicle OD (mAP50 = 94.86%)	94.86%
2	LPR-based POD 3D DT SPMS	LPD (mAP50 = 99.27%)	89.84%
		DTR-based LPR (Accuracy = 90.50%)
3	LPR-based Data Dashboard DT	LPD (mAP50 = 99.27%)	89.84%
		DTR-based LPR (Accuracy = 90.50%)
		Capacity to Compute for: Total Fare, Total Revenue, Parking Duration, Occupancy Rate, Turnover Rate, Peak Occupancy Periods, Dwell Time Distributions

.

A critical insight into deploying new technologies in operational settings is the need for reciprocal flexibility between the technology introduced and its operating environment. Integrating new technologies should not disrupt existing workflows or compromise the current level of operational stability and efficiency. Rather, facilities should be flexible by adjusting their processes to allow for the optimal functioning of newly integrated technologies. To optimize the added value of SPMSs, it is critical to create conditions conducive to guaranteed reliable outputs, such as fair and ambient lighting conditions for LPR and an optimal camera location for occlusion problems. Adjustments such as installing speed bumps or gate barriers to facilitate vehicle stops and clear license plate capture will improve the system metrics and enable a smooth integration with present operations.

Alternative digital twinning systems such as Unity, which provide more flexibility and long-term support, should be investigated in future studies. Unity is a preferred alternative platform for 3D environment BIM models because of its backward compatibility feature. Unlike the Autodesk Revit 23.1.80.30 software, which will eventually lose developer support for old software versions, Unity Engine will continue to enjoy continuous developer support from Unity. Thus, BIM developers need not worry about backward compatibility issues that may arise in the future. Furthermore, expanding 3D BIM modeling beyond parking management to other facility and infrastructure domains, such as building energy management, manufacturing process optimization, centralized airflow systems, and predictive maintenance, could demonstrate BIM technology’s versatility and scalability in various applications. Integrating BIM into these areas increases the ability to maintain optimum conditions for facility operations, giving meaningful insights and improving decision-making in various settings. To increase system robustness in various settings, better OD and STR models can be explored. Incorporating powerful computing tools, such as edge computing devices and cloud computing, can also guarantee system health and avoid performance throttling, guaranteeing that the parking management system will continue to be dependable and expandable as it develops.