Virtual plc dynamic simulation system and method for radiotherapy device host computer debugging

Abstract

This invention belongs to the field of medical device technology, and specifically relates to a virtual PLC dynamic simulation system and method for debugging the host computer of radiotherapy equipment. The system of this invention can autonomously implement a standard protocol stack, allowing seamless switching on the host computer without code modification. The system constructs a virtual data block (DB), I / O area, and flag bit area in memory, supporting high-concurrency read and write operations. This invention introduces a time-driven dynamic simulation rule engine layer, allowing users to define evolution logic such as kinematic trajectories, dose accumulation, heartbeat signals, and random noise through configuration files. The engine automatically updates memory address values ​​at fixed intervals, realistically simulating physical processes such as treatment bed movement, gantry rotation, and radiation beam emission. This invention eliminates the dependence on real PLC hardware and the TIA Portal environment, providing a lightweight, configurable virtual debugging environment with dynamic feedback capabilities for radiotherapy host computer software, significantly reducing development costs and improving verification efficiency.

Description

Technical Field

[0001] This invention belongs to the field of medical device technology, and specifically relates to a virtual PLC dynamic simulation system and method for debugging the host computer of radiotherapy equipment. Background Technology

[0002] In the development and debugging of control systems for radiotherapy medical devices (such as medical linear accelerators), the coordinated operation between the host computer treatment control software (a computer program responsible for the user interface, treatment process management, and safety monitoring) and the slave computer programmable logic controller (PLC, an industrial computer specifically designed to control the movement of mechanical equipment) is the core element for the safe and precise operation of the entire system. Taking the commonly used Siemens series PLCs in the industry as an example, equipment manufacturers typically employ two technical solutions when developing and testing the host computer software: The first method involves directly using the actual PLC hardware of a radiotherapy device. This requires connecting a physical S7-1200, S7-1500, or S7-300 / 400 controller to a computer network. The host computer software then issues commands via the standard S7 communication protocol (the network communication language used by Siemens PLCs) to read or write data to the PLC's internal data storage areas (e.g., "data blocks" (DB) storing information such as treatment bed position, gantry angle, and dose rate; input image area I storing input signals; output image area Q storing output commands; and bit storage area M storing intermediate states). This completes the functional verification.

[0003] The second method involves using Siemens' official S7-PLCSIM simulation software for simulation when there is no real hardware available.

[0004] The existing technology has the following key drawbacks: Using real hardware for debugging is extremely expensive, as the overall hardware control system of radiotherapy equipment (such as linear accelerators) is very costly. Building a complete hardware debugging environment not only occupies space but also involves safety risks such as high voltage and radiation. When multiple software engineers need to perform joint debugging at the same time, it is impossible to equip each of them with a real device, resulting in a severe shortage of development resources.

[0005] If virtual PLC debugging is used, the virtual PLC software suffers from severe environmental dependencies and system isolation. Although S7-PLCSIM can replace hardware operation logic under certain conditions, it heavily relies on the Siemens TIA Portal (Total Integrated Automation Platform) software environment, can only run on Windows systems, and cannot be deployed on Linux servers or cloud virtualization environments. For radiotherapy software development scenarios that require multi-team collaboration in different locations or the construction of automated testing platforms, this limitation is unacceptable. In addition, the software is large and resource-intensive, and in the S7-PLCSIM environment, the data itself does not have the ability to evolve actively according to physical laws. If developers want to simulate dynamic processes such as treatment bed movement and dose accumulation, they must write complex simulation logic in the PLC program or manually modify variable values ​​on the host computer. This not only leads to the mixing of simulation logic and real control program, increasing the risk of errors, but also requires host computer developers to be proficient in PLC programming, resulting in excessively high skill thresholds and learning costs. Summary of the Invention

[0006] To address the aforementioned problems in the existing technology, the present invention aims to provide a virtual PLC dynamic simulation system and method for debugging the host computer of radiotherapy equipment, which can completely replace the real PLC hardware of radiotherapy equipment, and provide virtual PLC services with dynamic physical simulation capabilities to the host computer treatment control software of radiotherapy equipment through a dynamic simulation rule engine.

[0007] The technical solution adopted in this invention is as follows: In a first aspect, this application provides a virtual PLC dynamic simulation system for debugging the host computer of radiotherapy equipment, comprising: The network communication layer is used to establish a communication connection with the host computer, receive request messages sent by the host computer, and / or send response messages back to the host computer. The protocol encoding / decoding layer is used to parse the request message and extract the request instruction; and / or to encapsulate the processing result into a response message; The memory data mapping layer is used to open a byte buffer in the system memory or data carrier to simulate the storage area of ​​the PLC. The storage area includes a data block DB, an input image area I, an output image area Q, and a flag bit area M. The memory data mapping layer performs data read or write operations on the byte buffer according to the request instruction. The dynamic simulation rule engine layer is used to drive the corresponding data in the byte buffer to perform time-varying calculations based on the evolution logic of at least one radiotherapy equipment PLC, using an independent timed scheduling thread.

[0008] This system simulates a PLC data server conforming to standard industrial Ethernet protocols such as S7, Modbus TCP, EtherNet / IP, Profinet, and ADS using pure software. The host computer-based treatment control software requires no code modification and can establish communication with the system via network, just like connecting to a real PLC, to read and write data blocks (DB) and I / O areas. This completely eliminates dependence on expensive radiotherapy equipment hardware, avoids the impact of hardware failures on debugging progress, and supports multiple developers simultaneously connecting to the same virtual PLC for collaborative debugging.

[0009] More importantly, this application also integrates a dynamic simulation rule engine driven by an independent timed scheduling thread into the system. This engine allows users to predefine mathematical models (such as kinematic models, radiation beam and dose accumulation simulation models, random noise models, etc.) describing the physical movement and dose changes of the radiotherapy equipment PLC. Then, according to the set timing rules, it drives the data in the byte buffer to automatically perform time-varying calculations and updates. In this way, the virtual PLC can realistically simulate complex dynamic scenarios such as the smooth movement of the treatment bed, the rotation of the gantry at a preset speed, and the continuous accumulation of dose values ​​when the radiation source emits a beam. It provides the host computer software with a lightweight, efficient, flexibly configurable virtual testing platform that can autonomously generate dynamic data. In addition to eliminating the dependence on real PLC hardware, it also solves the problems caused by the staticization of simulation data.

[0010] As a preferred embodiment of this application, the network communication layer is based on the Netty framework multiplexer to construct a multi-threaded master-slave thread pool model. When one or more host computers initiate a request, the network communication layer concurrently receives the request message in an asynchronous non-blocking manner and delivers the request message to the event-driven pipeline, fundamentally isolating the impact of network I / O blocking on the core business of the system.

[0011] As a preferred embodiment of this application, the protocol encoding / decoding layer has a built-in binary encoding / decoding chain; when the request message is received, the decoder performs layer-by-layer stripping according to the hierarchical structure of the S7 protocol: first, it parses the TPKT layer, then the COTP layer, and finally the S7 PDU application layer; when encapsulating the response message, the encoder encapsulates the processing result layer by layer according to the hierarchical structure of the S7 protocol: first, it encapsulates the S7 PDU application layer, then the COTP layer, and finally the TPKT layer.

[0012] The protocol encoding and decoding layer independently implements a complete S7 communication server protocol stack, which can accurately identify and respond to various requests initiated by the host computer. Its communication logic is highly consistent with the real physical PLC, ensuring that the host computer software can achieve a smooth switch from the physical PLC to this virtual PLC without modifying any code.

[0013] As a preferred embodiment of this application, the configuration of the data block DB is implemented through a configuration file, which contains the number, name and byte length information of the data block DB; when the system starts, it reads the configuration file and allocates a byte buffer of the corresponding size in the system memory or data carrier according to the configuration content.

[0014] As a preferred embodiment of this application, the at least one radiotherapy device PLC evolution logic includes kinematic trajectory simulation rules; the kinematic trajectory simulation rules are configured as follows: With a preset time period Δ t For periodic operation, in each cycle, the target position value is read from the byte buffer. P target Current location feedback value P previous and speed value V Applying kinematic formulas to calculate instantaneous position values P current : P current =P previous +sign ( P target -P previous ) ×min ( |P target -P previous |，V× Δ t ); Real-time location value P current Write current position feedback value P previous The memory address; in, sign For symbolic functions: when P target > P previous When, return 1; when P target < P previous When the time comes, return -1; P target = P previous If the value is 0, it returns 0.

[0015] As a preferred embodiment of this application, the at least one radiotherapy device PLC evolution logic includes logic interlocks and signal association rules, which are configured as follows: When the status of the monitored root node address changes and meets the set conditions, the rule engine automatically forces the writing of the specified value to one or more leaf node addresses.

[0016] As a preferred embodiment of this application, the at least one radiotherapy device PLC evolution logic includes a radiation beam and dose accumulation simulation rule, which is configured as follows: The rules engine uses a preset time period Δ t The system operates in a cyclic manner; when the beam trigger signal changes from 0 to 1, the engine initiates the dose accumulation process; within each cycle, the engine first reads the pulse frequency setpoint. F And combined with the period duration Δ t Calculate the theoretical increase in the number of pulses within this period. F ×Δ t The engine adds the new amount to the pulse count counter address. Then, the engine multiplies the updated pulse count counter value by the preset single pulse dose to obtain the current real-time cumulative dose and writes the cumulative dose feedback address. When the cumulative dose reaches or exceeds the prescription dose, the engine automatically resets the beam trigger signal to 0 and writes 1 to the beam completion status address, and the pulse count counter stops counting.

[0017] As a preferred embodiment of this application, the at least one radiotherapy device PLC evolution logic includes industrial-grade heartbeat and watchdog simulation rules, which are configured as follows: An integer memory address is allocated, and an accumulation period is configured. Every certain accumulation period, the engine automatically updates the value in the integer memory address according to a predetermined pattern to simulate the PLC of the radiotherapy equipment actively sending a heartbeat signal.

[0018] As a preferred embodiment of this application, the at least one radiotherapy device PLC evolution logic includes a physical environment random noise rule, which is configured as follows: Configure the reference address, maximum amplitude, and noise distribution type; the reference address stores the fluctuation center value of the physical quantity. The engine periodically generates random noise based on the maximum amplitude and superimposes it onto the fluctuation center value, according to the noise distribution type. The periodically updated physical quantities are written to the output address of the corresponding physical quantities.

[0019] In a second aspect, this application also provides a virtual PLC dynamic simulation method for debugging the host computer of radiotherapy equipment. This method uses the aforementioned virtual PLC dynamic simulation system for debugging the host computer of radiotherapy equipment, and includes the following steps: Startup and Loading: Read the configuration file and create a byte buffer in the system memory or data carrier to simulate the PLC according to the configuration file. The storage area includes at least a data block DB, an input image area I, an output image area Q, and a flag bit area M. At the same time, load at least one radiotherapy equipment PLC evolution logic from the configuration file and associate the at least one radiotherapy equipment PLC evolution logic with the corresponding byte buffer address. Start listening to the network communication layer port. Communication handshake: When the host computer initiates a connection request, a handshake process is performed with the host computer through the network communication layer to establish a communication connection; Concurrent service loop: After the communication connection is established, the network communication layer listens for request messages from the host computer; the protocol encoding and decoding layer parses the request messages and extracts the request instructions; the memory data mapping layer performs data read or write operations on the byte buffer according to the request instructions; simultaneously, the dynamic simulation rule engine layer uses an independent timed scheduling thread to drive the data in the corresponding byte buffer address to perform time-varying calculations according to at least one configured radiotherapy equipment PLC evolution logic, so as to simulate the dynamic changes of physical quantities of the radiotherapy equipment PLC; Terminate operation: When a stop command is detected, release the resources occupied by the system.

[0020] As a preferred embodiment of this application, during the concurrent service loop phase, after the data write operation on the byte buffer is completed, the radiotherapy device PLC evolution logic associated with the address of the written byte buffer is triggered.

[0021] The beneficial effects of this invention are as follows: 1. This application possesses realistic dynamic feedback capabilities: Completely different from the static simulation data experience of traditional simulations, this system integrates a dynamic simulation rule engine. This engine can simulate the smooth movement of the treatment bed, the gradual change in gantry angle, the real-time dose accumulation process during beam emission, and the irregular jitter of signals—all aspects of the PLC evolution logic of radiotherapy equipment. For the host computer software, its interaction with this application's system is comparable to connecting to a real PLC. This allows developers to effectively verify the motion control algorithms, timeout monitoring logic, and various anomaly handling processes of the host computer software, thereby elevating the software quality to a level suitable for safe deployment in medical equipment even in the laboratory stage.

[0022] 2. This application is completely hardware-independent: It accurately simulates the communication protocol function, data block DB management function and interlocking logic execution function of the hardware PLC through complete PLC virtual services, and can provide complete data exchange and dynamic simulation services for the host computer treatment control software without relying on any physical radiotherapy equipment control hardware.

[0023] 3. This application achieves cross-platform lightweight deployment: the packaged system is extremely small (usually less than 100MB), and it can run on multiple operating systems such as Windows, Linux, and macOS based on common languages ​​such as Java. Compared with the PLCSIM solution, which has an installation package of tens of GB and must rely on the Windows system, it has greater versatility and significant convenience advantages.

[0024] 4. This application has high concurrency communication capabilities: the multi-threaded model implemented through the Netty framework can support the concurrent connections of hundreds of host computer clients with extremely low system resource consumption, ensuring response latency within milliseconds and supporting multi-team collaborative debugging. Attached Figure Description

[0025] Figure 1 This is the system architecture diagram of this application; Figure 2 This is a flowchart of the host computer reading data from the PLC; Figure 3 This is the main operating flowchart of the system; Figure 4 This is a flowchart of the Netty TCP asynchronous communication service; Figure 5 This is a flowchart of the rule simulation service. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0027] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the invention can be combined with each other.

[0028] To address the high costs associated with testing with real PLC hardware in existing technologies, and the high environmental requirements and static simulation data issues associated with testing with virtual PLC software, this application provides a high-performance virtual PLC dynamic simulation system for debugging radiotherapy equipment. This system is developed using general-purpose languages ​​such as Java (Java is used as an example in this embodiment, but in practical applications, other computer languages ​​such as C++ can be used) and can run on multiple operating systems. It completely replaces the real PLC hardware of radiotherapy equipment, significantly reducing debugging costs and improving development efficiency for radiotherapy control software development teams.

[0029] This system simulates a PLC data server conforming to standard S7 and other industrial Ethernet protocols (such as Modbus TCP, EtherNet / IP, Profinet, ADS, etc.) using pure software. The host computer-based treatment control software requires no code modification and can establish communication with the system via the network, just like connecting to a real PLC, performing read and write operations on the simulated data blocks (DB) and I / O areas. This completely eliminates dependence on expensive radiotherapy equipment hardware, avoids the impact of hardware failures on the debugging progress, and supports multiple developers simultaneously connecting to the same virtual PLC for collaborative debugging. The ability to achieve concurrent multi-client connections is due to the system's network communication layer employing the Netty framework, allocating an independent channel handle and thread context to each host computer client connection.

[0030] More importantly, this solution integrates a time-driven dynamic simulation rule engine into the system. This engine allows users to predefine mathematical models (e.g., kinematic models, dose rise models, random noise models, etc.) describing the physical motion of the radiotherapy equipment PLC and changes in dose, indicating the dynamic evolution process and related calculations of the corresponding rules. Then, at set time intervals, the data (i.e., physical quantities) in the memory address associated with the engine is automatically updated according to the corresponding rules / logic. In this way, the virtual PLC can realistically simulate dynamic on-site feedback scenarios of complex physical quantities such as smooth movement of the treatment bed, rotation of the gantry at a preset speed, and continuous accumulation of dose values ​​when the radiation source emits its beam. This provides upper-level software developers with a lightweight, efficient, flexibly configurable virtual testing platform capable of autonomously generating dynamic data, fundamentally solving the problem of static simulation data in existing simulation technologies.

[0031] like Figure 1 As shown, the virtual PLC dynamic simulation system for debugging the host computer of radiotherapy equipment in this application includes: (1) Network communication layer.

[0032] The network communication layer is used to establish a communication connection with the host computer, receive request messages sent by the host computer, and / or send response messages back to the host computer.

[0033] Taking support for the S7 communication protocol as an example, the network communication layer establishes a communication connection with the host computer based on the TCP / IP protocol and receives request messages that conform to the S7 communication protocol sent by the connected host computer.

[0034] It should be noted that the S7 communication protocol is used as an example here only for the convenience of introducing the solution of this application. In practical applications, other industrial Ethernet protocols can also be supported (such as the example above).

[0035] As an optional implementation, the network communication layer is based on the Netty framework's multiplexer to build a multi-threaded master-slave thread pool model. When one or more host computers initiate a request, the network communication layer concurrently receives the request message in an asynchronous non-blocking (NIO) manner and delivers the request message to the event-driven pipeline.

[0036] (2) Protocol encoding and decoding layer.

[0037] The protocol encoding / decoding layer is used to parse request messages and extract request instructions; and / or to encapsulate processing results into response messages. Request messages are encapsulated messages issued by the host computer containing specific operation instructions (such as read / write operations); processing results are feedback messages generated by the simulated PLC after executing operation instructions and when feedback to the host computer is required.

[0038] Taking the S7 communication protocol support in the network communication layer as an example, the protocol encoding / decoding layer is used to parse the received request message using the S7 protocol, extracting the operation type, target storage area, starting address, and data length. Alternatively, when feedback is required, it is used to encapsulate the processing result into a response message according to the S7 protocol format.

[0039] In one specific implementation, the protocol codec layer incorporates a binary codec chain. Upon receiving a request message, the decoder peels back the request message layer by layer according to the S7 protocol's hierarchical structure: first, it parses the TPKT layer, then the COTP layer, and finally the S7 PDU application layer. When encapsulating the response message, the encoder encapsulates the processing result layer by layer according to the S7 protocol's hierarchical structure: first, it encapsulates the S7 PDU application layer, then the COTP layer, and finally the TPKT layer, thus encapsulating the processing result into a standard S7 response message.

[0040] (3) Memory data mapping layer.

[0041] The memory data mapping layer is used to allocate byte buffers in system memory or data carriers to simulate the storage area of ​​a PLC. This storage area includes a data block DB, an input image area I, an output image area Q, and a flag bit area M. Among them, the data block DB stores one or more key parameters such as the X / Y / Z coordinates of the treatment bed, the gantry rotation angle, the position of the multi-leaf grating blades, the dose rate setpoint, and the cumulative dose value.

[0042] The allocation of storage areas such as the data block DB, input image area I, output image area Q, and flag area M is to simulate the storage system of a real radiotherapy equipment PLC. The construction methods of each storage area are similar; this explanation uses the allocation of the data block DB as an example.

[0043] The configuration of data blocks (DBs) is implemented through configuration files (such as XML files), which contain the DB number, name, and byte length information. At system startup, the configuration file is read, and a byte buffer of the corresponding size is allocated in system memory or a data carrier (such as JVM heap memory) according to the configuration. Each data block (DB) corresponds to a byte array in computer memory. For other storage areas, namely I, Q, and M storage areas, memory space is also allocated from system memory or a data carrier according to the configuration file.

[0044] For example, when you need to allocate a data block DB with the number 500 and a length of 1024 bytes, the corresponding configuration XML file is as follows: <?xml version="1.0" encoding="UTF-8"?> <virtualplc> <!-- Data block definition: number is the DB number, size is the byte length --> <datablocks> <db number="200" size="1024" / > <db number="502" size="1024" / > < / datablocks> <!-- Length of the digital input area (in bytes) --> <inputs size="2048" / > <!-- Length of the digital output area (in bytes) --> <outputs size="512" / > <!-- Length of the flag bit area (in bytes) --> <memoryflags size="512" / > < / virtualplc> .

[0045] like Figure 2 As shown, within a Java program, each data block (DB) corresponds to a byte array in the computer's memory. Thanks to Java's excellent memory management capabilities, the system can support simultaneous access to multiple data blocks (DB).

[0046] The memory data mapping layer performs data read or write operations on the byte buffer according to request instructions. The memory data mapping layer supports simultaneous access to multiple data blocks. When memory operation is required, the "area type-data block number-start byte address-bit offset (corresponding byte length)" in the Industrial Ethernet protocol is seamlessly converted into an absolute index of the byte array, thereby achieving microsecond-level read / write response speeds.

[0047] For example, the memory data mapping layer locates the specific memory address to be operated on from different storage areas of the byte buffer based on the target storage area, starting address and data length parsed by the protocol encoding and decoding layer, and then performs data read or write operations on the corresponding address in the byte buffer according to the operation type.

[0048] Read operation: When the system recognizes that the request command sent by the host computer is a read request (determined by the operation type), it will extract the target storage area to be accessed, the DB number, and the starting byte address from the request command; then, by calculating the memory offset, it will extract a segment of data of the required length from the corresponding byte array, package it into a response message according to the specified format, and return it to the host computer.

[0049] Write operation: When processing a write request (also determined by the operation type of the request instruction), the system extracts the write data sent by the host computer, locates the memory address using the same method, and directly overwrites the contents of the corresponding byte array in memory according to the specified offset. After the write is completed, the system immediately triggers the "radiotherapy equipment PLC evolution logic" associated with that memory address to ensure that subsequent dynamic changes caused by the write can be responded to in a timely manner.

[0050] (4) Dynamic simulation rule engine layer.

[0051] As an important component of the system in this application, the dynamic simulation rule engine layer is responsible for driving the corresponding data in the byte buffer to perform time-varying calculations based on the evolution logic of at least one radiotherapy device PLC.

[0052] It is worth noting that the dynamic simulation rule engine layer uses independent timed scheduling threads to drive data updates. These independent timed scheduling threads mean that the dynamic simulation rule engine layer configures independently running clock units, such as microsecond-level clock units, and activates / triggers at least one configured radiotherapy equipment PLC evolution logic at regular intervals according to a fixed clock frequency (e.g., a 50ms time step). Each execution thread corresponds to one radiotherapy equipment PLC evolution logic. Each radiotherapy equipment PLC evolution logic is associated with the memory address to be updated in a byte buffer. The dynamic simulation rule engine layer maintains a rule execution task queue, corresponding to each radiotherapy equipment PLC evolution logic. Based on the configured clock frequency, it periodically polls various radiotherapy equipment PLC evolution logics, periodically extracting the associated physical quantity parameters as input variables from the byte buffer allocated by the memory data mapping layer, and inputting them into the corresponding radiotherapy equipment PLC evolution logic (e.g., radiation beam and dose accumulation simulation rules, each rule abstracted as a mathematical model) for time-varying calculations. The calculated data is written back to the corresponding memory address in real time, thus giving the system proactive behavior capabilities.

[0053] For example, the dynamic simulation rule engine layer is designed based on ScheduledThreadPoolExecutor and the underlying OS's time interrupt service. Its clock unit is independent of the network communication thread (i.e., other layers of the system), and maintains an independent system master clock axis. When the timer within the clock unit reaches a preset time step (e.g., 50ms, configurable), it immediately sends a hardware-level computation interrupt signal to the engine. Upon receiving this interrupt signal, the corresponding execution thread forcibly refreshes and calculates the value in the bound memory address. This design, based on a high-frequency, high-availability clock unit, ensures that no matter how busy the host computer's network communication is, the evolution of physical laws and time-driven updates within the virtual PLC can proceed at an extremely stable and precise frequency, thus ensuring the fidelity of industrial-grade simulation.

[0054] In the system designed above, the network communication layer acts as the physical port. Upon receiving the raw network byte stream (such as request messages, handshake messages, etc.) from the external host computer, it forwards it to the protocol encoding / decoding layer for parsing. The protocol encoding / decoding layer parses the byte stream layer by layer according to the configured communication protocol structure (determined by the supported industrial Ethernet protocol), extracting structured request instructions (including read / write target registers and offsets), and then calls the interface provided by the memory data mapping layer. The memory data mapping layer, guided by the request instructions, addresses and locates the corresponding byte array in the JVM heap memory (corresponding to the Java implementation; for other computer languages, the corresponding memory is used), directly extracting (reading) or overwriting (writing). If a write request is encountered, after the data write operation to the byte buffer is completed, the evolution logic of the radiotherapy equipment PLC associated with the written byte buffer address is triggered. That is, while completing the data overwriting, a data change event is sent to the dynamic simulation rule engine layer to wake up the associated radiotherapy equipment PLC evolution logic. When a read request is encountered, the memory data mapping layer returns the data (i.e., the processing result) to the protocol encoding / decoding layer, encapsulates it into a standard protocol format response PDU, completes network byte stream encoding, and finally hands it over to the network communication layer to send back to the corresponding host computer. At the technical architecture level, this system leverages the cross-platform capabilities of the Java language, enabling seamless operation on Linux servers and Windows workstations. The network communication layer constructs a multi-threaded master-slave thread pool model based on the high-performance Netty asynchronous non-blocking framework, concurrently responding to host computer connection requests through the thread pool model. When one or more host computers initiate a request, the network communication layer concurrently receives request messages in an asynchronous non-blocking manner and delivers the request messages to the event-driven pipeline. The protocol encoding / decoding layer autonomously implements a complete S7 communication server protocol stack (the S7 protocol consists of TPKT + COTP + application layer protocols), accurately identifying and responding to various requests initiated by the host computer. Its communication logic maintains a high degree of consistency with the real physical PLC, ensuring that the host computer software can achieve a smooth switch from the physical PLC to this virtual PLC without modifying any code.

[0055] This application simulates the storage area of ​​a PLC by allocating an independent byte buffer in memory, achieving extremely high data throughput and extremely low access latency.

[0056] The dynamic rule engine layer is independent of other layers and is maintained by an independent clock unit. It activates and runs according to a preset time frequency. Based on the configured PLC evolution logic of the radiotherapy equipment, an independent thread reads physical quantity data from the associated memory address, updates it according to the PLC evolution logic, and then writes it back to that memory address. Combined with the dynamic rule engine designed in this application, the system can automatically update data at specified memory addresses according to a preset time frequency. This design transforms the virtual PLC from a passive, static data storage device into an intelligent simulation entity with active feedback capabilities. For example, by configuring the motion rules of the treatment bed, the system can automatically simulate the physical process of the treatment bed's position coordinates continuously changing with time and velocity, allowing the host computer software to observe a smooth and realistic motion trajectory during debugging, greatly improving the simulation realism and reliability of debugging in the virtual environment.

[0057] The dynamic rule engine layer can be configured with one or more radiotherapy equipment PLC evolution logics. Each radiotherapy equipment PLC evolution logic corresponds to a physical and automation logic evolution law of the radiotherapy equipment PLC.

[0058] As an optional implementation method, such as Figure 5 As shown, the evolution logic of the PLC for radiotherapy equipment includes one or more of the following types of rules.

[0059] (1) Kinematic trajectory simulation rules.

[0060] The kinematic trajectory simulation rules are specifically designed for simulating motion control systems (such as three-dimensional motion beds, treatment heads, and gantry frames).

[0061] The system defines the target location address (Target), velocity address (Velocity), and current location address (Previous) for this rule.

[0062] The operational logic after the kinematic trajectory simulation rules are activated includes: With a preset time period Δ t The process runs in cycles (e.g., 50ms or other configured values), and in each cycle, the target position value is read from the byte buffer. P target Current location feedback value P previous and speed value V Applying kinematic formulas to calculate instantaneous position values P current : P current =P previous +sign ( Ptarget -P previous ) ×min ( |P target -P previous |，V× Δ t ); Real-time location value P current Write current position feedback value P previous The memory address; in, sign The min function is a symbolic function used to return the minimum value in a given parameter list.

[0063] when P target > P previous When the value inside the function is positive, return 1; when... P target < P previous When the value inside the function is negative, return -1; P target = P previous When the value inside the function is 0, return 0.

[0064] By configuring the location update rules as described above, we can ensure that the feedback value can smoothly approach the target value.

[0065] By configuring the kinematic trajectory simulation rules, after the host computer issues a position command, it can be observed that the data at the feedback address increases or decreases smoothly at the physical real speed, rather than jumping instantaneously, thus realizing the dynamic closed-loop simulation of the motion control system.

[0066] In one specific embodiment, the configuration file for the kinematic trajectory simulation rules is as follows: <rule type="KinematicTrajectory" name="TreatmentBed_X_Axis" intervalms="50"> <target address="DB200.0" dataType="Real" description="目标位置" / > <velocity address="DB200.4" dataType="Real" description="运动速度(mm / s)" / > <previous address="DB200.8" dataType="Real" description="当前位置反馈" / > < / rule> .

[0067] (2) Industrial-grade heartbeat and watchdog simulation rules.

[0068] Industrial-grade heartbeat and watchdog simulation rules are used to verify the vital signs monitoring logic between the host computer and the slave computer (commonly known as the "heartbeat" or "watchdog" mechanism). In radiotherapy equipment, this is often used to determine whether the control link is interrupted to ensure patient safety.

[0069] An integer memory address was specified for the industrial-grade heartbeat and watchdog simulation rule, and an accumulation period (e.g., 1000 milliseconds) was configured. The execution logic of the industrial-grade heartbeat and watchdog simulation rule after activation includes: Every certain accumulation cycle, the engine automatically updates the value in the integer memory address according to a predetermined pattern, such as increasing the value by 1, to simulate the PLC of the radiotherapy equipment actively sending a heartbeat signal, indicating a normal life state.

[0070] The host computer can simulate a PLC crash or communication interruption by manually pausing the engine's operation, thus allowing for convenient observation of whether the host computer's treatment control software can promptly pop up alarms, automatically pause treatment, or execute a safety reset, ensuring the accuracy of the safety logic.

[0071] In one specific embodiment, the configuration file for the industrial-grade heartbeat and watchdog simulation rules is as follows: <rule type="HeartbeatWatchdog" name="PlcLifeBeat" intervalms="1000"> <watchdogaddress address="DB200.12" dataType="Int" description="心跳计数器寄存器" / > <stepvalue value="1" description="每次累加步长" / > < / rule> .

[0072] (3) Random noise rules of physical environment.

[0073] The physical environment random noise rule is used to simulate the inherent minute fluctuations in the signals of various detectors in radiotherapy equipment, such as the normal drift of sensor voltage and current readings or temperature sensor acquisition values.

[0074] A baseline address, maximum amplitude, and noise distribution type are configured for the random noise rule in the physical environment. The baseline address stores the fluctuation center value of the physical quantity. The operational logic after the random noise rule in the physical environment is activated includes: The engine periodically generates random noise based on the maximum amplitude according to the noise distribution type and superimposes it onto the fluctuation center value; the periodically updated physical quantity is written to the output address of the corresponding physical quantity, thereby simulating the non-stationary characteristics of the real physical quantity caused by electromagnetic interference or physical drift.

[0075] By introducing noise conforming to a specific distribution into static data, the robustness of the host computer software under unstable signals, the effectiveness of the filtering algorithm, and the triggering accuracy of the alarm threshold can be verified, thereby improving the realism of the simulation environment.

[0076] Taking the voltage of the ionization chamber electronics module as the target physical quantity, the fluctuation center value within the reference address is configured as 220V. The user wants to simulate random noise with the fluctuation center value amplitude within ±1%, then the maximum amplitude is 2.2V, and the noise distribution type conforms to a Gaussian distribution, i.e., a random distribution type with a bell-shaped curve. The engine's calculation logic is then as follows: ; in, The fluctuation center value read from the reference value address is 220; This is the center weight of the maximum noise amplitude configured by the user, which corresponds to the value of 2.2 in the example above. This is a random floating-point number generated using Java's built-in Gaussian pseudo-random number generator (based on the Box-Muller transform), conforming to a standard normal distribution (a bell-shaped curve with a mean of 0 and a variance of 1). The output value is obtained by adding the two terms on the right. The calculations are performed at each time frequency point. Finally, the periodically updated voltage of the ionization chamber electronics module is written to the output address of the corresponding physical quantity.

[0077] In one specific embodiment, the configuration file for the physical environment random noise rules is as follows: <rule type="RandomNoise" name="IonChamber_Voltage_Noise" intervalms="100"> <baseaddress address="DB502.20" dataType="Real" description="高压基准设定值" / > <outputaddress address="DB502.24" dataType="Real" description="叠加噪声后的实际反馈值" / > <distribution type="Gaussian" / > <amplitude value="2.2" description="最大噪声振幅" / > < / rule> .

[0078] (4) Logic interlock and signal association rules.

[0079] Logical interlocking and signal association rules are used to simulate spontaneous, strongly correlated logical protection and interlocking behaviors within a hardware system. When the state of a monitored root node address changes and meets set conditions, the engine automatically forces the writing of specified values ​​to one or more leaf node addresses.

[0080] The program continuously reads the current value of the root node address at a fixed configured period and compares it with preset trigger conditions. This comparison process corresponds to the logic of "AND gate" and "conditional switch" in hardware: only when the root node state fully meets the set trigger conditions will subsequent actions be triggered; if the trigger conditions are not met, no operation is performed. The logic and the on / off judgment of the hardware circuit are completely consistent. Once the condition is triggered, the program bypasses other business logic and directly forces the pre-set values ​​to be written to all configured leaf node addresses.

[0081] In real radiotherapy equipment, various sensor signals are interconnected. For example, when the host computer writes an "emergency stop button pressed" signal to the PLC due to a fault or emergency (root node), the PLC's internal hardware circuitry and underlying logic force the radiotherapy equipment to execute a series of chain reactions, including "cutting off the high-voltage control contactor" (child node) and "forcibly revoking the beam output permission signal." This rule perfectly replicates this linkage tree protection logic of "root node state change, multi-leaf node linkage forced response" through pure software configuration, without writing any PLC code.

[0082] Through this rule, the PLC of the simulated radiotherapy equipment can automatically execute complex internal protection logic, and the host computer software can receive safety interlock feedback that conforms to physical logic when issuing unsafe instructions or encountering sudden fault signals.

[0083] In one specific embodiment, the configuration file for the logic interlock and signal association rules is as follows: <rule type="LogicInterlock" name="EmergencyStop_Chain" intervalms="20"> <conditionsource address="DB200.40.0" dataType="Bool" expectValue="1" description="急停按钮被按下" / > <actiontargets> <target address="DB200.40.1" dataType="Bool" forceValue="0" description="强行切断高压接触器反馈" / > <target address="DB502.10.0" dataType="Bool" forceValue="0" description="强行将出束许可信号(Beam Enable)置为0" / > <target address="DB200.50" dataType="Int" forceValue="999" description="向主状态寄存器写入急停故障码999" / > < / actiontargets> < / rule> .

[0084] (5) Simulation rules for emitted beam and dose accumulation.

[0085] Configure the simulation rules for emitted beams and dose accumulation to specify the addresses for storing the "emission trigger signal" (BOOL value), the "pulse number setting value", the "pulse frequency", the "cumulative dose feedback", and the "prescription dose".

[0086] The operational logic after the emission beam and dose accumulation simulation rules are activated includes: The rules engine uses a preset time period Δ t The system operates in a cyclic manner; when the beam trigger signal changes from 0 to 1, the engine initiates the dose accumulation process; within each cycle, the engine first reads the pulse frequency setpoint. F And combined with the period duration Δ t Calculate the theoretical increase in the number of pulses within this period. F ×Δ t The engine adds the new amount to the pulse count counter address. Then, the engine multiplies the updated pulse count counter value by the preset single pulse dose to obtain the current real-time cumulative dose and writes the cumulative dose feedback address. When the cumulative dose reaches or exceeds the prescription dose, the engine automatically resets the beam trigger signal to 0 and writes 1 to the beam completion status address, and the pulse count counter stops counting.

[0087] The simulation rules for radiation beam and dose accumulation realistically reproduce the underlying physical mechanism by which the PLC of the radiotherapy equipment controls the dose output by adjusting the pulse frequency. This allows the core functions of the host computer, such as treatment process control, dose monitoring and display, and treatment record printing, to be fully verified in an environment separate from the actual machine.

[0088] In one specific embodiment, the configuration file for the simulation rules of the emitted beam and dose accumulation is as follows: <rule type="BeamDoseAccumulation" name="Vmat_Dose_Simulation" intervalms="50"> <beamtriggeraddress address="DB502.0.0" dataType="Bool" description="出束触发信号" / > <pulsefrequencyaddress address="DB502.2" dataType="Int" description="当前脉冲频率设定值(Hz)" / > <singlepulsedose value="0.015" description="单个脉冲对应的剂量常数" / > <pulsecounteraddress address="DB502.4" dataType="DInt" description="内存脉冲计数器" / > <accumulateddoseaddress address="DB502.8" dataType="Real" description="实时累积剂量反馈(MU)" / > <prescriptiondoseaddress address="DB502.12" dataType="Real" description="处方总剂量(MU)" / > <beamcompleteaddress address="DB502.0.1" dataType="Bool" description="出束完成状态(1-已完成)" / > < / rule> .

[0089] Based on the ideas of this application, this application embodiment also provides a virtual PLC dynamic simulation method for debugging the host computer of radiotherapy equipment. This method is implemented using the virtual PLC dynamic simulation system for debugging the host computer of radiotherapy equipment described in the above embodiment.

[0090] The virtual PLC dynamic simulation method for debugging the host computer of radiotherapy equipment proposed in this application includes four stages: startup and loading, communication handshake, concurrent service loop, and operation termination. The following is a combination of... Figures 3-5 Each stage will be explained in detail.

[0091] S1: Startup and Loading Phase After the system's main program starts, it first reads the configuration file in XML format.

[0092] Parse the data blocks (DB200, DB502, etc.) to be simulated from the configuration file, along with their respective lengths, the size of the digital input / output area (i.e., input image area I / output image area Q), and the size of the flag bit area (M area).

[0093] Based on the analysis results, a corresponding byte array is allocated in the computer's memory to complete the initialization of all virtual storage areas.

[0094] Simultaneously, all defined radiotherapy equipment PLC evolution logic is read from the configuration file (see...). Figure 5 (Corresponding to the embodiment), and associate each radiotherapy equipment PLC evolution logic with its bound byte buffer address and evolution parameters (cycle, target value, speed address, pulse frequency address, etc.), and put them into a rule execution queue.

[0095] Create a TCP network server based on the Netty framework, start listening on the standard port 102, and prepare to accept connections from the host computer software.

[0096] S2: Communication handshake phase: Once at least one host computer initiates a TCP connection request, the system strictly follows the S7 communication protocol, exchanging a series of handshake messages with the host computer through the network communication layer to establish a communication channel, until both parties establish a logical connection capable of reading and writing data. This step completely mimics the behavior of a real physical PLC.

[0097] S3: Concurrent Service Cycle Phase: During the concurrent service cycle phase, two types of tasks are executed simultaneously: one is the communication service responsible for interacting with the host computer, and the other is the rule simulation service responsible for dynamic evolution.

[0098] (1) Communication service task (asynchronous event-driven): This task is managed by the Netty framework and uses an asynchronous non-blocking method to achieve concurrency. After the communication connection is established, the network communication layer listens for request messages from the host computer; the protocol encoding and decoding layer parses the request messages and extracts the request instructions; and the memory data mapping layer performs data read or write operations on the byte buffer according to the request instructions.

[0099] Whenever the host computer sends a read request (e.g., reading the current position of the treatment bed) or a write request (e.g., writing to a new target location), after the network communication layer receives the byte stream, the corresponding decoder converts the network byte stream into a request object that the program can understand. Then, the executor, based on the region type and address in the request, and according to the operation type, reads data from or writes data to the corresponding memory byte array, and immediately encapsulates the operation result into a response message and returns it to the host computer. The entire process is completed in milliseconds and can handle hundreds of host computer connections simultaneously.

[0100] (2) Rule Simulation Service: This is an independent task triggered by the system timer at fixed time intervals (e.g., 50 milliseconds). Through the dynamic simulation rule engine layer, an independent timed scheduling thread is used to drive the data in the corresponding byte buffer address to perform time-varying calculations based on the evolution logic of at least one radiotherapy equipment PLC configured, so as to simulate the dynamic changes of the physical quantities of the radiotherapy equipment PLC.

[0101] Each time it is triggered, the engine iterates through all the radiotherapy equipment PLC evolution logic in the rule queue, executing the internal calculation logic of each one. For example... Figure 3 In the illustrated embodiment, the calculation logic includes: motion simulation rules, random noise rules, dosage calculation rules, heart rate rules, and logical interlocking rules. After all calculations are completed, the updated data is directly reflected in the corresponding memory address, without requiring any additional operations from the host computer.

[0102] S4: Execution Termination Phase: When a stop command is detected, the system releases the resources it is using.

[0103] When the simulation needs to be stopped, the system shuts down the Netty server, releases all connections, and can optionally save the final memory data state to a local file for restoration on the next startup.

[0104] Through the above steps, the system achieves the transformation from static memory to an active dynamic simulation entity. The host computer software reads data at any time and obtains the latest dynamic values ​​calculated by the engine, conforming to the laws of physical evolution, thus creating a realistic equipment integration environment.

[0105] It should be noted that: Regarding the development language and network model, although the embodiments of this application are implemented using Java and Netty, in specific high-performance edge computing scenarios, the communication layer logic can be rewritten using C++ combined with Boost.Asio, or Golang combined with its efficient Goroutine scheduling model. These languages ​​have their own advantages in low-level memory control and extremely low latency processing, and can serve as migration variants of the solution in this application on different hardware platforms.

[0106] The virtual memory management model presented in this application is universal. Besides the Siemens S7 protocol, server-side virtualization for industrial Ethernet protocols such as Modbus TCP, EtherNet / IP, Profinet, and ADS can be achieved by changing the protocol adaptation layer. This means the system can evolve into a "multi-protocol virtual controller gateway," supporting unified simulation of heterogeneous automation environments.

[0107] The solution described in this application is based on a memory buffer and offers the highest performance. However, at the expense of some performance, an alternative solution could be to introduce an in-memory database such as Redis or a MySQL database as the data carrier, thereby enabling state sharing among multiple virtual PLC instances.

[0108] Compared to the two known testing schemes, this application has the following characteristics and advantages: Technical features: 1. Full-featured application-layer simulation implemented entirely in Java. Completely independent of any native dynamic link libraries in C / C++ or other languages, it independently completes the entire S7 communication message parsing and generation logic from TPKT / COTP to the underlying Protocol Data Unit (PDU) within the Java environment, effectively solving the problem of cross-platform deployment of industrial simulation software.

[0109] 2. Asynchronous non-blocking high-concurrency communication model. The multi-threaded model implemented through the Netty framework can support hundreds of concurrent connection requests from host computer clients with extremely low system resource consumption, while ensuring response latency within milliseconds.

[0110] 3. Time-Driven Automated Simulation Engine for Physical Properties. By abstracting the continuous changes in the physical world of radiotherapy equipment, such as treatment bed movement, gantry rotation, dose accumulation, signal noise, and safety interlocks, into configurable numerical evolution rules, the data in memory can dynamically evolve over time. This allows for the construction of a closed-loop test environment with realistic dynamic feedback without downloading any real control program to the virtual PLC. Users can flexibly configure parameters for various rules, bind arbitrary database addresses, and set trigger conditions as needed. Rule execution employs multi-threaded independent scheduling, ensuring real-time performance and simulation fidelity, fundamentally addressing the shortcomings of existing simulation software.

[0111] 4. PLC virtualization technology addresses the core pain points of high hardware costs and limited resources. Through a complete PLC virtual service module, it accurately simulates the communication protocol functions, DB data block management functions, and interlocking logic execution functions of the hardware PLC. Without relying on any physical radiotherapy equipment control hardware, it provides complete data exchange and dynamic simulation services for the host computer-based treatment control software, truly achieving comprehensive software debugging independent of the actual machine and breaking the constraint of hardware resources on the efficiency of radiotherapy software development.

[0112] advantage: 1. Extremely high development and debugging flexibility: Developers can completely break free from the limitations of physical hardware. During the software development phase, most of the upper-level computer logic debugging work can be completed simply by running this virtual PLC service on their own computer.

[0113] 2. Lightweight and Easy Deployment: The packaged system is very small (usually less than 100MB), and because it is developed based on Java, it can run directly on multiple operating systems such as Windows, Linux, and macOS with a single command. This is a significant advantage compared to the PLCSIM solution, whose installation packages are often tens of gigabytes and which depend on the Windows system.

[0114] 3. Realistic Dynamic Feedback Capability: Unlike the static experience of traditional simulations, this system's rule engine can simulate the smooth movement of the treatment bed, the gradual change in gantry angle, the real-time dose accumulation process during beam emission, and irregular signal jitter. For the host computer software, the series of feedback data received from this system, both in terms of the continuous pattern of numerical changes and noise characteristics, is highly similar to the sensor signals collected when connected to a real accelerometer. This allows developers to effectively verify the motion control algorithms, timeout monitoring logic, and various anomaly handling procedures of the host computer software, thereby elevating the software quality to a level suitable for safe deployment in medical devices even in the laboratory stage.

[0115] This invention is not limited to the above-described optional embodiments. Anyone can derive other various forms of products under the guidance of this invention. However, regardless of any changes made in their shape or structure, any technical solution that falls within the scope of the claims of this invention shall be protected by this invention.

Claims

1. A virtual PLC dynamic simulation system for radiotherapy device host computer debugging, characterized in that, include: The network communication layer is used to establish a communication connection with the host computer, receive request messages sent by the host computer, and / or send response messages back to the host computer. The protocol encoding / decoding layer is used to parse the request message and extract the request instruction; and / or used to encapsulate the processing results into a response message; The memory data mapping layer is used to open a byte buffer in the system memory or data carrier to simulate the storage area of ​​the PLC. The storage area includes a data block DB, an input image area I, an output image area Q, and a flag bit area M. The memory data mapping layer performs data read or write operations on the byte buffer according to the request instruction. The dynamic simulation rule engine layer is used to drive the corresponding data in the byte buffer to perform time-varying calculations based on the evolution logic of at least one radiotherapy equipment PLC, using an independent timed scheduling thread.

2. The virtual PLC dynamic simulation system for on-site machine debugging of a radiotherapy device according to claim 1, characterized in that, The network communication layer is based on the Netty framework's multiplexer and constructs a multi-threaded master-slave thread pool model. When one or more host computers initiate a request, the network communication layer concurrently receives the request message in an asynchronous non-blocking manner and delivers the request message to the event-driven pipeline.

3. The virtual PLC dynamic simulation system for on-site machine debugging of a radiotherapy device according to claim 1, characterized in that, The configuration of the data block DB is implemented through a configuration file, which contains the number, name and byte length information of the data block DB. When the system starts, it reads the configuration file and allocates a byte buffer of the corresponding size in the system memory or data carrier according to the configuration content.

4. The virtual PLC dynamic simulation system for debugging radiotherapy equipment's host computer according to claim 1, characterized in that, The PLC evolution logic of the at least one radiotherapy device includes kinematic trajectory simulation rules; the kinematic trajectory simulation rules are configured as follows: With a preset time period Δ t For periodic operation, in each cycle, the target position value is read from the byte buffer. P target Current location feedback value P previous and speed value V Calculate instantaneous position value using kinematic formulas P current : P current =P previous +sign ( P target -P previous ) ×min ( |P target -P previous |，V× D t ); Real-time location value P current Write current position feedback value P previous The memory address; in, min The function is used to return the minimum value in a given argument list. sign For symbolic functions: when P target > P previous When the time comes, return 1; when P target < P previous When the time comes, return -1; P target = P previous If the value is 0, it returns 0.

5. The virtual PLC dynamic simulation system for debugging radiotherapy equipment's host computer according to claim 1, characterized in that, The PLC evolution logic of the at least one radiotherapy device includes logic interlocks and signal association rules, which are configured as follows: When the status of the monitored root node address changes and meets the set conditions, the rule engine automatically forces the writing of the specified value to one or more leaf node addresses.

6. The virtual PLC dynamic simulation system for debugging radiotherapy equipment's host computer according to claim 1, characterized in that, The PLC evolution logic of the at least one radiotherapy device includes simulation rules for emitted beam and dose accumulation, which are configured as follows: The rules engine uses a preset time period Δ t The system operates in a cyclic manner; when the beam trigger signal changes from 0 to 1, the engine initiates the dose accumulation process; within each cycle, the engine first reads the pulse frequency setpoint. F And combined with the period duration Δ t Calculate the theoretical increase in the number of pulses within this period. F ×Δ t The newly added amount is accumulated into the pulse count counter address; Subsequently, the engine multiplies the updated pulse count counter value by the preset single-pulse dose to obtain the current real-time cumulative dose, and writes the cumulative dose feedback address. When the cumulative dose reaches or exceeds the prescribed dose, the engine automatically resets the beam trigger signal to 0 and writes 1 to the beam completion status address, and the pulse count counter stops counting.

7. The virtual PLC dynamic simulation system for debugging radiotherapy equipment's host computer according to claim 1, characterized in that, The PLC evolution logic of the at least one radiotherapy device includes industrial-grade heartbeat and watchdog simulation rules, which are configured as follows: An integer memory address is allocated, and an accumulation period is configured. Every certain accumulation period, the engine automatically updates the value in the integer memory address according to a predetermined pattern to simulate the PLC of the radiotherapy equipment actively sending a heartbeat signal.

8. The virtual PLC dynamic simulation system for debugging radiotherapy equipment's host computer according to claim 1, characterized in that, The at least one radiotherapy device PLC evolution logic includes physical environment random noise rules, which are configured as follows: Configure the reference address, maximum amplitude, and noise distribution type; the reference address stores the fluctuation center value of the physical quantity. The engine periodically generates random noise based on the maximum amplitude, according to the noise distribution type, and superimposes it onto the fluctuation center value; The periodically updated physical quantities are written to the output address of the corresponding physical quantities.

9. A virtual PLC dynamic simulation method for debugging the host computer of radiotherapy equipment, characterized in that, The method using the virtual PLC dynamic simulation system for debugging radiotherapy equipment as described in any one of claims 1 to 8 includes the following steps: Startup and Loading: Read the configuration file and create a byte buffer in the system memory or data carrier to simulate the PLC according to the configuration file. The storage area includes at least a data block DB, an input image area I, an output image area Q, and a flag bit area M. At the same time, load at least one radiotherapy equipment PLC evolution logic from the configuration file and associate the at least one radiotherapy equipment PLC evolution logic with the corresponding byte buffer address. Start listening to the network communication layer port. Communication handshake: When the host computer initiates a connection request, a handshake process is performed with the host computer through the network communication layer to establish a communication connection; Concurrent service loop: After the communication connection is established, the network communication layer listens for request messages from the host computer; the protocol encoding and decoding layer parses the request messages and extracts the request instructions; the memory data mapping layer performs data read or write operations on the byte buffer according to the request instructions; simultaneously, the dynamic simulation rule engine layer uses an independent timed scheduling thread to drive the data in the corresponding byte buffer address to perform time-varying calculations according to at least one configured radiotherapy equipment PLC evolution logic, so as to simulate the dynamic changes of physical quantities of the radiotherapy equipment PLC; Terminate operation: When a stop command is detected, release the resources occupied by the system.

10. The virtual PLC dynamic simulation method for debugging the host computer of radiotherapy equipment according to claim 9, characterized in that, During the concurrent service loop phase, after the data write operation on the byte buffer is completed, the radiotherapy device PLC evolution logic associated with the address of the written byte buffer is triggered.

Images