Industrial digital twin real-time rendering system and method of strong isolation architecture

Abstract

This invention discloses a real-time rendering system and method for industrial digital twins with a strongly isolated architecture. It adopts a three-level process-level decoupled architecture consisting of a configuration layer, an industrial-grade data center layer, and a rendering runtime layer. The industrial-grade data center layer centrally handles multi-protocol data acquisition, parsing and cleaning, time-series storage, and event-driven asynchronous distribution, achieving comprehensive offloading of computational load. The rendering runtime layer employs a physically-level strongly isolated design between the main rendering thread and the Lua sandbox thread. Through lock-free message queues and the introduction of a frame synchronization safety point mechanism, the scene tree remains read-only during the rendering phase, achieving logical fault isolation from the architectural root, ensuring the main rendering thread never blocks, preventing frame drops during high-concurrency access, and maintaining error-free visuals. This invention addresses the industry pain points of traditional digital twin architectures, such as coupling, single-threaded lag, and multi-threaded concurrency conflicts, meeting the 24 / 7 high-reliability, lightweight, low-disturbance, and distributed scalable digital twin operation requirements in industrial settings.

Description

Technical Field

[0001] This invention relates to the field of industrial digital twin 3D visualization and time-series data processing technology, and in particular to a real-time rendering system and method for industrial digital twins with a strong isolation architecture. Background Technology

[0002] Currently, industrial digital twins generally face problems such as architectural coupling, unstable performance, and uncontrollable failures during field-level deployment, and mainstream technical approaches have obvious shortcomings: 1) Heavy industrial twin platforms (such as the Siemens digital twin platform) It adopts a strongly coupled integrated architecture, with data processing, logic control, simulation calculation and 3D rendering deeply bound together, without a separate industrial data center layered design; the deployment cost is high and the hardware requirements are high, making it impossible to push the computing pressure down to the edge side; the logic and rendering are not thread-isolated, and resource contention and rendering stuttering are prone to occur when high-concurrency measurement points are connected, making it difficult to achieve stable 7×24-hour operation on ordinary industrial control computers.

[0003] 2) Generic game engine twins (such as Unity3D) It adopts a single main thread driven mode, in which scene updates, logic scripts, animation calculations, and rendering preparation are all executed on the same main thread; high-concurrency data access and complex logic operations are prone to blocking rendering time slices, resulting in frame drops, screen tearing, and program crashes; there is no independent data service layer, it does not support distributed expansion, and its stability cannot meet the stringent requirements of industrial sites.

[0004] 3) Standard lightweight VTK digital twin Simply replacing VTK as a rendering component does not change the overall structure; it remains a single-process tightly coupled structure. Without an independent data governance layer, data acquisition, parsing, logical operations, and rendering execution run in the same process. It lacks thread fault isolation capabilities and frame synchronization security control mechanisms, which can easily lead to rendering errors, state asynchrony, and system jitter under high concurrency conditions.

[0005] In summary, existing technologies generally suffer from common pain points such as heavy architectural coupling, concentrated computational load on the rendering end, inability to completely decouple logic and rendering, inability to isolate faults, susceptibility to stuttering under high concurrency, susceptibility to errors under multi-threaded concurrency, and inflexible deployment. They cannot simultaneously meet the comprehensive requirements of industrial sites for high real-time performance, high stability, low disturbance, lightweight design, distributed capability, and continuous 24 / 7 operation. Summary of the Invention

[0006] Technical Objective: To address the shortcomings of existing technologies, such as architectural coupling, easy blocking of the main rendering thread, inability to isolate logical faults, easy confusion in multi-threaded concurrency, and inability to reduce computational load, this invention discloses a real-time rendering system and method for industrial digital twins with a strong isolation architecture.

[0007] Technical solution: To achieve the above technical objectives, the present invention adopts the following technical solution.

[0008] A real-time rendering system for industrial digital twins with a strongly isolated architecture includes a configuration layer, an industrial-grade data center, and a rendering runtime layer that communicate via an asynchronous message protocol. The configuration layer is used for 3D scene management, enabling scene-data mapping configuration; The industrial-grade data center is deployed independently to complete multi-protocol data acquisition, data parsing and cleaning, time-series data storage and event-driven asynchronous message distribution, thus offloading the full data computing load to the data center. The rendering runtime layer connects to the configuration layer and the industrial-grade data center to obtain project files issued by the configuration layer and standard timing data pushed by event-driven processes in the industrial-grade data center. The rendering runtime layer includes the main rendering thread and several independent Lua sandbox threads. The two types of threads are physically isolated, have no shared memory, and interact asynchronously through a lock-free message queue. The main rendering thread sets the frame synchronization safety point based on the frame synchronization safety point parameter, and only updates the model state in batches at the frame synchronization safety point. During the rendering and drawing phase, the scene tree remains read-only. The Lua sandbox has an independent thread for device state calculation and animation parameter solving. Logical exceptions do not propagate to the main rendering thread.

[0009] A real-time rendering method for industrial digital twins with a strong isolation architecture, applied to the aforementioned real-time rendering system for industrial digital twins with a strong isolation architecture, includes the following steps: 1) Construct a 3D scene in the configuration layer: Establish a mapping relationship between data points and model attributes, edit and send project files, such as logic scripts and configuration files, to the rendering runtime layer; 2) Industrial-grade data centers complete multi-protocol data acquisition, parsing, cleaning, standardization, and time-series data persistence; 3) Industrial-grade data centers asynchronously push standardized data to the rendering runtime layer in an event-driven manner; 4) The rendering runtime layer performs subscription filtering and industrial measurement point matching on standardized data, and sends the effective data into an independent thread in the Lua sandbox for state calculation and animation solving; 5) The Lua sandbox's independent thread submits the computation results to the main rendering thread through a lock-free message queue; 6) The main rendering thread reads messages in batches and updates the scene state at the frame synchronization safe point. After exiting the safe point, it enters read-only scene traversal and GPU drawing to complete single-frame rendering. 7) Logical exceptions trigger independent self-recovery of the Lua sandbox thread, while the main rendering thread continues to run without interruption.

[0010] Beneficial effects: 1. The entire industrial data collection, governance, storage, and distribution chain is centrally handled by an independent data center, thus reducing the computing load to lower levels; the rendering end has no preprocessing burden and is compatible with ordinary industrial control computers. 2. The main rendering thread and the logic thread, which are independent threads in the Lua sandbox, are physically isolated, so that logical exceptions, infinite loops, and high loads do not spread or block rendering. 3. The rendering pipeline adopts a frame synchronization safety point mechanism, and the scene tree runs in read-only mode during the rendering stage to prevent concurrent errors. 4. The system supports distributed expansion, hot updates, and fault self-healing, meeting the high reliability, lightweight, and non-stop operation and maintenance requirements of industrial sites. Attached Figure Description

[0011] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the method in Embodiment 2 of the present invention. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0013] Example 1: As shown in the attached document Figure 1 As shown in this embodiment, an industrial digital twin real-time rendering system with a strongly isolated architecture includes a configuration layer, an industrial-grade data center, and a rendering runtime layer; the three modules are decoupled at the process level and communicate through an asynchronous message protocol. The configuration layer is used for 3D scene management, enabling scene-data mapping configuration; The configuration layer is an offline project configuration tool that does not participate in runtime data processing or real-time rendering, achieving complete separation between configuration and runtime, and ensuring a clean and stable runtime environment. Its functions include: 1) 3D Scene Management: Supports importing mainstream model formats, automatically constructing scene trees, hierarchical relationships, and spatial coordinate systems; supports visual configuration and pre-calculation of camera, viewpoint, lighting, inspection path, and roaming trajectory; supports pre-rendering processing such as LOD level, texture compression, and rendering batch optimization. In this invention, the configuration layer does not construct 3D models but directly imports models. The mainstream model formats include glTF, FBX, OBJ, and other commonly used formats in existing technologies. The implementation process of 3D scene management uses existing technologies, such as: based on an offline configuration engine and 3D model parser, automatically constructing scene trees and coordinate systems using scene graph structures, completing camera, lighting, and inspection path configurations through a visual editing panel, and relying on a pre-rendering optimizer to achieve LOD, texture compression, and rendering batch optimization, etc., which will not be elaborated here.

[0014] 2) Data Point and Model Mapping Configuration: Provides a visual binding interface, supporting the mapping of industrial measurement points to model attributes such as position, rotation, scaling, color, transparency, material, visibility, and animation. It supports batch mapping, expression editing, threshold range configuration, and linkage rule configuration. Industrial measurement points refer to physical equipment measurement points in the industrial equipment layer, such as various sensors and PLCs. It should be noted that this invention can operate even without an industrial equipment layer, directly rendering and simulating the mainstream model. When an industrial equipment layer exists, this invention can combine data from the physical equipment feedback to achieve real-time rendering of the digital twin based on the mainstream model rendering. In other words, without collecting industrial data, this invention uses scripts to simulate reality using virtual data; if industrial data is collected, the digital twin of this invention reflects the virtual reality. In addition, the data point and model mapping configuration in this step not only realizes the mapping relationship between industrial measuring points and locations, but also includes coordinate mapping relationships, action triggering mapping relationships, etc. The implementation of the mapping relationship is based on existing technologies, such as: establishing the association between industrial measuring points and model attributes through a visual binding editor, using an attribute-driven framework and mapping rule engine to realize batch mapping, expression editing, threshold and linkage rule configuration, and storing the mapping relationship in a structured configuration file, etc., which will not be elaborated here.

[0015] 3) Lua Logic Script Editing and Security Verification: Provides a dedicated editing environment supporting the writing of logic such as status judgment, threshold alarms, animation interpolation, linkage control, event triggering, and delayed execution; built-in syntax checking, timeout detection, and API permission constraints ensure the safe operation of scripts. This function corresponds to the subsequent Lua sandbox independent thread; the Lua logic script is completed first, and then data operations are performed in the Lua sandbox independent thread. Relying on a dedicated script editor to provide the writing environment, and based on the Lua virtual machine sandbox execution logic, security verification is achieved through static syntax checking, runtime timeout monitoring, and API whitelisting, isolating faults within the sandbox.

[0016] 4) Project file packaging, version management, and distribution: Unifies the packaging of scenes, models, mapping relationships, logic scripts, and frame synchronization security point parameters; supports encrypted transmission, incremental updates, version rollback, and remote distribution; automatically loaded when the rendering runtime layer starts. Integrates scene, mapping, and script resources through the project package manager, supports incremental updates, encryption, and version rollback, remotely distributed via asynchronous message channels, and automatically loaded and parsed when the rendering runtime layer starts.

[0017] The industrial-grade data center is deployed independently to complete multi-protocol data acquisition, data parsing and cleaning, time-series data storage and event-driven asynchronous message distribution, thus offloading the full data computing load to the rendering end and not passing data processing pressure to the rendering end. The industrial-grade data center is an independently deployed service process, serving as the system's data hub and computing core. It enables one-time data collection, global governance, and multi-device reuse, completely offloading all data processing pressure from the rendering end. Internally, it comprises four sub-layers: 1) Multi-protocol acquisition engine layer: used to acquire data from industrial measurement points; adopts an asynchronous non-blocking IO architecture, supporting mainstream protocols such as Modbus, OPC UA / DA, MQTT, PLC, Power104, and serial port; supports batch access of millions of measurement points, disconnection reconnection, heartbeat detection, buffered data transmission, and timeout judgment; it should be noted that the industrial-grade data center is connected to the industrial equipment layer, specifically the multi-protocol acquisition engine layer is connected to the industrial equipment layer; considering that the data transmission protocols of various physical devices in the industrial equipment layer are different, this invention introduces multiple mainstream protocols into the multi-protocol acquisition engine layer to achieve data reception and acquisition.

[0018] 2) Data Governance Layer: Connected to the multi-protocol acquisition engine layer, it is used to preprocess the acquired data to obtain standard time-series data. The preprocessing operations in the data governance layer include: completing message parsing, data cleaning, standardization and normalization, and real-time calculation, unifying heterogeneous industrial data into standard time-series data and shielding differences between devices and protocols. 3) Time-series Persistence Layer: Connected to the data governance layer, this layer stores standard time-series data. It integrates a high-performance time-series database, adapting to high-frequency industrial data acquisition scenarios. The storage engine is optimized for the three-dimensional time-series model of measurement points, timestamps, and numerical values, significantly improving high-concurrency write and historical retrieval performance compared to traditional relational databases. It employs automatic partitioning, columnar compression, and hot / cold tiered storage. Automatic partitioning refers to automatic partitioning management based on the time dimension, physically isolating massive amounts of time-series data by day / week / month, reducing the retrieval scanning scope and improving query, cleanup, and archiving efficiency. Columnar compression refers to using columnar storage and a dedicated time-series compression algorithm to batch compress continuous time-series values ​​from the same measurement point, significantly reducing disk storage space usage and adapting to low-cost storage of long-term, massive data. Hot / cold tiered storage means that it automatically schedules hot and cold time-series data, storing recently accessed high-frequency hot data on high-performance media and automatically migrating older, low-frequency cold data to low-cost storage media, balancing access performance and storage cost. In other words, the timing persistence layer of this invention supports high-throughput writing, long-cycle storage, historical playback, and querying by time slice / measurement point / device; 4) Event-driven message distribution layer: Connected to the data governance layer, it adopts event-driven push-based asynchronous distribution of standard time-series data, actively sending standardized data to the rendering runtime layer without polling; the event-driven message distribution layer supports subscription by scene, filtering by test point, and scheduling by priority, reducing the resource consumption of the rendering end.

[0019] Industrial-grade data centers support single-machine, distributed cluster, and centralized cloud deployment, and can simultaneously provide data services to multiple rendering runtime layers, including the ability to supply standardized industrial real-time and time-series data for one-time collection, global governance, and multi-terminal reuse. Industrial-grade data centers also possess horizontal scaling capabilities. In other words, in this invention, the industrial-grade data center is deployed independently, supports distributed horizontal scaling, and can simultaneously provide data services to multiple rendering runtime layers.

[0020] The rendering runtime layer is connected to the configuration layer and the industrial-grade data center. It is used to obtain the project files issued by the configuration layer and the standard time-series data pushed by the event-driven mechanism in the industrial-grade data center. The rendering runtime layer includes the main rendering thread and several independent Lua sandbox threads. The two types of threads are physically isolated, have no shared memory, and interact asynchronously through a lock-free message queue. The main rendering thread sets the frame synchronization safety point according to the frame synchronization safety point parameter, and only updates the model state in batches at the frame synchronization safety point. During the rendering and drawing phase, the scene tree remains read-only. Generally speaking, the main rendering thread is a native C++ thread that runs directly in the native operating system environment without a virtual machine or any script virtual machine.

[0021] The Lua sandbox independent thread is used for device state calculation and animation parameter solving, and logical exceptions do not propagate to the main rendering thread. The Lua sandbox independent thread runs on an independent thread and an independent virtual machine, with access restricted by an API whitelist. It does not hold any pointers to rendering objects or have rendering context operation permissions. The Lua sandbox independent thread and the main rendering thread only exchange pure data structures through a lock-free message queue. They do not share memory, call each other, or directly access scene resources, achieving strong isolation at the physical, memory, and permission levels. The main rendering thread abandons the traditional full-frame polling mode and adopts an event-driven incremental rendering mechanism. The Lua sandbox independent thread encapsulates changes in the state of production line equipment, workstations, and products as incremental update events, which are asynchronously pushed to the rendering layer through a lock-free message queue. The main rendering thread only detects and consumes events at frame synchronization safety points, and only performs local attribute updates on the model objects corresponding to the events. When there are no state changes, it does not perform model traversal or state refresh. During the rendering and drawing phase, the scene tree remains read-only, so that rendering is triggered by events and updates only take effect incrementally and locally, significantly reducing the rendering overhead of 3D scenes.

[0022] The rendering runtime layer is the core innovation of this invention. It adopts a rendering architecture with strong isolation between rendering and logic / physical levels, lock-free message queues, frame synchronization safety points, and read-only scene tree rendering, which solves the industry problems of traditional twin rendering such as stuttering, blocking, errors, and crashes from the bottom layer.

[0023] 1) Rendering and logic are completely separated from physics. This invention provides physical-level strong isolation between the rendering and logic execution environments, separating 3D image rendering and business logic operations into two completely independent execution domains. Each domain has its own independent memory space, independent CPU time slice, independent exception handling domain, and independent lifecycle. They do not share any memory, do not call each other, and do not compete for resources, thus cutting off any possibility of logical exceptions spreading to the main rendering thread from the underlying architecture.

[0024] The main rendering thread is strictly limited to a pure consumer role, performing only standard rendering pipeline operations such as scene tree traversal, view frustum culling, rendering state setting, GPU instruction submission, view interaction, frame synchronization, and screen output. It does not undertake any non-rendering workloads such as data parsing, state calculation, logical judgment, animation resolution, network transmission and reception, or file reading and writing. The rendering cycle is highly controllable, and the time slice is completely stable. It will not be blocked, stuttered, or experience frame rate jitter due to any external data fluctuations or logical operations.

[0025] Logical computations are entirely migrated to an independent Lua sandbox thread for execution. All device status checks, threshold alarms, linkage rules, animation interpolation, and parameter calculations are completed asynchronously within the sandbox. The Lua sandbox has an independent virtual machine, independent stack, and independent API whitelist, opening only limited controlled interfaces and prohibiting access to the rendering kernel, scene objects, and system resources. When logical errors such as infinite loops, computation timeouts, script exceptions, or memory overflows occur, the exceptions are confined within the sandbox thread, triggering only the sandbox's own circuit breaker, restart, and state recovery. This prevents the main rendering thread from lag, freezing, display distortion, or process crashes, achieving industrial-grade fault isolation.

[0026] 2) Frame synchronization safe point mechanism To completely resolve the issues of screen tearing, rendering errors, and state desynchronization caused by concurrent scene modifications by multiple threads, this invention sets a unique frame synchronization safety point within the main rendering thread. This serves as the sole entry point for state synchronization between the two threads, forming a strict timing control mechanism. The frame synchronization safety point is fixed: The frame synchronization safety point is set according to the frame synchronization safety point parameter. The frame synchronization safety point is located at the beginning of the single frame rendering cycle and before the scene tree traversal. It is the only time window in each frame that allows the model state to be updated. Frame synchronization safety point batch synchronization: Only during the frame synchronization safety point stage, the rendering main thread reads all the calculation results of the Lua sandbox thread from the lock-free message queue in one batch, and centrally completes the updates of model position, rotation, color, visibility, material and other attributes to ensure state consistency; Forced read-only mode during rendering: Once the frame synchronization safe point is exited and the scene traversal and GPU rendering phase are entered, the scene tree immediately enters read-only protection mode. Both the main rendering thread and the Lua sandbox thread are prohibited from making any modifications, writes, or deletions to scene objects, thus eliminating multi-threaded concurrent write conflicts from an architectural perspective. Strict timing and no interference: The rendering pipeline and logic calculation are safely separated into two stages that are executed in an orderly manner and do not interfere with each other. The logic calculation does not intrude on the rendering, and the rendering does not interrupt the logic, completely eliminating problems such as screen jitter, flickering, penetration, and rendering crashes caused by "calculating and rendering at the same time and updating and drawing at the same time" in traditional twin systems.

[0027] This mechanism is not a simple thread synchronization method, but rather it constructs a new rendering paradigm of "synchronizing the state first, then drawing in read-only mode" within the rendering cycle. The Unity engine cannot set a safepoint due to its single main thread limitation; Siemens cannot achieve read-only rendering due to its tightly coupled architecture; and the conventional VTK architecture, without layered isolation, cannot support timing control.

[0028] 3) Lock-free message queue Two threads exchange status data through a lock-free circular message queue, ensuring no locks, no waiting, no contention, and no risk of deadlock; the producer only writes and the consumer only reads, supporting batch enqueueing, batch dequeueing, and traffic shaping, with high throughput, low latency, and thread safety.

[0029] The Lua sandbox independent thread has its own memory space, execution stack and API access whitelist. Logical exceptions and infinite loops are handled only inside the sandbox, achieving fault isolation.

[0030] The main rendering pipeline only executes the 3D rendering pipeline and does not participate in data parsing or business logic operations, thus maintaining the stability of the rendering time slice.

[0031] This invention also discloses a real-time rendering method for industrial digital twins with a strongly isolated architecture, comprising the following steps: 1) Construct a 3D scene in the configuration layer: Establish a mapping relationship between data points and model attributes, edit and send project files, such as logic scripts and configuration files, to the rendering runtime layer; 2) Industrial-grade data centers complete multi-protocol data acquisition, parsing, cleaning, standardization, and time-series data persistence; 3) Industrial-grade data centers asynchronously push standardized data to the rendering runtime layer in an event-driven manner; 4) The rendering runtime layer performs subscription filtering and industrial measurement point matching on standardized data, and sends the effective data into an independent thread in the Lua sandbox for state calculation and animation solving; 5) The Lua sandbox's independent thread submits the computation results to the main rendering thread through a lock-free message queue; 6) The main rendering thread reads messages in batches and updates the scene state at the frame synchronization safe point. After exiting the safe point, it enters read-only scene traversal and GPU drawing to complete single-frame rendering. 7) Logical exceptions trigger independent self-recovery of the Lua sandbox thread, while the main rendering thread continues to run without interruption.

[0032] In this invention, the scene tree remains in a read-only state during the rendering and drawing stages 4)-7), and does not accept any concurrent modifications by any threads, thus avoiding screen tearing and rendering errors.

[0033] Industrial-grade data centers centrally handle all data computation loads, while the rendering end is only responsible for displaying the images, making them suitable for lightweight hardware deployments.

[0034] The Lua sandbox's independent thread supports hot reloading and dynamic replacement of Lua logic scripts, allowing business logic to be updated without restarting the rendering process.

[0035] Therefore, the overall data flow process of the system in this invention is as follows: 1) Industrial field equipment → Multi-protocol data acquisition → Industrial-grade data center analysis, cleaning, standardization, and storage; 2) Industrial-grade data centers operate on an event-driven model, asynchronously pushing standardized data to the rendering runtime layer. 3) Rendering runtime layer subscription filtering, measurement point matching → valid data is sent to the Lua sandbox; 4) The Lua sandbox completes state calculations and animation solutions → the results are pushed into a lock-free queue; 5) The main rendering thread reads and updates the model state in batches at the frame synchronization safe point; 6) Exit the safe point → enter the read-only rendering stage → complete the screen drawing; 7) Logical exception → Lua sandbox restarts independently → rendering main thread continues to run stably.

[0036] This invention adopts a three-level process-level decoupled architecture, which completely separates the three major functional domains of configuration, data governance, and real-time rendering. Each module runs as an independent process with an independent lifecycle, independent deployment node, and independent fault domain. The modules communicate with each other using an event-driven asynchronous message mechanism, with no synchronous blocking, no strong dependencies, and no implicit coupling, thereby improving the system's stability, scalability, and anti-interference capabilities from the root of the architecture.

[0037] The system consists of three parts: a configuration layer, an industrial-grade data center, and a rendering runtime layer. The industrial-grade data center, as the core of the system, is responsible for the unified access, parsing, cleaning, real-time computation, time-series persistence, and event-driven asynchronous distribution of multi-source industrial data, thus offloading the entire data computation load to the rendering end and completely eliminating the data processing pressure. The rendering runtime layer adopts a physically-level strong isolation architecture between the main rendering thread and logical threads, coupled with a frame synchronization safety point mechanism, to achieve complete decoupling between the rendering pipeline and business logic computation. The configuration layer is an offline configuration tool used to complete the unified configuration and distribution of 3D scenes, data mapping, and business logic without intruding on the system runtime environment, ensuring stable and reliable operation.

[0038] Example 2: As shown in the attached document Figure 2 As shown in this embodiment, a real-time rendering method for industrial digital twins with a strongly isolated architecture includes the following steps: S1: Scene configuration and data mapping; Import the 3D model through the configuration layer to build the scene tree and hierarchical structure; configure the camera, viewpoint, lighting, inspection path and LOD strategy; establish the mapping relationship between industrial measurement points and model attributes, and write Lua logic scripts such as threshold judgment, animation calculation and linkage control; configure the frame synchronization safety point triggering time, batch update threshold, timeout parameters, and complete the project file packaging and distribution.

[0039] S2: Launching an industrial-grade data center; Initialize the multi-protocol acquisition engine and connect to industrial measurement points, such as field PLCs, sensors, gateways, and other devices; the industrial-grade data center parses, filters, converts units, removes anomalies, and standardizes the raw data collected from the industrial measurement points; the data is written to a time-series database for persistence, and the raw data includes process, motion, and status data; the standardized measurement point data is asynchronously pushed to the subscribed rendering runtime layer in an event-driven manner, without passing any computational load to the rendering end. S3: Initialize the rendering runtime layer; Start the main rendering thread, load the scene configuration file output by the configuration layer, establish the rendering loop, and initialize the frame synchronization safety point timing control logic; create an independent Lua sandbox thread, allocate an independent virtual machine, memory space and execution stack, configure API whitelist, exception monitoring, and timeout circuit breaker rules; establish a lock-free message queue, complete the initialization of the dual-thread communication link, and achieve complete isolation between threads.

[0040] S4: Real-time data-driven rendering process; The rendering runtime layer receives standard data pushed by industrial-grade data centers, performs subscription matching and measurement point filtering according to the current scene configuration, and forwards only valid data to the Lua sandbox. The Lua sandbox performs state calculation, threshold judgment, animation interpolation and parameter solving, and encapsulates the results into state messages and pushes them into a lock-free queue. The main rendering thread reads messages in batches and updates model attributes centrally at frame synchronization safe points. After exiting the safe point, it enters read-only traversal of the scene tree and GPU drawing to complete the rendering of a single frame. The loop execution realizes real-time data-driven processing.

[0041] S5: Industrial-grade stability assurance; When the Lua sandbox encounters an exception, infinite loop, or crash, it triggers an independent thread to restart and reset the state, while the main rendering thread remains unaffected. When the network is interrupted or data connection is lost, local state caching is enabled to continuously output a stable state at a safe point to maintain continuous display. When there is a sudden increase in high-concurrency test points, the industrial-grade data center bears the full computing pressure, and the rendering end only updates in batches at safe points, without load jitter. When multiple terminals and multiple scenarios are accessed, data is uniformly distributed by an industrial-grade data center, and each rendering runtime layer runs independently, supporting distributed expansion; When business logic changes, dynamic replacement is achieved through hot reloading of Lua scripts, without restarting the rendering process or interrupting screen output.

[0042] As attached Figure 1As shown, the industrial field equipment layer uploads raw data through the industrial gateway; the configuration layer completes offline scene setup, data binding, logic editing, and configuration distribution; the industrial-grade data center layer realizes data acquisition, parsing, governance, storage, and asynchronous push, thus offloading computational pressure; the rendering runtime layer includes data adaptation, an independent Lua sandbox thread, a lock-free message queue, frame synchronization safety points, and the main rendering thread, achieving physical isolation between logic and rendering. Data flow: Industrial equipment acquisition → Data center processing → Rendering layer adaptation → Lua logic calculation → Safety point synchronization → Rendered screen output.

[0043] As attached Figure 2 As shown, the data flow process in this embodiment is as follows: Scene and data mapping configuration → Startup of industrial-grade data center → Initialization of rendering runtime layer → Real-time data-driven rendering → Industrial-grade stability assurance. The rendering runtime layer receives standard data, filters it through subscriptions and matches measurement points, then sends it to the Lua sandbox for computation; the results are submitted to the main rendering thread via a lock-free queue; the main rendering thread updates the state in batches at frame synchronization safety points, then proceeds to read-only scene traversal and GPU rendering; Lua sandbox anomalies can be restarted independently without affecting the main rendering thread, ensuring stable 24 / 7 system operation.

[0044] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product can be stored in a storage medium. The memory can be various types of memory, such as random access memory, read-only memory, flash memory, etc., such as read-only memory (ROM) / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which can be a personal computer, server, or network communication device such as a router) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0045] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An industrial digital twin real-time rendering system of a strong isolation architecture, characterized in that, This includes a configuration layer, an industrial-grade data center, and a rendering runtime layer that communicate via asynchronous message protocols. The configuration layer is used for 3D scene management, enabling scene-data mapping configuration; The industrial-grade data center is deployed independently to complete multi-protocol data acquisition, data parsing and cleaning, time-series data storage and event-driven asynchronous message distribution, thus offloading the full data computing load to the data center. The rendering runtime layer connects to the configuration layer and the industrial-grade data center to obtain project files issued by the configuration layer and standard timing data pushed by event-driven processes in the industrial-grade data center. The rendering runtime layer includes the main rendering thread and several independent Lua sandbox threads. The two types of threads are physically isolated, have no shared memory, and interact asynchronously through a lock-free message queue. The main rendering thread sets the frame synchronization safety point based on the frame synchronization safety point parameter, and only updates the model state in batches at the frame synchronization safety point. During the rendering and drawing phase, the scene tree remains read-only. The Lua sandbox has an independent thread for device state calculation and animation parameter solving. Logical exceptions do not propagate to the main rendering thread.

2. The industrial digital twin real-time rendering system of a strongly isolated architecture according to claim 1, characterized in that: The configuration layer implements functions including 3D scene management, data point and model mapping configuration, Lua logic script editing and security verification, as well as project file packaging, version management and distribution.

3. The industrial digital twin real-time rendering system of a strongly isolated architecture according to claim 1, wherein: Industrial-grade data centers include: Multi-protocol acquisition engine layer: used to acquire data from industrial measurement points; adopts an asynchronous non-blocking IO architecture, supports mainstream protocols; supports batch access of millions of measurement points, disconnection reconnection, heartbeat detection, buffer retransmission, and timeout judgment; Data governance layer: Connects to the multi-protocol acquisition engine layer and is used to preprocess the acquired data to obtain standard time-series data; Time-series persistence layer: Connected to the data governance layer, used to store standard time-series data; Event-driven message distribution layer: Connected to the data governance layer, it uses event-driven push-based asynchronous distribution of standard time-series data, actively sending standardized data to the rendering runtime layer without polling.

4. The industrial digital twin real-time rendering system of a strongly isolated architecture according to claim 3, wherein: Industrial measurement points are the physical equipment measurement points in the industrial equipment layer. Without an industrial equipment layer, the mainstream model is rendered and simulated. When an industrial equipment layer exists, the real-time rendering effect of the digital twin is achieved by combining the data fed back by the physical equipment and based on the rendering of the mainstream model.

5. The industrial digital twin real-time rendering system of a strongly isolated architecture according to claim 1, wherein: The main rendering thread only performs standard rendering pipeline operations, including scene tree traversal, view frustum culling, rendering state settings, GPU instruction submission, view interaction, frame synchronization, and screen output. It does not bear non-rendering loads, and the rendering cycle is highly controllable and the time slice is completely stable. It will not be blocked, stuttered, or experience frame rate jitter due to any external data fluctuations or logical operations.

6. The industrial digital twin real-time rendering system of a strongly isolated architecture according to claim 1, wherein: The frame synchronization safe point is located at the very beginning of a single frame rendering cycle, before the scene tree traversal. It is the only time window in each frame that allows the model state to be updated.

7. The industrial digital twin real-time rendering system of a strongly isolated architecture according to claim 1, wherein: The main rendering thread and the Lua sandbox thread pass state data through a lock-free circular message queue. Only during the frame synchronization safepoint phase does the main rendering thread read all the calculation results of the Lua sandbox thread in batches from the lock-free message queue. Once the frame synchronization safepoint is exited and the scene traversal and GPU rendering phase begins, the scene tree immediately enters read-only protection mode, and both the main rendering thread and the Lua sandbox thread are prohibited from performing any modification, writing, or deletion operations on scene objects.

8. A method for real-time rendering of industrial digital twin in a strong isolation architecture, applied to a system for real-time rendering of industrial digital twin in a strong isolation architecture according to any one of claims 1-7, characterized in that, Includes the following steps: 1) Construct a 3D scene in the configuration layer: Establish a mapping relationship between data points and model attributes, edit and send project files, such as logic scripts and configuration files, to the rendering runtime layer; 2) Industrial-grade data centers complete multi-protocol data acquisition, parsing, cleaning, standardization, and time-series data persistence; 3) Industrial-grade data centers asynchronously push standardized data to the rendering runtime layer in an event-driven manner; 4) The rendering runtime layer performs subscription filtering and industrial measurement point matching on standardized data, and sends the effective data into an independent thread in the Lua sandbox for state calculation and animation solving; 5) The Lua sandbox's independent thread submits the computation results to the main rendering thread through a lock-free message queue; 6) The main rendering thread reads messages in batches and updates the scene state at the frame synchronization safe point. After exiting the safe point, it enters read-only scene traversal and GPU drawing to complete single-frame rendering. 7) Logical exceptions trigger independent self-recovery of the Lua sandbox thread, while the main rendering thread continues to run without interruption.

Images