Security checkpoint twin consistency recovery method and system based on state snapshot and incremental compensation

Abstract

The application discloses a security check twin consistency recovery method and system based on state snapshots and incremental compensation, the recovery system comprises a data access module, a digital twin engine module, a recovery control module, a patch history storage module and a display module; the recovery method comprises the following steps: the display module generates a recovery request and sends the recovery request to the recovery control module in response to a recovery trigger condition of a display session; the recovery control module acquires the latest state snapshot of a target scene, establishes a recovery barrier, sends the snapshot to a display end and waits for an application confirmation; then, an incremental compensation window is calculated according to the snapshot, the recovery request and the barrier, candidate patches in the window are queried from a patch history, the compensation patches are released in sequence after being sorted, gap detected and semantically filtered, and finally, consistency verification is performed. The application can avoid the repeated compensation of process animation or short-time prompts in the recovery process.

Description

Technical Field

[0001] This invention belongs to the field of security inspection business and digital twin scenario recovery technology, and specifically relates to a security inspection twin consistency recovery method and system based on state snapshot and incremental compensation. Background Technology

[0002] With the increasing digitalization of civil aviation security checkpoints, security command centers are placing higher demands on the consistent display of 3D digital twin scenes, 2D monitoring dashboards, equipment operating status, and alarm status. Currently, the security digital twin system can update the status of manual verification counters, pre-security check equipment, X-ray machines, metal detectors, security check lanes, and alarm objects in real time by accessing security check business message events. It also pushes status change events to the front end for real-time display via WebSocket (a network communication protocol that establishes a persistent, full-duplex connection between a client (such as a browser) and a server) or other message push methods.

[0003] However, while existing security inspection digital twin systems can update the scene status based on continuously arriving business events sent from the backend during normal real-time operation, they still have the following significant shortcomings in recovery scenarios such as page initialization, browser refresh, network disconnection and reconnection, display terminal shutdown and reopening, and switching between real-time mode and other modes: 1. If the scene is reconstructed solely by relying on real-time events received after recovery, the front end lacks a complete baseline state in the early stages of recovery, which can easily lead to problems such as missing devices, missing alarms, delayed statistical values, or incomplete 3D node states. 2. If all historical events during the disconnection period are simply replayed, the process of passing security checks, placing personal luggage, and device alarms will be repeatedly played, causing users to mistakenly believe that the corresponding actions just happened on site, which seriously affects the experience and decision-making accuracy. 3. If only the latest snapshot is issued without processing the incremental changes between the snapshot generation and the completion of the front-end application, the effective state updates within the recovery window will be lost, resulting in the final state being inconsistent with the actual state. 4. If there is a lack of a unified cursor, timestamp, or version connection between snapshots and incremental patches, the front end may consume patches repeatedly, miss patches, or apply patches in the wrong order, further exacerbating state chaos. 5. When there are gaps in the patch history, incompatible snapshot structure versions, or incomplete device master data, the system lacks a verifiable degradation strategy, which may lead to continued display in an inconsistent state, posing risks to command and decision-making.

[0004] Therefore, there is an urgent need for a consistency recovery method for security inspection digital twin scenarios, which allows the front end to first obtain the final snapshot baseline during the recovery process, then compensate for necessary incremental changes, and perform verification and degradation processing on the recovery results, thereby restoring display consistency without interrupting the real-time processing of the back end. Summary of the Invention

[0005] The purpose of this invention is to provide a security inspection twin consistency recovery method and system based on state snapshots and incremental compensation. It achieves consistent recovery of scene state based on reliable state snapshots and incremental patches, and avoids problems such as missed patch events, duplicate compensation, out-of-order compensation, and repeated playback of process transient events during the recovery period.

[0006] To achieve the above objectives, this invention provides a security inspection twin consistency recovery method based on state snapshots and incremental compensation, comprising the following steps: S1. The display module responds to the recovery trigger condition of the display session, generates a recovery request, and sends the recovery request to the recovery control module. The recovery trigger condition includes at least one of the following: page initialization, user refresh, communication connection disconnection and reconnection, display terminal shutdown and reopening, scene model reloading, and switching from real-time mode to or from playback mode back to real-time mode. S2. The recovery control module calls the digital twin engine module to obtain the final state snapshot of the target scene according to the recovery request, and establishes a recovery barrier on the display session. The recovery barrier is used to prevent the real-time patch from being directly released to the display session before the final state snapshot application is completed and the incremental compensation is completed. S3. The recovery control module sends the final state snapshot to the display module's display terminal and requests the display terminal to return an application completion confirmation after completing the snapshot application. S4. The recovery control module calculates the incremental compensation window based on the final state snapshot, recovery request, and recovery barrier. S5. The recovery control module queries the candidate incremental patches located in the incremental compensation window from the patch history storage module, and performs sorting, deduplication, version verification and gap detection on the candidate incremental patches. S6. The recovery control module performs recovery semantic filtering on the candidate incremental patches that have been sorted, deduplicated, verified by version and detected by gaps, to obtain a set of compensation patches. The recovery semantic filtering includes at least: retaining persistent patches and discarding transient patches, wherein persistent patches are patches that affect the current final state and transient patches are patches used to express process animations or short-term prompts. S7. After confirming the final state snapshot application is completed on the display end, the recovery control module releases compensation patches to the display session according to the patch sorting result. S8. After the compensation patch is released, the recovery control module performs a consistency check on the recovery results of the display terminal. S9. When the consistency check passes, the display session will be marked as recovered, the recovery barrier will be removed, and the display session will be connected to the real-time patch stream. S10. If, during the recovery process, a patch history gap, snapshot version incompatibility, compensation window exceeding a preset threshold, missing device master data, application timeout, or consistency verification failure is detected, an abnormal degradation rule is executed.

[0007] Furthermore, in step S1, the recovery request includes at least the scene model identifier, session identifier, recovery type, last confirmed message identifier of the client, last confirmed message time or message cursor of the client, client protocol version, and client snapshot structure version.

[0008] Furthermore, in step S2, after obtaining the final state snapshot of the target scene, the recovery control module verifies the structure version, scene model identifier, snapshot summary, and basic master data mapping relationship of the final state snapshot. If the snapshot structure version is incompatible with the display end protocol version, or if the snapshot lacks the scene structure, device set, or basic mapping relationship required by the display end, then the release of the patch is stopped and the operation of re-acquiring the snapshot or security display processing is initiated.

[0009] Furthermore, in step S2, for new real-time patches generated after the recovery barrier is established, the recovery control module writes them into the session temporary storage queue, or records their upper bound cursor and retrieves them uniformly from the patch history storage module during the compensation query phase in step S5; after the recovery barrier is removed in step S9, the recovery control module releases the patches in the temporary storage queue according to the continuity relationship between the last compensation cursor and the real-time patch cursor, or starts pushing real-time patches from after the latest cursor on the server, thereby avoiding duplicate release or omission of patches.

[0010] Furthermore, in step S4, the incremental compensation window adopts a left-open, right-closed or equivalent boundary rule. The lower bound of the compensation window is determined based on the snapshot compensation cursor, snapshot status time, or snapshot status version. When the client's last confirmed cursor is valid after server verification and is later than the snapshot compensation cursor, the client's last confirmed cursor is used as the lower bound of the compensation window. The upper bound of the compensation window is determined based on the recovery barrier establishment time, compensation query time, the server's latest patch cursor, or the cursor at the end of the session temporary queue.

[0011] Furthermore, in step S6, during the recovery semantic filtering, persistent patches that have already been covered by snapshots are not released again; patches with multiple consecutive state changes for the same device or the same alarm object are merged into the last valid state according to the state version or message cursor; persistent patches that occur within the recovery window and still affect the current final state are retained as compensation patches; and transient patches that have ended before disconnection, shutdown, or initialization are not re-replayed.

[0012] Furthermore, in step S7, during the release of compensation patches, the display terminal only applies the compensation patches to state changes after the snapshot, and rejects expired patches, duplicate patches, or patches that do not belong to the current recovery batch based on the state version, entity identifier, and recovery batch identifier carried by the compensation patch. If a timeout, application failure, or version conflict is returned by the display terminal during the compensation process, the recovery control module suspends the release of subsequent patches and performs a new snapshot or security display process.

[0013] Furthermore, in step S8, the consistency verification includes at least one of device set verification, valid alarm set verification, statistical summary verification, status summary verification, patch cursor continuity verification, recovery batch verification, snapshot structure version verification, and master data mapping verification; the verification method is that the server calculates the expected summary based on the snapshot and patch and compares it with the summary returned by the display end, or the display end returns the last applied cursor, device set summary, alarm set summary, and statistical summary and the server performs the verification.

[0014] Furthermore, in step S10, the abnormal degradation rules include one or more of the following: reacquiring the final state snapshot, abandoning incremental compensation and using full snapshot recovery instead, requiring the display terminal to clear the local session state and then reapply the snapshot, and entering a secure display state. In the secure display state, the display terminal keeps the scene structure visible, but does not mark the device running status, alarm status, or statistical values ​​as synchronized.

[0015] This application also provides a security inspection twin consistency recovery system based on state snapshots and incremental compensation, used to perform any of the above recovery methods, including: The data access module is used to receive security inspection business events in real time and convert these events into standardized events with a unified format. The digital twin engine module is used to generate final state, final state snapshot, and incremental patches based on standard events; The patch history storage module is used to save patch events with time, cursor, version, and semantic category. The recovery control module is used to identify recovery requests, establish recovery barriers, calculate compensation windows, and query and release compensation patches. The display module is used to apply final state snapshots and compensation patches to create a consistent display of 3D scenes, 2D monitoring dashboards, effective alarms, and statistical status on the display terminal.

[0016] After adopting the above solution, the beneficial effects of the present invention are as follows: 1. This application adopts a recovery order of first obtaining the final state snapshot and then compensating with incremental patches, which enables the front end to quickly restore the complete initial state, including device status, valid alarm set and statistical baseline, and quickly fill in the gaps according to the valid state changes after the snapshot is generated, avoiding problems such as missing devices, missing alarms or lag in statistical values ​​caused by relying solely on subsequent real-time events.

[0017] 2. This application establishes a recovery barrier to prevent subsequent real-time patches from arriving prematurely before the snapshot has been applied, thereby reducing the risk of inconsistencies in state caused by the simultaneous activation of different front-end applications.

[0018] 3. This application introduces recovery semantic categories (continuous state / transient state) to automatically filter out transient process animations and short-term prompt events during the compensation phase, preventing process animations during disconnection or shutdown from being replayed after recovery, avoiding user misjudgment, and ensuring that the final device status and effective alarm time are accurately restored.

[0019] 4. This application utilizes compensation window boundary rules and sorting, deduplication, version verification, and gap detection mechanisms to ensure precise connection between snapshots and patches, avoid patch omissions, duplicate consumption, or incorrect ordering, and reduce issues such as missed events, re-events, duplicate compensation, and out-of-order compensation during the front-end scene 3D scene restoration process.

[0020] 5. After compensation is completed, this application performs multi-dimensional consistency verification (device set, alarm set, statistical summary, cursor continuity, etc.), which makes the recovery results quantifiable and verifiable, significantly improving the reliability of the system. When patch gaps, version incompatibility, missing master data, or verification failure are detected, it can automatically perform a new snapshot, full recovery, or enter a safe display state to prevent the system from continuing to output erroneous information in an inconsistent state and ensure the security of command and decision-making.

[0021] 6. This application restricts the recovery logic to the Session side (front-end display session side) and Control side (back-end recovery control module side), avoiding intrusion into the digital twin engine and not changing the engine's original reliable state generation mechanism, thereby allowing real-time business applications to focus more on processing the current message link.

[0022] 7. This application is not only applicable to security inspection digital twin scenarios, but can also be extended to other real-time display systems that require high consistency state recovery (such as smart factories, traffic monitoring, emergency command, etc.), and has good versatility and industrial application value. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the system structure of the present invention; Figure 2 This is a schematic diagram of the recovery timing of the present invention; Figure 3 This is a schematic diagram of the patch recovery semantic filtering of the present invention; Figure 4 This is a schematic diagram of the structure of the snapshot and patch data of the present invention; Figure 5 This is a logical diagram illustrating the abnormal degradation and security display states of the present invention; Figure 6 This is a schematic diagram of the recovery timing in Embodiment 5 of the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application, and the range values ​​mentioned in this application all include endpoint values.

[0025] Key references Figures 1-5 This invention provides a security inspection twin consistency recovery method based on state snapshots and incremental compensation. The recovery method is implemented by a recovery system, which includes a data access module, a digital twin engine module, a recovery control module, a patch history storage module, and a display module.

[0026] The data access module receives security check events in real time and formats them into standardized events. These events can be discrete, raw data generated in the security check production environment, such as the opening or closing status of verification counters, staff attendance and departure, passenger verification success or failure, X-ray machine activation and deactivation, passenger baggage retrieval, system alarms, and statistically derived events. Specifically, the data access module performs protocol parsing, field extraction, format conversion, validity verification, and unified encapsulation on the raw event data to create standardized events in a unified format.

[0027] The digital twin engine module is used to generate final states, final state snapshots, and incremental patches based on standard events. The final state is a unique, authoritative, and valid state result generated by the digital twin engine module for each business object at the current moment after complete business logic adjudication. Business objects refer to all entity objects described in the security check business system, including counters, luggage, personnel, equipment, alarms, etc., and each business object has a unique business identifier. For example... Figure 4 As shown, the final state snapshot represents the authoritative result of the target security inspection digital twin scenario at the snapshot state moment. It includes at least one or more of the following: scenario model identifier, scenario structure or grouping structure, device set (including manual verification counters, X-ray machines, security checkpoints, etc.), current device operating status, device business attributes, valid alarm set, statistical data, snapshot state time, snapshot compensation cursor, snapshot structure version, and snapshot summary. The incremental patch represents the transportable changes in the final state between adjacent states. It includes at least one or more of the following: patch identifier, message time, message cursor, state version, entity type, entity identifier, operation type, patch summary, and recovery semantic category. The recovery semantic category constrains the processing rules of patches in the recovery scenario.

[0028] The patch history storage module is used to save patch events with time, cursor, version and semantic category; the cursor is used to uniquely identify the order of each event (such as a patch message) in the event stream.

[0029] The recovery control module is used to identify recovery requests, establish recovery barriers, calculate compensation windows, and query and release compensation patches. The compensation window is a time range or cursor range used to define which historical patches need to be included in the compensation consideration; the compensation patch refers to the set of patches that are actually sent to the display end from the candidate patches in the compensation window after sorting, deduplication, version verification, gap detection, and recovery semantic filtering, for incremental application on the snapshot baseline.

[0030] The display module is used to apply final state snapshots and compensation patches to form a consistent display of 3D scenes, 2D monitoring dashboards, effective alarms, and statistical status on the display terminal.

[0031] Key references Figure 1 and Figure 3 The recovery method includes the following steps: S1. The display module, in response to the recovery trigger conditions of the display session, generates a recovery request and sends the recovery request to the recovery control module. The recovery trigger conditions include at least one of the following: page initialization, user refresh, reconnection after communication connection loss, reopening after display terminal shutdown, scene model reloading, switching from real-time mode to or from playback mode back to real-time mode. The recovery request includes at least a scene model identifier, a session identifier, a recovery type, the identifier of the last confirmed message from the client, the time or cursor of the last confirmed message from the client, the client protocol version, and the client snapshot structure version. The display session is a session stream connecting the display terminal and the display control module.

[0032] S2. The recovery control module assigns a recovery batch identifier to the recovery request and, based on the recovery request, calls the digital twin engine module to obtain a final state snapshot of the target scene. A recovery barrier is then established on the display session. This recovery barrier prevents real-time patches from being directly released to the display session before the final state snapshot application is completed and necessary incremental compensation is achieved. For new real-time patches generated after the recovery barrier is established, the recovery control module writes them to the session temporary storage queue or records their upper bound cursor and retrieves them uniformly from the patch history storage module during the compensation query phase in step S5.

[0033] After acquiring the final state snapshot of the target scene, the recovery control module verifies the structure version, scene model identifier, snapshot summary, and basic master data mapping relationship of the final state snapshot. If the snapshot structure version is incompatible with the display end protocol version, or if the snapshot lacks the scene structure, device set, or basic mapping relationship required by the display end, the patch release is stopped and the module proceeds to reacquire the snapshot or perform a secure display processing operation. The secure display processing (i.e. Figure 1 The security display control is a set of degradation handling logic that the recovery control module abandons the normal incremental compensation recovery process and executes instead when it detects an anomaly (patch gap, version incompatibility, missing master data, etc.), in order to enter the security display state.

[0034] S3. The recovery control module sends the final state snapshot to the display module's display end and requires the display end to return for application completion confirmation after completing the snapshot application. When the display end applies the snapshot, it reconstructs the display baseline based on the current state in the final state snapshot, including the scene structure, the current state of the device, the set of valid alarms, and the statistical status. It does not generate historical animations for procedural events that have occurred before the final state snapshot and does not present historical short-term prompts as real-time new events.

[0035] S4. The recovery control module calculates the incremental compensation window based on the final state snapshot, recovery request, and recovery barrier. The incremental compensation window uses a left-open, right-closed or equivalent boundary rule. The lower bound of the compensation window (the starting node boundary of the incremental compensation window) is determined based on the snapshot compensation cursor, snapshot state time, or snapshot state version. When the client's last confirmed cursor is valid after server verification and is later than the snapshot compensation cursor, the client's last confirmed cursor is used as the lower bound of the compensation window. The upper bound of the compensation window (the final node boundary of the incremental compensation window) is determined based on the recovery barrier establishment time, compensation query time, the server's latest patch cursor, or the cursor at the end of the session temporary queue. Therefore, the incremental compensation window covers any valid state changes that may be missed from the time the final snapshot is formed until the recovery on the display end. For example, to recover business data from 5:00 AM to 6:00 AM the previous day, the lower bound of the compensation window is 5:00 AM the previous day, and the upper bound is 6:00 AM the previous day.

[0036] S5. The recovery control module queries the patch history storage module for candidate incremental patches located within the incremental compensation window, and performs sorting, deduplication, version verification, and gap detection on the candidate incremental patches. The sorting is based on at least one of message cursor, message time, state version, and patch identifier; deduplication is based on at least one of patch identifier, entity identifier, state version, message cursor, and patch summary; gap detection is based on at least one of cursor continuity, state version continuity, time span threshold, patch summary chain, and patch quantity threshold. If an unfillable gap is detected, the candidate incremental patches are not released; instead, a final state snapshot is re-acquired or the system enters a secure display state. The secure display state refers to the restricted display mode entered by the front-end (display end) after receiving a downgrade command. In this mode, only the static structure is displayed, and dynamic states are either not displayed or explicitly marked as untrusted.

[0037] S6. The recovery control module performs recovery semantic filtering on the candidate incremental patches that have been sorted, deduplicated, version verified, and gap detected, resulting in a set of compensation patches. (See also: [link to relevant documentation]). Figure 3The recovery semantic filtering includes at least the following: retaining persistent patches and discarding transient patches. Persistent patches are those that affect the current final state, including device enable / disable status, device occupancy status, long-term running status, effective alarm activation or deactivation, and statistical value changes. Transient patches are those used to express process animations or short-term prompts, including verification pass flashing, luggage passing animation, and short-term tag effect. In the recovery semantic filtering, persistent patches already covered by snapshots are not released again; patches with multiple consecutive state changes for the same device or alarm object are merged into the last valid state based on the state version or message cursor; persistent patches that occur within the recovery window and still affect the current final state are retained as compensation patches; and transient patches that ended before disconnection, shutdown, or initialization are not replayed. In addition, there are diagnostic patches; the recovery control module records diagnostic information, participates in consistency checks, or triggers a security display state based on their severity.

[0038] S7. After the final state snapshot application is confirmed on the display end, the recovery control module releases compensation patches to the display session according to the patch sorting result. During the release of compensation patches, the display end only applies the compensation patches to state changes after the snapshot, and rejects expired patches, duplicate patches, or patches that do not belong to the current recovery batch based on the state version, entity identifier, and recovery batch identifier carried by the compensation patch. If a timeout, application failure, or version conflict is returned by the display end during the compensation process, the recovery control module suspends the release of subsequent patches and performs a new snapshot or security display processing operation.

[0039] S8. After the compensation patch is released, the recovery control module performs a consistency check on the recovery result of the display terminal. The consistency check includes at least one of the following: device set check, valid alarm set check, statistical summary check, status summary check, patch cursor continuity check, recovery batch check, snapshot structure version check, and master data mapping check. The check method is to compare the expected summary calculated by the server based on the snapshot and patch with the summary returned by the display terminal, or the server can verify the last applied cursor, device set summary, alarm set summary, and statistical summary returned by the display terminal.

[0040] S9. When the consistency check passes, the display session will be marked as recovered, the recovery barrier will be removed, and the display session will be connected to the real-time patch stream. After the recovery barrier is removed, the recovery control module will release the patches in the temporary queue according to the continuity relationship between the last compensation cursor and the real-time patch cursor, or start pushing real-time patches from the latest cursor on the server side, thereby avoiding duplicate release or omission of patches.

[0041] S10, Key Reference Figure 5If, during the recovery process, a patch history gap is detected (detected during patch query in step S5), snapshot version incompatibility is detected (detected during snapshot verification in step S2), the compensation window exceeds a preset threshold (detected after calculating the incremental compensation window in step S4), device master data is missing (detected during snapshot verification in step S2), the display application times out (detected after the display application in step S7), or consistency verification fails, an abnormal degradation rule is executed. The abnormal degradation rule includes one or more of the following: re-acquiring the final state snapshot, abandoning incremental compensation and using a full snapshot for recovery, requiring the display client to clear its local session state and then reapply the snapshot, or entering a secure display state. In the secure display state, the display client keeps the scene structure visible but does not mark the device running status, alarm status, or statistical values ​​as synchronized.

[0042] Through the above recovery method, this invention forms a complete recovery pipeline consisting of "trigger identification, barrier establishment, snapshot application, window calculation, patch query, patch organization, semantic filtering, sequential compensation, consistency verification, barrier removal, and security degradation." This pipeline ensures that the display does not rely on the client cache as the final state, nor does it simply replay all historical events during the disconnection period. Instead, it compensates for necessary state changes on top of the final snapshot baseline, thereby restoring the display consistency of the security inspection digital twin scenario.

[0043] The following provides further explanation through several specific embodiments.

[0044] Example 1: This embodiment demonstrates the real-time recovery process of a session in a disconnection and reconnection scenario. In this embodiment, the recovery is triggered by an abnormal network disconnection and reconnection, and the recovery process is as follows: First, the control module identifies the session as a disconnection and reconnection recovery type and reads the last acknowledgment message identifier, last acknowledgment message time, and scene model identifier carried by the client. The control module calls the digital twin engine module to obtain a snapshot of the final state of the target scene and immediately establishes a recovery barrier on that session. After the recovery barrier is established, new real-time patches are not directly sent to this session, but instead enter a temporary queue or await unified processing during the compensation query phase.

[0045] Next, the control module sends the final state snapshot to the display module. The display module completes local scene initialization based on the scene grouping structure, device status, valid alarm list, and statistical data in the snapshot, and returns a snapshot application completion confirmation to the control module. The control module calculates the incremental compensation window based on the snapshot state time and the recovery barrier establishment time, and queries the patch events within the compensation window from the patch event history.

[0046] For patch events within the compensation window, the control module first sorts them by message time and message identifier, and then removes duplicates based on message identifier and patch summary. If the same state patch for the same device is detected to appear repeatedly, only the last valid patch is retained. If a discontinuous message offset is detected, compensation is stopped and the final state snapshot is re-acquired.

[0047] Next, semantic filtering is performed. During this process, the control module classifies patches into persistent and transient patches. For example, verification of counter opening status, device alarm activation status, changes in valid alarm sets, and changes in statistical values ​​are persistent patches, which should be retained for compensation. Verification pass effects, short flashes, and one-off animations are transient patches, which are not replayed if they occur during the disconnection and do not change the final state.

[0048] After the compensation patch is applied, the control module performs a consistency check. The check items include whether the number of devices in the snapshot is consistent with the number of devices on the display end, whether the set of valid alarms is consistent, whether the statistical summary is consistent, and whether the last compensation patch cursor is continuous. After the check passes, the recovery barrier is removed, and the display session is reconnected to the real-time patch stream.

[0049] Example 2: This embodiment describes snapshot recovery after page initialization, refresh, and closing / reopening. In this embodiment, the recovery is triggered by the page being opened for the first time, the user refreshing the browser, or the display terminal closing and reopening. This type of recovery typically lacks a reliable client-side last confirmation cursor, or the cursor carried by the client has expired. The recovery process differs from Embodiment 1 in that: When calculating the incremental compensation window, if the client does not carry a valid cursor, the lower bound of the compensation window is the snapshot state time of the final state snapshot or the snapshot compensation cursor; if the client carries a valid cursor and the cursor is later than the snapshot compensation cursor, the lower bound of the compensation window is the client's last acknowledgment cursor.

[0050] When applying the final state snapshot, the display module only restores the current device state, valid alarms, and statistical data, without triggering historical verification animations, historical baggage animations, or historical short-term alarm flashing. When the final state snapshot contains a list of valid alarms, the display module directly presents the alarms that are still valid; for expired historical alarms, only statistical results or diagnostic records are retained, and no alarm animations are generated.

[0051] If no compensation patch exists in the compensation window, the control module will directly remove the recovery barrier after receiving confirmation of snapshot application completion. If a compensation patch exists in the compensation window, compensation will be performed according to the sorting, deduplication, and filtering methods described in Example 1. If the snapshot structure version is incompatible with the display protocol version, the control module will not release the compensation patch but will instead return a protocol upgrade or secure display instruction.

[0052] Through this embodiment, the display terminal can quickly restore to the current final state after initialization and reopening, and avoids displaying process events that have already occurred during the shutdown period as newly occurring events.

[0053] Example 3: This embodiment describes threshold-based compensation recovery in a distributed or edge caching scenario. In this embodiment, the control module can be deployed on the central server or cached in edge nodes, containing the most recent final state snapshot and the most recent patch events. Edge nodes are used to improve the recovery speed of the display end and provide limited recovery capabilities when the central link is temporarily unavailable.

[0054] When a session triggers a recovery, the edge node first determines whether the locally cached final state snapshot meets the requirements for structure version, scene model identifier, and maximum lag time. If it does, the edge node calculates a compensation window based on the local snapshot and local patch events; if it does not, the edge node requests a new final state snapshot from the central server.

[0055] Edge nodes determine whether to perform incremental compensation based on the number of compensation patches, the compensation time span, and the amount of compensation data. When the number of compensation patches is less than a preset threshold, the compensation time span is less than a preset threshold, and the gap detection passes, the edge node performs incremental compensation; when any condition exceeds the threshold, the edge node abandons incremental compensation and requests a new full snapshot.

[0056] When the central server is unavailable and the edge node cache has expired, the edge node puts the presentation session into a secure presentation state. In secure presentation state, the presentation client can still display the scene structure and static device configuration, but must not mark the device running status, alarm status, or statistical values ​​as synchronized.

[0057] This embodiment uses a threshold-based compensation strategy to reduce the pressure on the central server when the network is limited or multiple display terminals are recovering simultaneously, while ensuring that the recovery result is not mistakenly regarded as the final state due to expired caching.

[0058] Example 4: This embodiment corresponds to the implementation of a security inspection digital twin project. In one implementation, the digital twin engine module maintains a "StateSnapshot" as the final state snapshot. This snapshot includes the scene model identifier, snapshot time, node running state, and statistical information. The snapshot repository interface is used to load the most recent snapshot of the enabled scene and save the latest snapshot; the time-series repository interface is used to append and query patch event history. When the engine processes standard events, it first generates patch events, then evolves snapshots based on the state machine and saves the patch event history.

[0059] After the real-time WebSocket session is established, the recovery control module first sends a snapshot message to the presentation end; during playback or other mode initialization, a snapshot message can also be sent first before processing subsequent timeline messages. Based on the above engineering, this invention further defines a recovery barrier, compensation window, consistency check, and secure presentation state, ensuring verifiable consistency in the connection between snapshots and patches during the recovery session.

[0060] Example 5: like Figure 6 As shown, this embodiment uses the security checkpoint area of ​​Terminal 2 at an airport as an example to demonstrate the complete recovery process from recovery triggering to real-time access. The digital twin scenario model of this security checkpoint is labeled "T2-SEC-01," and includes 3 security check lanes (each lane contains 1 manual verification counter, 1 X-ray machine, and 1 metal detector gate) and 2 pre-security check devices, totaling 11 devices. The demonstration terminal DISP-A3 accesses the real-time patch stream via a WebSocket session; during normal operation, the last confirmed message cursor is CUR-90000.

[0061] At 05:00:00, the display terminal disconnected due to a network link failure. After the disconnection, the digital twin engine module continued to process events and generate patches: At 05:05:00, the CH-01 counter changed from "idle" to "verifying" (cursor CUR-90001, persistent state); At 05:12:00, the original alarm ALM-45210 was confirmed to be cleared by maintenance (CUR-90002, persistent state); At 05:20:00, the passenger verification was successful, generating a passing animation (CUR-90003, instantaneous state); At 05:25:00, the X-ray machine XR-01 detected a suspicious item, triggering a new alarm ALM-4535 (CUR-90004, persistent state); At 05:30:00, the number of people who passed through the inspection that day was updated to 1327 (CUR-90005, persistent state). Between the snapshot state time and the reconnection of the display terminal, the engine processed two more patches: at 05:45:00, counter CH-02 changed from "idle" to "verifying" (CUR-90006, persistent state), and at 05:55:00, passenger baggage generated a baggage animation as it passed through the X-ray machine (CUR-90007, transient state). The specific recovery process is as follows: S1. At 06:00:00, the DISP-A3 network of the demonstration terminal recovers and re-establishes a connection. The demonstration module recognizes the recovery trigger condition of reconnection after communication connection is lost, generates a recovery request, which includes the scenario model identifier "T2-SEC-01", the new session identifier "SID-7891", the recovery type "RECONNECT", the last confirmation cursor "CUR-90000", the protocol version "v3.2", and the snapshot structure version "STRUCT-v5", and sends the request to the recovery control module.

[0062] S2. Upon receiving the request, the recovery control module assigns a recovery batch identifier "BATCH-20260604-143515-A3" and establishes a recovery barrier on session SID-7891 at 06:00:00. Subsequent real-time patches are not directly released to this session but are written to the session's temporary queue. The recovery control module calls the digital twin engine module to obtain a final state snapshot of scenario "T2-SEC-01," obtaining the snapshot state time 05:30:00, snapshot compensation cursor CUR-90005, and snapshot structure version "STRUCT-v5." The recovery control module verifies that the snapshot structure version is compatible with the client protocol version, and that the snapshot contains a complete scene structure, device set, and basic master data mapping relationship; the verification passes. If the snapshot structure version here is "STRUCT-v6," which is incompatible with the client, patch release is stopped, and the process enters the security display process (corresponding to the abnormal degradation in step S10).

[0063] S3. The recovery control module sends the final state snapshot to the display terminal. The snapshot content includes the scene structure (3-channel grouping and 2 pre-security inspection devices), the current operating status of the devices (CH-01 is "Verifying", XR-01 is "Alarm", and the rest are "Normal"), the set of valid alarms (ALM-4530 and ALM-4535, ALM-4521 has been cleared and is not in the set), and statistics (1327 people passed inspection on the day). The display terminal reconstructs the display baseline based on the current state in the snapshot, directly rendering CH-01 as "Verifying", without generating a transition animation from "Idle" to "Verifying"; it directly displays ALM-4535 as a valid alarm, without generating an initial trigger flash. The display terminal returns confirmation after completing the snapshot application.

[0064] S4. The recovery control module calculates the incremental compensation window based on the snapshot, recovery request, and barrier. The snapshot compensation cursor is CUR-90005. The client's last confirmed cursor CUR-90000 is valid after server verification but is earlier than the snapshot compensation cursor. Therefore, the upper bound of the compensation window is taken from the snapshot compensation cursor CUR-90005 (left-open); the lower bound of the compensation window is taken from the latest server cursor CUR-90007 (right-closed) at the time of barrier establishment. Thus, the incremental compensation window is determined to be (CUR-90005, CUR-90007], covering the two patches missed between the snapshot formation and barrier establishment.

[0065] S5. The recovery control module queries the candidate incremental patches in the patch history storage module window and obtains two records: CUR-90006 (CH-02 counter status change, persistent state) and CUR-90007 (baggage passing animation, transient state). The candidate patches are sorted in ascending order by cursor and deduplication is performed; no duplicates are found. A gap detection is performed; cursors 90006 and 90007 increment consecutively, and the detection passes. If a gap is detected here (e.g., missing CUR-90006), compensation is stopped and a new snapshot is obtained (corresponding to the abnormal degradation in S10).

[0066] S6. The recovery control module performs recovery semantic filtering on the two candidate patches. CUR-90006 is a persistent patch, indicating that CH-02 changed from "idle" to "verifying." This state change occurred after the snapshot was taken (CH-02 was still "idle" in the snapshot), and it still affects the current final state, so it is retained as a compensation patch. CUR-90007 is a transient patch, expressing that the luggage animation has ended during the disconnection period and does not affect the final state, so it is not replayed. After filtering, the compensation patch set contains 1 record: CUR-90006.

[0067] S7. After the display client confirms that the snapshot application is complete, the recovery control module releases the compensation patch to the session according to the sorting result. The display client receives CUR-90006, updates the CH-02 counter status from "Idle" to "Verifying", and confirms that it belongs to the current recovery batch based on the recovery batch identifier "BATCH-20260604-143515-A3" carried by the patch. The display client does not generate a transition animation for this compensation patch, but only applies the final state change.

[0068] S8. After the compensation patch is released, the recovery control module performs a consistency check on the recovery results. The server calculates the expected digest: the number of devices is 11, the CH-02 status is "Verifying", the valid alarms are {ALM-4530, ALM-4535}, the statistics are "Passed Inspection: 1327 (i.e., the number of people who passed the inspection is 1327)", and the session alignment cursor is CUR-90007. The display terminal returns the local digest: the number of devices is 11, the valid alarms are consistent, the statistics are consistent, the last applied state patch cursor is CUR-90006, the session alignment cursor is CUR-90007 (where CUR-90007 is a transient patch, which has been skipped according to the recovery semantics and has not been actually applied), and the recovery batch is matched. The consistency check passes after comparison between the two parties. If the check fails (e.g., the number of devices on the display terminal is inconsistent), real-time access is suspended, and the display terminal is required to clear its local state and reapply the snapshot (corresponding to the abnormal degradation in step S10).

[0069] S9. After the consistency check passes, the recovery control module marks session SID-7891 as recovered and removes the recovery barrier. The recovery control module checks the relationship between the last compensation cursor CUR-90007 and the real-time patches in the temporary queue: CUR-90008 exists in the temporary queue (generated at 06:00:30), confirming cursor continuity. The recovery control module releases CUR-90008 from the temporary queue to the display session, and the session is then officially connected to the real-time patch stream; subsequent patches are directly pushed to DISP-A3.

[0070] During this recovery process, the abnormal degradation described in step S10 was not triggered. However, if the disconnection duration exceeds a preset threshold (e.g., the compensation window span exceeds 3600 seconds or the number of candidate patches exceeds 10,000), the recovery control module will abandon incremental compensation and instead require the display terminal to clear its local state and reapply a full snapshot recovery. If the device master data is missing, resulting in an incomplete set of devices in the snapshot, the recovery control module will put the display terminal into a safe display state: the scene structure remains visible, but the device running status is marked as "not synchronized," the alarm status is marked as "untrusted," and statistical values ​​are not displayed as synchronized data. At the same time, real-time patches are restricted from being continuously added.

[0071] This embodiment demonstrates the complete execution process of steps S1 to S10 of the recovery method in a specific scenario, including the generation of a recovery request triggered by reconnection at the display end, establishment of a recovery barrier and verification of snapshot acquisition, snapshot issuance and baseline reconstruction at the display end, compensation window calculation, candidate patch query and gap detection, recovery semantic filtering to distinguish between persistent and transient states, release of compensation patches in sequence, consistency verification, barrier removal and access to the real-time stream, and the handling of abnormal degradation. Specifically, the persistent patch (CH-02 state change) within the compensation window is retained and applied, while the transient patch (luggage animation) is filtered and not replayed, demonstrating the role of recovery semantic filtering in ensuring display consistency.

[0072] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0073] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for restoring consistency between security inspection twins based on state snapshots and incremental compensation, characterized in that, Includes the following steps: S1. The display module responds to the recovery trigger condition of the display session, generates a recovery request, and sends the recovery request to the recovery control module. The recovery trigger condition includes at least one of the following: page initialization, user refresh, communication connection disconnection and reconnection, display terminal shutdown and reopening, scene model reloading, and switching from real-time mode to or from playback mode back to real-time mode. S2. The recovery control module calls the digital twin engine module to obtain the final state snapshot of the target scene according to the recovery request, and establishes a recovery barrier on the display session. The recovery barrier is used to prevent real-time patches from being directly released to the display session before the final state snapshot application is completed and incremental compensation is completed. For real-time patches generated after the recovery barrier is established, the recovery control module writes them into the session temporary storage queue, or records their upper bound cursor and obtains them uniformly from the patch history storage module in the compensation query stage of step S5. S3. The recovery control module sends the final state snapshot to the display module's display terminal and requests the display terminal to return an application completion confirmation after completing the snapshot application. S4. The recovery control module calculates the incremental compensation window based on the final state snapshot, recovery request, and recovery barrier. The incremental compensation window adopts a left-open, right-closed boundary rule. The lower bound of the compensation window is determined based on the snapshot compensation cursor, snapshot state time, or snapshot state version. When the client's last confirmation cursor is valid after server verification and is later than the snapshot compensation cursor, the client's last confirmation cursor is used as the lower bound of the compensation window. The upper bound of the compensation window is determined based on the recovery barrier establishment time, compensation query time, the server's latest patch cursor, or the cursor at the end of the session temporary queue. S5. The recovery control module queries the candidate incremental patches located in the incremental compensation window from the patch history storage module, and performs sorting, deduplication, version verification and gap detection on the candidate incremental patches. S6. The recovery control module performs recovery semantic filtering on the candidate incremental patches that have been sorted, deduplicated, version verified, and gap detected to obtain a set of compensation patches. The recovery semantic filtering includes at least: retaining persistent patches and discarding transient patches, where persistent patches are patches that affect the current final state, and transient patches are patches used to express process animations or short-term prompts; in the recovery semantic filtering, persistent patches that have been covered by snapshots are not released again; for patches with multiple consecutive state changes for the same device or the same alarm object, they are merged into the last valid state according to the state version or message cursor; persistent patches that occur within the recovery window and still affect the current final state are retained as compensation patches; transient patches that have ended before disconnection, shutdown, or initialization are not replayed; S7. After confirming the final state snapshot application is completed on the display end, the recovery control module releases compensation patches to the display session according to the patch sorting result. S8. After the compensation patch is released, the recovery control module performs a consistency check on the recovery results displayed on the terminal. S9. When the consistency check passes, the display session will be marked as recovered, the recovery barrier will be removed, and the display session will be connected to the real-time patch stream. The recovery control module will release the patches in the temporary queue according to the continuity relationship between the last compensation cursor and the real-time patch cursor, or start pushing real-time patches from the latest cursor on the server side, thereby avoiding duplicate release or omission of patches. S10. If, during the recovery process, a patch history gap, snapshot version incompatibility, compensation window exceeding a preset threshold, missing device master data, application timeout, or consistency verification failure is detected, an abnormal degradation rule is executed.

2. The security inspection twin consistency recovery method based on state snapshot and incremental compensation as described in claim 1, characterized in that: In step S1, the recovery request includes at least the scene model identifier, session identifier, recovery type, last confirmed message identifier of the client, last confirmed message time or message cursor of the client, client protocol version, and client snapshot structure version.

3. The security inspection twin consistency recovery method based on state snapshot and incremental compensation as described in claim 2, characterized in that: In step S2, after obtaining the final state snapshot of the target scene, the recovery control module verifies the structure version, scene model identifier, snapshot summary, and basic master data mapping relationship of the final state snapshot. If the snapshot structure version is incompatible with the display end protocol version, or if the snapshot lacks the scene structure, device set, or basic mapping relationship required by the display end, the release of the patch is stopped and the operation of re-acquiring the snapshot or security display processing is initiated.

4. The security inspection twin consistency recovery method based on state snapshot and incremental compensation as described in claim 1, characterized in that: In step S7, during the release of compensation patches, the display terminal only applies the compensation patches to state changes after the snapshot, and rejects expired patches, duplicate patches, or patches that do not belong to the current recovery batch based on the state version, entity identifier, and recovery batch identifier carried by the compensation patch. If a timeout, application failure, or version conflict is returned by the display terminal during the compensation process, the recovery control module suspends the release of subsequent patches and performs a new snapshot or security display process.

5. The security inspection twin consistency recovery method based on state snapshot and incremental compensation as described in claim 1, characterized in that: In step S8, the consistency verification includes at least one of device set verification, valid alarm set verification, statistical summary verification, status summary verification, patch cursor continuity verification, recovery batch verification, snapshot structure version verification, and master data mapping verification. The verification method is that the server calculates the expected summary based on the snapshot and patch and compares it with the summary returned by the display end, or the display end returns the last applied cursor, device set summary, alarm set summary, and statistical summary, and the server performs the verification.

6. The security inspection twin consistency recovery method based on state snapshot and incremental compensation as described in claim 1, characterized in that: In step S10, the abnormal degradation rules include one or more of the following: reacquiring the final state snapshot, abandoning incremental compensation and using full snapshot recovery instead, requiring the display terminal to clear the local session state and then reapply the snapshot, and entering the secure display state. In the secure display state, the display terminal keeps the scene structure visible, but does not mark the device running status, alarm status, or statistical values ​​as synchronized.

7. A security inspection twin consistency recovery system based on state snapshots and incremental compensation, used to execute the recovery method of any one of claims 1-6, characterized in that, include: The data access module is used to receive security inspection business events in real time and convert these events into standardized events with a unified format. The digital twin engine module is used to generate final state, final state snapshot, and incremental patches based on standard events; The patch history storage module is used to save patch events with time, cursor, version, and semantic category. The recovery control module is used to identify recovery requests, establish recovery barriers, calculate compensation windows, and query and release compensation patches. The display module is used to apply final state snapshots and compensation patches to create a consistent display of 3D scenes, 2D monitoring dashboards, effective alarms, and statistical status on the display terminal.

Images