Intelligent parking lock management system based on shared reservation and emergency control

Abstract

The application relates to the technical field of parking management, and discloses an intelligent parking space lock management system based on shared reservation and emergency control, which comprises the following modules: a reservation token module, which is used for generating a revocable reservation token and writing the token into a local strategy table; a presence lock-lowering module, which is used for lowering the lock when a reservation is valid and a parking space is idle; an emergency priority module, which is used for determining an emergency request priority and freezing or revoking a reservation token; a conflict migration module, which is used for determining a migration parking space and rebuilding a reservation when a reservation conflicts; a mutual exclusion safety module, which is used for performing mutual exclusion and safety checking on a lock-lowering control command; an online settlement module, which is used for completing usage duration and fee calculation based on an event sequence; and a timeout rollback module, which is used for performing multistage rollback release processing when an emergency release is timed out. The application realizes deterministic control and traceable management of parking space usage in a shared reservation and emergency control parallel scene.

Description

Technical Field

[0001] This invention belongs to the field of parking management technology, specifically relating to an intelligent parking lock management system based on shared reservation and emergency control. Background Technology

[0002] With the continuous growth of urban motor vehicle ownership, parking resource shortages have become a significant issue affecting urban traffic efficiency and the quality of public services. To improve parking space utilization, intelligent parking management based on shared reservations has been gradually introduced, scheduling dispersed parking resources through advance reservations and on-time usage. However, existing shared reservation parking management systems mostly focus on centralized management of reservation information or cloud-based scheduling. The local ability of parking locks to determine the validity of reservations is limited. Under unstable network conditions or concurrent multi-source commands, problems such as inconsistent reservation verification, conflicts between lift locks, and missing usage records can easily occur.

[0003] On the other hand, in scenarios such as hospitals, fire lanes, and emergency response areas, parking spaces also need to provide priority access for emergency vehicles in emergency situations. In existing technologies, emergency release is usually achieved through manual intervention or simple priority overrides, lacking a structured connection with existing reservation mechanisms. This can easily lead to the loss of the original reservation status, unclear boundaries of responsibility, and difficulty in accurately calculating reservation conflicts, release processes, and costs afterward. Furthermore, in cases where emergency release is obstructed or timed out, existing systems typically lack a clear rollback mechanism, making it difficult to guarantee reliable passage for emergency vehicles.

[0004] Meanwhile, as parking services become increasingly commercialized, parking fee settlement relies more and more on accurate statistics of the actual usage time of parking spaces. However, in existing systems, the operation events generated by the parking space lock often lack a unified event sequence management and idempotent verification mechanism between the cloud-based settlement system and the system itself. This can easily lead to inaccurate billing due to duplicate reporting, network retransmissions, or timing discrepancies. Summary of the Invention

[0005] This invention provides an intelligent parking lock management system based on shared reservation and emergency control, which solves the technical problems in related technologies where shared reservation and emergency access coexist, such as the lack of local consistency verification of reservation validity, the lack of clear priority adjudication and status connection between emergency access and existing reservations, and the difficulty in forming a traceable time sequence of parking space usage events and supporting unified settlement processing.

[0006] This invention provides an intelligent parking lock management system based on shared reservation and emergency control, comprising:

[0007] The reservation token module is used to obtain user reservation information and system preset constants, generate a standardized reservation time window, generate a revocable reservation token and write it to the local policy table.

[0008] The on-site lock-down module is used to verify the revocable reservation token against the local policy table. It performs lock-down when the parking space is vacant and the current time is within the normalized reservation time window; otherwise, it triggers conflict handling.

[0009] The emergency priority module is used to obtain emergency request information and compare it with the priority of the revocable reservation token of the corresponding parking space. If emergency priority is granted, the parking space is allowed to proceed and the revocable reservation token is marked as frozen or revoked.

[0010] The conflict migration module is used to generate conflict events based on freeze and cancellation flags, determine the optimal migration parking space according to the parking space distance weighted rule, and generate a new revocable reservation token to write to the local policy table.

[0011] The mutual exclusion safety module is used to perform mutual exclusion and security checks on the lifting lock control commands. The lifting lock control command is executed when both mutual exclusion and security checks pass; otherwise, the lifting lock control command is rejected.

[0012] The online settlement module is used to report event sequences online. The cloud performs idempotency verification on the event sequences, obtains the actual usage time and unused time from the event timestamp, and calculates the user's actual payable fee and refundable fee according to the system's basic rate.

[0013] The timeout rollback module is used to determine whether a timeout has occurred by comparing the actual execution time of the emergency release action with the maximum allowed duration of the emergency action. If a timeout occurs, the retry priority comparison, near-field emergency credential whitelist verification, and mechanical redundancy channel release are performed in sequence.

[0014] The beneficial effects of this invention are as follows: By constructing a management mechanism combining shared reservation and emergency control locally on the parking lock, this invention achieves refined control and traceable management of the parking space usage process. By introducing revocable reservation tokens and standardized reservation time windows, the parking lock can perform consistency verification of reservation validity locally, reducing reliance on real-time cloud communication and improving the determinism of reservation verification and lock control. In emergency control scenarios, this invention uses clear priority comparison rules to adjudicate emergency requests and existing reservations, and distinguishes and manages reservation status through freeze or cancellation markers, creating a clear status connection between emergency access and shared reservations.

[0015] When reservation conflicts occur, this invention combines time conflict elimination with parking space distance weighting rules through conflict event generation and candidate parking space migration mechanisms. This achieves orderly migration of affected reservations, avoiding the problem of reservations becoming invalid or management chaos due to emergency release. Simultaneously, by implementing mutual exclusion and security checks on the lift lock control commands, the risk of misoperation caused by concurrent multi-source control commands is effectively reduced.

[0016] Furthermore, this invention constructs an event sequence based on event timestamps and completes the unified calculation of usage time and fees through cloud-based idempotent verification, thereby ensuring consistency and verifiability of parking usage records and settlement processes, and improving the reliability of parking resource scheduling and management transparency. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the modules of the intelligent parking lock management system based on shared reservation and emergency control of the present invention. Detailed Implementation

[0018] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.

[0019] It should be noted that, unless otherwise defined, the technical or scientific terms used in one or more embodiments of the present invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in one or more embodiments of the present invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0020] like Figure 1 As shown, the intelligent parking lock management system based on shared reservation and emergency control includes:

[0021] The reservation token module 1 is used to obtain user reservation information and system preset constants, generate a standardized reservation time window, generate a revocable reservation token and write it to the local policy table.

[0022] The on-site lock reduction module 2 is used to verify the revocable reservation token and the local policy table. It performs lock reduction when the parking space occupancy status is vacant and the current time is within the normalized reservation time window; otherwise, it triggers conflict handling.

[0023] Emergency Priority Module 3 is used to obtain emergency request information and compare its priority with the revocable reservation token of the corresponding parking space. If emergency priority is granted, the parking space is allowed to proceed and the revocable reservation token is marked as frozen or revoked.

[0024] Conflict migration module 4 is used to generate conflict events based on freeze and cancellation flags, determine the optimal migration parking space according to the parking space distance weighted rule, and generate a new revocable reservation token to write to the local policy table.

[0025] Mutual exclusion safety module 5 is used to perform mutual exclusion and security checks on the lifting lock control command. The lifting lock control command is executed when both mutual exclusion and security checks pass; otherwise, the lifting lock control command is rejected.

[0026] The online settlement module 6 is used to report event sequences online. The cloud performs idempotency verification on the event sequences, obtains the actual usage time and unused time from the event timestamp, and calculates the user's actual payable fee and refundable fee according to the system's basic rate.

[0027] The timeout rollback module 7 is used to determine whether a timeout has occurred by comparing the actual execution time of the emergency release action with the maximum allowable duration of the emergency action. If a timeout occurs, the retry priority comparison, near-field emergency credential whitelist verification, and mechanical redundancy channel release are performed in sequence.

[0028] In one embodiment of the present invention, the intelligent parking lock management system receives user reservation information from the reservation submission terminal and reads system preset constants. The user reservation information includes: parking space number, reservation start time, reservation end time, user identifier, and revocable identifier. Among them, the parking space number is a code used to uniquely locate the target parking space and its parking lock; the reservation start time and reservation end time are time data describing the valid interval of this reservation; the user identifier is identification information used to distinguish the reservation initiator; and the revocable identifier is a status identifier used to indicate that the reservation can be frozen or revoked in an emergency control scenario.

[0029] The system preset constants include: a first preset order, a second preset order, an early activation duration, and a delayed expiration duration; wherein, the first preset order is the fixed order in which the fields participating in the digest calculation are arranged and concatenated when generating the reservation unique identifier; the second preset order is the fixed order in which the fields participating in the digest calculation are arranged and concatenated when generating the digest verification value; the early activation duration is a duration constant for adjusting the reservation start time forward; and the delayed expiration duration is a duration constant for adjusting the reservation end time backward.

[0030] The reservation time boundaries are standardized based on the advance effective time and the delay expiration time. The reservation start time is adjusted forward by the advance effective time to obtain the standardized reservation start time, and the reservation end time is adjusted backward by the delay expiration time to obtain the standardized reservation end time. The standardized reservation start time and standardized reservation end time constitute a standardized reservation time window. The standardized reservation time window is a time window data object used in the shared reservation scenario to unify the local judgment criteria for parking locks to allow entry and delock. It has a clear extended boundary relative to the original reservation validity period, enabling the system to provide a consistent time tolerance range for early arrival and late departure in the parking space sharing service.

[0031] The system generates a revocable reservation token and writes it to the local policy table record unit. The revocable reservation token is a reservation credential data object that can be validated locally on the parking lock and can be frozen or revoked by the emergency control process. It includes a unique reservation identifier, parking space number, standardized reservation time window, revocable identifier, and a digest verification value. The unique reservation identifier is generated by concatenating the user identifier, parking space number, reservation start time, and reservation end time in a first preset order, followed by digest calculation. The digest verification value is generated by concatenating the unique reservation identifier, parking space number, standardized reservation time window, and revocable identifier in a second preset order, followed by digest calculation. Digest calculation refers to performing deterministic digest calculation on the data to be digested to output a fixed-length digest result, enabling the parking lock to perform a consistency comparison between the revocable reservation token and the corresponding record in the local policy table record unit using the digest verification value. By generating unique reservation identifiers and summary verification values ​​in layers, it is ensured that reservations for different parking spaces or time periods by the same user can be uniquely distinguished, and that revocable reservation tokens can be verified to ensure that there are no field-level differences during transmission, storage, or multi-terminal synchronization.

[0032] The local policy table record unit is a local structured storage unit on the parking space lock side, used to maintain the set of revocable reservation tokens and their status change records for each parking space number, supporting local determination under offline or weak network conditions. The system writes the generated revocable reservation tokens into the local policy table record unit corresponding to the parking space number. When the local policy table contains the same unique reservation identifier, the latest revocable reservation token replaces the original one, and the tokens are stored in ascending order according to reservation start time, reservation end time, and dictionary order of the unique reservation identifier. These replacement and sorting rules ensure that in cases of repeated issuance, retransmission, or multi-terminal synchronization, the local policy table maintains only one valid record for the same unique reservation identifier and maintains a deterministic storage order, thus providing a stable index foundation for token verification, time window determination, emergency priority handling, and conflict migration writing in subsequent steps.

[0033] Based on the above implementation process, this invention forms a verifiable and consistent local control foundation for parking locks in parking space management scenarios where shared reservations and emergency control coexist. On the one hand, by standardizing the reservation time window, it unifies the time determination criteria for shared reservations on the parking lock side, reducing disputes caused by inconsistent interpretations of reservation time boundaries by different terminals. On the other hand, through the hierarchical generation of reservation unique identifiers and digest verification values, as well as the replacement and sorting management of record units in the local policy table, the parking lock can still perform consistency verification of reservation credentials and maintain a stable set of reservation records even when offline or under weak network conditions. This provides a reliable local reference object for applying freeze or cancellation marks to revocable reservation tokens during emergency priority access.

[0034] In one embodiment of the present invention, the revocable reservation token is verified against the local policy table. Locking is deactivated when the parking space is vacant and the current time falls within the normalized reservation time window; otherwise, conflict handling is triggered, including:

[0035] Step 11: Obtain the parking space occupancy status and current time. The parking space occupancy status indicates whether the parking space is occupied by a vehicle; in this embodiment, it includes both vacant and non-vacant. The system locates the local policy table record unit corresponding to the parking space number carried in the revocable reservation token. The system searches the local policy table record unit for a record with a matching reservation unique identifier. If no record with a matching reservation unique identifier is found, it indicates that the revocable reservation token does not exist locally or has expired. The system then generates a conflict handling flag and writes the flag to the local event queue to record a reservation verification failure event.

[0036] Step 12: When a record with a matching reservation unique identifier is found, the system continues to verify the integrity and timeliness of the revocable reservation token. Specifically, the system extracts a digest verification value from the record and compares it with the digest verification value carried in the revocable reservation token. If the consistency comparison is inconsistent, the system determines that the revocable reservation token is inconsistent with the record in the local policy table record unit, generates a conflict handling flag, and writes it to the local event queue. If the consistency comparison passes, the system further extracts the normalized reservation start time and normalized reservation end time from the record and uses them to form a normalized reservation time window. The normalized reservation time window is a time interval formed by adjusting the early effective time and late expiration time based on the reservation start time and reservation end time, used to unify the effective use judgment boundary in the shared reservation scenario. The system determines whether the current time is not earlier than the normalized reservation start time and not later than the normalized reservation end time; if the current time does not meet this time relationship, it indicates that the reservation has not yet taken effect or has expired, and the system also generates a conflict handling flag and writes it to the local event queue. The conflict handling marker includes the parking space number, the unique reservation identifier, the current time, the parking space occupancy status, and the conflict reason code, which are used to clearly record the object, time, and reason for the conflict.

[0037] Step 13: After completing the consistency check and time window check above without generating a conflict handling flag, the system enters the parking space occupancy status determination stage. At this time, the system again determines whether the parking space occupancy status is vacant. When the parking space occupancy status is vacant, it indicates that both the reservation conditions and the on-site status are met. The system executes a delocking action to release the parking space for the reserved user and writes a record containing the unique reservation identifier and event timestamp into the local event queue as part of the event sequence. The event timestamp is a timestamp recording the moment the delocking action occurs, used to subsequently reconstruct the event timeline in the cloud and calculate the actual usage time. Conversely, when the parking space occupancy status is not vacant, although the reservation token is valid and within the normalized reservation time window, the system still generates a conflict handling flag and writes it into the local event queue because the parking space has been occupied, to reflect the inconsistency between the reservation conditions and the actual occupancy status.

[0038] Through the aforementioned processing mechanism, this invention achieves layered verification of reservation validity, time legitimacy, and on-site occupancy status in parking space management scenarios where shared reservations and emergency control operate in parallel. This solution enables parking locks to quickly determine reservation eligibility locally and, through conflict resolution markers and event queues, structurally records abnormal situations, providing a reliable data foundation for subsequent emergency priority release, conflict migration handling, and fee settlement.

[0039] In one embodiment of the present invention, obtaining emergency request information and comparing its priority with the revocable reservation token for the corresponding parking space, if the emergency has priority, allows passage and marks the revocable reservation token as frozen or revoked, includes:

[0040] Step 21: Obtain emergency request information and locate the local policy table record unit corresponding to the parking space number carried in the emergency request information. The emergency request information is a set of input data for the emergency control process, including parking space number, emergency request time, emergency priority, and emergency release type. The parking space number is used to identify the target parking space corresponding to the emergency request; the emergency request time is a timestamp indicating the occurrence of the emergency request; the emergency priority is a level information used for comparison with the reservation priority; and the emergency release type is a control identifier used to indicate whether a freeze or cancellation flag is applied to the revocable reservation token after emergency release. The system searches the local policy table record unit for a revocable reservation token with a unique reservation identifier. If no revocable reservation token is found, it indicates that there is currently no comparable reservation record for the target parking space or the reservation has expired. The system then generates a conflict handling flag and writes this flag to the local event queue to record an abnormal event where emergency priority determination cannot be completed.

[0041] Step 22: When a revocable reservation token is retrieved, the system enters the emergency priority comparison stage. The system extracts the reservation priority and reservation start time from the revocable reservation token and compares the emergency priority in the emergency request information with the reservation priority. When the emergency priority is higher than the reservation priority, the system directly determines emergency priority; when the emergency priority and reservation priority are the same, the system further compares the emergency request time with the reservation start time. If the emergency request time is earlier than the reservation start time, emergency priority is determined; otherwise, it is determined as non-emergency priority. By combining priority comparison with time comparison, the system introduces the time dimension as a judgment criterion when priorities are the same, thereby forming a deterministic emergency priority determination rule and avoiding ambiguity caused by a single priority judgment.

[0042] Step 23: If emergency priority is determined, the system executes a release, which includes lowering the parking space lock to make the target parking space directly accessible in an emergency scenario. Simultaneously, the system applies a status marker to the revocable reservation token according to the emergency release type: when the emergency release type is a freeze marker, a freeze marker is applied to the revocable reservation token to indicate that the reservation is temporarily frozen but not cancelled during the emergency release; when the emergency release type is a cancellation marker, a cancellation marker is applied to the revocable reservation token to indicate that the reservation is terminated due to the emergency release. The system writes a record containing the parking space number, unique reservation identifier, emergency release type, emergency request time, and event timestamp into the local policy table record unit and the local event queue, and saves this record as part of the event sequence. The event timestamp is used to record the specific time when the emergency release and marking operations occur, providing a time basis for subsequent reconstruction of the event timeline in the cloud, execution of cost settlement, and auditing.

[0043] Through the aforementioned processing mechanism, this invention achieves deterministic priority determination between emergency requests and reservation requests in parking space management scenarios where shared reservations and emergency control operate in parallel. It also differentiates and manages reservation statuses using freeze and cancellation flags. On one hand, this solution ensures that emergency vehicles have priority access to parking spaces in emergency situations; on the other hand, by embedding emergency release and reservation status change records in the local policy table and local event queue, the system has clear data support for subsequent conflict resolution, reservation restoration, or fee settlement.

[0044] In one embodiment of the present invention, a conflict event is generated based on a freeze flag and a cancellation flag, the optimal relocation parking space is determined according to a parking space distance weighted rule, and a new revocable reservation token is generated and written to the local policy table, including:

[0045] Step 31: Under the parking space number corresponding to the original reservation, locate the local policy table record unit for that parking space and retrieve a revocable reservation token with the same unique reservation identifier. The system determines whether the revocable reservation token has been marked with a freeze or cancellation flag. A freeze flag indicates that the reservation was temporarily suspended but not invalidated during emergency release, while a cancellation flag indicates that the reservation was terminated due to emergency release. When it is determined that the revocable reservation token has been marked with a freeze or cancellation flag, the system generates a conflict event. The conflict event is a structured data object describing the conflict state between the reservation and emergency release, including the parking space number, unique reservation identifier, freeze or cancellation flag, emergency request time, and event timestamp. The system writes this conflict event to a local event queue and saves it as part of an event sequence for subsequent reconstruction of the complete timeline of reservation conflict and migration processing in the cloud.

[0046] Step 32: After generating a conflict event, the system enters the parking space migration calculation stage. The system obtains a set of candidate parking spaces and reads the parking space number and availability status of each candidate parking space in the set. The candidate parking space set is a pre-selected set of parking spaces that are physically or logically available to accept migration reservations; the availability status of a candidate parking space is used to characterize whether the parking space has the basic conditions for allocation at the current moment. The system calculates a weighted distance value for each candidate parking space according to the parking space distance weighting rule. Specifically, for each candidate parking space, the system obtains multiple distance metrics relative to the parking space to be migrated, and multiplies each distance metric with its corresponding distance weight to obtain a distance product. Then, the distance products are summarized to obtain the weighted distance value of the candidate parking space. Here, the distance metric is used to characterize the distance between the candidate parking space and the parking space to be migrated, and the distance weight is used to characterize the relative importance of different distance dimensions in the migration decision. The system identifies the candidate parking space with the smallest weighted distance value as the optimal relocation parking space. When multiple candidate parking spaces have the same weighted distance value, the system further compares them according to the lexicographical order of the parking space numbers to determine the unique optimal relocation parking space. Through these rules, the system forms a deterministic relocation decision result in the case of multiple candidate parking spaces, avoiding inconsistencies or unreproducible relocation results.

[0047] Step 33: After determining the optimal relocated parking space, the system generates a new revocable reservation token based on the unique reservation identifier corresponding to the conflict event and the normalized reservation time window of the original revocable reservation token. The normalized reservation time window follows the original reservation's time interval adjusted for advance effective duration and delayed expiration duration to ensure the continuity of the relocated reservation in the time dimension. The system replaces the parking space number in the new revocable reservation token with the parking space number of the optimal relocated parking space and generates a digest verification value for the new revocable reservation token to form a complete and verifiable reservation certificate. Subsequently, the system writes the new revocable reservation token into the local policy table record unit corresponding to the optimal relocated parking space; when a record with the same unique reservation identifier already exists in the local policy table record unit, the newly generated revocable reservation token replaces the original revocable reservation token, and the records are stored in ascending order according to the reservation start time, reservation end time, and lexicographical order of the unique reservation identifier, thereby maintaining the deterministic order of reservation records in the local policy table record unit.

[0048] Through the aforementioned processing mechanism, this invention achieves a complete closed-loop process, from conflict identification and conflict event solidification to reservation migration and reconstruction, when conflicts arise between shared reservations and emergency control. On the one hand, by triggering conflict event generation through freeze and cancellation markers, the system can clearly distinguish the abnormal reservation status caused by emergency access. On the other hand, by determining the optimal migration parking space based on parking space distance weighted rules and generating a new revocable reservation token, the system can reasonably migrate and continuously manage the original reservation without affecting emergency access, thereby improving the scheduling efficiency and controllability of parking space resources in complex traffic scenarios.

[0049] In one embodiment of the present invention, the lift lock control command is subjected to mutual exclusion verification and security verification. The lift lock control command is executed if both mutual exclusion verification and security verification pass; otherwise, the lift lock control command is rejected. This includes:

[0050] Step 41: Obtain the lift lock control command and perform command type solidification processing on the lift lock control command, clearly distinguishing it as a lift lock command or a lower lock command. The lift lock command is used to drive the parking space lock to switch from a lower lock state to a lift lock state, and the lower lock command is used to drive the parking space lock to switch from a lift lock state to a lower lock state. Based on the parking space number associated with the lift lock control command, the system locates the local policy table record unit corresponding to the parking space number, and simultaneously obtains the current parking space occupancy status and the current time.

[0051] Step 42: After completing command type fixation and context location, the system performs mutual exclusion verification. Specifically, the system reads the currently pending command type from the local policy table record unit and performs mutual exclusion determination with the command type of the newly acquired lift lock control command. This mutual exclusion determination is used to identify whether there are concurrent control requests with a different command type than the currently pending command. When the two command types match, the system determines that the mutual exclusion verification passes and allows entry into the subsequent verification process; when the two command types do not match, the system determines that the mutual exclusion verification fails and refuses to execute the lift lock control command. When refusing execution, the system writes a rejection record containing the parking space number, command type, current time, and event timestamp into the local event queue, recording a command rejection event caused by mutual exclusion conflict in a structured manner.

[0052] Step 43: Provided the mutual exclusion check passes, the system performs either a security check or executes the action directly based on the command type. When the command type is an upgrade command, the system performs a security check on the upgrade command. The security check includes at least a parking space occupancy status check and a reservation time boundary check: the system determines whether the parking space occupancy status is vacant and whether the current time is not earlier than the end time of the normalized reservation time window corresponding to the revocable reservation token. The end time of the normalized reservation time window is the reservation end time adjusted for a delayed expiration duration, used to limit the earliest allowed time for the upgrade action. When the parking space occupancy status is vacant and the current time is not earlier than the end time of the normalized reservation time window, the system determines that the security check has passed and executes the upgrade command; when the parking space occupancy status is not vacant, or the current time is earlier than the end time of the normalized reservation time window, the system determines that the security check has failed and refuses to execute the upgrade command.

[0053] When the mutual exclusion check passes and the command type is a lowering command, the system will not perform the aforementioned security check, but will directly execute the lowering command to ensure that the parking space can be promptly made usable in scenarios such as reservation activation or emergency release. Whether executing a locking command, a lowering command, or refusing execution due to failure to pass the mutual exclusion check or security check, the system generates a corresponding result record and writes the result record, containing the parking space number, command type, current time, event timestamp, and result type, to the local event queue. The result type characterizes the final processing result of the locking / lifting control command, and its value is limited to execution or rejection.

[0054] Through the aforementioned processing mechanism, this invention achieves concurrent conflict protection and safety boundary constraints for parking space lock control commands in a parking space management system that combines shared reservation and emergency control. On the one hand, mutual exclusion verification avoids conflicts between locking and unlocking commands from different sources on the same parking space; on the other hand, by limiting the locking action to be performed only after the parking space is vacant and the reservation time window has ended, the impact of accidental locking or misoperation on user parking experience and parking space security is effectively reduced. Simultaneously, all control results are recorded through a local event queue, providing a complete data foundation for subsequent event sequence reporting, usage duration calculation, and fee settlement.

[0055] In one embodiment of the present invention, an event sequence is reported online, and the cloud performs idempotency verification on the event sequence. The actual usage duration and unused duration are obtained from the event timestamps, and the actual fees payable by the user and the fees refundable by the user are calculated according to the system's basic rate, including:

[0056] Step 51: Read all records associated with the unique appointment identifier in the local event queue, and sort them chronologically using the event timestamp as the sole sorting criterion, thus forming an ordered set of events reflecting the entire lifecycle of the appointment. The system encapsulates the sorted records into an event sequence and generates a corresponding sequence number for this event sequence, while also recording the sequence number and the reporting time of the event sequence. The sequence number is used to distinguish event sequences reported in different time batches to support subsequent idempotency verification processing in the cloud. After encapsulation, the system reports the event sequence to the cloud online via the network.

[0057] Step 52: Upon receiving the event sequence, the cloud first performs idempotency verification. Specifically, based on the unique reservation identifier carried in the event sequence, the cloud retrieves the historical sequence number and historical event summary associated with that unique reservation identifier. The historical sequence number is the event sequence identifier that has been successfully written into the cloud event database, and the historical event summary is the verification result obtained by summarizing the historical event sequence. The cloud compares the sequence number corresponding to the current event sequence with the historical sequence number and generates an event summary for the current event sequence. If the current sequence number is later than the historical sequence number and the current event summary is inconsistent with the historical event summary, the cloud determines that the current event sequence is a new and valid event sequence, passes the idempotency verification, and writes it into the cloud event database; otherwise, it is determined to be a duplicate or invalid report and is rejected from being written into the cloud event database. Through this idempotency verification mechanism, the cloud can avoid duplicate event counting caused by duplicate reporting, network retransmission, or out-of-order reporting.

[0058] Step 53: After the idempotency check passes, the cloud performs usage duration and cost calculation based on the event sequence. The cloud extracts the corresponding event sequence according to the unique reservation identifier and reconstructs the event timeline based on the chronological order of the event timestamps. The event timeline reflects the complete time sequence of parking space status changes from reservation start, release, occupancy, to release. Based on the event type field, the cloud identifies the event timestamp indicating the start of occupancy and the event timestamp indicating the end of occupancy in the event timeline, and determines the time difference between the event timestamp indicating the end of occupancy and the event timestamp indicating the start of occupancy as the actual usage duration. Subsequently, the cloud subtracts the actual usage duration from the total duration corresponding to the normalized reservation time window to obtain the unused duration.

[0059] After calculating the duration, the cloud platform further performs cost calculation. The system obtains the system base rate and multiplies it by the actual usage duration to obtain the user's actual payable cost. Simultaneously, it multiplies the system base rate by the unused duration to obtain the user's refundable cost. The system base rate is a pre-set unit time cost parameter on the system side, used to unify the cost calculation method for different reservations. The cloud platform associates and records the user's actual payable cost and refundable cost with the reservation's unique identifier as the basis for subsequent billing processing and user settlement.

[0060] Through the above processing mechanism, this invention achieves a complete closed loop from local event collection and event sequence reporting of parking space locks to unified verification and settlement in the cloud. On the one hand, by reconstructing the event timeline through event timestamps, the actual usage of parking spaces in scenarios where shared reservations and emergency control are intertwined can be accurately restored; on the other hand, through idempotent verification and sequence number mechanisms, it ensures that cloud-based fee calculations are based only on unique and valid event sequences, avoiding duplicate billing or omissions.

[0061] In one embodiment of the present invention, the timeout is determined by comparing the actual execution time of the emergency release action with the maximum allowable duration of the emergency action. If a timeout occurs, the following steps are performed sequentially: retry priority comparison, near-field emergency credential whitelist verification, and mechanical redundancy channel release, including:

[0062] Step 61: Determine the actual execution time of the emergency release operation. Based on the unique reservation identifier, the system reads records with the event type "Release" from the local event queue and extracts the corresponding event timestamp as the release start time. Simultaneously, it reads records with the event type "Locking Completed" from the local event queue and extracts the corresponding event timestamp as the release completion time. The release start time represents the initial moment when the emergency release command is confirmed for execution, and the release completion time represents the moment when the parking space lock actually lowers and enters a passable state. The system determines the time difference between the release completion time and the release start time as the actual execution time of the emergency release operation, associates this actual execution time with the unique reservation identifier, and writes it into the local event queue to form deterministic time data that can be referenced by subsequent steps.

[0063] Step 62: After obtaining the actual execution time of the emergency release action, the system enters the timeout determination stage. The system obtains the pre-set maximum allowable duration of the emergency action, which is a time threshold defined by the system side to limit the longest allowed duration from triggering to completion of the emergency release action. The system compares the actual execution time of the emergency release action with the maximum allowable duration. When the actual execution time of the emergency release action is greater than the maximum allowable duration, the system generates a timeout flag; when the actual execution time of the emergency release action is not greater than the maximum allowable duration, the system generates a no-timeout flag. The system associates the generated timeout flag or no-timeout flag with the parking space number, reservation unique identifier, emergency request time, and event timestamp, and writes it to the local event queue, saving it as part of the event sequence.

[0064] Step 63: When the system generates a timeout flag, indicating that the emergency release action failed to be completed within the specified time, the system initiates a rollback process. This rollback process executes multiple rollback links sequentially in a preset fixed order. First, the system performs a retry priority comparison, which uses the emergency request information and the corresponding parking space's revocable reservation token as input to re-prioritize the current emergency request and reservation status. If the retry priority comparison fails to facilitate release completion, the system continues to perform near-field emergency credential whitelist verification. The near-field emergency credential whitelist verification is used to determine whether there are emergency credentials that meet the preset whitelist conditions. When the verification passes, the system directly executes a delocking action and writes the corresponding result to the local event queue. When the near-field emergency credential whitelist verification fails or a release completion result is still not formed, the system further triggers mechanical redundancy channel release. The mechanical redundancy channel release is a backup release method that does not rely on the conventional control link, and its triggering result is also written to the local event queue.

[0065] During the aforementioned rollback process, the system generates rollback records for three types of rollback paths: retry priority comparison, near-field emergency credential whitelist verification, and mechanical redundancy channel release. Each rollback record includes at least the parking space number, unique reservation identifier, emergency request time, event timestamp, and rollback path type. The rollback path type is limited to retry priority comparison, near-field emergency credential whitelist verification, or mechanical redundancy channel release. By uniformly writing the rollback records to the local event queue, the system can completely reconstruct the processing path after the emergency release timeout during subsequent event sequence reconstruction.

[0066] Through the aforementioned processing mechanism, this invention, in an intelligent parking lock management system that combines shared reservation and emergency control, achieves continuous monitoring and deterministic determination of the execution time of emergency release actions, and provides multi-level, orderly rollback guarantees in case of timeout. On the one hand, this scheme calculates the actual execution time of emergency release actions through event timestamps, providing a clear data basis for timeout determination; on the other hand, through a rollback link combining retry, whitelist verification, and mechanical redundancy channels, it ensures that emergency vehicles can still obtain necessary passage guarantees in complex or abnormal environments.

[0067] In one embodiment of the present invention, in addition to generating a revocable reservation token and writing it to the local policy table record unit, the method further includes cleaning up expired revocable reservation tokens, including:

[0068] Step 71: Obtain the current time and locate the corresponding local policy table record unit based on the parking space number. The system iterates through the existing revocable reservation tokens in this local policy table record unit and extracts the corresponding normalized reservation time window end time for each revocable reservation token. The normalized reservation time window end time is used to uniformly represent the latest time that the reservation is allowed to remain valid in a shared reservation scenario.

[0069] Step 72: After extracting the end time of the normalized reservation time window, the system compares the current time with the end time of the normalized reservation time window. If the current time is later than the end time of the normalized reservation time window, the system determines that the corresponding revocable reservation token has exceeded its valid time range and identifies the revocable reservation token as an expired revocable reservation token. For records identified as expired revocable reservation tokens, the system deletes them from the local policy table record unit to free up local storage space and prevent incorrect reference to expired reservations during subsequent reservation verification or emergency priority processing.

[0070] Step 73: While deleting the expired revocable reservation token, the system records the cleanup action as an event. Specifically, the system encapsulates the parking space number, reservation unique identifier, current time, and event timestamp corresponding to the expired revocable reservation token to form a cleanup record, and writes this cleanup record to the local event queue. This cleanup record, as part of an event sequence, is used to fully reflect the lifecycle changes of local reservation data to the cloud when subsequently reporting the event sequence online. The event timestamp is used to identify the specific time point when the cleanup action occurred, supporting subsequent tracing and verification of the reservation expiration time.

[0071] Through the aforementioned cleanup mechanism, this invention can continuously maintain the validity of the set of revocable reservation tokens in the local policy table recording unit within an intelligent parking lock management system that combines shared reservations and emergency control. On the one hand, timely removal of expired revocable reservation tokens helps avoid misjudging the reservation status during parking space occupancy verification, emergency priority determination, and conflict migration handling. On the other hand, by writing the cleanup process into the local event queue and incorporating it into event sequence management, the critical status change of reservation expiration also has traceable data records, providing a complete basis for unified cloud management, statistical analysis, and accounting processing, thus achieving refined management of the parking reservation data lifecycle.

[0072] In one embodiment of the present invention, based on determining the optimal relocation parking space, the candidate parking space set needs to undergo time conflict elimination before calculating the weighted distance value, including:

[0073] Step 81: Obtain the candidate parking space set. The candidate parking space set is a set of parking spaces that meet the basic migration conditions in terms of physical location, management scope, or system rules. For each candidate parking space in the candidate parking space set, the system locates the corresponding local policy table record unit based on the parking space number. The system extracts the normalized reservation start time and normalized reservation end time corresponding to all revocable reservation tokens from the local policy table record unit to construct the set of occupied reservation intervals for that candidate parking space in the time dimension.

[0074] Step 82: After extracting the reservation time intervals for candidate parking spaces, the system enters the time conflict judgment stage. The system compares the normalized start and end times of the original revocable reservation tokens corresponding to the conflict event with the normalized start and end times of each revocable reservation token for each candidate parking space. The system determines that a candidate parking space has a time conflict when the following time relationships exist: the normalized start time of the original revocable reservation token is no later than the normalized end time of a revocable reservation token for the candidate parking space, and the normalized end time of the original revocable reservation token is no earlier than the normalized start time of that revocable reservation token for the candidate parking space. These time relationships characterize the overlapping intervals between two normalized reservation time windows on the time axis. Once it is determined that at least one revocable reservation token for a candidate parking space overlaps with an original revocable reservation token on the normalized reservation time window, the system identifies the candidate parking space as having a time conflict and removes it from the candidate parking space set.

[0075] Step 83: After completing the time conflict elimination, the system performs a weighted distance calculation based on the eliminated candidate parking space set. The system calculates a weighted distance value for each eliminated candidate parking space and determines the optimal relocation parking space according to the magnitude of the weighted distance value. Subsequently, the system generates a new revocable reservation token based on the unique reservation identifier corresponding to the conflict event and writes the new revocable reservation token into the local policy table record unit corresponding to the optimal relocation parking space to complete the data reconstruction of the reservation migration on the local side.

[0076] Through the aforementioned time conflict elimination mechanism, this invention enables precise screening of candidate parking spaces in the time dimension within an intelligent parking lock management system that combines shared reservations and emergency control. On one hand, by excluding candidate parking spaces that are unavailable in terms of time before distance-weighted calculation, it avoids time overlap between relocated reservations and existing reservations, thereby reducing the probability of subsequent conflicts. On the other hand, this mechanism ensures that parking space relocation decisions not only rely on spatial distance factors but also comprehensively consider the continuity and feasibility of reservation times, contributing to improved rationality and stability of parking resource scheduling.

[0077] It should be noted that the range and threshold size are set for ease of comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data, as long as it does not affect the ratio between the parameter and the quantized value.

[0078] The embodiments of the present invention have been described above, but the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of the present embodiments, all of which are within the protection scope of the present embodiments.

Claims

1. An intelligent parking lock management system based on shared reservation and emergency control, characterized in that, include: The reservation token module is used to obtain user reservation information and system preset constants, generate a standardized reservation time window, generate a revocable reservation token and write it to the local policy table. The on-site lock-down module is used to verify the revocable reservation token against the local policy table. It performs lock-down when the parking space is vacant and the current time is within the normalized reservation time window; otherwise, it triggers conflict handling. The emergency priority module is used to obtain emergency request information and compare it with the priority of the revocable reservation token of the corresponding parking space. If emergency priority is granted, the parking space is allowed to proceed and the revocable reservation token is marked as frozen or revoked. The conflict migration module is used to generate conflict events based on freeze and cancellation flags, determine the optimal migration parking space according to the parking space distance weighted rule, and generate a new revocable reservation token to write to the local policy table. The mutual exclusion safety module is used to perform mutual exclusion and security checks on the lifting lock control commands. The lifting lock control command is executed when both mutual exclusion and security checks pass; otherwise, the lifting lock control command is rejected. The online settlement module is used to report event sequences online. The cloud performs idempotency verification on the event sequences, obtains the actual usage time and unused time from the event timestamp, and calculates the user's actual payable fee and refundable fee according to the system's basic rate. The timeout rollback module is used to determine whether a timeout has occurred by comparing the actual execution time of the emergency release action with the maximum allowed duration of the emergency action. If a timeout occurs, the retry priority comparison, near-field emergency credential whitelist verification, and mechanical redundancy channel release are performed in sequence.

2. The intelligent parking lock management system based on shared reservation and emergency control according to claim 1, characterized in that, User reservation information includes: parking space number, reservation start time, reservation end time, user ID, and revocable flag; The system preset constants include: first preset order, second preset order, early activation time, and delayed expiration time; The standardized reservation start time is obtained by adjusting the reservation start time forward to advance the effective period, and the standardized reservation end time is obtained by adjusting the reservation end time backward to delay the expiration period. The standardized reservation start time and the standardized reservation end time constitute a standardized reservation time window. The user identifier, parking space number, reservation start time, and reservation end time are concatenated in a first preset order and then a digest operation is performed to obtain a unique reservation identifier. The unique reservation identifier, parking space number, normalized reservation time window, and revocable identifier are concatenated in a second preset order and then a digest operation is performed to obtain a digest verification value. A revocable reservation token is generated and written to the record unit of the local policy table corresponding to the parking space number. When the same unique reservation identifier exists in the local policy table, the latest revocable reservation token replaces the original revocable reservation token and is stored in ascending order according to the reservation start time, reservation end time, and dictionary order of the unique reservation identifier.

3. The intelligent parking lock management system based on shared reservation and emergency control according to claim 1, characterized in that, Verify the revocable reservation token against the local policy table. If the parking space is available and the current time falls within the normalized reservation time window, perform lock reduction; otherwise, trigger conflict handling, including: Step 11: Obtain the parking space occupancy status and current time; locate the local policy table record unit based on the parking space number in the revocable reservation token; and search for a record with the same reservation unique identifier in the local policy table record unit; if no record is found, generate a conflict handling flag and write the conflict handling flag to the local event queue; the parking space occupancy status includes free and not free. Step 12: Extract the summary verification value from the retrieved record and compare it with the summary verification value in the revocable reservation token. Extract the normalized reservation start time and normalized reservation end time from the record to form a normalized reservation time window. Determine if the current time is not earlier than the normalized reservation start time and not later than the normalized reservation end time. If the consistency comparison is inconsistent, generate a conflict handling flag and write it to the local event queue. If the time relationship is not satisfied, generate a conflict handling flag and write it to the local event queue. The conflict handling flag includes the parking space number, unique reservation identifier, current time, parking space occupancy status, and conflict reason code. Step 13: If no conflict resolution flag is generated in steps 11 and 12, determine whether the parking space occupancy status is vacant; if the parking space occupancy status is vacant, perform lock reduction and write the record containing the reservation unique identifier and event timestamp into the local event queue as part of the event sequence; if the parking space occupancy status is not vacant, generate a conflict resolution flag and write it into the local event queue.

4. The intelligent parking lock management system based on shared reservation and emergency control according to claim 1, characterized in that, Obtain emergency request information and compare its priority with the corresponding revocable reservation token for the parking space. If the emergency request has priority, allow entry and mark the revocable reservation token as frozen or revoked, including: Step 21: Obtain emergency request information and locate the corresponding local policy table record unit based on the parking space number. Search the local policy table record unit for a revocable reservation token with the same reservation unique identifier. If no revocable reservation token is found, generate a conflict handling flag and write it to the local event queue. The emergency request information includes the parking space number, emergency request time, emergency priority, and emergency release type. Step 22: Extract the reservation priority and reservation start time from the revocable reservation token, and compare the emergency priority with the reservation priority; when the emergency priority is higher than the reservation priority, the emergency priority is determined; when the emergency priority and the reservation priority are the same, the emergency request time and the reservation start time are compared; if the emergency request time is earlier than the reservation start time, the emergency priority is determined; otherwise, the non-emergency priority is determined. Step 23: When emergency priority is determined, release is performed, which includes delocking; when the emergency release type is freeze mark, freeze mark is applied to the revocable reservation token; when the emergency release type is revocation mark, revocation mark is applied to the revocable reservation token, and the record containing the parking space number, reservation unique identifier, emergency release type, emergency request time and event timestamp is written into the local policy table record unit and the local event queue as part of the event sequence.

5. The intelligent parking lock management system based on shared reservation and emergency control according to claim 1, characterized in that, Conflict events are generated based on freeze and cancellation flags. The optimal relocation parking space is determined according to the parking space distance weighted rule. A new revocable reservation token is generated and written to the local policy table, including: Step 31: Retrieve the revocable reservation token with the same reservation unique identifier in the local policy table record unit corresponding to the parking space number, and determine whether the revocable reservation token has been marked with a freeze or cancellation flag; if a freeze or cancellation flag has been marked, generate a conflict event, and write the conflict event containing the parking space number, reservation unique identifier, freeze or cancellation flag, emergency request time and event timestamp into the local event queue as part of the event sequence. Step 32: Obtain the candidate parking space set and read the parking space number and availability status of each candidate parking space in the candidate parking space set. Multiply each distance metric value by its corresponding distance weight to obtain the distance product, and summarize to obtain the weighted distance value of the candidate parking spaces. Select the candidate parking space with the smallest weighted distance value as the optimal migration parking space. When there are candidate parking spaces with the same weighted distance value, determine the optimal migration parking space according to the lexicographical order of the parking space numbers. The distance metric value represents the distance between the candidate parking space and the migrated parking space. Step 33: Generate a new revocable reservation token based on the reservation unique identifier corresponding to the conflict event and the normalized reservation time window of the original revocable reservation token. Replace the parking space number of the new revocable reservation token with the parking space number of the optimal migration parking space. After generating a digest verification value for the new revocable reservation token, write it into the local policy table record unit corresponding to the optimal migration parking space. When the same reservation unique identifier exists in the local policy table record unit, replace the original revocable reservation token with the latest revocable reservation token and store them in ascending order according to the reservation start time, reservation end time, and dictionary order of the reservation unique identifier.

6. The intelligent parking lock management system based on shared reservation and emergency control according to claim 1, characterized in that, The lift lock control command undergoes mutual exclusion and security checks. The lift lock control command is executed only if both checks pass; otherwise, it is rejected. This includes: Step 41: Obtain the lifting lock control command and solidify the command type as lifting lock command or lowering lock command; locate the local policy table record unit according to the parking space number associated with the lifting lock control command; and obtain the parking space occupancy status and current time. Step 42: Read the command type to be executed in the local policy table record unit and perform mutual exclusion judgment with the command type of the lifting lock control command. If the command types are consistent, pass the mutual exclusion check. If the command types are inconsistent, reject the lifting lock control command and write the rejection record containing the parking space number, command type, current time and event timestamp into the local event queue. Step 43: When the mutual exclusion check passes, perform a security check on the lock-up command. If the parking space occupancy status is vacant and the current time is not earlier than the end time of the normalized reservation time window of the revocable reservation token, the security check passes and the lock-up command is executed. If the parking space occupancy status is not vacant, or the current time is earlier than the end time of the normalized reservation time window, the lock-up command is rejected. When the mutual exclusion check passes and the command type is a lock-down command, the lock-down command is executed, and the result record containing the parking space number, command type, current time, event timestamp, and result type is written to the local event queue. The result type takes a value in execution and rejection.

7. The intelligent parking lock management system based on shared reservation and emergency control according to claim 1, characterized in that, The event sequence is reported online, and the cloud performs idempotency verification on the event sequence. The actual usage duration and unused duration are obtained from the event timestamps. The actual fees payable by the user and the fees refundable by the user are calculated according to the system's basic rate, including: Step 51: Read all records associated with the unique reservation identifier in the local event queue, sort all records according to the order of event timestamps and encapsulate them into an event sequence, generate the sequence number corresponding to this event sequence and record the sequence number and the reporting time, and report the event sequence online to the cloud; Step 52: After receiving the event sequence, the cloud retrieves the historical sequence number and historical event summary based on the reservation unique identifier, compares the current sequence number with the historical sequence number, and generates an event summary from the event sequence. If the current sequence number is later than the historical sequence number and the current event summary is inconsistent with the historical event summary, it is checked for idempotency and written to the cloud event database; otherwise, writing is rejected. Step 53: After the idempotency verification is passed, the cloud extracts the event sequence according to the reservation unique identifier and reconstructs the event timeline according to the order of event timestamps. Based on the event type field, the event timeline determines the start and end timestamps of the occupied event. The difference between the end and start timestamps of the occupied event is determined as the actual usage time. The difference between the total duration corresponding to the normalized reservation time window and the actual usage time is determined as the unused time. The system base rate is multiplied by the actual usage time to obtain the user's actual payable fee. The system base rate is multiplied by the unused time to obtain the user's refundable fee.

8. The intelligent parking lock management system based on shared reservation and emergency control according to claim 1, characterized in that, The timeout is determined by comparing the actual execution time of the emergency release action with the maximum allowable duration of the emergency action. If a timeout occurs, the following steps are performed in sequence: retry priority comparison, near-field emergency credential whitelist verification, and release via the mechanical redundancy channel. Step 61: Based on the reservation unique identifier, read the record with event type "release" in the local event queue and extract its event timestamp as the release start time. Read the record with event type "lock reduction completed" in the local event queue and extract its event timestamp as the release completion time. Determine the time difference between the release completion time and the release start time as the actual execution time of the emergency release action. Associate the actual execution time of the emergency release action with the reservation unique identifier and write it into the local event queue. Step 62: Obtain the maximum allowed duration of emergency actions. Compare the actual execution time of the emergency release action with the maximum allowed duration of the emergency action. If the actual execution time of the emergency release action is greater than the maximum allowed duration of the emergency action, generate a timeout flag. If the actual execution time of the emergency release action is not greater than the maximum allowed duration of the emergency action, generate a non-timeout flag. Associate the generated flag with the parking space number, reservation unique identifier, emergency request time, and event timestamp, write it into the local event queue, and use it as part of the event sequence. Step 63: When a timeout flag is generated, the retry priority comparison, near-field emergency credential whitelist verification, and mechanical redundancy channel release are executed sequentially. The input for the retry priority comparison is the emergency request information and the revocable reservation token of the corresponding parking space. When the near-field emergency credential whitelist verification passes, the lock is deactivated and written to the local event queue. When the mechanical redundancy channel release is triggered, it is written to the local event queue, and a fallback record containing the parking space number, reservation unique identifier, emergency request time, event timestamp, and fallback link type is generated and written to the local event queue for the three types of fallback links. The fallback link type is determined by the values ​​in the retry priority comparison, near-field emergency credential whitelist verification, and mechanical redundancy channel release.

9. The intelligent parking lock management system based on shared reservation and emergency control according to claim 1, characterized in that, In addition to generating revocable reservation tokens and writing them to the local policy table record unit, the process also includes cleaning up expired revocable reservation tokens, including: Step 71: Obtain the current time, traverse the revocable reservation tokens in the local policy table record cell corresponding to the parking space number, and extract the normalized reservation time window end time of each revocable reservation token. Step 72: When the current time is later than the end time of the normalized reservation time window, the corresponding revocable reservation token is determined as an expired revocable reservation token, and the expired revocable reservation token is deleted from the local policy table record unit. Step 73: Encapsulate the parking space number, reservation unique identifier, current time and event timestamp corresponding to the expired revocable reservation token into a cleanup record, write it into the local event queue and as part of the event sequence.

10. The intelligent parking lock management system based on shared reservation and emergency control according to claim 5, characterized in that, Based on the determination of the optimal relocation parking space, the candidate parking space set needs to undergo time conflict elimination before calculating the weighted distance value, including: Step 81: Obtain the candidate parking space set, and locate the corresponding local policy table record unit for each candidate parking space in the candidate parking space set according to the parking space number, and extract the normalized reservation start time and normalized reservation end time of all revocable reservation tokens in the local policy table record unit. Step 82: Determine the time relationship between the normalized start time and normalized end time of the original revocable reservation token corresponding to the conflict event and the normalized start time and normalized end time of each candidate parking space's revocable reservation token. If there is a situation where the normalized start time of the original revocable reservation token is not later than the normalized end time of the revocable reservation token and the normalized end time of the original revocable reservation token is not earlier than the normalized start time of the revocable reservation token, then it is determined that the candidate parking space has a time conflict and the candidate parking space is removed from the candidate parking space set. Step 83: Calculate the weighted distance value for the candidate parking space set after elimination and determine the optimal relocation parking space. Generate a new revocable reservation token and write it into the local policy table record unit corresponding to the optimal relocation parking space.

Images