A multi-source event graph-driven warehouse gate double-phase token opening and closing control method

Abstract

The present application belongs to the technical field of logistics automation management, and discloses a warehouse checkpoint double-phase token opening and closing control method driven by multi-source event graph. First, multi-source events are received and standardized processing is performed, and then the events are mapped into event graphs and corresponding version numbers are generated. Based on event triggering, a passage application and a unique identifier are generated, and based on multi-factor comprehensive scoring, it is determined whether to release. The pre-token is issued for the application that passes the scoring. After the pre-token verification passes, the channel resources are occupied. When the channel occupation passes the scoring determination and it is determined that the access control can be passed, the submission token is issued and verified in time. The device command is issued by consuming the submission token. The access control device is opened and the door closing submission token is issued after the opening and closing loop meets the requirements. After the verification and consumption, the door is closed and the resource lock is released. The present application realizes the separation of resource occupation and action execution, the validity of the pre-token can be directly changed by business change, and the possibility of error in access control management is reduced.

Description

Technical Field

[0001] This invention belongs to the field of logistics automation management technology, specifically relating to a warehouse gate dual-phase token opening and closing control method driven by multi-source event graph. Background Technology

[0002] In existing technologies, gate control is disconnected from business status. Current solutions often rely on license plate recognition results or manual button presses as trigger conditions, failing to fully integrate business events such as transport reservations, waybill status, driver identity, warehouse platform status, loading / unloading tasks, queue management, and entry / exit directions. This easily leads to problems like vehicles being released without reservations, vehicles arriving at the wrong warehouse or gate, and vehicles leaving before loading / unloading is complete. While existing technologies utilize event status as trigger conditions to generate gate opening commands, in the logistics field, network latency, interface retries, repeated driver scanning, multiple license plate recognition triggers, and repeated operations by gate personnel can result in multiple gate opening commands for the same vehicle and the same business document, causing repeated gate openings, accidental gate openings, gate occupancy conflicts, or multiple vehicles following each other. Furthermore, the system's equipment control lacks a closed loop. The system does not continuously receive feedback from equipment execution results, gate status, vehicle passage detection, camera captures, inductive loops, and weighbridge weighing, making it impossible to confirm whether a passage is truly completed or to identify anomalies such as vehicles not entering after gate opening, equipment not responding, or gates not closing. In summary, existing access control token-based technologies tie resource reservation and action execution to the same token, lack hierarchical authorization verification, and cannot immediately change the token's validity after business changes, leading to frequent access control management errors. Summary of the Invention

[0003] The purpose of this invention is to provide a warehouse gate access control method driven by a multi-source event graph, which solves the technical problems of existing technologies that bind resource reservation and action execution to the same token, lack hierarchical authorization verification, and cannot immediately change the validity of the token after business changes, resulting in frequent access control management errors.

[0004] The multi-source event graph-driven warehouse gate dual-phase token opening and closing control method first receives and standardizes multi-source events, then maps the events to an event graph and generates corresponding version numbers. Based on event triggers, it generates access requests and unique identifiers, and determines whether to grant access based on a multi-factor comprehensive score. For requests that pass the score, a pre-token is issued. After the pre-token is verified, it occupies channel resources. When channel occupancy is determined by a score indicating that access is possible, a submission token is issued and verified promptly. The submission token is consumed to issue device commands. The access control device's door opening closed-loop requirements are simultaneously met: the device returns a successful door opening, the door sensor or barrier gate status changes to open, the channel detects the target vehicle starting to pass, and no abnormal following is detected. After meeting these requirements, the door opens and a closing submission token is issued. After verification and consumption, the door closes and the resource lock is released. The method includes the following steps: Step 1: Event reception, queuing, and standardized processing; Step 2: Event graph construction and graph version update; Step 3: Pass application generation and unique identifier calculation; Step 4: Multi-dimensional verification of eligibility; Step 5: State machine control of the dual-phase gated token; Step 6: Pre-token issuance, holding, and verification; Step 7: Channel occupancy determination; Step 8: Submit token issuance, verification, and one-time consumption; Step 9: Device path selection, token verification, and command generation; Step 10: Device command closed-loop and receipt verification.

[0005] Preferably, in step 1, events are received and written into an event queue to generate standard business events; in step 2, the standard business events are mapped into an event graph, which includes a set of nodes, a set of edges, and a set of edge weights. The set of nodes includes at least reservation nodes, waybill nodes, vehicle nodes, driver nodes, gate nodes, equipment nodes, channel occupancy nodes, feedback nodes, risk nodes, and audit nodes; the set of edges includes at least ownership edges, allocation edges, occupancy edges, feedback edges, locking edges, and audit edges; when a new event is added to the event queue, the graph nodes and edges are updated according to the event content, and a graph version number is generated.

[0006] Preferably, in step 3, if the received event triggers a passage request, a passage request is generated based on the event graph. Repeated operations under the unique identifier of the same passage request only update the event version and status record. In step 4, the passage request is checked for four types of verification: vehicle identity, business status, gate matching, and risk status. A comprehensive release score is calculated based on the factors of the four types of verification and then compared with the automatic release threshold. If the comprehensive release score is higher than the automatic release threshold and there are no strong rejection conditions, the process proceeds to the pre-token generation step. If the comprehensive release score is within the manual review range, the request is changed to a pending manual confirmation status. If the comprehensive release score is lower than the rejection threshold or there are strong rejection conditions, passage is rejected.

[0007] Preferably, in step 5, a state machine with a dual-phase token is maintained for each passage application. The state machine achieves state transitions through state transition functions. The authorization verification function takes the token as input. Only when the authorization verification function returns a pass and the resource lock or one-time consumption write is completed, is it allowed to enter the subsequent state or generate a device command. The token states include: S0 pending trigger, S1 pending verification, S2 verification passed / pending pre-token authorization, S3 pre-token verification passed / resource occupied, S4 channel pending clearing, S5 submitted token verification passed / pending issuance, S6 command issued, S7 door open, S8 vehicle passing, S9 passage completed / pending door closing authorization, S10 door closing submitted token verification passed / door closing command issued, S11 door closed, S12 abnormal pause, S13 passage refused, S14 manual release. After step 4 is executed, the pre-token generated by the state machine transitions from state S1 to state S2.

[0008] Preferably, in step 5, the state transition function is as follows: S_next = f(S_current, Event, Guard, Timeout, GraphVersion,TokenState) Wherein, S_next represents the new state, S_current is the current state, Event is the triggering event, Guard is the transition guard condition, Timeout is the timeout condition, GraphVersion is the event graph version, and TokenState is the token state; Guard includes at least the token holding relationship, token digest, validity period, graph version number (GraphVersion consistency), resource lock number, one-time consumption flag, and latest device / channel evidence; TokenState includes at least the following states: unissued, issued and awaiting holding, held and awaiting verification, verified, consumed, released, revoked, and expired; the server is prohibited from executing across states; the authorization verification function takes the token as input, and only when the authorization verification function returns successfully and the resource lock or one-time consumption write is completed is it allowed to enter the subsequent state or generate device commands.

[0009] Preferably, in step 6, when the state machine is in state S2, the server issues a pre-token based on the access request. After the authorization verification function of the pre-token returns a pass, an occupancy record is written into the resource lock table based on the information of the pre-token. The corresponding authorization verification function verifies the following for the pre-token: the pre-token has not expired or been revoked; the unique identifier of the access request bound to it is consistent with the current access request; the bound map version number is not behind the current valid map version; the gate and lane are not occupied by other valid tokens; and the vehicle, direction, actuator, and expected action are consistent with the current request. In step 7, sensor signals are read, and the lane occupancy score O_lane is calculated using the formula: O_lane = Σ(s_i × w_i), where s_i is the occupancy signal of the i-th sensor and w_i is the corresponding weight; the server determines the channel to be cleared only when the current access request holds a verified pre-token P_token and the channel occupancy score O_lane is lower than the clearing threshold θ_clear for N consecutive frames; if the channel is not cleared or the pre-token P_token verification fails, the state remains in state S4 channel waiting to be cleared or rolls back to state S12 abnormal pause, and the generation of submission tokens is not allowed.

[0010] Preferably, in step 8, when the state machine is in state S4 (channel pending clearing), and the pre-token is still in the verified and resource-occupied state, the channel is cleared, the device is in the executable state, and the security interlock is passed, the server issues an opening submission token. The opening submission token is a one-time token. The opening submission token is bound to the opening action, the device path, the channel clearing evidence, and the security interlock result. For the opening submission token, the guard condition for the state machine to enter S5 from S4 is that the corresponding authorization verification function returns a pass. The verification content of the corresponding authorization verification function for the opening submission token includes: the pre-token is still in the verified and resource-occupied state, the opening submission token has not expired and has not been consumed, the channel clearing evidence is still within the allowed freshness window, the device is online and the action type is opening, the security interlock has not been triggered, and the graph version number has not changed to cause a refusal to pass. After the verification is passed, the opening submission token enters the verified / pending consumption state. Before the device command is generated, the device adaptation service still needs to perform consumption verification.

[0011] Preferably, in step 9, the formula for calculating the equipment path selection result is as follows: (The formula is not provided in the original text.) Path = argmax(u1·compatibility + u2·safety + u3·latency - u4·conflict) Wherein, Path represents the device path; compatibility represents protocol compatibility; safety represents security; latency represents response delay; and conflict represents conflict risk; u1, u2, u3, and u4 are the factor weights of the corresponding factors, respectively; a standard device command to be verified is generated based on the device path Path. Before converting to a specific device protocol, the token verification service must be called to perform verification on the submitted token for validity period, one-time consumption, graph version number, resource lock, device status, and action type; after the verification is passed, the submitted token status is set to consumed and the command number is bound in an atomic manner.

[0012] Preferably, in step 10, a standard device command that has passed token verification is sent to the device adapter; wait for device confirmation according to the command identifier; in this step, the door opening closed-loop requirements must be met simultaneously: the device returns a successful door opening, the door sensor or barrier gate status changes to open, the channel detects the target vehicle starting to pass, and no abnormal following vehicle is detected; when the vehicle passage evidence meets the passage completion conditions, the state machine enters state S9 Passage Complete / Waiting for Door Closing Authorization state; the server issues a door closing submission token, which is bound to the consumed door opening submission token, vehicle passage evidence, channel clearing evidence before door closing, device readiness evidence, and security area detection result. The closing action; the guard condition for the state machine to enter state S10 from state S9 is that the corresponding authorization verification function returns successfully, and the device adaptation service consumes the token once before issuing the closing command; the closing loop requirements must be met simultaneously: the device returns that the closing was successful, the door sensor or barrier gate status changes to closed, no vehicle is detected to be stuck, and no personnel or vehicles are found to be in a dangerous area; only when the receipt verification passes, and the command number, device number, and token digest in the receipt are consistent with the consumed and submitted token, will the server advance the state machine; if the receipt times out, the state is inconsistent, the token digest is inconsistent, or an anomaly is detected, the server enters the anomaly rollback process.

[0013] Preferably, the warehouse gate dual-phase token opening and closing control method driven by multi-source event graph further includes the following steps: Step 11, Abnormal Rollback and Token Expiration: Before the device performs the door opening and closing actions, the abnormal risk score is calculated as follows: A_risk = ρ1A_biz + ρ2A_device + ρ3A_pass + ρ4A_security + ρ5A_timeout Wherein, A_biz: business anomaly risk component, A_device: device anomaly risk component, A_pass: passage anomaly risk component, A_security: security anomaly risk component, A_timeout: timeout anomaly risk component; ρ1, ρ2, ρ3, ρ4, ρ5 are the weights of each corresponding risk component; when the anomaly risk score A_risk exceeds the high-risk threshold, the server locks the gate and requires manual handling; when the device fails to open the gate, the server rolls back the corresponding submission token from state S6 to state S5 or state S12, and decides whether to allow the original command query or reissue a new submission token based on whether the submission token has been consumed; when the vehicle does not pass and the token times out, the server rolls back the corresponding submission token from state S7 to state S12, and invalidates the corresponding pre-token, gate opening submission token, and unused gate closing submission token; when the business status changes before the gate is opened, the pre-token is revoked, the resource lock is released, and the system switches to denying passage or awaiting manual confirmation.

[0014] This invention has the following advantages: It uses business events as the triggering condition for access control and integrates business status with access control tokens. At the token level, it decouples the conventional token form into pre-tokens and submission tokens. The pre-token does not directly drive device actions but is used as an authorization credential for resource occupation and submission tokens. Therefore, it separates resource occupation from action execution. Business changes can directly change the validity of the pre-token and immediately block the generation of submission tokens. The entire authorization process is strictly limited to a series of linear authorization processes: pre-occupancy, channel clearing, token consumption, and device action. This achieves a reliable and secure closed-loop management process, thereby reducing the possibility of errors in access control management.

[0015] Furthermore, by binding tokens to the hash version of the dynamic business graph, version consistency is forcibly verified at every step of the state machine transition. Even if the token is not explicitly revoked, outdated business states cannot drive subsequent actions, thus solving the problem of control and business separation at the source. Simultaneously, by forcibly binding token consumption to device commands, and combining this with four-fold verification using device receipts, door sensors, ground sensors, and cameras, duplicate commands and the risk of unauthorized follow-up are effectively prevented. This invention also transforms exception handling into a computable automatic scoring and rollback mechanism, coupled with an immutable hash audit chain, ensuring that every erroneous operation can be accurately traced back to the specific token verification stage. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the overall process of a multi-source event graph-driven dual-phase token opening and closing control method for warehouse gates according to the present invention. Figure 2 This is a lifecycle flowchart of the dual-phase gated token in this invention; Figure 3 This is a state transition flowchart of the dual-phase token state machine in this invention; Figure 4 This is a flowchart of the channel occupancy determination and device path selection in this invention; Figure 5 This is a flowchart of the closed-loop control and acknowledgment verification of device commands in this invention; Figure 6 This is a flowchart of abnormal rollback and token invalidation in this invention. Detailed Implementation

[0017] The following detailed description of the embodiments, with reference to the accompanying drawings, will further illustrate the specific implementation of the present invention, in order to help those skilled in the art to have a more complete, accurate, and in-depth understanding of the inventive concept and technical solution of the present invention.

[0018] like Figures 1-6 As shown, this invention provides a warehouse gate access control method driven by a multi-source event graph. First, it receives and standardizes multi-source events, then maps the events to an event graph and generates corresponding version numbers. Based on event triggers, it generates access requests and unique identifiers. Based on a multi-factor comprehensive scoring system, it determines whether to allow access and issues pre-tokens to requests that pass the scoring. After the pre-token is verified, it occupies channel resources. When channel occupancy is determined by the scoring system to allow passage, it issues and verifies a submission token, consumes the submission token, and issues device commands. The access control device's door opening closed-loop requirements are simultaneously met: the device returns a successful door opening, the door sensor or barrier gate status changes to open, the channel detects the target vehicle starting to pass, and no abnormal following is detected. After meeting these requirements, the door opens and a closing submission token is issued. After verification and consumption, the door closes and the resource lock is released.

[0019] The control method specifically includes the following steps: Step 1: Event reception, queuing, and standardized processing.

[0020] In this step, the server used for gate control receives appointment events, waybill events, vehicle events, driver events, warehouse operation events, equipment events, and human events, and writes them into the event queue Q_event.

[0021] The server generates standard business events (Events) based on the event source, business type, vehicle, driver, document, warehouse, gatekeeper, direction, timestamp, and original payload. The expression for a standard business event (Event) is as follows: Event={event_id,source_type,business_type,vehicle_no,driver_id,order_id,warehouse_id,gate_id,direction,event_time,payload,confidence,version} Among them, event_id: unique event ID, source_type: event source type, business_type: business event type, vehicle_no: license plate number, driver_id: driver identification, order_id: reservation order number, warehouse_id: warehouse number, gate_id: gate number, direction: passage direction (entry / exit), event_time: event occurrence timestamp, payload: original event payload, retaining complete additional data from the source system, confidence: event confidence, and version: event structure version number.

[0022] The server merges events from the same vehicle, the same gate, and within the same time window, and calculates the event credibility C_event. The formula is as follows: C_event = α1C_plate + α2C_order + α3C_driver + α4C_gate + α5C_device Wherein, C_plate represents the reliability of license plate recognition, C_order represents the reliability of reservation or waybill status, C_driver represents the reliability of driver identity, C_gate represents the reliability of vehicle matching with warehouse gate, and C_device represents the reliability of device feedback.

[0023] Step 2: Event graph construction and graph version update.

[0024] In this step, the server maps standard business events to an event graph G_t. The event graph includes a node set V_t, an edge set E_t, and an edge weight set W_t, expressed as: G_t = (V_t, E_t, W_t). The node set V_t includes at least reservation nodes, waybill nodes, vehicle nodes, driver nodes, gate nodes, equipment nodes, channel occupancy nodes, feedback nodes, risk nodes, and audit nodes. The edge set E_t includes at least ownership edges, allocation edges, occupancy edges, feedback edges, locking edges, and audit edges.

[0025] When a new event is added to the event queue, the server updates the graph nodes and edges based on the event content and generates a graph version number. The expression is: GraphVersion(t+1) = Hash(GraphVersion(t) || Event_id || EdgeDelta) Here, EdgeDelta represents the node or edge change caused by this event, Event_id is the number of the corresponding standard business event, GraphVersion(t) is the t-th graph version number, and Hash represents the conversion to a hash code. Using the graph version number, subsequent tokens and device commands can be traced back to the business state at the time of generation.

[0026] Step 3: Pass application generation and unique identifier calculation.

[0027] In this step, if the received event triggers a pass request, the server generates a pass request (PassRequest) based on the vehicle node, driver node, reservation node, waybill node, gate node, and direction information in the event graph. The expression is as follows: PassRequest = {request_id, vehicle_no, driver_id, order_id,warehouse_id, gate_id, direction, expected_time_window, graph_version, risk_state, device_group, request_version} Among them, request_id: unique application number, vehicle_no: license plate number, driver_id: driver identification, order_id: reservation order number, warehouse_id: warehouse number, gate_id: gate number, direction: passage direction (entry / exit), expected_time_window: expected passage time window, graph_version: graph version number, risk_state: risk status identifier, device_group: device group identifier, request_version: application structure version number.

[0028] The server also generates a unique identifier K_pass for the pass application based on the vehicle, business document, warehouse, gate, direction, time window, and map version. The expression is as follows: K_pass = Hash(vehicle_no || order_id || warehouse_id || gate_id || direction || expected_time_window || graph_version).

[0029] For duplicate scans, duplicate license plate recognitions, interface retries, or manual clicks under the same unique identifier K_pass for a pass application, no new pass application will be generated; only the event version and status record will be updated.

[0030] Step 4: Multi-dimensional verification of eligibility.

[0031] In this step, the server performs four types of verifications on the passage application: vehicle identity, business status, gatekeeper matching, and risk status, and calculates the comprehensive release score S_pass. The formula for the comprehensive release score S_pass is: S_pass = η1F_vehicle + η2F_biz + η3F_gate + η4C_event - η5R_risk Wherein, F_vehicle is the vehicle identity verification factor, F_biz is the business status verification factor, F_gate is the gatekeeper matching factor, R_risk is the risk deduction factor, and C_event is the event credibility; η1, η2, η3, η4, and η5 are the corresponding factor weights in turn.

[0032] The formula for the vehicle identity verification factor F_vehicle is as follows: F_vehicle = β1I_plate_order + β2I_plate_file + β3I_vehicle_status + β4I_blacklist, Wherein, I_plate_order: an indicator function for whether the license plate matches the reservation order / waybill; I_plate_file: an indicator function for whether the license plate matches the file / system whitelist; I_vehicle_status: an indicator function for whether the vehicle status is normal; I_blacklist: an indicator function for whether the vehicle is on the blacklist; β1, β2, β3, and β4 are the corresponding weight coefficients in order.

[0033] The formula for the business status verification factor F_biz is as follows: F_biz = γ1I_appointment + γ2I_order + γ3I_task + γ4I_queue + γ5I_finish Wherein, I_appointment: an indication function indicating whether the appointment is valid and within the allowed time window; I_order: an indication function indicating whether the waybill is valid and incomplete; I_task: an indication function indicating whether the warehouse operation task (such as loading and unloading task) is ready; I_queue: an indication function indicating whether the vehicle has been called in the queue; I_finish: an indication function indicating whether the business preconditions (such as an appointment before entry and loading and unloading completed before exit) are met; γ1, γ2, γ3, and γ4 are the corresponding weight coefficients in order.

[0034] The formula for the gate matching factor F_gate is as follows: F_gate = I(gate_real = gate_plan) × exp(-d_gate / D_gate) Where, I(gate_real = gate_plan): an indicator function for whether the actual gate arrival matches the reserved / planned gate, d_gate: the deviation distance between the actual gate and the planned gate, D_gate: the normalized distance threshold for gate deviation, and exp represents the natural exponential function.

[0035] The formula for the risk deduction factor R_risk is as follows: R_risk = δ1R_repeat + δ2R_tail + δ3R_device + δ4R_manual + δ5R_conflict Among them, R_repeat: repeated request risk factor, R_tail: following vehicle risk factor, R_device: equipment malfunction risk factor, R_manual: manual intervention risk factor, R_conflict: conflict risk factor, reflecting the risks of multiple vehicles concurrently at the same gate, directional conflicts, or resource lock competition; δ1, δ2, δ3, δ4, δ5 are the corresponding weight coefficients in order.

[0036] If the overall pass score S_pass is higher than the automatic pass threshold θ_auto and there are no strong rejection conditions, the server enters the pre-token generation step; if the overall pass score S_pass is within the manual review range, the server will change the request to a pending manual confirmation status; if S_pass is lower than the rejection threshold or there are strong rejection conditions such as a blacklist, no valid business documents, or gatekeeper mismatch, the server will refuse passage.

[0037] Step 5: State machine control of the dual-phase gated token.

[0038] In this step, the server maintains a state machine for each access request using a two-phase token. The state machine implements state transitions through state transition functions.

[0039] Token status includes: S0 Pending trigger, S1 Pending verification, S2 Verification passed / Pending pre-token authorization, S3 Pre-token verification passed / Resources occupied, S4 Channel to be cleared, S5 Submitted token verification passed / Pending issuance, S6 Instruction issued, S7 Door opened, S8 Vehicle passing, S9 Passage completed / Pending door closing authorization, S10 Door closing token verification passed / Door closing instruction issued, S11 Door closed, S12 Abnormal pause, S13 Passage refused, S14 Manual release.

[0040] The state transition function is as follows: S_next = f(S_current, Event, Guard, Timeout, GraphVersion,TokenState) Here, S_next represents the new state, S_current is the current state, Event is the triggering event, Guard is the transition guard condition, Timeout is the timeout condition, GraphVersion is the event graph version, and TokenState is the token state. A Guard must include at least the token holding relationship, token digest, expiration date, GraphVersion consistency, resource lock number, one-time consumption flag, and latest device / channel evidence. Servers are prohibited from executing across states; for example, a server cannot enter a resource-occupied state without holding and verifying a pre-token, cannot issue an open command without verifying a submitted token, and cannot issue a close command without verifying a closed submitted token.

[0041] The token state (TokenState) includes at least the following states: unissued, issued and awaiting holding, held and awaiting verification, verified, consumed, released, revoked, and expired. Each state transition records the token input, verification result, and transition reason. The token state and the state machine state are updated through the same transaction or a transaction group with idempotent constraints.

[0042] In this method, the state machine does not automatically enter the next authorized state upon token generation. The token service first issues the token, and then the state machine or device adaptation service executes the authorization verification function VerifyToken() with the token as input. Only when the authorization verification function VerifyToken() returns successfully and the resource lock or one-time consumption write is completed is it allowed to enter the subsequent state or generate device commands.

[0043] After step 4 is executed, the pre-token generated by the state machine transitions from state S1 to state S2.

[0044] Step 6: Pre-token issuance, holding, and verification.

[0045] In this step, when the state machine is in state S2 verification passed / awaiting pre-token authorization, the server issues a pre-token P_token based on the access request. The expression is as follows: P_token = Hash(K_pass || graph_version || gate_id || lane_id ||direction || pre_state || resource_lock_key || expire_time || nonce) Where, lane_id: lane number, pre_state: current lifecycle state of the pre-token, esource_lock_key: unique identifier key for the resource lock, expire_time: token expiration timestamp, nonce: random number.

[0046] When the server writes the pre-token P_token to the token table, the token status is "issued and awaiting holding," and the token holder is the corresponding PassRequest. The pre-token does not directly drive device actions; instead, it serves as an authorization credential for entering the resource-occupied state (S3) and for subsequently generating and submitting the token. The guard condition for the state machine to transition from state S2 to state S3 is not that the pre-token P_token has been generated, but rather that the authorization verification function for the pre-token returns "passed." The corresponding expression is: VerifyToken(P_token, K_pass, GraphVersion, resource_lock_key, action=pre_authorize), where action is the action type, and pre_authorize indicates pre-authorization.

[0047] The above-mentioned authorization verification function VerifyToken verifies the following for the pre-token P_token: the pre-token P_token has not expired or been revoked; the bound access application unique identifier K_pass is consistent with the current access application; the bound graph version number GraphVersion is not behind the current valid graph version; the gate and lane are not occupied by other valid tokens; and the vehicle, direction, actuator, and expected action are consistent with the current application.

[0048] When the verification is successful, the server writes an occupancy record in the resource lock table with gate_id, lane_id, direction, and actuator_id as unique keys, so that the pre-token P_token actually controls whether the access request is allowed to enter state S3.

[0049] The lifecycle of a pre-token includes holding, renewal, release, and expiration. Once the pre-token P_token is successfully verified, other candidate applications at the same gate, in the same lane, and in the same direction cannot enter state S3. When the gate opening / closing process is completed, the service is rejected, manually canceled, timed out, or an abnormal rollback occurs, the server releases the resource lock and sets the pre-token P_token to released, revoked, or expired. A pre-token P_token that has failed verification or has been released cannot be used as the hash input or authorization basis for the submission token C_toke.

[0050] Step 7: Channel occupancy determination.

[0051] In this step, the server reads signals from sensors such as inductive loops, door magnets, cameras, infrared detectors, and weighbridges, and calculates the channel occupancy score O_lane. The formula is: O_lane = Σ(s_i × w_i), where s_i is the occupancy signal of the i-th sensor and w_i is the corresponding weight.

[0052] The server determines that a channel is cleared only if the current pass request holds a verified pre-token P_token and the channel occupancy score O_lane is below the clearing threshold θ_clear for N consecutive frames. If the channel is not cleared or the pre-token P_token verification fails, the state remains in state S4 (channel pending clearing) or rolls back to state S12 (abnormal pause), and the generation of a submit token is not allowed.

[0053] Step 8: Submit token issuance, verification, and one-time consumption.

[0054] In this step, when the state machine is in state S4 (channel pending clearing), and the pre-token P_token is still in the verified and resource-occupied state, the server issues an open submission token when the channel is cleared, the device is in the executable state, and the security interlock is successful. Submission tokens include open submission tokens and close submission tokens. The expression for the open submission token C_token_open is: C_token_open = Hash(P_token || occupancy_clear_evidence || device_ready_evidence || safety_ok || action=open || expire_time || nonce) Among them, occupancy_clear_evidence: evidence of channel clearing, device_ready_evidence: evidence of device readiness, and safety_ok: safety interlock verification passed indicator.

[0055] The door opening submission token is bound to the door opening action, device path, channel clearing evidence, and security interlock result. When the server writes the door opening submission token C_token_open to the token table, the token status is "issued but awaiting verification," but it does not directly trigger a device action. For the door opening submission token, the guard condition for the state machine to transition from S4 to S5 is that the corresponding authorization verification function returns "pass." The corresponding authorization verification function is: VerifyToken(C_token_open, P_token, latest_occupancy, latest_device_state, action=open), where latest_occupancy: the latest channel occupancy status, and latest_device_state: the latest device state.

[0056] The authorization verification function VerifyToken verifies the following for the door opening submission token C_token_open: the pre-token P_token is still in a verified and resource-occupied state; the door opening submission token C_token_open has not expired and has not been consumed; the channel clearing evidence is still within the allowed freshness window; the device is online and the action type is open; the security interlock has not been triggered; and the graph version number GraphVersion has not changed to cause a denial of passage. After successful verification, the door opening submission token C_token_open enters the verified / pending consumption state; consumption verification still needs to be performed by the device adaptation service before the device command is generated.

[0057] In this step, if the device is not ready, the channel is re-occupied, the security interlock fails, or the pre-token P_token expires, the door opening submission token C_token_open will fail verification, and the pre-token P_token will remain pending, released, or expire. The door opening submission token C_token_open is a one-time token. After the device adaptation service consumes it and binds it to the command number (command_id), the same door opening submission token C_token_open can only be used to query the original command or process the original command receipt; it cannot trigger a new door opening action again.

[0058] Step 9: Device path selection, token verification, and command generation.

[0059] In this step, the server selects the device path based on the device capability profile D_cap. The device capability profile includes at least the protocol type, actuator type, feedback mode, door closing receipt method, security lock capability, response latency threshold, and anomaly recovery capability.

[0060] The formula used by the server to calculate the device path selection result is: Path = argmax(u1·compatibility + u2·safety + u3·latency - u4·conflict) Where Path represents the device path; compatibility represents protocol compatibility; safety represents security; latency represents response delay; and conflict represents conflict risk; u1, u2, u3, and u4 are the factor weights of the corresponding factors, respectively.

[0061] The server generates a standard device command to be verified based on the device path, as shown in the following expression: Command = {command_id, token_type, C_token_digest, device_id, gate_id, action, priority, timeout, retry_count, callback_url, token_verify_result} Wherein, command_id: command number, token_type: token type identifier, C_token_digest: submission token digest, device_id: target device number, action: action type, priority: command priority, timeout: command timeout, retry_count: maximum number of retries, callback_url: callback address, and token_verify_result: token verification result snapshot, recording the complete verification result of VerifyToken() executed on the submission token before the command was generated.

[0062] Before converting to a specific device protocol, the device adapter must call the token verification service to perform validations on the submitted token (such as C_token_open or C_token_close) for validity period, one-time consumption, graph version number (GraphVersion), resource lock, device status, and action type. Upon successful validation, the submitted token's status is atomically set to consumed and bound to the command number (command_id). For gates, roller shutters, or access controllers whose native protocols do not support token fields, the device adapter, acting as the token control execution layer, stores and verifies the token, sending only its recognizable open or close signals to the physical device. If token verification fails, the adapter must not send any action signals to the device.

[0063] Step 10: Device command closed-loop and receipt verification.

[0064] In this step, after the server sends a standard device command (Command) that has been verified with a token to the device adapter, it waits for the device to respond according to the command identifier. The door opening closed-loop requirements must be met simultaneously: the device returns a successful door opening response, the door sensor or barrier gate status changes to open, the passage detects the target vehicle starting to pass, and no abnormal following is detected. The door closing closed-loop requirements must be met simultaneously: the device returns a successful door closing response, the door sensor or barrier gate status changes to closed, the ground loop detector does not detect a vehicle remaining, and the infrared or camera does not detect personnel or vehicles in a dangerous area.

[0065] The server will only advance the state machine if the receipt verification passes and the command number, device number, and token digest in the receipt are consistent with the consumed and submitted token; if the receipt times out, the state is inconsistent, the token digest is inconsistent, or an anomaly is detected, the server will enter the anomaly rollback process.

[0066] After the door-opening action is performed, this step further implements the generation, verification, and release of the door-closing submission token. Once the vehicle passes through and the conditions for passage are met, the state machine enters state S9, Passage Completed / Pending Gate Closing Authorization. The server issues a gate closing submission token C_token_close. The expression is as follows: C_token_close = Hash(C_token_open || pass_evidence || close_clear_evidence || device_ready_evidence || safety_ok || action=close || expire_time|| nonce) Among them, pass_evidence: evidence of vehicle passage, close_clear_evidence: evidence of the passage being cleared before the door is closed, and action=close: the action type is closing the door.

[0067] The door-closing submission token C_token_close is bound to the consumed door-opening submission token, vehicle passage evidence, passage clearing evidence before closing evidence, device readiness evidence, security area detection result, and the door-closing action. The guard condition for the state machine to transition from state S9 to state S10 is that the corresponding authorization verification function returns "pass," and the device adaptation service consumes the token once before issuing the door-closing command. The corresponding authorization verification function is: VerifyToken(C_token_close, C_token_open, latest_occupancy, latest_device_state, action=close).

[0068] If the gate closing submission token verification fails, there are vehicles or personnel in the channel, the equipment is offline, the token has expired, or it has been consumed, the server must not issue a gate closing command and will enter state S12 abnormal suspension or state S14 manual confirmation. If the gate closing receipt and the channel no-delay verification pass, the state machine enters state S11 gate is closed, the server releases the resource lock corresponding to the pre-token P_token, sets the gate closing submission token C_token_close to completed, and makes the opening and closing tokens on this passage chain unusable again.

[0069] This method also includes the following steps: Step 11: Abnormal rollback and token invalidation.

[0070] Before the equipment performs actions such as opening or closing the door, the abnormal risk score A_risk is calculated, as follows: A_risk = ρ1A_biz + ρ2A_device + ρ3A_pass + ρ4A_security + ρ5A_timeout Wherein, A_biz: business anomaly risk component, A_device: device anomaly risk component, A_pass: access anomaly risk component, A_security: security anomaly risk component, A_timeout: timeout anomaly risk component; ρ1, ρ2, ρ3, ρ4, ρ5 are the weights of the corresponding risk components in order.

[0071] When the abnormal risk score A_risk exceeds the high-risk threshold, the server locks the gate and requires manual intervention. When the device fails to open the gate, the server rolls back the corresponding submission token from state S6 to state S5 or state S12, and decides whether to allow the original command query or reissue a new submission token depending on whether the submission token has been consumed. When the vehicle fails to pass and the token times out, the server rolls back the corresponding submission token from state S7 to state S12, and invalidates the corresponding pre-token P_token, the gate opening submission token C_token_open, and the unused gate closing submission token C_token_close. When the business status changes before the gate is opened, such as the waybill being canceled or the vehicle being added to the blacklist, the server revokes the pre-token, releases the resource lock, and switches to denying passage or awaiting manual confirmation.

[0072] Step 12: Business status write-back and audit traceability.

[0073] After passage is completed, the server will write back the vehicle's actual entry or exit time, gate number, equipment number, captured image number, passage result, and abnormal marker to the reservation system, TMS, WMS, ERP, or park management system.

[0074] The server stores a complete audit chain for each pass request, expressed as follows: H_n = Hash(H_n-1 || event_id || graph_version || K_pass || P_token ||C_token_open || C_token_close || token_verify_result || command_id || device_feedback || timestamp) Wherein, H_n: the hash value of the nth audit record, H_n-1: the hash value of the previous audit record, event_id: the original standard event number, device_feedback: the device feedback summary, and timestamp: the timestamp of the audit record.

[0075] The audit chain records include the original business event, event graph version, verification results, pre-token, submission token, device instructions, device feedback, vehicle passage evidence, manual processing records, and business write-back results. Any supplementary entries, manual releases, or status corrections generate a new version and do not overwrite the original records.

[0076] The present invention will be illustrated through specific embodiments using the following examples: the entry of receiving vehicles into the logistics warehouse, the exit after loading and unloading, and the handling of abnormalities.

[0077] In this embodiment, the warehouse gate control server is deployed on the enterprise campus intranet or a cloud-based private network. The server includes business event collection services, event standardization services, event graph services, two-phase token services, gate state machine services, device adaptation services, anomaly handling services, and audit tracing services. These services can be deployed on the same server or separately as microservices.

[0078] During system initialization, the administrator configures various objects in the background, including warehouses, storage areas, platforms, gates, passageways, barriers, roller shutters, cameras, inductive loop detectors, infrared detectors, door magnets, weighbridges, voice broadcast screens, and manual monitoring terminals. Each device is configured with its device number, associated gate, communication protocol, control address, supported actions, feedback fields, timeout period, number of retries, default security status, and priority.

[0079] Simultaneously, the system configures the interface parameters for the reservation system, TMS transportation system, WMS warehousing system, ERP system, vehicle blacklist / whitelist system, park personnel system, and equipment control platform. Interface parameters include interface address, call key, event type, idempotency field, receipt field, failure retry strategy, and business status mapping relationship. After initialization, the system generates an initial event graph G_0 based on the configuration, using warehouses, gatekeepers, equipment, vehicles, drivers, reservation orders, and waybills as nodes, and ownership, authorization, binding, occupation, passage, receipt, and exception as edges.

[0080] In this embodiment, the system also configures several thresholds, including a passage scoring threshold T_pass, a channel clearing threshold θ_clear, a consecutive clearing frame count N, a pre-token validity period T_pre, a submitted token validity period T_commit, an opening receipt timeout T_open, a closing receipt timeout T_close, an anomaly risk threshold T_risk, and a manual review threshold T_manual. These thresholds are stored in a rule configuration table and serve as input parameters for state machine transitions and token expiration determination.

[0081] The database must store at least the following tables or datasets: Event Table, Graph Node Table, Graph Edge Table, Graph Version Table, Pass Request Table, Pre-Token Table, Submit Token Table, Gate Status Table, Equipment Command Table, Equipment Receipt Table, Exception Handling Table, and Audit Linked List. Specifically, the Token Table stores token digests (not plaintext business data), the Equipment Command Table stores command number, command digest, sending time, expected receipt, and actual receipt, and the Gate Status Table stores current status, occupied token, occupied vehicle, occupied direction, and status update time.

[0082] To ensure the control process can be restored after a system restart or network fluctuations, the server periodically persists state machine snapshots. These snapshots include the current gatekeeper state, the most recent GraphVersion, valid P_token, valid C_token, the last device command, the last device receipt, and anomaly flags. After service recovery, the system first reads the actual device state and compares it with the state machine snapshot. If they match, the original process continues; otherwise, it enters S12 anomaly pause and waits for re-verification.

[0083] Here are some specific examples: I. Event Access and Graph Update.

[0084] In one embodiment, the server receives reservation creation events from the reservation system, waybill dispatch events from the TMS, loading and unloading task events from the WMS, license plate recognition events from the camera, driver check-in events from the barcode scanner, channel occupancy events from the inductive loop detector, and status feedback events from the barrier gate device. All events first enter the event queue Q_event, which is sorted according to event time, reception time, and event priority.

[0085] The event standardization service maps and cleans the fields of the original events, generating Events in a unified format. For license plate recognition events, the system records the license plate number, recognition confidence, captured image number, gate number, and recognition time; for QR code check-in events, the system records the driver's identity, mobile phone number, appointment number, and check-in location; for device feedback events, the system records the device number, command number, feedback status, door sensor status, and feedback time.

[0086] When an original event lacks necessary fields, the system does not discard the event directly. Instead, it generates an event to be completed and writes it to the event table. For example, if a camera recognizes a license plate but does not match a reservation order, the system first records evidence of the vehicle's arrival. If the driver subsequently scans a code or manually enters a reservation order, the system establishes a connection between the two events using the license plate, gate information, and time window. This avoids disruptions to the access chain due to different arrival orders of events.

[0087] After reading the Event, the Event Graph Service performs a graph update. If the Event is a reservation creation event, a new reservation node is added, and edges are established between the reservation and the vehicle, driver, warehouse, gate, and time window. If the Event is a license plate recognition event, edges are added or updated to indicate vehicle arrival at the gate. If the Event is a device feedback event, the device node status is updated, and edges are established between the command and feedback. After each update, the system calculates the GraphVersion, which serves as one of the inputs for generating subsequent K_pass, P_token, and C_token.

[0088] When multiple events have conflicting time sequences, the system merges them according to business priority. For example, a reservation cancellation event has higher priority than a license plate arrival event, a blacklist event has higher priority than a manual release event, and a device offline event has higher priority than an automatic door opening request. Through this process, subsequent control procedures are always executed based on versioned snapshots of the event graph, rather than directly based on the results returned by a single interface.

[0089] After the map update is complete, the system will trigger a candidate access request scanning task. The scanning task uses vehicle arrival events, driver check-in events, or manual registration events as trigger points, linking them forward to reservation orders and waybills, and backward to gate equipment and channel occupancy status, forming a candidate relationship map. The candidate relationship map only indicates possible passage and does not equate to permission to open the gate; the actual gate opening action must go through a two-phase token process.

[0090] II. Vehicle entry control.

[0091] Vehicle Anhui B12345 is scheduled to arrive at Hefei Warehouse No. 1 Receiving Gate A at 10:00 AM on June 15, 2026. The reservation order number is AP20260615001, corresponding to the inbound waybill YD20260615001, and the driver is Zhang. The reservation system has already pushed the reservation creation event to the server, the TMS has pushed the waybill dispatch event, and the WMS has pushed the pending receipt task event.

[0092] When a vehicle arrives at gate A, the camera recognizes the license plate number Anhui B12345, and the driver simultaneously scans the QR code at the gate to sign in. After receiving the license plate recognition event and the QR code scanning event, the server writes them to the event queue. The event standardization service generates an Event, and the event graph service updates the relationships between vehicles, drivers, reservation orders, waybills, gates, and equipment. At this point, a candidate passage subgraph is formed in the graph, representing the sequence "vehicle-reservation order-waybill-warehouse-gate-equipment".

[0093] The gatekeeper state machine service reads vehicle nodes, driver nodes, reservation order nodes, waybill nodes, warehouse nodes, gatekeeper nodes, equipment nodes, and currently occupied lane nodes from the graph, and generates a PassRequest. The system calculates K_pass based on vehicle, reservation order, waybill, warehouse, gatekeeper, direction, time window, and GraphVersion. If the same K_pass already exists within the valid time, the system reuses the original pass request to avoid duplicate control.

[0094] The passage verification service calculates S_pass. Verification items include whether the license plate matches the vehicle on the reservation, whether the driver's identity matches, whether the reservation time is within the allowed window, whether the vehicle is on the blacklist, whether the waybill is valid, whether the gate allows this type of service, whether the current channel is occupied by other tokens, whether the device is online, and whether there are any unprocessed anomalies. If S_pass is less than T_manual but no high-risk rule is triggered, the system enters manual review mode; if S_pass is not less than T_pass, the status changes from S1 pending verification to S2 verification passed.

[0095] For example, if the vehicle consistency score is 1, the driver consistency score is 1, the appointment time window score is 0.9, the gate matching score is 1, the equipment online score is 1, the channel idle score is 0.8, and the miss risk score is 1, then the system calculates S_pass according to the preset weights. If the calculation result reaches T_pass, the system continues the token process; if the license plate matches but the driver has not checked in, the system can enter a waiting state for supplementary events instead of immediately rejecting the request.

[0096] The bi-phase token service issues a P_token in state S2. The P_token is bound to K_pass, GraphVersion, gate number, lane number, direction, vehicle number, resource lock key, expected action, validity period, and current state. The issuance of the P_token does not immediately propel the state machine into state S3; the system requires the state machine service to hold the P_token and call VerifyToken for pre-token verification.

[0097] After successful P_token verification, the system switches the gatekeeper status from S2 (verification passed / pending pre-token authorization) to S3 (pre-token verification passed / resource occupied), and writes the occupied vehicle, occupied direction, actuator number, token number, and token expiration time into the gatekeeper resource lock table. If the channel clearing condition is not met within T_pre, or if the GraphVersion, business status, and device status are inconsistent, the P_token automatically expires and the resource lock is released. The gatekeeper status returns to S1 (pending verification) or S12 (abnormal pause). The system will not continue to use expired P_tokens to generate C_token_open.

[0098] Subsequently, the channel occupancy determination module reads the data from the inductive loop, door sensor, camera target detection, and infrared detection within the context of the verified P_token, and calculates the channel occupancy score based on O_lane. When O_lane is less than θ_clear for N consecutive frames, and the door sensor indicates that the door is in a controllable state, the device heartbeat is normal, and no personnel or non-target vehicles are detected within the safe area, the system remains in S4 and allows the issuance of C_token_open; only after C_token_open is subsequently verified successfully does the system enter the S5 state of submitting token verification passed / awaiting issuance.

[0099] The N-frame consecutive frame determination can be performed at a fixed sampling interval, such as sampling the channel status every 200 milliseconds. The channel is considered cleared only if the clearing condition is met for 5 consecutive frames. If a vehicle, person, obstacle, or door sensor abnormality is detected in any frame, the consecutive count is reset to zero, and a clearing failure event is recorded. This mechanism is used to avoid false judgments caused by momentary sensor jitter.

[0100] The dual-token service issues C_token_open in S4 state. C_token_open is bound to P_token, channel clearing evidence, device readiness evidence, security test results, door opening action, device path, and submission time. After issuance, the system immediately performs submission token verification, rereading the latest channel occupancy, device heartbeat, security interlock, and P_token resource lock status; only after successful verification does the state enter S5, and only then is the generation of device commands allowed.

[0101] The validity period of C_token_open is shorter than that of P_token, and it can only be used once. Before generating a Command_open, the device adaptation service verifies and consumes the C_token_open again. The token status changes from verified to consumed and bound to the command_id. If the device adaptation service receives a duplicate command request for the same C_token_open, the system only allows querying the original command result and does not allow creating a new opening command. This prevents duplicate openings caused by interface retries, repeated page clicks, or repeated message deliveries.

[0102] The device path selection module reads the device capability profile D_cap of the barrier gate, roller shutter door, and controller, and selects an available control path. For example, if the barrier gate supports HTTP control and is online, while the roller shutter door only supports serial port control and currently has no opening requirement, the system selects the barrier gate's HTTP control path. After successful token verification, the device adaptation service generates a Command_open, which includes the command number, C_token_open digest, device number, action type, action parameters, validity period, retry policy, and expected feedback fields.

[0103] When multiple controllable devices exist at the same gate, the system calculates a path score based on device online status, recent failure count, average response time, control priority, and safety status. If the main controller is offline but the backup controller is online, the system can select the backup path; if all automatic paths are unavailable, the system does not generate device commands and transitions to manual confirmation.

[0104] After the device adaptation service confirms that C_token_open has been verified and the one-time consumption has been completed, it converts Command_open into a device protocol command and sends it out. After the device returns a successful door opening, the closed-loop feedback module continues to verify the door magnetic status, the barrier gate status, the changes in the ground induction coil, and the camera capture results. Only when the device feedback is successful, the door status is open, the target vehicle begins to pass through, and no unauthorized vehicle is detected following, does the state machine transition from S6 (instruction issued) to S7 (passage).

[0105] When a vehicle passes through, the system determines that the vehicle has completed entry based on the departure signal from the inductive loop, the camera's snapshot, and the gatekeeper's direction, and enters the S9 state of "Passage Completed / Gate Closing Authorization". The system issues a gate closing submission token C_token_close, which is bound to C_token_open, vehicle passage evidence, evidence of the passage being cleared before closing, equipment readiness evidence, security area detection results, and the gate closing action. Only after VerifyToken(C_token_close, action=close) is successfully passed and consumed once by the device adaptation service does the system generate Command_close and enter S10. After the device reports that the gate is closed and there is no congestion in the passage, the status enters S11 "Gate Closed", the system releases the resource lock corresponding to P_token, and sets P_token, C_token_open, and C_token_close to "Completed" or "Released". The system writes back the actual entry time, gatekeeper number, equipment number, snapshot image number, passage result, and audit chain number to the reservation system, TMS, and WMS.

[0106] III. Vehicle Exit Control.

[0107] After completing loading and unloading, vehicle Anhui B12345 drove towards exit gate B. The camera recognized the license plate, and the server generated a PassRequest for the exit direction, then queried the WMS loading / unloading task status, TMS waybill node, weighbridge weighing status, and warehouse exception status in the event graph. Because exit control and entry control have different business bases, the system increased the weight of loading / unloading completion, handover confirmation, and weighing verification in S_pass.

[0108] If the data map shows that the loading and unloading task has been completed, the outbound verification has passed, there are no warehouse anomaly orders, the vehicle is not temporarily locked, and gatekeeper B allows departure, then the system issues and verifies the departure P_token. After the channel is cleared, the system issues the departure C_token_open, and after verification and one-time consumption are passed, selects Command_open according to the equipment capability profile. After the vehicle leaves, the system issues and verifies C_token_close. After successful verification, a Command_close is generated, the TMS waybill node is written back to indicate that the vehicle has left the site, and the departure time is written to the WMS.

[0109] If the WMS displays that the loading / unloading task is incomplete, or the TMS displays an abnormal waybill node, or the weighbridge weighing difference exceeds the threshold, the system will not issue or verify C_token_open, nor will it issue an opening command. At this time, the state machine enters S13 to refuse passage or S14 to require manual confirmation, prompts the driver to return to the warehouse for processing, and pushes the reason for the abnormality to the warehouse personnel.

[0110] Regarding the exit direction, the system can also perform closed-loop verification based on the entry access audit chain. If a vehicle requests to exit without a valid entry record, the system marks the request as an abnormal exit; if a vehicle exceeds the maximum stay time after entering, the system requires manual confirmation; if the exit gate is inconsistent with the reserved gate, the system determines whether to allow the vehicle to change its exit route based on the gate's access control rules.

[0111] IV. Prevention of Duplicate Requests Vehicle Anhui B12345 experienced network latency at gate A, causing the driver to scan the code repeatedly, and the camera also triggered multiple license plate recognition events. The system generates the same K_pass based on the same vehicle, same reservation order, same waybill, same warehouse, same gate, same direction, same time window, and same GraphVersion, thus preventing the creation of multiple passage applications.

[0112] If the system detects that P_token has been verified and holds the resource lock but C_token_open has not yet been generated, the new duplicate request will only refresh the event evidence and will not change the reserved resources. If it detects that C_token_open has been verified and Command_open has been issued, the duplicate request will only return the current status and the previous device control result and will not issue the door opening command again. If passage has been completed, the duplicate request will be marked as a historical request and enter the audit chain as evidence of duplicate triggering.

[0113] At the device command level, the system uses command_id and C_token digest together for idempotency control. Before sending a command, the device adaptation service queries the token table and the device command table. If a command with the same C_token_open or C_token_close already exists and has been successfully sent or is awaiting an acknowledgment, a new command will not be created. If the previous command failed but is still within the allowed retry range, a retry command will be generated under the constraint that the original submission token allows retry and associated with the original command number, or the original token will be invalidated and a new submission token will be reissued.

[0114] V. Interception of Business Status Changes In one embodiment, a P_token is generated upon the vehicle's arrival at the gate. However, before the passage is cleared or the equipment is ready, the reservation system pushes a reservation cancellation event, or the vehicle blacklist system pushes a temporary access restriction event. After the event graph service updates the GraphVersion, the state machine service discovers that the GraphVersion bound to the current P_token is no longer the latest business graph version.

[0115] The system recalculates S_pass. If a cancellation event or blacklist event causes S_pass to fall below the rejection threshold, the system immediately invalidates P_token, changes the status from S3 (pre-token generated) to S13 (rejected), does not generate C_token, does not issue device commands, and outputs the rejection reason to the gatekeeper screen and the manually operated terminal. This process is used to prevent physical door opening from being performed even when the service status has expired.

[0116] If the change in business status occurs after C_token_open is issued or verified but before Command_open is confirmed by the device, the system marks C_token_open as pending revocation and sends a revocation command or a stop sending command to the device adaptation service. If the device adaptation service has not yet consumed the token, consumption is prohibited and the resource lock is released; if the device has already opened the door, the system enters the abnormal handling process, requiring rapid door closure, alarm activation, and recording the time difference between the business status change and the physical action.

[0117] VI. Abnormal equipment rollback After the server issues Command_open, if the device fails to return a successful door opening response within T_open, or if the device returns a successful response but the door sensor remains closed, the closed-loop feedback module identifies this as inconsistent device feedback. The state machine transitions from S6 (command issued) to S12 (abnormal pause) and calculates A_risk.

[0118] If A_risk is lower than T_risk and the number of retries has not exceeded the limit, the system rereads the device's online status, door sensor status, and channel occupancy status, and generates a new Command_retry. The Command_retry still needs to be verified through a retry of the original C_token_open, or the state machine needs to reissue and verify a new C_token_open, and the original command number is marked as failed. If the device still does not provide a valid response after the retry, the system locks the gate, invalidates the P_token, C_token_open, and any unused C_token_close, and notifies manual intervention.

[0119] In abnormal door closing scenarios, if a vehicle has passed but the door sensor does not report that the door is closed, the system does not directly determine that passage is complete. Instead, it maintains the S10 door closing token verification passed / door closing command issued state and continues to collect detection results from the door sensor, ground loop coil, and camera. If a vehicle is stuck or a person is in a dangerous area, the system prohibits repeated consumption of C_token_close and triggers an alarm. If the passage is safe but door closing fails, the state machine will retry within the original token retry range, or the original C_token_close will expire and the manual door closing process will begin.

[0120] If the device reports success but the camera does not detect the target vehicle passing, the system will maintain the status as S7 passage and start a waiting timer. If no evidence of passage is detected after the waiting time, the system will mark this passage as "door open but not passed," and after verifying the door closing security conditions, will issue and verify C_token_close, then generate a door closing command. Simultaneously, P_token, C_token_open, C_token_close, and Command_open will be associated with the anomaly audit log. This process distinguishes between situations where the device execution is successful but the actual passage does not occur.

[0121] VII. Handling Risks of Following in Vehicles After vehicle Anhui B12345 passed through the gate, the ground loop and camera detected another vehicle following closely behind, but this vehicle did not have a corresponding valid K_pass, P_token, and C_token. The system wrote the following vehicle identification result into the event graph, generated an abnormal following edge on the current passage chain, and marked this passage as a following risk.

[0122] When the risk of following another vehicle is triggered, the system suspends automatic passage through the same gate, displays an anomaly alert on the gate screen, sends a captured image and license plate recognition to the personnel on duty, and switches the gate status to require manual confirmation. If the following vehicle subsequently registers a valid appointment, the system will not overwrite the original anomaly record, but will instead generate a new registration event and manual processing record.

[0123] In another embodiment, the camera detects two vehicles passing by consecutively, and the inductive loop detector only generates a long occupancy signal once. The system fuses the inductive loop occupancy duration, the number of video targets, and the door sensor opening time for judgment. If the single-vehicle passage time threshold is exceeded and the number of video targets is greater than 1, a multi-vehicle passage anomaly is generated. This anomaly does not affect the write-back of authorized vehicles' entry, but it will lock subsequent automatic release and require manual confirmation of the second vehicle's identity.

[0124] 8. Manual intervention and re-release In S14 manual confirmation mode, on-duty personnel can view vehicle information, driver information, reservation orders, waybills, map version, failed verification items, equipment status, captured images, and historical audit chains on the manual terminal. Personnel can choose to refuse passage, request supplementary information for re-verification, specify a device path for passage, or transfer the device to the warehouse for processing.

[0125] If a human operator chooses to supplement information and re-verify, the system generates a ManualEvent and updates the event graph, then recalculates K_pass and S_pass. If the human operator chooses to grant access via a specified device path, the system still needs to issue and verify P_token, C_token_open, and the necessary C_token_close, and adds the manual_approval field, approver, approval time, and approval reason to the submitted token. Even in the case of human approval, the system does not bypass two-phase token verification, one-time consumption, and device closed-loop verification.

[0126] When a manual access request is denied, the system writes the reason for the denial to the event graph and invalidates the currently valid token. When the manual access is granted again, the system does not reuse the invalidated token, but instead regenerates K_pass, P_token, and C_token based on the new GraphVersion. If a manual user forcibly opens the door while the device is malfunctioning, the system requires the reason for the forced opening to be entered and distinguishes this action from the normal automatic access action for record-keeping.

[0127] IX. Audit Retrospective For each successful pass, rejection, exception, rollback, retry, or manual intervention, the system generates an audit log. The audit log includes the original event number, standard event content, graph version, pass application number, K_pass, P_token, C_token_open, C_token_close, token verification result, device command number, device feedback, captured image number, state machine transition record, exception score, manual intervention record, and business write-back result.

[0128] The audit chain generates H_n in chronological order. During subsequent queries, the system can trace the complete passage process backwards based on the vehicle, driver, reservation order, waybill, gatekeeper, equipment command, or token number. If a dispute requires verification of whether a door was opened or closed incorrectly, the system can compare the issuance conditions of P_token, C_token_open, and C_token_close, verification results, one-time consumption records, channel clearing evidence, equipment feedback, and graph version to determine whether the door opening / closing action was triggered by both a valid business event and a valid equipment status.

[0129] Key data in the audit chain is stored using an append-only method. Subsequent manual entries, business corrections, and abnormal closures are all appended as new audit nodes, without overwriting the original nodes. During audit queries, the system displays the input events, judgment conditions, and output actions for each state transition, enabling managers to reconstruct the complete computer processing from vehicle arrival to gate closure.

[0130] 10. Dual-gate collaborative control In some warehouses, the entrance and exit gates are adjacent, or the same vehicle needs to pass through the outer gate of the park before passing through the inner gate of the warehouse. The system can treat the two gates as two sub-nodes of the same passage task. When a vehicle passes through the outer gate, the system issues and verifies the outer gate P_token, outer gate C_token_open, and outer gate C_token_close. Only after the outer gate passage is completed, the closing token is released, and an audit node is formed, does the system allow the inner gate candidate passage application to enter the verification process.

[0131] If the outer door is open but the inner door passage is not cleared, the system will not generate an inner door C_token in advance; it will only generate or wait for an inner door P_token. If the vehicle stays between the outer and inner doors for an extended period, the system will set the passage task to an intermediate standby state and suspend automatic inner door release. In this way, the system avoids the safety risks caused by both doors opening simultaneously and also prevents the loss of traceability after a single vehicle task is broken up.

[0132] XI. Token Status Restoration When the server restarts, the network is interrupted, or the message queue is temporarily unavailable, the system first reads the gate status table, token table, resource lock table, and actual device status after recovery. If P_token is valid and verified but C_token_open has not been generated, and the gate device is in a closed state, the system recovers to S3 pre-token verification passed / resource occupied or re-verification state; if C_token_open has been consumed and the device gate is in an open state, the system recovers to S7 passage and continues to wait for vehicle passage evidence; if C_token_close has been consumed but no gate closing receipt has been received, the system recovers to S10 and continues gate closing loop verification.

[0133] If the database record shows the door is closed but the device actually reports it as open, the system considers the states inconsistent, enters S12 abnormal pause, locks the automatic release, and notifies manual verification. The recovery process does not directly continue opening the door based on a single database record or a single device response, but determines the next state through the consistency of token status, device status, and channel detection.

[0134] As can be seen from the operational examples of the above embodiments, compared with the method of directly opening the door based solely on the reservation order or license plate recognition result, the present invention can reduce the risks of repeated door opening, accidental door opening after service failure, accidental door closing, inconsistent equipment receipts, misjudgment of channel occupancy, and abnormal vehicle following. Simultaneously, the present invention binds the token state with GraphVersion, resource lock, device commands, device adaptation layer consumption records, and audit chain, ensuring that each gate opening and closing action is based on a closed-loop path of token holding, successful verification, state transition, and device action. This provides the technical benefits of tokens and their states being computable, verifiable, rollbackable, and traceable. The present invention is not only applicable to gate barriers but also to roller shutters, retractable doors, access control controllers, and warehouse gate scenarios with multiple device combinations.

[0135] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution of the present invention, or the direct application of the inventive concept and technical solution of the present invention to other occasions without modification, are all within the protection scope of the present invention.

Claims

1. A warehouse gate dual-phase token opening and closing control method driven by multi-source event graph, characterized in that, First, receive multi-source events into the queue and perform standardization processing. Then, map the events to an event graph and generate corresponding version numbers. Generate a pass application and a unique identifier based on the event trigger. Determine whether to grant access based on a comprehensive score of multiple factors. Issue a pre-token to the application that passes the score. After the pre-token verification is successful, the channel resources are occupied. When the channel occupancy is determined by scoring to ensure that the access control can be passed, a token is issued and submitted and verified in a timely manner. The token is consumed to issue a device command. The door opening closed-loop requirements of the access control device must be met simultaneously: the device returns a successful door opening, the door sensor or barrier gate status changes to open, the channel detects the target vehicle starting to pass, and no abnormal following vehicle is detected. After the requirements are met, the door is opened and a door closing token is issued and submitted. After verification and consumption, the door is closed and the resource lock is released. Includes the following steps: Step 1: Event reception, queuing, and standardized processing; Step 2: Event graph construction and graph version update; Step 3: Pass application generation and unique identifier calculation; Step 4: Multi-dimensional verification of eligibility; Step 5: State machine control of the dual-phase gated token; Step 6: Pre-token issuance, holding, and verification; Step 7: Channel occupancy determination; Step 8: Submit token issuance, verification, and one-time consumption; Step 9: Device path selection, token verification, and command generation; Step 10: Device command closed-loop and receipt verification.

2. The warehouse gate dual-phase token opening and closing control method driven by multi-source event graph as described in claim 1, characterized in that, In step 1, events are received and written to the event queue to generate standard business events. In step 2, the standard business events are mapped to an event graph, which includes a set of nodes, a set of edges, and a set of edge weights. The set of nodes includes at least reservation nodes, waybill nodes, vehicle nodes, driver nodes, gate nodes, equipment nodes, channel occupancy nodes, feedback nodes, risk nodes, and audit nodes. The set of edges includes at least ownership edges, allocation edges, occupancy edges, feedback edges, locking edges, and audit edges. When a new event is added to the event queue, the graph nodes and edges are updated according to the event content, and a graph version number is generated.

3. The warehouse gate dual-phase token opening and closing control method driven by multi-source event graph as described in claim 1, characterized in that, In step 3, if the received event triggers a passage application, a passage application is generated according to the event graph. For repeated operations under the unique identifier of the same passage application, only the event version and status record are updated. In step 4, the passage application is checked for four types of verification: vehicle identity, business status, gate matching, and risk status. A comprehensive release score is calculated based on the factors of the four types of verification and then compared with the automatic release threshold for verification. If the overall release score is higher than the automatic release threshold and there is no strong rejection condition, proceed to the pre-token generation step; If the overall release score is within the manual review range, the request will be changed to a pending manual confirmation status; if the overall release score is below the rejection threshold or there are strong rejection conditions, passage will be refused.

4. The warehouse gate dual-phase token opening and closing control method driven by multi-source event graph as described in claim 1, characterized in that, In step 5, a state machine with a two-phase token is maintained for each access request. The state machine achieves state transition through a state transition function. The authorization verification function takes the token as input. Only when the authorization verification function returns as passed and the resource lock or one-time consumption write is completed, is it allowed to enter the subsequent state or generate a device command. The token states include: S0 pending trigger, S1 pending verification, S2 verification passed / pending pre-token authorization, S3 pre-token verification passed / resource occupied, S4 channel to be cleared, S5 token submission verification passed / pending issuance, S6 instruction issued, S7 door opened, S8 vehicle passing, S9 passage completed / pending door closing authorization, S10 door closing token submission verification passed / door closing instruction issued, S11 door closed, S12 abnormal pause, S13 passage refused, S14 manual release; after step 4 is executed, the pre-token generated by the state machine transitions from state S1 to state S2.

5. A warehouse gate dual-phase token opening and closing control method driven by multi-source event graphs according to claim 4, characterized in that, In step 5, the state transition function is as follows: S_next = f(S_current, Event, Guard, Timeout, GraphVersion, TokenState) Wherein, S_next represents the new state, S_current is the current state, Event is the triggering event, Guard is the transition guard condition, Timeout is the timeout condition, GraphVersion is the event graph version, and TokenState is the token state; Guard includes at least the token holding relationship, token digest, validity period, graph version number (GraphVersion consistency), resource lock number, one-time consumption flag, and latest device / channel evidence; TokenState includes at least the following states: unissued, issued and awaiting holding, held and awaiting verification, verified, consumed, released, revoked, and expired; the server is prohibited from executing across states; the authorization verification function takes the token as input, and only when the authorization verification function returns successfully and the resource lock or one-time consumption write is completed is it allowed to enter the subsequent state or generate device commands.

6. A warehouse gate dual-phase token opening and closing control method driven by multi-source event graphs according to claim 5, characterized in that, In step 6, when the state machine is in state S2, the server issues a pre-token based on the access request. After the authorization verification function of the pre-token returns a pass, an occupancy record is written into the resource lock table based on the information of the pre-token. The corresponding authorization verification function verifies the following for the pre-token: the pre-token has not expired or been revoked; the unique identifier of the access request bound to it is consistent with the current access request; the bound map version number is not behind the current valid map version; the gate and lane are not occupied by other valid tokens; and the vehicle, direction, actuator, and expected action are consistent with the current request. In step 7, sensor signals are read, and the lane occupancy score O_lane is calculated using the formula: O_lane = Σ(s_i × w_i), where s_i is the occupancy signal of the i-th sensor and w_i is the corresponding weight; the server determines the channel to be cleared only when the current access request holds a verified pre-token P_token and the channel occupancy score O_lane is lower than the clearing threshold θ_clear for N consecutive frames; if the channel is not cleared or the pre-token P_token verification fails, the state remains in state S4 channel waiting to be cleared or rolls back to state S12 abnormal pause, and the generation of submission tokens is not allowed.

7. The warehouse gate dual-phase token opening and closing control method driven by multi-source event graph as described in claim 6, characterized in that, In step 8, when the state machine is in state S4, the channel is waiting to be cleared, and the pre-token is still in the verification passed and resource occupied state, the channel is cleared, the device is in the executable state, and the security interlock is passed, the server issues an opening submission token. The opening submission token is a one-time token. The opening submission token is bound to the opening action, the device path, the channel clearing evidence, and the security interlock result. For the door opening submission token, the guard condition for the state machine to enter S5 from S4 is that the corresponding authorization verification function returns as passed. The verification content of the corresponding authorization verification function for the door opening submission token includes: the pre-token is still in the verified and resource-occupied state, the door opening submission token has not expired and has not been consumed, the channel clearing evidence is still within the allowed freshness window, the device is online and the action type is door opening, the security interlock has not been triggered, and the graph version number has not changed to cause a denial of passage. After the verification is passed, the door opening submission token enters the verified / pending consumption state. Before the device command is generated, the device adaptation service still needs to perform consumption verification.

8. A warehouse gate dual-phase token opening and closing control method driven by multi-source event graphs according to claim 7, characterized in that, In step 9, the equipment path is selected based on the equipment capability profile. The formula for calculating the equipment path selection result is as follows: Path = argmax(u1·compatibility + u2·safety + u3·latency - u4·conflict) Wherein, Path represents the device path; compatibility represents protocol compatibility; safety represents security; latency represents response delay; and conflict represents conflict risk; u1, u2, u3, and u4 are the factor weights of the corresponding factors, respectively; a standard device command to be verified is generated based on the device path Path. Before converting to a specific device protocol, the token verification service must be called to perform verification on the submitted token for validity period, one-time consumption, graph version number, resource lock, device status, and action type; after the verification is passed, the submitted token status is set to consumed and the command number is bound in an atomic manner.

9. The warehouse gate dual-phase token opening and closing control method driven by multi-source event graph as described in claim 8, characterized in that, In step 10, a standard device command that has been verified by the token is sent to the device adapter; wait for the device to respond according to the command identifier; in this step, the door opening closed loop requirements must be met simultaneously: the device returns that the door opening was successful, the door magnet or barrier gate status changes to open, the channel detects that the target vehicle has started to pass through, and no abnormal following vehicle is detected; Once the vehicle passes through the evidence and meets the passage completion conditions, the state machine enters state S9 Passage Complete / Waiting for Door Closure Authorization. The server issues a door closing submission token, which is then bound to a consumed door opening submission token, vehicle passage evidence, evidence of the passage being cleared before closing the door, equipment readiness evidence, security zone detection results, and the door closing action. The guard condition for the state machine to transition from state S9 to state S10 is that the corresponding authorization verification function returns successfully, and the device adaptation service consumes the token once before issuing the door closing command. The door closing closed loop requirements must be met simultaneously: the device returns a successful door closing, the door sensor or barrier gate status changes to closed, no vehicle lingering is detected, and no personnel or vehicles are found in the danger zone. Only when the receipt verification passes, and the command number, device number, and token digest in the receipt are consistent with the consumed and submitted token, will the server advance the state machine. If the receipt times out, the state is inconsistent, the token digest is inconsistent, or an anomaly is detected, the server enters the anomaly rollback process.

10. A warehouse gate dual-phase token opening and closing control method driven by a multi-source event graph according to claim 9, characterized in that, It also includes the following steps: Step 11, Abnormal Rollback and Token Expiration: Before the device performs the door opening and closing actions, the abnormal risk score is calculated as follows: A_risk = ρ1A_biz + ρ2A_device + ρ3A_pass + ρ4A_security + ρ5A_timeout Wherein, A_biz: business anomaly risk component, A_device: device anomaly risk component, A_pass: passage anomaly risk component, A_security: security anomaly risk component, A_timeout: timeout anomaly risk component; ρ1, ρ2, ρ3, ρ4, ρ5 are the weights of each corresponding risk component; when the anomaly risk score A_risk exceeds the high-risk threshold, the server locks the gate and requires manual handling; when the device fails to open the gate, the server rolls back the corresponding submission token from state S6 to state S5 or state S12, and decides whether to allow the original command query or reissue a new submission token based on whether the submission token has been consumed; when the vehicle does not pass and the token times out, the server rolls back the corresponding submission token from state S7 to state S12, and invalidates the corresponding pre-token, gate opening submission token, and unused gate closing submission token; when the business status changes before the gate is opened, the pre-token is revoked, the resource lock is released, and the system switches to denying passage or awaiting manual confirmation.

Images