SIS simulation control platform and SIS simulation control method

Abstract

The invention provides an SIS simulation control platform and an SIS simulation control method, and relates to the technical field of industrial control, the system comprises a communication adaptation module, a protocol driving module, a core service processing module and at least two controller service modules; a system identifier in a network data packet is analyzed through a protocol driving module, and intelligent routing is realized through a core service processing module, so that a single platform can dynamically call different controller service modules, and compatibility and simulation of various types of real controllers (such as TCS-900 and TCS-500 systems) are realized. According to the design, the problems of one-machine-one-simulation and system splitting in a traditional scheme are fundamentally solved, the reuse rate of simulation codes and architecture is greatly improved, and the cost of repeatedly developing an independent simulation system for each type of controllers is avoided.

Description

Technical Field

[0001] This invention relates to the field of industrial control technology, and more specifically, to a SIS simulation control platform and a SIS simulation control method. Background Technology

[0002] In complex industrial scenarios such as petrochemicals, power generation, and rail transportation, Safety Instrumented Systems (SIS) are used to implement critical safety interlocking and protection functions, requiring extremely high reliability. During system development, engineering configuration, and commissioning phases, thorough verification and testing of the control logic are typically necessary. Traditional methods heavily rely on actual physical controller hardware, leading to high development costs, limited equipment resources, and long and risky on-site commissioning cycles. To improve efficiency, the industrial control field has gradually introduced virtual simulation technology. By simulating the behavior of the controller through software, the host computer software and configuration logic can be tested without the actual hardware.

[0003] However, most existing simulation solutions are customized for specific controller models or series, with the simulation software tightly coupled to the business logic of the real controller. For example, a simulation controller developed for the TCS-900 system cannot be used for the TCS-500 system, and vice versa. This "one-model-one-simulation" approach leads to redundant construction of simulation platforms, low code reuse rates, maintenance difficulties, and difficulty in adapting to the needs of engineering sites with multiple systems coexisting. Furthermore, the differences in user program execution mechanisms, communication protocols, and data organization methods among different controllers further increase the design complexity of the simulation platform.

[0004] Therefore, the industry urgently needs a SIS simulation control platform that is compatible with multiple controllers, supports protocol parsing and service scheduling decoupling, and has unified user program simulation capabilities, in order to reduce development and maintenance costs, improve the flexibility and efficiency of simulation verification, and shorten the project deployment cycle. Summary of the Invention

[0005] The problem solved by this invention is one or more of the aforementioned related technical problems.

[0006] To address the above problems, this invention provides an SIS simulation control platform and an SIS simulation control method.

[0007] In a first aspect, the present invention provides a SIS simulation control platform, including... The system includes a communication adapter module, a protocol driver module, a core business processing module, and at least two controller business modules. The communication adapter module is used to receive raw UDP network data packets sent by the host computer software; The protocol driver module is used to parse the original UDP network data packet according to a predetermined controller communication protocol to obtain application layer data containing system identifier and control commands, and to receive the controller communication protocol response data returned by the core business processing module and send it to the communication adaptation module. The core business processing module is used to call the corresponding controller business module according to the system identifier, and send the control command to the called controller business module; and receive the raw business processing data returned by the controller business module, and encapsulate the raw business processing data into the controller communication protocol response data; Each of the controller business modules corresponds to a type of real controller, which is used to receive the control commands sent by the core business processing module, execute specific business logic related to the real controller to generate the original business processing data, wherein the specific business logic includes user program logic calculation, which is executed based on the three-address code intermediate code generated after the user program is compiled.

[0008] Optionally, when parsing the original UDP network data packet, the protocol driver module is specifically used to extract the system identifier from the application layer header or extended parameters of the controller communication protocol; the system identifier is used to uniquely distinguish at least two different types of real controllers corresponding to the controller service modules.

[0009] Optionally, the communication adaptation module uses a message queue for asynchronous data packet sending and receiving.

[0010] Optionally, the SIS simulation control platform further includes a user interface module, which provides an operating interface for simulation control.

[0011] Optionally, the SIS simulation control platform further includes a simulation command processing process for receiving simulation control commands from an external server or the user interface module. The simulation control commands include simulation controller initialization, step-by-step operation, pause operation, configuration saving, or configuration loading.

[0012] Optionally, each of the controller service modules includes: Simulation real-time data memory is used to store variable data calculated and updated by the user program; The instruction set configuration file is used to define the mapping relationship between the operators and parameter types of the three-address code and the simulation function addresses of the corresponding real controller instruction set; The three-address code interpreter is used to call the corresponding simulation function to execute the user program logic to obtain the calculation result based on the three-address code intermediate code and the instruction set configuration file, and update the calculation result to the simulation real-time data memory.

[0013] Optionally, the SIS simulation control platform further includes: The data refresh thread is used to run periodically according to a preset cycle, and to trigger the three-address code interpreter in the controller business module to execute the user program logic calculation, and refresh the obtained calculation result to the simulation real-time data memory.

[0014] Optionally, the controller communication protocol includes the UCP protocol.

[0015] Secondly, the present invention provides an SIS simulation control method applied to the aforementioned SIS simulation control platform, the SIS simulation control method comprising: Receive user datagram protocol data packets sent by the host computer software, and parse the user datagram protocol data packets to obtain controller communication protocol application layer data containing system identifiers and control commands; The corresponding controller service module is invoked according to the system identifier, and the control command is sent to the invoked controller service module; The specific business logic corresponding to the control command is executed to generate original business processing data. When the business logic involves the execution of a user program, the three-address code intermediate code of the user program is interpreted and executed by a three-address code interpreter. The original business processing data is encapsulated into a User Datagram Protocol (UDP) response packet, and the UDP response packet is sent back to the host computer software.

[0016] Optionally, the SIS simulation control method further includes: An independent data refresh thread is started, and the controller business module is periodically triggered to perform user program logic calculations according to the configured period, and the calculation results are updated to the simulation real-time data memory.

[0017] The beneficial effects of the SIS simulation control platform and SIS simulation control method of the present invention are: Significant technical and economic benefits were achieved by constructing a unified simulation platform with a clear hierarchy and modular design. First, it uses a protocol-driven module to parse system identifiers from network data packets and implements intelligent routing via a core business processing module. This allows a single platform to dynamically call different controller business modules, thus achieving compatibility and simulation for various real controller models (such as the TCS-900 and TCS-500 systems). This design fundamentally solves the problems of "one simulation per machine" and system fragmentation in traditional solutions, greatly improving the reusability of simulation code and architecture, and avoiding the cost of repeatedly developing independent simulation systems for each type of controller. Second, each controller business module adopts a computation method based on three-address code intermediate code to execute user program logic, decoupling high-level programming languages ​​(such as FBD and ST) from the underlying controller-specific instruction set. This instruction set-independent simulation core allows the platform to flexibly adapt to the operational logic of different controllers through configuration, enhancing the platform's scalability and maintainability. When supporting new controllers, the main task is to develop the corresponding business modules rather than reconstructing the entire platform. Ultimately, these technical features work together to enable the development of host computer software, logic verification, and engineering debugging to be carried out entirely in a virtual environment, freeing us from dependence on physical controllers. This not only saves on expensive hardware procurement and debugging costs, but also allows development and implementation personnel to work in parallel, significantly shortening project development cycles and on-site commissioning time, and reducing the complexity and cost of operation and maintenance throughout the entire lifecycle. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the structure of a SIS simulation control platform according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the architecture of a SIS simulation control platform according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating a SIS simulation control method according to an embodiment of the present invention. Detailed Implementation

[0019] 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. Although some embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present invention. It should be understood that the accompanying drawings and embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0020] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0021] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to"; the term "based on" means "at least partially based on"; the term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments"; and the term "optionally" means "optional embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first," "second," etc., mentioned in this invention are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0022] It should be noted that the one or more modifications mentioned in this invention are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise expressly indicated in the context, they should be understood as one or more.

[0023] The names of the messages or information exchanged between the multiple devices in the embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0024] like Figure 1 As shown in the figure, an embodiment of the present invention provides a SIS simulation control platform, including a communication adaptation module, a protocol driver module, a core service processing module, and at least two controller service modules; The communication adapter module is used to receive raw UDP network data packets sent by the host computer software.

[0025] Specifically, in the SIS simulation control platform, the communication adapter module is the underlying module responsible for network communication, and its core function is to simulate the physical network interface of the real controller. The specific process is as follows: Initialization and Listening: When this module starts, it initializes a virtual network environment. For example, on the Windows platform, a virtual network interface card (NIC) can be created and bound using WinPcap or a similar library. A UDP socket can then be created on this NIC and bound to the simulation controller's default IP address and port number (e.g., 192.168.1.100:50000). This port is used to listen for all communication data sent from the host computer's configuration or monitoring software.

[0026] Receiving raw data packets: The host computer software (such as the configuration software SafeContrix) sends UDP data packets to the IP address and port of the simulated controller according to the physical and network layer formats of the real controller communication. The socket of the communication adapter module continuously listens, and once it detects that data has arrived, it immediately receives the entire raw UDP network data packet (including the UDP header, IP header, and the application layer data payload) and reads it into the memory buffer.

[0027] The received raw data packets are not parsed for business logic within this module. The core responsibility of this module is to act as a reliable "data transporter." It directly and transparently passes the received raw byte stream data packets to the upper-layer module—the protocol driver module—through a predefined internal interface (such as function calls or memory sharing) for further protocol parsing.

[0028] This module is architecturally connected to the operating system's network stack (via a virtual network card) at the bottom and directly to the protocol driver module at the top.

[0029] In some embodiments, this module corresponds to EthernetEmulator.dll. It is a standalone dynamic link library that encapsulates all operations related to the underlying network transmission and reception. Its interface design allows upper-layer modules (protocol driver modules) to obtain raw, unprocessed network data packets from it, just as if reading data from a real network card.

[0030] The communication adaptation module constructs a stable and transparent virtual network channel at the operating system level, enabling the entire simulation platform to completely simulate the network access behavior of a real controller without requiring any physical hardware network cards or controllers. This not only completely eliminates the hard dependency of upper-level software development, testing, and early logic verification on specific physical controllers, significantly reducing hardware procurement and debugging costs, but also provides a foundation for deploying and running multiple simulation controller instances in parallel on multiple hosts or virtual machines, thus supporting complex multi-system joint simulation testing scenarios. Furthermore, the module's transparent forwarding of raw data packets ensures that upper-layer business processing logic can focus on core protocol parsing and business simulation without needing to concern itself with complex network communication details, improving the clarity, maintainability, and operational reliability of the entire simulation platform architecture.

[0031] The protocol driver module is used to parse the original UDP network data packet according to a predetermined controller communication protocol to obtain application layer data containing system identifier and control commands, and to receive the controller communication protocol response data returned by the core business processing module and send it to the communication adapter module.

[0032] Specifically, in the SIS simulation control platform, the protocol driver module plays the core role of "protocol translator" and "communication hub," and its processing revolves around data format conversion and routing.

[0033] Downlink Processing (Request Parsing): After receiving the raw UDP network data packets from the communication adaptation module, the primary task of this module is to perform application layer protocol parsing. It strips the UDP / IP header and decodes the data payload according to predefined, proprietary controller communication protocols (such as UCP). The parsing process extracts key application layer information, mainly including: Control commands: such as specific operation instructions and parameters for "reading variables", "starting the controller", and "downloading configuration".

[0034] System Identifier: This is a key field embedded in the protocol frame (such as a specific address field or extension header) to uniquely identify the controller series to which the command target belongs (for example, identifying whether this command is sent to a “TCS-900 series” or a “TCS-500 series” emulation controller).

[0035] After parsing, the original network byte stream is transformed into a semantically clear application layer data object (containing system identifiers and control commands), which is then passed to the core business processing module for subsequent business distribution.

[0036] Uplink processing (response encapsulation): When the core business processing module completes its business logic and returns controller communication protocol response data (i.e., the business result encapsulated according to the protocol format, such as a response frame containing return data or operation status codes), the protocol driver module is responsible for delivering it back to the network. This process is relatively straightforward: the module takes the received protocol response data as the payload, adds the correct UDP header (specifying the source / destination port and IP address), assembles it into a UDP response packet (controller communication protocol response data) conforming to the network transmission format, and finally sends this packet back to the communication adapter module, which then sends it out through the virtual network card.

[0037] This module occupies a central position in the architecture. It connects directly downwards to the communication adaptation module, receiving raw network packets and returning network response packets; it also connects directly upwards to the core business processing module, submitting parsed application layer instructions and receiving protocol responses.

[0038] In some embodiments, this module corresponds to SimuControllerUCPDriver.dll. This dynamic link library is specifically responsible for encoding and decoding the UCP protocol and is a key bridge for enabling interconnection between the simulation controller and the host computer software (which communicates using the UCP protocol).

[0039] The protocol-driven module decouples network communication from application services, bringing core architectural advantages: it encapsulates complex and specialized industrial communication protocol (such as UCP) parsing logic in an independent module, freeing upper-layer business processing modules from concern themselves with specific network packet formats. More importantly, by actively parsing and extracting system identifiers, this module establishes a unified and intelligent request routing foundation for the entire platform, enabling different series of controller commands to be accurately identified and directed to the corresponding business processing units. This not only greatly improves the platform's compatibility and scalability with different controller protocols (adding a new controller protocol mainly involves expanding the parsing capabilities of this module), but also significantly reduces the complexity and maintenance costs of core business logic, ensuring a clear architecture and stable operation of the simulation platform when supporting multiple systems.

[0040] The core business processing module is used to call the corresponding controller business module according to the system identifier, and send the control command to the called controller business module; and receive the raw business processing data returned by the controller business module, and encapsulate the raw business processing data into the controller communication protocol response data.

[0041] Specifically, in the SIS simulation control platform, the core business processing module assumes the dual responsibilities of "business scheduling center" and "response assembler", and its processing realizes the routing and unified response of multi-system business.

[0042] Service Scheduling (Downlink Routing): After receiving the parsed application layer data (containing system identifiers and control commands) from the protocol driver module, this module's core task is service distribution. It doesn't directly handle specific services; instead, it acts as a scheduler, dynamically searching for and calling a specific matching module among the multiple controller service modules loaded on the platform, based on the key information of the system identifier. For example, if the system identifier points to TCS-900, it calls the module named SIMUSCU9010.dll; if it points to TCS-500, it might call SIMUSCU5010.dll. After determining the target module, it passes control commands (such as "execute user logic calculation" or "read data from a certain memory area") to that module.

[0043] Response Assembly (Uplink Encapsulation): After the called controller business module executes specific business logic (such as running a three-address code program or accessing the simulation real-time database), it generates raw business processing data (e.g., an integer value of a temperature variable "150", or a "successful operation" status boolean value). The core business processing module receives this raw data and encapsulates it according to the controller communication protocol (such as the UCP protocol) specification followed by this request. This includes adding information such as the response header, status code, and length specified by the protocol, assembling it into a complete controller communication protocol response data that can be correctly parsed by the host computer, and finally returning this standardized response data packet to the protocol driver module.

[0044] This module is the hub of the platform's business layer. It connects downwards (or horizontally) to one or more controller business modules (DLL dynamic libraries), responsible for loading, managing, and calling them; and connects upwards to protocol driver modules, receiving instructions and returning protocol responses.

[0045] In some embodiments, this module corresponds to SimuControllerKernel.dll. This module implements a unified service scheduling interface and manages the lifecycle and calling logic of different controller service modules.

[0046] The introduction of the core business processing module achieves a strategic separation between business scheduling and specific business implementation, forming the core pillar of the platform's scalability. Through a unified scheduling layer, it automatically routes all business requests based on clear system identifiers. This allows support for a new controller type without modifying the platform's core scheduling framework; only the corresponding business module needs to be developed and registered, thus greatly improving the platform's scalability and maintainability. Simultaneously, it encapsulates heterogeneous, raw business results into standard protocol responses, providing a stable and consistent interface to the upper layers. This not only simplifies the processing logic of protocol-driven modules but also ensures the standardization and reliability of the entire platform's external communication, significantly reducing the complexity of system integration and subsequent upgrades.

[0047] Each of the controller business modules corresponds to a type of real controller, which is used to receive the control commands sent by the core business processing module, execute specific business logic related to the real controller to generate the original business processing data, wherein the specific business logic includes user program logic calculation, which is executed based on the three-address code intermediate code generated after the user program is compiled.

[0048] Specifically, in the SIS simulation control platform, each controller business module is a "controller behavior simulator," which encapsulates the core operating logic of a specific model of real controller (such as TCS-900). The process begins with receiving instructions and ends with producing data.

[0049] Command Reception and Logic Execution: Upon receiving explicit control commands from the core business processing module, this module immediately initiates the corresponding business logic. This logic highly simulates the internal behavior of a real controller and mainly includes: Basic business processing: such as management operations on the controller, including starting / stopping, changing passwords, and clearing configuration.

[0050] Core computing tasks, such as user program logic calculations: This is the most complex and crucial part. When commands involve executing user-configured logic (such as an interlocking control loop), the module does not directly execute the original FBD or ST language program, but instead executes the three-address intermediate code generated after these programs have been uniformly compiled.

[0051] For example, suppose the user program calculates "A+B". The compiled three-address code might be: T1 = READ(A); T2 = READ(B); T3 = ADD(T1, T2; WRITE(C, T3). The execution engine inside the module will interpret these three-address codes line by line: first, it reads the values ​​of operands A and B from the simulated I / O or memory area, then calls a simulated addition function to perform the calculation, and finally writes the result to the simulated memory address of the target variable C. All calculations are performed in a software simulation manner, simulating the operation behavior of a real CPU.

[0052] Generate raw business processing data: The result of executing the above business logic is the raw business processing data. Its format is determined by the received command. For "read" type commands: the raw data is the current value of the variable (such as an integer, floating-point number, or boolean value) extracted from the simulation memory after the user's logical calculation is executed.

[0053] For "control" or "write" type commands: the raw data is usually an operation status confirmation (such as "success" or "failure" indication with an error code).

[0054] This module is located at the end of the execution phase in the architecture. It is only unidirectionally coupled upwards to the core business processing module, being called by it and returning data. The business modules of each controller are independent of each other and have no direct interaction.

[0055] In some embodiments, this module specifically corresponds to SIMUSCU9010.dll. This dynamic link library fully simulates the operations of the SCU9010 / 9020 model controller and is a "digital twin" instance of the TCS-900 series in the simulation platform. Similarly, a module supporting the TCS-500 series may be named SIMUSCU5010.dll.

[0056] The core design of the three-address intermediate code achieves instruction set-independent simulation effects. The principle behind this is to establish a universal intermediate layer that compiles user programs written in different high-level programming languages ​​(FBD, LD, ST) into a unified three-address intermediate code with a fixed format and clear semantics. This code does not contain any specific controller hardware instructions; it only describes "what to do" (operational logic) without specifying "how to do it" (which machine instruction executes it). For example, an addition operation in the three-address code is simply represented as T1 = A + B; it doesn't care which controller's ALU performs the addition.

[0057] To achieve decoupling, the platform provides an instruction set configuration file (such as an XML file) for each supported controller. This file establishes a mapping from generic operators with three-address codes to simulation functions specific to the target controller.

[0058] For example, when A + B in a user program is compiled into the three-address code ADD, A, B, T1: For the TCS-900 controller, its configuration file specifies that the ADD operator is mapped to the Simu_ADD_TCS900() simulation function.

[0059] For the TCS-500 controller, its configuration file specifies that the same ADD operator is mapped to another function, Simu_ADD_TCS500().

[0060] These two simulation functions accurately simulate the micro-operations, timing, and boundary behaviors of real TCS-900 and TCS-500 CPUs when performing addition, but their external interfaces (the way they are called by the three-address code interpreter) are unified.

[0061] Runtime execution: Interpreter + mapping table dynamic invocation: The core of the simulation platform contains a three-address code interpreter. Its workflow when executing user programs is as follows: Read a three-address code instruction (such as ADD, A, B, T1).

[0062] Consult the instruction set configuration file loaded by the current controller business module to find the target simulation function address corresponding to ADD (e.g., Simu_ADD_TCS900).

[0063] Retrieve the values ​​of operands A and B from the simulated real-time memory.

[0064] The found simulation function Simu_ADD_TCS900(A, B) is called to perform the calculation.

[0065] Write the calculation result returned by the function back to location T1 in the simulation's real-time memory.

[0066] Through the above process, the platform core (interpreter) is completely separated from the instruction implementation (simulation functions) of the specific controller. When supporting a new controller, engineers do not need to modify the platform interpreter or recompile the entire system.

[0067] Only two things need to be done: 1. Write a simulation function library for the new controller (simulating all its instructions). 2. Write an instruction set configuration file that defines the mapping from three-address code operators to these new simulation functions. The new business module (including the function library and configuration file) can then be dynamically loaded into the platform and will take effect immediately.

[0068] Three-address codes serve as the unique and stable interface standard, while instruction set configuration files provide flexible and replaceable mapping rules. The combination of these two makes the simulation core act like a universal "translator": it consistently understands the three-address code as its "Esperanto," while how it specifically "speaks" it into the "dialect" of a particular controller (executes the corresponding machine instructions for simulation) is entirely determined by the pluggable configuration files. This is the core technical means to achieve "instruction set independence" and "high scalability."

[0069] The independent design of the controller business modules achieves isolation and high reusability of business logic, forming the cornerstone of the platform's "unified architecture and multi-type compatibility." It encapsulates differentiated operational logic closely related to specific controller hardware (such as instruction sets, memory layout, and runtime sequences) within independent, pluggable modules, ensuring the stability and universality of the simulation platform's core framework. This design greatly improves code maintainability and scalability: maintaining or upgrading the simulation logic of a particular controller model only requires modifying or replacing the corresponding business module, without affecting the overall platform or other controller simulation functions; supporting new controllers only requires developing a new business module according to the specifications and registering it. Ultimately, this modular strategy significantly reduces the development complexity, testing risks, and long-term maintenance costs of multi-system simulation platforms, enabling users to efficiently and flexibly perform preliminary verification and debugging of various types of real controller programs within a unified software environment.

[0070] In this embodiment, the SIS simulation control platform achieves significant technical and economic benefits by constructing a unified simulation platform with a clear hierarchy and modular design. First, it parses the system identifier in network data packets through a protocol-driven module and implements intelligent routing via a core business processing module. This allows a single platform to dynamically call different controller business modules, thereby achieving compatibility and simulation for various real controller models (such as TCS-900 and TCS-500 systems). This design fundamentally solves the problem of "one simulation per machine" and system fragmentation in traditional solutions, greatly improving the reusability of simulation code and architecture, and avoiding the cost of repeatedly developing independent simulation systems for each type of controller. Second, each controller business module adopts a computation method based on three-address code intermediate code to execute user program logic, decoupling high-level programming languages ​​(such as FBD and ST) from the underlying controller-specific instruction set. This instruction set-independent simulation core allows the platform to flexibly adapt to the operational logic of different controllers through configuration, enhancing the platform's scalability and maintainability. When supporting new controllers, the main task is to develop the corresponding business modules rather than reconstructing the entire platform. Ultimately, these technical features work together to enable the development of host computer software, logic verification, and engineering debugging to be carried out entirely in a virtual environment, freeing us from dependence on physical controllers. This not only saves on expensive hardware procurement and debugging costs, but also allows development and implementation personnel to work in parallel, significantly shortening project development cycles and on-site commissioning time, and reducing the complexity and cost of operation and maintenance throughout the entire lifecycle.

[0071] Optionally, when parsing the original UDP network data packet, the protocol driver module is specifically used to extract the system identifier from the application layer header or extended parameters of the controller communication protocol; the system identifier is used to uniquely distinguish at least two different types of real controllers corresponding to the controller service modules.

[0072] Specifically, during the operation of the SIS simulation control platform, the system identifier extraction performed by the protocol-driven module is the first step in critical routing decisions. The process is essentially a deep message parsing performed according to proprietary communication protocol specifications.

[0073] After obtaining the raw UDP packet from the communication adapter module, this module first strips the UDP / IP header, exposing the application layer message that conforms to a specific controller communication protocol (such as the UCP protocol). Subsequently, it strictly follows the format specifications of this protocol to parse the application layer message field by field.

[0074] Location identifier field: The system identifier is not stored arbitrarily, but is explicitly defined in a specific location within the protocol frame structure. This is typically implemented in two ways: Located in the fixed message header: In the message header predefined by the protocol, one or more bytes are specifically assigned the meaning of "device type", "serial number" or "system ID".

[0075] Located in variable extended parameters: In the extended parameter area (variable length field) for specific complex commands (such as pipeline management commands), parameters used to identify the target system are carried.

[0076] For example, the module parses a command frame from the UCP3.0 protocol. It identifies the frame as a "pipe write command," then parses its extended parameter list, finding a parameter named "System_ID" with a value of "9010." This "9010" is extracted as the system identifier, indicating that this command intends to operate on the SCU9010 controller simulation module of the TCS-900 series. If the value is "5010," it corresponds to the TCS-500 series.

[0077] The extracted system identifier is a crucial routing key. It is passed to the core business logic processing module along with the parsed control commands. The core business logic processing module uses this identifier to precisely select and call the module corresponding to "9010" or "5010" from among numerous controller business modules, thereby ensuring that the business logic executes in the correct simulation environment.

[0078] This process is entirely completed within the protocol driver module. This module takes a raw UDP network byte stream as input and outputs a structured application-layer data object containing system identifiers, control commands, and parameters. It provides upstream (the core business processing module) with clearly translated instructions appended with context (system identifiers).

[0079] In some embodiments, a complete decoder for the UCP protocol is implemented within SimuControllerUCPDriver.dll (the protocol driver module), which includes logic for locating and reading the system identifier from fixed or variable fields of various UCP command frames (such as pipe commands, read / write commands).

[0080] The design of the protocol-driven module, which accurately extracts system identifiers from proprietary communication protocols, is the core technological guarantee for achieving unified platform intelligent routing and seamless compatibility across multiple systems. It abstracts and condenses the physical and logical differences between different controller series into a simple identifier that can be transmitted in network packets. This mechanism allows the host computer software to communicate according to a predetermined protocol without needing to know what kind of simulation controller is behind it; the simulation platform, however, can automatically and accurately distribute commands to the corresponding business modules for execution based on this identifier. This fundamentally solves the architectural challenge of "unified entry point and business separation" in multi-controller simulation systems. It not only avoids the repetitive work of developing independent communication front-ends for each controller but also gives the platform extremely strong flexibility: when supporting new controller series in the future, the main work involves developing their business modules and registering new identifier mappings in the protocol-driven module, without changing the overall communication scheduling framework of the platform. This greatly improves the system's scalability and maintainability and significantly reduces the technical complexity and cost of long-term evolution.

[0081] Optionally, the communication adaptation module uses a message queue for asynchronous data packet sending and receiving.

[0082] Specifically, in the SIS simulation control platform, the communication adaptation module uses a message queue mechanism to handle the sending and receiving of network data packets, which is a classic asynchronous and decoupled design. Its core lies in separating the "production" (network reception / service generation) and "consumption" (protocol parsing / network transmission) of data, and coordinating them through a first-in-first-out (FIFO) buffer.

[0083] The specific processing procedure is as follows: Receive path (UDP packet inbound): When the virtual network card detects a UDP packet sent from the host computer, the receiving thread of the communication adapter module immediately stores it as a complete "message" (i.e., raw byte stream) in the receive message queue. This operation is extremely fast; the receiving thread then returns and continues listening to the network without waiting for the packet to be processed by subsequent modules.

[0084] A separate consumer thread (or one actively pulled by the protocol-driven module) continuously monitors the receive queue. Once a new message is in the queue, it is retrieved and passed to the protocol-driven module for further parsing via an interface call.

[0085] Sending path (outbound UDP response packet): When the protocol driver module needs to send a response to the host computer, it does not directly call the network sending function. Instead, it stores the pre-packaged UDP response packet as a "message" in the sending message queue. The sending thread of the communication adapter module continuously monitors the sending queue. Once it detects a message to be sent, it retrieves it and sends it to the network through the virtual network card's socket.

[0086] In some embodiments, the EthernetEmulator.dll module encapsulates such a message queue mechanism. Its interface functions with the upper layer (protocol driver module) are essentially "enqueue" and "dequeue" operations on the queue, rather than direct, synchronous network I / O calls.

[0087] The use of message queues for asynchronous sending and receiving brings crucial performance robustness and architectural decoupling advantages to the simulation platform. First, it effectively smooths out traffic spikes and troughs, instantly buffering large influxes of data packets during peak network traffic periods, preventing data loss due to momentary delays in business processing and ensuring communication reliability. Second, it achieves complete decoupling between the sending / receiving process and the business processing process: the network receiving thread can capture data at high speed and without interruption, unaffected by the processing speed of downstream businesses; similarly, the speed at which the business side generates responses is not blocked by occasional network latency. This asynchronous pipelined working mode significantly improves the overall system throughput, responsiveness, and resource utilization. More importantly, it provides the system with excellent scalability and maintainability: future adjustments to queue length and optimization of the number of consumer threads can handle more complex loads, and changes to the network communication layer have minimal impact on the business logic layer, thus greatly enhancing the stability and scalability of the entire simulation platform when dealing with high-concurrency, high-real-time industrial simulation scenarios.

[0088] like Figure 1 As shown, optionally, the SIS simulation control platform further includes a user interface module, which provides an operation interface for simulation control.

[0089] Specifically, the user interface module is a standalone graphical application (such as SISCon.exe) that provides engineers with a visual control console. Through this interface, users can: Status monitoring: Visually view the operating status of the simulation controller (such as running / stopping), CPU load, real-time values ​​of key variables, etc.

[0090] Manual control: By using graphical controls such as buttons and menus, you can directly issue basic operation commands to the simulation platform, such as "start simulation", "stop simulation", and "step through" the user program for debugging.

[0091] Configuration management: Selecting simulation tasks, loading existing configuration files, and setting simulation run parameters, etc.

[0092] This module typically serves as the front-end entry point for the simulation platform. Architecturally, it is not directly coupled to the core business modules. Instead, it indirectly drives the background simulation engine by translating user intents into standard simulation control commands through the simulation command processing process or a predefined inter-process communication (IPC) interface. It is primarily geared towards end users (engineers).

[0093] The introduction of the user interface module provides an intuitive and user-friendly human-computer interaction entry point for complex technical platforms. It abstracts the complex underlying simulation engine operations into simple graphical, menu-driven operations, greatly reducing the platform's usage threshold and learning cost. This allows engineering configuration personnel without extensive programming backgrounds to easily perform simulation testing and logic debugging. Simultaneously, a unified interface facilitates centralized management and monitoring of the operating status of multiple simulation controllers, improving the efficiency of engineering implementation and the standardization of operations.

[0094] Optionally, the SIS simulation control platform further includes a simulation command processing process for receiving simulation control commands from an external server or the user interface module. The simulation control commands include simulation controller initialization, step-by-step operation, pause operation, configuration saving, or configuration loading.

[0095] Specifically, the simulation command processing process (such as TCSSimuControl.exe) is a persistent background console program or service process that acts as the high-level command scheduler of the simulation platform. Its core workflow is as follows: Command reception: The process continuously listens for commands from two main channels: From the user interface module: Receiving operations triggered by the user through the graphical interface. From external servers: For example, receiving batch or automated test commands issued by an integrated development environment or automated testing framework server (such as ContrixPlusServer) via command line, network socket, or RPC.

[0096] Command parsing and forwarding: After receiving the original command (such as "Simulation initialization: system=TCS900, configuration file=plant1.cfg", "Execute 100 simulation steps"), the process parses and verifies it, and converts it into standardized calling instructions that can be recognized by the core business processing module inside the simulation platform.

[0097] Execution and Control: It is responsible for coordinating the complete execution of these high-level commands. For example, for the "Configuration Load" command, it will sequentially trigger the core module to load the specified file and initialize the memory and state of the corresponding controller business module. For the "Step" command, it will precisely control the simulation engine to execute one cycle of user logic calculation and then pause it, allowing the user to observe the intermediate state.

[0098] This process resides in the coordination layer of the architecture. It interfaces upwards with the user interface and external automation systems, and interacts closely with core business processing modules (such as SimuControllerKernel.dll) downwards, driving them to complete complex simulation control sequences. Essentially, it is an enhanced encapsulation and automation orchestrator of the basic capabilities (start and stop) of core business modules.

[0099] The design of the simulation command processing process standardizes the control interface and expands its automation capabilities. First, it provides a stable and unified command access point for the user interface and external systems, shielding them from the complexity of internal module calls. More importantly, it enables fine-grained and automated control of the simulation process (such as precise stepping, breakpoints, and sequential execution), essential for in-depth logic debugging and automated testing. This allows the simulation platform to be used not only for manual verification but also seamlessly integrated into continuous integration / testing (CI / CT) pipelines, enabling automated regression testing of configuration logic. This significantly improves software quality and the automation level of project delivery, while shortening the testing cycle.

[0100] Optionally, each of the controller service modules includes: Simulation real-time data memory is used to store variable data calculated and updated by the user program; The instruction set configuration file is used to define the mapping relationship between the operators and parameter types of the three-address code and the simulation function addresses of the corresponding real controller instruction set; The three-address code interpreter is used to call the corresponding simulation function to execute the user program logic to obtain the calculation result based on the three-address code intermediate code and the instruction set configuration file, and update the calculation result to the simulation real-time data memory.

[0101] Specifically, the three core components within each controller's business module and their collaborative workflow constitute the "micro-execution engine" for achieving accurate simulation.

[0102] Simulated real-time data memory: This is a structured area in memory used to store data (such as I / O image area, intermediate variable area, holding registers, etc.) that mirrors the real controller. All inputs, outputs, and intermediate variables of user program operations are mapped to specific addresses here.

[0103] It serves as both the endpoint and origin of data flow. The operands (such as the values ​​of A and B) required for computation by the three-address code interpreter are read from here; the result of the computation (such as the result of C = A + B) is immediately written back to the corresponding address here. Any real-time data read by the host computer ultimately originates from this memory.

[0104] Instruction set configuration file: It is a static database of mapping rules, existing in text (such as XML) or binary format. It bridges the gap between platform-independent three-address codes and controller-specific simulation functions.

[0105] Its working process is as follows: The file defines the correspondence between each three-address code operator (such as ADD, MOV, AND) and its parameter type (such as INT32, FLOAT, BOOL), and a specific simulation function entry address. For example, the configuration might specify that (operator = ADD, parameter type 1 = INT32, parameter type 2 = INT32) maps to the function pointer Simu_ADD_Int32(). This function internally precisely simulates the behavior of a real controller CPU performing 32-bit integer addition.

[0106] Three-address code interpreter: It is the core of the module's CPU emulation. Its task is to interpret and execute the three-address code sequence generated by compiling the user program.

[0107] Its working process is as follows: The interpreter reads a three-address code instruction (such as t3 = ADD(t1, t2)). Based on the operator (ADD) and operand type (assuming it is INT32) of the instruction, it queries the instruction set configuration file to find the address of the corresponding simulation function Simu_ADD_Int32.

[0108] The current values ​​of operands t1 and t2 are read from the real-time simulation data memory, and a function such as Simu_ADD_Int32(t1_value, t2_value) is called. This simulation function performs the software-simulated addition operation and returns the calculation result.

[0109] The interpreter writes this calculation result to the address corresponding to variable t3 in the simulation real-time data memory.

[0110] The instruction set configuration file is the "translation manual," the three-address code interpreter is the "translator and executor," and the simulated real-time data memory is the "common notepad." Following the manual's instructions, the interpreter continuously reads data from the notepad, performs calculations, and writes the results back to the notepad.

[0111] Optionally, the SIS simulation control platform further includes: The data refresh thread is used to run periodically according to a preset cycle, and to trigger the three-address code interpreter in the controller business module to execute the user program logic calculation, and refresh the obtained calculation result to the simulation real-time data memory.

[0112] Specifically, the SIS simulation control platform introduces a data refresh thread, which is an active, periodic driving mechanism that simulates the scanning cycle of a real controller.

[0113] Its specific working process: Thread Startup and Timing: After the simulation controller starts, the platform creates an independent data refresh thread. This thread is woken up periodically at a preset, configurable interval (e.g., 50ms, simulating the scan cycle of the real controller).

[0114] Triggering logic calculation: After each wake-up, this thread does not directly process data, but instead acts as a "commander," sending a synchronization trigger signal to the controller's business module. This signal commands the three-address code interpreter within the module to begin operation.

[0115] Execution and Update: Upon receiving the trigger signal, the three-address code interpreter immediately starts, completely interpreting and executing all the three-address codes corresponding to the currently loaded user program. As mentioned above, this process completes all logic and operations by calling a series of simulation functions, and finally refreshes (writes) all outputs and intermediate variable calculation results in batches to the simulation real-time data memory.

[0116] Repeated cycle: After completing one refresh, the data refresh thread enters sleep mode, waiting for the next cycle to arrive, and then repeats steps 2-3, thus forming a continuous and periodic simulation operation.

[0117] This thread ensures that even without read / write requests from the host computer, the user program logic can run autonomously and continuously at a fixed rhythm, just like in a real controller, keeping the data in the simulation memory dynamically updated.

[0118] By combining real-time data memory, instruction set configuration files, a three-address code interpreter, and a data refresh thread, the simulation core achieves instruction set abstraction and periodic autonomous execution, resulting in high realism and flexibility in the simulation. The architecture of the simulation's real-time data memory, instruction set configuration files, and three-address code interpreter completely decouples the user program from the specific controller hardware instruction set. This allows the same set of intermediate user program code to execute on controller business modules with different architectures by loading different configuration files, greatly improving the versatility and portability of the simulation core and reducing the cost of developing entirely new emulators for each new CPU.

[0119] Building upon this foundation, the introduction of a data refresh thread perfectly simulates the "scan-execute-update" periodic operating mode of a real PLC / controller. It ensures the autonomous, continuous, and rhythmic evolution of the internal state of the simulation environment, rather than passively calculating only in response to requests from the host computer. This allows simulation testing to more realistically reflect the program's runtime sequence, cumulative state effects, and periodic behavior in real hardware, which is crucial for discovering hidden logic errors related to time or scan cycles (such as edge triggering, counter, and timer behavior). It enables offline simulation not only to verify the correctness of the logic but also the realism of its dynamic behavior, thereby significantly shifting timing-related issues that would otherwise only be exposed on the field controller to the development stage, significantly improving debugging quality and reducing field risks.

[0120] Optionally, the controller communication protocol includes the UCP protocol.

[0121] Among them, UCP protocol: a communication protocol that can be used between the controller and the host computer software. UDP (User Datagram Protocol): a connectionless transport layer user datagram protocol.

[0122] In some embodiments, such as Figure 2 The diagram shown illustrates the architecture of the SIS simulation control platform (SISCon.exe), illustrating its core modules and dependencies. This is a typical, hierarchical Windows desktop application architecture diagram, reflecting a highly modular design philosophy. The following provides a detailed explanation of each component: I. Main Program and Core Business Layer: SISCon.exe: This is the platform's executable main program, i.e., the application that the user directly launches.

[0123] Based on the MFC framework, it provides a graphical user interface (UI), which serves as the entry point for users to interact with the simulation platform (such as starting / stopping simulation, loading configurations, and monitoring variables).

[0124] SimuControllerKernel.dll: This is the core business processing and scheduling module of the simulation platform, and it is the "brain" of the system.

[0125] SISCon.exe drives the entire simulation process by calling the interfaces provided by this dynamic link library. It is responsible for calling specific controller business modules based on system identifiers and managing the flow of simulation commands.

[0126] SimuControllerUCPDriver.dll: This is the protocol driver module, which acts as a "translator" between the core business layer and the network layer.

[0127] It is specifically responsible for encoding and decoding the UCP protocol, parsing raw data packets from the network into business instructions, or encapsulating business results into network response packets.

[0128] II. Network Communication and Low-Level Adaptation Layer: EthernetEmulator.dll: This is the communication adaptation module, responsible for simulating the physical network interface of the real controller. Implemented based on the WinPcap library, it is responsible for initializing the virtual network card, creating UDP sockets, and asynchronously sending and receiving raw network data packets. It is the cornerstone of network communication between the platform and the host computer software.

[0129] packet.lib & wpcap.lib: These two are the development libraries (static link libraries) of the well-known open-source network packet capture library WinPcap.

[0130] EthernetEmulator.dll needs to link these two libraries during compilation to call the low-level network packet capture and injection API provided by WinPcap, thereby achieving fine-grained control over network flow.

[0131] III. Specific Controller Business Implementation Layer: SIMUSCU9010.dll: This is the specific business processing module for the SCU9010 / 9020 model controller in the TCS-900 system.

[0132] It includes all the business simulation implementations specific to this controller model, such as the configuration structure, memory layout, and user program (three-address code) interpretation and execution logic. This is the key to the platform's ability to simulate a specific controller.

[0133] TCS900CfgInfoAcs.dll: This is the configuration information access module for the TCS-900 system.

[0134] It is likely responsible for accessing and parsing the TCS-900 controller's unique configuration files, hardware configuration information, etc., to provide SIMUSCU9010.dll with the correct initialization parameters and runtime environment data.

[0135] ipphpapi.lib: This is a helper static library (possibly "IP Helper API" or other proprietary helper library).

[0136] It may provide auxiliary functions related to network configuration, IP address management, or inter-process communication to support the operation of EthernetEmulator.dll or other modules.

[0137] IV. Architecture Summary and Features: The diagram vividly illustrates the layered, decoupled, and plug-in architecture of the described technical solution: The layers are clearly defined: from top to bottom, they are UI layer (exe) - core scheduling and protocol layer (dll) - network communication layer (dll+lib) - specific business implementation layer (dll).

[0138] High cohesion and low coupling: Each dynamic link library (DLL) has a single responsibility and interacts through clearly defined interfaces. For example, to support a new controller (such as TCS-500), theoretically only new SIMUSCU5010.dll and TCS500CfgInfoAcs.dll need to be developed and registered in the core module, without modifying other layers.

[0139] like Figure 3 As shown, this embodiment of the invention provides an SIS simulation control method applied to the SIS simulation control platform. The SIS simulation control method includes: Receive user datagram protocol data packets sent by the host computer software, and parse the user datagram protocol data packets to obtain controller communication protocol application layer data containing system identifiers and control commands; The corresponding controller service module is invoked according to the system identifier, and the control command is sent to the invoked controller service module; The specific business logic corresponding to the control command is executed to generate original business processing data. When the business logic involves the execution of a user program, the three-address code intermediate code of the user program is interpreted and executed by a three-address code interpreter. The original business processing data is encapsulated into a User Datagram Protocol (UDP) response packet, and the UDP response packet is sent back to the host computer software.

[0140] Optionally, the SIS simulation control method further includes: An independent data refresh thread is started, and the controller business module is periodically triggered to perform user program logic calculations according to the configured period, and the calculation results are updated to the simulation real-time data memory.

[0141] While the present invention has been disclosed above, its scope of protection is not limited thereto. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention, and all such changes and modifications will fall within the scope of protection of the present invention.

Claims

1. A SIS simulation control platform, characterized in that, It includes a communication adaptation module, a protocol driver module, a core business processing module, and at least two controller business modules; The communication adapter module is used to receive raw UDP network data packets sent by the host computer software; The protocol driver module is used to parse the original UDP network data packet according to a predetermined controller communication protocol to obtain application layer data containing system identifier and control commands, and to receive the controller communication protocol response data returned by the core business processing module and send it to the communication adaptation module. The core business processing module is used to call the corresponding controller business module according to the system identifier, and send the control command to the called controller business module; and receive the raw business processing data returned by the controller business module, and encapsulate the raw business processing data into the controller communication protocol response data; Each of the controller business modules corresponds to a type of real controller, which is used to receive the control commands sent by the core business processing module, execute specific business logic related to the real controller to generate the original business processing data, wherein the specific business logic includes user program logic calculation, which is executed based on the three-address code intermediate code generated after the user program is compiled.

2. The SIS simulation control platform according to claim 1, characterized in that, When the protocol driver module parses the original UDP network data packet, it is specifically used to extract the system identifier from the application layer message header or extended parameters of the controller communication protocol; the system identifier is used to uniquely distinguish at least two different types of real controllers corresponding to the controller service modules.

3. The SIS simulation control platform according to claim 1, characterized in that, The communication adaptation module uses a message queue for asynchronous data packet sending and receiving.

4. The SIS simulation control platform according to claim 1, characterized in that, The SIS simulation control platform also includes a user interface module, which provides an operating interface for simulation control.

5. The SIS simulation control platform according to claim 4, characterized in that, The SIS simulation control platform also includes a simulation command processing process for receiving simulation control commands from an external server or the user interface module. The simulation control commands include simulation controller initialization, step-by-step operation, pause operation, configuration saving, or configuration loading.

6. The SIS simulation control platform according to claim 1, characterized in that, Each of the controller service modules includes: Simulation real-time data memory is used to store variable data calculated and updated by the user program; The instruction set configuration file is used to define the mapping relationship between the operators and parameter types of the three-address code and the simulation function addresses of the corresponding real controller instruction set; The three-address code interpreter is used to call the corresponding simulation function to execute the user program logic to obtain the calculation result based on the three-address code intermediate code and the instruction set configuration file, and update the calculation result to the simulation real-time data memory.

7. The SIS simulation control platform according to claim 5, characterized in that, The SIS simulation control platform also includes: The data refresh thread is used to run periodically according to a preset cycle, and to trigger the three-address code interpreter in the controller business module to execute the user program logic calculation, and refresh the obtained calculation result to the simulation real-time data memory.

8. The SIS simulation control platform according to claim 1, characterized in that, The controller communication protocol includes the UCP protocol.

9. A SIS simulation control method, characterized in that, The SIS simulation control method, applied to the SIS simulation control platform as described in any one of claims 1 to 9, comprises: Receive user datagram protocol data packets sent by the host computer software, and parse the user datagram protocol data packets to obtain controller communication protocol application layer data containing system identifiers and control commands; The corresponding controller service module is invoked according to the system identifier, and the control command is sent to the invoked controller service module; The specific business logic corresponding to the control command is executed to generate original business processing data. When the business logic involves the execution of a user program, the three-address code intermediate code of the user program is interpreted and executed by a three-address code interpreter. The original business processing data is encapsulated into a User Datagram Protocol (UDP) response packet, and the UDP response packet is sent back to the host computer software.

10. The SIS simulation control method according to claim 9, characterized in that, The SIS simulation control method also includes: An independent data refresh thread is started, and the controller business module is periodically triggered to perform user program logic calculations according to the configured period, and the calculation results are updated to the simulation real-time data memory.

Images