Containerization virtual PLC system of Internet of Things based on star flash

Abstract

The invention defines an Internet of Things containerization virtual PLC system based on star flash. The system comprises a cloud server, at least one fog end node, a star flash wireless communication module and field end equipment, two normal forms are converted: 1, a dynamic migration normal form of control logic is realized, and a PLC is not a static entity bound to specific hardware but a control unit capable of flexibly scheduling and seamlessly migrating among computing power nodes through containerization and thermal migration technologies, so that the system availability and the resource utilization rate are fundamentally improved; and 2, a wireless normal form of field communication initiatively establishes a star flash technology as a core communication link of a virtual PLC and field equipment, and a deterministic wireless link provided by the wireless normal form effectively solves the core bottleneck of uncontrollable time delay and reliability of the traditional wireless technology, so that industrial-grade control is possible to get rid of wired constraint. Through the synergistic effect of the two normal forms, the containerized virtual control system which is high in toughness and flexibility and extremely flexible in deployment, operation and maintenance is jointly formed.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of industrial control and Internet of Things (IoT) technology, specifically involving a programmable logic controller (PLC) system architecture based on containerization, virtualization, and novel wireless communication technologies, and more particularly an IoT containerized virtual PLC system based on SparkLink LowEnergy (SLE). Background Technology

[0002] In industrial control systems, programmable logic controllers (PLCs) have always been the core device for achieving low-level automation. However, with the advancement of Industry 4.0 and smart manufacturing, the traditional PLC architecture is increasingly revealing two major bottlenecks: First, there is a serious hardware dependency problem. Traditional PLCs adopt an architecture that deeply binds dedicated hardware to the control system, which makes it difficult to upgrade functions, has a long fault recovery cycle, and makes it difficult to flexibly allocate system resources, thus failing to meet the requirements of modern intelligent manufacturing for flexibility and adaptability.

[0003] Secondly, there is the issue of flexibility in field-level communication. Although wireless communication technologies (such as ZigBee, Wi-Fi, and Bluetooth) have been explored in the Industrial Internet of Things, the inherent high latency and jitter of their communication protocols make it difficult to meet the millisecond-level real-time control requirements of factory automation in terms of key indicators such as packet loss rate and transmission delay. As a result, most high-reliability control loops still rely on wired connections.

[0004] To decouple hardware, containerized virtual PLC technology has emerged. However, existing containerization solutions mostly focus on achieving portable software deployment and environmental isolation. Their control instances remain relatively static after operation, lacking the ability to migrate online and seamlessly between heterogeneous hardware nodes, thus failing to fundamentally improve system high availability. Furthermore, even with virtualization, communication with field devices still largely relies on traditional wired or unreliable wireless methods, limiting the overall flexibility and reliability of the system. Therefore, the industry urgently needs a new control system architecture that can deeply integrate dynamic scheduling of computing resources with field-level deterministic wireless communication. Summary of the Invention

[0005] This invention aims to overcome the limitations of existing virtual PLC systems in terms of dynamic migration of control logic and field-level deterministic wireless communication, and provides a new containerized virtual PLC architecture that supports online hot migration and highly reliable wireless control.

[0006] Technical solution A containerized virtual PLC system for IoT based on StarSpark includes: a cloud server, at least one fog node, a StarSpark wireless communication module, and field devices; The cloud server deploys a container management service based on the OPC UA protocol, and uses a server / client subscription mechanism to publish container migration and runtime status maintenance functions. The cloud server is connected to several fog-end containerized virtual PLC nodes via a network; The fog node is deployed on an embedded hardware platform and uses containerization technology to encapsulate the virtual PLC runtime environment. The fog terminal node and the field terminal equipment are connected through the Star Flash wireless communication module. By utilizing the negotiable timing parameters and high anti-interference characteristics of Star Flash wireless communication, reliable and deterministic transmission of industrial protocol data can be achieved.

[0007] The field-end equipment includes sensors and actuators, receives control commands and uploads collected data through the StarScan module; the equipment needs to integrate industrial protocol slave services to parse commands, encapsulate data, and implement a data type conversion engine and anomaly protection mechanism; The industrial control logic and its dependent environment, including the virtual PLC runtime, communication module, and device driver library components, are encapsulated into a standardized container image; the container migration process enables the migration and dynamic reconstruction of containers between fog nodes.

[0008] Specifically, The container image, through declarative configuration, transforms the complex industrial software environment that originally required multiple configuration steps into a pre-configured, directly deployable, and version-manageable atomic unit, thereby simplifying deployment and maintenance on edge devices.

[0009] The container migration process includes: independently copying persistent data through volume mounting; creating checkpoint files for the running container on the source host node and packaging and transmitting them to the target host node; and performing state recovery on the target node using the same container image and configuration parameters, where the configuration parameters include device mapping, network mode, and mount point definition. Furthermore, the container migration process also includes a peripheral state consistency maintenance step. By placing the containerized application in a recoverable state point before migration and rebinding physical peripherals such as GPIO and serial communication ports on the target end, seamless switching of control output is ensured. The introduction of physical peripheral state consistency check overcomes the problem that existing container migration functions do not consider state consistency, which may lead to control interruption.

[0010] Control commands are transmitted from the cloud server to the fog node via an OPC UA channel based on the TCP / IP protocol; The fog node construction process includes: installing a container engine and user space checkpoint tools on the host operating system, developing an OPC UA client program to subscribe to cloud commands, and building a container image; the image integrates a device control library, an OPC UA client, and a virtual PLC runtime program, declares and exposes OPC UA ports, web service ports, and industrial protocol ports, and configures container startup commands and persistent storage volumes; when running the container, it needs to be bound to a serial device and mounted with a persistent volume, providing external access through port mapping; containerized deployment supports rapid fault recovery, persistent runtime status, and strong resource isolation; The configuration process for the StarShine wireless communication module includes: ensuring electrical compatibility and antenna optimization on the hardware side, establishing a serial physical connection, and presetting unified communication parameters; configuring the StarShine working mode and serial port pass-through service during module initialization, setting device identifier, transmit power, and area parameters; setting the field device as a StarShine slave / broadcaster and enabling periodic broadcasting, with the fog node actively initiating a connection as a master / scanner; after link establishment, enabling the security authentication mechanism as needed and negotiating communication parameters, including protocol layer MTU / data length extension and timing layer connection interval, slave device delay, and monitoring timeout; and verifying the reliability of data flow through the StarShine link after activating serial port pass-through. The configuration process of the StarSpark wireless communication module is dominated by a strategy-driven automated negotiation method, which solves the problems of traditional wireless solutions requiring manual parameter tuning in industrial settings and being unable to adapt to multiple service scenarios. Specifically, a communication strategy library is predefined for different control tasks (such as high-reliability, high-real-time tasks and routine data acquisition tasks). When the virtual PLC container is instantiated, the system automatically maps its service attributes to specific StarSpark parameter targets and drives the module to complete automatic initialization and link establishment. The parameter negotiation phase after link establishment is no longer a simple protocol interaction, but executes the above-mentioned strategy mapping, dynamically negotiating key parameters including the maximum transmission unit / data length extension at the protocol layer and the connection interval, slave device latency, and monitoring timeout at the timing layer. This ensures that the performance of the generated wireless link precisely matches the differentiated needs of the upper-layer industrial applications from the very beginning, achieving a precise match between communication service capabilities and control task quality.

[0011] The fog terminal node PLC control program is developed based on the IEC 61131-3 standard. After compilation, it is uploaded to the fog terminal containerized virtual PLC for execution. The program includes control algorithms and dedicated data conversion function blocks to solve the problem of floating-point transmission limitations of industrial protocols.

[0012] This invention decouples control logic from hardware, allowing the management server to dynamically schedule control tasks. For example, based on the physical location of field devices or network conditions, the virtual PLC control program can be dynamically migrated to a fog node with lower communication latency to reduce delays and interference; or, when facing hardware maintenance, load balancing, or sudden hardware failures, hot migration technology can be used to seamlessly and losslessly switch running container instances to standby nodes.

[0013] Secondly, the system of this invention possesses automated fault recovery capabilities. When a container instance fails, the system can automatically create a new healthy instance to resume control tasks within a very short time, based on the persistently stored image and configuration. This automated recovery mechanism replaces the traditional manual intervention repair mode after a PLC failure, and together with dynamic migration capabilities, ensures the high availability and continuity of industrial control operations.

[0014] Beneficial effects This invention achieves a fundamental shift in two major paradigms of industrial control systems: 1. In terms of control architecture, the system has moved from "static deployment" to "dynamic reconfiguration". Based on container hot migration technology, the system can dynamically adjust the physical location of the control logic at runtime according to the needs, realizing the leap from "static hardware binding" to "dynamic control migration" and solving the core bottleneck of hardware binding in the control system.

[0015] 2. In terms of field connectivity, the transition from "wired network" to "wireless" is achieved. By replacing the traditional wired industrial bus with the StarScan protocol, a low-latency, high-reliability wireless control channel comparable to wired networks is constructed. This is the physical foundation for seamless migration of control logic and a fundamental breakthrough in system deployment flexibility.

[0016] The synergistic effect of these two paradigms together constitutes a highly resilient, flexible, and easy-to-maintain industrial control system, providing ideal underlying support for intelligent manufacturing and edge control. Attached Figure Description

[0017] Figure 1 This is a diagram showing the overall architecture of the system of the present invention; Figure 2 This is a schematic diagram of the data and control command flow of a specific embodiment 1 of the system of the present invention; Figure 3 This is a schematic diagram of the fog terminal controller on a Raspberry Pi 5 platform in a specific embodiment 1 of the system of the present invention; Figure 4 This is a schematic diagram of the BeagleBoneGreen Wireless development board used for simulating production environments and field endpoints in a specific embodiment 1 of the system of the present invention; Figure 5This is a schematic diagram of the principle of a four-water-tank simulated production environment in a specific embodiment 1 of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0019] A StarSpark-based IoT containerized virtual PLC system includes: a cloud server, at least one fog-end containerized virtual PLC node, a StarSpark wireless communication module, and field devices; such as Figure 1 .

[0020] Figure 2 This is a schematic diagram of the data and control command flow of the IoT containerized virtual PLC system based on StarFlash as described in this invention.

[0021] Example 1 The specific process of using the system of this invention in a four-tank process control system includes the following steps: S1: First, configure the cloud server. Develop an OPC UA server-side program, which needs to be based on a server / client subscription mechanism to publish container migration and container runtime state maintenance functions. Control commands are transmitted to the fog-end containerized virtual PLC node via an OPC UA channel based on the Ethernet TCP / IP protocol. Physical connections between devices can be established via Wi-Fi, etc., ensuring that all devices are in the same network domain. In this embodiment, the TCP port is opened as the OPC UA communication port. The specific execution flow of the container migration program includes: independently copying and transmitting persistent data through volume mounting; subsequently, creating a checkpoint for the running container on the source host node, packaging the checkpoint file and transmitting it to the target host node; finally, performing container state recovery operations on the target host node using the same container image and configuration parameters (including device mapping, network mode, and mount point). During the container migration process, special attention should be paid to the state consistency of physical peripherals such as GPIO interfaces and serial communication ports. Before actually performing the migration operation, the containerized application should be placed at a recovery point that ensures state consistency, and the peripherals should be rebound on the target end.

[0022] S2: Construct a containerized virtual PLC node. This virtual PLC is deployed as a fog-end computing node to control field physical devices. The containerized deployment mode supports container migration, rapid fault recovery, and persistent storage of operating status for the virtual PLC, improving the robustness and deployment flexibility of the controller. Simultaneously, leveraging the strong isolation characteristics of container technology, it effectively enhances the security of the control system. The specific operations for constructing a fog-end containerized virtual PLC in S2 include: S21: As Figure 3 As shown, prepare two Raspberry Pi hardware devices. Use an image writing tool to flash the operating system and install the container engine and CRIU (Checkpoint / Restore in Userspace) userspace checkpoint tool on the system. Develop an OPC UA client program and pull the OpenPLC Runtime source code. First, deploy a temporary OPC UA client on the host operating system to maintain a management connection with the cloud server and receive critical commands before container startup and during container migration. S22: Write the Dockerfile build file. Key configurations include: installing compilation dependencies based on the operating system base image; deploying the GPIO control library and OPC UA client dependency library; copying the OPC UA client program developed in S21 into the image; importing the local OpenPLC runtime source code and then performing OpenPLC compilation and image layer solidification; declaring and exposing the communication ports required for program execution; setting the container startup command to point to the virtual PLC runtime and the OPC UA client program deployed within the container; and defining the persistent storage volume VOLUME / docker_persistent. After the container starts successfully, the temporary OPC UA client process on the host machine is immediately stopped to avoid conflicts between communication ports and logic, thus completing a smooth handover of control communication responsibilities.

[0023] S23: Run the built container image. Precise configuration of port mapping, serial device binding, and persistent volume mount parameters is required at startup. Finally, verify the functional integrity and operational consistency of the container migration process by executing the OPC UA server-side test program.

[0024] S3: Configure the StarFlash Low Power (SLE) wireless communication module to achieve reliable data transmission between the fog terminal virtual controller and field sensors. The specific implementation steps are as follows: During the hardware and electrical matching phase, ensure the module uses a 3.3V logic level, the power system has sufficient current redundancy and the antenna layout design is optimized, and physical connections strictly adhere to the principles of cross-interconnection of inputs and outputs and common grounding. Pre-set unified serial communication parameters at both communication ends, and verify the exclusive use of serial port resources. Complete device initialization configuration, set the module to Starflash Low Power (SLE) operating mode and enable serial port pass-through service, and simultaneously configure the device's readable identifier (name / address), transmit power, and regional compliance parameters. During link establishment, define the end connected to the field sensor as the slave / broadcast end (Peripheral / Advertiser), enable periodic broadcasting and set the broadcast interval and load data, and define the containerized virtual PLC active end of the fog end computing node as the master / scanner end (Central / Scanner). After performing device scanning, initiate a connection request based on the target address. After link establishment, enable security mechanisms as needed (authentication-free mode or paired encryption mode), and negotiate communication parameters through pre-defined communication strategies for this type of process control task—including MTU size / data length extension (DLE) at the protocol layer and connection interval (Conn Interval) and slave device delay (Slave). Latency and Supervision Timeout are used to balance real-time performance, throughput, and connection stability. Then, the serial port pass-through status at both ends is activated (notification / indication features are enabled) to verify the reliable transmission of local UART data streams through the SLE link after being encapsulated by the module. Finally, bidirectional communication tests are performed to verify system connectivity and robustness (covering packet loss, jitter, reconnection scenarios, and critical signal strength environments), and the effective configuration is written to the module's non-volatile memory to ensure consistent power-on self-starting behavior.

[0025] S4: This example uses Figure 4 The BeagleBone Green Wireless development board shown is used to build a simulated production environment. This hardware platform acts as a sensor node for field devices, responsible for transmitting real-time data and driving the simulated production equipment to verify the system's feasibility. The simulation object is the four-tank process control system proposed by Karl Henrik Johansson in 2000 (see [link to structural principle]). Figure 5 It injects water into four coupled water tanks through dual water pumps, and uses valves to adjust the water flow distribution ratio. , The simulation was conducted using a nonlinear state-space model established based on the law of conservation of mass and Bernoulli's equation. In this model, sensors collect the liquid level height of each water tank in real time. The mist terminal PLC controls the water pump to do work by adjusting the output voltage based on the direct proportional relationship between the output power of the water pump and its input voltage (V), thereby achieving tracking control of the liquid level.

[0026] In this system, the liquid level sensors and water pumps configured in each water tank constitute the field-end equipment; the mist-end containerized virtual PLC carries the liquid level tracking control algorithm; the two interact with each other through a star-flash wireless communication module. Specifically, the star-flash wireless communication module is responsible for uploading the liquid level data from the field end to the mist-end PLC and sending the control commands generated by the PLC to the water pump actuators at the field end, thus forming a closed-loop control. The dynamic characteristics of the system are described by the following set of nonlinear differential equations: in Water tank Cross-sectional area; Water tank Cross-sectional area of ​​the outlet hole; Water tank Water level; Gravitational acceleration; Water pump Voltage; Valve water flow distribution ratio; In this example They were set to (0.071cm², 0.057cm², 0.071cm², 0.057cm²) respectively. They were set to (28 cm², 32 cm², 28 cm², 32 cm²) respectively. The values ​​were set to (0.7, 0.6), the initial water levels were (12.4 cm, 12.7 cm, 1.8 cm, 1.4 cm), and the initial voltage was... Using (3.0V, 3.0V), and based on the aforementioned dynamic model and parameters, a simulation environment program is built using Python. This program integrates the Modbus communication protocol to realize data interaction and establish a Modbus RTU slave station. It amplifies the water level values ​​of tanks 1 and 2 by 1000 times and writes them into the holding register starting at address %IW100 (because the Modbus RTU protocol does not natively support floating-point transmission, it is necessary to convert the three decimal places to integer data). It synchronously reads control instructions from the holding register starting at address %IW100 and combines two consecutive 16-bit words into a 32-bit REAL floating-point number. The program has built-in voltage limiting protection, a data type conversion engine, and a communication status monitoring mechanism to ensure the functional integrity of the system under abnormal operating conditions.

[0027] S5: Write a control program using a language supported by the IEC 61131-3 standard to implement a control algorithm that adjusts the water level towards the setpoint. Taking the PID algorithm as an example, the mathematical formula for the PID algorithm is as follows: in Proportional gain is an adjustment parameter. Integral gain is also a tuning parameter. Differential gain is also a tuning parameter; Error = Setpoint (SP) - Feedback (PV); Current time; Integral variable, the value from 0 to the present time. ; Algorithm output; When the algorithm inputs data to three decimal places (i.e., multiplied by 1000), the recommended parameter settings for PID1 controlling water pump 1 are as follows: =0.0015, =30.0, =0), the recommended parameter settings for PID2 to control water pump 2 are as follows: ( =0.00135, =40.0, =0). Given that the OPENPLC's built-in PID algorithm outputs in 32-bit REAL format and the Modbus RTU protocol does not support floating-point data transmission, a dedicated function module needs to be developed to manually deconstruct the REAL data using the memcpy function and convert it into two consecutive 16-bit WORDs in high-low order for transmission. After compiling the program code containing this function block, it should be uploaded to the corresponding port of the containerized virtual PLC via the server and executed. When the system is running normally, the simulation environment water level should converge according to the preset setting value. Key indicators such as the star link transmission delay and container migration delay should meet the real-time control requirements, and the cloud server should be able to fully execute virtual PLC parameter configuration, container status maintenance, and cross-node migration operations.

[0028] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A containerized virtual PLC system for the Internet of Things based on StarFlash, characterized in that, Includes: cloud server, at least one fog node, StarFlash wireless communication module and field terminal equipment; The cloud server deploys a container management service based on the OPC UA protocol, and uses a server / client subscription mechanism to publish container migration and runtime status maintenance functions. The cloud server is connected to several fog-end containerized virtual PLC nodes via a network; The fog node is deployed on an embedded hardware platform and uses containerization technology to encapsulate the virtual PLC runtime environment. The fog terminal node and the field terminal device are connected through the Star Flash wireless communication module. By utilizing the negotiable timing parameters and high anti-interference characteristics of Star Flash wireless communication, reliable and deterministic transmission of industrial protocol data can be achieved. The field-end equipment includes sensors and actuators, receives control commands and uploads collected data through the StarScan module; the equipment needs to integrate industrial protocol slave services to parse commands, encapsulate data, and implement a data type conversion engine and anomaly protection mechanism; The industrial control logic and its dependent environment, including the virtual PLC runtime, communication module, and device driver library components, are encapsulated into a standardized container image; the container migration process enables the migration and dynamic reconstruction of containers between fog nodes.

2. The system as described in claim 1, characterized in that, The container image, through declarative configuration, transforms the industrial software environment into a pre-configured, directly deployable, and version-manageable atomic unit, thereby simplifying deployment and maintenance on edge devices. The container migration process includes: independently copying persistent data through volume mounting; creating a checkpoint file for the running container on the source host node and packaging and transmitting it to the target host node; and performing state recovery on the target node using the same container image and configuration parameters, where the configuration parameters include device mapping, network mode, and mount point definition.

3. The system as described in claim 2, characterized in that, The container migration process also includes a peripheral state consistency maintenance step, which involves placing the containerized application in a recoverable state before migration and rebinding physical peripherals such as GPIO and serial communication ports on the target end to ensure seamless switching of control outputs.

4. The system as described in claim 1, characterized in that, The fog node construction process includes: installing a container engine and user space checkpoint tools on the host operating system, developing an OPC UA client program to subscribe to cloud commands, and building a container image; the container image integrates a device control library, an OPC UA client, and a virtual PLC runtime program, declares and exposes OPC UA ports, web service ports, and industrial protocol ports, and configures container startup commands and persistent storage volumes; when running the container, it needs to be bound to a serial device and mounted with a persistent volume, providing external access through port mapping; containerized deployment supports rapid fault recovery, persistent runtime status, and strong resource isolation.

5. The system as described in claim 1, characterized in that, The configuration process for the StarShine wireless communication module includes: ensuring electrical compatibility and antenna optimization on the hardware side, establishing a serial physical connection, and presetting unified communication parameters; configuring the StarShine working mode and serial port pass-through service during module initialization, setting device identifier, transmit power, and area parameters; setting the field device as a StarShine slave / broadcaster and enabling periodic broadcasting, with the fog node actively initiating a connection as a master / scanner; after link establishment, enabling the security authentication mechanism as needed and negotiating communication parameters, including protocol layer MTU / data length extension and timing layer connection interval, slave device delay, and monitoring timeout; and verifying the reliability of data flow through the StarShine link after activating serial port pass-through. The configuration process of the StarSpark wireless communication module is dominated by a policy-driven automated negotiation method, which solves the problems of traditional wireless solutions requiring manual parameter tuning in industrial fields and being unable to adapt to multiple service scenarios. A communication policy library for different control tasks is predefined. When the virtual PLC container is instantiated, the system automatically maps its service attributes to specific StarSpark parameter targets and drives the module to complete automatic initialization and link establishment. The parameter negotiation process after link establishment executes the above policy mapping, and dynamically negotiates the maximum transmission unit / data length extension at the protocol layer and the connection interval, slave device delay, and monitoring timeout parameters at the timing layer, ensuring that the performance of the generated wireless link accurately matches the differentiated needs of the upper-layer industrial applications from the very beginning.

6. The system as described in claim 1, characterized in that, The fog terminal node PLC control program is developed based on the IEC 61131-3 standard. After compilation, it is uploaded to the fog terminal containerized virtual PLC for execution. The program includes control algorithms and dedicated data conversion function blocks to solve the problem of floating-point transmission limitations of industrial protocols.

Images