Industrial protocol simulation method and system

Abstract

The invention discloses an industrial protocol simulation method and system, and belongs to the technical field of industrial simulation, and the method comprises the following steps: creating simulation equipment; determining configuration information according to the simulation equipment; measuring point data is generated according to the configuration information, and the measuring point data is stored in a memory database; and establishing communication connection between the simulation equipment and external equipment by using the protocol plug-in container so as to read the measuring point data in the memory database and write the external data into the memory database. Communication connection between the simulation device and the external device is established through the protocol plug-in container, connection is established through the corresponding protocol plug-in container for devices using different protocols, only the protocol plug-in container needs to be added when protocols need to be added, the whole system does not need to be reconstructed, and the requirements of different industries and enterprises for new protocol support are met.

Description

Technical Field

[0001] This application relates to the field of industrial simulation technology, specifically to an industrial protocol simulation method and system. Background Technology

[0002] With the development of Industrial Internet technology, automated simulation testing systems for industrial protocols are becoming increasingly important in evaluating protocol performance and stability. An automated simulation testing system for industrial protocols is a dedicated testing platform for industrial communication scenarios. Its core objective is to simulate the real interaction logic of devices, networks, and protocols in an industrial environment through software simulation and hardware adaptation. It automates the testing of industrial protocols and the devices or systems based on those protocols, assessing their compatibility, stability, security, and performance. Ultimately, it verifies whether the tested object meets industrial communication standards and practical application requirements.

[0003] In related technologies, systems typically require pre-installed fixed protocol modules and lack a universal protocol extension mechanism. This results in the need to reconstruct the system when adding new protocols, which can easily lead to system compatibility issues and make it difficult to meet the needs of different industries and enterprises for supporting new protocols.

[0004] Specifically, existing technologies, such as Chinese Patent Publication No. CN114531476A, disclose a method and system for industrial protocol parsing and data conversion. This system utilizes three modules—a control logic configuration program, a data engine tool, and a built-in universal gateway program—to work collaboratively. While graphical elements reduce the difficulty of protocol implementation, these protocol modules are pre-defined and fixed, lacking a universal protocol extension mechanism. When new industrial protocols need to be supported, the entire system must be modified and restructured, resulting in long development cycles, poor compatibility, and difficulty in meeting the diverse protocol requirements of different industries.

[0005] Another Chinese patent, CN118869560A, proposes an automated simulation and testing system for industrial protocols. While emphasizing concurrent communication and real-time simulation, its system architecture remains decoupled, with the protocol processing module tightly coupled to the simulation core, lacking a mechanism for dynamically loading and isolating the execution of protocols. This makes it difficult to guarantee the system's performance and stability when simulating millisecond-level scheduling scenarios involving hundreds of devices and tens of thousands of data points. Furthermore, such systems typically employ simple single-threaded queues or timers when handling high-frequency task scheduling, lacking efficient scheduling algorithms optimized for industrial scenarios and failing to achieve high-precision, low-jitter scheduling triggering for massive amounts of data points.

[0006] In summary, existing industrial protocol simulation systems mainly suffer from the following drawbacks: Poor protocol scalability: The system architecture is rigid, and adding or replacing protocols requires refactoring the system code, making it impossible to achieve "hot-swappable" protocols.

[0007] High system coupling: The protocol processing module is tightly bound to the core simulation engine, resulting in poor system stability and weak resource isolation.

[0008] Insufficient scheduling efficiency and accuracy: There is a lack of dedicated scheduling algorithms for high-frequency industrial data scenarios, making it difficult to support large-scale, high-concurrency real-time simulation tasks.

[0009] Unintelligent resource utilization: The system configuration (such as database selection) cannot be dynamically adjusted according to the actual host hardware resources and business load, resulting in low resource utilization efficiency.

[0010] Therefore, there is an urgent need in this field for a new industrial protocol simulation solution to address one or more of the aforementioned technical problems. Summary of the Invention

[0011] This application provides an industrial protocol simulation method and system, which aims to solve the problem that the lack of a universal protocol extension mechanism leads to the need to reconstruct the system when new protocols are added.

[0012] In a first aspect, embodiments of this application provide an industrial protocol simulation method, comprising the following steps: Create simulation equipment; Determine the configuration information based on the simulation equipment; Measurement point data is generated based on the configuration information and stored in an in-memory database. The protocol plugin container is used to establish a communication connection between the simulation device and external devices, so as to read measurement point data from the in-memory database and write external data into the in-memory database.

[0013] In some embodiments, the configuration information includes at least one of device information, task information, protocol plugin information, data measurement point information, and data generation strategy information.

[0014] In some embodiments, generating measurement point data based on configuration information includes: Based on the task information, a hierarchical time wheel algorithm is used to schedule tasks to be executed. Execute the task to be executed, and generate measurement point data based on the data measurement point information and data generation strategy information; The measurement data is stored in an in-memory database.

[0015] In some embodiments, task scheduling is performed based on a hierarchical time wheel algorithm according to task information to obtain tasks to be executed, including: Tasks are categorized based on their duration to determine their hierarchy, with the duration of a task being positively correlated with its hierarchy. Write tasks to the corresponding level slots at standard intervals; Control the time wheel of each level to roll at the corresponding cycle, and reduce the level of the task when the task of the higher level expires; Output the tasks to be executed through the lowest level slots.

[0016] In some embodiments, establishing a communication connection between the emulation device and an external device using a protocol plug-in container includes: All protocol plugin containers are initialized through a unified plugin container interface, and each protocol plugin container encapsulates a protocol plugin. Select the corresponding protocol plugin container based on the communication protocol of the external device; Establish an independent sandbox environment for the protocol plugin container through the plugin container interface; Import the configuration information into the sandbox environment and establish a communication connection between the simulation device and external devices within the sandbox environment.

[0017] In some embodiments, after establishing a communication connection between the simulation device and an external device within the sandbox environment, the process includes: Upon receiving a read command from an external device, read the measurement point data from the memory database; The measurement point data is converted into the corresponding protocol format through the protocol plugin container and sent to the external device.

[0018] In some embodiments, after establishing a communication connection between the simulation device and an external device within the sandbox environment, the process includes: Upon receiving a write command from an external device, retrieve the write data from the external device; The written data is converted into the corresponding protocol format by the protocol plugin container and sent to the in-memory database.

[0019] In some embodiments, before initializing all protocol plugin containers through a unified plugin container interface, the following steps are also included: Security checks are performed on the protocol plugin container via the plugin container interface; After the security verification is passed, the information of the protocol plugin container will be registered in the configuration information.

[0020] In some embodiments, before determining the configuration information based on the simulation device, the method further includes: The simulation equipment selects a storage database based on a quantitative analysis algorithm to store configuration information.

[0021] In some embodiments, selecting a storage database based on a quantization analysis algorithm using a simulation device includes: Evaluate the metrics of the simulation equipment based on the characteristics of its hardware resources and workload. Calculate the comprehensive decision score based on the simulation equipment's indicators; The database to be stored is selected based on the comprehensive decision-making score.

[0022] In some embodiments, the method further includes: The simulation device, configuration information, measurement point data, and communication connection status between the simulation device and external devices can be interacted with in real time through a visual interface.

[0023] Secondly, embodiments of this application also provide an industrial protocol simulation system, including: A simulation engine used to create simulated devices; The configuration management module is used to determine configuration information based on the simulation equipment. The data generation module is used to generate measurement point data based on configuration information, and the measurement point data is stored in an in-memory database. The protocol plugin module includes multiple protocol plugin containers corresponding to different protocols. These containers are used to establish communication connections between the simulation device and external devices, enabling the reading of measurement point data from the memory database and the writing of external data into the memory database.

[0024] In some embodiments, the system further includes: The visualization module is used to enable real-time interaction with the simulation equipment, configuration information, measurement point data, and communication connection status between the simulation equipment and external devices through a visual interface.

[0025] This application establishes a communication connection between the simulation device and the external device through a protocol plug-in container. For devices using different protocols, the connection is established through the corresponding protocol plug-in container. When a protocol needs to be added, only the protocol plug-in container needs to be added, without the need to reconstruct the entire system, thus meeting the needs of different industries and enterprises for new protocol support.

[0026] The key feature of this application lies in the introduction of a protocol plugin container architecture. A protocol plugin container is an independent running unit that encapsulates a specific industry protocol stack (such as Modbus TCP, OPC UA, etc.) and all its dependencies. It communicates with the simulation engine through a unified plugin container interface, which defines standard lifecycle methods such as initialization, service startup, data point reading and writing, and stopping. When a protocol plugin container is loaded, the system creates an independent sandbox environment for it through this interface, isolating and restricting CPU, memory, network, and file system access. This ensures that any protocol plugin failure will not affect the main system, and the addition of a new protocol only requires implementing this standard interface and encapsulating it as a container, without modifying the core system code, thus achieving true plug-and-play protocol functionality. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a flowchart illustrating an industrial protocol simulation method provided in an embodiment of this application; Figure 2 This is another flowchart illustrating an industrial protocol simulation method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating step S202 of an industrial protocol simulation method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating step S204 of an industrial protocol simulation method provided in an embodiment of this application; Figure 5 This is a flowchart illustrating step S2041 of an industrial protocol simulation method provided in this application embodiment; Figure 6 This is a flowchart illustrating step S205 of an industrial protocol simulation method provided in an embodiment of this application; Figure 7 This is a flowchart illustrating step S206 of an industrial protocol simulation method provided in an embodiment of this application; Figure 8 This is a flowchart illustrating step S207 of an industrial protocol simulation method provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an industrial protocol simulation system provided in an embodiment of this application.

[0029] Explanation of icon numbers: 100. Simulation Engine; 200. Configuration Management Module; 201. Database Selection Module; 202. Information Configuration Module; 300. Data Generation Module; 301. Scheduler; 302. Data Generator; 400. Protocol Plugin Module; 401. Protocol Plugin Container; 402. Plugin Container Interface; 500. Visualization Module; 501. Web User Interface; 502. Application Programming Interface; 600. In-Memory Database. Detailed Implementation

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

[0031] In the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0032] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0033] The use of "applies to" or "configured to" in this application implies open and inclusive language, which does not exclude the applicability to or configuration to devices performing additional tasks or steps. Additionally, the use of "based on" implies openness and inclusivity, because processes, steps, calculations, or other actions "based on" one or more of the stated conditions or values ​​may in practice be based on additional conditions or values ​​beyond those stated.

[0034] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0035] Firstly, embodiments of this application provide an industrial protocol simulation method, such as... Figure 1 As shown, it includes the following steps: S101. Create a simulation device.

[0036] Simulation equipment refers to software-defined virtual industrial equipment used to simulate the functions of physical equipment in real industrial scenarios, such as sensors, controllers, and actuators.

[0037] S102. Determine the configuration information based on the simulation equipment.

[0038] The configuration information is a complete set of parameters for the normal operation of the simulation equipment. By dynamically modifying the configuration information, such as adjusting the data generation strategy and updating the scheduling cycle, it can be adapted to the flexible needs of industrial scenarios. Standardizing the definition of the configuration information can ensure compatibility between different simulation equipment and different protocols, reducing the difficulty of cross-scenario reuse.

[0039] S103. Generate measurement point data based on the configuration information, and store the measurement point data in an in-memory database.

[0040] The measurement data consists of data generated by the simulation equipment during its operation, such as temperature values ​​from temperature sensors, output voltage from controllers, and operating status of actuators. This measurement data is stored directly in an in-memory database for easy retrieval from external data without affecting operational efficiency.

[0041] S104. Use the protocol plugin container to establish a communication connection between the simulation device and the external device, so as to read the measurement point data in the memory database and write the external data into the memory database.

[0042] The protocol plugin container encapsulates the protocol runtime environment. Each protocol plugin container corresponds to an industrial protocol. Through the protocol plugin container, a communication connection between the simulation device and external devices can be established. External data can be directly read from the memory database to obtain the measurement point data obtained by the simulation device, or external data can be written to the memory database, enabling fast data reading or writing.

[0043] This application embodiment establishes a communication connection between the simulation device and the external device through a protocol plug-in container. For devices using different protocols, the connection is established through the corresponding protocol plug-in container. When a protocol needs to be added, only the protocol plug-in container needs to be added, without the need to reconstruct the entire system, thus meeting the needs of different industries and enterprises for new protocol support.

[0044] This application also provides another industrial protocol simulation method, such as... Figure 2 As shown, it includes the following steps: S201. Create a simulation device.

[0045] Simulation equipment refers to software-defined virtual industrial equipment used to simulate the functions of physical equipment in real industrial scenarios, such as sensors, controllers, and actuators.

[0046] S202. Select a storage database based on the simulation equipment and the quantitative analysis algorithm.

[0047] The storage database is used to store configuration information. The amount of configuration information required varies for different simulation devices, so it is necessary to select the appropriate storage database for the configuration information.

[0048] In one embodiment, the storage database can be SQLite (a lightweight database for Structured Query Language) or MySQL (a relational database for Structured Query Language). SQLite is used for lightweight scenarios (such as small-scale devices, low concurrency, and short storage cycles) to save resources; MySQL is used for medium-to-high load scenarios (such as large-scale devices, high concurrency, and long storage cycles) to ensure performance.

[0049] like Figure 3 As shown, step S202 includes S2021-S2023.

[0050] S2021. Evaluate the performance indicators of the simulation device based on the characteristics of the hardware resources and workload of the host machine where the simulation device is located.

[0051] Hardware resources refer to the basic hardware data of the host machine where the simulation device is located, such as CPU (Central Processing Unit) processing power, memory capacity, storage input / output performance, and network connectivity.

[0052] The workload consists of the core business data of the host machine where the simulation equipment is located, such as the scale of the simulation equipment, the density of data measurement points, the complexity of data operations, and the concurrent access requirements.

[0053] The hardware resource indicators of the simulation equipment are calculated using a hardware resource scoring model, and the service load indicators of the simulation equipment are calculated using a service load scoring model. The indicators of hardware resources and service load are then quantified for subsequent decision-making.

[0054] The hardware resource scoring model is shown in Table 1: Table 1: Hardware Resource Scoring Model

[0055] In one embodiment, taking CPU processing power as an example, the score is 0-100. The number of cores (2 or fewer), 3-4 cores, and 4 or more cores correspond to 30, 60, and 80 points respectively, with a weight of 0.4. The clock speed (1.5GHz or less), 1.6-2.5GHz, and 2.6GHz or more correspond to 20, 50, and 80 points respectively, with a weight of 0.35. The architectures ARM_CORTEX_A53, ARM_CORTEX_A72, X86_ATOM, X86_CELERON, X86_I3, X86_I5, X86_I7, and X86_XEON correspond to 40, 60, 50, 65, 75, 85, 95, and 100 points respectively, with a weight of 0.25. The formula for calculating CPU processing power is: ; in For CPU processing power, For core quantity, Main frequency, For the architecture.

[0056] The formula for calculating hardware resource metrics is: ; in, For hardware resource indicators, For CPU processing power, For content inventory assessment, For storage I / O performance, Rate network connectivity.

[0057] The business load scoring model is shown in Table 2: Table 2: Service Load Scoring Model

[0058] In one embodiment, taking the scale of the simulation equipment as an example, the score is 0-100. The number of equipment is less than or equal to 10, 10-50, 50-100, 100-200, and greater than 200, corresponding to 20, 40, 60, 80, and 80 points respectively, with a weight of 0.7. Equipment complexity is categorized as simple, medium, complex, and ultra-complex, corresponding to 20, 40, 60, 85, and 100 points respectively, with a weight of 0.3. The formula for calculating the scale of the simulation equipment is: ; in This refers to the scale of the simulation equipment at the CPU. For the number of devices, For equipment complexity.

[0059] The formula for calculating the business load metric is: ; in, For business load metrics, For CPU processing power, For content inventory assessment, For storage I / O performance, Rate network connectivity.

[0060] S2022. Calculate the comprehensive decision score based on the indicators of the simulation equipment.

[0061] The comprehensive decision score is calculated based on the weights of hardware resource metrics and business load metrics, as shown in the following formula: ; in, For comprehensive decision-making scoring, For hardware resource indicators, This is a business load metric.

[0062] S2023. Select the storage database based on the comprehensive decision score.

[0063] If the overall decision score is 40 or less, the current scenario is considered low-load, and SQLite is the appropriate choice. In resource-constrained environments, lightweight single-file databases offer the best cost-effectiveness.

[0064] If the overall decision score is greater than 40 and less than or equal to 75, the current scenario is determined to be a medium load scenario. You can choose SQLite or MySQL according to your needs. For example, choose MySQL if high availability or distributed deployment is required, and choose SQLite if single-machine deployment is required and performance is sufficient.

[0065] If the overall decision score is 75 or higher, the current scenario is determined to be high-load, and MySQL is selected. In high-concurrency, large-data-volume scenarios, enterprise-grade database capabilities are required, therefore MySQL is chosen.

[0066] S203. Determine the configuration information based on the simulation equipment.

[0067] Configuration information includes at least one of the following: device information, task information, protocol plugin information, data measurement point information, and data generation strategy information.

[0068] Device information includes device name, communication protocol type, communication port, and status information, which are used to define the simulation device.

[0069] Task information includes details about the task that needs to be scheduled for execution, such as the task name, task category, and task duration.

[0070] The protocol plugin information includes various industrial protocols, such as Modbus TCP / RTU, Snap7, OPC UA protocol, nmea0183 and other mainstream industrial protocols.

[0071] The data measurement point information includes measurement point ID, measurement point name, measurement point data type, and measurement point scaling factor. The data types include bool, byte, char, double, float, int, short, uchar, uint, ushort, and string. The measurement point scaling factor scale is used to calculate the actual value of the measurement point, i.e., actual value = original value × 10^scale, where scale can be negative.

[0072] The data generation strategy information describes the data generation strategy for the measurement points, such as fixed values, random intervals, trigonometric function waveforms, and Python script engine parsing, as well as how often the data is generated, which can be set to the millisecond level, such as 100ms or 200ms.

[0073] S204. Generate measurement point data based on the configuration information, and store the measurement point data in an in-memory database.

[0074] like Figure 4 As shown, step S204 includes S2041-S2043.

[0075] S2041. Based on the task information, perform task scheduling using the hierarchical time wheel algorithm to obtain the tasks to be executed.

[0076] like Figure 5 As shown, step S2041 includes S20411-S20414.

[0077] S20411. Classify tasks according to their cycle and determine their levels, where the cycle of a task is positively correlated with its level.

[0078] The task cycle is the time interval between task trigger data generation. Based on the task cycle, tasks are classified into four levels: the shorter the cycle, the lower the level; and the longer the cycle, the higher the level.

[0079] The four levels are millisecond, second, minute, and hour, corresponding to task types such as real-time control commands, process data acquisition, equipment status inspection, and statistical report generation, respectively. The period range of the millisecond level is less than or equal to 1000ms with a precision of 1ms; the period range of the second level is 1001ms-600000ms with a precision of 1s; the period range of the minute level is 600001ms-3600000ms with a precision of 1 minute; and the period range of the hour level is greater than 3600000ms with a precision of 1 hour.

[0080] S20412. Write the tasks to the corresponding level slots at standard intervals.

[0081] A slot is the smallest time unit carrier of the time wheel within each level. Each level contains a fixed number of slots, and each slot corresponds to a standard interval, which is used to store all tasks that have expired.

[0082] For example, an actual period of 98ms is merged into a standard interval of 100ms, and an actual period of 5200ms is merged into 5000ms.

[0083] By grouping similar scheduling intervals into standard intervals, we can avoid each task occupying an independent slot and improve the utilization rate of the time wheel slots.

[0084] S20413. Control the time wheel of each level to roll at the corresponding cycle, and reduce the level of the task after the high-level task expires.

[0085] Each level's time wheel rotates at a constant speed according to its own precision. For example, the millisecond level scrolls one slot every 1ms, the second level scrolls one slot every 1s, and so on.

[0086] Each level of the time wheel has an independent scrolling cycle and does not interfere with each other. For example, the millisecond level has a scrolling cycle of 1ms, and checks the currently pointed slot every 1ms to determine if any tasks have expired; the second level has a scrolling cycle of 1s, and checks the current slot every 1s; the minute level has a scrolling cycle of 1 minute, and checks the current slot every 1 minute; the hour level has a scrolling cycle of 1 hour, and checks the current slot every 1 hour.

[0087] When the remaining execution time of a task in a higher-level slot is less than or equal to the maximum cycle time of the next level, it will automatically be downgraded by one level.

[0088] For example, if a task in the minute layer has a cycle of 30 minutes, and the remaining execution time is only 500ms, the minute layer time wheel detects that the remaining time is less than or equal to 1000ms, triggering a reduction in the task level. The task is then moved to slot 500 in the millisecond layer. When the millisecond layer time wheel scrolls to slot 500, the task can be executed.

[0089] S20414. Output tasks to be executed through the lowest level slot.

[0090] The millisecond layer is the highest precision and highest priority layer in the entire hierarchical time wheel. All tasks about to be executed will eventually converge at the millisecond layer.

[0091] When the millisecond time wheel scrolls to the target slot, all tasks in that slot are sent to the data generator in batches, triggering data generation and generating real-time data for the measurement points.

[0092] S2042. Execute the task to be executed, and generate measurement point data based on the data measurement point information and data generation strategy information.

[0093] Based on the data measurement point information and data generation strategy, the measurement point data is simulated and generated in the simulation equipment.

[0094] S2043. Store the measurement point data in an in-memory database.

[0095] In one embodiment, the in-memory database is a Redis (remote dictionary server) database with a memory read / write latency of ≤1ms, supporting millions of operations per second, meeting the needs of high-frequency data interaction, supporting multiple data structures, and flexibly storing measurement point data.

[0096] The hierarchical time wheel algorithm divides scheduled tasks into multiple levels based on their period, such as millisecond, second, minute, and hourly levels, and groups tasks with similar periods into slots with standard intervals. Through hierarchical rolling and task degradation mechanisms, all tasks to be executed are ultimately triggered by the highest-level (millisecond) high-precision time wheel. This method effectively reduces the number of time wheel slots, lowers memory overhead, and ensures millisecond-level scheduling accuracy, making it suitable for industrial simulations where a large number of data points have different update frequencies.

[0097] S205. Use the protocol plug-in container to establish a communication connection between the simulation device and the external device.

[0098] The protocol plugin container encapsulates an independent running unit of the industrial protocol stack, which interacts with the simulation engine through the plugin container interface.

[0099] like Figure 6 As shown, step S205 includes S2051-S2056.

[0100] S2051. Perform security verification on the protocol plugin container through the plugin container interface.

[0101] Each protocol plugin, along with its dependent libraries, is encapsulated into an independent protocol plugin container that conforms to the plugin container interface specification. When a new protocol plugin container is uploaded to a specified directory, the plugin container interface is invoked to perform compliance verification on the protocol plugin container's image and configuration. S2052. After the security verification is passed, register the information of the protocol plugin container in the configuration information.

[0102] After successful verification, the plugin container's information is registered in the configuration management module, such as protocol type, version, and supported service ports.

[0103] S2053. Initialize all protocol plugin containers through a unified plugin container interface.

[0104] The plugin container interface is based on the CRI (Container Runtime Interface), which ensures that all plugin containers follow the same initialization standard and avoids the problem of inconsistent initialization processes among plugins.

[0105] S2054. Select the corresponding protocol plugin container according to the communication protocol of the external device.

[0106] The protocol type used when an external device initiates communication is usually determined by the port number, protocol identifier field, or configuration preset. Based on the protocol type of the external device, a protocol plugin container with the same protocol type is selected.

[0107] S2055. Establish an independent sandbox environment for the protocol plugin container through the plugin container interface.

[0108] When starting the simulation device, an independent sandbox environment is established for the protocol plugin container through the plugin container interface. The sandbox environment contains independent CPU, memory, network, and file system, which restricts the resource access scope of the protocol plugin container. The sandbox environment is an independent runtime environment implemented through resource isolation and access control mechanisms, which is used for security isolation and resource control to avoid overload.

[0109] S2056. Import the configuration information into the sandbox environment and establish a communication connection between the simulation device and the external device within the sandbox environment.

[0110] Configuration information is dynamically injected into the running protocol plugin container through the plugin container interface, establishing a communication connection between the simulation device and external devices within the sandbox environment.

[0111] S206. Read the measurement point data from the memory database.

[0112] like Figure 7 As shown, step S206 includes S2061-S2062.

[0113] S2061. Upon receiving a read command from an external device, read the measurement point data from the memory database.

[0114] The measurement point data can be read directly from the memory database through the plugin container interface, without the need for forwarding, thus improving reading efficiency.

[0115] S2062. Convert the measurement point data into the corresponding protocol format through the protocol plug-in container and send it to the external device.

[0116] The protocol plugin container converts the measurement point data into protocol data packets in the corresponding protocol format, making it recognizable by external devices, and then transmits the converted protocol data packets to the external devices.

[0117] S207. Write external data into the in-memory database.

[0118] like Figure 8 As shown, step S207 includes S2071-S2072.

[0119] S2071. Upon receiving a write command from an external device, obtain the write data from the external device.

[0120] External devices control the simulation device by writing data to the memory database. The written data is a protocol data packet generated in the protocol format of the external device.

[0121] S2072. Convert the written data into the corresponding protocol format through the protocol plugin container and send it to the in-memory database.

[0122] The written data is parsed and format converted by the protocol plugin container, and then sent to the slot memory database through the plugin container interface.

[0123] S208. Real-time interaction with simulation equipment, configuration information, measurement point data, and communication connection status between simulation equipment and external equipment is achieved through a visual interface.

[0124] The system's operating status can be monitored through a visual interface, including device status, communication connection status, and data generation status. It can also dynamically select the storage database based on the load and modify configuration information in real time, as well as obtain real-time status feedback.

[0125] Secondly, embodiments of this application also provide an industrial protocol simulation system, such as... Figure 9 As shown, it includes a simulation engine 100, a configuration management module 200, a data generation module 300, a protocol plugin module 400, and a visualization module 500.

[0126] The simulation engine 100 is used to create simulated devices and control the configuration management module 200, data generation module 300, and protocol plug-in module 400. The simulation engine 100 is responsible for loading and managing the lifecycle operations of device configurations, including the creation, startup, shutdown, and destruction of virtual devices. Through the configuration information configured by the device configuration management module 200, the simulation engine 100 coordinates the running status of the scheduler 301, data generator 302, and protocol plug-in container 401, and provides interfaces for the visual monitoring interface to call, achieving centralized management and monitoring of the system.

[0127] The configuration management module 200 is used to determine configuration information based on the simulation equipment. The configuration management module 200 includes a database selection module 201 and an information configuration module 202. The database selection module 201 adopts a distributed database architecture and is used to select a storage database based on the simulation equipment using a quantitative analysis algorithm. It supports seamless switching between SQLite and MySQL and selects a suitable storage solution based on the system deployment. The information configuration module 202 provides parameter configuration and management, used to determine configuration information, including equipment information, task information, protocol plugin information, data measurement point information, and data generation strategy information, ensuring the security and reliability of the system configuration.

[0128] The data generation module 300 generates measurement point data based on configuration information, and the measurement point data is stored in the in-memory database 600. The data generation module 300 includes a scheduler 301 and a data generator 302. The scheduler 301 schedules tasks based on a hierarchical time wheel algorithm according to task information to obtain tasks to be executed. The data generator 302 executes the tasks to be executed, generating measurement point data based on measurement point information and data generation strategy information. The data generator depends on the following configuration fields: monitor_id (unique identifier for the measurement point ID), value (latest value of the current measurement point), value_type (value type, 0 fixed value, 1 random value, 2 step-increment), min (minimum value), max (maximum value), initial_value (initial value), step (step size), name (measurement point name), and data_type (data type).

[0129] The protocol plug-in module 400 includes multiple protocol plug-in containers 401 corresponding to different protocols. These containers are used to establish communication connections between the simulation device and external devices, enabling the reading of measurement point data from the in-memory database 600 and the writing of external data to the in-memory database 600. The protocol plug-in module 400 has a unified plug-in container interface 402, which allows for dynamic management, isolated operation, and efficient scheduling of the protocol plug-in containers 401 according to the scheduling of the simulation engine 100.

[0130] The plugin container interface 402 has an initialization interface, a service interface, a read interface, a write interface, and a stop interface. The initialization interface is used to initialize the plugin container according to the configuration information, the service interface is used to start the protocol service and receive bidirectional communication information, the read interface is used to process read data requests, the write interface is used to process write data requests, and the stop interface is used to stop and clean up the protocol plugin container 401.

[0131] The protocol plugin container 401 is managed throughout its entire lifecycle through the plugin manager and plugin container interface 402 in the simulation engine 100. The simulation engine 100 controls the protocol plugin container 401 to load pre-configured configuration information, process the communication protocols of external devices, parse and extract valid data sent by external devices, read the measurement point data in the memory database 600, and respond to the connection requests of external devices according to the configuration information of the measurement points and specific protocol rules, return data, and monitor the connection status.

[0132] The protocol plugin module 400 manages the lifecycle states of the protocol plugin container 401 through a state machine. The state machine transitions are shown in Table 3: Table 3: Schematic diagram of state machine transitions

[0133] The visualization module 500 is used to enable real-time interaction with the simulation equipment, configuration information, measurement point data, and communication connection status between the simulation equipment and external devices through a visual interface.

[0134] The visualization module 500 includes a web user interface 501 and an application programming interface 502. The web user interface 501 includes a device information editor, a measurement point data import module, and a real-time data curve monitoring panel. The device information editor is used to edit the configuration information of the simulation device, the measurement point data import module is used to import measurement point data, and the real-time data curve monitoring panel is used to display the curves generated by the real-time data. The application programming interface 502 provides a standardized interface for device configuration, starting and stopping the protocol plug-in container 401, and obtaining runtime status. The visualization module 500 achieves visualized management of the communication process through graphical configuration elements, improving the convenience and usability of system operation.

[0135] Example 1: This embodiment details the specific technical solution for the data generator 302 in the data generation module 300 to generate measurement point data based on configuration information. In response to a task to be executed triggered by the scheduler 301, the data generator 302 calculates and updates the measurement point values ​​according to the generation strategy defined in the measurement point information corresponding to that task.

[0136] 1. The basic configuration of data generation strategy.

[0137] The generation strategy for each data measurement point is defined and managed by the configuration management module 200 and loaded into the data generator 302 through the simulation engine 100. The generation strategy is determined by configuration fields, which include identifier, measurement point value, value type, lower limit of value, upper limit of value, initial value, step size value, measurement point name, and data type.

[0138] The identifier (monitor_id) is a unique identifier for the measurement point, used to index the measurement point in the in-memory database 600.

[0139] The measurement point value is the latest value of that measurement point, which is dynamically updated by the data generator 302.

[0140] The value type (value_type) is used to define the algorithm for generating the value. This example supports three basic types: 0 (fixed value), 1 (random value), and 2 (incrementing by step).

[0141] The lower bound (min) is the lower limit for value generation, and it is effective for values ​​of random type and step-size increment.

[0142] The upper limit of the value (max) is the upper limit for the generation of values, and it is effective for values ​​of random type and step-by-step growth.

[0143] The initial value (initial_value) is the initial value of the measuring point.

[0144] The step size is the step size of the numerical value, and it is valid for value types that are incremented by step.

[0145] The measurement point name (name) is used for visualization.

[0146] The data type (data_type) is the data type of the measurement point, such as int, float, double, used to ensure the accuracy and correct format of the generated values.

[0147] 2. Data generation algorithm based on value_type Data generator 302 executes the following algorithm for each triggered measurement point, the core logic of which is based on value type-based branching: When the value type is fixed, value_type = 0, the data generator 302 will ignore the min, max, and step fields and always set the measurement point value to the initial value.

[0148] It is used to simulate device signals with constant states, such as a switch that is always on, or a constant setpoint.

[0149] When the value type is set to random, with value_type = 1, data generator 302 generates a uniformly distributed random number within the closed interval [min, max] each time it is called. The generated random number undergoes type conversion based on the data type to ensure data type correctness.

[0150] It is used to simulate physical quantities with fluctuations, such as ambient temperature, humidity, and pressure, or to simulate sensor noise.

[0151] When the value type is incremented by a step, `value_type = 2`. Data generator 302 increments the current measurement point value by a fixed step value each time it is called. When the incremented value exceeds the upper limit, there are two configurable modes for handling this: Loop mode: When value + step > max, reset the measurement point value to the lower limit of the value.

[0152] Saturation mode: When value + step > max, the measurement point value will be kept at the upper limit of the value until it is reset externally.

[0153] It is applied to physical quantities that change monotonically or periodically, such as analog counters, cumulative flow, and equipment runtime.

[0154] 3. Data generation and writing process.

[0155] The complete processing flow of data generator 302 for a single measurement point is as follows: Obtain the identifier of a measurement point from the queue of tasks to be executed in scheduler 301.

[0156] The complete generation strategy configuration for the test point is obtained from the configuration cache in the memory database or by directly querying the configuration management module based on the identifier.

[0157] Based on the value type in the configuration, the corresponding generation strategy is invoked to calculate the new measurement point values.

[0158] Perform a final verification on the generated new measurement point values ​​to ensure that they conform to the value type and are within a reasonable range.

[0159] The new measurement point value, along with the current high-precision timestamp, is written to the corresponding identifier key in the in-memory database 600 through a single atomic operation. This step employs zero-copy or efficient serialization techniques to minimize performance overhead.

[0160] Send an asynchronous notification to the visualization module 500 to inform that the value of a certain measurement point has been updated, so that the interface display can be refreshed in real time.

[0161] Through the technical solution detailed in this embodiment, the data generator 302 can efficiently and accurately generate dynamic measurement point data that meets the needs of industrial simulation scenarios based on a flexible and configurable strategy, providing rich and realistic data sources for the upper-layer protocol plug-in module.

[0162] Example 2: This embodiment details how to construct a protocol plug-in container 401 for simulating a Modbus TCP slave device, specifically demonstrating the structure, configuration, and interaction process of the protocol plug-in container 401 with the system in this invention.

[0163] 1. Structure and configuration of protocol plugin container 401.

[0164] The Modbus TCP Slave protocol plugin container 401 is a standalone software package whose internal structure includes plugin descriptor files, main program binaries, dependency library directories, and configuration template directories.

[0165] The plugin descriptor file (plugin.json) is used to declare the metadata, dependencies, resource requirements, and features of the plugin container.

[0166] Metadata defines the basic identity information of a plugin, used for plugin identification, version management, and functional description. It defines the plugin container name, version, supported protocol types, compatible plugin container interface 402 versions, and application scenario description. For example, in this embodiment, the metadata definition is as follows: {"name":"modbus-tcp-slave","version":"2.1.0","protocolType": "MODBUS_TCP","criVersion": "v1alpha2","description": "A Modbus TCP Slave plugincontainer for industrial simulation."}.

[0167] Dependencies are used to determine the external dependencies required for the plugin to run, ensuring that the core functional libraries can be loaded correctly after the container starts. The dependency entries define the name, version, and type of the dependent libraries. For example, in this embodiment, the dependency definition is as follows: {"name": "libmodbus","version":"3.1.6","type": "SHARED_LIBRARY"}.

[0168] Resource requirements are the hardware resource constraints needed for the plugin to run, used to allocate appropriate hardware resources during container scheduling, including memory requirements, CPU share, and open ports. For example, in this embodiment, the resource requirements are as follows: {"memoryMB": 256,"cpuShares": 512, "ports": [502, 1502, 2502]}.

[0169] Functional characteristics define the core functional limits and supported business capabilities of a plugin, used to evaluate whether the plugin meets the application scenario requirements. Examples include supported Modbus function codes, maximum concurrent connections, and data processing capacity per second. For instance, in this embodiment, the functional characteristics are as follows: {"supportedFunctions": [1, 2, 3, 4, 5, 6, 15, 16], "maxConnections": 128, "dataPointsPerSecond": 10000}.

[0170] The plugin descriptor file defines the identity of the protocol plugin, the required environmental resources, and its protocol processing capabilities. It serves as the basis for the system to verify and manage plugins.

[0171] The main program binary (modbus_tcp_slave) is used to implement the plugin container interface 402 (CRI).

[0172] The dependency library directory (lib) contains the dependency libraries required by the protocol stack, such as libmodbus.so.5.

[0173] The configuration template directory (config_templates) provides configuration template files for quickly generating device-specific configurations.

[0174] 2. The lifecycle of the protocol plugin container 401 and its interaction with the system.

[0175] The Modbus TCP Slave protocol plugin container 401 completes its lifecycle management through interaction with the simulation engine 100. The specific steps are as follows: S301. Verification and Registration.

[0176] The plugin manager in simulation engine 100 performs security verification on protocol plugin container 401 through the security verification interface (PluginService.Validate RPC interface).

[0177] The verification process includes checking the integrity of the plugin descriptor file, verifying the digital signature, and confirming the version compatibility of the dependent library libmodbus. After successful verification, the system registers the plugin's protocol type (MODBUS_TCP), available port (502), and other information into the configuration management module 200, making it available for use by simulation devices.

[0178] S302. Initialization and Sandbox Environment Creation.

[0179] When a user creates a simulated device using the Modbus TCP protocol, the simulation engine 100 controls the system to create an independent sandbox environment for the Modbus TCP protocol plugin container 401 through the sandbox creation interface (RuntimeService.RunPodSandbox interface). The sandbox environment is strictly restricted to accessing only specified CPU shares (512 shares), memory (256MB), and network ports (502), achieving resource isolation from the host and other plugins.

[0180] S303, Configuration Injection and Service Startup.

[0181] The system dynamically injects the configuration file of the current simulation device into the running sandbox environment through the configuration injection interface (RuntimeService.Attach interface). This configuration file, generated by the configuration management module 200, specifies the mapping relationship between the Modbus slave's IP address, port, data measurement points, and Modbus register addresses (e.g., measurement point 4503621119836162 maps to holding register 40001). See Table 4 for an example of the configuration file. Table 4: Configuration File Examples

[0182] The main program within the plugin container parses this configuration and calls its implemented initialization method to complete the initialization. Subsequently, the system calls the container's startup method to start the Modbus TCP service listening thread and begin accepting connection requests from external master stations.

[0183] 3. Data Generator 302.

[0184] The data generation module 300 is used to generate measurement point data based on the configuration information. Example data for the data generation configuration is shown in Table 5. Table 5: Example of Data Generation Configuration File

[0185] Wherein, `monitor_id` is the unique identifier of the measurement point ID, `value` is the latest value of the current measurement point, `value_type` is the value type (0 is a fixed value, 1 is a random value, 2 is a step-incrementing value), `min` is the minimum value, `max` is the maximum value, `initial_value` is the initial value, `step` is the step size, `name` is the measurement point name, and `data_type` is the data type. Measurement point data is stored in the in-memory database 600. The data generation module 300 includes a scheduler 301 and a data generator 302. The scheduler 301 is used to schedule tasks based on the task information using a hierarchical time wheel algorithm to obtain tasks to be executed. The data generator 302 is used to execute the tasks to be executed, generating measurement point data and updating it to the in-memory database 600 based on the measurement point information and data generation strategy information.

[0186] 4. Data processing flow of protocol plugin container 401.

[0187] When the Modbus TCP Slave protocol plugin container 401 is running, it processes data read and write requests according to the following procedure: (1) Handle read requests (such as function code 03 - read holding register).

[0188] The external Modbus TCP master initiates a register read request to the simulation device's IP:502 port.

[0189] The network listening thread within the plugin container receives the request and parses out the register address to be read (e.g., 40001).

[0190] The container converts register address 40001 into the internally defined measurement point ID 4503621119836162 based on the pre-injected configuration mapping.

[0191] The container calls its implemented data reading interface (ReadDataPoint interface) to directly access the in-memory database 600 through the shared memory mechanism, reads the latest value of the measurement point 4503621119836162, and simultaneously obtains the data timestamp.

[0192] The container encapsulates the read values ​​into a response data packet according to the Modbus TCP protocol format and sends it back to the external master station.

[0193] (2) Handle write requests.

[0194] The external master station sends a write register request to set the value of the target measurement point 4503621119836163 to 100.

[0195] The plugin container parses the request, resolving the target measurement point 4503621119836163 into register address 40002. It then uses relevant APIs such as modbus_mapping_t and modbus_reply to write the value to the register. The container calls its implemented data write interface (WriteDataPoint) to directly write the value 100 to the in-memory database 600.

[0196] After a successful write operation, the container sends an asynchronous write operation callback notification to the simulation engine 100 via the CRI's streaming interface (streamServer), informing it that the measurement point value has been updated. The simulation engine 100 can then trigger relevant business logic, such as recording operation logs or notifying the visualization module 500 to update the display.

[0197] 5. Stopping and cleaning up protocol plugin container 401.

[0198] When the simulation device is stopped or removed, the simulation engine 100 notifies the protocol plugin container 401 to shut down the protocol plugin container 401, close the Modbus TCP listening port, disconnect all client connections, and release occupied memory and other resources through the pause interface (RuntimeService.StopContainer interface) and the delete container interface (RuntimeService.RemoveContainer interface). Finally, the system cleans up the sandbox environment to achieve real-time resource reclamation.

[0199] This embodiment demonstrates that a complete industrial protocol (Modbus TCP) is successfully encapsulated into an independent, standards-compliant protocol plugin container 401. By implementing a well-defined set of interfaces, it achieves decoupling from the simulation engine 100 and runs securely and efficiently in an isolated sandbox environment. This design fully demonstrates the effectiveness and superiority of this invention in achieving flexible protocol expansion, resource isolation, and efficient communication.

[0200] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0201] The above provides a detailed description of an industrial protocol simulation method and system provided by the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An industrial protocol simulation method, characterized in that, Includes the following steps: Create simulation equipment; The configuration information is determined based on the simulation equipment; Measurement point data is generated based on the configuration information, and the measurement point data is stored in an in-memory database; The protocol plugin container is used to establish a communication connection between the simulation device and the external device, so as to read the measurement point data from the memory database and write external data into the memory database.

2. The method according to claim 1, characterized in that, The configuration information includes at least one of the following: device information, task information, protocol plugin information, data measurement point information, and data generation strategy information.

3. The method according to claim 2, characterized in that, Generate measurement point data based on the configuration information, including: Based on the task information, task scheduling is performed using a hierarchical time wheel algorithm to obtain the tasks to be executed. Execute the task to be executed, and generate the measurement point data based on the data measurement point information and the data generation strategy information; The measurement point data is stored in the memory database.

4. The method according to claim 3, characterized in that, Based on the task information, a hierarchical time wheel algorithm is used for task scheduling to obtain the tasks to be executed, including: Tasks are categorized based on their cycle time to determine their hierarchical level, wherein the cycle time of a task is positively correlated with its hierarchical level. Write the tasks to the corresponding level slots at standard intervals; Control the time wheel of each level to roll at the corresponding period, and reduce the level of the task after the task of the higher level expires; The task to be executed is output through the slot at the lowest level.

5. The method according to claim 1, characterized in that, The process of establishing a communication connection between the simulation device and the external device using a protocol plugin container includes: All the protocol plugin containers are initialized through a unified plugin container interface, and each protocol plugin container encapsulates a protocol plugin. Select the corresponding protocol plugin container according to the communication protocol of the external device; An independent sandbox environment is established for the protocol plugin container through the plugin container interface; The configuration information is imported into the sandbox environment, and a communication connection is established between the simulation device and the external device within the sandbox environment.

6. The method according to claim 5, characterized in that, After establishing a communication connection between the simulation device and the external device within the sandbox environment, the process includes: Upon receiving a read instruction from the external device, the measurement point data in the memory database is read; The measurement point data is converted into the corresponding protocol format by the protocol plugin container and sent to the external device.

7. The method according to claim 5, characterized in that, After establishing a communication connection between the simulation device and the external device within the sandbox environment, the process includes: Upon receiving a write instruction from the external device, the write data from the external device is obtained; The written data is converted into the corresponding protocol format by the protocol plugin container and sent to the in-memory database.

8. The method according to claim 5, characterized in that, Before initializing all the aforementioned protocol plugin containers through a unified plugin container interface, the following is also included: The protocol plugin container is security verified through the plugin container interface. After the security verification is passed, the information of the protocol plugin container is registered in the configuration information.

9. The method according to claim 1, characterized in that, Before determining the configuration information based on the simulation device, the process also includes: The simulation device selects a storage database based on a quantitative analysis algorithm to store the configuration information.

10. The method according to claim 9, characterized in that, The simulation device selects a storage database based on a quantitative analysis algorithm, including: The metrics of the simulation equipment are evaluated based on the characteristics of its hardware resources and workload. Calculate the comprehensive decision score based on the indicators of the simulation equipment; The storage database is selected based on the comprehensive decision score.

11. The method according to claim 1, characterized in that, The method further includes: The simulation device, configuration information, measurement point data, and communication connection status between the simulation device and the external device can be interacted with in real time through a visual interface.

12. An industrial protocol simulation system, characterized in that, include: A simulation engine used to create simulated devices; The configuration management module is used to determine configuration information based on the simulation device; The data generation module is used to generate measurement point data according to the configuration information, and the measurement point data is stored in an in-memory database; The protocol plugin module includes multiple protocol plugin containers corresponding to different protocols. These containers are used to establish communication connections between the simulation device and external devices, enabling the reading of measurement point data from the memory database and the writing of external data into the memory database.

13. The system according to claim 12, characterized in that, The system also includes: The visualization module is used to enable real-time interaction with the simulation device, configuration information, measurement point data, and communication connection status between the simulation device and the external device through a visual interface.

Images