Conveyor line digital twin virtual debugging system and method based on b / s architecture

Abstract

The application relates to the technical field of PLC control, in particular to a conveying line digital twin virtual debugging system and method based on a B / S architecture. The system comprises a three-layer B / S architecture composed of a PLC simulation layer, a business logic layer and a three-dimensional visualization layer. The PLC simulation layer is used for running a PLC program to obtain feedback signals of controlled equipment, simulating the control logic of the PLC on the controlled equipment based on the feedback signals, and sending control signals to the business logic layer. The business logic layer is used for obtaining the control signals and performing business logic operation based on the control signals and the feedback signals to calculate the movement of the simulated controlled equipment and obtain real-time position data. The three-dimensional visualization layer is used for displaying the running state of the controlled equipment based on a pre-constructed virtual model of the controlled equipment and the real-time position data to show the running result of the PLC program, and generating feedback signals based on virtual sensors on the virtual model of the controlled equipment and sending the feedback signals to the business logic layer.

Description

Technical Field

[0001] This application relates to the field of PLC control technology, specifically to a digital twin virtual debugging system and method for a conveyor line based on a B / S architecture. Background Technology

[0002] In the process of upgrading to intelligent manufacturing, the demand for flexible production lines in discrete manufacturing places higher demands on equipment debugging efficiency. Traditional physical debugging methods rely on on-site joint debugging of mechanical, electrical, and control systems, which has many drawbacks, such as long debugging cycles, high trial-and-error costs, and difficulties in cross-regional collaboration. Especially in complex conveyor line scenarios, PLC program logic verification requires repeated start-ups and shutdowns of real equipment. This not only exacerbates mechanical wear but may also lead to cascading failures, mechanical damage, or even personal injury due to sensor signal feedback delays or errors in control instructions written by debugging personnel due to programming negligence or poor logic design.

[0003] In recent years, to address the aforementioned challenges of physical debugging, many virtual debugging software programs based on a client / server (C / S) architecture (such as those based on Unity) have emerged in the market. However, while solving old problems, these solutions have also introduced new technical bottlenecks: First, C / S architecture virtual debugging client software is typically large in size and has high requirements for local computer hardware configuration, resulting in high deployment and usage barriers; second, software licensing fees are expensive, and the software is deeply tied to specific operating systems or platforms, resulting in poor flexibility (e.g., poor compatibility with domestic platforms such as Kylin).

[0004] In summary, traditional debugging methods and existing technologies are clearly insufficient to meet the needs of modern intelligent manufacturing, making it difficult to efficiently, accurately, and cost-effectively debug and optimize controlled equipment. Summary of the Invention

[0005] In view of this, embodiments of this application aim to provide a digital twin virtual debugging system and method for a conveyor line based on a B / S architecture.

[0006] This application provides a digital twin virtual debugging method for conveyor lines based on a B / S architecture, including a three-layer B / S architecture consisting of a PLC simulation layer, a business logic layer, and a three-dimensional visualization layer;

[0007] PLC simulation layer: used to run PLC programs, simulate the PLC programs, obtain feedback signals from the controlled devices, simulate the PLC's control logic for the controlled devices based on the feedback signals, and send control signals to the business logic layer;

[0008] The business logic layer is communicatively connected to the PLC simulation layer. It is used to acquire the control signals and perform business logic operations based on the control signals and the feedback signals to calculate the motion of the simulated controlled equipment and obtain real-time position data.

[0009] 3D visualization layer: Communicatively connected to the business logic layer, used to display the operating status of the controlled equipment based on a pre-built virtual model of the controlled equipment and the real-time location data to show the running results of the PLC program, and generate feedback signals based on virtual sensors on the virtual model of the controlled equipment and send them to the business logic layer.

[0010] In some embodiments, the PLC simulation layer includes:

[0011] PLC programming submodule: used to write the PLC program;

[0012] PLC simulation submodule: used to simulate the PLC program to simulate the PLC's control logic for the controlled equipment.

[0013] In some embodiments, the business logic layer includes:

[0014] Signal processing submodule: used to process control signals generated by the PLC program simulation and feedback signals from the controlled device;

[0015] Business logic operation submodule: used to perform business logic operations based on the signals processed by the signal processing submodule;

[0016] Configuration Management Submodule: Used to manage the configuration information of the controlled devices and generate corresponding controlled devices based on the configuration information;

[0017] Kinematics calculation submodule: used to calculate the motion state of the controlled device and obtain real-time position data based on the calculation results of the business logic operation submodule and the dynamic model of the controlled device.

[0018] In some embodiments, the three-dimensional visualization layer includes:

[0019] Scene building submodule: used to build virtual models of controlled devices;

[0020] Model loading and updating submodule: used to load the virtual model of the controlled device in the virtual scene, and update the running status of the virtual model according to the real-time location data of the business logic layer;

[0021] Sensor simulation submodule: used to simulate the detection logic of sensors in the virtual scene and generate corresponding sensor signals; wherein the sensor signals are feedback signals.

[0022] In some embodiments, the communication between the business logic layer and the 3D visualization layer uses the WebSocket protocol to achieve real-time data transmission.

[0023] The PLC simulation layer and the business logic layer use a Redis message queue to achieve asynchronous decoupling of signals and data.

[0024] In some embodiments, the three-dimensional visualization layer is further used to: acquire data information obtained by the physical device of the controlled device running the PLC program; and adjust the virtual model of the controlled device based on the data information.

[0025] This application provides a digital twin virtual debugging method for conveyor lines based on a B / S architecture. The method includes the following steps:

[0026] Deploy a PLC simulation layer, a business logic layer, and a 3D visualization layer on the server side;

[0027] The PLC program is written through the PLC programming submodule and used to run the PLC program in the PLC simulation layer. The PLC program is simulated to obtain the feedback signal of the controlled device. Based on the feedback signal, the control logic of the PLC on the controlled device is simulated and the control signal is sent to the business logic layer.

[0028] The business logic layer receives control signals generated by the PLC program simulation and uses a preset message middleware to achieve asynchronous signal transmission and decoupling between the PLC simulation layer, the business logic layer and the 3D visualization layer.

[0029] The virtual model of the controlled device is updated in the 3D visualization layer according to the calculation results of the business logic layer, and then displayed in the client browser.

[0030] The detection logic of the sensor is simulated in the virtual scene, and the corresponding sensor signal is generated. The signal is fed back to the PLC simulation layer through the message middleware to form a closed-loop signal feedback link, thereby realizing bidirectional interaction between the virtual model and the PLC program.

[0031] In some embodiments, the business logic layer achieves asynchronous signal transmission and decoupling between the PLC simulation layer, the business logic layer, and the 3D visualization layer through the following steps:

[0032] The business logic layer converts the control signals generated by the PLC program simulation into messages of a preset format and sends them to the message middleware;

[0033] The message middleware caches the messages and forwards them to the corresponding target modules according to preset routing rules; wherein the target modules include at least one of the PLC simulation layer and the business logic layer.

[0034] The target module receives the message from the message middleware and performs corresponding processing.

[0035] In some embodiments, it also includes:

[0036] Obtain data information from the controlled device's physical device running the PLC program;

[0037] The virtual model of the controlled device is adjusted based on the data information.

[0038] This application provides an electronic device, including:

[0039] A processor, and a memory for storing a processor-executable program;

[0040] The processor is used to implement the above-described B / S architecture-based digital twin virtual debugging method for transport lines by running programs in the memory.

[0041] The digital twin virtual debugging system for a conveyor line based on a B / S architecture provided in this application includes a three-layer B / S architecture consisting of a PLC simulation layer, a business logic layer, and a three-dimensional visualization layer.

[0042] The PLC simulation layer is used to run and simulate the PLC program, acquire feedback signals from the controlled device, simulate the PLC's control logic for the controlled device based on the feedback signals, and send control signals to the business logic layer. The business logic layer, communicatively connected to the PLC simulation layer, acquires the control signals and performs business logic operations based on the control signals and feedback signals to calculate the simulated movement of the controlled device and obtain real-time position data. The 3D visualization layer, also communicatively connected to the business logic layer, displays the operating status of the controlled device based on a pre-built virtual model of the controlled device and the real-time position data to demonstrate the PLC program's execution results. It also generates feedback signals based on virtual sensors on the virtual model of the controlled device and sends them to the business logic layer. This configuration provides a safe and low-cost virtual environment for running and simulating PLC programs, enabling engineers to perform logic verification and debugging of PLC programs without relying on actual physical equipment. By receiving feedback signals and simulating the PLC's control logic over the controlled equipment, potential problems in the PLC program can be quickly identified and resolved in a virtual environment, reducing equipment downtime and production losses caused by program errors in real production environments. It allows for the early exposure of compatibility and functional issues between the PLC program and the controlled equipment before actual installation and commissioning. This helps optimize the program logic, ensuring the stability and reliability of the PLC program in actual operation and reducing project implementation risks. Optimizing the PLC program based on feedback signals improves the accuracy and efficiency of the control logic. This not only helps improve the operating performance of the controlled equipment but also enables more complex control strategies, enhancing the automation and intelligence of the production process. Attached Figure Description

[0043] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0044] Figure 1 This is a schematic diagram of a digital twin virtual debugging system for a conveyor line based on a B / S architecture, provided in one embodiment of this application.

[0045] Figure 2 This is a schematic diagram of signal flow in a closed-loop feedback mechanism provided in one embodiment of this application.

[0046] Figure 3 This application provides a technical approach for the data interaction and business processing layer (backend) in one embodiment.

[0047] Figure 4 This is a flowchart illustrating a B / S architecture-based digital twin virtual debugging method for a conveyor line, provided in one embodiment of this application.

[0048] Figure 5 This is a schematic diagram of an electronic device structure provided in one embodiment of this application. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0050] In the process of upgrading to intelligent manufacturing, the demand for flexible production lines in discrete manufacturing industries has placed higher requirements on equipment debugging efficiency. Traditional physical debugging methods rely on on-site joint debugging of mechanical, electrical, and control systems, which has industry challenges such as long debugging cycles, high trial-and-error costs, and difficulties in cross-regional collaboration. Especially in complex conveyor line scenarios, PLC program logic verification requires repeated start-ups and shutdowns of real equipment, which not only aggravates mechanical wear but may also cause cascading failures due to sensor signal feedback delays.

[0051] In recent years, the B / S architecture (Browser / Server) has been widely used in the manufacturing industry, and WebGL technology has made high-precision 3D rendering on the browser side possible. However, existing B / S architecture digital twin systems still face core challenges such as the lack of real-time signal closed-loop, low efficiency of dynamic mapping between virtual and physical equipment, and insufficient sensor simulation accuracy, making it difficult to meet the millisecond-level real-time interaction and high-fidelity virtual-physical synchronization requirements for conveyor line debugging.

[0052] This invention addresses the aforementioned technical bottlenecks by proposing a digital twin virtual debugging system for conveyor lines based on a B / S architecture. It employs a layered decoupling design of the PLC simulation layer, business logic layer, and 3D visualization layer, combined with Redis message middleware to achieve asynchronous cross-layer transmission of control signals and equipment status. A closed-loop feedback mechanism is constructed: "virtual device action → front-end sensor trigger → PLC response → model update," supporting modular simulation of industrial sensors such as photoelectric / proximity switches. Dynamic equipment instantiation generation technology is developed to achieve automatic mapping from Three.js 3D configuration parameters to Spring Boot backend device objects. Based on existing equipment models, this system and debugging method significantly reduce the dependence of debugging on physical equipment, providing a lightweight, high-real-time virtual debugging infrastructure for intelligent manufacturing.

[0053] After introducing the basic principles of this application, various non-limiting embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0054] Reference Figure 1 , Figure 2 This application provides a digital twin virtual debugging system for a conveyor line based on a B / S architecture, comprising a three-layer B / S architecture consisting of a PLC simulation layer, a business logic layer, and a three-dimensional visualization layer.

[0055] PLC simulation layer: used to run PLC programs, simulate the PLC programs, obtain feedback signals from the controlled devices, simulate the PLC's control logic for the controlled devices based on the feedback signals, and send control signals to the business logic layer;

[0056] The business logic layer is communicatively connected to the PLC simulation layer. It is used to acquire the control signals and perform business logic operations based on the control signals and the feedback signals to calculate the motion of the simulated controlled equipment and obtain real-time position data.

[0057] 3D visualization layer: Communicatively connected to the business logic layer, used to display the operating status of the controlled equipment based on a pre-built virtual model of the controlled equipment and the real-time location data to show the running results of the PLC program, and generate feedback signals based on virtual sensors on the virtual model of the controlled equipment and send them to the business logic layer.

[0058] Specifically, this system can be used for virtual debugging and optimization of PLC code in conveyor systems in discrete manufacturing, logistics and warehousing, and other fields. PLC debugging personnel can then use the virtual PLC and the virtual debugging system designed in this invention to accurately and in real time view the running effect of the virtual PLC code, facilitating PLC code debugging and optimization by engineers.

[0059] The system designed in this invention mainly consists of three parts: a PLC simulation layer (PLC control and simulation part, which can be based on Siemens TIA Portal and PLC Sim Advance), a business logic layer (data interaction and business processing part, i.e., the backend, which can preferably be developed using the Spring Boot framework of Java, or other technologies such as the Django or Flask framework of Python, or the Node.js framework based on JavaScript), and a 3D visualization layer (3D visualization part, i.e., the frontend, which can be based on the Three.js framework).

[0060] Specifically, the PLC simulation layer includes: a PLC programming submodule for writing the PLC program; and a PLC simulation submodule for simulating the PLC program to simulate the PLC's control logic for the controlled device.

[0061] Technology Stack: Siemens TIA Portal, PLC Sim Advance. Using PLC Sim Advance software, Siemens PLCs (S1500 or S200, etc.) can be simulated. PLC debugging engineers can write PLC programs using TIA Portal software. These PLC programs are essentially consistent with the actual PLC programs in the field. This PLC program is then burned into the PLC Sim Advance software. With the help of the virtual debugging system designed in this invention application, the PLC program can be debugged and optimized based on the real-time operating effect of the equipment displayed in the 3D visualization section, realizing the virtual debugging and optimization function of PLC programs under a digital twin-based B / S architecture.

[0062] The business logic layer includes: a signal processing submodule for processing control signals generated by the PLC program simulation and feedback signals from the controlled device; a business logic operation submodule for performing business logic operations based on the signals processed by the signal processing submodule; a configuration management submodule for managing the configuration information of the controlled device and generating corresponding controlled devices based on the configuration information; and a kinematics calculation submodule for calculating the motion state of the controlled device and obtaining real-time position data based on the operation results of the business logic operation submodule and the dynamic model of the controlled device.

[0063] Technology stack: SpringBoot + Redis + JSON / XML configuration files + RESTful API + WebSocket protocol + Snap7 protocol;

[0064] Reference Figure 3 The data interaction section is as follows:

[0065] Communication between the front-end and back-end uses the WebSocket protocol for real-time data transmission. The back-end and PLC simulation layer use a Redis message queue to achieve asynchronous decoupling of signals and data. In Spring Boot, data in the DB data block of the Siemens S1500 virtual PLC is directly read and written via the Snap7 protocol.

[0066] Furthermore, other technologies such as Server-Sent Events (SSE) or HTTP Long-Polling can also be used to achieve similar functionality in certain scenarios.

[0067] The business processing section is as follows: The business processing section is mainly divided into the following functional modules: parsing the front-end JSON configuration file to generate virtual device classes, PLC signal synchronization, calculation of cargo movement in a single device, transfer and transportation of cargo in connected devices, calculation of device sensor positions, WebSocket message push, and functions for generating cargo at the inbound station and deleting completed cargo at the outbound station.

[0068] Front-end JSON configuration file parsing to generate virtual device class function

[0069] The system uses Spring Boot's property configuration annotations to automatically map YAML configurations. After editing on the front-end, the generated configuration file is pushed to the server. The configuration file defines device instances, each corresponding to a pre-defined type template. The device type template includes attributes such as device ID, entrance / exit topology, kinematic parameters (velocity / acceleration), and geometric path points (3D coordinates). The back-end automatically injects the device list from the YAML into a strongly typed collection using property configuration annotations. When the YAML configuration file changes, Spring's refresh scope annotation module, in conjunction with a file listener service, triggers configuration reloading.

[0070] PLC signal synchronization function, Redis connection maintenance and exception recovery

[0071] The system retrieves PLC signal data from Redis at fixed intervals using deserialization. A scheduled task monitors the Redis connection status; if a query returns an error, a reconnection operation is initiated. This mechanism ensures that the system automatically restores the data channel after a 5-second initial delay following network fluctuations or a Redis service restart, providing a fundamental guarantee for PLC signal synchronization. Atomic signal updates are implemented, using atomic variables to store Boolean, Integer, and Long signals respectively, avoiding variable conflicts during multi-threaded access. Atomic variables are pre-defined based on the signal enumeration class during initialization, allowing direct manipulation of these variables and preventing concurrent conflicts when updating PLC data via multiple threads. The system retrieves PLC signal data from Redis at fixed intervals, processes it into three categories based on device type, iterates through device instances, and continuously updates Boolean signals such as forward / reverse / high-speed.

[0072] Cargo movement calculation function in a single unit

[0073] Cargo Motion Calculation and Status Update Process: The system drives global cargo position updates through timed tasks and employs a hierarchical processing mechanism for differentiated calculations for different types of equipment. First, the system analyzes the equipment's operating status based on PLC control signals: by combining forward and reverse signals, it determines whether the equipment is stationary, running forward, running in reverse, or in an abnormal state, dynamically matching preset kinematic parameters (such as maximum speed and acceleration). For running equipment, based on the path start and end point coordinates, current progress, and acceleration function, a linear interpolation algorithm is used to calculate the cargo displacement, updating the three-dimensional spatial coordinates and motion progress in real time.

[0074] Linear interpolation calculation: The displacement of goods on the equipment path is calculated using normalized schedule parameters. Interpolate within the range [0,1]:

[0075] in and These are the three-dimensional coordinates of the path's start and end points, respectively. It is calculated from speed and time.

[0076] Acceleration integral model: When the device is in a state of uniform acceleration, the instantaneous velocity and displacement increment The calculation is as follows:

[0077] in Here, is the initial velocity, and is the acceleration. For time intervals (defined by time calculation).

[0078] Variable acceleration motion processing: If the acceleration varies with time (e.g., sudden stop or gentle start-stop), the displacement is calculated using piecewise integration.

[0079]

[0080] Numerical solution is achieved by discretizing the time step, ensuring trajectory smoothness under complex working conditions.

[0081] Formula 1 is the interpolation logic, which generates a continuous trajectory using the coordinates of path points;

[0082] Formulas 2-3 are the core algorithm, supporting both constant and variable acceleration modes;

[0083] Kinematic Model and Anomaly Handling Mechanism: A corresponding calculation model is selected based on the equipment's running direction: for forward motion, a dynamic acceleration integral algorithm is used, combined with time intervals to calculate instantaneous velocity and displacement; for reverse motion, inverse trajectory calculation is performed based on deceleration parameters. During calculation, the integrity of path points is checked in real time; calculations are terminated and alarms are triggered for equipment with abnormal configurations. When initializing the cargo position, the system automatically locates the path start point and generates an initial pose along the equipment's orientation vector. A thread-safe data update strategy is employed to ensure the consistency of position states during concurrent calculations by multiple devices.

[0084] The cargo transfer system, based on the equipment connection topology, polls the readiness status of adjacent devices in real time. When cargo is detected to have completed movement on the current device, a multi-level verification process is initiated: first, the electrical interlock logic between the current device's release signal and the target device's receiving signal is verified; second, mechanical compatibility is checked (e.g., the transfer machine is in position, and the roller conveyor's running direction); finally, a capacity check ensures that the target device can carry the cargo. If any condition is not met, the transfer is paused and a status log is recorded.

[0085] Differentiated strategies for cargo transportation are designed for different equipment combinations:

[0086] Direct transfer between roller conveyors uses a coordinate mapping algorithm to move goods from the end of the current equipment to the starting point of the target equipment, requiring the axes of the two equipment to be aligned and their speeds to be matched. For roller conveyor-transfer machine coordination, synchronous verification of the transfer machine's vertical positioning signal (UP / DN) is necessary.

[0087] A dual detection and rollback mechanism is introduced to ensure reliability: the device status is locked during the transfer process to avoid positional errors caused by concurrent modifications; if the transfer takes more than 500ms, the goods are automatically returned to the end of the source device and an alarm is triggered.

[0088] Device sensor position calculation function

[0089] For each type of equipment, if there are sensors on the equipment that need to be moved (such as proximity switch sensors on a hoist), the global coordinates of the sensors are dynamically updated based on the equipment displacement (such as the hoist's lifting height) and rotation matrix when the equipment moves, according to the sensor reference installation position defined in the configuration file.

[0090] WebSocket communication mechanism

[0091] The system integrates WebSocket service based on Spring Boot to achieve full-duplex real-time communication between the browser and the backend: The server maintains a long-connection session pool, and after the frontend establishes a connection via the ws: / / protocol, it uses the Protobuf protocol to compress and transmit data packets. The message types are divided into two categories: world coordinates of all goods (incremental update period of 100ms) and sensor location (incremental update period of 100ms). The server supports multiple clients to concurrently subscribe to the same scenario through a message partitioning and routing mechanism. In case of abnormal disconnection, message sending is paused and automatic reconnection is attempted. After reconnection, the latest status is synchronized. At the same time, a built-in heartbeat detection and flow control strategy is implemented to ensure the stability and real-time performance of communication in high-concurrency scenarios (end-to-end latency <200ms).

[0092] The 3D visualization layer includes: a scene construction submodule for constructing a virtual model of the controlled device; a model loading and updating submodule for loading the virtual model of the controlled device in the virtual scene and updating the running status of the virtual model according to the real-time location data of the business logic layer; and a sensor simulation submodule for simulating the detection logic of sensors in the virtual scene and generating corresponding sensor signals, wherein the sensor signals are feedback signals.

[0093] (1) Building a digital twin 3D scene based on Three.js:

[0094] A high-precision industrial scene is built using the Three.js engine, loading pre-built conveyor equipment and cargo models via GLTF / GLB format. Utilizing Vue3's reactive data binding features, the motion state of equipment in the scene (such as roller conveyor rotation and transfer machine translation) is dynamically controlled. Furthermore, cargo coordinate data calculated in real-time by the backend is received via WebSocket, driving the displacement animation of the virtual cargo model.

[0095] (2) Modular simulation and batch communication configuration method for sensors

[0096] The system adopts a modular design to create and manage virtual sensors, and dynamically calculates the spatial position of sensors based on device path points.

[0097] For virtual simulation of photoelectric sensors: Based on the equipment type (such as roller conveyor, transfer machine), a sensor array with a vertical or parallel layout is automatically created. The installation position is determined by the path point coordinates and offset parameters (such as the end distance ratio of 0.1-0.15). A three-dimensional collision detection area is constructed using ray detection technology.

[0098] This application employs a sensor signal generation method based on front-end ray detection, rather than treating the entire equipment as a state machine model as used in other industry simulation methods. Its technical advantage lies in its ability to accurately simulate the nonlinear motion process of the conveyor belt under complex conditions such as speed changes, emergency stops, and flexible start-stops. It can also accurately simulate the specific timing and location of photoelectric sensor triggering when irregularly shaped goods move on the conveyor belt. This allows the system to expose and verify PLC program logic defects that are closely related to the shape of the goods, equipment acceleration / deceleration, and timing, which are often overlooked by traditional simplified simulation models, greatly improving the fidelity and reliability of virtual debugging.

[0099] The sensor type (photoelectric / proximity switch) and sensor trigger distance are defined via a JSON configuration file. The sensors are topologically sorted according to the user-defined device arrangement order, and the consistency between the actual generated quantity and the configuration is verified. An alarm log is triggered in case of anomalies, ensuring that the detection order conforms to the conveyor line control logic. When goods enter the X-ray detection range, the relevant sensor trigger parameters are dynamically updated.

[0100] During the communication between WebSocket and the backend, the system reserves several (e.g., 10,000) Boolean value slots. By manually sorting the virtual sensors of various Boolean types that have been configured and generated, the system can push the status of these sensors to the PLC simulation layer, achieving millisecond-level synchronization between physical signals and virtual detection.

[0101] (3) Configuration file generation

[0102] The system provides the ability to generate configuration files in multiple formats, supports structured storage and flexible adaptation of equipment data, defines standardized interfaces according to equipment type (roller conveyor, transfer conveyor, elevator, etc.), encapsulates core attributes such as equipment ID, path points, and sensor parameters, and ensures data integrity through type verification functions.

[0103] Furthermore, the three-dimensional visualization layer is also used to: acquire data information obtained by the physical device of the controlled device running the PLC program; and adjust the virtual model of the controlled device based on the data information.

[0104] Specifically, this includes: Data acquisition: In a real production environment, controlled physical conveyor line equipment operates according to PLC programs, generating a series of data containing key information such as equipment operating status and production data. The 3D visualization layer has the ability to acquire data from these physical devices, which may be achieved through technologies such as sensors and data acquisition systems to collect real-time or near-real-time data from the physical devices.

[0105] Virtual Model Adjustment: After acquiring the data information of the physical equipment, the 3D visualization layer adjusts the virtual model of the controlled equipment based on this data. For example, if there are some differences between the physical and virtual equipment, these differences will be reflected in the actual operation. The virtual model will be modified accordingly to ensure that the virtual model is consistent with the physical equipment in appearance, behavior, and operating logic. This adjustment involves not only the static attributes of the model (such as equipment appearance and size) but also dynamic characteristics (such as movement speed and action sequence), enabling the virtual model to accurately reflect the actual operating status of the physical equipment under the control of different PLC programs.

[0106] In this way, the 3D visualization layer integrates the real operating data of physical equipment into the display and simulation of the virtual model, further enhancing the realism and practicality of the virtual debugging system. This allows operators and engineers to more accurately observe, analyze, and optimize the control effect of the PLC program on the equipment in the virtual environment, achieving an effective combination of virtual and reality.

[0107] The method embodiments of this application can be executed through the system embodiments of this application. For details not disclosed in the method embodiments of this application, please refer to the system embodiments of this application.

[0108] Reference Figure 4 The B / S architecture-based digital twin virtual commissioning method for conveyor lines provided in this application includes the following steps:

[0109] S401 deploys a PLC simulation layer, a business logic layer, and a 3D visualization layer on the server side.

[0110] S402: A PLC program is written through the PLC programming submodule and used to run the PLC program in the PLC simulation layer. The PLC program is simulated to obtain the feedback signal of the controlled device. Based on the feedback signal, the control logic of the PLC on the controlled device is simulated and the control signal is sent to the business logic layer.

[0111] S403, receives control signals generated by the PLC program simulation through the business logic layer, and realizes asynchronous signal transmission and decoupling between the PLC simulation layer, the business logic layer and the three-dimensional visualization layer through a preset message middleware;

[0112] S404, the operating status of the virtual model of the controlled device is updated by the 3D visualization layer according to the calculation result of the business logic layer, and displayed in the client browser;

[0113] S405 simulates the sensor detection logic in the virtual scene and generates corresponding sensor signals, which are fed back to the PLC simulation layer through the message middleware to form a closed-loop signal feedback link, realizing bidirectional interaction between the virtual model and the PLC program.

[0114] In some embodiments, the method further includes: the business logic layer implements asynchronous signal transmission and decoupling between the PLC simulation layer, the business logic layer, and the 3D visualization layer through the following steps:

[0115] The business logic layer converts the control signals generated by the PLC program simulation into messages of a preset format and sends them to the message middleware;

[0116] The message middleware caches the messages and forwards them to the corresponding target modules according to preset routing rules; wherein the target modules include at least one of the PLC simulation layer and the business logic layer.

[0117] The target module receives the message from the message middleware and performs corresponding processing.

[0118] Obtain data information from the controlled device's physical device running the PLC program;

[0119] The virtual model of the controlled device is adjusted based on the data information.

[0120] In summary, the solution provided in this application constructs a three-layer B / S architecture consisting of a PLC simulation layer, a business logic layer, and a 3D visualization layer. Each layer uses Redis to achieve asynchronous decoupling of signals and data.

[0121] Based on digital twin technology, a virtual debugging scenario that maps to the physical production line 1:1 is established in the front-end 3D virtual environment. The two-way interaction between the physical equipment and the virtual model is realized through the modular simulation method of industrial sensors.

[0122] The specific process is as follows: the virtual device's action triggers the sensors (such as photoelectric sensors) in the front-end virtual scene, generating a Boolean signal consistent with the real PLC signal; this signal is fed back to the virtual PLC control logic in real time through the message middleware, driving the back-end to generate motion scripts and update the 3D model state, forming a closed-loop control link of "virtual device action → front-end sensor trigger → PLC response → model update", which meets the core requirements of high-precision replication simulation in the full life cycle management of digital twins.

[0123] The core technologies of this application are: a closed-loop feedback mechanism for simulation signals: a closed-loop mechanism of "equipment action → sensor triggering → PLC response → model update", including signal trigger priority determination rules and timing synchronization technology for status feedback. A three-layer B / S asynchronous architecture supporting virtual debugging: a layered collaborative architecture of PLC simulation layer, business logic layer, and 3D visualization layer, especially through message middleware to achieve cross-layer asynchronous transmission mechanism of control signals, equipment status, and model data. Millisecond-level synchronization technology for multi-source signals: a global timestamp alignment method for digital twin virtual-real synchronization, combined with spatiotemporal consistency verification rules for physical device signals and virtual sensor events, ensuring cross-layer signal transmission delay ≤20ms.

[0124] In some embodiments, the key aspects of modular simulation of industrial sensors in a 3D virtual environment include:

[0125] In 3D scenes such as Three.js, the triggering logic of sensors that output Boolean values ​​(True / False) such as photoelectric sensors, proximity switch sensors, and toggle switch sensors is simulated through ray detection, collision detection, and position threshold range triggering technology. It supports visual configuration of sensor type, installation location, and trigger threshold (such as detection distance and sensitivity) to achieve a high degree of simulation with physical sensors.

[0126] The digital twin sensor type library covers a variety of common industrial sensor virtual models and their corresponding triggering algorithms, such as photoelectric sensors, proximity switches, and toggle switches. Each virtual sensor model is meticulously designed based on the characteristics and functions of real sensors, accurately simulating their behavior and response patterns in actual industrial scenarios.

[0127] The system's visual configuration function greatly simplifies user operation, supporting the setting of sensor arrangement order in the virtual environment through simple drag-and-drop actions. Users do not need to write complex code; they can complete sensor layout and configuration simply through the intuitive graphical interface. The system automatically generates Boolean signals based on user-defined configuration parameters. These signals, following user-defined rules, are accurately written to the designated DB (data block) address of the PLC, thereby achieving real-time control and feedback of the PLC program.

[0128] To ensure the accuracy and reliability of sensor signals, the system employs an advanced abnormal signal filtering method. This method effectively suppresses false triggering caused by model jitter or other interference factors. Users can set the sensor jitter threshold according to actual needs; the system only determines a valid trigger signal when the sensor detects consistent results multiple times consecutively. This significantly reduces erroneous signals caused by external interference or model instability, improving the overall stability and reliability of the system.

[0129] Based on the requirements of digital twin virtual debugging, an automated mapping link is constructed between the front-end Three.js 3D scene and the back-end device instance. After the user configures the parameters such as the size, motion logic, conveying direction and sensor position of the device model (such as roller conveyor, elevator, transfer machine, etc.) in the front-end 3D visualization environment, the system automatically generates a structured configuration file (JSON / XML format), which is dynamically instantiated into a runnable device object through the Spring Boot back-end parsing engine, forming a management process of "3D configuration → digital twin generation → virtual debugging and verification".

[0130] In the backend configuration file generated by the frontend simulation environment, different configuration parameters are automatically generated for different types of devices to adapt to the backend object motion position calculation function.

[0131] Specifically, the configuration-instance automatic conversion mechanism for digital twins automatically generates a structured configuration file from the front-end 3D model parameters (size, path points, connection relationships), and dynamically instantiates it into a runnable device object through the back-end parsing engine.

[0132] This mechanism automates the conversion process from virtual model configuration to runnable device objects. Specifically, in the front-end 3D modeling environment, designers can intuitively set parameters for the 3D model of the conveyor line equipment, including key information such as equipment dimensions, pathpoint distribution on the conveyor line, and connections between devices. Once these parameters are configured, the system automatically generates structured configuration files, such as common JSON or XML formats. These configuration files record detailed parameter information of the equipment in a structured form, providing a data foundation for subsequent equipment instantiation. On the back-end, a parsing engine is deployed, whose main responsibility is to read and parse the configuration files generated by the front-end. Through parsing, the back-end understands the various parameters of the equipment and their relationships, and dynamically creates corresponding runnable device objects based on this information. This process eliminates the need to manually write large amounts of code to define device objects, greatly improving development and debugging efficiency and reducing errors that may result from manual operation. Once the device object is instantiated, it can be activated and used in the virtual debugging system to simulate and debug equipment behavior.

[0133] A dynamic parameter binding method for digital twins protects the automated mapping rules between device parameters (such as speed, device linking relationships, etc.) in the backend configuration file and backend device class attributes. This includes differentiated parameter loading logic based on device type, reducing the cost of refactoring the debugging environment. This method focuses on ensuring that device parameters in the backend configuration file can be automatically and accurately mapped to the attributes of the backend device class. The backend configuration file stores various parameters of the devices, such as the operating speed of conveyor line equipment and the linking relationships between devices. Through predefined mapping rules, the system can automatically bind the parameters in the configuration file to the corresponding attributes in the backend device class. This binding relationship is established automatically without manual intervention, greatly improving the accuracy and efficiency of configuration. This method also specifically considers the parameter differences that may exist between different device types. For different types of equipment, the system adopts differentiated parameter loading logic. For example, for devices with different functions such as roller conveyors and transfer machines, their parameter requirements and configuration methods may differ. The system can automatically load and apply the corresponding parameter configuration logic according to the device type, ensuring that each device object can be correctly initialized and run according to its own type. This differentiated processing based on device type further enhances the flexibility and adaptability of the system. In this way, the dynamic parameter binding method for digital twins not only simplifies the reconstruction process of the equipment commissioning environment but also reduces related costs. When adjustments or expansions to the conveyor line are needed, only the 3D model parameters need to be updated at the front end and the configuration file regenerated. The back end can then automatically update the parameters of the equipment objects based on the new configuration file, without requiring large-scale modifications and redeployments to the backend code. This enables the entire system to respond more quickly to equipment changes or process adjustments, improving the overall flexibility and efficiency of the system.

[0134] The calculation of the motion position of the back-end object includes:

[0135] Equipment management and PLC signal synchronization: Based on the equipment motion status signals, the movement positions of all goods on a single section of the equipment are calculated. The conveying path is abstracted into a parameterizable line segment model, and the displacement of the goods is calculated in real time using kinematic equations. It supports custom configurations for various modes such as uniform acceleration, variable acceleration, and pulse acceleration, and enables arbitrary curve changes such as emergency stops, speed changes, and reciprocating motion. The position of the goods is dynamically mapped to three-dimensional spatial coordinates according to the path scaling factor, ensuring high-precision simulation and real-time synchronization of the motion trajectory of all goods during equipment operation, meeting the flexible motion control requirements under complex working conditions.

[0136] Based on the equipment's motion status signals, calculate the transfer and transportation of goods within the connected equipment.

[0137] Based on the equipment's motion status signals, the equipment sensors perform real-time calculations.

[0138] WebSocket communication is used to push the real-time position information of all objects and the real-time status information of all sensors to the front end.

[0139] Cargo dynamic position calculation method: A real-time cargo position calculation algorithm based on PLC instructions (speed, direction) and equipment parameters (path geometry, dimensions, acceleration curves) supports nonlinear motion trajectory of cargo on a single equipment path (such as speed change, emergency stop) and continuity verification of paths between multiple equipment.

[0140] The backend position calculation function, consisting of a dynamic cargo position calculation method and inter-equipment cargo transfer rules, automatically calculates the movement position of cargo on the equipment based on PLC instructions (speed / direction) and equipment parameters (size / path), including path connection rules when transferring across equipment. It automatically detects the status of adjacent equipment (e.g., the current equipment has completed transport, the next equipment is idle), triggers cargo transfer, and converts the coordinates to the new equipment's starting point.

[0141] Specifically, the dynamic location calculation method for goods mainly involves two key aspects: real-time location calculation of goods on a single device path and location calculation and transfer rules during goods transfer between multiple devices. The following is a detailed explanation:

[0142] Real-time location calculation of goods on a single device path includes:

[0143] Based on PLC instructions and equipment parameters: By receiving speed and direction information from PLC instructions, as well as data such as path geometry, equipment size, and acceleration curves from equipment parameters, a specially designed algorithm is used to calculate the position of goods on a single equipment path in real time.

[0144] Support for nonlinear motion trajectories: The algorithm can handle nonlinear motion scenarios such as speed changes and sudden stops for goods along a single equipment path. It fully considers the impact of acceleration variations on cargo displacement, accurately simulating the actual motion state of the cargo and ensuring accurate calculation of cargo position under different motion modes.

[0145] The location calculation and transfer rules for goods transfer between multiple equipment rooms include:

[0146] Cross-device path connection: When goods need to be transferred from one device to another, the system automatically calculates the movement position of the goods on different devices according to preset rules. This requires considering factors such as the relative position between the two devices and the geometry of the path to ensure that the goods can be smoothly and accurately transferred from the end point of one device to the starting point of the next device.

[0147] Adjacent Equipment Status Detection and Cargo Transfer Triggering: The system monitors the status of adjacent equipment in real time, such as whether the current equipment has completed its transportation task and whether the next equipment is idle. When the transfer conditions are met, the system automatically triggers the cargo transfer process and transforms the cargo's coordinates to the starting coordinate system of the new equipment, ensuring seamless connection of cargo between different equipment.

[0148] In summary, the solution provided in this application adopts a layered asynchronous architecture (PLC simulation layer → business logic layer → 3D visualization layer), and uses Redis message middleware to achieve decoupled signal transmission. It constructs a closed-loop link of "equipment action → sensor triggering → PLC response → model update," and combines priority determination and spatiotemporal consistency verification rules to ensure the timing accuracy of signal feedback. Compared to the unidirectional signal transmission and interaction scheme between PLC and digital twin systems in other digital twin simulation systems, this application achieves a bidirectional closed-loop mechanism for signal information between virtual debugging and real equipment, improving the reliability of the digital twin virtual debugging logic verification in this application.

[0149] This application generates structured configuration files (JSON / XML) using a Three.js front-end visual interface, and dynamically instantiates device objects through a Spring Boot parsing engine, establishing an automated mapping link from "3D configuration to digital twin generation." It supports differentiated loading of device size, path, and sensor parameters. Compared to the inconvenient solution of restarting the entire system when changing configurations in a client-server architecture digital twin simulation system, this application supports dynamic configuration and real-time application of device parameters, significantly improving the efficiency of debugging scenario reconstruction and reducing the operational costs of multi-device collaborative debugging.

[0150] The conveying path is abstracted into a parametric mathematical model, and the cargo displacement is calculated by combining kinematic equations. A path continuity verification algorithm is used to achieve seamless connection of coordinates across devices, and the WebSocket protocol is used to synchronize cargo position and device status to a 3D visualization layer. This application calculates position based on PLC instructions and parameters such as device speed / acceleration, using incremental time, which better conforms to actual motion laws and achieves high-precision simulation.

[0151] It integrates raycasting, bounding box, and multi-frame filtering algorithms to simulate the installation position and detection logic of photoelectric / proximity switches; it supports visualized configuration of sensor sensitivity and jitter threshold, achieving a highly consistent mapping between Boolean signals and physical devices. It overcomes the limitations of simplified simulations based on device state variables, improving the accuracy of sensor signal generation and environmental adaptability.

[0152] Below, for reference Figure 5 This describes an electronic device according to embodiments of the present application. Figure 5A block diagram of an electronic device according to an embodiment of this application is illustrated.

[0153] like Figure 5 As shown, the electronic device 500 includes one or more processors 510 and memory 520.

[0154] The processor 510 may be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and may control other components in the electronic device 500 to perform desired functions.

[0155] The memory 520 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 510 may execute the program instructions to implement the B / S architecture-based digital twin virtual debugging method for transport lines and / or other desired functions described in the various embodiments of this application above. Various contents, such as category correspondences, may also be stored in the computer-readable storage medium.

[0156] In one example, the electronic device 500 may also include an input device 530 and an output device 540, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0157] In addition, the input device 530 may also include, for example, a keyboard, mouse, interface, etc. The output device 540 can output various information to the outside, including analysis results, etc. The output device 540 may include, for example, a display, speaker, printer, and communication network and its connected remote output devices, etc.

[0158] Of course, for the sake of simplicity, Figure 5 Only some of the components of the electronic device relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device may include any other suitable components depending on the specific application.

[0159] In addition to the methods and devices described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the B / S architecture-based digital twin virtual debugging method for a transport line according to various embodiments of this application as described in the "Exemplary Methods" section above.

[0160] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0161] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the B / S architecture-based digital twin virtual debugging method for a transport line according to various embodiments of this application as described in the "Exemplary Methods" section above.

[0162] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0163] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A digital twin virtual commissioning system for conveyor lines based on a B / S architecture, characterized in that, It includes a 3-layer B / S architecture consisting of a PLC simulation layer, a business logic layer, and a 3D visualization layer; PLC simulation layer: used to run PLC programs, simulate the PLC programs, obtain feedback signals from the controlled devices, simulate the PLC's control logic for the controlled devices based on the feedback signals, and send control signals to the business logic layer; wherein, the PLC simulation layer and the business logic layer achieve asynchronous decoupled communication through message middleware; The business logic layer, which is communicatively connected to the PLC simulation layer, is used to acquire the control signals, and perform business logic operations based on the control signals and the feedback signals to calculate the motion of the simulated controlled equipment and obtain real-time position data; and sends the real-time position data to the 3D visualization layer, wherein the business logic layer and the 3D visualization layer are connected through a real-time long connection communication protocol. 3D visualization layer: Communicatively connected to the business logic layer, it is used to display the operating status of the controlled equipment based on a pre-built virtual model of the controlled equipment and the real-time location data to demonstrate the running results of the PLC program, and to generate feedback signals based on virtual sensors on the virtual model of the controlled equipment and send them to the business logic layer; The business logic layer includes: Signal processing submodule: used to process control signals generated by the PLC program simulation and feedback signals from the controlled device; Business logic operation submodule: used to perform business logic operations based on the signals processed by the signal processing submodule; Configuration Management Submodule: Used to manage the configuration information of the controlled devices and generate corresponding controlled devices based on the configuration information; Kinematics calculation submodule: used to calculate the motion state of the controlled device and obtain real-time position data based on the calculation results of the business logic operation submodule and the dynamic model of the controlled device; The 3D visualization layer includes: Scene building submodule: used to build virtual models of controlled devices; Model loading and updating submodule: used to load the virtual model of the controlled device in the virtual scene, and update the running status of the virtual model according to the real-time location data of the business logic layer; Sensor simulation submodule: used to simulate the detection logic of sensors in the virtual scene and generate corresponding sensor signals; wherein the sensor signals are feedback signals; The business logic layer and the 3D visualization layer communicate using the WebSocket protocol to achieve real-time data transmission. The PLC simulation layer and the business logic layer use a Redis message queue to achieve asynchronous decoupling of signals and data. The 3D visualization layer is also used to: acquire data information obtained by the physical device of the controlled equipment running the PLC program; and adjust the virtual model of the controlled equipment based on the data information.

2. The B / S architecture-based digital twin virtual debugging system for conveyor lines according to claim 1, characterized in that: The PLC simulation layer includes: PLC programming submodule: used to write the PLC program; PLC simulation submodule: used to simulate the PLC program to simulate the PLC's control logic for the controlled equipment.

3. A digital twin virtual debugging method for conveyor lines based on a B / S architecture, characterized in that, The method, applied to the B / S architecture-based digital twin virtual commissioning system for conveyor lines as described in any one of claims 1 to 2, comprises the following steps: Deploy a PLC simulation layer, a business logic layer, and a 3D visualization layer on the server side; The PLC program is written through the PLC programming submodule and used to run the PLC program in the PLC simulation layer. The PLC program is simulated to obtain feedback signals from the controlled device. Based on the feedback signals, the control logic of the PLC on the controlled device is simulated and control signals are sent to the business logic layer. The business logic layer receives control signals generated by the PLC program simulation and uses a preset message middleware to achieve asynchronous signal transmission and decoupling between the PLC simulation layer, the business logic layer and the 3D visualization layer. The virtual model of the controlled device is updated in the 3D visualization layer according to the calculation results of the business logic layer, and then displayed in the client browser. The detection logic of the sensor is simulated in the virtual scene, and the corresponding sensor signal is generated. The signal is fed back to the PLC simulation layer through the message middleware to form a closed-loop signal feedback link, thereby realizing bidirectional interaction between the virtual model and the PLC program.

4. The digital twin virtual debugging method for conveyor lines based on B / S architecture according to claim 3, characterized in that, The business logic layer achieves asynchronous signal transmission and decoupling between the PLC simulation layer, the business logic layer, and the 3D visualization layer through the following steps: The business logic layer converts the control signals generated by the PLC program simulation into messages of a preset format and sends them to the message middleware; The message middleware caches the messages and forwards them to the corresponding target modules according to preset routing rules; wherein the target modules include at least one of the PLC simulation layer and the business logic layer. The target module receives the message from the message middleware and performs corresponding processing.

5. The digital twin virtual debugging method for conveyor lines based on B / S architecture according to claim 3, characterized in that, Also includes: Obtain data information from the controlled device's physical device running the PLC program; The virtual model of the controlled device is adjusted based on the data information.

6. An electronic device, characterized in that, include: A processor, and a memory for storing a processor-executable program; The processor is configured to implement the B / S architecture-based digital twin virtual debugging method for transport lines as described in any one of claims 3 to 5 by running the program in the memory.

Images