A virtual master-sensor simulation system and method for module interoperability testing

Abstract

The application discloses a virtual master-sensor simulation system and method for module interoperability testing, adopts a layered architecture, the bottom layer simulates a physical interface, the upper layer arranges test steps, and forms an end-to-end automatic verification process. The system comprises a virtual master engine module, a sensor behavior simulation module, a protocol adaptation and interface management module and a test script and scene configuration module; each is connected with each other through the same bus and cooperates. The application virtualizes various masters and sensors with a single hardware platform, reduces equipment procurement cost and breaks through the static scene limit. A built-in state machine and a physical dynamic model realize high-fidelity simulation, a protocol adaptation layer supports dynamic switching of mainstream industrial protocols, and the cross-protocol transparent connection capability of a terminal is verified. Full-process automatic management and quantitative evaluation mechanism upgrade the test from sampling inspection to systematic and comprehensive verification, and improve test efficiency, coverage depth and result reliability.

Description

Technical Field

[0001] This invention relates to the technical field of module interoperability testing, and more particularly to a virtual master controller-sensor simulation system and method for module interoperability testing. Background Technology

[0002] With the deep application of IoT technology in critical infrastructure monitoring fields such as power and transportation, the functionality of terminal devices in specific scenarios, such as icing monitoring terminals, highly depends on reliable and transparent connections between core communication and data acquisition modules and diverse main control devices. Currently, verifying the interoperability of such modules mainly relies on real hardware interface testing, requiring the construction of a complete environment including specific main control models, sensors, and peripheral circuits. This method is not only costly and rigid in configuration, but also difficult to simulate complex, edge, and abnormal operating conditions, resulting in limited test coverage and low efficiency. Especially for the core objective of "transparent connection," which requires modules to seamlessly adapt to the main control protocols and data interaction logic of different manufacturers, traditional testing methods have significant bottlenecks in terms of flexibility, scenario coverage, and test cost control. Therefore, there is an urgent need for a virtualized testing solution that can simulate diverse main control behaviors and sensor data sequences in a highly dynamic and low-cost manner to systematically verify various interaction scenarios that modules may encounter in the real world, ensuring their plug-and-play reliability and communication robustness in harsh industrial environments.

[0003] Currently, in the Industrial Internet of Things (IIoT) fields such as icing monitoring, the research and deployment of terminal communication modules face a key bottleneck: ensuring stable and reliable "transparent connection"—that is, seamless interoperability—with diverse and multi-protocol master control devices on the market. Traditional testing methods heavily rely on building real hardware environments, requiring the purchase and integration of various specific models of master control devices, sensors, and peripheral circuits, resulting in high testing costs and lengthy cycles. More challenging is the poor flexibility of such physical testing platforms, making it difficult to simulate complex and dynamic operating conditions, such as the gradual increase of icing, sudden wind-induced vibrations, instantaneous sensor failures, and severe communication anomalies like signal interference, protocol frame errors, and link interruptions. Test cases are often limited to a finite number of static points, failing to systematically cover all possible interactive states and edge cases in real deployments, resulting in significant blind spots in the verification of module interoperability and robustness. Summary of the Invention

[0004] In view of the aforementioned existing problems, this invention is proposed. Therefore, this invention provides a virtual master controller-sensor simulation system and method for module interoperability testing, solving the problems of high cost, fixed scenarios, and difficulty in covering complex edge cases inherent in traditional testing environments built with real hardware.

[0005] In a first aspect, embodiments of the present invention provide a virtual master-sensor simulation system for module interoperability testing, comprising: The virtual master control engine module is used to simulate the logical actions of industrial controllers based on a finite state machine model and generate logical signals. The sensor behavior simulation module is used to establish sensor output models based on physical laws and statistical methods, calculate and generate sensor data including normal and abnormal operating conditions, and provide input events for state transition to the virtual main control engine module. The test script and scenario configuration module is used to receive test scenario parameters and trigger conditions, generate control commands to drive the virtual main control engine module to run, and the sensor data generated by the sensor behavior simulation module is used to provide input events for state transition of the virtual main control engine module. The protocol adaptation and interface management module is communicatively connected between the virtual main control engine module and the module under test. It includes a protocol adaptation layer and a physical interface simulation layer. The protocol adaptation layer is used to load the corresponding protocol description file according to the protocol type indication in the logic signal and encapsulate the logic signal into a protocol frame. The physical interface simulation layer is used to convert the protocol frame into physical electrical signals that simulate the electrical characteristics of the real main control device and output them to the module under test to realize virtualized testing of module interoperability.

[0006] As a preferred embodiment of the virtual master controller-sensor simulation system for module interoperability testing described in this invention, wherein: the finite state machine model of the virtual master controller engine module adopts an extended model, represented as:

[0007] in, For a finite set of states, Let Ω be the input alphabet, λ be the output alphabet, λ be the output function, and V be the set of internal variables. This is the initial state; The state transitions of the virtual master control engine module are described using Markov chains:

[0008] in, Indicates the state Lower input receiver Then transferred to state The probability, Let be the probability distribution function that changes over time.

[0009] As a preferred embodiment of the virtual master-sensor simulation system for module interoperability testing described in this invention, wherein: in the sensor behavior simulation module, the tensile sensor output model under the icing monitoring scenario... The calculation formula is:

[0010] in, This is the initial preload. This is the icing growth coefficient. and These are ambient temperature and humidity, respectively. Let wind speed be a function. The periodic component caused by wind vibration. Gaussian white noise is used to simulate measurement errors.

[0011] As a preferred embodiment of the virtual master controller-sensor simulation system for module interoperability testing described in this invention, the protocol adaptation layer includes a protocol dynamic loader, which, upon receiving a protocol type indication from the virtual master controller engine module, unloads the current protocol description file and loads the corresponding industrial protocol description file. The protocol description file is defined using a declarative language and includes a frame start symbol, address field length, function code enumeration value, data field length calculation rules, and CRC check algorithm. The protocol adaptation layer encapsulates logical signals into protocol frames containing a message header, address, function code, data, and checksum according to the protocol description file.

[0012] As a preferred embodiment of the virtual master controller-sensor simulation system for module interoperability testing described in this invention, the physical interface simulation layer is implemented using a software-defined radio or programmable logic device, and is used to convert the digital bit stream of the protocol frame into a physical electrical signal according to the configured electrical characteristic parameters. The electrical characteristic parameters include rise time, fall time, voltage level, and signal bias; the physical interface simulation layer adjusts the electrical characteristic parameters to simulate RS-485 differential voltage or TTL single-ended voltage signals.

[0013] As a preferred embodiment of the virtual master controller-sensor simulation system for module interoperability testing described in this invention, the test script and scenario configuration module further includes a fault injection unit; the fault injection unit is used to inject preset fault types into the protocol adaptation layer or the physical interface simulation layer. The fault types include check errors caused by intentional tampering with the CRC check field, data errors caused by modifying the data payload, and delay injection caused by inserting a delay function into the transmission queue; The virtual master control engine module controls the module under test to enter the abnormal operating condition test process according to the triggering conditions and duration of the fault injection.

[0014] As a preferred embodiment of the virtual master controller-sensor simulation system for module interoperability testing described in this invention, the test script and scenario configuration module further includes a verification assertion unit; The verification assertion unit is used to receive the response data of the module under test and to make automatic judgments based on the predicate logic expression; The predicate logic expression includes basic assertion operators and logical operators, used to compare the error between the response data of the module under test and the expected result; The verification assertion unit generates a test report containing test coverage metrics based on the judgment result. The test coverage metrics are calculated based on the weight of the test cases and the execution results. The test script and scenario configuration module supports the automatic generation of test cases based on reinforcement learning algorithms; the reinforcement learning algorithm adjusts the test strategy according to historical test data and selects the test step sequence that can maximize the exposure of interoperability issues by optimizing the value function.

[0015] Secondly, the present invention provides a virtual master controller-sensor simulation method for module interoperability testing, comprising: The logic actions of an industrial controller are simulated based on a finite state machine model to generate logic signals; A sensor output model is established based on physical laws and statistical methods to calculate and generate sensor data that includes both normal and abnormal operating conditions. The test scenario parameters and triggering conditions are obtained, control commands are generated to drive the operation of the finite state machine model, and the sensor data is fed back to the finite state machine model as input. According to the protocol type indication in the logical signal, the corresponding protocol description file is loaded, and the logical signal is encapsulated into a protocol frame using the encapsulation rules defined in the protocol description file; The protocol frame is converted into a physical electrical signal that simulates the electrical characteristics of a real master control device, and the physical electrical signal is output to the module under test to realize virtualized testing of module interoperability.

[0016] Thirdly, the present invention provides an electronic device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the virtual master controller-sensor simulation method for module interoperability testing.

[0017] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the virtual master-sensor simulation method for module interoperability testing.

[0018] Compared with existing technologies, the advantages of this invention are as follows: This invention uses a software-defined approach to virtualize multiple master control devices and sensors on a single hardware platform, solving the core pain points of high equipment procurement costs and fixed test scenarios in traditional testing. The system's built-in master control state machine model and sensor dynamic model based on physical laws can simulate complex interactions and continuous changes in the real world with high fidelity, expanding the test environment from limited static scenarios to unlimited dynamic simulations. Secondly, its protocol adaptation layer adopts a dynamically configurable protocol stack architecture, supporting real-time parsing and generation of mainstream industrial protocols, achieving seamless test switching across protocols and vendors, and verifying the "transparent connection" capability of terminal modules. Finally, the fully automated test management and closed-loop verification mechanism, combined with an evaluation system based on quantitative indicators, transforms testing from manual sampling inspection to systematic and comprehensive empirical verification, improving testing efficiency, coverage depth, and result reliability, providing strong technical support for the rapid iteration and highly reliable deployment of IoT terminal products. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a schematic diagram of the system structure of a virtual master controller-sensor simulation system for module interoperability testing according to an embodiment of the present invention; Figure 2 This is a schematic flowchart of a virtual master controller-sensor simulation method for module interoperability testing according to an embodiment of the present invention. Detailed Implementation

[0020] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0021] Example 1, referring to Figure 1As one embodiment of the present invention, this embodiment provides a virtual master controller-sensor simulation system for module interoperability testing, such as... Figure 1 As shown, it includes: The virtual master control engine module is used to simulate the logical actions of industrial controllers based on a finite state machine model and generate logical signals. The sensor behavior simulation module is used to establish sensor output models based on physical laws and statistical methods, calculate and generate sensor data including normal and abnormal operating conditions, and provide input events for state transition to the virtual main control engine module. The test script and scenario configuration module is used to receive test scenario parameters and trigger conditions, generate control commands to drive the virtual main control engine module to run, and the sensor data generated by the sensor behavior simulation module is used to provide input events for state transitions to the virtual main control engine module. The protocol adaptation and interface management module is a communication connection between the virtual main control engine module and the module under test. It includes a protocol adaptation layer and a physical interface simulation layer. The protocol adaptation layer is used to load the corresponding protocol description file according to the protocol type indication in the logic signal and encapsulate the logic signal into a protocol frame. The physical interface simulation layer is used to convert the protocol frame into physical electrical signals that simulate the electrical characteristics of the real main control device and output them to the module under test to realize virtualized testing of module interoperability.

[0022] It should be noted that this system is scalable and adopts a layered architecture. The bottom layer simulates physical interfaces, while the upper layer orchestrates test procedures, forming an end-to-end automated verification process. The four modules mentioned above are interconnected and work collaboratively via a common bus. Specifically, the virtual master control engine module simulates the logical actions of various industrial controllers, supporting simulation of microcontrollers and programmable logic controllers. The sensor behavior simulation module calculates and generates output data from physical sensors under different environmental conditions based on mathematical models, including output data under normal operating conditions and output data under fault conditions. The protocol adaptation and interface management module converts upper-layer logic signals to physical interface signals, acting as a bridge between the two. The test script and scenario configuration module has an interface and supports automated testing, allowing testers to flexibly configure and execute various test tasks.

[0023] Furthermore, the logic signals are a set of high-level data and control commands output by the virtual main control engine after state machine calculations, and then sent to the protocol adaptation and interface management layer. Specifically, the logic signals contain the following three types of information: 1. Data value signal: The virtual master control engine calculates the specific data content that needs to be sent to the DUT based on the current state and input, such as virtual sensor data and time events. For example, the parameters carried in the command to read the tension sensor sent to the DUT, such as register address 0x0001; and the configuration parameters sent to the DUT, such as sampling period of 500ms and alarm threshold of 15mm.

[0024] 2. Protocol type indicator: This indicates which industrial protocol (Modbus RTU, S7 PPI, HostLink, etc.) should be used for encapsulation. This indicator signal tells the protocol adaptation layer to select the corresponding protocol description file for frame assembly.

[0025] 3. Timing constraint signals, which include time-related parameters such as expected response timeout, frame interval, and retransmission count. For example, a logic signal might carry a field... This indicates that the module under test is expected to return a response within 200ms.

[0026] It should be noted that logical signals are abstract information independent of specific physical interfaces and protocol formats. They are generated by the virtual master control engine and passed to the protocol adaptation layer for the next step of physical signal conversion.

[0027] Furthermore, the virtual master control engine focuses on a mathematical model built using finite state machines (FSMs) and sequential logic. Each virtual master control device is defined as:

[0028] Where Q is a finite set of states, representing the various operating states that the master control device can be in; Σ is the input alphabet, containing sensor data, user commands, time events, etc.; and δ: Q × Σ → Q is the state transition function. It is the initial state. It is a set of acceptance states, representing the state of successful test completion.

[0029] In one feasible approach, for complex industrial controllers, the system extends the model by adding output functions and internal variables.

[0030] Specifically, the underlying implementation of industrial controller simulation can be divided into the following four layers: Taking the Siemens S7-1200 model as an example, the state set is as follows: In software implementation, it can be encoded as an enumeration type.

[0031] State transition function It is implemented as event-driven table lookup logic. A typical implementation uses a two-dimensional array (state transition table) statement.

[0032] The timing logic is implemented through a timer queue and timestamp comparison. Each virtual master instance maintains a list of timers, recording future actions to be triggered (such as polling and timeout checks). In the system's main loop, each iteration checks the current timestamp; if the trigger time of a certain timer is reached, the corresponding timing event is generated and pushed into the event queue. The mathematical formula is: .

[0033] The main loop of the virtual master engine is an event-driven scheduler. It outputs logical signals to the protocol adaptation layer.

[0034] Furthermore, the finite state machine model of the virtual master control engine module adopts an extended model, represented as follows:

[0035] in, For a finite set of states, Let Ω be the input alphabet, λ be the output alphabet, λ be the output function, and V be the set of internal variables. This is the initial state; The state transitions of the virtual master control engine module are described using Markov chains:

[0036] in, Indicates the state Lower input receiver Then transferred to state The probability, Let be the probability distribution function that changes over time.

[0037] Furthermore, in the sensor behavior simulation module, the tensile sensor output model under the icing monitoring scenario... The calculation formula is:

[0038] in, This is the initial preload. This is the icing growth coefficient. and These are ambient temperature and humidity, respectively. Let wind speed be a function. The periodic component caused by wind vibration. Gaussian white noise is used to simulate measurement errors.

[0039] Furthermore, for a tilt sensor, its output angle θ can be expressed as:

[0040] in, It is the initial installation angle. It is the structural elasticity coefficient. It is the line stiffness. This indicates the vibration response caused by wind load.

[0041] Furthermore, the protocol adaptation layer includes a protocol dynamic loader, which, upon receiving a protocol type indication from the virtual master control engine module, unloads the current protocol description file and loads the corresponding industrial protocol description file. The protocol description file is defined using a declarative language and includes a frame start symbol, address field length, function code enumeration value, data field length calculation rules, and CRC check algorithm. The protocol adaptation layer encapsulates logical signals into protocol frames containing a message header, address, function code, data, and checksum according to the protocol description file.

[0042] Specifically, the protocol adaptation layer receives logical signals from the virtual master control engine, loads the corresponding protocol description file based on the "protocol type indication" carried in the signal, and encapsulates the data according to the frame generation formula in the disclosure document. The byte lengths and value rules for Header, Address, Function, and CRC are defined by the protocol description file. The Data portion originates from the specific data values ​​in the logic signals, such as the starting address and number of registers to be read. The system generates CRC checksums by looking up tables or calculating in real time (e.g., CRC-16 in Modbus RTU).

[0043] The encapsulated protocol frame is sent to the UART / SPI controller simulator in the physical interface simulation layer. This simulator converts each byte into a serial bit stream according to the configured communication parameters and adds start bits, stop bits, and optional parity bits. For example, in ASCII mode, a hexadecimal-to-ASCII character conversion may also be performed.

[0044] Specifically, the physical interface simulation layer uses a software-defined radio (SDR) or programmable logic device (FPGA) hardware platform to generate real differential voltages (such as the A / B line voltage difference of RS-485) or single-ended voltages (such as TTL 0V / 3.3V) based on the bit stream values ​​(0 / 1) and configured electrical characteristic parameters (rise time, fall time, level amplitude, signal bias). Mathematically, for bit b in the time interval... Internally, the output voltage is ,in , It simulates a function with gradually varying edges (such as a first-order RC charging curve), implemented through pre-emphasis or delay circuits in an FPGA.

[0045] The conversion process from logic signals to physical signals is real-time, and a specified silence time can be maintained between frames (determined by timing constraints in the logic signals), thus completely simulating the physical layer behavior of a real master control device.

[0046] It should be noted that the protocol adaptation layer uses a flexible and adjustable protocol structure, capable of converting one industrial communication protocol into another in real time. Protocol processing primarily relies on an interpretation and execution engine that operates according to the Protocol Description Language (PDL). The generation method for each protocol frame is calculated using the following formula: Frame=Header⊕Address⊕Function⊕Data⊕CRC Wherein, ⊕ represents a byte concatenation operation, Header is the start-of-frame flag sequence, Address is the device address field, Function is the function code that defines the operation type, Data is the payload data with variable length, and CRC is the cyclic redundancy check code.

[0047] Furthermore, for protocols with high time requirements, the system uses real-time scheduling algorithms to ensure time accuracy and that response times are within specified limits.

[0048] in, It is the expected response time stipulated in the agreement. This is the time jitter allowed by the system, which is usually less than 5% of the time specified in the protocol.

[0049] Furthermore, the physical interface simulation layer is implemented using software-defined radio or programmable logic devices to convert the digital bit stream of the protocol frame into physical electrical signals according to the configured electrical characteristic parameters; Electrical characteristic parameters include rise time, fall time, voltage level, and signal bias; the physical interface simulation layer adjusts electrical characteristic parameters to simulate RS-485 differential voltage or TTL single-ended voltage signals.

[0050] Specifically, the physical interface simulation layer uses software-defined radio (SDR) and programmable logic devices (FPGA) to simulate electrical characteristics. The rise time and fall time of digital signals, as well as the accuracy and bandwidth of analog signals, can all be changed by adjusting parameters, thus adapting to different interface standards.

[0051] The parameter adjustment mechanism adopts a layered configurable parameter model, which includes three layers: the first layer is the communication parameter configuration (physical layer). For wired interfaces such as RS-485 and RS-232, the system maintains a communication parameter structure that can be dynamically modified according to protocol standards. The adjustment mechanism involves test scripts or users specifying the communication parameters of the target master device through configuration files (such as JSON / YAML). The system then calls functions in the driver layer to update the FPGA / SDR registers in real time without requiring a restart. For switching from Modbus RTU to Modbus ASCII, only the baud rate (sometimes the same) and frame encapsulation format need to be modified.

[0052] The second layer is the protocol frame structure configuration (data link layer / application layer): The protocol adaptation layer maintains a Protocol Description File (PDF), which defines various characteristics of the protocol in a declarative language (such as XML or a custom DSL), such as the fixed byte sequence of the start-of-frame (Header), the length, position, and byte order of the address field, the enumerated values ​​of the function codes and their corresponding operational meanings, the rules for calculating the length of the data field (fixed / variable / depending on the function code), the CRC algorithm type (CRC-16 / CRC-32 / accumulation) and checksum position, and the response timeout and retransmission strategy.

[0053] The adjustment mechanism works by unloading the current PDF, loading the new PDF, and resetting the protocol parsing state machine when a protocol switch is needed (e.g., from Modbus RTU to S7 PPI). The loading process can be completed within microseconds without affecting other modules. Users can also select the "target controller brand and model" from the dropdown menu in the graphical interface, and the system will automatically associate the corresponding PDF.

[0054] The third layer is timing parameter configuration: For time-sensitive protocols, the system provides a timing parameter configuration interface, including inter-character timeout. (Modbus standard); minimum inter-frame interval; maximum response wait time.

[0055] The adjustment mechanism involves writing these parameters into the configuration table of the real-time scheduler, which is then monitored by a high-precision timer (based on the CPU clock or FPGA counter).

[0056] The essence of the parameter adjustment mechanism is to extract the values ​​and rules in the protocol standard into a set of configurable parameters, and to achieve flexible switching of the protocol through dynamic loading and real-time reconfiguration, without recompiling or restarting the system, so as to ensure that the platform can adapt to various known and future industrial protocol standards.

[0057] Furthermore, the test script and scenario configuration module also includes a fault injection unit; the fault injection unit is used to inject preset fault types into the protocol adaptation layer or physical interface simulation layer. Fault types include check errors caused by intentional tampering with the CRC check field, data errors caused by modifying the data payload, and delay injection caused by inserting a delay function into the transmission queue; The virtual master control engine module controls the module under test to enter the abnormal operating condition test process based on the triggering conditions and duration of the fault injection.

[0058] Furthermore, test scenarios are arranged according to the triggering of events and time requirements. A complete test scenario can be understood as: Scenario=(E,C,A,T) in, It is a set of events, where C⊆E×E represents the temporal constraints between the events. A:E→Action is the mapping from event to specific operation, T:E→ It is a function that represents the timing attribute of an event.

[0059] Specifically, each test event consists of three parts: triggering condition, execution action, and verification assertion. In automated test scenario orchestration and execution, the "triggering condition" is the prerequisite for initiating the test action. The specific criteria for the triggering condition include: 1. Time-triggered conditions: Triggered when the system time (global simulation clock) reaches a preset time point, or when a specified duration has elapsed relative to a certain event. For example, absolute time is at_time=12:00:00 or simulation_time=3600s. Relative delays are after (300ms) and delay (10s). Periodic trigger is every (5s).

[0060] The triggering object is to trigger a test action, such as switching the virtual master controller model, changing the virtual sensor parameters, injecting a communication fault, or recording a snapshot of the current data.

[0061] 2. State Change Trigger Conditions: Triggered when the state variable value of the test system or the module under test changes, and the changed value meets the preset predicate condition. For example, the virtual master engine's state changes from POLLING to FAULT. The alarm flag reported by the module under test changes from false to true. Three consecutive sampled values ​​in the data stream exceed the threshold (e.g., tensile force > 1500N).

[0062] State variables include the current state of the virtual master controller. The data includes virtual sensor output values, register values ​​reported by the module under test, and the health status of the communication link.

[0063] For example, when virtual_master.state==FAULT, a "diagnostic action" is triggered, which saves the error log and switches to the standby master control model.

[0064] 3. Data reception trigger conditions: Triggered when the protocol adaptation layer successfully parses and receives a complete frame, or receives specific data content. For example, receiving any frame on_frame_received; or receiving a Modbus request frame with function code 0x03; or receiving a data frame in which a field equals the expected value (e.g., device_id==0x01); or receiving an abnormal response (e.g., Modbus exception code 0x02).

[0065] The triggering object refers to the data comparison action triggered when the tensile data frame returned by the module under test is received. The reported value is compared with the reference value of the virtual model in real time, and the error is recorded.

[0066] It should be noted that the test engine maintains an event-action mapping table, with each triggering condition corresponding to a predicate function. ,in This is the current event (time event, state change event, data reception event). When At that time, the engine immediately executes the set of actions bound to that condition. , is represented as: .

[0067] Furthermore, the specific process of executing actions is scheduled by the test script execution engine, which includes: 1. Modify virtual environment parameters: This type of action changes the state or configuration of the simulation model by calling the application programming interfaces (APIs) of each module.

[0068] The specific process involves specifying the target module (e.g., "virtual master control engine" or "sensor behavior simulation module") and parameter names (e.g., "icing growth coefficient α", "temperature setpoint", "wind speed function type") in the test script. The execution engine parses the action and sends parameter update instructions to the target module via remote procedure call (gRPC / REST) ​​or message queue. The target module receives the instructions, verifies the validity of the parameter range, and then updates its internal variables. The physical equations in the sensor model immediately recalculate the output values ​​according to the new parameters. After the update is complete, the target module returns an acknowledgment message. The entire process typically takes less than 10ms.

[0069] 2. Sending Protocol Commands: This type of action sends specific protocol frames to the Module Under Test (DUT) through the protocol adaptation layer.

[0070] The specific process involves defining the action, including the target protocol type, function code, data payload, and expected response (optional). The execution engine submits the action to the protocol instruction queue, which is then retrieved by the protocol adaptation layer's worker thread. The protocol adaptation layer encapsulates the instructions into raw protocol frames based on the currently active protocol description file (PDF). The physical interface simulation layer converts the frames into electrical signals and sends them to the DUT. If an expected response is specified, the system starts a timeout timer, waiting for the DUT's reply. The reply result (success / timeout / error code) is recorded in the test log.

[0071] 3. Introducing faults: This type of action deliberately disrupts normal communication or the integrity of sensor data during the test in order to verify the robustness of the module under test.

[0072] The specific process involves fault types including CRC errors, frame format errors, delay injection, packet loss, sensor data mutations / freezing, and power interruptions. The execution engine sends instructions to the fault injection module, specifying the fault type, duration, and triggering condition (immediately or on a specific frame). Based on the instructions, the fault injection module intervenes at the protocol adaptation layer or physical interface simulation layer: for CRC errors, it intentionally inverts or writes a random value to one byte of the CRC field after frame encapsulation. For delay injection, it inserts a delay function into the transmission queue, causing a specific frame to be sent later. For sensor data mutations, it directly modifies the output buffer of the sensor simulation module, forcing the value at a certain moment to be 0 or the maximum value. After the fault lasts for the specified time, it automatically recovers. The system records the behavior of the module under test throughout the fault period and after recovery.

[0073] Each action has a unique ID, and upon completion, it triggers a verification assertion action to automatically assess the DUT's response. These processes are fully automated, achieving a closed-loop test.

[0074] Furthermore, the test script and scenario configuration module also includes a verification assertion unit; The verification assertion unit is used to receive the response data from the module under test and to make automatic judgments based on the predicate logic expression; Predicate logic expressions include basic assertion operators and logical operators, used to compare the error between the response data of the module under test and the expected result; The verification assertion unit generates a test report containing test coverage metrics based on the judgment results. The test coverage metrics are calculated based on the weight of the test cases and the execution results. The test script and scenario configuration module supports the automatic generation of test cases based on reinforcement learning algorithms; the reinforcement learning algorithm adjusts the test strategy based on historical test data and selects the test step sequence that can maximize the exposure of interoperability issues by optimizing the value function.

[0075] It should be noted that the core of the verification assertion unit is a programmable assertion evaluator, whose judgment logic is based on predicate logic expressions. The specific judgment logic includes: The system can predefine the following basic conditional operators, which can be used in combination, as shown in Table 1: Table 1 Basic Assertion Types

[0076] Basic assertions can be combined with logical operators to form complex judgment logic: The condition (∧) is such that all subconditions of AND(P1,P2,...) must be true.

[0077] OR (∨) means that at least one subcondition of OR (P1, P2, ...) is true.

[0078] The condition not (¬) is that the subcondition of not (P) is not true.

[0079] Implies (→) are implies(P,Q) if P is true then Q must be true.

[0080] After the test actions are executed, the system collects the responses of the module under test (including protocol response data, state variable changes, and logs). The actual output of the assertion module is matched against the pre-defined assertion expressions in the test script. Each assertion has a tolerance parameter (such as absolute error, relative error, and time jitter threshold). The evaluation result returns "pass" or "fail," along with detailed information (such as actual value vs. expected value, and error amount). All pass / fail cases of assertions are summarized in the test report and participate in the calculation of test coverage metrics. The assertion module internally uses an expression tree to represent P(actual, expected). In summary: , in, This is the number of assertions in the current test case. An assertion passes when all predicates are true simultaneously.

[0081] Through the above design, the verification assertion unit can flexibly express various test intentions and achieve fully automated judgment without human intervention.

[0082] Test coverage is quantified and evaluated using the following metrics:

[0083] Where N is the total number of test cases. It is the weight of the i-th test case. It is the execution result of the i-th test case (1 for pass, 0 for fail).

[0084] Furthermore, the system adopts a microservice architecture, with modules communicating through message queues and remote call interfaces. The virtual master control engine module and the sensor behavior simulation module each run in independent container instances, and the number of instances can be increased as needed to handle large-scale concurrent test requests. The protocol adaptation and interface management module employs zero-copy and memory pool technologies to reduce data copying and improve response speed.

[0085] Furthermore, the system employs machine learning methods to optimize the test case generation process. Specifically, based on historical test data, the system dynamically adjusts the testing strategy using a reinforcement learning model, and its value function update follows the formula:

[0086] in, α is the value estimate of performing action a in state s, where α is the learning rate, r is the immediate reward, and γ is the discount factor. It is the new state after the transfer. Through the above mechanism, the system can learn and search during the testing process, automatically selecting the test step sequence that is most likely to expose interoperability issues, thereby improving testing efficiency.

[0087] Reference Figure 2 This embodiment also provides a virtual master controller-sensor simulation method for module interoperability testing, including: Step S100: Simulate the logical actions of the industrial controller based on the finite state machine model to generate logical signals; Step S200: Establish a sensor output model based on physical laws and statistical methods, and calculate and generate sensor data that includes normal and abnormal operating conditions; Step S300: Obtain test scenario parameters and triggering conditions, generate control commands to drive the operation of the finite state machine model, and feed sensor data back to the finite state machine model as input; Step S400: Based on the protocol type indication in the logic signal, load the corresponding protocol description file, and encapsulate the logic signal into a protocol frame using the encapsulation rules defined in the protocol description file; Step S500: Convert the protocol frame into a physical electrical signal that simulates the electrical characteristics of the real master control device, and output the physical electrical signal to the module under test to realize virtualized testing of module interoperability.

[0088] This embodiment also provides an electronic device suitable for a virtual master-sensor simulation method used for module interoperability testing, including: The memory and processor are used to store computer-executable instructions and execute the computer-executable instructions to implement the virtual master-sensor simulation method for module interoperability testing as proposed in the above embodiments.

[0089] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements the virtual master-sensor simulation method for module interoperability testing as proposed in the above embodiments.

[0090] The storage medium proposed in this embodiment and the virtual master controller-sensor simulation method for module interoperability testing proposed in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0091] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0092] Example 2 is an embodiment of the present invention. This embodiment differs from the first embodiment in that it performs interoperability testing on an ice-covering monitoring terminal communication module called "ice core-T1 module" to verify the beneficial effects of the present invention.

[0093] In this embodiment, the icing monitoring terminal communication module is applied to a power transmission line monitoring system. It needs to work collaboratively with programmable logic controllers (PLCs) from different manufacturers to acquire real-time data from tension sensors, tilt sensors, and temperature and humidity sensors, and then transparently transmit the data to the monitoring center via a 4G network. The project requires this module to be plug-and-play compatible, supporting at least three mainstream PLCs: Siemens S7-1200, Schneider Modicon M221, and Omron CP1H. Furthermore, it must ensure data transmission stability and the applicability of the communication protocol under weather conditions such as wind, rain, and snow.

[0094] Traditional testing methods require building three separate, complete hardware environments, which is costly and cannot systematically simulate the gradual increase in icing, nor can they reproduce various abnormal communication conditions. This embodiment uses a virtual master controller-sensor simulation system to integrate the interoperability testing of all target master controllers onto a single platform. The test mainly verifies three indicators: the module's ability to correctly parse communication protocols, the accuracy of reported data, and operational stability under abnormal conditions. The test focuses on whether the module can still collect sensor data normally and report it accurately when switching to different master controllers, which causes changes in command format and interaction timing.

[0095] In the test script and scenario configuration module, a test scenario was created and named "Comprehensive Test of Multi-Master Controller Ice Growth and Fault Injection". The scenario is divided into three stages: system stabilization stage, ice gradually thickening stage, and communication anomaly and recovery stage. The entire process simulates 72 hours.

[0096] The key model configuration is as follows: The virtual master control engine loads three master control device models: Siemens S7-1200 (version 2.1), Schneider M221 (version 1.5), and Omron CP1H (version 3.0). Each model is implemented using a state machine approach based on its corresponding product manual. Taking the Siemens model as an example, its state machine is defined as follows:

[0097] The state set Q = {IDLE, POLLING, CONFIG, DIAG, FAULT} and the input set Σ include three types of events: timer events, virtual sensor data ready events, and response frames from the module under test. The state transition function implements the polling logic. For example, in the POLLING state, once a sensor data ready signal is received, the state transitions to DIAG for inspection.

[0098] The sensor behavior simulation module is configured with three virtual sensor instances: The tension sensor (analog model: HT-F201) uses a physical model of gradually increasing ice thickness, and its output value is calculated according to the following formula:

[0099] Among them, the initial preload =1000 N, coefficient of friction when icing α =0.15; temperature T(τ) and relative humidity RH(τ) are provided by the temperature and humidity sensor model, simulating the cooling process from +2℃ to -5℃, with relative humidity varying between 85% and 100%; v(τ) is the simulated gust wind speed, ranging from 0 to 15 m / s; eccentric tension β = 50 N, wind vibration angular frequency ω = 2π / 10, corresponding to a period of 10 seconds; ε(t) represents the measurement noise.

[0100] The tilt sensor output θ(t) is correlated with the tension value:

[0101] Wherein, the initial tilt angle =0, coefficient γ=0.002, equivalent stiffness k=5000 N / m, wind amplitude δ=0.5, frequency f=1Hz.

[0102] Temperature and humidity composite sensor: outputs a preset temperature and humidity change curve to drive the above model.

[0103] The protocol adaptation and interface management layer simulates an RS-485 physical interface, with communication parameters set as follows: baud rate 9600bps, 8 data bits, 1 stop bit, and even parity. The system simultaneously loads three protocol description files: Modbus RTU (corresponding to Schneider Electric controllers), S7 PPI simplified version (corresponding to Siemens controllers), and HostLink (corresponding to Omron controllers); it automatically switches to the appropriate communication protocol based on the currently active virtual controller type.

[0104] After the test is started, the system executes automatically in stages. The RS-485 interface of the module under test is connected to the system's protocol adaptation layer via a USB converter, and its 4G uplink interface is connected to a separate test server to receive and verify uplink data.

[0105] Phase 1 (0-12 hours): The virtual Siemens S7-1200 master controller starts working first, starting from IDLE state, executing the initialization process, and sending a device identification command to the module under test (DUT). The system verifies whether the module responds with the correct information, including the device model and version. Subsequently, the master controller enters POLLING state, polling the three sensor data channels every 2 seconds. At this time, the tension sensor output is basically stable at F(t)≈1000+ε(t). The protocol adaptation layer encapsulates the request according to the S7 PPI protocol frame format and calculates the cyclic redundancy check code in real time. The correct response from the DUT is recorded, and the test server compares the data reported from the cloud with the virtual sensor output value to verify whether the two are consistent within the allowable error range. Baseline data is collected in this phase.

[0106] Phase Two (12-60 hours): The system triggers the "icing growth" event. The ambient temperature gradually decreases from 2°C to -5°C along a preset curve, while the relative humidity remains above 95%. A random gust model is introduced for wind speed. The tension sensor output increases significantly according to the integral model, superimposed with wind vibration effects; the tilt sensor shows a slight change accordingly. At this point, the test script automatically switches the master controller to the Schneider Modicon M221 model. The polling cycle and instruction format of this master controller differ from those of the Siemens master controller (e.g., using Modbus function code 03 to read the holding register). The system verifies whether the module under test can seamlessly adapt to this switch, i.e., correctly parse the new protocol and return data without restarting or reconfiguration. In the middle of this phase, the master controller is further switched to the Omron CP1H model for equivalent verification.

[0107] Phase Three (60-72 hours): Performing abnormal stress tests. First, the protocol adaptation layer intentionally alters the cyclic redundancy check (CRC) code when sending a data frame according to script instructions, simulating line interference. The test module is observed to see if it detects the error and discards the frame as required by the protocol (either by not responding or returning an error code). Second, a sensor disconnection is simulated by momentarily setting the output of the tension sensor to zero and maintaining it, verifying whether the test module can correctly report this abnormal state (such as a register value of zero or a specific error flag). Third, frequent power-on and power-off cycles of the main control unit are simulated: the virtual main control engine continuously executes 10 "power-off-start-polling" operations within 5 minutes, verifying whether the test module can successfully reconnect and maintain uninterrupted data transmission.

[0108] Protocol consistency analysis showed that the module under test could correctly parse the basic function codes of the three main control protocols, but a timeout occurred when processing a non-standard extended instruction of the Omron HostLink protocol, revealing an interoperability issue. Data accuracy analysis showed that throughout the entire icing growth simulation process, the correlation coefficient between the tensile force data reported by the module under test and the calculated value of the virtual model reached 0.999, and the maximum absolute error did not exceed 15N, meeting the accuracy requirements.

[0109] Performance metrics are quantified as follows: Test throughput: The system manages 3 groups of virtual controllers and sensors in parallel. 72 hours of simulation testing is equivalent to 216 hours of testing workload using a traditional single-threaded method. Problem detection capability: A total of 245 test cases were executed, covering normal, boundary, and abnormal scenarios. Test coverage: Based on the formula:

[0110] Where N=245, Based on the weights assigned according to functional importance, the calculated overall test coverage is 98.7%, which is significantly higher than the approximately 70% coverage estimated by traditional hardware testing.

[0111] Anomaly handling verification: In the test of injecting cyclic redundancy check error codes 20 times, the module under test successfully detected all errors; when simulating sensor disconnection, the module under test reported disconnection alarm within two polling cycles (maximum 4 seconds), which is consistent with the design expectation.

[0112] The above embodiments demonstrate that this testing system is an essential verification platform in the "Research on Key Technologies for Transparent Connection of Icing Terminal Modules," solving the problems of hardware dependence and high cost in multi-master controller adaptation testing. Through reasonable modeling and automation, interoperability testing is upgraded from functional sampling checks to systematic practical verification, laying a solid foundation for the stable and reliable operation of power Internet of Things terminals.

[0113] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A virtual master-sensor simulation system for module interoperability testing, characterized in that, include: The virtual master control engine module is used to simulate the logical actions of industrial controllers based on a finite state machine model and generate logical signals. The sensor behavior simulation module is used to establish sensor output models based on physical laws and statistical methods, calculate and generate sensor data including normal and abnormal operating conditions, and provide input events for state transition to the virtual main control engine module. The test script and scenario configuration module is used to receive test scenario parameters and trigger conditions, and generate control commands to drive the virtual main control engine module to run. The protocol adaptation and interface management module is communicatively connected between the virtual main control engine module and the module under test. It includes a protocol adaptation layer and a physical interface simulation layer. The protocol adaptation layer is used to load the corresponding protocol description file according to the protocol type indication in the logic signal and encapsulate the logic signal into a protocol frame. The physical interface simulation layer is used to convert the protocol frame into physical electrical signals that simulate the electrical characteristics of the real main control device and output them to the module under test to realize virtualized testing of module interoperability.

2. The virtual master controller-sensor simulation system for module interoperability testing as described in claim 1, characterized in that, The finite state machine model of the virtual master control engine module adopts an extended model, represented as follows: in, For a finite set of states, Let Ω be the input alphabet, λ be the output alphabet, λ be the output function, and V be the set of internal variables. This is the initial state; The state transitions of the virtual master control engine module are described using Markov chains: in, Indicates the state Lower input receiver Then transferred to state The probability, Let be the probability distribution function that changes over time.

3. The virtual master controller-sensor simulation system for module interoperability testing as described in claim 2, characterized in that, In the sensor behavior simulation module, the tensile sensor output model under the icing monitoring scenario The calculation formula is: in, This is the initial preload. This is the icing growth coefficient. and These are ambient temperature and humidity, respectively. Let wind speed be a function. The periodic component caused by wind vibration. Gaussian white noise is used to simulate measurement errors.

4. The virtual master controller-sensor simulation system for module interoperability testing as described in claim 3, characterized in that, The protocol adaptation layer includes a protocol dynamic loader, which is used to unload the current protocol description file and load the corresponding industrial protocol description file when it receives a protocol type indication from the virtual main control engine module. The protocol description file is defined using a declarative language and includes a frame start symbol, address field length, function code enumeration value, data field length calculation rules, and CRC check algorithm. The protocol adaptation layer encapsulates logical signals into protocol frames containing a message header, address, function code, data, and checksum according to the protocol description file.

5. The virtual master controller-sensor simulation system for module interoperability testing as described in claim 4, characterized in that, The physical interface simulation layer is implemented using software-defined radio or programmable logic devices and is used to convert the digital bit stream of the protocol frame into physical electrical signals according to the configured electrical characteristic parameters. The electrical characteristic parameters include rise time, fall time, voltage level, and signal bias; the physical interface simulation layer adjusts the electrical characteristic parameters to simulate RS-485 differential voltage or TTL single-ended voltage signals.

6. The virtual master controller-sensor simulation system for module interoperability testing as described in claim 5, characterized in that, The test script and scenario configuration module also includes a fault injection unit; the fault injection unit is used to inject preset fault types into the protocol adaptation layer or physical interface simulation layer. The fault types include check errors caused by intentional tampering with the CRC check field, data errors caused by modifying the data payload, and delay injection caused by inserting a delay function into the transmission queue; The virtual master control engine module controls the module under test to enter the abnormal operating condition test process according to the triggering conditions and duration of the fault injection.

7. The virtual master controller-sensor simulation system for module interoperability testing as described in claim 6, characterized in that, The test script and scenario configuration module also includes a verification assertion unit; The verification assertion unit is used to receive the response data of the module under test and to make automatic judgments based on the predicate logic expression; The predicate logic expression includes basic assertion operators and logical operators, used to compare the error between the response data of the module under test and the expected result; The verification assertion unit generates a test report containing test coverage metrics based on the judgment result. The test coverage metrics are calculated based on the weight of the test cases and the execution results. The test script and scenario configuration module supports the automatic generation of test cases based on reinforcement learning algorithms; the reinforcement learning algorithm adjusts the test strategy according to historical test data and selects the test step sequence that can maximize the exposure of interoperability issues by optimizing the value function.

8. A virtual master-sensor simulation method for module interoperability testing, characterized in that, include: The logic actions of an industrial controller are simulated based on a finite state machine model to generate logic signals; A sensor output model is established based on physical laws and statistical methods to calculate and generate sensor data that includes both normal and abnormal operating conditions. The test scenario parameters and triggering conditions are obtained, control commands are generated to drive the operation of the finite state machine model, and the sensor data is fed back to the finite state machine model as input. According to the protocol type indication in the logical signal, the corresponding protocol description file is loaded, and the logical signal is encapsulated into a protocol frame using the encapsulation rules defined in the protocol description file; The protocol frame is converted into a physical electrical signal that simulates the electrical characteristics of a real master control device, and the physical electrical signal is output to the module under test to realize virtualized testing of module interoperability.

9. An electronic device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the virtual master-sensor simulation method for module interoperability testing as described in claim 8.

10. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the virtual master-sensor simulation method for module interoperability testing as described in claim 8.

Images