A security check operation state management method and system based on discrete service event semantic driving

Abstract

The application discloses a security check operation state management method and system based on discrete service event semantic driving. The method comprises the following steps: acquiring security check service discrete original event data, and completing analysis, mapping and standardization processing to generate standardized events; forming a candidate state change request or a performance trigger request according to the standardized events; executing business stage state inference in combination with a current state, an event window, an associated object state and a stage transfer rule to generate a candidate business stage state; executing constraint checking and conflict resolution according to a preset business constraint to generate a legal state migration request; generating a legal authoritative state according to the legal state migration request; when detecting that a state chain is illegal, performing recalculation on a local event chain based on a latest legal state snapshot to complete local state rollback; updating a state snapshot and generating a patch according to the legal authoritative state; and driving object updating in a digital twin scene according to the patch.

Description

Technical Field

[0001] This invention relates to the fields of security inspection operations and digital twin technology, and in particular to a security inspection operation status management method and system based on discrete business event semantics. Background Technology

[0002] With the continuous growth of civil aviation transportation, the airport security check environment is becoming increasingly complex, placing higher demands on digital means for the perception and command of on-site operations. Currently, the Civil Aviation Security Management Information System (SCMIS) can record operational data such as counter opening and closing, staff on / off duty, passenger verification, equipment operation, and alarm handling. However, existing technologies still have the following shortcomings in achieving digital twin construction and visualized operational command for security check scenarios: 1. The disconnect between data presentation and spatial perception: Existing systems primarily present business data in the form of tables, logs, or statistical reports. This non-spatial representation lacks intuitive visual feedback, making it difficult for managers to quickly establish an intuitive understanding of the overall physical situation in complex security checkpoint environments. This is especially true when dealing with sudden surges in traffic or abnormal alarms, limiting decision-making and response efficiency.

[0003] 2. The dilemma of state evolution under the condition of missing continuous trajectories: Traditional digital twin technology heavily relies on continuous physical motion trajectories (such as GPS / UWB positioning) or high-frequency sensor data to drive object evolution. However, in security inspection scenarios, due to privacy protection and perception limitations, the security inspection process for passengers and luggage exhibits characteristics of "clear discrete nodes and missing intermediate processes." Directly using existing trajectory smoothing or physical simulation schemes makes it difficult to accurately recreate the logical connections between discrete business nodes, easily leading to distortions in business flows in the digital space.

[0004] 3. Timing conflicts and inconsistencies in asynchronous event-driven systems: Security checks are driven by a stream of events triggered by various devices and systems. Due to network latency, differences in device sampling frequencies, or asynchronous system uploads, business events often cannot be guaranteed to arrive at the backend in the physical order of occurrence. Traditional sequential update mechanisms can lead to logical inversions in the state of digital twin objects when handling "late" or out-of-order events (e.g., receiving a baggage opening event before receiving a scanning anomaly event), causing a disconnect between the virtual scene and the physical site, and lacking effective self-healing and backtracking mechanisms.

[0005] Therefore, how to build a security inspection digital twin system with logical self-healing capabilities and high reliability and consistency by leveraging the semantic drive of discrete business events without relying on continuous trajectories is a technical challenge that urgently needs to be solved in the current construction of smart airports. Summary of the Invention

[0006] The purpose of this invention is to provide a security inspection operation status management method and system based on discrete business event semantics, so as to solve the problems of state evolution distortion and timing conflict caused by the lack of continuous trajectory data and the out-of-order arrival of asynchronous events in security inspection scenarios.

[0007] To achieve the above objectives, the solution of the present invention is: a security inspection operation status management method based on discrete business event semantics, comprising at least the following steps: S1: Real-time access to discrete raw business event data of security inspection services; S2: Parse, map, and standardize the raw business event data to generate standardized events; based on the event type, node type, action type, and business load of the standardized events, generate candidate state change requests or performance trigger requests; S3: Business Stage Status Inference: After receiving a normalized event, combine the current status of the target object, the sequence of most recent related events, the status of associated objects, the event time interval, and the preset stage transition rules to infer the current candidate business stage status of the target object; S4: Business constraint conflict resolution: Based on preset business constraints, perform business constraint verification and conflict resolution on candidate business stage status and candidate status change requests to generate a legal status transition request; S5: Generate the legitimate authority state of the target object based on the legitimate state transition request; S6: Local state rollback: When the current state chain is detected to be invalid in step S4, the local event chain is located and recalculated based on the most recent valid state snapshot to generate a new valid authoritative state; S7: Update the target object's state snapshot based on its legitimate authority status and generate an incremental patch; S8: Distribute the patch generated in step S7 to the front-end display module to drive the 3D scene node objects and 2D situation components to update in conjunction with the same patch source.

[0008] S9: Implement a divide-and-conquer approach for persistent and transient states: Divide legitimate authority states into persistent and transient states and apply different processing strategies.

[0009] S10: To achieve accurate mapping between business objects and 3D scene node objects, the system adopts an object binding mechanism. This establishes binding relationships between the business object layer, the twin object layer, and the model node layer.

[0010] S11: Execution State Recovery and Exception Handling: During initialization, disconnection recovery, shutdown and restart, or mode switching, the system restores the scenario running state by obtaining the latest valid state snapshot, and after the state snapshot is restored, it accesses the subsequent original business event data after the snapshot time point. When there is an event gap, it fills in the original business event data corresponding to the gap.

[0011] After adopting the above solution, the beneficial effects of the present invention are as follows: 1. In the absence of continuous trajectory data, by introducing business stage state inference, discrete business events are transformed into logically coherent business process stage expressions, forming a stable and interpretable digital twin state.

[0012] 2. Through a business constraint conflict resolution mechanism (including prior state, time sequence, business loop, mutually exclusive state and related object constraints), candidate state change requests are accepted, temporarily stored, rejected, delayed, or local state rollback is triggered. This effectively solves the timing conflict problem caused by out-of-order asynchronous events and late events, and improves the legality and stability of state transitions.

[0013] 3. By using a local state rollback mechanism, the local event chain is recalculated and the state is reconstructed based on the most recent valid state snapshot. This reduces rollback overhead while ensuring state consistency and enhances the system's adaptability to out-of-order events, late events, and abnormal recovery scenarios.

[0014] 4. By using a unified patch to drive the linkage display of 3D and 2D, we can ensure that the 3D scene and 2D situation components are updated synchronously based on the same patch source, thereby improving display consistency.

[0015] 5. By using a divide-and-conquer mechanism of persistent and transient states, only the persistent state is restored in scenarios such as initialization and reconnection after disconnection, without replaying the historical transient state, thereby improving the accuracy of state restoration.

[0016] 6. By using object binding and state recovery mechanisms, flexible mapping between business objects and 3D scene node objects is achieved, and the running state can be quickly restored based on state snapshots in abnormal scenarios, thereby improving the robustness of system operation. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the main process of the security inspection operation status management method of the present invention; Figure 2 This is a detailed flowchart of the security inspection operation status management method of the present invention; Figure 3 This is a business phase status diagram of the manual verification counter object of the present invention; Figure 4 This is a business stage state diagram of the baggage object of the present invention; Figure 5 It is a schematic diagram of the business constraint conflict resolution mechanism of the present invention; Figure 6 It is a schematic diagram of the local state rollback mechanism of the present invention; Figure 7 It is a schematic diagram of the divide-and-conquer processing of the persistent state and the transient state of the present invention; Figure 8 It is a schematic diagram of the three-dimensional and two-dimensional联动更新 (I'm not sure what "联动更新" exactly means in this context. Maybe it should be "linked update" or something else more specific. For now, I'll keep it as is) of the present invention; Figure 9 It is a schematic diagram of the overall architecture of the security inspection operation status management system of the present invention. Specific implementation manner

[0018] The following will make a detailed description of the present invention in conjunction with the accompanying drawings and specific embodiments.

[0019] The present invention provides a security inspection operation status management method based on discrete business event semantic drive. This method is applicable to the application scenarios of digital twin construction, business stage state inference, state adjudication, recovery and reconstruction, and three-dimensional and two-dimensional linked display of business objects such as manual verification counters, X-ray machines, security inspection channels, luggage inspection areas, duty posts, and alarm objects in the security inspection and verification scenarios.

[0020] In the present invention, a business object refers to all entity objects described in the security inspection business system, including counters, luggage, personnel, equipment, alarms, etc., and each business object has a unique business identifier.

[0021] The present invention transforms discrete business events into a logically self-consistent business state flow by establishing a business stage state machine and a semantic adjudication mechanism, and combines local state backtracking technology to achieve a highly reliable and self-healing state fitting of the digital space to the physical site, thereby improving the intuitiveness and response efficiency of security inspection command.

[0022] The security inspection operation status management method of the present invention based on discrete business event semantic drive refers to Figure 1 (main process schematic diagram) and Figure 2 (detailed process schematic diagram), and includes the following steps: S1: Access the original business event data Real-time access the discrete original business event data generated in the security inspection production environment, including: The opening or closing status of the verification counter, including manual verification counters and self-service verification counters; Events of duty personnel on duty, off duty, and temporarily off duty; Events of successful and failed passenger verification; Events of X-ray machine activation and deactivation; Events of passenger luggage placement, luggage scanning, luggage unpacking, and luggage removal; System alarm class events; Statistical derivative events.

[0023] S2: Generate normalized events and form candidate requests. The system performs protocol parsing, field extraction, format conversion, validity verification, and unified encapsulation on the original business event data. It also maps the business identifier ID of the business object in the original business data payload to the scene node identifier nodeId and the node type nodeType, thereby generating standardized events with a unified format within the system.

[0024] The mapping between business identifier ID, scene node identifier (nodeId), and node type (nodeType) is established through configuration management information in the backend database. This mapping is used to map business objects in the business system to object model objects (also known as 3D scene node objects) in the 3D scene.

[0025] The normalized event includes at least the following fields: eventId is used to uniquely identify an event; eventType is used to identify the event type; The timestamp is used to identify when an event occurred. sceneId is used to identify the scene; nodeType is used to identify the type of model node or object in the scene; nodeId is used to identify model nodes in the scene; `source` is used to identify the source system; The `action` keyword is used to identify the type of action. headers are used to carry event header information; The payload is used to carry business data attributes; version is used to indicate version information.

[0026] The system processes normalized events according to the following rules: Events on the same node are sorted by timestamp + version; Duplicate events with the same eventId are processed only once; Events lacking key fields will not enter the legitimate authority status generation process; Events that do not trigger a persistent state transition are not written to the state snapshot and are only used to generate performance patches.

[0027] After generating a normalized event, the system forms a candidate state change request or a performance trigger request based on the event type, node type, action type, and business load of the normalized event. The candidate state change request is used to drive the object to enter the business stage state inference (S3) and the legitimate authority state generation process (S5); the performance trigger request is used to drive the object to generate short-term visual performance without directly changing the object's long-term legitimate authority state.

[0028] The event type (eventType) refers to the category of the event in the system, used to distinguish the handling method of the event. For example, it may include: persistent state events: events that cause continuous changes in the state of an object; transient business events: events that only trigger short-term behavior and do not form a long-term state; alarm events: events related to alarm triggering, processing, and cancellation; and statistical derivative events: events used for situation statistics and indicator display.

[0029] The node type (nodeType) refers to the category of scene nodes or objects affected by the event, used to identify which type of 3D scene node object the event corresponds to. For example, it may include: manual verification counters, self-service verification counters, X-ray machines, baggage objects, alarm objects, and other security check area equipment or node objects.

[0030] The action type refers to the specific business action corresponding to the event, which describes what business changes have occurred for the object. For example, it may include: counter opening and closing; staff going on duty and leaving duty; passenger verification successful or unsuccessful; X-ray machine being activated or deactivated; luggage placement, scanning, opening, and retrieval; alarm triggering, processing, and deactivation.

[0031] The business payload refers to the specific business data content carried by the event, used to supplement the attribute information required for event processing. For example, it may include: business device number; counter number; bag ID; passenger ID number; and other attribute parameters related to this business action.

[0032] S3: Business Execution Phase Status Inference For the target object (the object currently being processed by the system, whose state needs to be inferred or whose behavior needs to be updated), upon receiving a normalized event, it does not directly enter the final authoritative state, but first enters the business stage state inference process. That is, by combining the target object's current state (which is stored in the latest state snapshot), the most recent related event sequence, the states of associated objects, the time interval between adjacent events, and the preset stage transition rules, the candidate business stage state in which the target object is currently located is inferred.

[0033] The business stage state is used to describe the stage position of the target object in the business process, not to describe the continuous movement trajectory of the target object in physical space. Wherein: The business stage status of manually verified counter objects includes (reference) Figure 3 ): COUNTER_READY PASSENGER_VERIFYING VERIFY_SUCCESS_COMPLETED VERIFY_FAILED_PENDING_RECHECK For example, when the manual verification counter is open and the staff is on duty, and the system receives a processing event before the passenger's verification is successful or failed, the system infers that the counter is in the PASSENGER_VERIFYING stage.

[0034] The operational stages of baggage items include (see reference) Figure 4 ): BAG_PENDING_SCAN BAG_SCAN_COMPLETED BAG_CHECK_EXCEPTION BAG_OPEN_CHECKING BAG_COMPLETED For example, when a baggage object has received a baggage placement event but has not yet received a scan completion event, the system infers that the baggage object is in the BAG_PENDING_SCAN stage; when the scan result is received, the system infers that the baggage object has entered the BAG_SCAN_COMPLETED stage; when an anomaly check-related event is received, the system infers that the baggage object has entered the BAG_CHECK_EXCEPTION or BAG_OPEN_CHECKING stage.

[0035] The business phase status of the alarm object includes: ALARM_TRIGGERED ALARM_PROCESSED ALARM_CLEARED S4: Execution of Business Constraint Conflict Resolution (Reference) Figure 5 ) Perform business constraint validation on candidate service stage states and candidate state change requests to determine whether they meet preset business constraints. The business constraints include: Preconditions: These constraints limit an event or phase transition to a specific state that can only take effect in the current state.

[0036] For example, when the manual verification counter object is not currently in the PASSENGER_VERIFYING state, a successful verification event should not directly cause it to enter the VERIFY_SUCCESS_COMPLETED state.

[0037] Time sequence constraint: Used to restrict the order of events to a predetermined time sequence.

[0038] For example, for the same alarm object, the alarm clearing event should occur later than the alarm triggering event.

[0039] Business closed-loop constraint: Used to limit the migration of certain stages to meet the complete business chain.

[0040] For example, when the manual verification counter is closed or unattended, it should not directly generate a verification success status or a verification failure pending review status.

[0041] Mutual exclusion state constraint: used to restrict the same object from being in multiple logically mutually exclusive states at the same time.

[0042] For example, the same manual verification counter object cannot be in two mutually exclusive completed states other than COUNTER_READY and PASSENGER_VERIFYING at the same time, that is, it cannot be in VERIFY_SUCCESS_COMPLETED and VERIFY_FAILED_PENDING_RECHECK at the same time.

[0043] Related object constraints: Related object constraints are used to limit the state transition of a target object to the state conditions of other objects that have a related relationship with it.

[0044] For example, when a baggage object enters the BAG_COMPLETED state, the system makes a comprehensive judgment based on the verification status of the passenger to which it belongs, as well as the completion status of the baggage object's own scanning, anomaly check, or bag opening check.

[0045] After business constraint verification, the system performs one of the following processes on the corresponding request (the candidate state change request currently undergoing constraint verification in step S4): Acceptance: When the candidate business stage status meets all business constraints, the system accepts the candidate status change request, marks it as a legitimate status transition request, and outputs it to step S5 to enter the legitimate authoritative status generation process.

[0046] Temporary storage: When the current state constraint or associated object constraint is not met temporarily, but subsequent events may still complete the business chain, the system will temporarily store the corresponding request and wait for the supplementary event to arrive before re-executing the business constraint verification.

[0047] For example, if a piece of luggage has received an event related to an anomaly check but has not yet received the corresponding scan completion event, the system can temporarily store the candidate status change request.

[0048] Rejection: When the state of a candidate business stage clearly violates the business closed-loop constraints and mutual exclusion state constraints, and subsequent events cannot remedy the situation, the system rejects the state transition request.

[0049] For example, if an alarm cancellation event is received directly before an alarm object has been triggered, the system will reject the state transition request.

[0050] Delayed processing: When a candidate state change request meets the business logic, but the event arrival order is abnormal and the time order needs to be corrected, the system performs delayed processing on the request.

[0051] For example, if the retrieval event for the same baggage object arrives at the system before the scanning event, the system can delay the processing of the candidate status change request triggered by the retrieval event and re-determine it after the order is corrected.

[0052] Triggering partial state rollback: When a candidate state change request has participated in the current state chain (the object's state change history) and has caused a state result, but subsequent verification finds that it conflicts with business constraints, or the existing state chain becomes invalid after a late event arrives, the system triggers step S6 partial state rollback, and re-executes the phase state inference, business constraint verification and state adjudication on the relevant object's partial event chain.

[0053] For example, if a baggage object has entered the completed state, and then receives an abnormal check event with an earlier timestamp, causing the current state chain (e.g., BAG_PENDING_SCAN, BAG_SCAN_COMPLETED, BAG_CHECK_EXCEPTION, BAG_OPEN_CHECKING, and BAG_COMPLETED) to become invalid, the system will trigger a partial state rollback.

[0054] S5: Generate a legitimate and authoritative state The legitimate state transition request obtained after business constraint verification in step S4 is submitted to the state machine module, a sub-functional module within the legitimate state generation module. The state machine module, combining the current state snapshot of the target object and preset state transition rules, performs state transition calculations on the legitimate state transition request to generate the legitimate authoritative state of the target object. The current state snapshot, stored in the state snapshot module, records the latest legitimate authoritative state of the target object; the preset state transition rules define the legitimate transition paths and conditions between the target object's states at each business stage.

[0055] The legitimate and authoritative state, as the only valid state of the target object at present, serves as the basis for subsequent state snapshot updates, patch generation, and state rollback operations.

[0056] In this solution, the state machine module does not directly consume the original business events, but instead consumes legitimate state transition requests that have undergone event semantic mapping, business stage state inference, and business constraint conflict resolution. In this way, the present invention establishes an interpretable intermediate inference layer between the discrete original business event input and the final digital twin state output, thereby improving the stability and technical depth of state construction.

[0057] S6: Perform partial state rollback ( Figure 6 ) When the system detects an invalid current state chain in step S4, a partial state rollback is performed. Situations that trigger a partial state rollback include: A late event arrives and conflicts with the current state chain; The insertion of a compensation event caused a break in the business sequence; The reconstruction state in the recovery scenario is inconsistent with the current legitimate authority state; The same object exhibits continuous state transitions that fail to meet business constraints.

[0058] Local state rollback includes the following processes: Locate the most recent legitimate authoritative state snapshot: The system locates the most recent legitimate authoritative state snapshot related to the current object in the state snapshot sequence as the rollback starting point.

[0059] Extract local event chain: Extract the local event chain related to the object from the time of the most recent legitimate authority state snapshot to the current time, and sort the information according to timestamp and version.

[0060] Re-adjudicate local event chains: Based on the current business constraint rules and business stage state inference rules, re-execute business stage state inference, business constraint conflict resolution, and legitimate authority state generation on local event chains.

[0061] Reconstruct legitimate authority state: Replace the original illegitimate state chain with the recalculation result (the correct legitimate authority state sequence obtained after recalculation), generate a new legitimate authority state, and update the latest legitimate authority state snapshot corresponding to the target object.

[0062] S7: Update the state snapshot and generate a patch. Update the target object's state snapshot based on its legitimate and authoritative status, and simultaneously update the scene's state snapshot. After the state snapshot update is complete, generate an incremental patch. The patch includes: StatePatch: Used to express an authoritative state change of an object, including at least the object identifier, state version, changed fields, new state, and effective time. RenderPatch: Used to drive the short-term visual appearance of an object, including at least object identifier, appearance action, appearance parameters, duration and priority; StatsPatch: Used to express real-time statistical results.

[0063] Patch generation follows these rules: 1. Only generate patches for objects that have changed; 2. Only output the fields that have changed; 3. Changes to multiple objects are broken down into object-level patches; 4. Merge consecutive mergeable patches within the window without altering the state semantics; 5. Patches carry state and version information; repeated consumption does not affect the final state.

[0064] S8: Driving 3D and 2D Linked Display (Reference) Figure 8 ) The status patch and performance patch generated in step S7 are distributed to the front-end display module to drive the 3D scene node objects and 2D situation components to update in conjunction with each other based on the same patch source.

[0065] The front-end display module includes a 3D display submodule and a 2D status display submodule: 1. The 3D display submodule updates the state and appearance of scene node objects based on state patches and appearance patches; 2. The two-dimensional situational awareness submodule refreshes metrics, charts, status bars, and alarm bars based on status patches and performance patches.

[0066] Among them, the state patch serves as the basis for object state synchronization, while the presentation patch serves as the basis for visual updates of 3D scene node objects and 2D situational components.

[0067] S9: Execute continuous and transient state divide and conquer (see reference) Figure 7 ) After generating the legitimate authority state in step S5 and before generating the patch in step S7, this step divides the legitimate authority state output by S5 into two categories: persistent and transient, and adopts different processing strategies: The persistent state is captured in a snapshot and retained as the current legitimate and authoritative state indefinitely. Simultaneously, a state patch is generated in step S7. The persistent states include: counter open / closed state, X-ray machine operating state, staff on duty status, and alarm activated state.

[0068] Transient states are not written to the long-term authoritative state; they are only generated as performance patches in step S7 to trigger short-term visual actions. Transient states include: verification pass effect, verification failure prompt, short-term luggage placement animation, short-term alarm flashing, and one-time audio-visual actions.

[0069] Transient state processing rules include: Only the last instance of the same instantaneous event involving the same object within a preset time window is retained; High-priority instant effects can override low-priority effects; When the page is initialized, disconnected and reconnected, or closed and reopened, only the continuous state is restored, and the historical instantaneous state is not replayed; In history playback mode, the instantaneous performance can be reconstructed according to the event timeline.

[0070] S10: Establish object binding relationship To achieve accurate mapping between business objects and 3D scene node objects, the system employs an object binding mechanism. This establishes binding relationships between the business object layer, the twin object layer, and the model node layer. Specifically: 1. The business object layer is used to describe object entities in the business system. Each business object has a unique business identifier. 2. The twin object layer is used to describe the digital twin objects within the system. The twin objects record the mapping relationship between business objects and scene nodes. 3. The model node layer is used to describe node objects in the 3D scene. Each model node has a unique nodeId and a corresponding nodeType.

[0071] Based on the mapping relationship in the background configuration management, the system maps the business object identifier to the 3D scene node identifier nodeId and the node type nodeType, thereby establishing a binding relationship between the business object and the 3D scene node object.

[0072] A business object can be bound to one or more model nodes; the two-dimensional situation component and the three-dimensional scene node object share the same business object identifier or the same mapped node identifier.

[0073] For each baggage object, the system maintains a unique baggage number (bagId) and establishes a one-to-many association between the passenger object and the baggage object through the passenger identifier (passengerId). One passenger object corresponds to zero or one or more baggage objects.

[0074] It should be noted that step S10 is a backend management operation that maintains a mapping table between all device service identifiers and 3D scene node identifiers (nodeId), providing the source for mapping lookup in step S2.

[0075] S11: Execution State Recovery and Exception Handling During initialization, disconnection recovery, shutdown and reopening, or mode switching, the system restores the scenario's running state by obtaining the latest valid state snapshot. After the state snapshot restoration is complete, it accesses subsequent original business event data after the snapshot time point. When there are event gaps, it fills in the original business event data corresponding to the gaps. Specifically: Page initialization is performed in the following order: 1. Load scene resources; 2. Rebuild object mapping relationships; 3. Obtain the latest valid status snapshot; 4. Initialize the object state; 5. Access subsequent event data after the snapshot time point; when there is an event gap, fill in the event data corresponding to the gap.

[0076] No historical animations or short-term effects are triggered before the state initialization is complete.

[0077] In scenarios involving disconnection recovery or shutdown and reopening, the system executes the following: 1. Obtain the latest valid status snapshot; 2. Restore the current running state of the target object and its associated objects; 3. Rebuild object binding relationships; 4. Access event data after the snapshot time point; when there are event gaps, fill in the event data corresponding to the gaps; 5. When an invalid state chain is detected after recovery, a partial state rollback is triggered.

[0078] When an abnormal situation occurs, the system performs the following corresponding actions based on the abnormality type: 1. For cases where a standardized event lacks key fields, the corresponding event will be transferred to the exception handling queue; 2. In cases where object mapping is missing, log the mapping exception and output a configuration exception message; 3. In the event of a snapshot recovery failure, the system enters a secure display state and outputs a status synchronization failure message; 4. In cases of abnormal event sequence, the system will perform temporary storage, delayed processing, or partial state rollback depending on the severity of the abnormality.

[0079] It should be noted that steps S1 to S11 described in this invention are all independent technical steps, and each step can be implemented alone or in combination with other steps. Any product or method that uses any independent step of this invention as the core of its technical solution falls within the protection scope of this invention.

[0080] This invention is a security inspection operation status management system based on discrete business event semantics, such as... Figure 9As shown, it includes the following modules: Data source module – Environmental data generated by security checks.

[0081] Data access, parsing and standardization module: used to access multi-source raw business data and complete protocol parsing, field extraction, business object identifier mapping, event type identification, action semantic recognition, legality verification and standardized event generation.

[0082] Business phase state inference module: used to generate candidate business phase states by combining the current state of the object, the event window, the state of the associated object, and the phase transition rules.

[0083] Business constraint conflict resolution module: It is used to perform legality verification on the status of candidate business stages according to preset business constraints, and output the processing results of accepting, temporarily storing, rejecting, delaying processing or triggering partial state rollback.

[0084] Legitimate Authority Status Generation Module: Used to generate the legitimate authority status of an object based on the legitimate status migration request that has passed the business constraint verification.

[0085] Local state rollback module: used to locate the most recent valid state snapshot when the state chain is invalid, and to recalculate the local event chain.

[0086] State Snapshot Module: Used to maintain and persist the latest legitimate authority state of the scene and objects.

[0087] Patch generation and distribution module: Used to generate status patches, performance patches and statistical patches based on status changes, and distribute the patches to the front-end display module.

[0088] Front-end display module: Used to drive the coordinated rendering of the 3D display submodule and the 2D situational awareness submodule based on the patch. The legitimate authority generation module is the sole source of authority status; the front-end display module does not directly modify the authority status.

[0089] It should be noted that each functional module described in this invention is an independently operating technical unit, each constituting an independent technical solution, and each can be implemented and protected independently. Any system or method that uses any independent module of this invention as the core of its technical solution falls within the protection scope of this invention.

[0090] The above description is only a preferred embodiment of the present invention and is not intended to limit the design of this case. All equivalent changes made based on the key design features of this case shall fall within the protection scope of this case.

Claims

1. A security inspection operation status management method based on discrete business event semantics, characterized in that, Includes the following steps: S1: Real-time access to discrete raw business event data of security inspection services; S2: Parse, map, and standardize the raw business event data to generate standardized events; based on the event type, node type, action type, and business load of the standardized events, generate candidate state change requests or performance trigger requests; S3: Business Stage Status Inference: After receiving a normalized event, the current status of the target object, the sequence of most recent related events, the status of associated objects, the event time interval, and the preset stage transition rules are combined to infer the current candidate business stage status of the target object; S4: Business Constraint Conflict Resolution: Based on preset business constraints, perform business constraint verification and conflict resolution on the candidate business stage status and candidate status changes, and generate a legal state transition request. S5: Generate the legitimate authority state of the target object based on the legitimate state transition request; S6: Local state rollback: When the current state chain is detected to be invalid in step S4, locate and recalculate the local event chain based on the most recent valid authoritative state snapshot to generate a new valid authoritative state; S7: Update the target object's state snapshot based on its legitimate authority status and generate an incremental patch; S8: Distribute the patch generated in step S7 to the front-end display module to drive the 3D scene node objects and 2D situation components to update in conjunction with the same patch source.

2. The security inspection operation status management method based on discrete business event semantics as described in claim 1, characterized in that: In step S1, the original business event data includes: the open or closed status of manual verification counters and self-service verification counters; on-duty personnel's on-duty, off-duty, and temporary off-duty events; passenger verification success and failure events; X-ray machine activation and deactivation events; passenger baggage placement, baggage scanning, baggage opening, and baggage retrieval events; system alarm events; and statistical derivative events.

3. The security inspection operation status management method based on discrete business event semantics as described in claim 1, characterized in that: In step S2, the business identifier ID in the original business data payload is mapped to the scene node identifier and node type to generate a standardized event with a unified format within the system. The normalized event includes at least the following fields: eventId, used to identify the uniqueness of the event; eventType, used to identify the event type; and timestamp, used to identify the time the event occurred. sceneId is used to identify the scene; nodeType is used to identify the type of model node or object in the scene; nodeId is used to identify the model node in the scene; source is used to identify the source system. The action is used to identify the action type; headers are used to carry event header information; payload is used to carry business data attributes; and version is used to indicate version information.

4. The security inspection operation status management method based on discrete business event semantics as described in claim 1, characterized in that: In step S3, the business stage status includes: The business stage status of the manual verification counter object: COUNTER_READY, PASSENGER_VERIFYING, VERIFY_SUCCESS_COMPLETED, and VERIFY_FAILED_PENDING_RECHECK; The business phase status of baggage objects: BAG_PENDING_SCAN, BAG_SCAN_COMPLETED, BAG_CHECK_EXCEPTION, BAG_OPEN_CHECKING, and BAG_COMPLETED; The business phase status of the alarm object: ALARM_TRIGGERED, ALARM_PROCESSED, and ALARM_CLEARED.

5. The security inspection operation status management method based on discrete business event semantics as described in claim 1, characterized in that: In step S4, the business constraints include: Preconditions: These constraints are used to limit an event or phase transition to only taking effect in a specific current state. Time sequence constraints: used to restrict the order of events to a predetermined time sequence. Business closed-loop constraints: These are used to limit the migration of certain stages to meet the requirements of a complete business chain; Mutual exclusion state constraint: used to restrict the same object from being in multiple logically mutually exclusive states at the same time; Related object constraints: These are used to limit the state transition of a target object to the state conditions of other objects that have a related relationship with it. After business constraint verification, the candidate state change request is processed by accepting, temporarily storing, rejecting, delaying, or triggering partial state rollback.

6. The security inspection operation status management method based on discrete business event semantics as described in claim 1, characterized in that: In step S6, the process of local state rollback is as follows: locate the most recent legitimate authority state snapshot, extract the local event chain, re-adjudicate the local event chain, and reconstruct the legitimate authority state.

7. The security inspection operation status management method based on discrete business event semantics as described in claim 1, characterized in that: In step S7, the patch includes: StatePatch: Used to express changes in the authoritative state of an object; RenderPatch: Used to drive the short-term visual appearance of an object; StatsPatch: Used to express real-time statistical results; Patch generation follows these rules: Patches are generated only for objects that have changed; only the fields that have changed are output; changes to multiple objects are split into object-level patches; consecutive mergeable patches are merged within the window without changing the state semantics; and patches carry state version information, so repeated consumption does not affect the final state.

8. The security inspection operation status management method based on discrete business event semantics as described in claim 7, characterized in that: In step S8, the front-end display module includes a 3D display submodule and a 2D situational awareness submodule: the 3D display submodule updates the state and appearance of scene node objects according to the state patch and appearance patch; the 2D situational awareness submodule refreshes indicators, charts, status bars and alarm bars according to the state patch and appearance patch.

9. The security inspection operation status management method based on discrete business event semantics as described in claim 1, characterized in that, It also includes S9: performing persistent and transient divide-and-conquer: dividing the legitimate authority state into two categories, persistent and transient, and adopting different processing strategies; the persistent state enters a state snapshot and is retained as the current legitimate authority state for a long time, while generating a state patch; the transient state does not enter a long-term authority state, but only generates a performance patch.

10. A system for managing the operational status of security checks based on the semantic-driven discrete business events method according to any one of claims 1 to 9, characterized in that, At least including: The module includes a data access parsing and standardization module, a business stage state inference module, a business constraint conflict resolution module, a legitimate and authoritative state generation module, a partial state rollback module, a state snapshot module, a patch generation and distribution module, and a front-end display module.

Images