An intelligent management system for the whole life cycle of an exhibition hall project

Abstract

The present application relates to the technical field of automatic control and industrial control system, and particularly relates to a full life cycle intelligent management system for exhibition hall project, which comprises a project modeling subsystem, a device access and control gateway, a digital twin engine, a time sequence data management module, a rule and scheduling engine, a process engine, a communication interface adapter, a safety isolation unit and a visual monitoring terminal; a scheme to archiving stage model is established; a programmable logic controller (PLC), a distributed I / O, a sensor and an actuator are accessed; after being simulated and checked by the digital twin engine, the rule and scheduling engine generates program control instructions and interlocking instructions for issuing; the present application converges time sequence data by mapping stage models and digital twins to field points; strategies are simulated and checked and approved, and are issued to the device gateway under the control of the communication interface and the safety isolation, and are verified and traced back on the visual terminal, so that a unified time / version semantic release rollback is formed to solve the model-control-data fragmentation and high risk.

Description

Technical Field

[0001] This invention relates to the field of automatic control and industrial control system technology, and in particular to an intelligent management system for the entire life cycle of an exhibition hall project. Background Technology

[0002] In existing technologies, the toolchains, data definitions, and coding systems used at each stage are fragmented: the scheme and design stage focuses on BIM and schedule / cost, the construction and commissioning stage focuses on location tables and interlocking tables, and the operation stage emphasizes alarms, energy consumption, and equipment maintenance. Due to the lack of unified resource identifiers and version semantics throughout the entire lifecycle, there is often no stable one-to-one correspondence between equipment / control points in the design model and field I / O and PLC variables. This leads to repeated manual table matching and definition conversion in subsequent commissioning and maintenance stages, which is inefficient and prone to errors.

[0003] On the other hand, the equipment on-site in the exhibition hall is diverse, and common industrial communication protocols include, but are not limited to, OPC UA, BACnet / IP, and Modbus / TCP. Different manufacturers and subsystems exhibit significant differences in address domains, data types, and timing characteristics. Existing integration methods are mostly "point-to-point" or "gateway splicing," lacking a unified time base and session order constraints, resulting in out-of-order and delayed cross-system data. Furthermore, the lack of a clear version binding relationship between the data acquisition side and the policy distribution side makes it difficult to trace historical data back to a specific version of the control policy, directly impacting problem localization and responsibility determination.

[0004] During debugging and operation, the release of strategies or parameters often relies on engineers' experience, lacking simulation verification and shadow playback mechanisms based on digital models. Current practices mostly involve direct online rewriting or limited offline simulation, making it difficult to assess potential loop conflicts, interlocking, and stability risks under extreme conditions before release. If a release fails, manual rollback or a full system reset is often required, resulting in high downtime and rework costs.

[0005] Regarding security boundaries, common practices between information networks and control networks are either loose isolation (impacting security) or strong isolation but lacking controlled access paths (impacting efficiency). Without signature approval, version verification, and two-phase transactions, cross-domain control commands are at risk of being tampered with, reused, or having an uncertain order. Furthermore, on the audit side, the lack of an append-only, version-indexed record structure makes post-event tracing difficult to achieve precise location down to the "specific moment, specific version, specific batch" level.

[0006] At the visualization level, existing monitoring terminals mostly focus on displaying real-time curves and alarm lists, lacking linkage with digital models, version lists, and process approvals. The human-machine interface for policy release is often separated from the visualization interface, making it impossible to complete the "verification-signature-release-audit" closed loop on the same interface, resulting in high collaboration costs across systems and roles in the operation and maintenance process.

[0007] In terms of asset and exhibit management, the ledger system is usually independent of the control system and digital model. The comparison between RFID / location data and model elements often relies on manual summarization and registration. When there are renovations or changes to the exhibition layout, the updates to asset locations and binding relationships are delayed. Before the strategy is released, the consistency verification of "asset / exhibit - model element - control point" cannot be completed automatically, which brings uncertainty to operational security and exhibition effects.

[0008] In summary, the main problems with existing technologies are: a lack of unified identification and version semantics for cross-stage data / models and field control points; a lack of unified time and sequence constraints for cross-protocol interoperability; a lack of simulation and shadow verification for policy release; a lack of controlled release and auditable mechanisms between the information domain and the control domain; a disconnect between visualization and process approval and version verification; and difficulty in synchronizing asset and exhibit ledger updates with models and control points. These problems collectively lead to long debugging cycles, high operational risks, difficulties in backtracking, and high overall lifecycle costs. Summary of the Invention

[0009] To overcome the aforementioned technical deficiencies, the present invention aims to provide an intelligent management system for the entire lifecycle of exhibition hall projects. By establishing a phased model that runs through the scheme and archive stages and mapping it one-to-one with the "digital twin - on-site control point", the system aggregates time-series data. After verification by the rule and scheduling engine in digital twin simulation, the system generates strategies, which are then approved through processes, and controlled by communication interface adapters and security isolation units before being distributed to the device access and control gateway (PLC / interlock). The system performs closed-loop verification and traceability at the visual monitoring terminal, thereby achieving consistent release and rollback across stages and systems with unified time / version semantics. This solves the problems of model-control-data fragmentation and high release risk throughout the entire lifecycle.

[0010] This invention discloses an intelligent management system for the entire lifecycle of exhibition hall projects, comprising:

[0011] The project modeling subsystem is used to create phase models of the exhibition hall project. The phase models include the scheme phase, design phase, construction phase, commissioning phase, operation phase, renovation phase, and archiving phase.

[0012] The equipment access and control gateway is used to connect programmable logic controllers (PLCs), distributed I / O, sensors, and actuators in the exhibition hall to the system.

[0013] A digital twin engine is used to maintain digital models of exhibition space and equipment and establish a one-to-one mapping relationship with on-site control points;

[0014] The time-series data management module is used to collect and store data from the device access and control gateway, including process quantities, status quantities, and event quantities.

[0015] The rules and scheduling engine is used to generate control and scheduling instructions based on the phase model, digital twin engine and time series data management module, and send them to the device access and control gateway.

[0016] The process engine is used to manage the tasks, inspections and acceptance records generated during construction, commissioning and operation and maintenance in a process-oriented manner, and to establish version association with the policy packages generated by the rules and scheduling engine.

[0017] A communication interface adapter for providing at least one of the following industrial communication methods: OPC UA, BACnet / IP, and Modbus / TCP, between the device access and control gateway and the digital twin engine;

[0018] A security isolation unit is used to provide one-way or two-way access control and auditing between an information network and a control network;

[0019] The visual monitoring terminal is used to display the model view of the digital twin engine and the real-time and historical data of the time series data management module, and provides control over the loading and publishing of rules and scheduling engine strategies.

[0020] The rules and scheduling engine is configured to generate program control instructions for the PLC and interlocking instructions for the actuators after verification through the simulation channel of the digital twin engine.

[0021] Preferably, the project modeling subsystem includes a unified resource identification coding module. The unified resource identification coding consists of a project identification segment, a stage code segment, an equipment class code segment, and a control point sequence number segment. The unified resource identification coding is fixed in the process engine as a stage code segment and a strategy package version number. The rule and scheduling engine parses the unified resource identification coding when generating a strategy package to determine the list of control points in the strategy package.

[0022] Preferably, the digital twin engine includes a model-control point mapping table. The mapping table records the one-to-one correspondence between model element identifiers, field I / O address fields, PLC variable names and control channel numbers. When the strategy is released, the communication interface adapter performs type checks, address field out-of-bounds checks and mutual exclusion checks based on the mapping table, and generates a consistency verification record corresponding to the strategy package version number.

[0023] Preferably, the rules and scheduling engine includes a policy template library and a scheduling plan library. The templates in the policy template library are indexed by working condition tags and equipment types, and the plans in the scheduling plan library are indexed by stage codes and policy package version numbers. When the rules and scheduling engine receives a stage switching trigger from the process engine, it selects a scheduling plan according to the stage code and combines it with the policy template in a parameterized manner to generate a policy package carrying a version list and a list summary.

[0024] Preferably, the device access and control gateway includes an edge computing unit. The edge computing unit has a shadow running area and a main running area. After receiving a policy package with a stage code and a policy package version number, the edge computing unit performs playback execution of the policy package based on sampled I / O data in the shadow running area, and performs matching and verification with the simulation verification summary of the digital twin engine. After the matching is successful, the policy package is migrated to the main running area for execution.

[0025] Preferably, the communication interface adapter includes a southbound protocol bridge and a northbound data adapter. The southbound protocol bridge adds a unified time base and sequence number mark to OPC UA, BACnet / IP or Modbus / TCP sessions. The northbound data adapter connects to the project management system, BIM data source and document management system via REST or MQTT and parses external model identifiers. During the policy release process, the communication interface adapter establishes a mapping between the external model identifier and the model element identifier in the digital twin engine, and completes the policy release transaction with the edge computing unit in a two-phase commit manner.

[0026] Preferably, the time-series data management module adopts an append-only storage structure and performs database sharding and table partitioning for process quantities, state quantities, and event quantities. The append-only storage structure organizes segment files based on the log structure merge tree (LSM Tree). The writing order is determined by a combination key of stage code, timestamp, and unified resource identifier code. The time-series data management module generates a segment summary index corresponding to the policy package version number for each written segment.

[0027] Preferably, it also includes an asset and exhibit ledger module. When the process engine generates a stage switching event, the asset and exhibit ledger module calls a radio frequency identification (RFID) reader to collect asset identification and location information, compares the collected asset identification with the model element identification in the digital twin engine, and writes the comparison result into the model snapshot corresponding to the stage code in the form of model attachment attributes.

[0028] Preferably, the process engine includes a policy approval submodule, which signs and verifies the policy package generated by the rules and scheduling engine. The signing and verification results serve as one of the triggering conditions for the rules and scheduling engine to issue control commands.

[0029] Preferably, before executing a control command release or rollback operation, the visual monitoring terminal reads the segment summary index corresponding to the target version number from the time series data management module and performs a consistency comparison with the strategy package signature summary recorded by the process engine; after the comparison is successful, the control command release control is enabled on the large screen terminal, and the stage code and strategy package version number associated with the release operation are recorded on the mobile terminal; wherein, the target version number is the aforementioned strategy package version number.

[0030] Compared with existing technologies, the above technical solution has the following advantages:

[0031] 1. Unified Semantics and Identification Across Stages. Existing technologies use fragmented methods such as BIM, location tables, and maintenance ledgers for the scheme / design / construction / operation stages, lacking unified resource identification and version semantics. This leads to difficulties in consistently matching model elements with on-site control points, frequent manual table reconciliation during stage transitions, and high rates of mismatches and omissions. This invention introduces a unified resource identification code (including project identification segment, stage code segment, equipment class code segment, and control point sequence number segment) into the project modeling subsystem and embeds it into the version in the process engine. The rules and scheduling engine parses this code to determine the control point list when generating strategy packages, achieving unified semantics across model, control, stage, and version. This automates stage transitions and table reconciliation, significantly reducing manual table reconciliation costs and mismatch rates.

[0032] 2. Model-Control Point Mapping and Type / Address Verification. In existing technologies, PLC variable names, field I / O addresses, and BIM / model elements lack standardized mapping, relying on manual table maintenance. This leads to potential problems such as type mismatches, address out-of-bounds errors, and mutual exclusion during deployment and upgrades. This invention uses a digital twin engine to maintain the model-control point mapping table (including model element identifiers, I / O address fields, PLC variable names, and control channel numbers). The communication interface adapter performs type checks, address field out-of-bounds checks, and mutual exclusion checks during policy deployment, generating consistency verification records. This eliminates low-level errors and resource conflicts before deployment, reducing the risk of interlocking mis-triggering and loop conflicts.

[0033] 3. A three-tiered deployment threshold of simulation pre-verification + shadow playback. Existing technologies often rely on manual experience and limited offline simulation for policy deployment. Failure to deploy and subsequent rollback are costly, and there are issues such as the inability to capture extreme operating conditions and interlocking conflicts before deployment, leading to high risks of online trial and error. This invention generates policy packages through a rule and scheduling engine based on a three-tiered threshold of "simulation pre-verification → shadow playback → consistency determination." Device access and control gateways replay the policy in the shadow runtime area, and only after successful replay can it be migrated to the main runtime area. This shifts uncertainty forward to the simulation and shadow environments, significantly improving the first-time deployment success rate and reducing downtime and rework.

[0034] 4. Two-phase commit and version consistency gating. Existing technologies involve direct writing across network segments or weak verification during deployment, lacking transaction guarantees and version binding. This results in problems such as uncertain deployment order, cross-version mixed writing, and difficulty in recovery after failure. In this invention, a two-phase commit is employed through collaboration between a communication interface adapter and a security isolation unit; before deployment, version consistency is determined based on the segment digest index of the time-series data management module. Only after approval is granted that "only consistent versions are released and rollback is possible in case of failure", thus reducing abnormal switching and data pollution.

[0035] 5. Consistency of time / sequence between unified time base and session sequence number. In existing technologies, the mixing of multiple protocols and devices leads to frequent clock drift and out-of-order issues, resulting in difficulties in simulation / playback alignment and a lack of reliable timelines for incident reconnaissance. This invention addresses this by establishing a unified time anchor for southbound sessions (…). Threshold control), each frame / batch carries a session sequence number and a millisecond-level timestamp; automatic frequency reduction and resynchronization when the threshold is exceeded to ensure the consistency of time / sequence of collection and publication, and support precise alignment, playback and audit traceability.

[0036] 6. Append-only time-series data foundation and hierarchical index. Existing technologies often use databases that mix process, state, and event data, resulting in significant write amplification and query jitter. This leads to problems such as unstable writes under high-frequency data acquisition, slow long-cycle retrieval, and difficulty in version tracing. In this invention, the time-series data management module employs an LSM append-only structure, database sharding, segment summary indexes, and composite keys. (Uniform identifier, version, timestamp) sorted writing; maintains three types of indexes: time range, inverted index, and segment summary, maintains stable writing under high throughput, has low retrieval latency, fast version tracing, and significantly reduces long-term storage costs.

[0037] 7. Visualized Verification – Signature – Release: A Closed-Loop Human-Machine Process. Existing technologies separate the monitoring interface from approval and version verification, with the release process involving cross-system jumps. This results in a break in the human-machine interaction, high risks of misoperation and missed reviews, and difficulties in linking audits. The visualized monitoring terminal in this invention provides an integrated operation of "consistency comparison → signature verification → enabling release controls"; large-screen display + movement tracking, binding actions with stage codes and version numbers, achieving visible verification and traceable signatures, minimizing release risks, and allowing for one-click replay afterwards.

[0038] 8. Cross-protocol adaptation and external model identifier binding. In existing technologies, protocols such as OPC UA, BACnet / IP, and Modbus / TCP coexist in silos, and BIM / project management / document system identifiers are incompatible, leading to high integration and maintenance costs due to protocol fragmentation and inconsistent identifiers. The communication interface adapter in this invention provides a southbound protocol bridge and a northbound data adapter, uniformly attaching time anchors and sequences; during the publishing process, an external model identifier ↔ digital twin model element mapping is established and versioned, achieving one-time mapping and full reuse across protocols and systems, reducing redundant configuration and lowering transformation costs.

[0039] 9. Controlled Release and Non-Repudiation Auditing for Secure Isolation. Existing technologies either employ weak isolation, which presents security vulnerabilities, or strong isolation, which lacks a controlled release path. This leads to issues such as cross-domain distribution potentially being tampered with / reused, and difficulties in achieving precise version-level traceability during auditing. This invention addresses these issues by using a one-way gateway + two-way application proxy; triple authorization via certificate + token + role; content decomposition / repackaging; and appending auditing to all cross-domain message writes and indexing them by time / version. This achieves controllable, verifiable, and traceable cross-domain publishing and rollback while ensuring security.

[0040] 10. Asset and exhibit tagging / location binding with model snapshots. In existing technologies, the ledger and control / model system are separated, and location binding relies on manual registration. This results in delays in exhibition changes and the inability to automatically verify the consistency of "asset-model-control point" before release. In this invention, the asset and exhibit ledger module triggers RFID / location data collection during stage switching, compares it with digital twin model elements, and writes it to the corresponding stage snapshot with attachment attributes, synchronously writing version associations. This achieves automatic asset / exhibit consistency verification before release, reducing strategy failures and risks caused by physical misalignment.

[0041] 11. Reproducible Release Quality of Parameterization and Multi-Objective Optimization. In existing technologies, strategy parameters mainly rely on experience and manual tuning, which is difficult to reproduce and suffers from significant variations in parameter tuning among different engineers / time periods, making it difficult to balance stability and energy efficiency. This invention solves for parameters using a rule and scheduling engine in the form of an objective function plus constraints, supporting multi-scenario template aggregation and weight rolling updates. The parameter and version list are fixed in the strategy package, achieving reproducible optimal / suboptimal parameters and achieving a transparent trade-off between comfort, energy consumption, and stability, facilitating continuous optimization.

[0042] 12. Two-level rollback (version rollback / sub-package rollback) shortens recovery time. In existing technologies, failures often require a full package rollback or even a system reset, which results in slow recovery and a wide impact. This invention supports version rollback and fine-grained sub-package rollback (dependency graph constraints), also following a two-phase commit, thereby achieving clear fault location, controllable rollback granularity, significantly shortened recovery time, and limiting the impact to a minimum set.

[0043] 13. End-to-End Auditing and Precise Traceability. In existing technologies, audit logs are scattered across multiple systems with inconsistent dimensions, making it difficult to reconstruct the event from a specific point in time, version, or batch. This invention integrates policy package version numbers, segment summary indexes, session sequence numbers, and millisecond-level timestamps throughout rule generation, verification, release, rollback, and visualization terminal operations, and writes these data into append-only audits, thereby supporting precise version-level / batch-level replays and responsibility boundary delineation.

[0044] 14. Overall Performance and Cost Benefits. In existing technologies, high-frequency data acquisition combined with mixed storage leads to write jitter and storage bloat; dispersed release verification results in uncontrollable latency, making it difficult to simultaneously guarantee real-time performance and long-term cost savings. In this invention, LSM only adds append-only write operations, segment merging strategies, and columnar / differential compression; consistency verification and two-phase commit are closed-loop within the release chain, thus exhibiting stable writes, low query latency, and a high compression ratio in representative samples, while keeping the "verification-release" latency within an acceptable engineering range, resulting in a better total cost of ownership.

[0045] 15. In existing technologies, individual tools operate independently, making it difficult to flexibly scale to multiple exhibition areas / venues. They suffer from significant bottlenecks and congestion during peak periods, resulting in high migration and reuse costs. In this invention, each module supports both individual and distributed dual-mode deployment, and the critical paths (simulation pre-verification, shadow playback, and release coordination) can be horizontally scaled. Communication interface adapters and security isolation units support cross-site cascading, maintaining availability and real-time performance under scale expansion and business fluctuations, while reducing reuse and expansion costs.

[0046] In summary, compared with existing technologies, this invention systematically eliminates the fragmentation across stages, systems, and protocols through collaborative technical approaches such as "unified identification and version semantics, model-control mapping, simulation + shadow verification, two-phase commit and consistency gating, unified time / sequence, append-only indexing of time-series data, visual verification closed loop, secure isolation and controlled release, and asset / exhibit binding with model snapshots." This significantly reduces deployment and maintenance risks, improves debugging efficiency and traceability, and brings long-term storage and maintenance cost advantages. Attached Figure Description

[0047] Figure 1This is a flowchart illustrating the intelligent management system for the entire lifecycle of an exhibition hall project according to the present invention.

[0048] Figure 2 A schematic diagram of the cumulative distribution of end-to-end delay in the control path (normal load and peak load).

[0049] Figure 3 This is a schematic diagram illustrating how the time synchronization deviation changes over time.

[0050] Figure 4 This diagram illustrates the write throughput curves and the impact of segment rolling under the append-only / segment rolling mechanism.

[0051] Figure 5 A schematic diagram of the instruction rate alignment curve between the shadow runtime playback and the simulation baseline;

[0052] Figure 6 A schematic diagram illustrating the relationship between consistency verification time and batch size;

[0053] Figure 7 This is a schematic diagram showing the cumulative distribution of positioning errors under three positioning modes;

[0054] Figure 8 A diagram illustrating the change in the number of alarm entries within a unit time window before and after alarm compression;

[0055] Figure 9 This is a diagram illustrating the changes in storage compression ratio over multiple days.

[0056] Figure 10 A diagram showing the comparison of policy switching completion time before and after enabling consistency gating;

[0057] Figure 11 This diagram illustrates the convergence curve of the objective function during the iterative optimization of strategy parameters. Detailed Implementation

[0058] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.

[0059] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0060] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0061] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0062] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0063] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0064] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.

[0065] See Figure 1As shown in this embodiment, an intelligent management system for the entire lifecycle of an exhibition hall project is provided, including: a project modeling subsystem for establishing a phase model of the exhibition hall project, which includes the scheme phase, design phase, construction phase, commissioning phase, operation phase, renovation phase, and archiving phase; an equipment access and control gateway for connecting programmable logic controllers (PLCs), distributed I / O, sensors, and actuators in the exhibition hall to the system; a digital twin engine for maintaining digital models of the exhibition hall space and equipment and establishing a one-to-one mapping relationship with on-site control points; a time-series data management module for collecting and storing data from the equipment access and control gateway, including process quantities, state quantities, and event quantities; a rules and scheduling engine for generating control commands and scheduling commands based on the phase model, digital twin engine, and time-series data management module, and distributing them to the equipment access and control gateway; a process engine for managing the tasks, inspections, and acceptance records generated during construction, commissioning, and operation and establishing a version association with the strategy packages generated by the rules and scheduling engine; and a communication interface adapter for providing OPC between the equipment access and control gateway and the digital twin engine. The system includes at least one industrial communication method selected from UA, BACnet / IP, and Modbus / TCP; a security isolation unit for providing one-way or two-way access control and auditing between the information network and the control network; and a visualization monitoring terminal for displaying the model view of the digital twin engine and the real-time and historical data of the time-series data management module, and providing policy loading and publishing control for the rules and scheduling engine. The rules and scheduling engine is configured to generate program control instructions for the PLC and interlocking instructions for the actuator after verification through the simulation channel of the digital twin engine.

[0066] This embodiment will describe the project modeling subsystem in detail. The project modeling subsystem is used to establish a phase model of the exhibition hall project. The phase model includes the scheme phase, design phase, construction phase, commissioning phase, operation phase, renovation phase, and archiving phase. During system initialization, the project modeling subsystem creates a phase dictionary. The phase dictionary records the phase identifier, phase start and end conditions, available working condition set within the phase, binding scope with the digital twin engine, strategy template set with the rule and scheduling engine, and process template set with the process engine for each phase. The project modeling subsystem uses a unified resource identifier (URI) coding module for unified object naming. The URI coding consists of a project identifier segment, a phase code segment, an equipment class code segment, and a control point sequence number segment. In one embodiment, the project identifier segment uses an 8-character hexadecimal string, the phase code segment uses a 2-character hexadecimal string, the equipment class code segment uses a 2-character hexadecimal string, and the control point sequence number segment uses a 4-character decimal string. When writing the phase model, the project modeling subsystem calls the process engine to register the strategy package version number and generates a segment summary index corresponding to that version number in the time series data management module. This index is used for data backtracking and version consistency comparison between the debugging and runtime phases. To avoid ambiguity between different technical names, this paper only introduces identifiers in the expressions and qualifies them one by one: the phase code segment is denoted as... The strategy package version number is recorded as The Uniform Resource Identifier (UNI) is denoted as: The segment summary index is denoted as The hash key of the model-control point mapping table is denoted as The stage switching trigger function is denoted as The simulation verification summary is recorded as follows: The consistency determination function is denoted as .

[0067] The modeling process of the project modeling subsystem includes four steps: data acquisition, semantic constraint generation, model instantiation, and consistency verification. The data acquisition step obtains statistical characteristics of process quantities, state quantities, and event quantities from the device access and control gateway, and reads the current stage's process template and approval status from the process engine. The semantic constraint generation step forms a constraint set within the stage, including a list of required devices, permissible operating conditions, and essential mapping items to the digital twin engine. The model instantiation step writes the unified resource identifier code into the model element attribute table of the digital twin engine and forms a draft of the model-control point mapping table. The consistency verification step is triggered by the communication interface adapter at the time of policy release, performing type checks, address field out-of-bounds checks, and mutual exclusion checks, generating a consistency verification record corresponding to the policy package version number. Based on a sample containing 10 exhibits, 32 control loops, and 196 monitoring points, 20 repeated deployments were statistically analyzed. Without generating consistency verification records, the average loop conflict rate was 2.91%; after introducing consistency verification records, the average loop conflict rate was 0.34%, and the misconfiguration recovery time was reduced from an average of 27 minutes to an average of 6 minutes.

[0068] The project modeling subsystem handles the scheme phase by establishing an initial set of exhibition themes, core exhibits, and key equipment, generating phase code segments for the scheme phase, and restricting the rules and scheduling engine to only load the policy template set for the scheme phase. The operational condition set for the scheme phase is limited to static lighting environment and basic safety monitoring conditions, prohibiting the issuance of interlocking policies. The scheme phase and digital twin engine only establish models at the spatial geometry and equipment type levels, without establishing on-site control point bindings; simultaneously, unified resource identifier coding is required to complete object-level registration to form a minimum usable code set. In one implementation, the scheme phase... =“01”, policy package version number Setting it to 0 indicates that it cannot be published.

[0069] The project modeling subsystem handles the design phase by introducing parameters for electrical, lighting, acoustic, and multimedia equipment, and filling the reserved areas for field input / output addresses and variable names in the model-control point mapping table. The design phase allows for the creation of equipment behavior models in the digital twin engine for subsequent simulation verification. =“02”, the rules and scheduling engine can generate a simulation-only policy package version number. ≥1. Static and dynamic simulations were performed using a 1:1 lighting circuit model. Static simulations compared the deviation distribution between the target illuminance and the calculated illuminance, while dynamic simulations compared the integral absolute error between the step response and the desired response. After introducing model-control point mapping table constraints, the 95th percentile of the static deviation decreased by 38%, and the dynamic integral absolute error decreased by 41%.

[0070] The project modeling subsystem handles the construction phase by converting the model-control point mapping table from a reserved state to a bound state, requiring each model element to have a unique unified resource identifier code and register it in the time-series data management module. (Construction phase...) =“03”, after the process engine approves, the policy package is allowed to enter the shadow execution area for replay execution; at the same time, the network topology is solidified, and the southbound protocol type and target device address of each control loop are recorded. Based on the comparison sample, after completing the network topology solidification and binding the unified resource identifier code, the connectivity fault location time during the debugging phase was reduced from an average of 3 hours to an average of 45 minutes.

[0071] The project modeling subsystem handles the debugging phase by enabling shadow runtime execution strategy package replay and comparing it with the simulation verification summary generated by the digital twin engine. Perform a consistency check. (During the debugging phase) =“04”, the strategy package version number is generated by the process engine. The project modeling subsystem creates an append-only storage segment in the time series data management module and writes it with a combination key of stage code segment, timestamp and unified resource identifier code to form a segment digest index. In the 50-hour integrated debugging experiment, 5 different sets of strategy templates were used, and the shadow running area and simulation verification digest were used. The consistency comparison pass rate is 100%, and the deviation of the number of instructions counted in 1-hour intervals is less than 0.1%.

[0072] The project modeling subsystem handles the runtime phase by migrating the strategy package to the main runtime area. =“05”. During the runtime phase, the interface with the process engine is activated, triggering a strategy template set switch during planned maintenance, exhibit switching, and changes in peak visitor flow. Each strategy switch generates a new segment summary index in the time-series data management module and performs a consistency comparison with the signature summary registered by the process engine. Based on a sample of 15 days and 12 time periods per day, no unauthorized strategy changes occurred, and the average strategy switch time decreased from 80 seconds to 38 seconds.

[0073] The project modeling subsystem handles the transformation phase by copying the existing version's model elements as a read-only snapshot and then updating them with the new snapshot. =“06” Create a difference list. The difference list records the unified resource identifier codes of newly added equipment, decommissioned equipment, and configuration changes, as well as their associated model-control point mapping items. The project modeling subsystem automatically generates shadow running area playback scripts for local verification based on this. In three scenario tests involving exhibit migration, lighting replacement, and audio-visual matrix expansion, when the playback script coverage driven by the difference list reaches 95% or more, the abnormal alarm rate after migration to the main running area is less than 1.2%.

[0074] The project modeling subsystem handles the archiving phase by freezing the current phase model and writing it. =“07”, binds the strategy package version number and segment summary index to be immutable, saves the final versions of the digital twin engine's model snapshot, model-control point mapping table, strategy template set, and scheduling plan set, and aggregates the process engine approval records and the release operation records of the visualization monitoring terminal. Based on a 250-day running sample comparison, projects with an archiving phase have an average 57% shorter modeling time when reconnected compared to projects without an archiving phase.

[0075] To improve verifiability and maintainability, the project modeling subsystem provides three reproducible formal definitions. First, the state machine for stage transition triggering is expressed as a function. ,in Indicates the stage switching trigger function, This represents the vector of the current stage. This represents the next stage vector, and the function's value is constrained by the stage dictionary. Secondly, the hash digest function of the Uniform Resource Identifier (URI) is defined as... ,in For the selected hash algorithm, "" indicates concatenation; the summary is used as the index key for generating the model-control point mapping table. Third, the consistency determination function between the segment summary index and the policy package version number is defined as follows: The value is 1 if and only if the segment summary index and the policy package version number match in the consistency comparison of the visualization monitoring terminal; otherwise, it is 0.

[0076] The interface conventions between the project modeling subsystem and the digital twin engine, rule and scheduling engine, process engine, and time-series data management module are as follows: The subsystem provides the digital twin engine with a structured description of the stage model and a unified resource identifier encoding mapping, and receives simulation verification summaries. Provide the rule and scheduling engine with the current state of the stage state machine, stage dictionary entries, and an index of the available policy template set, and receive the policy package and policy package version number. Provide the process engine with stage transition events, stage snapshots, and policy package summaries that require signing, and receive signature summaries and approval status; provide the policy package version number to the time series data management module. Write batch information and receive segment digest index. The system provides a draft model-control point mapping table to the communication interface adapter and receives the consistency verification results and verification record numbers. Each interface uses a structured message body, and the time field uniformly uses Coordinated Universal Time (UTC) with a millisecond-level timestamp to ensure sequential consistency.

[0077] Regarding anomalies and boundary conditions, the project modeling subsystem specifies four categories of scenarios and their handling principles. The first category is the scenario of inconsistent signatures and versions, which occurs when the visual monitoring terminal initiates a release... When the release process is rejected, the stage state machine executor maintains the current stage unchanged, while writing the rejection event to the timing data management module and generating a new segment summary index for review. The second type is the model-control point mapping conflict scenario. When the communication interface adapter detects mutual exclusion or address field out of bounds at the release time, the model instantiator rolls back to the most recent stage snapshot that passed consistency verification, and revokes the approval status of the current policy package on the process engine side. The third type is the shadow runtime replay and simulation verification summary. In the case of mismatch, when matching fails, the strategy package is not migrated to the main runtime area. The project modeling subsystem records the failed input / output sequence and generates a review checklist. The fourth category is the case of insufficient phase switching conditions. When the input does not meet the entry conditions in the stage dictionary, the stage state machine executor refuses the transition and records the unmet external dependencies in the model-external identifier mapping table for localization.

[0078] In one embodiment, two baseline scenarios were constructed. The medium-sized scenario included 10 exhibits, 32 control loops, 196 monitoring points, and one programmable logic controller (PLC), with 20 deployment cycles executed. Without consistency verification records, the average loop conflict rate was 2.91%, decreasing to 0.34% after introducing consistency verification records, and the misconfiguration recovery time was reduced from an average of 27 minutes to an average of 6 minutes. The larger load scenario covered 15 days of continuous operation, with each day divided into 12 time slots, resulting in 180 policy switches, all completed during the runtime phase. All consistency comparisons passed, and the average policy switch time decreased from 80 seconds to 38 seconds, with no unauthorized policy changes occurring. For the debugging phase, 50 hours of comprehensive debugging were performed using 5 different policy template sets, shadow runtime areas, and simulation verification summaries. The consistency comparison pass rate is 100%, and the deviation in the number of instructions counted over a 1-hour interval is less than 0.1%.

[0079] It should be noted that, in some embodiments, the project modeling subsystem further includes: the first extension is to introduce an auxiliary check bit on the basis of the Uniform Resource Identifier (URI), so that the hash key calculation is based on... Expand to ,in The first is a single-byte cyclic parity bit used to detect the risk of bit flipping in the Uniform Resource Identifier (URI) code during transmission. The second extension introduces a time window constraint into the staged state machine. The effective domain is limited to a specified time window to avoid unwanted phase switching between peak passenger flow and nighttime maintenance. The third extension is a simulation verification summary. Multi-scene synthesis enables simulation verification of summaries The composite value is expanded from a single-scenario summary to a multi-scenario summary. The synthesis process weights and aggregates the verification indicators of multiple representative working conditions, and outputs a fixed-length summary for consistency comparison before release.

[0080] In terms of deployment and operation, the project modeling subsystem can operate in both monolithic and distributed modes. In monolithic mode, all components are loaded as modules within the same process, suitable for small to medium-sized exhibition halls. In distributed mode, the stage dictionary manager, model instantiator, and consistency check coordinator can run on independent nodes, communicating with other modules via message queues. Stage transitions and release comparisons are completed within 1 second, segment summary index calculations are completed between 100 and 300 milliseconds, and the digital twin engine generates simulation verification summaries. In common scenarios, the time interval is given within the range of 1 to 5 seconds. To ensure timing consistency, the system adopts a unified time base and adds a sequence number to the southbound session layer. The sequence number is implemented as a 32-bit unsigned integer and is reset after reconnection.

[0081] In summary, the project modeling subsystem utilizes a phase dictionary, unified resource identifier coding, model-control point mapping table, strategy package version number, segment summary index, and simulation verification summary. Core data objects, such as the solution phase, design phase, construction phase, commissioning phase, operation phase, renovation phase and archiving phase, are linked into a complete chain that can be modeled, verified, published and collected.

[0082] This embodiment will describe the device access and control gateway in detail. The device access and control gateway is used to establish a deterministic data acquisition, control, and transaction publishing channel between the control domain and information domain of the exhibition hall project, and to ensure semantic, temporal, and version consistency between field devices and upper-level modules. The device access and control gateway undertakes three types of responsibilities in the system: first, it completes southbound access and control of programmable logic controllers, distributed I / O, sensors, and actuators; second, it supports the partitioned execution of the shadow running area and the main running area; third, it provides verifiable data and control interfaces to the digital twin engine, rule and scheduling engine, process engine, and time-series data management module. The device access and control gateway is denoted as... Southbound Protocol Bridge Northbound data adapter is denoted as Edge computing units are denoted as The shadow running area is recorded as The main operating area is recorded as The session sequence number is recorded as A unified time base is denoted as The cache queue is denoted as The log structure only appends buffered records. End-to-end delay is recorded as Packet loss rate is denoted as Time synchronization deviation is denoted as Issuing a consistency instruction is recorded as .

[0083] The architecture of the device access and control gateway consists of a southbound protocol bridge, an execution controller, an edge computing unit, a caching and persistence subsystem, a northbound data adapter, and a security isolation unit. The southbound protocol bridge is responsible for establishing sessions with field networks such as OPC UA, BACnet / IP, and Modbus / TCP. The execution controller translates control commands issued by the rules and scheduling engine into write or call operations executable by the target device. The edge computing unit handles partitioned execution between the shadow running zone and the main running zone. The caching and persistence subsystem maintains multi-level cache queues and append-only buffers locally. The northbound data adapter completes uplink publishing to the digital twin engine and time-series data management module. The security isolation unit provides a minimally exposed session whitelist and access control policies. After power-on self-test, the device access and control gateway enters a boot process. First, it synchronizes with a unified time base, then establishes a southbound session and performs device discovery and location verification. Finally, based on the approval status of the process engine, it loads the policy package into the shadow running zone or the main running zone.

[0084] Time consistency is guaranteed through a unified time base and session sequence numbers. When establishing each southbound session, the device access and control gateway assigns a 32-bit unsigned session sequence number to that session and appends the session sequence number and a millisecond-level timestamp to each sampling frame and control frame. Time synchronization deviation is... This is represented as the absolute difference between the field device clock and the unified time base, which the system maintains at the session dimension. ≤2ms target constraint; when If the latency exceeds 5ms, the device access and control gateway marks the session as pending calibration and reduces the frequency of control command issuance until synchronization is completed again. End-to-end latency Defined as the time interval between the generation of control commands by the rules and scheduling engine and the confirmation of execution by the field executor, in typical scenarios unaffected by network congestion, statistical samples show... The median was 28ms, the 95th percentile was 46ms, and the 99th percentile was 71ms.

[0085] The Southbound Protocol Bridge is responsible for device discovery, site registration, type checking, address domain out-of-bounds checking, and mutual exclusion checks. During device discovery, the Southbound Protocol Bridge reads the object models exposed by each protocol and extracts the object identifier, attribute set, and available methods. It then compares these with the model-control point mapping table of the digital twin engine to generate a list of sites awaiting verification. During site verification, the Southbound Protocol Bridge performs type checking and address domain out-of-bounds checking according to the device type. Type checking confirms that the read / write operation is consistent with the site's data type; address domain out-of-bounds checking confirms that the register address or object instance number is within the allowed range; mutual exclusion checking detects whether the same physical site is simultaneously requested for writing by different policies. If the check fails, the device access and control gateway writes the fault entry locally, only appending to the buffer, and blocks write operations to that site until the fault is resolved. To quantify the necessity of the above checks, 20 repeated deployments were carried out in a sample containing 10 field devices and 320 points. Without the checks, the point write failure rate was 1.8%, while with the checks enabled, the point write failure rate was 0.2%, and the fault location time was reduced from an average of 24 minutes to an average of 7 minutes.

[0086] The edge computing unit provides partitioned execution capabilities for the shadow execution area and the main execution area. The shadow execution area is used for the playback and verification of policy packages, while the main execution area is used for the online execution of policy packages. The policy loading process is triggered by the process engine. The rules and scheduling engine issues policy packages, policy package version numbers, and signature digests. The device access and control gateway first loads the policy package into the shadow execution area and reads process quantities, status quantities, and event quantities according to the sampling period specified by the rules and scheduling engine. The read data is written to a local multi-level cache queue according to the unified resource identifier code and timestamp. The playback mechanism of the shadow execution area works in two modes: fixed length or sliding window. The window length can be configured to 1s, 5s, or 10s. The device access and control gateway simulates the control commands generated by the playback in a local closed loop and performs a consistency comparison with the simulation verification digest generated by the digital twin engine. When the comparison passes, a release consistency indication is generated. =1, otherwise =0. Only when =0. The strategy package is migrated to the main runtime area only when the value = 1 and the signature verification of the process engine is valid. In the 50-hour integrated debugging sample, a total of 5 sets of strategy templates were loaded. The consistency comparison between the shadow runtime area and the simulation verification summary passed 100%, and the median time required for each migration was 3.4 seconds.

[0087] The caching and persistence subsystem organizes data streams using a multi-level cache queue and append-only log structure to adapt to different jitter and bursts. The first level is a circular memory cache, used to absorb sampling jitter and provide continuous batches for uplink deployment. The second level is a disk append-only buffer, written sequentially using a combination key consisting of a Uniform Resource Identifier (URI), policy package version number, and timestamp. The third level is a failure retry queue, used to temporarily store data batches that could not be uploaded due to short-term network unavailability. The cache queue capacity and refresh policy can be configured individually according to device type. A standard configuration is a 256-frame circular cache, a 64MB append-only buffer segment size, and a 1GB failure retry queue capacity. In a 15-day operational sample, with the above configuration, the median packet loss rate (P1) was 0%, the 95th percentile was 0.02%, and the 99th percentile was 0.05%. All lost packets were recovered within 30 seconds via the failure retry queue.

[0088] The northbound data adapter is responsible for publishing collected data and execution receipts in batches to the digital twin engine and time-series data management module, and providing status notifications to the process engine and visualization monitoring terminal. Each publishing batch includes fields such as batch number, policy package version number, start timestamp, end timestamp, batch summary, and number of records. The batch summary uses a selected hash algorithm to summarize the records in the batch, and the summary value is written to the time-series data management module along with the batch metadata, and used for consistency comparison on the visualization monitoring terminal. To ensure the consistency of the publishing order, the northbound data adapter includes a session sequence number and timestamp in the first and last frames of each batch, and records the end-to-end latency statistics for that batch. In a sample of 180 policy switches, the northbound data adapter's batch publishing was successful in all cases, with an average batch size of 4.2MB, a median end-to-end latency (Le) of 31ms, and a 95th percentile of 55ms.

[0089] The execution controller translates control commands generated by the rules and scheduling engine into write and call operations executable by field devices, and provides rate limiting, over-limit protection, and interlock checks. Rate limiting prevents excessive writing to the same device within a unit of time, with a default limit of no more than 20 writes per second; over-limit protection blocks writes and logs anomalies when write values ​​exceed the device's allowable range; interlock checks confirm that the current command does not conflict with existing interlock states. After each write transaction is completed, the execution controller sends an execution receipt to the northbound data adapter, which includes the location identifier, target value, actual value, acknowledgment time, and error code. In a test sample of 32 control loops, enabling rate limiting and interlock checks reduced the number of device write rejection events caused by control commands from 73 to 8, and the average recovery time for write rejection events decreased from 11 minutes to 3 minutes.

[0090] The security isolation unit is responsible for implementing access control, minimum exposure, and trusted publication between the information network and the control network. Access control employs a whitelist policy, allowing only authorized addresses from the rules and scheduling engine, digital twin engine, process engine, and time-series data management module to access designated ports. The minimum exposure control principle prohibits the opening of unnecessary services on the control network side. Trusted publication requires signature verification, shadow runtime comparison, and session health checks to be completed before the policy package is migrated to the main runtime area. For ease of verification, the device access and control gateway generates a publication record for each policy publication, which includes the policy package version number, signature digest, session sequence number range, timestamp range, and publication consistency indication.

[0091] Regarding anomalies and boundary conditions, the device access and control gateway defines several processing paths. In the event of a time synchronization anomaly, if... If the latency exceeds 5ms for more than 10 seconds, the device access and control gateway will set the session to pending calibration, stop writing to the corresponding actuator, and only allow reading; when network jitter is abnormal, if the end-to-end latency is... If the failure time exceeds 100ms for three consecutive times, the device access and control gateway will refresh the failure retry queue and reduce the release batch size to recover. When there is an abnormal point mutual exclusion occupation, the device access and control gateway will process the write request with a first-come, first-served policy and write the rejected request to the append buffer for replay by the upper layer. When there is an abnormal session disconnection, the device access and control gateway will automatically reconnect and reset the session sequence number. After reconnection, the first batch will be marked as "breakpoint resume".

[0092] It should be noted that the data provided in this embodiment is verifiable. The device access and control gateway underwent quantitative testing in two scenarios. The medium-scale scenario included 10 exhibits, 32 control loops, and 196 monitoring points. In 20 repeated deployments, the point write failure rate decreased from 1.8% to 0.2%, the loop conflict location time decreased from an average of 24 minutes to an average of 7 minutes, and the median end-to-end latency Le was 28ms. The high-load scenario covered 15 days, 12 time periods per day, and a total of 180 policy switches. Northbound batch deployments were 100% successful, the median packet loss rate P1 was 0%, all lost packets were recovered within 30 seconds, and the median arrival time of the first control command after a policy switch was 36ms.

[0093] It should be noted that the device access and control gateway in this embodiment also includes the following three possible implementations: The first extension is to enable a time window write policy for southbound sessions, limiting specific devices to only being allowed to write within a specified time window, and only being allowed to read outside the time window; this policy can significantly reduce write conflicts during peak periods. The second extension is to enable differential digests for batch releases. The northbound data adapter generates differential digests outside of the batch digests, only summarizing records not covered by the previous batch, which helps to accelerate consistency comparison of the visual monitoring terminal. The third extension is to introduce multi-scenario playback scripts in the shadow running area. The device access and control gateway sequentially replays multiple representative operating condition scripts provided by the digital twin engine, generates consistency indicators for each operating condition, and aggregates them into a migration decision. The aggregation rule is implemented using simple majority or weighted majority, which can be configured according to project needs.

[0094] In terms of deployment and operation and maintenance, the device access and control gateway supports both monolithic and distributed deployment modes. In monolithic mode, the southbound protocol bridge, edge computing unit, northbound data adapter, and security isolation unit run on the same host, suitable for small to medium-sized scenarios. In distributed mode, the southbound protocol bridge and edge computing unit can run on edge nodes close to the field network, while the northbound data adapter and security isolation unit are deployed on information domain nodes. Through message queues and a unified time base, policy loading, playback, deployment, and archiving can be completed within 1 to 5 seconds in typical scenarios. The operation and maintenance tools provide session views, location views, and deployment views. Figure 3 The interface displays the health status of southbound sessions, point read / write statistics, and the status of the policy deployment link.

[0095] In summary, the device access and control gateway uses southbound protocol bridges, execution controllers, and edge computing units as its core components. It organizes field data and control flow through a unified time base, session sequence numbers, partitioned execution, and multi-level caching. Together with northbound data adapters and security isolation units, it achieves robust integration with the digital twin engine, rule and scheduling engine, process engine, and time-series data management module. Based on quantitative indicators such as end-to-end latency, packet loss rate, write failure rate, and consistency comparison, it can support the implementation of the device access and control gateway throughout the entire lifecycle of the exhibition hall project from three levels: time consistency, data consistency, and version consistency.

[0096] This embodiment will describe the digital twin engine in detail. The digital twin engine is used to establish a synchronized, simulateable, and verifiable model system between the virtual and physical domains of an exhibition hall project, providing consistent data and behavioral semantics throughout the planning, design, construction, commissioning, operation, renovation, and archiving phases. The digital twin engine works collaboratively with the project modeling subsystem, rule and scheduling engine, process engine, device access and control gateway, and time-series data management module to support the entire process from modeling and verification to release and aggregation. For ease of expression, this section only introduces identifiers and qualifies them one by one in the formulas: the state vector is denoted as... The control quantity is recorded as Observations are recorded as The next state function is denoted as The observation function is denoted as Digital twin simulation model is denoted as The state estimator is denoted as The parameter set is denoted as Error measurement is denoted as The simulation verification summary is recorded as follows: The function representing the model-control point mapping relationship is denoted as The version-bound hash key is denoted as The data fusion weight vector is denoted as .

[0097] The digital twin engine's architecture comprises a model resource manager, a model-control point mapping manager, a state estimation and data fusion unit, a simulation execution and verification unit, a version and snapshot manager, and a northbound interface unit. The model resource manager stores and loads spatial geometry models, device behavior models, and logical interlocking models, providing indexes by project, stage, and device type. The model-control point mapping manager maintains a one-to-one correspondence between digital twin model elements and field input / output addresses, and between programmable logic controller variable names and control channel numbers. The state estimation and data fusion unit synchronizes, denoises, and interpolates process quantities, state quantities, and event quantities from the time-series data management module, generating state vectors usable for simulation-driven and visualization-driven operations. The simulation execution and verification unit performs time-domain or event-domain simulations based on rules and policy packages generated by the scheduling engine, outputting simulation verification summaries. The version and snapshot manager binds the digital twin model to the policy package version number, segment summary index, and signature summary, generating traceable model snapshots. The northbound interface unit provides model views, switching between running and simulation states, and consistency comparison results to the visualization monitoring terminal and the project modeling subsystem.

[0098] In terms of data modeling, the digital twin engine organizes virtual elements in a hierarchical structure. The spatial layer records the exhibition hall's spatial geometry, exhibit locations, and equipment installation points; the equipment layer records equipment types, parameters, and permissible control ranges; the interlocking layer records the causal relationships and safety constraints between equipment; and the mapping layer records the binding of model elements to on-site control points. The model-control point mapping relationship is achieved through… Formal definition, where Identify model elements. For field input / output addresses, This refers to the variable name of the programmable logic controller. To control the channel number. To ensure version consistency, the version and snapshot manager calculate a hash key for each mapping change. ,in For the selected hash algorithm, To standardize resource identification coding, This is the strategy package version number. This is for changing the timestamp. It is associated with the segment summary index in the time series data management module and is used for consistency comparison.

[0099] In terms of state estimation and data fusion, the digital twin engine combines on-site observations with model priors. In the discrete time domain, the state update and observation model is written as: The state estimator minimizes the error metric Achieve joint estimation of parameters and state. Data fusion weight vector. Based on the observed noise statistics and online updates of sensor health, it meets the requirements. and In a sample containing 196 monitoring points, after adopting this state estimation and data fusion method, the median root mean square error of the state estimation was reduced by 27% and the 95th percentile was reduced by 33% compared with the unfused baseline.

[0100] In terms of simulation execution and verification, the digital twin engine supports both time-domain and event-domain simulations. Time-domain simulation uses fixed-step or adaptive-step integral models, while event-domain simulation uses rule-triggered or interlocked triggers to advance discrete events. Simulation inputs include a policy package, initial state vector, boundary conditions, and perturbation scripts; simulation outputs include multi-channel time-series trajectories and event sequences. The digital twin engine compares the simulation outputs with the target constraints to generate a simulation verification summary. . The generation process employs a two-stage workflow: first, key indicators are normalized and aggregated to obtain a fixed-length indicator vector; then, a summary is generated from this indicator vector. For multi-scenario verification, the digital twin engine weights the verification indicators of multiple representative working conditions into a vector. After aggregation, multi-scenario indicator vectors are formed, and then simulation verification summaries are generated. This process ensures that fixed-length summaries can be output for both single and multi-scenario applications, facilitating consistency comparison between device access and control gateway summaries in the shadow runtime area and simulation verification areas. In a sample of 5 policy template sets and 50 hours of comprehensive debugging, the pass rate for comparing simulation verification summaries with shadow runtime area playback results was 100%, and the deviation in the number of control commands counted over a 1-hour interval was less than 0.1% (see [reference]). Figure 5 (As shown).

[0101] In terms of interlocking and safety constraint modeling, the digital twin engine records safety rules in the form of constraint sets. Each constraint is defined by a triple (trigger condition, prohibition set, and recovery condition), where the trigger condition is the logical expression that enters the restricted state when satisfied, the prohibition set lists the control actions that are prohibited in the restricted state, and the recovery condition defines the conditions for exiting the restricted state. To avoid logical conflicts, the digital twin engine performs reachability and dead zone checks when loading the constraint set and writes the detection summary to the version and snapshot manager. Based on a sample of 32 control loops, 120 interlocking rules were detected, with an average detection time of 0.9 seconds. Potential conflicts were located and fixed within 5 iterations.

[0102] In terms of version and snapshot management, the digital twin engine provides unified version management for models, mappings, constraints, and parameters. Each change generates a model snapshot, which contains complete copies of the spatial, device, interlocking, and mapping layers, and is bound to the policy package version number, segment digest index, and signature digest. Snapshots can be retrieved by stage code segment and timestamp, and are used for runtime rollback, differential analysis in the modification stage, and solidification in the archiving stage. Statistical samples show that in projects with snapshot mechanisms enabled, the average rollback operation in the runtime stage takes 42 seconds, a significant reduction compared to the baseline without snapshot mechanisms (average 3 minutes).

[0103] Regarding interfaces with other modules, the digital twin engine provides four types of inputs and outputs. For the project modeling subsystem, the digital twin engine receives the phase model, unified resource identifier encoding mapping, and phase state machine, and returns the model snapshot identifier and mapping consistency verification result. For the rules and scheduling engine, the digital twin engine receives the policy package and policy package version number, and returns the simulation results and simulation verification summary. For device access and control gateways, the digital twin engine provides the playback scripts and simulation verification summaries required by the shadow runtime area. The system receives replay fingerprints and provides consistency checks. For the time-series data management module, the digital twin engine reads the segment summary index and writes the simulation baseline trajectory in batches for subsequent visualization comparison and offline analysis. All interfaces include millisecond-level timestamps and session sequence numbers, and the message body contains the policy package version number and snapshot identifier to ensure sequence consistency and version consistency.

[0104] In terms of phase collaboration, the digital twin engine assumes different responsibilities in the seven phases. The scheme phase focuses on spatial geometry and equipment type-level modeling, without establishing on-site control point bindings. The design phase supplements equipment parameters and generates equipment behavior models, supporting the establishment of simulation baselines. The construction phase completes model-control point mapping binding and solidifies network topology information. The commissioning phase performs shadow runtime playback and simulation comparison, outputting a simulation verification summary. It is associated with the segment summary index. During the runtime phase, online state estimation, anomaly detection, and policy switching evaluation are provided, generating a reference trajectory corresponding to the policy package version number. During the modification phase, local simulation scripts are generated based on the difference list, and incremental verification is performed. During the archiving phase, model snapshots are frozen and bound to the policy package version number and segment summary index as immutable.

[0105] Regarding anomalies and boundary conditions, the digital twin engine defines four predictable scenarios: missing data, time drift, mapping inconsistency, and simulation mismatch. When data is missing, the state estimation and data fusion unit compensates using temporal neighborhood interpolation and model priors, and marks the missing interval in the summary. When time drift exceeds 5ms, the digital twin engine pauses generating a new simulation verification summary and issues a time synchronization alarm. When mapping inconsistency occurs, the model-control point mapping manager reverts to the most recently passed consistency check version. When simulation mismatch occurs, the simulation execution and verification unit outputs a mismatch report, which includes indicator deviations, triggering events, and suggested parameter adjustment ranges.

[0106] In this embodiment, two representative scenarios were quantitatively evaluated. The medium-scale scenario included 10 exhibits, 32 control loops, and 196 monitoring points. During 20 repeated deployments, after implementing model-control point mapping management and version snapshots, the average time to locate mapping consistency faults decreased from 25 minutes to 6 minutes. The larger-load scenario covered 15 days of continuous operation and 180 policy switches. In the hourly trajectory comparison between the simulation verification summary and the operational data, the median mean square error of the trajectory was 0.07, a significant reduction compared to the baseline (median 0.12) without state estimation and data fusion enabled. The median event timing matching rate within a 5-minute window before and after policy switching was 99.6%.

[0107] It should be noted that the digital twin engine in this embodiment also includes the following three implementable methods: First, parameter adaptive calibration: for the parameter set Online least squares or recursive least squares is used for updates, and the step size of parameter updates is constrained to avoid introducing oscillations. In the samples of the lighting and air conditioning subsystems, the 95th percentile of the model-measured deviation decreased by 21% and 17% respectively within 24 hours after adopting this method. Second, multi-resolution simulation: allows for asynchronous long integrals and synchronization point alignment for subsystems with large differences in response speed, allocating computational resources to key subsystems while keeping the overall simulation time unchanged. Third, diagnostic mode: enables fault injection scripts within the simulation execution and verification unit to perform offline verification for typical faults (sensor misalignment, actuator jamming, network jitter), and writes the results to the version and snapshot manager for rapid location during runtime.

[0108] In terms of deployment and operation, the digital twin engine supports both monolithic and distributed deployment modes. Monolithic mode is suitable for small to medium-sized exhibition halls, where the model resource manager, state estimation and data fusion unit, and simulation execution and verification unit run on the same host. In distributed mode, the simulation execution and verification unit can be horizontally scaled, simulating in parallel by exhibit or device type, with the model-control point mapping manager providing consistency verification as a shared service. In typical scenarios, the execution time for a single simulation verification is between 1 and 5 seconds, and snapshot generation is completed within 100 to 300 milliseconds. To ensure time consistency, the digital twin engine includes millisecond-level timestamps and session sequence numbers in all outputs and periodically corrects clock drift when interacting with device access and control gateways.

[0109] In summary, the digital twin engine enables the virtual and physical domains to achieve synchronization and a consistent closed loop for simulation and verification at each stage through collaborative mechanisms such as model resource management, model-control point mapping management, state estimation and data fusion, simulation execution and verification, and version and snapshot management. Under specified sample and load conditions, various quantitative indicators (state estimation error, trajectory mean square error, event timing matching rate, and rollback time, etc.) meet the consistency requirements within and across stages, and can be extended as needed through parameter adaptive calibration, multi-resolution simulation, and diagnostic modes.

[0110] This embodiment will describe the time-series data management module in detail. The time-series data management module provides a sustainable, quickly retrieval-enabled, and cross-version traceable time-series data foundation across the acquisition, simulation, and visualization domains of the exhibition hall project. It also performs hierarchical organization, incremental persistence, and version consistency verification for process quantities, state quantities, and event quantities. The time-series data management module works collaboratively with the project modeling subsystem, device access and control gateway, digital twin engine, rule and scheduling engine, and visualization monitoring terminal to support a data closed loop from the debugging phase to the operation phase. For ease of expression, identifiers are introduced and defined individually only in the formulas: write throughput is denoted as... Read latency is denoted as The size of a segment file is recorded as The segment summary index is denoted as (Following the previous definition), the strategy package version number is denoted as... (Following the aforementioned definition), the Uniform Resource Identifier (URI) is denoted as... (Following the previous definition), the timestamp is recorded as (milliseconds), the probability of a successful disk placement is denoted as Packet loss rate is denoted as Disordered windows are recorded as Compression ratio is denoted as The hit rate is recorded as The data retention period is recorded as The index key function is denoted as The segment check function is denoted as .

[0111] The time-series data management module's architecture consists of an acquisition entry layer, a preprocessing and buffering layer, a storage engine layer, an indexing and retrieval layer, a version and consistency verification layer, and a northbound service layer. The acquisition entry layer receives batches of process, status, and event data from the device access and control gateway; the preprocessing and buffering layer performs deduplication, out-of-order rearrangement, time base alignment, and batch grouping; the storage engine layer generates and compresses segment files according to the append-only log structure merging tree; the indexing and retrieval layer maintains segment summary indexes, inverted indexes, and time range indexes; the version and consistency verification layer binds the segment summary indexes to the policy package version number and outputs consistency judgments; and the northbound service layer provides hierarchical query, comparison, and export capabilities to the digital twin engine and the visualization monitoring terminal. Process, status, and event data are logically partitioned into separate databases and tables, each using independent segment files and indexes to allow for differentiated compression and caching strategies based on access characteristics.

[0112] Regarding the data model and key space, the time-series data management module generates a unique index key for each record. The index key function is defined as follows: ,in For the selected hash algorithm, This indicates concatenation. Records are written along with a Uniform Resource Identifier (URI), policy package version number, and millisecond-level timestamp to ensure stable location during fragmentation and merging. The physical sorting within a segment file follows a combined sorting principle of "stage code segment first, timestamp second, URI third," facilitating range scanning and batch playback within a stage. The segment file's metadata includes the segment's start and end timestamps, the first and last URIs, the number of records, the compression ratio, the segment digest, and the policy package version number. Segment digest index. Each segment file is uniquely generated for subsequent consistency comparison and fast jump.

[0113] Regarding the write path, the time-series data management module employs multi-layer buffering to absorb jitter and bursts. The acquisition entry layer buckets batches from the device access and control gateway according to the Uniform Resource Identifier (URI) and then enters the preprocessing and buffering layer. The preprocessing and buffering layer first performs deduplication, detecting duplicates in the in-memory hash table based on the index key function; subsequently, it performs out-of-order rearrangement, with an out-of-order window... The default value is 2 seconds. Data within the window is reordered by timestamp, and late data outside the window is appended as a "late segment" and marked as late. Finally, time base alignment is performed, aligning batches with non-uniform time bases to a unified millisecond time axis using interpolation or downsampling. Write throughput With a medium-sized sample size (2,000 records per second), the median is 2,450 records per second, and the 95th percentile is 2,800 records per second; with a larger load sample size (10,000 records per second), the median is 11,200 records per second, and the 95th percentile is 12,600 records per second. Successful disk placement probability. In a 15-day running sample, the success rate was 100%, and all short-term failures were filled within 30 seconds through the failure retry queue.

[0114] Regarding the storage engine, the time-series data management module employs an append-only structure with a log-structured merge tree. The memory layer maintains active segments using ordered skip lists, the disk layer is organized using immutable segment files, and a background merge thread performs segment merging based on size and time strategies. (Segment file size...) The default target size is 64MB. New segments are generated on a rolling basis when the active segment reaches the target size or exceeds the 60s time threshold (see [link]). Figure 4 (As shown). Compression employs a combination of block-level columnar compression and differential coding. For process variables, floating-point differential compression with bit width is preferred; for state variables, run-length encoding is preferred; and for event variables, key-value dictionary compression is preferred. On a 10-day sample, the compression ratio is [missing information]. The median was 3.7, and the 95th percentile was 4.5, representing a significant decrease in disk usage compared to the uncompressed baseline (see [reference]). Figure 9 (As shown). The background merging strategy follows the principle of "new and old priority and minimizing time coverage" to avoid excessive merging across stages or versions, so as to maintain a consistent mapping between the segment summary index and the strategy package version number.

[0115] In terms of indexing and retrieval, the time-series data management module maintains three types of indexes. The first type is a segment summary index, used for quickly locating segment files based on version and stage dimensions. The second type is an inverted index, where the key is a Uniform Resource Identifier (URI) and the value is a list of segment files containing that URI along with a time range. The third type is a time range index, which records the start and end timestamps of each segment file and uses skip lists or sparse B+ trees for fast range location. The query path is first coarsely located using the segment summary index and the time range index, and then finely located using the inverted index. In a sample run of 180 strategy switches and 15 days, the query hit rate... The median is 99.2%, and the read latency is... The median time for aggregate queries at the 1-hour granularity is 47ms, and the 95th percentile time is 83ms; the median time for fine-grained queries at the 1-minute granularity is 58ms, and the 95th percentile time is 96ms.

[0116] Regarding version and consistency verification, the time-series data management module binds the segment summary index of each segment file to the policy package version number and provides a consistency determination function. The determination function is defined as follows: If and only if the binding relationship between the segment summary index and the policy package version number is consistent in the metadata and verification records; otherwise... .

[0117] Before publishing or rolling back, the visual monitoring terminal calls a consistency determination function, allowing progress only if the determination result is 1. Combined with the aforementioned processes of device access and control gateway and digital twin engine, consistency determination can be completed within 100ms to 300ms. To support rollback, the time-series data management module stores signature digests and session sequence number ranges in the segment metadata, facilitating cross-system verification.

[0118] Regarding data retention and lifecycle management, the time-series data management module formulates retention strategies based on two dimensions: stage and version. The retention strategy is implemented in a three-tiered hierarchy: hot data area, warm data area, and cold data area. The hot data area retains data from the past 7 days, with indexes and segment files permanently cached; the warm data area retains data from the past 180 days, with only indexes permanently cached; the cold data area contains archived data, which is batch compressed and dumped by segment files. Data retention period Configuration can be done separately for project level and device class. Archiving operations are triggered during the archiving phase; segment files and segment summary indexes are frozen in read-only mode and bound to the model snapshot for post-event verification and re-access. Statistics from 250 days of operation show that, with tiered retention, the cache hit rate is 22% higher than the full hot storage strategy, and the total storage cost is reduced by 41%.

[0119] Regarding anomalies and boundary conditions, the time-series data management module defines five processing paths: out-of-order window, time drift, batch missing, index corruption, and disk pressure. Out-of-order window occurs when the difference between the timestamp of late data and the current time exceeds the out-of-order window; the system writes this data into the late segment and records the late range in the metadata. Time drift occurs when the difference between the batch time base and the unified time base exceeds a threshold; the system sets this batch to pending calibration and pauses merging. Batch missing occurs when there are skipped session sequence numbers; the system waits for the missing data to be filled in the failure retry queue; if it is not filled within 30 seconds, it is marked as missing and written to the segment metadata. Index corruption occurs when the segment summary index or inverted index is inconsistent; the system triggers reconstruction and corrects it based on the segment summary. Disk pressure occurs when the remaining space is below a threshold; the system pauses new segment rolling and prioritizes merging and dumping. All of these paths are recorded in the operation log for easy cross-module location.

[0120] Regarding interfaces with other modules, the time-series data management module provides stable input and output. For device access and control gateways, it provides batch write interfaces, failure retry interfaces, and write confirmation receipts; for the digital twin engine, it provides simulation baseline trajectory write interfaces and range query interfaces by version, stage, and unified resource identifier code; for the project modeling subsystem, it provides segment summary index retrieval interfaces by stage code segment and policy package version number; for the visual monitoring terminal, it provides aggregation query, comparison query, and consistency judgment query, and supports exporting to segmented files; for the rules and scheduling engine, it provides windowed statistical interfaces before and after policy switching for assessing the impact of policy switching. All interface message bodies carry the policy package version number, session sequence number, and millisecond-level timestamp to ensure cross-system sequential consistency.

[0121] It should be noted that, regarding the implementation examples and test data, two representative scenarios were constructed for quantitative evaluation. The medium-scale scenario included 10 exhibits, 32 control loops, and 196 monitoring points, running continuously for 50 hours with an average write rate of 2,000 records per second. In this scenario, the write throughput... The median is 2,450 messages per second, with a read latency of [missing information]. The median compression time is 47ms, and the compression ratio is... The median is 3.8, the out-of-order window reordering coverage within 2 seconds is 99.5%, and the packet loss rate is... The median was 0%, and all packet loss was recovered within 30 seconds. Under heavy load, the system ran continuously for 15 days, with 12 time slots per day and 180 policy switches, achieving an average write rate of 10,000 records per second. In this scenario, the write throughput... The median is 11,200 messages per second, with a read latency of [missing information]. The median is 58ms, the 95th percentile is 96ms, and the query hit rate is... The median is 99.2%, indicating a high probability of successful placement. 100%, consistency determination The average time was 0.21 seconds (see [reference]). Figure 6 (As shown).

[0122] It should be noted that the time-series data management module in this embodiment also includes the following three implementation methods: First, enhanced visibility: generating a visual summary snapshot for the segment file, including a primary key distribution histogram and time coverage density, which can be directly rendered on the visual monitoring terminal side to assist in locating hotspots and gaps. Second, differential segmentation technology: differential calculation is performed on the same Uniform Resource Identifier (URI) code between adjacent versions to form differential segments, storing only the changed parts, which can further reduce storage costs in scenarios where multiple versions coexist. Third, near real-time computing interface: user-defined function hooks are exposed at the end of the write path, allowing rolling aggregation or anomaly detection to be performed on records within a batch, and the results are written with the same name as the segment file, facilitating direct consumption by the upper layer.

[0123] In terms of deployment and operation, the time-series data management module supports both monolithic and distributed deployment modes. Monolithic mode is suitable for small to medium-sized exhibition halls, with the data acquisition entry layer and the northbound service layer running on the same host. In distributed mode, the storage engine layer and index and retrieval layer can be horizontally scaled using unified resource identifier encoding hash sharding, and the preprocessing and buffering layers are deployed close to the device access and control gateway to reduce write latency. Under normal scenarios, new segment rolling and segment summary index generation are completed within 100ms to 300ms, segment merging jobs are executed during off-peak hours without affecting online queries, and backup and archiving tasks are automatically triggered during the archiving phase and can be completed without stopping writes. To ensure time consistency, all disk records and index updates use millisecond-level timestamps, and cross-nodes are periodically corrected using a unified time base.

[0124] In summary, the time-series data management module constructs a foundation for time-series data that spans acquisition, simulation, and visualization through append-only log structure merging trees, hierarchical indexes, and segment summary indexes bound to strategy package version numbers. Under given sample and load conditions, quantitative indicators such as write throughput, read latency, compression ratio, query hit rate, and consistency determination meet the requirements for continuous operation, and maintain recoverability and traceability under boundary conditions such as out-of-order, missing, and index-damaged conditions.

[0125] This embodiment will describe the rules and scheduling engine in detail. The rules and scheduling engine is used to generate, evaluate, orchestrate, and release control and scheduling instructions under the constraints of the exhibition hall project's phased model, maintaining consistency in strategy packages, time, and data across the scheme, design, construction, commissioning, operation, renovation, and archiving phases. The rules and scheduling engine works collaboratively with the project modeling subsystem, digital twin engine, device access and control gateway, process engine, and time-series data management module. Its responsibilities include strategy template management, scheduling plan management, parameterized combination generation, pre-release verification, runtime switching and rollback, version and signature management, and audit aggregation. For ease of expression, identifiers are introduced only in the formulas and each is individually defined: the strategy package version number is denoted as... The stage code segment is denoted as The strategy template set is denoted as The set of scheduling plans is denoted as The parameter vector is denoted as The objective function is denoted as The constraint set is denoted as The weight vector is denoted as Time window record Issuing readiness instructions is recorded. The consistency determination function is denoted as The simulation verification summary is recorded as follows: Replay consistency indicator is recorded as .

[0126] In terms of architecture, the rules and scheduling engine consists of a policy template library, a scheduling plan library, a parameterized combiner, a policy package builder, a simulation pre-verifier, a shadow playback coordinator, a release transaction coordinator, a version and signature manager, and a runtime orchestrator. The strategy template library organizes templates by device type, operating condition label, and stage dimension. Each template consists of four parts: input, condition, action, and interlock reference. The scheduling plan library organizes plan items by stage code segment and calendar dimension. Each plan item describes start / stop time, repetition rules, and conflict priority. The parameterization combiner selects templates and extracts parameter vectors based on the stage dictionary and unified resource identifier encoding mapping provided by the project modeling subsystem. The strategy package builder encapsulates parameterization templates, scheduling plans, interlock references, and metadata into strategy packages and generates a strategy package version number. The simulation pre-verifier submits the strategy package to the digital twin engine for time-domain or event-domain simulation and obtains a simulation verification summary. The shadow playback coordinator collaborates with the device access and control gateway to complete shadow runtime area playback and collect consistency indicators. The release transaction coordinator drives two-phase commit when the process engine signature verification is valid and the consistency comparison passes. The version and signature manager maintains the strategy package version number, signature summary, and audit log. The runtime orchestrator performs strategy switching, rate limiting, and rollback based on the scheduling plan and real-time signals during the runtime phase.

[0127] In terms of data models, the rules and scheduling engine maintains three core objects. The first is policy templates, whose fields include template identifier, applicable device type, input signal list, control quantity list, trigger condition, action expression, and interlock reference. Action expressions support basic operators such as arithmetic operations, range pruning, and rate limiting. The second is scheduling plans, whose fields include plan identifier, stage code segment, start / stop time, repetition rules, exception calendar, and conflict priority. The third is policy packages, whose fields include policy package identifier, policy package version number, stage code segment, parameterized template list, scheduling plan list, interlock reference list, simulation baseline identifier, signature digest, build timestamp, and release status. Policy packages and segment digest indexes are bound one-to-one in the time-series data management module for consistency comparison of the visual monitoring terminal.

[0128] In terms of parameterization and optimization, the rule and scheduling engine determines the parameter vector in the form of an objective function and constraints. The objective function can be decomposed according to the equipment subsystem; for example, the lighting subsystem is weighted by illuminance error and energy consumption, the HVAC subsystem by temperature and humidity deviation and energy consumption, and the audiovisual subsystem by sound pressure level and delay. Formalized, this is written as minimization. satisfy ,in For the first Sub-objective functions, As weight, This represents the feasibility constraints under a given stage code segment (including equipment rated range, interlocking prerequisites, and venue opening time restrictions). To improve reusability, the rule and scheduling engine records recommended initial values ​​and parameter boundaries for each template. The parameterization combiner first solves for a fast feasible solution using the recommended initial values, and then performs local search or piecewise linear approximation optimization according to weights. Twenty parameterization experiments were conducted with a sample of 10 exhibits and 32 control loops. The median average solution time was 210ms, and the 95th percentile was 380ms. After introducing feasibility constraints, the rejection rate of unexecutable templates was 100%, avoiding runtime write rejection (see [reference]). Figure 11 (As shown).

[0129] Regarding strategy package construction and version management, the rules and scheduling engine generates a strategy package version number for each build and writes the version number and stage code segment into the metadata. The strategy package version number is incremental and monotonic. The builder calculates a digest of the strategy package content, and the digest, along with the signature digest from the process engine, is written to the version and signature manager. During the build process, the rules and scheduling engine generates a version list and a list digest for each strategy package. The version list identifies all parameterized templates and scheduling plans, while the list digest is used for subsequent consistency verification and rapid comparison. Based on a sample of 180 strategy switches, the median time for the strategy package construction and registration process is 0.42 seconds, and the 95th percentile is 0.73 seconds.

[0130] For pre-release verification, the rules and scheduling engine employs a three-tiered threshold: simulation pre-verification, shadow playback, and consistency determination. First, the simulation pre-verifier submits the policy package, initial state, and boundary conditions to the digital twin engine, which then returns a simulation verification summary. Second, the shadow playback coordinator organizes device access and control gateways to run in the shadow runtime area according to time windows. Play back the collected data, generate a playback fingerprint, and calculate a playback consistency indicator (see [reference]). Figure 5 (As shown); Finally, the rules and scheduling engine trigger a consistency check on the visual monitoring terminal, and the check function... And playback consistency indication At that time, issue a readiness instruction. Otherwise, take 0. In the 50-hour integrated debugging experiment, using 5 sets of strategy templates, the consistency comparison between simulation verification and shadow playback had a pass rate of 100%, and the average time for consistency determination was 0.21s.

[0131] In terms of runtime orchestration, the rules and scheduling engine executes start-ups, shutdowns, switches, and rollbacks according to the scheduling plan, handling unexpected events and priority conflicts. Time-driven start-ups and shutdowns are triggered by the scheduling plan library, while event-driven switches are triggered by the stage state machine of the project modeling subsystem or status notifications from the device access and control gateway. Conflict resolution adopts a priority chain of "interlock priority—safety priority—planning priority—energy efficiency priority," with interlock restrictions having a veto power, followed by safety constraints, then planning constraints, and energy efficiency adjustments taking effect only if they do not violate the first three constraints. The rules and scheduling engine generates a switch transaction identifier for each switch and records windowed statistics in the time-series data management module for impact assessment. Based on a 15-day, 180-switch sample, the success rate of start-ups and shutdowns and switches was 100%, with a median arrival time of 36ms for the first control command after a switch and a 95th percentile of 61ms. In the 27 requests with interlock conflicts, all were intercepted and returned with visual prompts.

[0132] Regarding rollback and fault handling, the rules and scheduling engine provides three paths. First, version rollback: When a critical metric caused by a policy package exceeds a threshold, the runtime orchestrator calls the release transaction coordinator to roll back the current version to the previous stable version. The rollback process follows the same two-phase commit as release. Second, partial disabling: When a single template causes an anomaly, the rules and scheduling engine temporarily disables it from the current policy package and restores service with the minimum replacement template. Third, security degradation: When the digital twin engine or device access and control gateway reports time synchronization anomalies, mapping inconsistencies, or playback mismatches, the rules and scheduling engine downgrades to a secure template set, retaining only basic monitoring and limit control. Statistics show that the trigger rates for the three handling paths are 0.7%, 0.4%, and 0.3% respectively, all completing the closed loop within one minute.

[0133] Regarding interfaces with other modules, the rules and scheduling engine interacts stably with five modules. For the project modeling subsystem, the rules and scheduling engine receives the stage dictionary, stage state machine, and unified resource identifier encoding mapping, and returns policy requirements and a list of available templates. For the digital twin engine, the rules and scheduling engine submits policy packages and simulation scenarios, and receives simulation results and simulation verification summaries. For the device access and control gateway, the rules and scheduling engine issues policy packages, policy package version numbers, and playback window configurations, and receives playback consistency indications and execution receipts. For the process engine, the rules and scheduling engine submits policy package summaries to obtain signatures and approval results. For the time-series data management module, the rules and scheduling engine queries the segment summary index and writes the statistical results of the switching window, providing a comparison basis for the visual monitoring terminal. All interface message bodies carry millisecond-level timestamps and session sequence numbers, and are marked with stage code segments and policy package version numbers to ensure sequence consistency and version consistency.

[0134] Regarding anomalies and boundary conditions, the rules and scheduling engine defines five categories of scenarios and their handling strategies. First, template parameter out-of-bounds: the parameterized combiner automatically rolls back to the boundary value and records an alarm. Second, plan conflicts: the scheduling plan library performs conflict detection during the build phase, and the runtime orchestrator re-verifies and resolves them according to the priority chain when triggered. Third, simulation mismatch: the simulation pre-verifier outputs a mismatch report and blocks the release. Fourth, replay failure: the shadow replay coordinator requests additional samples or a shorter time window for retrying. Fifth, signature verification failure: the release transaction coordinator terminates the transaction and requires the process engine to re-sign. All of the above scenarios generate audit logs within the version and signature manager.

[0135] In terms of implementation examples and test data, the rules and scheduling engine underwent quantitative evaluation in two representative scenarios. The medium-scale scenario included 10 exhibits, 32 control loops, and 196 monitoring points. The average policy refactoring frequency was once per hour, the median parametric solution time was 210ms, the median policy package construction and registration time was 0.42s, the consistency comparison pass rate of simulation verification and shadow playback was 100%, and the median end-to-end time from construction to release was 1.6s. The larger load scenario covered 15 days and 180 policy switches, with a 100% transaction success rate. The median arrival time of the first control command after a switch was 36ms, the 95th percentile was 61ms, and there were 0 unauthorized policy changes.

[0136] It should be noted that the rules and scheduling engine in this embodiment also includes the following three possible implementation methods: First, adaptive weight update: rolling learning is introduced into the weight vector of the objective function, and the weights are updated at the daily level based on the statistical results of the time-series data management module, so that energy efficiency and comfort are dynamically balanced on different passenger flow days. Second, multi-scenario template aggregation: during the simulation pre-verification stage, simulation verification summaries are generated according to multiple representative working conditions, and the indicators of each working condition are aggregated according to weight to generate a single release benchmark, improving the stability of complex exhibits. Third, fine-grained rollback points: the strategy package is split into sub-packages that can be rolled back independently, and the sub-packages are constrained by a dependency graph. When rolling back, only the sub-package that caused the exception is rolled back while the remaining sub-packages remain online, shortening the recovery time.

[0137] In terms of deployment and operation, the rules and scheduling engine supports both monolithic and distributed modes. In monolithic mode, the policy template library, scheduling plan library, parameterized combiner, and policy package builder run on the same host. In distributed mode, the simulation pre-verifier and runtime orchestrator can be horizontally scaled and processed in shards according to exhibits or device categories, while the release transaction coordinator runs as a centralized service to maintain consistency. In typical scenarios, the time from the triggering of the receive phase switch to the completion of the release transaction is within the range of 1 to 5 seconds. During peak periods, the system prioritizes the real-time performance of release transactions and consistency checks, and parameterized solving and simulation pre-verification can be scaled through elastic computing resources.

[0138] In summary, the rules and scheduling engine, based on the policy template library and scheduling plan library, forms publishable policy packages through parameterized combination, simulation pre-verification, shadow playback, and consistency determination. During runtime, priority chains and transaction mechanisms ensure the determinism of start-up, shutdown, switching, and rollback. Under given sample and load conditions, the construction latency, switching latency, and consistency indicators meet the requirements for continuous operation. Furthermore, its adaptability in complex display scenarios can be further improved through adaptive weights, multi-scenario aggregation, and fine-grained rollback.

[0139] This embodiment will describe the process engine in detail. The process engine is used to implement process-oriented modeling, signature approval, compliance verification, and release event orchestration for tasks, inspections, and acceptance records throughout the scheme, design, construction, commissioning, operation, renovation, and archiving phases of the exhibition hall project. It maintains consistent interaction with the project modeling subsystem, rules and scheduling engine, digital twin engine, device access and control gateway, and time-series data management module throughout the entire chain. The core objective of the process engine is to transform phase events and approval thresholds into executable process instances, ensuring that the strategy package version number and signature digest are verified and bound before release and rollback actions. For ease of expression, identifiers are introduced only in the formulas and each is individually qualified: the process instance identifier is denoted as... Task node identifier is recorded as The stage code segment is denoted as (Following the previous definition), the strategy package version number is denoted as... (Following the aforementioned definition), the signature digest is denoted as The approval time limit is recorded as The timeout penalty coefficient is denoted as Publish transaction status record The preparation phase and the submission phase of the two-phase submission are respectively denoted as... and The process pass rate is recorded as The rejection rate is recorded as The timeout rate is recorded as Traceability marking The consistency determination function is denoted as (Following the previous definition), the signature verification function is denoted as... The function for determining the license is denoted as Or 0.

[0140] In terms of architecture, the process engine consists of a process definition manager, a form and evidence collector, a signature and approval service, a compliance template checker, a release transaction coordinator, a rollback transaction coordinator, an audit and traceability logger, and a northbound interface unit. The process definition manager is responsible for maintaining a process template library by stage, defining task nodes, roles, inputs, outputs, and transition conditions in the templates; the form and evidence collector is responsible for collecting inspection records, test reports, on-site photos, and digital files at each task node, and connecting to the time-series data management module to backfill key indicator snapshots; the signature and approval service provides non-repudiation approval based on signature digests, supporting multiple roles in parallel; the compliance template checker compares the achievement conditions of process nodes with the stage dictionary provided by the project modeling subsystem, and calls the interfaces of the digital twin engine and the rules and scheduling engine to verify the version and simulation baseline; the release transaction coordinator collaborates with the device access and control gateway to realize two-phase commit release; the rollback transaction coordinator completes rollback using the same mechanism; the audit and traceability recorder generates traceability identifiers for each approval, release, and rollback, and writes them to the time-series data management module; the northbound interface unit outputs process status and key information to the visual monitoring terminal.

[0141] In terms of the data model, the process engine maintains a process template for each stage. The template includes a process template identifier, stage code segments, a set of nodes, a set of transition conditions, and a set of verification rules. Each task node in the node set includes a node identifier, role, input list, output list, required evidence type, and approval time limit. The output list can reference strategy packages, strategy package version numbers, and list summaries generated by the rules and scheduling engine, as well as simulation verification summaries generated by the digital twin engine. Each process instance... Phase code segments are bound during creation. With traceability label The files and evidence in the example are automatically associated with It is recorded with a timestamp in milliseconds. To maintain consistency across modules, the workflow engine calculates the signature digest when generating approval documents. And save the signature digest and session sequence number range in the audit and traceability logger.

[0142] In terms of process modeling and execution, the process engine compiles templates into finite state automata, where the set of states corresponds to task nodes and transition conditions correspond to edges between nodes. To accommodate both serial and parallel structures, the process engine introduces barrier nodes into parallel branches during compilation, with the in-degree and out-degree of the barrier set according to the number of branches. When a process instance is executed, the form and evidence collector first ensure that the input list and required evidence are complete. Then, the signature and approval services push the node into the pending approval state, with the approval time limit for the pending state... Retrieved from node configuration; once a node is reached, the transition conditions trigger the next node. For nodes that need to be linked with strategy packages, the process engine calls the rules and the scheduling engine to read the strategy package version number during the transition. It then calls the digital twin engine to read the simulation verification summary and writes the corresponding fields into the node output.

[0143] Regarding signature and approval, the workflow engine generates a signature request for each node awaiting approval, including the workflow instance identifier, node identifier, policy package digest, and key evidence digest. The signature verification function is defined as Ver(Sig) = 1 if and only if the signature digest matches the initiator's public key and the signature timestamp is within the node's approval time limit; otherwise, it is 0. The approval condition is... =1 and the node fulfillment condition is met. To control default risk, a penalty model with approval time limit constraints is introduced, where the node's overtime penalty is defined as... ,in This represents the actual approval time. In a sample containing 10 exhibits, 32 control loops, and 196 monitoring points, the process pass rate after adopting the signature and approval service was [data missing]. The median rejection rate was 98.6%. The median was 1.1%, and the timeout rate was... The median time for single-node signature verification is 0.3%, and the median time for single-node signature verification is 0.18 seconds.

[0144] Regarding compliance verification, the process engine performs three types of verifications for each key node. The first type is stage consistency verification, which checks whether the stage to which the node belongs is consistent with the stage dictionary of the project modeling subsystem, and whether the preconditions for stage switching have been met. The second type is version consistency verification, which calls the segment summary index interface and consistency determination function of the time series data management module. The first type of verification is a pass if the result is 1. The third type is simulation consistency verification, which involves reading the simulation verification summary provided by the digital twin engine and comparing it with the results on the visual monitoring terminal. Only when all three types of verifications pass can the node enter the completion state. Statistics show that during 50 hours of integrated debugging, the average time for the above three types of verifications was 0.27s, with stage consistency verification taking 0.05s, version consistency verification taking 0.12s, and simulation consistency verification taking 0.10s.

[0145] Regarding transaction publishing, the process engine uses a two-phase commit mechanism to ensure consistency with transactions related to device access and control gateways. Preparation phase. In the middle stage, the process engine sends a release preparation request to the device access and control gateway, including the policy package version number, signature digest, segment digest index, and session health check indication; the device access and control gateway returns a replay consistency indication and a session health digest, and the process engine writes the results to the audit and traceability logger. (Submission phase) In the middle, if the license determination function is published... If the result is positive, the process engine issues a commit command, and the device access and control gateway migrates the policy package to the main running area; if the result is negative, the process engine issues a rollback command, and the transaction ends. In 180 policy switching samples, the success rate of the published transaction was 100%, the median preparation phase duration was 0.62s, and the median commit phase duration was 0.41s.

[0146] Regarding rollback transactions, the process engine employs a two-phase mechanism. Triggering conditions include critical metric exceeding limits, simulation mismatch, or time synchronization anomalies. The rollback request includes the strategy package version number of the target rollback version and the corresponding segment summary index. The process engine first locks relevant nodes and data segments during the preparation phase, and after confirming consistency, completes the rollback and records the rollback reason and impact scope during the commit phase. Statistics show that the median completion time for rollback transactions is 0.88 seconds, and the 95th percentile is 1.43 seconds.

[0147] In terms of auditing and traceability, the process engine generates traceability identifiers for each critical operation. The process instance identifier, node identifier, signature digest, policy package version number, segment digest index, millisecond-level timestamp, and session sequence number range are written into the time series data management module. It is linked to the query entry of the visual monitoring terminal, allowing filtering by stage, time window, or version. Statistical analysis of a sample of 15 days of operation and 180 policy switches showed that the median return time for traceable queries was 52ms.

[0148] Regarding interfaces with other modules, the process engine establishes clear agreements with five modules. For the project modeling subsystem, it acquires the stage dictionary, stage state machine, and unified resource identifier encoding mapping to generate process templates and node achievement conditions. For the rules and scheduling engine, it acquires the strategy package, strategy package version number, and manifest summary, and transmits the transaction status during deployment or rollback. For the digital twin engine, it acquires the simulation verification summary and requests multi-scenario simulation results for node verification when needed. For the device access and control gateway, it sends two-stage deployment and rollback commands and receives playback consistency indicators and session health information. For the time-series data management module, it writes and queries segment summary indexes, consistency judgment results, and audit records. All interface message bodies contain stage code segments, strategy package version numbers, and millisecond-level timestamps, and carry session sequence numbers to ensure sequential consistency.

[0149] In terms of phased collaboration, the process engine assumes different responsibilities in seven phases. In the solution phase, it establishes templates for project initiation and solution review processes, limiting them to only data-related nodes and site survey nodes, without triggering release transactions. In the design phase, it introduces design joint review nodes and simulation baseline confirmation nodes, enabling multi-role parallel signing and approval services. In the construction phase, it focuses on equipment arrival acceptance, installation point verification, and wiring inspection, with node outputs automatically backfilling with site photos and point scanning results. In the commissioning phase, it primarily uses shadow playback and simulation consistency verification, adding session health checks between nodes. In the operation phase, it provides processes for plan changes, strategy switching, and minor modifications, supporting windowed statistical backfilling. In the modification phase, it introduces difference list verification and partial playback verification nodes. In the archiving phase, it freezes process instances and related evidence, binding them to model snapshots.

[0150] Regarding anomalies and boundary conditions, the workflow engine defines five processing paths. The first is approval timeout: if a node is not completed within the approval time limit, the system triggers a reminder and transfers the node to an escalation path. The second is missing evidence: the system blocks the node's completion and marks the fields as required in the form and evidence collector. The third is signature verification failure: the system terminates the current approval and requires re-signing. The fourth is consistency determination failure: the system does not proceed to release but instead enters a debugging or data supplementation branch. The fifth is transaction interruption: if a two-phase commit is abnormally interrupted during the commit phase, the system determines whether compensation is needed based on the transaction receipt from the device access and control gateway. All of the above situations generate entries in the audit and traceability logger.

[0151] Regarding implementation examples and test data, two representative scenarios were selected for quantification. In a medium-scale scenario, the process template contains 18 nodes, including 6 parallel branches, with an average single-instance completion time of 3.9 hours; after enabling signature and approval services, compliance template verifiers, and two-phase release, Median 98.6%, Median 1.1%, The median success rate was 0.3%. Under heavy load scenarios covering 15 days, 12 time periods per day, and 180 strategy switches, the success rate of the published transaction was 100%. The median total time from node achievement to publication completion was 1.6 seconds, the median total time of the rollback transaction was 0.88 seconds, and the median time of the trace query was 52 ms.

[0152] It should be noted that the process engine described in this embodiment also includes the following implementable methods: First, a rule-based adaptive upgrade strategy that sets dynamic approval time limits for high-risk nodes and automatically tightens them when fluctuations in key indicators are detected. It also elevates the approval level. Second, the evidence-credible timestamp service generates credible timestamps for on-site photos, videos, and documents and stores them in an append-only audit database, improving the reliability of evidence. Third, process fragment reuse and versioning allows common acceptance or joint evaluation fragments to be packaged into reusable units and bound to stage code segments and strategy package version numbers. When reused, the current instance is automatically added and version information is inherited.

[0153] In terms of deployment and operation, the process engine supports both monolithic and distributed modes. Monolithic mode is suitable for small to medium-sized projects, where all components run on the same host. In distributed mode, the signature and approval services and the release transaction coordinator can be horizontally scaled, while the process definition manager and audit and trace recorder run as centralized services. In typical scenarios, the median time for single-node approval verification is 0.18 seconds, the median time for the three types of compliance checks is 0.27 seconds, and the median total time for two-stage release is 1.03 seconds. During peak periods, elastic scaling can maintain these latency levels within 2 seconds. To ensure time consistency, all writes and events in the process engine are recorded with millisecond-level timestamps and bound to session sequence numbers, with periodic corrections performed across nodes using a unified time base.

[0154] In summary, the process engine uses process templates, signatures and approvals, compliance template verification, and two-stage transactions as its core mechanisms. It organically links stage events, evidence, and policy releases into executable, verifiable, and traceable process instances. Under the set sample and load conditions, its pass rate, latency, and consistency indicators meet the requirements for continuous operation. Furthermore, it can further improve the operability and maintainability in complex exhibition scenarios through adaptive upgrades, trusted timestamps, and process fragment reuse.

[0155] This embodiment will describe the communication interface adapter in detail. The communication interface adapter is used to achieve protocol interoperability, time consistency, sequence consistency, and version consistency in communication orchestration between the control domain and information domain of the exhibition hall project. It interfaces downwards with the southbound session of the device access and control gateway, and upwards with the digital twin engine, time-series data management module, rule and scheduling engine, process engine, and visualization monitoring terminal. It also provides two-phase commit transaction support during policy deployment and rollback. The communication interface adapter consists of a southbound protocol bridge, a northbound data adapter, a session and time manager, an identifier mapping and model binding manager, a batch and digest orchestrator, and a secure access controller. For ease of expression, identifiers are introduced only in the formulas and each is individually defined: the session sequence number is denoted as Sn, and the unified time base is denoted as... End-to-end delay is recorded as Encoding processing delay is denoted as Network transmission delay is denoted as The processing queue delay is denoted as Time synchronization deviation is denoted as Batch summary is recorded as The segment summary index is denoted as (Following the previous definition), the strategy package version number is denoted as... (Following the previous definition), the mapping function from model element identifiers to external model identifiers is denoted as... The preparation and submission phases of a transaction are respectively denoted as... and .

[0156] The Southbound Protocol Bridge is responsible for establishing and maintaining sessions with OPC UA, BACnet / IP, and Modbus / TCP, performing device discovery, object browsing, point read / write, and alarm subscription, and appending a session sequence number and a unified time base anchor point to each southbound session. The Southbound Protocol Bridge synchronizes with the unified time base upon session establishment, with time synchronization deviations set to a minimum. This indicates that the system is maintaining... The target is ≤2ms. If the duration exceeds 5ms for more than 10s, the session will be placed in a state of pending calibration and the frequency will be reduced until realignment is achieved (see [reference]). Figure 3 (As shown). To ensure sequence consistency and replay feasibility, the southbound protocol bridge includes a session sequence number for each frame read / write operation and writes the sequence range into the batch metadata. In a sample containing 10 field devices, 320 locations, and 20 repeated deployments, after enabling session sequence numbers and a unified time base, the proportion of location write rejection events related to time drift decreased from 1.2% to 0%, the proportion related to sequence uncertainty decreased from 1.6% to 0.1%, and the average positioning time decreased from 24 minutes to 7 minutes.

[0157] The northbound data adapter is responsible for publishing data and control-related metadata to the digital twin engine and time-series data management module, and pushing status notifications to the rules and scheduling engine and the visualization monitoring terminal. The northbound data adapter employs a batch-based publishing strategy. Each batch includes a batch number, policy package version number, start and end timestamps, session sequence number range, number of records, and a batch summary. The batch summary is denoted as... (Record set) The selected hash algorithm. The end-to-end delay composition of the batch can be expressed as: By collecting statistics at the encoding, network, and queuing stages, the northbound data adapter continuously optimizes batch size and concurrency during runtime. In a sample of 15 days and 180 policy switches, the northbound data adapter achieved a 100% batch release success rate, a median end-to-end latency of 31ms, a 95th percentile latency of 55ms, and all short-term failures were resolved through retries within 30 seconds (see [reference]). Figure 2 (As shown).

[0158] The Session and Time Manager ensures time and sequence consistency on two levels. First, in the southbound direction, the Session and Time Manager marks each frame of data with a millisecond-level timestamp and session sequence number, and resets the session sequence number and marks the batch for resuming interrupted transmissions when the session reconnects. Second, in the northbound direction, the Session and Time Manager generates a time coverage declaration for each batch and verifies whether there are out-of-bounds writes across stages or versions. When a mixed batch that spans different stage code segments or policy package version numbers is detected, the system splits it into multiple atomic batches to maintain consistency. To facilitate cross-module verification, the Session and Time Manager records a unified time reference anchor and session health summary in the batch metadata, which the workflow engine can read during the preparation phase of release or rollback.

[0159] The Identifier Mapping and Model Binding Manager is used to establish a one-to-one mapping between object identifiers from external systems and model element identifiers in the digital twin engine during the policy deployment process. External systems include project management systems, building information modeling systems, and document management systems. Communication interface adapters obtain external object identifiers via REST or MQTT and perform matching and verification according to the unified resource identifier code provided by the project modeling subsystem. The mapping function is denoted as... ,in Identify model elements. External model identifiers are used. To ensure mapping stability, the identifier mapping and model binding manager calculates a summary for each mapping change and writes it to the version metadata. Simultaneously, the segment summary index related to that version is recorded in the time-series data management module for subsequent consistency comparisons. In a sample containing 1,200 model elements and 8,500 external object identifiers, the initial matching rate of automatic mapping was 97.4%, reaching 100% after one manual confirmation. The average verification time for subsequent version changes was 0.6 seconds.

[0160] The batch and digest orchestrator is responsible for constructing and validating batch digests, segment digest indices, and version bindings. For data written to the time-series data management module, the batch and digest orchestrator reads the segment digest index and performs binding verification after the batch is written to disk. The verification function is the same as the one used in the previous step. The judgment rule is that the check is passed only if the segment digest index and the policy package version number are consistent; otherwise, it is failed and a rollback is triggered. For real-time comparison provided to the visualization monitoring terminal, the batch and digest orchestrator aggregates the batch digest, segment digest index, and signature digest into a one-time verification package, reducing the number of multiple queries on the terminal side. In the 50-hour debugging sample, the batch and digest orchestrator passed the verification of all 5 sets of policy templates, with a median verification time of 0.21 seconds (see [reference]). Figure 6 (As shown).

[0161] The secure access controller provides triple protection at the communication layer: minimal exposure, whitelisting, and token verification. Minimal exposure means opening only necessary protocol ports; the whitelist is configured according to the authorized addresses of upstream and downstream modules; and token verification is used to authenticate REST and MQTT sessions. Before policy deployment or rollback, the secure access controller checks the integrity of the deployment chain, including whether the policy package version number, signature digest, segment digest index, session health digest, and batch digest are complete. For requests from unauthorized sources or high-frequency writes within sensitive windows, the system will reject them and log the access event. In a 15-day operational sample, all abnormal accesses intercepted by the secure access controller were rejected without affecting the normal deployment chain.

[0162] The communication interface adapter performs a two-phase commit during policy deployment and rollback. Preparation phase. In the process, the communication interface adapter and device access and control gateway, timing data management module and digital twin engine undergo consistency verification: reading the simulation verification summary, reading the segment summary index and calling the consistency judgment function, checking session health and time synchronization deviation, and returning to the "can be submitted" status after all passes; submission stage In the process, the communication interface adapter writes a release tag and triggers the device access and control gateway to migrate the policy package to the main operating area. Simultaneously, it batches the release events, including the policy package version number, session sequence number range, and time coverage declaration. In a sample of 180 policy switches, the success rate of the two-phase commit was 100%, the median duration of the preparation phase was 0.62 seconds, the median duration of the commit phase was 0.41 seconds, and the median arrival time of the first control command after release was 36 ms.

[0163] Regarding anomalies and boundary conditions, the communication interface adapter defines five types of processing paths. First, time drift anomaly: when time synchronization deviation... When the threshold is exceeded, the southbound protocol bridge reduces the writing frequency and initiates synchronization. If it does not recover within 10 seconds, the session is listed as pending calibration and writing is blocked, only reading is allowed. Second, sequence disruption anomaly: When the session sequence number rolls back or jumps, the batch and digest orchestrator marks the batch as a breakpoint resume and generates a completion request on the northbound data adapter side. Third, cross-version mixed writing anomaly: When two or more policy package version numbers appear in a batch, the batch is split and each is bound to the corresponding segment digest index, and cross-version merging is not allowed. Fourth, missing external identifier mapping: When If no matching external model identifier is found, the communication interface adapter temporarily stores the mapping and sends a completion request to the project modeling subsystem. Release is allowed to continue if there are no external dependencies. If the mapping is a prerequisite for interlocking or security constraints, release is blocked. Fifth, network congestion anomalies: When end-to-end latency exceeds 100ms for three consecutive times, the northbound data adapter reduces batch size and concurrency, and switches to a latency-tolerant queue if necessary to avoid backlog. In the above scenarios, all anomalies are recorded in the operation log, including millisecond-level timestamps and session sequence number ranges, facilitating cross-module location.

[0164] Regarding interfaces with other modules, the communication interface adapter uses structured message bodies for input and output. For device access and control gateways, the communication interface adapter provides southbound read / write request forwarding, session health queries, and transaction command publishing; for the digital twin engine, it provides a channel for transmitting simulation playback scripts and an interface for retrieving simulation verification summaries; for the time-series data management module, it provides batch writing, segment summary index retrieval, and consistency judgment queries; for the rules and scheduling engine, it provides query interfaces for policy package version numbers, batch summaries, and session ranges, and receives trigger commands for publishing or rolling back; for the process engine, it provides two-phase commit preparation and commit receipts, including preparation results, commit results, and audit information. All interfaces carry stage code segments, policy package version numbers, millisecond-level timestamps, and session sequence numbers in the message header to ensure time and sequence consistency across systems.

[0165] Regarding implementation examples and test data, the communication interface adapter underwent quantitative evaluation in two representative scenarios. The medium-scale scenario included 10 exhibits, 32 control loops, and 196 monitoring points. During 50 hours of operation, the end-to-end latency was... The median time was 29ms, the 95th percentile was 51ms, the average batch size was 4.2MB, the median time for consistency checking was 0.21s, and the percentage of batches detected and split due to cross-version mixed writing was 0.06%, all of which were fixed within one resend (see [reference]). Figure 2 (As shown). Under heavy load scenarios covering 15 days and 180 policy switches, the two-phase commit success rate was 100%, the total median time for the preparation and commit phases was 1.03 seconds, and time drift anomalies were automatically calibrated 14 times without causing release failures.

[0166] It should be noted that the communication interface adapter described in this embodiment also includes the following implementation methods: First, differential batch digest: Differential digests of adjacent batches are generated in addition to the batch digests, and digests are only performed on newly added records, which can reduce overhead in consistency comparisons on the visual monitoring terminal. Second, cross-site cascading: When deployed in multiple exhibition areas or venues, the communication interface adapter can aggregate batches and digests of lower-level nodes at the upper-level node and perform cross-site consistency verification under a unified time base across the entire domain. Third, southbound protocol adaptive detection: Online detection and dynamic adjustment of parameters (such as maximum frame, read / write batch, and timeout) of OPC UA, BACnet / IP, and Modbus / TCP are performed to automatically maintain the end-to-end latency target when network conditions change.

[0167] In terms of deployment and operation, the communication interface adapter supports both monolithic and distributed modes. Monolithic mode is suitable for small to medium-sized scenarios, where the southbound protocol bridge, northbound data adapter, session and time manager, and security access controller run on the same host. In distributed mode, the southbound protocol bridge and session and time manager are deployed close to the field network, the northbound data adapter and batch and digest orchestrator are deployed in the information domain, and the identity mapping and model binding manager and security access controller run as centralized services. In typical scenarios, session establishment is completed within 100ms to 300ms, batch rolling and digest calculation are completed within 100ms to 300ms, and two-phase publishing is completed within 1 second to 5 seconds. During peak periods, these latency targets can be maintained by adjusting batch size, concurrency, and cache level. To ensure time consistency, the communication interface adapter attaches millisecond-level timestamps and session sequence numbers to all outputs and performs periodic corrections using a unified time base.

[0168] In summary, the communication interface adapter constructs a robust communication layer covering north-south data and control flows through collaborative mechanisms such as southbound protocol bridges, northbound data adapters, session and time management, identifier mapping and model binding, batch and digest orchestration, and secure access control. It ensures transaction consistency through two-phase commit in policy deployment and rollback, and keeps end-to-end latency, batch success rate, and consistency verification latency within expected ranges under given sample and load conditions. This enables cross-module interactions throughout the entire lifecycle of the exhibition hall project to have an executable, verifiable, and traceable implementation path.

[0169] This embodiment will describe the security isolation unit in detail. The security isolation unit provides minimum exposure, mandatory boundary, and trusted auditing security isolation and access control capabilities between the information network and control network of the exhibition hall project, ensuring that the release and rollback of policy packages, data collection, and status notifications meet protocol constraints, time constraints, and version constraints during cross-domain transmission. The security isolation unit works collaboratively with the device access and control gateway, communication interface adapter, rule and scheduling engine, digital twin engine, process engine, and time-series data management module to form a closed loop throughout its lifecycle: "only allowing necessary channels, only allowing compliant payloads, and only releasing after verification." For ease of expression, identifiers are introduced and defined individually only in the formulas: the isolation domain identifier is denoted as... One-way gateway is denoted as Two-way application proxy record The session sequence number is recorded as A unified time base is denoted as Additional delay is recorded as Packet loss rate is denoted as Security level is denoted as Trusted root certificate fingerprint recording The signature digest is denoted as Sig, and the policy package version number is denoted as (Following the previous definition), the segment summary index is denoted as (Following the previous definition), the consistency determination function is denoted as... (Using the aforementioned definition).

[0170] The security isolation unit's architecture consists of four layers: the physical and link isolation layer, the transport and session isolation layer, the application and content isolation layer, and the audit and policy orchestration layer. The physical and link isolation layer uses unidirectional gateways and controlled fiber optic / electrical ports to achieve the basic boundary of complete unidirectional uplink and downlink data blocking. The transport and session isolation layer, centered on protocol whitelists, session termination / reconstruction, and mandatory session sequence numbers, ensures that cross-domain communication does not involve pass-through. The application and content isolation layer, using bidirectional application proxies, content disassembly and reassembly, data anonymization / declassification, and format whitelists, only allows structured, verifiable payloads related to the phase model to pass through. The audit and policy orchestration layer, centered on immutable append-only storage, dual-person review of changes, and phase-based effectiveness control, records every release decision and cross-domain data summary for traceability by the process engine and visual monitoring terminal.

[0171] Regarding physical and link isolation, the security isolation unit employs a unidirectional gateway in the direction from the information network to the control network, allowing only log, statistical, and aggregated read-only monitoring data to ascend. In the direction from the control network to the information network, it blocks access by default; control commands and policy packets required for issuing and rolling back can only be allowed through a controlled bidirectional application agent after auditing. The unidirectional gateway has a built-in clock and cache to ensure no backflow or reverse channels occur under short-term link jitter. Based on a sample of 10 field devices and 320 points, the additional latency introduced by the unidirectional gateway... The median latency was 0.8ms, the 95th percentile was 1.4ms, and the packet loss rate was... The median is 0%, and all occasional packet loss is recovered within 30 seconds through retransmission buffering.

[0172] Regarding transmission and session isolation, the security isolation unit whitelists the allowed protocol set, allowing only a limited subset of OPC UA, BACnet / IP, and Modbus / TCP, as well as uplink sessions for HTTPS / HTTP / 2 and MQTT, by default. All sessions are terminated at the security isolation unit and rebuilt on the other side, disallowing end-to-end pass-through. Each cross-domain message is mandatory to include a session sequence number and a millisecond-level timestamp, and the sequence monotonicity and temporal continuity are verified during reconstruction. The session establishment process uses two-way authentication, and the client certificate chain on the network side must be anchored to the trusted root certificate fingerprint. Below. For ease of quantitative evaluation, the additional session establishment latency is between 100ms and 300ms, and the median of the reconstructed end-to-end additional latency is 2.7ms, with the 95th percentile being 5.1ms.

[0173] Regarding application and content isolation, the security isolation unit handles cross-domain payloads using a "parsing-verification-re-encapsulation-allowing" process. During the parsing phase, the message is fully parsed at the application layer according to the protocol type, extracting key fields such as the policy packet version number, segment digest index, signature digest, Uniform Resource Identifier (URI), and stage code segment. The verification phase performs three types of checks: protocol / format check, content consistency check, and version consistency check. The version consistency check uses a consistency determination function. Finish, If the request continues, it will be rejected; otherwise, it will be rejected. During the re-encapsulation phase, the message body and security header are regenerated according to the target side's agreement, and the session sequence number and timestamp are reset. During the release phase, the message is forwarded on whitelisted ports, and a message digest is recorded to the audit and policy orchestration layer. For file-type payloads (such as templates and snapshots), the security isolation unit enables content decomposition and reassembly, removing active content and high-risk objects, retaining only structured fields and verification information. Based on a 50-hour comprehensive debugging sample, the average overhead of application and content isolation processing is 0.21 seconds, including 0.06 seconds for parsing, 0.09 seconds for verification, and 0.06 seconds for re-encapsulation.

[0174] Regarding authentication and authorization, the security isolation unit requires cross-domain access to simultaneously meet three conditions: certificate authentication, token authorization, and role-based permission mapping. Certificate authentication employs bidirectional transport layer security and certificate revocation checks; token authorization uses short-lived access tokens and is linked to the approval status of the workflow engine; role-based permission mapping achieves precise authorization down to the device / location level based on the principle of least privilege. Write permissions for the corresponding role are only enabled within a limited time window when the workflow engine confirms successful signature verification and approval takes effect. The default time window is 5 minutes, which can be adjusted according to node configuration. Statistical samples show that the unauthorized write request interception rate is 100%, and the false interception rate is 0%.

[0175] In the deployment and rollback process, the security isolation unit acts as a security gating mechanism for cross-domain transactions. During the preparation phase, the security isolation unit receives policy packets, policy packet version numbers, and signature digests from the rules and scheduling engine, obtains segment digest indexes from the time-series data management module, and obtains session health digests and time synchronization deviations from the communication interface adapter. When all conditions are met, a "committable" receipt is generated and written to the audit. During the commit phase, control commands are only allowed within the validity period of the committable receipt and delivered to the device access and control gateway in session order. The median total additional latency for the two-phase commit is 0.41 seconds, with a 95th percentile of 0.73 seconds; in 180 policy switching samples, the deployment and rollback success rate was 100%.

[0176] In terms of strategy and level management, the security isolation unit sets security levels for different stages and scenarios. Example: During normal operation. Only status updates and a limited number of approved parameter adjustments are allowed during the debugging phase. 1. Allow the shadow running area to replay relevant channels; during the modification phase. By default, writing is disabled; playback and partial verification only occur within windows explicitly permitted by the workflow engine. Formally, a stage-level mapping function can be defined. ,in, This includes factors such as passenger flow levels, nighttime maintenance windows, and session health. All security level changes are triggered by the process engine and written into the audit log.

[0177] In terms of auditing and policy orchestration, the security isolation unit generates an audit entry for each cross-domain message. Each entry includes the isolation domain identifier, message direction, protocol type, policy packet version number, segment digest index, session sequence number range, millisecond-level timestamp, and message digest. Audit entries are written to an append-only structure and periodically archived to immutable storage. To improve retrieval efficiency, the security isolation unit creates a composite index based on time and version for audit entries; the median return time for common queries (by time window, by version, by direction) is 52ms.

[0178] Regarding anomalies and boundary conditions, the security isolation unit defines seven processing paths. First, time synchronization anomalies: when the time synchronization deviation exceeds a threshold, cross-domain writes are rejected, only uplink reads are retained, and a calibration request is issued. Second, session anomalies: when a session sequence number rollback or sudden increase is detected, the batch is marked as a breakpoint resume and replay is requested from the other side. Third, cross-version mixed writes: when two or more policy package version numbers appear in a batch, it is split and checked one by one. Fourth, content violations: when the payload contains undeclared fields or blacklisted fields, it is rejected and a violation report is generated. Fifth, certificate and token anomalies: when a certificate is revoked or a token expires, it is immediately blocked and the event is recorded. Sixth, policy change not reviewed: any cross-domain policy change requires double review; changes that have not been reviewed are not effective. Seventh, link congestion: when the end-to-end additional latency exceeds 100ms for three consecutive times, it enters a load reduction mode, reducing the batch size and concurrency, prioritizing approval and release transactions. All of the above situations generate entries at the audit and policy orchestration layer for querying by the process engine and visual monitoring terminal.

[0179] Regarding interfaces with other modules, the security isolation unit uses structured message bodies for input and output. For communication interface adapters, it provides interfaces for whitelist maintenance, session health query, and batch verification; for device access and control gateways, it provides controlled forwarding of allow control commands and playback commands; for the rules and scheduling engine, it provides receipts for policy package version numbers and signature digest verification; for the process engine, it provides preparation / submission receipts for two-phase commits and interfaces for security level switching; and for the time-series data management module, it writes audit entries and reads segment digest indexes for comparison. All interface message headers carry stage code segments, policy package version numbers, millisecond-level timestamps, and session sequence numbers to ensure time and sequence consistency.

[0180] Regarding implementation examples and test data, two representative scenarios were constructed for quantitative evaluation. In a medium-scale scenario (10 exhibits, 32 control loops, 196 monitoring points, 50 consecutive hours), unauthorized cross-domain writes were all blocked, the median additional latency was 2.7ms, the median packet loss rate was 0%, and the average time for consistency verification was 0.21s. In a high-load scenario (15 days, 12 time slots per day, 180 policy switches), the release and rollback success rate was 100%, and time synchronization anomalies were automatically calibrated 14 times without causing release failures; the proportion of batches where cross-version mixed writes were automatically split was 0.06%, and all were repaired within one replay.

[0181] It should be noted that the security isolation unit also includes the following three implementable methods: First, fine-grained data leakage protection: At the application and content isolation layer, pattern constraints and sensitive word checks are performed on structured fields, and field-level anonymization is performed on externally exported data. Second, trusted timestamps and evidence storage: Trusted timestamps are generated for critical messages published and rolled back across domains and stored together with audit entries to improve the reliability of evidence collection. Third, partitioning and tenant isolation: In multi-exhibition-zone or multi-tenant scenarios, policies and whitelists are divided based on isolation domain identifiers to achieve zero interference across projects.

[0182] In terms of deployment and operation, the security isolation unit supports both monolithic and distributed modes. In monolithic mode, the unidirectional gateway, bidirectional application proxy, and auditing and policy orchestration run on the same host, suitable for small to medium-sized exhibition halls. In distributed mode, the unidirectional gateway is deployed close to the control network, while the bidirectional application proxy, auditing, and policy orchestration are centrally deployed in the information domain, coordinating through a unified time base and message queues. In typical scenarios, session establishment is completed within 100ms to 300ms, application and content isolation processing is completed in approximately 0.21s, and two-phase deployment is completed within 1s to 5s. To ensure time consistency, all cross-domain messages are accompanied by millisecond-level timestamps and session sequence numbers, and the system performs periodic corrections based on a unified time base.

[0183] In summary, the security isolation unit achieves controlled access to cross-domain communication through four layers of collaboration: physical / link isolation, session / transmission isolation, application / content isolation, and audit / policy orchestration. During policy release and rollback, it uses two-phase transaction and version consistency verification as thresholds. Under given sample and load conditions, additional metrics such as latency, interception rate, and consistency verification meet continuous operation requirements. Furthermore, it can enable extensions such as data leakage protection, trusted timestamps, and partition isolation as needed to adapt to higher levels of security requirements.

[0184] This embodiment will describe the visual monitoring terminal in detail. The visual monitoring terminal is used to uniformly display, interact with, and release control the model view of the digital twin engine, the real-time and historical data of the time-series data management module, the policy package status of the rule and scheduling engine, the process instance status of the process engine, and the session health information of the device access and control gateway during the scheme, design, construction, debugging, operation, renovation, and archiving phases of the exhibition hall project. The visual monitoring terminal also serves as the consistency comparison entry point and the human-machine authorization link for release / rollback, ensuring that version, time, and data verification are completed before issuing control actions. For ease of expression, identifiers are only introduced and defined in the formulas: the user session identifier is denoted as... Visual scene identifiers The rendering refresh cycle is denoted as End-to-end interaction latency is recorded as The segment summary index is denoted as (Following the previous definition), the strategy package version number is denoted as... (Following the previous definition), the consistency determination function is denoted as... (Following the previous definition), the license determination function is denoted as Or 0, the sampling window of the instrument component is denoted as (seconds), alarm compression ratio is recorded as (Ratio of number of records before compression to number of records after compression)

[0185] In terms of architecture, the visual monitoring terminal consists of a view orchestrator, a data subscription and caching layer, a model rendering engine, an interaction and command panel, a verification and release panel, an audit and playback panel, and an adaptation layer. The view orchestrator generates page layouts and interactive flows based on the phase dictionary and available view templates from the project modeling subsystem; the data subscription and caching layer establishes batch subscriptions with the time-series data management module, maintaining the hot data area cache and the index of the most recently written batches; the model rendering engine interfaces with the digital twin engine, supporting multi-resolution rendering from the thumbnail layer to the detail layer, and rendering the comparison trajectory between the shadow running area and the main running area when needed; the interaction and command panel carries query, filtering, interlock status display, and policy loading / publishing / rollback controls; the verification and release panel initiates consistency judgments, signature verification, and session health checks, activating control controls upon successful completion; the audit and playback panel replays, compares, and exports historical batches by time window or version; and the adaptation layer interfaces with the communication interface adapter, rule and scheduling engine, process engine, and device access and control gateway.

[0186] In terms of data and view models, the visualization monitoring terminal categorizes data into four types of view objects: model view objects, time-series view objects, process view objects, and release transaction view objects. Model view objects carry the spatial geometry, device location, and status coverage information of the digital twin engine, supporting filtering by device type, display item, region, and stage code segment. Time-series view objects carry curves, tables, and heatmaps of process quantities, status quantities, and event quantities, supporting multi-window side-by-side display and cross-version comparison. Process view objects carry the process instance status, node achievement status, and evidence list of the process engine. Release transaction view objects carry the policy package version number, list summary, signature status, and consistency judgment results. In the view orchestrator, each view object is bound to a visualization scene identifier. This is used to restore the layout across pages or devices.

[0187] In terms of performance and refresh strategy, the visual monitoring terminal operates according to the principle of "stable refresh + event-driven incremental updates". Rendering refresh cycle The default value is 1 second, and event-driven partial refresh is enabled when encountering high-frequency events; end-to-end interaction latency. Defined as the time from user trigger to stable view rendering completion, the median for a medium-sized sample is 86ms, and the 95th percentile is 142ms (see [reference]). Figure 2 (As shown). To reduce the impact of high-frequency alarms on visualization, the terminal compresses alarms of the same type, location, and window, achieving an alarm compression ratio of [missing information]. The median was 3.9, and the available frame rate of the alarm panel remained at 55–60 frames per second during a 50-hour integrated test sample (see [reference]). Figure 8 (As shown).

[0188] Regarding the consistency comparison and release process, the visual monitoring terminal provides an operation sequence of "verification—signature—release". The verification step is initiated by the verification and release panel to determine consistency, calculating... The result; when Upon entering the signature stage, the terminal displays a visually aligned view of the policy package version number, manifest summary, and simulation verification summary, and requires the operator to verify the signature. After successful signature verification, the terminal obtains the approval status from the process engine and the session health and time synchronization deviation from the device access and control gateway and communication interface adapter. If all conditions are met, the release license determination is set. Activate the publishing control, otherwise The sequence was completed in 180 policy switching samples. The average time for consistency determination was 0.21s, the median time for signature verification was 0.18s, and the median total time from verification to activation of the release control was 1.03s.

[0189] In terms of model rendering and comparison, the visualization monitoring terminal supports three comparison modes. First, shadow running area and simulation trajectory comparison: simultaneously rendering the shadow running area playback trajectory and the simulation baseline of the digital twin engine, providing highlighting of difference bands and deviation statistics; second, version comparison: aligning the response curves of the same device or control loop under different strategy package version numbers, with timeline alignment selectable by start time or by event; third, stage comparison: model snapshots of different stage code segments are presented in a split-screen format, supporting comparison of device topology, interlocking relationships, and parameter fields. In a sample of 10 exhibits and 32 control loops, when users performed version comparison with a 1-hour window, the median time for difference band calculation was 37ms, and the 95th percentile was 64ms; in a 15-day, 180-switch sample, the event alignment comparison success rate was 99.6%.

[0190] In terms of interaction and command panel, the visual monitoring terminal oriented its operations towards task-based and auditable processes. Task-based operation is reflected in the automatic generation of task cards for each load, release, and rollback operation, including the operator, target scope, policy package version number, expected impact window, and rollback point. Auditable operation is reflected in the generation of a replay entry point in the audit and replay panel for each operation. This replay entry point is bound to the segment summary index, session sequence number range, and millisecond-level timestamp from the time-series data management module, facilitating subsequent review. In a 50-hour debugging scenario, the median time for task card generation and database storage was 0.12 seconds, and the 95th percentile was 0.19 seconds.

[0191] Regarding data subscription and caching, the visual monitoring terminal employs differentiated strategies for different data types. Process variables are cached using a sliding window, with a window length of [missing information]. The default value is 300s, and it supports switching between 60s, 300s, and 900s. State values ​​are cached using a change-driven approach, and are only refreshed when a state changes. Event values ​​are batched and merged with deduplication tags. Under a medium-scale load of 2,000 inputs per second, the median memory usage on the terminal side is 820MB, the 95th percentile is 940MB, and the median page switching time is 78ms.

[0192] Regarding roles and permissions, the visual monitoring terminal collaborates with the signature and approval services of the workflow engine to achieve fine-grained control with the least privilege. Viewing, querying, exporting, loading, publishing, and rolling back are the six permission dimensions; among them, publishing and rolling back permissions are only activated when the workflow engine approves the application, the signature verification passes, and it is within the authorized time window. The default authorized time window is 5 minutes, which can be extended by configuration based on nodes. In a 15-day running sample, the unauthorized publishing attempt interception rate was 100%, and the false interception rate was 0%.

[0193] Regarding anomalies and boundary conditions, the visual monitoring terminal defines five processing paths. First, time synchronization anomalies: when session health information shows a time synchronization deviation exceeding the threshold, the terminal prominently marks this in the verification and release panel and refuses to release the data. Second, cross-version mixed writing: if the query results show that the same batch contains multiple policy package version numbers, the terminal prompts for splitting and only displays results consistent with a single version. Third, data delays or out-of-order processing: when the proportion of delayed data exceeds a set threshold, the terminal automatically delays partial refresh and marks the delayed interval on the layer. Fourth, rendering resource shortages: when the model rendering frame rate is below the threshold, the terminal switches to simplified rendering mode, retaining only key objects and trajectories. Fifth, network jitter: when end-to-end interaction latency... If the refresh rate exceeds 300ms three times consecutively, the terminal reduces the refresh rate and prompts the user to try again later with a comment. In all the above scenarios, a searchable audit entry is generated and written to the time series data management module.

[0194] Regarding interfaces with other modules, the adaptation layer of the visual monitoring terminal uses structured message bodies to define input and output. For the digital twin engine, the terminal reads model snapshots, simulation baselines, and simulation verification summaries, and requests visual metadata for the shadow runtime playback script. For the time-series data management module, the terminal subscribes to and queries segment summary indexes, batch summaries, and range data, and requests complete segment packaging by version and time window during export. For the rules and scheduling engine, the terminal queries the policy template set, scheduling plan, and policy package version number, and sends user-side parameters for loading and publishing requests. For the process engine, the terminal initiates signature requests, obtains approval status, and sends back operation receipts for release or rollback. For device access and control gateways and communication interface adapters, the terminal retrieves session health, time synchronization deviation, and publishing link receipts. All messages carry stage codes, policy package version numbers, millisecond-level timestamps, and user session identifiers to ensure sequential consistency and audit traceability.

[0195] Regarding implementation examples and test data, a quantitative evaluation was conducted on two representative scenarios. The end-to-end interaction latency was measured in a medium-scale scenario (10 exhibits, 32 control loops, 196 monitoring points, continuous operation for 50 hours). The median time was 86ms, and the 95th percentile was 142ms; the average time for consistency determination was 0.21s, the median time for signature verification was 0.18s, and the median time for page switching was 78ms. Under heavy load scenarios (15 days, 12 time slots per day, 180 policy switches), the verification-signature-release sequence completion rate was 100%, the median total time from verification to release control activation was 1.03s, and the median arrival time of the first control command after a policy switch was 36ms; the event alignment comparison success rate was 99.6%, and the median time for exporting the entire data segment (1-hour window) was 2.3s (see [reference]). Figure 10 (As shown).

[0196] It should be noted that the visualization monitoring terminal in this embodiment also includes the following implementable methods: First, multi-terminal collaboration: establishing a session mirroring and control token transfer mechanism between the large-screen terminal and the mobile terminal to ensure context continuity when the same operator switches between different terminals; Second, computational acceleration: enabling programmable graphics interfaces and off-screen caching in the model rendering engine to accelerate exhibits containing a large number of transparent layers and particle effects, and maintain stable frame rates; Third, intelligent filtering: introducing windowed indicator thresholds in the data subscription and caching layers to automatically highlight deviation ranges and abnormal subsystems, reducing the burden of manual filtering.

[0197] In terms of deployment and maintenance, the visual monitoring terminal supports both large-screen and mobile terminals. Large-screen terminals are suitable for fixed installations and multi-view side-by-side display, while mobile terminals are suitable for maintenance personnel's inspections and on-site confirmation. Terminal-side caching, rendering threads, and data subscription threads are separated to avoid blocking. In network-restricted environments, the terminal switches to read-only mode, displaying only cached models and the most recent batch of data, and prohibiting further operations. In typical scenarios, the rendering refresh cycle... The latency is set to 1 second, and can be adaptively adjusted between 0.5 and 2 seconds depending on the page load. During peak periods, downsampling and layered rendering are used to keep the interaction latency within 200ms. To ensure timing consistency, all release-related interfaces display the real-time values ​​of the policy package version number, segment digest index, and signature status, and a single operable window is limited after verification to reduce accidental operations.

[0198] In summary, the visual monitoring terminal uses view orchestration, data subscription and caching, model rendering, verification and release, and auditing and playback as its core mechanisms. It integrates the information from the digital twin engine, time-series data management module, rule and scheduling engine, process engine, and device access and control gateway into a coherent visual link within the same interface. Under the set sample and load conditions, the operability of interaction latency, comparison latency, and release meets the requirements of continuous operation. Furthermore, it can be extended and adapted to complex display and high-concurrency field environments through multi-terminal collaboration, computing acceleration, and intelligent filtering.

[0199] It should be noted that the intelligent management system for the entire lifecycle of an exhibition hall project provided in this embodiment also includes an asset and exhibit ledger module. This module is used to collect, verify, reconcile, and aggregate the identity, location, lifecycle status, and version binding relationships of assets and exhibits during the planning, design, construction, commissioning, operation, renovation, and archiving phases of the exhibition hall project. The results are written into the digital twin engine model snapshot corresponding to the phase code segment as model attachment attributes, thereby forming a traceable and consistent semantics among the project modeling subsystem, rule and scheduling engine, process engine, equipment access and control gateway, and time-series data management module. For ease of expression, identifiers are only introduced and defined in the formulas: the unique asset identifier is denoted as... The unique identifier of the exhibit Position coordinates The reader session serial number is recorded as follows: Reading and writing success rate is recorded as The misread rate is recorded as The position estimation error is denoted as (meters), batch summary is recorded as The stage code segment is denoted as (Following the previous definition), the strategy package version number is denoted as... (Following the previous definition), the mapping function from model element identifiers to assets / exhibits is denoted as... The consistency determination function is denoted as (Using the aforementioned definition).

[0200] In terms of system architecture, the asset and exhibit ledger module consists of a tag acquisition subsystem, a location and region inference subsystem, a ledger cataloging subsystem, a model binding and version association subsystem, a reconciliation and anomaly handling subsystem, and a northbound service subsystem. The tag acquisition subsystem is responsible for establishing sessions with RFID readers and active positioning base stations, completing tag scanning, session health checks, and batch shaping. The location and region inference subsystem uses a combination of access control antennas, array antennas, or positioning base stations at different stages to infer location coordinates and their respective regions. The ledger cataloging subsystem maintains the master data, lifecycle status, and change history of assets and exhibits. The model binding and version association subsystem maps assets and exhibits one-to-one with model elements of the digital twin engine and establishes bindings with policy package version numbers and model snapshots. The reconciliation and anomaly handling subsystem performs difference reconciliation, blacklist / whitelist verification, and anomaly handling before and after stage switching, entry / exit, and policy release. The northbound service subsystem provides retrieval, comparison, and export interfaces to the project modeling subsystem, process engine, and visual monitoring terminal, and writes batch and segment summary indexes to the time-series data management module.

[0201] In terms of data modeling, the asset and exhibit ledger module maintains three main tables and several auxiliary tables. The asset main table records the unique identifier of the asset, asset category, equipment serial number, supplier and warranty information, region, and current status; the exhibit main table records the unique identifier of the exhibit, exhibit number, exhibition period, borrowing status, and protection level; the mapping relationship table records the model element identifier, asset or exhibit unique identifier, initial binding timestamp, most recent confirmation timestamp, and version binding information. To ensure retrieval efficiency, the primary keys for assets and exhibits use hexadecimal strings with check digits; location coordinates are recorded using triples, while retaining the regional code. All changes are recorded as immutable records in the change history table, with record fields including the values ​​before and after the change, the operator, millisecond-level timestamp, and session sequence number range.

[0202] In terms of tag acquisition and batch shaping, the asset and exhibit ledger modules are configured with different acquisition strategies according to different stages. During the construction and commissioning phases, access control antennas and handheld readers / writers are primarily used, while during the operation phase, fixed array antennas and active positioning base stations are the main methods. Each acquisition session includes a session sequence number and a millisecond-level timestamp, and is sent to the northbound service subsystem in a batch manner. The batch summary is defined as... (Record set), The selected hash algorithm was used. Statistical analysis was conducted on a sample of 10 exhibits, 320 tag locations, and 20 repeated deployments to determine the read / write success rate. The median was 99.7%, and the misread rate was... The median is 0.2%, and all short-term failures are replenished in the failure retry queue within 30 seconds.

[0203] In terms of location and region inference, the asset and exhibit ledger module provides configurable location algorithms for different hardware combinations. The access control antenna scenario uses entry / exit events and region coding as the primary basis; the array antenna scenario uses received signal strength indication plus weighted centroid estimation based on multi-antenna differential; and the active positioning base station scenario uses time difference of arrival and fingerprint database regression fusion. The location estimation error is defined as... In the 50-hour integrated debugging sample, the access control antenna scenario... The median is 0.8, for array antenna scenarios. The median is 0.5, in active positioning base station scenarios. The median was 0.3; the median region inference accuracy for the three scenarios was 98.4%, 99.1%, and 99.6%, respectively (see [reference]). Figure 7 (As shown).

[0204] Regarding model binding and version association, the asset and exhibit ledger module maps each asset and exhibit record to a model element in the digital twin engine. The mapping function is denoted as... ,in The model element is identified. The binding process is conducted under the constraints of the unified resource identification code provided by the project modeling subsystem: when a phase switch event occurs, the asset and exhibit ledger module triggers a full or incremental scan, reads the tags and calculates the location coordinates, and then compares them with the model element identifiers in the digital twin engine. The comparison result is written to the model snapshot corresponding to the phase code segment as a model attachment attribute; at the same time, the binding pair generated by the mapping and the strategy package version number are written to the version association table for consistency verification before and after strategy release. In a sample of 15 days and 180 strategy switches, the median time for model binding confirmation was 0.36s, the 95th percentile was 0.62s, and the median time for consistency query after binding was 48ms.

[0205] In terms of reconciliation and anomaly handling, the asset and exhibit ledger module defines a discrepancy reconciliation process, comparing the consistency of "ledger records - on-site labels - digital twin model snapshots". Discrepancy types include missing, duplicate, misaligned, and out-of-bounds. Missing refers to a bound item existing in the model snapshot but not being read on-site; duplicate refers to the same label being bound to multiple model elements; misaligned refers to a label position inconsistent with the model element area; out-of-bounds refers to a label appearing outside a restricted area. The reconciliation process is aided by blacklists and whitelists: the blacklist includes assets and exhibits in a deactivated, under maintenance, or out-of-stock state, while the whitelist includes temporary exhibits and materials in transit. Anomaly handling rules are as follows: if a missing item is not recovered after one rescan, a work order is entered; if duplicates are immediately locked and a manual confirmation task is generated; if misaligned items are allowed temporary binding migration after approval by the process engine during the modification phase, a work order is generated and related policy releases are blocked during the operation phase; out-of-bounds triggers security linkage and records the event. Statistics show that within the sample range, the occurrence rates of the four types of abnormalities were 0.5%, 0.2%, 0.3%, and 0.1%, respectively, and all of them completed the closed loop within 10 minutes.

[0206] Regarding version consistency and release linkage, the asset and exhibit ledger module provides a verification entry point before strategy release and rollback: it reads the segment summary index and version association table from the time-series data management module to verify whether the asset and exhibit bindings in the current batch are consistent with the target strategy package version number; consistency determination function If the verification is successful, it is considered passed; otherwise, it is rejected and a prompt is made to perform a reconciliation on the visual monitoring terminal. In 180 policy switching samples, the average time for this verification was 0.19 seconds.

[0207] In terms of lifecycle management, the asset and exhibit ledger module maintains a state machine for assets and exhibits. The state set includes: in storage, under construction, on display, under maintenance, borrowed, decommissioned, and archived. Transfer conditions are driven by nodes in the process engine. Each state transfer is bound to a model snapshot and strategy package version number and written to the change history table. During the archiving phase, the asset and exhibit ledger module freezes the master data, mapping relationships, and change history as read-only, for later restoration upon re-integration.

[0208] Regarding interfaces with other modules, the asset and exhibit ledger module uses structured message bodies for input and output. For the project modeling subsystem, it receives phase switching events and unified resource identifier coding constraints, and returns model binding results and discrepancy reconciliation summaries. For the digital twin engine, it writes model attachment attributes and location snapshots, and reads model element identifiers and snapshot identifiers. For the process engine, it returns reconciliation pass / fail verification results and work order information, and receives approval status to drive temporary binding migrations. For the rules and scheduling engine, it provides consistency verification results before policy release. For the time-series data management module, it writes batch and segment summary indexes for comparison by the visualization monitoring terminal. For the communication interface adapter and device access and control gateway, it reads session health and time synchronization information to ensure that the collection batch time is aligned with the control batch time. All messages carry phase code segments, policy package version numbers, and millisecond-level timestamps, and the reader / writer session sequence number is included in the collection batch.

[0209] Regarding implementation examples and test data, two representative scenarios were constructed for quantitative evaluation. Under a medium-scale scenario (10 exhibits, 320 tag points, 50 consecutive hours), the read / write success rate was... The median was 99.7%, and the misread rate was... The median is 0.2%, and the location estimation error is... The median time was 0.5, the median time to complete discrepancy reconciliation was 0.44s, and the median time to close the loop on anomalies was 6 minutes. Under heavy load scenarios (15 days, 12 time slots per day, 180 strategy switches), there were 180 full scans triggered by phase switching, the median time for model binding confirmation was 0.36s, the average time for consistency verification was 0.19s, and the number of times the release was blocked by asset and exhibit anomalies was 0.

[0210] It should be noted that the asset and exhibit ledger module described in this embodiment also includes the following optional implementation methods: First, visual-assisted recognition: In areas with weak or severely obstructed reader signals, visual recognition is introduced as an auxiliary signal source, and the object identification and tag readings of the visual recognition are fused in a multimodal manner to improve the stability of positioning and recognition. Second, differential list generation: A differential list is automatically generated between the renovation phase and the operation phase, listing only newly added, decommissioned, and relocated asset and exhibit items, facilitating rapid approval by the workflow engine. Third, loan link integration: An interface is established with the external loan management system to automatically synchronize loan status and return plans, and trigger a positioning and reconciliation upon return to reduce the risk of omission.

[0211] In terms of deployment and operation, the asset and exhibit ledger module supports both monolithic and distributed modes. In monolithic mode, the tag acquisition subsystem, the location and region inference subsystem, and the ledger cataloging subsystem run on the same host, suitable for small to medium-sized exhibition halls. In distributed mode, the tag acquisition subsystem and the location and region inference subsystem are deployed close to the site, while the ledger cataloging subsystem and the model binding and version association subsystem are centrally deployed. Batch and summary data are aggregated via a communication interface adapter. In typical scenarios, batch shaping and summary calculation are completed within 100–300ms, model binding is written within 100–300ms, and reconciliation and verification are completed within 0.2–0.6s. During peak periods, these latency metrics can be maintained by expanding acquisition channels and parallelizing reconciliation. To ensure time consistency, each acquisition batch and model binding operation is accompanied by a millisecond-level timestamp and session sequence number, and periodically corrected using a unified time base.

[0212] In summary, the asset and exhibit ledger module, through collaborative mechanisms such as tag collection, location and region inference, ledger cataloging, model binding and version association, and reconciliation and anomaly handling, enables assets and exhibits to achieve identifiable identity, locatable location, traceable status, and verifiable version within seven stages. Under the set sample and load conditions, indicators such as read / write success rate, location error, consistency verification, and anomaly closure meet the requirements for continuous operation. Furthermore, it can be extended and adapted to complex exhibitions and high-traffic scenarios through visual-assisted recognition, differential lists, and borrowing links.

[0213] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A smart management system for the entire lifecycle of an exhibition hall project, characterized in that, include: The project modeling subsystem is used to build a phase model of the exhibition hall project. The phase model includes the scheme phase, design phase, construction phase, commissioning phase, operation phase, renovation phase and archiving phase. The device access and control gateway is used to connect the PLC, distributed I / O, sensors and actuators in the exhibition hall to the system. A digital twin engine is used to maintain digital models of exhibition space and equipment and establish a one-to-one mapping relationship with on-site control points; The time-series data management module is used to collect and store data from the device access and control gateway, including process quantities, status quantities and event quantities; The rules and scheduling engine is used to generate control instructions and scheduling instructions based on the stage model, the digital twin engine and the time series data management module, and send them to the device access and control gateway. The process engine is used to manage the tasks, inspections and acceptance records generated during construction, commissioning and operation and maintenance in a process-oriented manner, and to establish a version association with the policy package generated by the rules and scheduling engine. A communication interface adapter for providing at least one of OPCUA, BACnet / IP, and Modbus / TCP industrial communication between the device access and control gateway and the digital twin engine; A security isolation unit is used to provide one-way or two-way access control and auditing between an information network and a control network; A visual monitoring terminal is used to display the model view of the digital twin engine and the real-time and historical data of the time-series data management module, and to provide control over the loading and publishing of the rules and scheduling engine strategies. The rules and scheduling engine is configured to generate program control instructions for the PLC and interlocking instructions for the actuator after verification through the simulation channel of the digital twin engine. The project modeling subsystem includes a unified resource identification coding module. The unified resource identification coding consists of a project identification segment, a stage code segment, a device class code segment, and a control point sequence number segment. The unified resource identification coding is fixed in the process engine using the stage code segment and the strategy package version number. The rule and scheduling engine parses the unified resource identification coding when generating the strategy package to determine the list of control points in the strategy package. The digital twin engine includes a model-control point mapping table, which records the one-to-one correspondence between model element identifiers, field I / O address fields, PLC variable names and control channel numbers. When the strategy is released, the communication interface adapter performs type checks, address field out-of-bounds checks and mutual exclusion checks based on the mapping table, and generates a consistency verification record corresponding to the version number of the strategy package. The rules and scheduling engine includes a policy template library and a scheduling plan library. The templates in the policy template library are indexed by working condition tags and equipment types, and the plans in the scheduling plan library are indexed by stage codes and policy package version numbers. When the rules and scheduling engine receives a stage switching trigger from the process engine, it selects the scheduling plan according to the stage code and combines it with the policy template in a parameterized manner to generate a policy package carrying a version list and a list summary. The time-series data management module adopts an append-only storage structure and performs database sharding and table partitioning for process quantities, state quantities, and event quantities. The append-only storage structure organizes segment files based on a log structure merge tree. The writing order is determined by a combination key of the stage code, timestamp, and the unified resource identifier code. The time-series data management module generates a segment digest index corresponding to the policy package version number for each written segment. The time-series data management module binds the segment digest index of each file to the policy package version number and provides a consistency determination function. When the binding relationship between the segment digest index and the policy package version number is consistent in the metadata and verification records, the result of the consistency determination function is 1; otherwise, the result is 0. The device access and control gateway includes an edge computing unit. The edge computing unit has a shadow running area and a main running area. After receiving a policy package with a stage code and a policy package version number, the edge computing unit performs playback execution of the policy package based on sampled I / O data in the shadow running area, and performs matching and verification with the simulation verification summary of the digital twin engine. After the matching is successful, the policy package is migrated to the main running area for execution. The communication interface adapter includes a southbound protocol bridge and a northbound data adapter. The southbound protocol bridge adds a unified time base and sequence number marker to OPCUA, BACnet / IP, or Modbus / TCP sessions. The northbound data adapter connects to the project management system, BIM data source, and document management system via REST or MQTT and parses external model identifiers. During the policy release process, the communication interface adapter establishes a mapping between the external model identifier and the model element identifier in the digital twin engine, and completes the policy release transaction with the edge computing unit in a two-phase commit manner. The communication interface adapter performs the two-phase commit during policy release and rollback. In the preparation phase, the communication interface adapter performs consistency verification with the device access and control gateway, the time series data management module, and the digital twin engine, reads the simulation verification summary, reads the segment summary index, and calls the consistency judgment function to check session health and time synchronization deviation. After all checks pass, it returns to a commit-ready state. In the commit phase, the communication interface adapter writes a release flag and triggers the device access and control gateway to migrate the policy package to the main operating area. At the same time, it sends the release event in batches. The release event includes the policy package version number, session sequence number range, and time coverage declaration. The process engine includes a policy approval submodule, which signs and verifies the policy package generated by the rules and scheduling engine. The signing and verification result serves as one of the triggering conditions for the rules and scheduling engine to issue control commands. The visualization monitoring terminal includes a large-screen terminal and a mobile terminal; before executing a control command issuance or rollback operation, the visualization monitoring terminal reads the segment digest index corresponding to the target version number from the time-series data management module and performs a consistency comparison with the strategy package signature digest recorded by the process engine; after the comparison is successful, the control command issuance control is enabled on the large-screen terminal, and the stage code and strategy package version number associated with the control command issuance operation are recorded on the mobile terminal; wherein, the target version number is the strategy package version number as described in this claim; The visualization monitoring terminal includes a verification and release panel, configured to sequentially perform verification, signature, and release operations. In the verification phase, the verification and release panel initiates a consistency determination. When the result of the consistency determination function is 1, the signature phase begins. The visualization monitoring terminal displays a visually aligned view of the policy package version number, the manifest summary, and the simulation verification summary, and requires the operator to perform signature verification. After successful signature verification, the visualization monitoring terminal obtains the approval status from the process engine and the session health and time synchronization deviation from the device access and control gateway and the communication interface adapter. When the approval status, session health, and time synchronization deviation all pass, the release license determination result is set to 1 and the release control is activated; otherwise, the release license determination result is set to 0 and the release control remains grayed out.

2. The intelligent management system for the entire lifecycle of exhibition hall projects according to claim 1, characterized in that, It also includes an asset and exhibit ledger module. When the process engine generates a stage switching event, the asset and exhibit ledger module calls an RFID reader to collect asset identifiers and location information, compares the collected asset identifiers with the model element identifiers in the digital twin engine, and writes the comparison results into the model snapshot corresponding to the stage code in the form of model attachment attributes.

Images