Iot-based intelligent parking space real-time monitoring and scheduling method and system

Abstract

The present application relates to the technical field of traffic management and Internet of Things technology, and more particularly to a real-time monitoring and scheduling method and system for intelligent parking spaces based on Internet of Things, which comprises: denoising, time correction and blockchain registration of multi-source sensor data to form traceable parking space and road load information. A three-dimensional digital twin environment is generated with the help of neural radiation field, and the floors and sensors are hierarchically associated through fractal hypergraph, and the floor capacity and cross-layer channel are recorded in the quantum approximate optimization algorithm. Under the guidance of the output scheduling strategy, the parking demand is dynamically received in combination with the Internet of Things platform, and if the floor is insufficient, the queuing information is established and the allocation and queuing records are continuously updated in combination with real-time sensing. After the vehicle leaves, the actual occupancy data is compared with the expected data, and the three-dimensional twin model and quantum algorithm parameters are automatically corrected and written into the blockchain. The present application realizes precise scheduling in multiple floors and multiple scenes, effectively reduces congestion and improves parking turnover rate.

Description

Technical Field

[0001] The present invention relates to the field of the integration of traffic management and Internet of Things technologies, and in particular to a method and system for real-time monitoring and scheduling of smart parking spaces based on the Internet of Things. Background Art

[0002] With the continuous growth of urban traffic volume and vehicle numbers, achieving efficient parking space management and real-time scheduling has become a critical issue for urban smart transportation. While existing technologies can centrally manage multiple parking lots (Chinese invention patent application, publication number: CN117133144A, title: A Smart City Parking Space Prediction Method and System Based on the Internet of Things), they generally suffer from the following shortcomings: First, some solutions can only schedule parking spaces based on the current vacancy status of a single parking lot and lack the ability to deeply predict historical data by time period. Second, most solutions lack cross-lot or multi-floor linkage mechanisms when parking lots are full, resulting in vehicles queuing and congesting at the entrance of the target lot. Furthermore, there is a lack of effective filtering and trustworthy endorsement of abnormal or faulty sensor data, which can easily affect subsequent scheduling decisions. These shortcomings make parking space information management unable to fully meet the needs of city-level traffic diversion and peak shifting, making it difficult to ensure parking efficiency and traffic flow in large-scale applications. Summary of the Invention

[0003] To address the numerous issues with the aforementioned existing technologies, the present invention provides a real-time monitoring and scheduling method and system for intelligent parking spaces based on the Internet of Things (IoT). This system utilizes the IoT and blockchain to record parking space and road occupancy information, then constructs a three-dimensional digital twin model and fractal hypergraph to represent the relationships between multiple floors, multiple sites, and their sensor nodes. Finally, comprehensive scheduling is performed using quantum approximate optimization. Through this closed-loop process, the system dynamically adjusts parking space allocation, cross-floor guidance, and queuing mechanisms in real time, continuously updating model and algorithm parameters. This approach can significantly improve parking space utilization during peak hours, alleviate traffic congestion, and enhance the user parking experience.

[0004] A real-time monitoring and scheduling method for smart parking spaces based on the Internet of Things includes the following steps:

[0005] Obtain parking space occupancy data and road flow data, perform denoising and time coordinate alignment on the parking space occupancy data and road flow data, and write them into the blockchain to form trusted data after completion;

[0006] A three-dimensional digital twin environment is constructed based on the trusted data. A three-dimensional model of the parking lot and road is generated using a neural radiation field. A fractal hypergraph is used to represent the hierarchical association between the floor structure and the sensor nodes. The fractal hypergraph is mapped to a quantum approximate optimization algorithm to obtain scheduling strategy data.

[0007] Receive user parking requests, allocate parking spaces and generate navigation routes based on the scheduling policy data, establish queuing information if there are no vacant parking spaces on the target floor, and dynamically update the user's parking reservation information or queuing information based on the trusted data;

[0008] The arriving vehicles are identified and their occupancy is verified, and actual occupancy data and departure data are generated when they leave the site. The actual occupancy data and departure data are compared with the scheduling strategy data, and then the parameters of the three-dimensional digital twin environment and quantum approximate optimization algorithm are updated.

[0009] Preferably, in the process of acquiring parking space occupancy data and road traffic data and performing denoising and time coordinate alignment processing, by marking each piece of data with a timestamp and geographic location identifier, sensor data with continuous value jumps and exceeding a fixed threshold are eliminated, and the verified data are packaged into a trusted input and written into the blockchain.

[0010] Preferably, when constructing a three-dimensional digital twin environment based on the trusted data, multi-view images are used to sample the parking lot area, and a neural radiation field is used to generate a three-dimensional rendering result of the connection between the floor structure and the road, and the floor position reflected in the rendering result is mapped to the sensor coordinate information.

[0011] Preferably, in the step of hierarchically associating the floor structure and the sensor nodes through a fractal hypergraph, a first-level hyperedge is established for each floor to include the coordinate information of all sensors and parking spaces on that floor, and a cross-floor hyperedge is created based on the physical connection between the floors to characterize the path that the vehicle can travel across floors. The cross-floor hyperedge carries a hash index corresponding to the sensor trusted identifier registered on the blockchain.

[0012] Preferably, in the step of mapping the fractal hypergraph to a quantum approximate optimization algorithm and obtaining scheduling strategy data, the connectivity relationship between floors and the parking space remaining information are extracted as quantum bit constraints, and the sensor credibility level is incorporated into the objective function of quantum annealing or hierarchical quantum circuits. After generating preliminary scheduling results, the floors where low-credibility sensors are located are corrected in combination with multi-agent collaboration to finally form the scheduling strategy data.

[0013] Preferably, when receiving a user's parking demand, the target floor is determined by retrieving the number of available parking spaces on each floor in the scheduling strategy data and the vehicle queue length information provided by the road side unit, and a navigation route is generated based on the floor entrance coordinates rendered by the neural radiation field.

[0014] Preferably, if there are no vacant parking spaces on the target floor, queue information is established, and the queue sequence is sorted in order based on the estimated departure time of each parking space in the trusted data. Whenever a vehicle leaves, the number of parking spaces on the corresponding floor is increased and the first user in the queue sequence is notified. After the user's waiting time exceeds the preset time limit, his or her queue space is released and the user's timeout record is updated on the blockchain.

[0015] Preferably, when identifying and verifying the occupancy of the arriving vehicle, the license plate recognition or the identifier generated by the user's mobile terminal is compared with the scheduling strategy data and the parking space reservation information registered in the blockchain. If a match is successful, the vehicle is bound to the parking space on that floor and the entry time is recorded. If there is no match, the parking space is reallocated according to the floor's remaining capacity or the user is asked to continue queuing.

[0016] Preferably, after the actual occupancy data and departure data are generated when leaving the site, the difference between the actual parking time of the vehicle and the expected parking interval output by the quantum approximate optimization algorithm in the scheduling strategy data is calculated, and based on the difference, the floor capacity and sensor trust level parameters in the neural radiation field model and the fractal hypergraph are updated, and the updated results are rewritten into the blockchain for subsequent scheduling reference.

[0017] A smart parking space real-time monitoring and scheduling system based on the Internet of Things is used to implement the smart parking space real-time monitoring and scheduling method based on the Internet of Things. The system includes:

[0018] A data processing module is used to obtain parking space occupancy data and road flow data, perform denoising and time coordinate alignment on the parking space occupancy data and road flow data, and register the processed trusted data into the blockchain;

[0019] A three-dimensional environment module is used to build a three-dimensional digital twin environment based on the trusted data, generate a three-dimensional model of the parking lot and road using a neural radiation field, and represent the floor structure and sensor nodes in a hierarchical manner through a fractal hypergraph. The fractal hypergraph is mapped to a quantum approximate optimization algorithm to obtain scheduling strategy data;

[0020] A demand allocation module is used to receive user parking requests, allocate parking spaces and generate navigation routes based on the scheduling policy data, establish queue information if there are no vacant parking spaces on the target floor, and dynamically update the user's parking space reservation information or queue information based on the trusted data;

[0021] The vehicle verification module is used to identify and verify the occupancy of arriving vehicles, and generate actual occupancy data and departure data when the vehicle leaves the site. After comparing the actual occupancy data and departure data with the scheduling strategy data, the parameters of the three-dimensional digital twin environment and quantum approximate optimization algorithm are updated.

[0022] Compared with the prior art, the advantages and beneficial effects of the present invention are:

[0023] The present invention uses the Internet of Things platform and blockchain trusted management technology to achieve complete verification and tamper-proof registration of sensor data, thereby reducing the interference of faults or false readings on scheduling.

[0024] The present invention achieves three-dimensional parking space management across floors and regions through three-dimensional digital twins and fractal hypergraph technology, enabling more flexible multi-floor or multi-field coordinated scheduling during congestion.

[0025] The present invention uses quantum approximate optimization technology to achieve a global cross-layer vehicle allocation effect under multiple constraints, that is, it can quickly provide users with suitable parking spaces or queuing solutions even during peak hours. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 Schematic diagram of the process of the present invention;

[0027] Figure 2 It is a structural block diagram of the system of the present invention. DETAILED DESCRIPTION

[0028] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0029] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise," "include," etc. used herein indicate the presence of the features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0030] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0031] like Figure 1 As shown, a real-time monitoring and scheduling method for smart parking spaces based on the Internet of Things includes the following steps:

[0032] Obtain parking space occupancy data and road flow data, perform denoising and time coordinate alignment on the parking space occupancy data and road flow data, and write them into the blockchain to form trusted data after completion;

[0033] In this solution, geomagnetic sensors, cameras, and other monitoring devices are deployed inside the parking lot and on the surrounding roads. These sensors periodically generate parking occupancy and road traffic data and transmit it to the system backend. Because the sensors are dispersed and have different clocks, the raw data often contains noise and timestamp deviations. To ensure the accuracy of subsequent scheduling or forecasting, this raw data requires de-noising and time-alignment processing in the first step, ensuring that parking spaces and road conditions within the same time period correspond to each other.

[0034] Use threshold detection or sliding averages to filter out unusual jumps. If the value difference between the same sensor values ​​exceeds a preset range within a short period of time, the reading is marked as abnormal and excluded from further processing. For the remaining readings, filtering methods (such as wavelet noise reduction and moving average) can be used to reduce the impact of random jitter on the overall trend.

[0035] Because each sensor has an initial clock offset, it is necessary to recalibrate the timestamp of each record using the system's unified reference time as a reference. The correction formula can be written as:

[0036]

[0037] in is the difference between the sensor and the reference clock. After completing this process, the same batch of data can be analyzed within the same time slice, making the floor parking space occupancy and road traffic appear synchronized.

[0038] Package the denoised and aligned data together with the floor or road segment identifiers into a dataset . Calculate the hash And get the hash value , and then bind it to the unique index of the batch of data.

[0039] Bundle Registered in the blockchain network, it is maintained by multiple nodes. When you need to verify the data later, you only need to compare With blockchain , you can determine whether the data has been tampered with.

[0040] With multi-node consensus storage, even if some nodes fail or data is tampered with, the blockchain network can maintain overall credibility. If disputes arise over queuing or vehicle allocation, the authenticity of the original reading can be verified by tracing back to the corresponding hash index.

[0041] The collection period can be adjusted according to the parking lot and road traffic volume (such as 60 seconds or 120 seconds). When threshold detection, if the difference between any sensor in the two consecutive sampling values exceeds the value , it is considered abnormal. After clicking, the same system time label is marked for all readings, which is convenient for the same batch of occupancy and flow analysis.

[0042] In one embodiment, the collection period is set to 120 seconds, sensor A measures the parking space occupancy value, and sensor B measures the road traffic. If the reading difference between sensor A in the adjacent two sampling is 30, and the agreement , the record is removed.

[0043] After correcting the time stamp of each data, it is packaged as a data set , and the hash is calculated . Finally is written to the blockchain. If you want to confirm the total number of available parking spaces on the floor and the congestion degree of the surrounding road in the future, you can read the blockchain index and check its hash integrity to obtain the corresponding trusted data set.

[0044] The present application reduces the misjudgment of parking space state and road traffic caused by faults or external interference through the above denoising process. Time alignment realizes multi-sensor time synchronization, providing a solid foundation for subsequent scheduling. After writing to the blockchain, any node can prevent unauthorized changes to the data, and the data generation and correction process can also be tracked. If there is a contradiction in the decision-making at a certain time period, you can quickly backtrack to the corresponding hash index and check the original record. In the future, accurate parking information and road load are needed in three-dimensional digital twins, fractal hypergraphs or quantum approximate optimization. The trusted data output in this step can ensure the correctness of the scheduling algorithm and reduce model distortion.

[0045] Preferably, in the process of obtaining parking occupancy data and road traffic data and performing denoising and time coordinate alignment, the sensor data that appears continuous value jump and exceeds the fixed threshold is removed by marking the time stamp and geographic location identifier for each data, and the verified data is packaged to form a trusted input and written to the blockchain.

[0046] In this scheme, the Internet of Things end will provide two types of core data: parking occupancy data and road traffic data. Parking occupancy data is mainly derived from sensors (magnetic inductors, ultrasonic detectors, etc.) built in parking lots, which produce values indicating whether a vehicle is occupied every certain collection period. Road traffic data is generally monitored by road side units or cameras to monitor vehicle throughput, average speed, etc. After collection, these raw data need to be transmitted back to the system background to filter out unreliable readings and ensure time sequence matching.

[0047] A unified system time stamp is added to each sensor output , and performs offset correction on the built-in clock of each sensor. At the same time, the geographical identifier of the sensor, such as the floor or road section, is written into the data to be used later to determine the area to which the reading belongs.

[0048] When performing denoising on sensor output, the key is to identify continuous value jumps: if the difference in readings of the same sensor in adjacent sampling periods is greater than a preset threshold, If this condition persists for multiple consecutive cycles, the sensor is considered abnormal. This abnormality may be caused by hardware failure or strong external interference. Retaining such readings can lead to misjudgments of parking space or road load during dispatch, so they are eliminated through the algorithm.

[0049] After denoising and removing abnormal data, the remaining data is integrated into a data packet in each acquisition cycle .

[0050] The system will record the following information: Timestamp ; Geographical identification (floor number or road section); Sensor ID and its trusted status; The sequence of values ​​that is normally retained after processing.

[0051] In this solution, blockchain is used to ensure the traceability and non-tamperability of data records. Obtain a hash value through a hash function The hash value is then bound to the data packet index and written to the blockchain. Once written to the multi-node network, subsequent queries or audits can verify whether the data has been modified by comparing it with the hash value.

[0052] Subsequent steps in this solution, such as 3D digital twins and quantum approximate optimization, require retrieving this verified and de-noised parking and road data from the blockchain. Because this data is time- and geo-referenced, the system can accurately determine available parking spaces and road traffic conditions on each floor, enabling optimal vehicle allocation and scheduling.

[0053] By using "continuous numerical jumps exceeding a fixed threshold" for elimination, erroneous occupancy readings caused by occasional hardware failures, environmental interference, etc. are greatly reduced, ensuring the stability of subsequent floor parking space calculations or congestion assessments. By aligning the time coordinates, the same timing benchmark is given to the outputs of different sensors, allowing this solution to compare the parking space status and road traffic at the same time in real time, thereby performing coordinated scheduling in the same cycle. After the denoising and elimination operations are completed, the system will package and register the processing results to the blockchain. Multi-node consensus can prevent data from being maliciously tampered with, providing a reliable information source for subsequent parking space allocation or priority queuing. Eliminating abnormal data avoids unreasonable occupancy or traffic anomalies in subsequent three-dimensional digital twins or fractal hypergraph mapping. After time alignment, there is no need to perform complex cross-time interpolation of readings from different sensors, which greatly saves computing resources.

[0054] In one embodiment, it is assumed that 10 geomagnetic sensors are installed in a parking floor (with a collection period of 60 seconds), and the adjacent road-side units also output the vehicle throughput every 60 seconds.

[0055] In one acquisition cycle, if the difference between the readings of a sensor in adjacent cycles exceeds the preset threshold If this happens three times in a row, the sensor is considered faulty and the record is deleted.

[0056] Add a unified system timestamp to the rest of the normal readings ,For example . Integrate these timestamps and location coordinates and package them into a data set , generate hash , write the blockchain index (SlotDataIndex, H).

[0057] Filtering out faulty data prevents subsequent algorithms from mistakenly interpreting a sudden surge in parking spaces on a given floor as a complete occupancy. Multi-node consensus ensures reliable data storage, allowing for rapid verification of record integrity should scheduling operations require tracing the number of parking spaces at that moment. Furthermore, time alignment allows the scheduling engine to compare road traffic volume and parking space availability within the same 60-second period, enabling precise allocation.

[0058] A three-dimensional digital twin environment is constructed based on the trusted data. A three-dimensional model of the parking lot and road is generated using a neural radiation field. A fractal hypergraph is used to represent the hierarchical association between the floor structure and the sensor nodes. The fractal hypergraph is mapped to a quantum approximate optimization algorithm to obtain scheduling strategy data.

[0059] In the initial stages of the solution, trusted data such as parking space occupancy and road traffic volume was obtained through blockchain registration. Sensor location and floor information were de-noised and time-aligned. Building on this foundation, the 3D digital twin environment needed to present parking lot floors, vehicle lanes, and their connections to external roads in a detailed manner.

[0060] Neural Radiance Field (NeRF) can perform implicit function fitting on multi-view images or point cloud data, record the distribution of light and density in three-dimensional coordinates, and then form an integrated volume rendering result. In the IoT scenario, this step relies on image data collected by several cameras or lidars installed inside and outside the parking lot. The system will match these multi-view images with the existing floor geographic coordinates, and fit the spatial contours of each floor, up and down ramps, or elevator entrances and exits and other key structures in the NeRF model. The resulting three-dimensional model can accurately map in digital space which area corresponds to a certain floor, where the access corridor or external road connection point is.

[0061] A 3D digital twin environment only provides the system with information about its external structure and coordinates, which is insufficient for high-level modeling of the three-dimensional relationships between floors and sensors. Therefore, this solution introduces a "fractal hypergraph" to hierarchically describe the distribution of sensors within floors, across floors, and across roads. Each floor is considered a hyperedge (E_l), and each sensor and parking space node within that floor is incorporated into E_l. If there are vertical connections or aisles between floors, corresponding "cross-floor links" are created in the fractal hypergraph, indicating that vehicles can travel from one floor to another.

[0062] Based on the three-dimensional coordinates output by NeRF and the sensor locations registered on the blockchain, each sensor is considered a node (v_i). This node is connected to a floor hyperedge E_l, indicating that sensor v_i belongs to floor l and is responsible for monitoring parking availability or traffic flow within its range. If a sensor monitors a cross-floor area (such as a stairwell or a corridor corner), multiple links can be established between multiple floors in the fractal hypergraph, allowing the system to identify the multi-floor coverage characteristics of the sensor.

[0063] Each node or hyperedge in the fractal hypergraph can have additional attributes, such as floor capacity, sensor credibility (based on the trustworthiness determined by previous denoising), etc. This attribute will affect the constraint weight during subsequent quantum optimization.

[0064] The system must find a globally optimal or near-optimal solution for vehicle scheduling and parking resource allocation: which floor can accommodate how many vehicles, which road sections can handle how much traffic, and how to minimize waiting times and congestion. Quantum approximate optimization algorithms (such as quantum annealing or hierarchical quantum circuits) excel at handling multi-constrained, large-scale feasible domain optimization searches. This solution converts floor capacity, node (sensor) reliability, and channel connectivity information in a fractal hypergraph into quantum bits and coupling coefficients, which are then globally solved by a quantum computing system.

[0065] Assume that the system objective function It is the sum of multiple costs, examples are as follows:

[0066]

[0067] in: and is the weighting coefficient; Indicates the floor number, ; Indicates that quantum search is assigned to the floor the number of vehicles; For floor the maximum capacity or desired vehicle quota; Indicates floor and There is a channel or adjacent relationship between them; Represents the congestion or credibility impact of the channel.

[0068] When quantum algorithms minimize After that, the system can read the vehicle allocation plan from the solution, or obtain the "dispatching strategy data" in the result analysis stage, including the number of vehicles assigned to each floor, recommended channel usage, etc.

[0069] After optimization, the solution generates a set of scheduling policy data, which guides the parking system in assigning vehicles to which floors and under what conditions vehicles are allowed to travel across floors or temporarily enter on external roads. In this solution, if a sensor has low credibility (a high-weight penalty term within the fractal hypergraph), the quantum algorithm tends to avoid using that floor for allocation or require additional manual confirmation in the scheduling policy.

[0070] Preferably, when constructing a three-dimensional digital twin environment based on the trusted data, multi-view images are used to sample the parking lot area, and a neural radiation field is used to generate a three-dimensional rendering result of the connection between the floor structure and the road, and the floor position reflected in the rendering result is mapped to the sensor coordinate information.

[0071] In this solution, several cameras or lidar sensors are typically installed in parking lots and adjacent roadways to capture multi-view images. Sensor readings (such as parking occupancy and road traffic) are previously registered and verified on the blockchain, forming "trusted data" that provides spatial reference and temporal alignment for 3D modeling.

[0072] By capturing images or point clouds at different angles and heights (such as near floor entrances or indoor pillars), multi-view information covering the entire parking lot space can be obtained. These images can be sampled from key locations such as floor tops, ramp slopes, and road intersections, providing diverse viewpoint data for subsequent Neural Radiance Field (NeRF) training.

[0073] Unlike traditional mesh / point cloud reconstruction, NeRF learns the volume density and color of each 3D coordinate by training a multi-layer perceptron (MLP). In this solution, the system feeds the NeRF model with multi-view images of the parking garage floors and roadway areas. Once trained, the model can perform volume rendering from any viewpoint, outputting a 3D representation of the parking garage floor structure and its connections to the external roadway.

[0074] Parking lots often consist of multiple floors (such as underground floors or multi-story parking structures) connected to surface roads or elevated ramps. NeRF fits the differences in multi-view images to identify shapes such as vertical heights between floors, ramps, or curved entrances and exits, generating a three-dimensional volume rendering. Once rendered, the system accurately identifies elements such as the location of each floor, road connection angles, and floor bottom curvature within the 3D digital twin environment.

[0075] This solution uses the sensor coordinates registered in the blockchain (based on the positioning in the previous stage) to compare with the rendering results, and the physical location of the sensor ( Coordinates) are matched one by one with the volume rendering coordinate system of the NeRF model. If the match is successful (i.e. the difference between the two in the three-dimensional coordinates is less than a certain threshold ), it is confirmed that the sensor belongs to a certain floor or road passage.

[0076] During the mapping process, the number of parking spaces or traffic flow information provided by the sensor is also compared to see if it meets the expected range for the corresponding area on that floor (such as the maximum capacity of a floor or road flow restrictions). If the sensor value is seriously inconsistent with the three-dimensional position, the sensor may be marked as low-confidence, and the subsequent scheduling algorithm will downgrade its reading.

[0077] The system can set a coordinate difference threshold ,when Otherwise, it is determined that there is a deviation in the sensor coordinates or a model reconstruction error. For uphill and downhill or curved areas, the NeRF rendering coordinates can be partially relaxed. To allow for greater surface errors.

[0078] Because NeRF renders the parking structure through ray volume rendering, rather than pre-constructing a mesh, it accurately captures the multi-story layout of the parking structure and its connections to external roads (such as corner ramps and turning radii). Compared to traditional simplified models based on CAD drawings, this solution better displays actual wall curvatures or inclined walkways, enabling subsequent scheduling algorithms to make more precise judgments on traffic feasibility.

[0079] Through a 3D alignment process, each sensor coordinate finds its corresponding position in the rendered result, automatically determining whether the sensor belongs to floor A or road section B, significantly simplifying manual labeling. If a sensor physically moves (e.g., temporarily shifts), simply updating the coordinates and re-comparing them to the NeRF model quickly corrects its floor or monitoring area.

[0080] In subsequent fractal hypergraph and quantum optimization, the necessary floor-sensor associations are firmly established through this mapping process. The system can directly reference these associations to construct hyperedges, set floor capacities, or set sensor credibility weights. This allows the system to achieve a global scheduling solution that conforms to real-world spatial conditions during the fractal hypergraph mapping quantum algorithm.

[0081] In one example, a large shopping mall's underground parking lot on the second floor was equipped with approximately ten cameras, covering the entrances to different floors and the junctions with the external road. Several LiDAR cameras were also used to scan the curves of the corridors. The camera angles were combined with point cloud data and fed into a NeRF model for training, generating volume renderings of the underground parking lot and the outdoor ramps.

[0082] After training is completed, the 3D model can show the distribution of each layer and the angle of connection with the ground road. The sensor coordinates pre-recorded in the blockchain Matching with NeRF rendering coordinate system, if sensor A is located at the edge of floor 2, then Much smaller than , the system confirms that sensor A belongs to the corner of floor 2.

[0083] In actual applications, if the coordinate deviation between sensor A and the model exceeds the threshold, the system may mark A as having abnormal positioning; it may also make secondary corrections based on local features (such as fine-tuning A's After the mapping is completed, A is considered a sensor node on floor 2 in the subsequent algorithms, and its readings will affect the determination of available parking spaces or traffic load on floor 2.

[0084] Preferably, in the step of hierarchically associating the floor structure and the sensor nodes through a fractal hypergraph, a first-level hyperedge is established for each floor to include the coordinate information of all sensors and parking spaces on that floor, and a cross-floor hyperedge is created based on the physical connection between the floors to characterize the path that the vehicle can travel across floors. The cross-floor hyperedge carries a hash index corresponding to the sensor trusted identifier registered on the blockchain.

[0085] This solution uses a fractal hypergraph to represent multi-story parking lots and the hierarchical relationships between sensors and parking spaces within them. Unlike conventional graphs, fractal hypergraphs allow hyperedges to be recursively nested at multiple levels, which offers significant advantages for multi-story parking structures. In conventional graphs, nodes represent entities and edges represent connections. However, in a multi-story building, each floor contains several parking spaces, sensors, and possible sub-areas; this complex relationship is difficult to represent simply using a node-edge model. To this end, this solution defines each floor as a first-level hyperedge (E_l), incorporating the sensor nodes and parking space coordinates on the same floor into E_l. This ensures that all elements within a floor (parking space coordinates, sensor locations) are naturally aggregated within the graph structure, facilitating the subsequent retrieval of overall properties of a "floor" (such as the total number of parking spaces and failure rate) in algorithms such as quantum optimization.

[0086] Multi-story parking garages often have ramps, elevators, or curved entrances and exits. When vehicles need to move between floors, they connect these passages. Fractal hypergraphs use "cross-floor hyperedges" to represent these passages. In the graph structure, a special hyperedge (E_{l,l+1}) exists between floors E_l and E_{l+1}, recording the passage's capacity, spatial location, and corresponding constraints (such as maximum slope and access control).

[0087] For each floor, the system obtains the plane or three-dimensional coordinates of the parking space from the three-dimensional digital twin environment. In the first-level hyperedge E_l of the fractal hypergraph, these parking spaces are recorded in the form of nodes or attached attributes so that the parking space capacity of a certain floor can be allocated in subsequent scheduling.

[0088] In this solution, the sensors have already been verified for reliability in the previous steps, and the corresponding hash indexes have been registered on the blockchain. Within the fractal hypergraph, these sensors are also nodes (n_i) and "mounted" on the corresponding floor E_l. This method allows for rapid determination of the number of sensor nodes on a given floor and which sensors are affected by faults or reduced reliability.

[0089] When a sensor node n_i has a blockchain-registered hash index H_i (used to trace sensor data), n_i is annotated with this value H_i in the fractal hypergraph. If certain cross-floor channels or nodes also require trusted information (such as gate access status recorded on the blockchain), this hash index can also be added to the corresponding hyperedge (E_{l,l+1}) to indicate its trustworthiness level.

[0090] When a vehicle needs to move from floor l to floor l+1, it needs to rely on the corresponding ramp or elevator passage. In the fractal hypergraph, the core attributes of this passage, such as the vehicle flow capacity, the coordinates or the entrance and exit information at the intersection with the floor structure, are described by the cross-floor hyperedge (E_{l,l+1}). When the vehicle scheduling needs to determine which floor can accept more vehicles or needs to disperse the flow in adjacent floors, the connectivity and congestion of (E_{l,l+1}) can be queried.

[0091] The blockchain hash index is written into the cross-floor hyperedge (E_{l,l+1}) to facilitate the query of related trust, sensor state, etc. in subsequent quantum approximate optimization or fault detection. For example, when there is a sensor on the ramp to monitor the vehicle passing speed, the sensor hash index can be bound to (E_{l,l+1}) so that the scheduling algorithm can refer to the most reliable sensor reading when judging the flow constraint.

[0092] By setting each floor as a first-level hyperedge (E_l), all parking spaces and sensor nodes on the floor are explicitly aggregated in the graph structure, which facilitates the quantum or other scheduling algorithms to quickly obtain information such as "total capacity of the floor" and "monitoring failure rate". The cross-floor hyperedge represents the vehicle passable passage, so that the multi-floor parking scheduling has integrity and can automatically identify the best cross-layer path or guide the vehicle to the adjacent floor when a certain floor is full.

[0093] Because the sensor nodes or passage are all carrying blockchain hash indexes in the fractal hypergraph, if the hash recorded by a sensor is abnormal or marked as low trust, the related node will be given a higher penalty weight or be excluded from the priority, so that the scheduling algorithm avoids relying on suspicious floors or passages. This improves the robustness of the system to abnormal sensor data and ensures the safety and traceability of global scheduling.

[0094] In the fractal hypergraph, the floor capacity, cross-layer connection, and sensor trust are clearly expressed in the same structure. When the quantum algorithm is mapped, the capacity of each floor hyperedge (E_l) and the connectivity parameters of the cross-layer hyperedge (E_{l,l+1}) can be converted into quantum bits or coupling coefficients to form a set of Hamiltonian constraints that can be solved in quantum annealing or hierarchical circuits, and finally output the scheduling strategy data.

[0095] In one embodiment, a three-story underground parking lot in a shopping mall has a number of parking spaces and a number of sensors (magnetic or camera) on each floor; the floors are connected by ramps; and all sensor trust information has been written into the blockchain.

[0096] Define the hyperedge E_1 for floor 1, which contains the node set {Sensor A, Sensor B, Parking Space 1, Parking Space 2,...}. Similarly, establish E_2 and E_3. If floor 1 has parking space coordinates (x1, y1), (x2, y2), etc., and sensor coordinates (x3, y3), (x4, y4), etc., the hyperedge E_1 can be expressed as: , ...), the system records it in the E_1 attribute; if sensor A corresponds to the hash index H_A, then H_A is stored at node A.

[0097] For the ramp connecting floors 1 and 2, we create E_{1,2}, which contains information about the maximum traffic volume, slope, and other parameters, along with the hash index H_C of several sensors (such as ramp monitor C). If floors 2 and 3 are also connected in the same way, we create E_{2,3} in the hypergraph.

[0098] When the subsequent scheduling algorithm runs quantum approximate optimization, it scans the floor information of E_1, E_2, and E_3 to determine the available parking spaces on each floor. It then uses the connectivity or credibility of E_{1,2} and E_{2,3} to determine how vehicles are allocated across floors. If a sensor C is detected as faulty, the system dynamically lowers the priority of E_{1,2} during scheduling.

[0099] Preferably, in the step of mapping the fractal hypergraph to a quantum approximate optimization algorithm and obtaining scheduling strategy data, the connectivity relationship between floors and the parking space remaining information are extracted as quantum bit constraints, and the sensor credibility level is incorporated into the objective function of quantum annealing or hierarchical quantum circuits. After generating preliminary scheduling results, the floors where low-credibility sensors are located are corrected in combination with multi-agent collaboration to finally form the scheduling strategy data.

[0100] In the previous steps, floors and sensor nodes are represented as a fractal hypergraph. Each floor forms a first-level hyperedge (E_l), which carries information such as parking space coordinates and available parking spaces. If there are ramps connecting floors, a cross-floor hyperedge (E_{l,l+1}) is established in the hypergraph. Furthermore, each sensor node has a blockchain-registered credibility identifier or hash index to indicate the reliability of its readings.

[0101] Quantum approximate optimization algorithms (such as quantum annealing or hierarchical quantum circuits) can search for global approximate optimal solutions under high-dimensional constraints. Here, this solution converts inter-floor connectivity and parking space availability information into quantum bits or coupling coefficient constraints:

[0102] Floor capacity: If the floor The maximum number of parking spaces is , then the corresponding constraints can be set in the quantum model to assign Number of vehicles Should not exceed Too much, otherwise there will be additional penalties.

[0103] Cross-floor channel: The hypergraph (E_{l,l+1}) records the floors and These relationships can be expressed as coupling terms in the quantum model to reflect the load effect brought by cross-layer flow.

[0104] Because the system needs to identify suspicious floors or sensor failures during dispatch, the algorithm assigns corresponding weights to sensor confidence levels and incorporates them into the optimization objective. When a key sensor on a floor demonstrates low confidence, this solution assigns a higher penalty or risk factor to that floor. The quantum algorithm, while minimizing global energy, tends to reduce vehicle allocations to that floor or perform more redundant checks.

[0105] When the quantum system traverses all feasible states, it obtains a set of floor allocation results (i.e., preliminary scheduling results) that are approximately globally optimal by minimizing the objective function. These results include the number of vehicles to be assigned to each floor, the probability distribution of cross-floor travel, and the restriction strategy for low-credibility floors.

[0106] This solution does not rely entirely on the "natural solution" output by the quantum algorithm. Instead, it corrects suspicious floors through multi-agent decision-making (such as floor management agents or a unified collaborative dispatch center). If the quantum algorithm assigns too many vehicles to a low-credibility floor, the number of vehicles can be appropriately reduced through agent voting or collaborative strategies. If the actual sensor credibility of the floor temporarily returns to normal, the number of vehicles that can be assigned can be increased to ensure scheduling flexibility.

[0107] After the multi-agent correction is complete, the system outputs the final dispatch strategy data. This data includes: the upper limit of vehicle capacity allocation for each floor; the availability of inter-floor channels; and special rules set for low-credibility floors or sensors (such as manual confirmation or flow control).

[0108] Since fractal hypergraphs can easily represent complex channel relationships between multiple floors, and quantum approximate optimization can perform parallel searches under high-dimensional constraints, the combination of the two enables the system to find approximately optimal scheduling solutions in a relatively short period of time, thereby avoiding long-term congestion of vehicles on the same floor or at the same entrance and exit.

[0109] By incorporating sensor credibility into the objective function, if a critical sensor on a floor is detected as faulty, the algorithm automatically imposes a higher energy penalty on that floor, directing allocation to other floors. If the sensor failure is recovered, the floor can be reopened to a reasonable quota through multi-agent correction.

[0110] Because all sensor nodes and their trusted identifiers are registered on the blockchain, any scheduling decision can be traced back to the time, location, and hash index of the corresponding sensor reading. The system retains corresponding logs during quantum algorithms and multi-agent collaborative corrections, facilitating later audits or analysis in the event of scheduling disputes.

[0111] In one example, a city commercial center has four floors of underground parking, each equipped with approximately ten sensors (such as geomagnetic sensors or cameras), whose credibility has been registered on the blockchain in a previous step. The floors are connected by ramps, and some of the ramp sensors have malfunctioned.

[0112] In a fractal hypergraph, the system constructs E_1, E_2, E_3, and E_4, corresponding to four floors respectively. Each hyperedge contains parking space information and sensor nodes. Cross-floor hyperedges (E_{1,2}, E_{2,3}, and E_{3,4}) store ramp capacity and sensor failure hashes. This hypergraph is mapped to a quantum approximate optimization algorithm: the objective function is set to penalize over-allocation to faulty floors or aisle congestion.

[0113] The system performs a parallel search for vehicle allocation between floors and may conclude that it is not appropriate to allocate too many vehicles to floor 3 (because the faulty sensor is located on ramp 3) and direct more vehicles to floors 1 or 2.

[0114] If the Floor 1 management agent determines that its actual occupancy is lower than the algorithm's estimate, it can make a partial correction in the scheduling policy data, increasing the quota for Floor 1 and reducing the inflow for Floor 3. Ultimately, the final version of the scheduling policy data is generated, recording specific actions such as "opening more parking spaces on Floor 1, partially closing Floor 3 or requiring manual confirmation."

[0115] If the fault is not completely eliminated, floor 3 will be downgraded and vehicles will be diverted to floors 1 or 2, reducing queues and congestion. Once the fault is resolved, the multi-agent system will trigger a lightweight quantum solution, and the next scheduling cycle will restore the floor 3 quota.

[0116] Receive user parking requests, allocate parking spaces and generate navigation routes based on the scheduling policy data, establish queuing information if there are no vacant parking spaces on the target floor, and dynamically update the user's parking reservation information or queuing information based on the trusted data;

[0117] In this solution, a set of "scheduling policy data" has been generated in previous steps using a 3D digital twin environment, fractal hypergraphs, and quantum approximate optimization algorithms. This data includes information such as capacity allocation for each floor, sensor credibility constraints, and vehicle cross-floor movement rules. When a user requests parking, the system first consults this scheduling policy to determine parking space allocation and driving routes.

[0118] The user enters a parking request (including location, vehicle type, etc.) into the vehicle terminal or mobile app. The system then uses the scheduling policy data to identify the appropriate floor and available parking spaces for the vehicle. If the scheduling policy indicates that there is remaining capacity on the target floor, the system immediately generates a reserved parking space. Otherwise, the system checks adjacent resources or queue information on the floor for further processing.

[0119] All parking space occupancy readings, road traffic flow, and other information are registered on the blockchain (trusted data). When allocating parking spaces or adjusting navigation, the system will determine the allocation priority based on the latest sensor credibility or the change in remaining capacity on each floor.

[0120] If the scheduling strategy data shows that there are a number of vacancies on a certain floor Vehicles can continue to be accepted, and the system will assign one or more spare parking spaces on that floor to the user (usually one is locked in the app). After the allocation is successful, a driving route within the floor will be generated for the user to ensure that the user can reach the designated parking space in the shortest possible time after entering the parking lot.

[0121] In multi-story parking lots or complex structures with connecting ramps, the system extracts floor coordinates and ramp directions from the 3D digital twin environment. Combined with channel availability recorded through quantum approximate optimization, it calculates a feasible and minimally congested driving path. The system then sends this path to the user's in-vehicle terminal or mobile device, allowing the user to follow it to the desired floor and parking space.

[0122] If the target floor is full, or a limit is set for that floor in the scheduling strategy, the system will create a queue for the user. This information has the following characteristics in this solution:

[0123] In the data structure, users are registered with metadata such as their desired floor and application time, and are assigned a queue number based on their previous queue sequence. When a parking space becomes available on that floor (via trusted data to detect vehicle departure), the system notifies the first user in the queue that they can enter. If a user does not respond within a certain time limit, they can be removed from the queue or postponed.

[0124] Changes in parking spaces on a floor and sensor status updates can affect queue priority and entry timing. For example, if a sensor malfunction causes inaccurate space recording on a floor, a warning will be generated in the system and parking will be temporarily delayed for queued users. Once detection accuracy is restored or a space becomes available on the floor, the queue can be "promoted" to allow the next waiting vehicle to enter.

[0125] When a user secures a parking space or obtains floor approval, the system creates a "parking reservation" and stores its hash value on the blockchain to prevent tampering. If the user cancels or arrives late, the system marks the reservation as invalid and releases the space to another user in the queue. If the sensor data is unreliable upon arrival or a new backlog of vehicles has appeared on the floor, the system automatically reallocates the space based on the scheduling policy data and searches for a feasible floor.

[0126] The system periodically polls the queue or triggers immediately when a parking space is vacant. If a parking space is found to be vacant and there are no faults, the user at the head of the queue is notified to proceed to a designated floor. If a user fails to respond after a predetermined waiting time, the system removes them from the queue or repositions them to the end. All actions are recorded on the blockchain for traceability and auditability.

[0127] Through parking space allocation and navigation route generation, users can determine their target floor and specific parking space location before entering the parking lot, eliminating the need to repeatedly search within the lot. If the target floor is full, the system automatically creates a queue record, allowing users to clearly understand their current waiting status and estimated waiting time, reducing congestion caused by blind entry.

[0128] In multi-story parking lots, the system uses a scheduling strategy generated by a quantum algorithm to distribute users to available floors or remind them to wait in line, maximizing the use of space resources. If a sensor anomaly occurs, reliance on that floor can be reduced promptly, preventing worsening congestion or wasting resources.

[0129] Because this solution relies entirely on trusted data registered on the blockchain, parking space and queue information can be automatically updated based on real-time occupancy records, dynamically reflecting the load and sensor status of each parking lot floor. If a user exits the queue or temporarily cancels a reservation, the system can immediately release resources to facilitate the allocation of parking spaces for other vehicles.

[0130] Preferably, when receiving a user's parking demand, the target floor is determined by retrieving the number of available parking spaces on each floor in the scheduling strategy data and the vehicle queue length information provided by the road side unit, and a navigation route is generated based on the floor entrance coordinates rendered by the neural radiation field.

[0131] In the previous solution step, the quantum approximate optimization algorithm has output a "scheduling strategy data" that records the number of allocable parking spaces, cross-layer channel restrictions, and corresponding sensor credibility factors for each floor. After receiving the user's parking request, the system will first read this scheduling strategy data to determine the current allocable parking spaces on each floor ( ) or margin ( )'s latest records.

[0132] System query floor Number of available parking spaces ;like If it is greater than a certain threshold, then the floor More vehicles can be accepted, otherwise the system will consider other floors or queuing mechanisms. The remaining information of all floors is combined with the quantum algorithm scheduling results through periodic sensor updates to ensure that the remaining capacity of each floor remains relatively accurate within the scheduling strategy data.

[0133] In the IoT environment, the roadside unit can collect vehicle queue length, average speed and other indicators in real time ( If the queue at a certain section is too long, the system may suggest that the user enter from a relatively empty floor with less traffic or from another intersection.

[0134] The system will compare all floor margins in the "Dispatching Strategy Data" ( ) and the queue information sent back by the road side unit ( ), select the most suitable floor For example, if the floor There are still enough seats available and the queue for the road segment leading to that floor is short ( The value is smaller), the system will give priority to allocating floors ; If the remaining capacity on all floors is low, the queuing mechanism will be further triggered.

[0135] The system uses Neural Radiance Field (NeRF) to model the parking lot in a 3D digital twin environment. For each floor, the entrance area coordinates ( ), such as ramp junctions or flat entrances. The entrance coordinates are extracted from the 3D model and used to generate the starting point or key turning node of the navigation route required by the user terminal, ensuring that the user can accurately locate the floor door / ramp entrance in the actual physical space.

[0136] User terminal (vehicle device or mobile app) uploads user location ( ), the system combines the floor The entrance coordinates ( ) calculates an optimal path. If there are multiple ramps between floors, the system selects the one with the least traffic volume based on the road feasibility or sensor congestion information in the scheduling strategy data.

[0137] Conventional shortest path algorithms (such as Dijkstra) or cross-layer path constraints after quantum approximation optimization can be used to find segmented paths for users in the three-dimensional digital twin coordinate system: from the ground entrance to the floor The entrance coordinates ( ). At the same time, if the road side unit information shows a certain road section queue If the route is too long, the cost weight of the section will be increased in route planning to avoid congestion.

[0138] Through comprehensive judgment of scheduling strategy data and road unit queue information, the system can make real-time choices between multiple floor reserves and road conditions, guiding users to the most idle or most accessible target floor, thereby improving parking resource utilization and user experience. The floor entrance coordinates obtained from the neural radiation field enable navigation instructions to accurately locate the floor entrance ramp position in an indoor environment, preventing users from getting lost or going to the wrong entrance in a multi-story garage. If the system determines that all available floors are close to full, it automatically establishes queue information and combines it with trusted data (parking space departure times recorded in the blockchain or sensor monitoring) to dynamically allow users in the queue to enter in turn to prevent excessive congestion or continuous overflow of floors.

[0139] In one example, a commercial complex has two underground parking floors, one on the first and second floors, and a roadside unit that monitors the length of vehicle queues at the entrance. Assume that the scheduling policy output by quantum approximate optimization indicates that floor 1 can accommodate 30 vehicles and floor 2 can accommodate 50 vehicles.

[0140] When the system query is made, it is found that there are 20 parking spaces remaining on floor 1 (sufficient margin), and the road side unit returns the entrance queue. There are only two cars waiting; the system then assigns user A to floor 1. The entrance coordinates of floor 1 are retrieved from the NeRF rendered 3D model ( ), generate the route for floor 1 and send it to user A’s mobile phone or vehicle terminal.

[0141] At this point, due to the sudden influx of vehicles, the available parking space on Floor 1 has dropped to 0. If another parking space is requested by user B, the system detects that there are no available spaces on Floor 1 and checks the available space on Floor 2 (assuming there are still 15 spaces left). B is then directed to Floor 2. If Floor 2 is also short, a queue is created for B, and the system waits for notification when a space becomes available on Floor 2. This queue status is registered on the blockchain and combined with trusted data reflecting the monitoring results of sensors on Floor 2, allowing for continuous updates of queue priorities.

[0142] User A successfully obtains navigation directly to Floor 1, avoiding trial and error in the basement; User B accepts queuing when Floor 2 cannot be accommodated, and can then wait for a parking space to be vacated by a departing vehicle before being allocated and navigated.

[0143] Preferably, if there are no vacant parking spaces on the target floor, queue information is established, and the queue sequence is sorted in order based on the estimated departure time of each parking space in the trusted data. Whenever a vehicle leaves, the number of parking spaces on the corresponding floor is increased and the first user in the queue sequence is notified. After the user's waiting time exceeds the preset time limit, his or her queue space is released and the user's timeout record is updated on the blockchain.

[0144] In the previous step, if the system is based on the "dispatching strategy data" and the number of available parking spaces on the current floor ( If the target floor is determined to be full, the user cannot be immediately assigned to that floor. To ensure resource utilization and user experience, the system will establish a queue, allowing users to receive the next available parking space after a short wait.

[0145] When the floor margin If the number of cars is 0 or insufficient to accommodate new cars, the system will create a queue on that floor to record the subsequent arrival of users. This process will also register the corresponding queue sequence on the IoT platform to facilitate centralized query by the central management service.

[0146] The estimated departure time for each parking space has been calculated from previous readings (or inferred from the user's reservation information) and registered on the blockchain to ensure trust and immutability. When the system creates a queue, it reads this departure time information to sort or predict it.

[0147] This plan will allocate all the floors to the target floor The user is placed in the queue , and then sort the users in the queue according to the "estimated departure time of each parking space", usually adopting the strategy of "first departure parking space first": if a parking space will be The earlier the value is, the faster the parking space will be available. The system allows users at the head of the queue to get a free parking space as soon as possible, reducing waiting time.

[0148] In this plan, each parking space has an "estimated departure time limit" , indicating a parking space May become available at that moment.

[0149] Queue The user in the queue is recorded with (userID, requestTime, status). The system can match the departure time limits of different parking spaces: if there is enough parking space to accommodate the user at the end of the departure period, the system will immediately notify the user to go there.

[0150] When the trusted data detects that a parking space has been left (confirmed by blockchain or sensor), the system automatically sends the floor margin Add 1 and check Checks whether the first user in the queue meets the requirements. If the first user can be accommodated, a notification is sent and the user's status is changed to "Assigned" in the queue information.

[0151] In IoT applications, if the user waits for longer than the preset time limit, If a user does not arrive or confirm their call, the system will release their queue position, allowing the next user to move forward. This can avoid wasting resources by occupying the head of the queue for too long, and also ensure that users who do not respond after a short wait will not block the queue.

[0152] When the system releases a queue seat, the user's "timeout" event is recorded on the blockchain, with the (userID, timeStamp, reason) recorded and hashed for later auditing and statistics. This record prevents users from repeatedly queuing on different floors to fraudulently claim a seat, and also allows the system to assess their credibility and priority during future scheduling.

[0153] When there are no vacancies on the target floor, the queue management mechanism allows users to wait in an orderly manner, reducing congestion in the lobby or repeated detours at the floor entrance. Once a parking space is released, the system immediately notifies the first user in the queue to enter, improving turnover efficiency. Combined with real-time departure detection information, scheduling can avoid delays such as "seats appearing to be available but not yet being vacant" or "seats being available but not being notified in a timely manner." This also improves the user experience, allowing for relatively accurate estimates of waiting times and boarding opportunities.

[0154] If a user fails to enter the parking lot within the specified time or chooses to give up, the system will immediately release their occupied space and register the timeout record on the blockchain to maintain overall queue fluidity. If the user later applies for parking again, the system can handle it accordingly based on their timeout record and the current parking status.

[0155] In one embodiment, assuming that the remaining space on floor A drops to 0, the new user U needs to queue in queue Q_A. By consulting the estimated departure time limit set of each parking space on floor A, The system predicts that two parking spaces will be released within 30 seconds. Therefore, U can enter the parking lot after waiting in the queue for 30 seconds.

[0156] When it is detected that the owner of one of the parking spaces has left, the system confirms from the trusted data that the parking space status has become available, and the remaining space on floor A is incrementally updated. , and immediately send a notification to allow U to enter to ensure the connection. If U does not respond within the reserved 20 seconds, the system will mark U as timed out and retain the timestamp record of "U" in the blockchain for subsequent audits and to prevent duplicate registration.

[0157] In practice, queue information can be stored in a database and integrated with the blockchain. When the first user in line receives notification, the system reserves their spot for a few seconds or tens of seconds. If they still haven't arrived, the spot is released to the next user. Blockchain registration ensures that all changes are immutable, preventing disputes among multiple parties.

[0158] Preferably, when identifying and verifying the occupancy of the arriving vehicle, the license plate recognition or the identifier generated by the user's mobile terminal is compared with the scheduling strategy data and the parking space reservation information registered in the blockchain. If a match is successful, the vehicle is bound to the parking space on that floor and the entry time is recorded. If there is no match, the parking space is reallocated according to the floor's remaining capacity or the user is asked to continue queuing.

[0159] In this solution, parking lots can monitor parking space and sensor status in real time, and manage reservation and queuing information through blockchain. Off-site users can access the floor and parking space assigned by the scheduling strategy through a mobile app or front-end system. However, upon arrival, re-identification is required to prevent users from arriving late or using someone else's parking space.

[0160] Scheduling strategy data: A set of floor allocation rules, parking space priorities, and queuing mechanisms, output by quantum optimization or multi-agent collaborative processes. Blockchain-registered parking reservations: When a parking space is allocated to a user on a corresponding floor, a reservation record with a timestamp and hash index is generated on the blockchain for subsequent on-site identification and record comparison.

[0161] License Plate Recognition: Parking lot entrance cameras use a license plate recognition algorithm to capture license plate numbers. When the system detects license plate A, it searches the scheduling policy data and blockchain registration information to determine whether a corresponding reservation / queue record exists for "License Plate A." User Mobile Terminal Identification: If a QR code or token such as NFC is generated by the user's mobile app, it can also be scanned / read by the gate or entrance sensor device and mapped to the "terminal identification" in the previous scheduling policy. These two identification methods can be used in parallel or alternately to improve fault tolerance: if a license plate is damaged, a mobile terminal can be used as a replacement; or if the app is offline, license plate recognition can still be used.

[0162] Scheduling strategy data holds parking space and floor allocation information: if the user is assigned a floor , the system will search within the policy for "License Plate (or Terminal ID) = X" → "Parking Space Reservation = Y". Parking space reservations registered on the blockchain: Using the license plate number or user ID as an index, the corresponding hash record can be located. If the hash verification succeeds and the reservation is still valid, a match is established.

[0163] Successful match: This means the current vehicle is indeed the one who reserved the parking space. The system will mark it as "occupied" in the database (or blockchain extension information) and record the entry time. Matching failure: If the license plate / identity is not found or the match times out, the system will decide whether to reassign the user to a new floor, place them in a new queue, or notify them that they cannot enter based on the latest floor capacity or queue situation.

[0164] After a successful match, a one-to-one association is established between the vehicle's identification (license plate or user ID) and the parking space ID (slot ID) on that floor, ensuring that the space is not preempted within a specified timeframe. Fields such as (parking space ID, user ID, entry time, retention period) are typically stored in an internal database for subsequent settlement, queue determination, and exit monitoring.

[0165] The system automatically marks the vehicle's entry time This information is then written into a trusted database or blockchain (depending on the solution strategy) for subsequent billing and floor occupancy assessment. If a parking space has a time limit for occupancy in the scheduling strategy data, this record can help determine whether a vehicle has overstayed its parking space.

[0166] If there is no match, the parking space will be reallocated or the user will be asked to continue queuing. Reasons for non-matching include: the user is too late and the original reservation has become invalid; the license plate / mobile terminal identification does not match the blockchain record (such as fraudulent use, input error); the reservation has just been canceled or there is a floor failure causing the remaining space to be frozen.

[0167] The system then checks the "dispatch strategy data" for available parking spaces on other floors or access restrictions on adjacent floors. If a floor has available parking spaces, the user is directed to that floor; if not, the user is prompted to queue. If the user chooses to queue, the system creates a corresponding queue record and writes its information (userID, time stamp, etc.) to the blockchain, ensuring that subsequent vehicles leaving the parking lot are notified of available parking spaces.

[0168] Through license plate recognition or terminal identification comparison, the system can accurately control which user enters which floor, preventing others from misusing or grabbing parking spaces, and if malicious impersonation is discovered, it can be saved on the chain for traceability. Because the system verifies when the vehicle enters the site and immediately updates the occupancy status in the database or blockchain, the remaining capacity on each floor can dynamically track the actual occupancy. If the verification fails and the vehicle is transferred to another floor or queued, the remaining capacity on the original floor will not be reduced. After receiving a parking space reservation allocation, the user no longer has to worry about not being able to enter because the floor is full. After a successful comparison, the user can quickly enter and the time is recorded. If there is a faulty identification at the entrance or exit or the user information is abnormal, the backup process (reallocation, queuing, etc.) will be entered, so that the system has the ability to recover from abnormal data.

[0169] In one embodiment, there are 20 remaining parking spaces on Floor 1 and 5 remaining parking spaces on Floor 2 in a shopping mall's underground parking lot. Quantum approximate optimization proposes a strategy of prioritizing Floor 1.

[0170] User A obtains a reservation for parking space 10 on floor 1 and registers it on the blockchain. When entering the parking lot, the camera recognizes the license plate "A1234" and finds "parking space 10, floor 1 reserved for A1234" in the scheduling strategy. The system successfully matches: vehicle A is bound to parking space 10, and the entry time is Records show that the margin on floor 1 changes from 20 to 19.

[0171] If user B only obtains a queue number for floor 2 and verifies their license plate number, "B5678," at the entrance and exit, but discovers they have no reservation or it has expired, the system will check that floor 2 has a vacant space (5) and assign them a spot directly or send them back to the queue (if there are insufficient temporary spaces). If an immediate spot cannot be assigned, user B enters the queue, and the blockchain registers "userB, layer 2 queue, timeStampX." A parking space notification will be issued to them when a vehicle leaves floor 2.

[0172] User A successfully enters parking space 10 on floor 1 and completes the occupancy record. User B is queued or reassigned to floor 2, dynamically processed based on real-time data and scheduling strategies. This example significantly reduces resource waste caused by invalid reservations or incorrect license plates and ensures that users enter the parking space at the correct level.

[0173] The arriving vehicles are identified and their occupancy is verified, and actual occupancy data and departure data are generated when they leave the site. The actual occupancy data and departure data are compared with the scheduling strategy data, and then the parameters of the three-dimensional digital twin environment and quantum approximate optimization algorithm are updated.

[0174] In this solution, vehicles entering the parking lot undergo an identification process (e.g., license plate recognition or user mobile terminal identification) and are matched against existing scheduling policy data to determine the target floor and parking space. After identification and matching, the system verifies the vehicle's actual parking location against the assigned floor space to confirm the correct location.

[0175] When the system recognizes a license plate or logo, it queries the previously generated "dispatching strategy data" against the parking space reservation status registered on the blockchain. If a match is found, the vehicle is assigned to a parking space on the corresponding floor and the entry time is recorded. If the match fails or an anomaly occurs (such as a reservation expired due to a long delay), the system will decide whether to reassign a parking space or place the user in the queue based on the current floor availability or queue information.

[0176] After the vehicle enters the parking lot, the sensor and system monitor the parking time and parking space number. When the vehicle leaves, the system vacates the parking space and records the actual occupancy data associated with the parking space (occupancyRecord), including the entry time. , departure time and other statistical information.

[0177] DepartureInfo typically refers to records related to a vehicle's departure, such as the time of departure, the lane of departure, and whether there were any overtime or defaults. These records form immutable credentials on the blockchain or in a backend database, useful for subsequent audits and user fee settlements.

[0178] When the vehicle leaves the parking lot, the system compares the "actual occupancy data" and "departure data" with the original scheduling strategy data for the floor and parking space prediction or planning to determine if there are any differences. For example, the scheduling strategy had expected the vehicle to park in the parking space for a long time. , and the actual parking time It may be larger or smaller than this value. If the deviation is large, it means that the previous quantum approximate optimization prediction of the parking space usage is not accurate enough, and subsequent parameters need to be corrected.

[0179] In this solution, the 3D digital twin environment visualizes and simulates parking spaces, building structure, and vehicle allocation on each floor. If actual occupancy results show that a floor is more frequently occupied or empty than originally predicted, the 3D twin model can fine-tune fields such as floor capacity, sensor status, and vehicle flow routing based on new departure records and vehicle entry and exit frequencies.

[0180] At the core of this solution, a quantum approximate optimization algorithm (or quantum annealing, hierarchical quantum circuit) uses floor capacity, sensor reliability, and other parameters as input. When actual parking space usage data deviates significantly from predictions, the quantum algorithm's parking space allocation, sensor reliability weights, or floor coupling coefficients need to be corrected to ensure the next round of scheduling is more realistic. For example, if the average dwell time of vehicles on floor 2 is verified to be significantly longer than originally predicted, the algorithm might increase the occupancy penalty coefficient for floor 2, reducing the frequency of vehicle recommendations for that floor.

[0181] Selected, after generating actual occupancy data and departure data when leaving the site, the difference between the actual parking time of the vehicle and the expected parking interval output by the quantum approximate optimization algorithm in the scheduling strategy data is calculated, and based on the difference, the floor capacity and sensor trust level parameters in the neural radiation field model and the fractal hypergraph are updated, and the updated results are rewritten into the blockchain for subsequent scheduling reference.

[0182] When a vehicle leaves the parking space, the system will know that the vehicle has left the parking space automatically or through license plate recognition. At this time, the "actual occupancy data" is generated, recording the license plate or user ID, the start and end time of the vehicle's parking in the parking space, and the length of time the parking space has been used. At the same time, "departure data" refers to more auxiliary information including the vehicle's departure floor number, departure timestamp, whether it has timed out, etc., which is used to combine with other modules (such as settlement or statistics).

[0183] In the early stages of the project, the quantum approximate optimization algorithm estimated the parking time of each floor in order to balance scheduling or queue management. Usually, an estimated parking time range is stored in the scheduling strategy data. or interval .

[0184] When the vehicle leaves the parking lot, the actual parking time can be and the expected interval in the scheduling strategy For comparison:

[0185] like Significantly shorter than , indicating that the system previously overestimated the parking time for this floor (or parking space); if Beyond , the system underestimates the vehicle's dwell time.

[0186] In this solution, Neural Radiance Field (NeRF) not only renders static geometry but also statistically models parking durations, lane congestion, and other metrics, or modeling human traffic flows. When a significant discrepancy between actual parking durations and predicted values ​​is detected, the system makes corresponding corrections in certain areas of the 3D digital twin (e.g., a floor entrance or exit). For example, the frequency of vehicle entry and exit on a particular floor may require relabeling. Spatial resources can be labeled in subsequent renderings with reminders such as "This floor has a high turnover rate" or "This floor is prone to congestion" for review by algorithms or management.

[0187] In the fractal hypergraph structure, each floor (hyperedge E_l) carries capacity, credibility, or other attributes. If actual parking significantly deviates from expectations, the floor capacity weight or sensor credibility weight can be adjusted: if a sensor is found to continuously report relatively inaccurate parking durations, its credibility level can be lowered. If idle or overflow parking spaces on a certain floor frequently occur, the estimated available capacity of the floor can also be increased or decreased accordingly (for example, if the parking space turnover rate is fast, the floor capacity utilization rate can be increased).

[0188] To ensure data traceability and tamper-proofing, the update process of this step (such as floor capacity correction and sensor trust level change) will also generate a new hash and write it into the blockchain node, so that subsequent scheduling and auditing can accurately grasp the reason for the change.

[0189] In practical applications, the expected parking interval given by the quantum algorithm can be expressed as ; Actual parking of the vehicle After leaving the market, you can calculate: . Define a difference function Or similar comparative indicators, if If the absolute value is too large, it will trigger parameter update.

[0190] If floor A has multiple short parking (actual shorter than expected), the system can increase the vehicle flow density in the 3D digital twin, indicating that this floor has a high turnover rate, which is beneficial for subsequent visualization and quantum solution to adjust the scheduling scheme.

[0191] Store the capacity estimate in the floor hyperedge E_l within the fractal hypergraph If multiple times expected (the average parking time of the vehicle owner is much longer than the system calculates), the system can reduce the capacity to prevent too many vehicles from being dispatched to this floor in subsequent scheduling.

[0192] Once the correction of the floor capacity or sensor reliability is completed, the new state is packaged together with the capacity and trust level and hashed and written to the blockchain, ensuring that the system can access the latest information in subsequent iterations of scheduling and that any modifications can be audited.

[0193] By comparing the departure data, the system has a more realistic understanding of the length of time a parking space is used, and the next quantum approximation optimization is closer to the on-site situation, reducing resource waste or excessive congestion. It is easy to form a continuous learning closed loop: observe the real vs. predicted, correct the parameters, and optimize the next round of scheduling. Updating the neural radiation field model in real time can accurately reflect the floor congestion and vehicle flow channel usage in the 3D digital twin environment; correcting the floor capacity and sensor reliability in the fractal hypergraph ensures that the quantum algorithm does not make decisions based on outdated or error-prone data. Writing the updated parameters to the blockchain helps to track how the system adjusts the floor capacity and why it reduces the reliability level of a certain sensor, etc. The source of the decision-making to ensure the transparency of the scheduling system.

[0194] As shown in Figure 2 , a smart parking lot real-time monitoring and scheduling system based on the Internet of Things is used to implement the smart parking lot real-time monitoring and scheduling method based on the Internet of Things. The system comprises:

[0195] A data processing module is configured to acquire parking occupancy data and road traffic data, and to perform denoising and time coordinate alignment processing on the parking occupancy data and road traffic data, and to register the trusted data formed after processing to the blockchain. It is mainly connected to various sensor devices such as parking sensors, road side units, etc. After denoising and time correction through edge computing or server, the trusted data is written to the blockchain. It is usually equipped with a geomagnetic sensor, a camera or a laser radar, etc. to acquire parking occupancy and road traffic information; the original data is sent to the centralized processing node through the network to realize batch data aggregation and blockchain registration.

[0196] ​The 3D environment module is used to build a 3D digital twin environment based on the trusted data. It uses a neural radiation field to generate a 3D model of the parking lot and roads. It then uses a fractal hypergraph to represent the hierarchical association between floor structures and sensor nodes. This fractal hypergraph is then mapped to a quantum approximate optimization algorithm to obtain scheduling strategy data. The neural radiation field model is trained using multi-view imaging or lidar data on a high-performance computing platform (such as a GPU) to generate 3D renderings of parking lot floors and roads. The floors and sensor nodes are then hierarchically managed based on the fractal hypergraph. This 3D information is then mapped to a quantum approximate optimization algorithm to output key parameters such as floor capacity and cross-layer channels required for the scheduling strategy.

[0197] The demand allocation module receives user parking requests, allocates parking spaces based on the scheduling policy data, and generates navigation routes. If there are no available spaces on the target floor, a queue is created. The module dynamically updates the user's parking reservation or queue information based on the trusted data. It interacts with user terminals (onboard devices, mobile phones) to receive parking requests. Based on the scheduling policy and current parking space information stored in the blockchain, it allocates parking spaces and generates navigation routes for the user. If a floor's parking space is insufficient, a queue is created and recorded in the database or blockchain. If a space becomes available, the queued user is automatically notified to proceed.

[0198] The vehicle verification module is used to identify and verify the occupancy of arriving vehicles. Upon departure, actual occupancy and departure data are generated. These data are compared with the scheduling policy data to update the parameters of the 3D digital twin environment and quantum approximate optimization algorithm. Access devices such as license plate recognition cameras and QR code / NFC readers are used to confirm the identity of arriving vehicles. Upon successful comparison, the vehicle is assigned a parking space and actual occupancy data is generated upon departure. By comparing information such as actual parking duration with the scheduling policy, quantum algorithm parameters or 3D models can be updated to continuously improve system scheduling performance and reliability.

[0199] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware.

[0200] The above are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included within the scope of the claims of the present application.

Claims

1. A real-time monitoring and scheduling method for smart parking spaces based on the Internet of Things, characterized in that: The following steps are involved: Obtain parking space occupancy data and road flow data, perform denoising and time coordinate alignment on the parking space occupancy data and road flow data, and write them into the blockchain to form trusted data after completion; A three-dimensional digital twin environment is constructed based on the trusted data. A three-dimensional model of the parking lot and road is generated using a neural radiation field. A fractal hypergraph is used to represent the hierarchical association between the floor structure and the sensor nodes. The fractal hypergraph is mapped to a quantum approximate optimization algorithm to obtain scheduling strategy data. In the step of mapping the fractal hypergraph to a quantum approximate optimization algorithm and obtaining scheduling strategy data, the connectivity relationship between floors and parking space remaining information are extracted as quantum bit constraints, and the sensor credibility level is incorporated into the objective function of quantum annealing or layered quantum circuits. After generating preliminary scheduling results, the floors where low-credibility sensors are located are corrected in combination with multi-agent collaboration, and finally the scheduling strategy data is formed; Receive user parking requests, allocate parking spaces and generate navigation routes based on the scheduling policy data, establish queuing information if there are no vacant parking spaces on the target floor, and dynamically update the user's parking reservation information or queuing information based on the trusted data; The arriving vehicles are identified and their occupancy is verified, and actual occupancy data and departure data are generated when they leave the site. The actual occupancy data and departure data are compared with the scheduling strategy data, and then the parameters of the three-dimensional digital twin environment and quantum approximate optimization algorithm are updated.

2. The method according to claim 1, characterized in that In the process of obtaining parking space occupancy data and road flow data and performing denoising and time coordinate alignment processing, by marking each data with a timestamp and geographic location identifier, sensor data with continuous value jumps and exceeding a fixed threshold are eliminated, and the verified data is packaged into a trusted input and written into the blockchain.

3. The method according to claim 1, characterized in that When constructing a three-dimensional digital twin environment based on the trusted data, multi-view images are used to sample the parking lot area, and a neural radiation field is used to generate a three-dimensional volume rendering result of the connection between the floor structure and the road, and the floor position reflected in the rendering result is mapped with the sensor coordinate information.

4. The method according to claim 3, characterized in that In the step of hierarchically associating the floor structure and sensor nodes through a fractal hypergraph, a first-level hyperedge is established for each floor to include the coordinate information of all sensors and parking spaces on that floor, and cross-floor hyperedges are created based on the physical connections between floors to represent the paths that vehicles can travel across floors. The cross-floor hyperedges carry hash indexes corresponding to the sensor trusted identifiers registered on the blockchain.

5. The method according to claim 1, wherein When receiving a user's parking request, the target floor is determined by retrieving the number of available parking spaces on each floor in the scheduling strategy data and the vehicle queue length information provided by the road side unit, and a navigation route is generated based on the floor entrance coordinates rendered by the neural radiation field.

6. The method according to claim 5, characterized in that If there are no vacant parking spaces on the target floor, a queue is created and the queue sequence is sorted in order based on the estimated departure time of each parking space in the trusted data. Whenever a vehicle leaves, the number of parking spaces on the corresponding floor is increased and the first user in the queue is notified. If the user's waiting time exceeds the preset time limit, the queue space is released and the user's timeout record is updated on the blockchain.

7. The method according to claim 1, characterized in that When identifying and verifying the occupancy of arriving vehicles, the license plate recognition or the identifier generated by the user's mobile terminal is compared with the scheduling strategy data and the parking space reservation information registered on the blockchain. If a match is successful, the vehicle is bound to the parking space on that floor and the entry time is recorded. If there is no match, the parking space is reallocated according to the floor's remaining capacity or the user is asked to continue queuing.

8. The method according to claim 7, characterized in that After generating actual occupancy data and departure data upon departure, the difference between the actual parking time of the vehicle and the estimated parking interval output by the quantum approximate optimization algorithm in the scheduling strategy data is calculated. Based on this difference, the floor capacity and sensor trust level parameters in the neural radiation field model and fractal hypergraph are updated, and the updated results are rewritten into the blockchain for subsequent scheduling reference.

9. A real-time monitoring and scheduling system for smart parking spaces based on the Internet of Things, used to implement the real-time monitoring and scheduling method for smart parking spaces based on the Internet of Things according to any one of claims 1 to 8, characterized in that: The system includes: A data processing module is used to obtain parking space occupancy data and road flow data, perform denoising and time coordinate alignment on the parking space occupancy data and road flow data, and register the processed trusted data into the blockchain; A three-dimensional environment module is used to build a three-dimensional digital twin environment based on the trusted data, generate a three-dimensional model of the parking lot and road using a neural radiation field, and represent the floor structure and sensor nodes in a hierarchical manner through a fractal hypergraph. The fractal hypergraph is mapped to a quantum approximate optimization algorithm to obtain scheduling strategy data; A demand allocation module is used to receive user parking requests, allocate parking spaces and generate navigation routes based on the scheduling policy data, establish queue information if there are no vacant parking spaces on the target floor, and dynamically update the user's parking space reservation information or queue information based on the trusted data; The vehicle verification module is used to identify and verify the occupancy of arriving vehicles, and generate actual occupancy data and departure data when the vehicle leaves the site. After comparing the actual occupancy data and departure data with the scheduling strategy data, the parameters of the three-dimensional digital twin environment and quantum approximate optimization algorithm are updated.

Images