A communication decoupling method and middleware system for a radiotherapy device

Abstract

This invention provides a communication decoupling method and middleware system for radiotherapy equipment. The method is applied to an independently running middleware system and includes: receiving read / write requests from host computer treatment control software, the read / write requests carrying predefined custom business key values; querying a pre-loaded mapping dictionary to obtain a mapping entity uniquely corresponding to the custom business key value, the mapping entity containing at least lower-level machine physical address information and data type information; constructing a data read / write message adapted to the lower-level machine communication protocol based on the lower-level machine physical address information and data type information in the mapping entity, and interacting with the lower-level machine to perform data read / write operations; and returning the read data or the result of the write operation to the host computer treatment control software. This invention achieves decoupling of business logic and underlying communication, adapting to hardware changes without modifying business code, and improving system maintainability and security.

Description

Technical Field

[0001] This invention relates to the field of communication decoupling technology for radiotherapy equipment, and more specifically to a communication decoupling method and middleware system for radiotherapy equipment. Background Technology

[0002] In radiotherapy equipment such as medical linear accelerators, the host computer-based treatment control system (TCS) needs to interact with the slave computer-based programmable logic controller (PLC) in real time with high precision. The PLC is typically responsible for controlling key motion and safety components such as the treatment bed, gantry, multi-leaf grating, and dose monitoring system. Currently, the common communication scheme between the host and slave computers is as follows: the host computer treatment software directly establishes a connection with the slave PLC and performs data reading and writing based on the Siemens S7 communication protocol. In this direct communication mode, when developers write the host computer business code, they must hard-specify the specific physical address (e.g., DB500.DBD18), data type (e.g., REAL, i.e., floating-point), and data length of the parameters to be read in the PLC data block (DB block). All parameter reading and writing logic related to the treatment process is tightly coupled with the address, protocol, and other communication details of these underlying PLCs.

[0003] The aforementioned existing technical solutions have some significant objective defects in practical application and long-term maintenance: First, the maintainability of the system is extremely poor. When the register address or DB block offset corresponding to any business variable changes due to firmware upgrades, hardware replacements, or program logic optimizations of the lower-level PLC, maintenance personnel must search, modify, recompile, and redeploy all source code lines in the upper-level treatment software that reference the old address one by one. This is very easy to introduce new errors due to human oversight.

[0004] Secondly, the development process is prone to errors and difficult to debug. When writing data read and write code, the host computer development engineer is very likely to make offset calculation errors due to manually writing the address (for example, mistakenly writing DB100.DBW200 as DB100.DBW202), or make data type specification errors due to negligence (for example, parsing the address storing floating-point numbers as a double-word integer). Such errors cannot be detected by the compiler at the compilation stage and will only be exposed when the system is running. This may lead to deviations in the display of treatment parameters and trigger device interlocking protection interruptions. Although the existing technology CN117724870A realizes the configurability of communication protocols and parameters through JSON configuration files, which improves the flexibility of protocol adaptation to a certain extent, its focus is on the parameter configuration of the protocol layer and fails to fundamentally separate business semantics from physical addresses. The business code still needs to care about the organization of the underlying data. Furthermore, the business logic is deeply coupled with the underlying communication technology. The source code of the core business processes in the host computer contains a large amount of underlying technical implementation code related to PLC address definitions, S7 protocol data frame assembly, byte order conversion, etc. This tight coupling reduces the readability of the business logic and restricts the overall development and iteration efficiency of the system. While existing technologies such as CN121658013A provide some standardized conversion mechanisms, they still focus on data processing and conversion at the interface level and fail to provide a complete mapping and automatic conversion scheme from business key values ​​to underlying physical addresses.

[0005] In summary, there is an urgent need for a technical solution that can completely decouple communication between the upper and lower level of radiotherapy equipment, eliminate data security risks caused by human coding errors at the architectural level, and significantly reduce the complexity of system development and maintenance.

[0006] Therefore, existing technologies still need further development. Summary of the Invention

[0007] The purpose of this invention is to overcome the above-mentioned technical deficiencies and provide a communication decoupling method and middleware system for radiotherapy equipment to solve the problems existing in the prior art.

[0008] To achieve the above-mentioned technical objectives, according to a first aspect of the present invention, the present invention provides a communication decoupling method for radiotherapy equipment, applied to an independently operating middleware system, comprising: S1. Receive a read / write request from the host computer treatment control software, wherein the read / write request carries a predefined custom business key value; S2. Query the pre-loaded mapping relationship dictionary to obtain the mapping entity that uniquely corresponds to the custom business key value. The mapping entity contains at least the lower-level machine physical address information and data type information. S3. Based on the lower-level machine physical address information and the data type information in the mapping entity, construct a data read / write message adapted to the lower-level machine communication protocol, and interact with the lower-level machine to perform data read / write operations. S4. Return the read data or the result of the write operation to the host computer treatment control software.

[0009] Specifically, the mapping entity also includes data length information, and after interacting with the lower-level machine and reading the data, it also includes: Based on the preset data type information and data length information in the mapping entity, the raw byte stream obtained from the lower-level machine is automatically deserialized and type-converted to obtain target data that matches the data type information.

[0010] Specifically, the mapping dictionary is stored and loaded through a configuration file, and the method further includes: When the middleware system starts, it loads and parses the configuration file, loads all mapping relationships into memory, and records the initial summary value of the configuration file. The current summary value of the configuration file is checked periodically according to a preset cycle; When the current summary value is detected to be inconsistent with the initial summary value, the configuration file is automatically reloaded and parsed to refresh the mapping relationship dictionary without restarting the middleware system and the host computer treatment control software.

[0011] Specifically, the receipt of read / write requests and the return of results are implemented through a pre-established network service interface, which includes: The synchronous call interface based on the HTTP protocol maintains the connection after receiving the read / write request until the data read / write operation is completed and the result is returned. An asynchronous call interface based on the WebSocket protocol returns immediately upon receiving the read / write request. After the data read / write operation is completed, the result is actively pushed through the established long connection.

[0012] Specifically, the lower-level machine communication protocol is the Siemens S7 protocol, and the method for constructing data read / write messages adapted to the lower-level machine communication protocol based on the lower-level machine physical address information and data type information in the mapping entity includes: Determine the maximum length of the protocol data unit corresponding to the pre-specified lower-level PLC model; When the amount of data read or written in a single operation exceeds the maximum length of the protocol data unit, the read / write request is automatically split into multiple sub-messages that meet the length limit, and packet transmission is performed.

[0013] Specifically, the method further includes: Define a standard error code system, including configuration errors, interface errors, communication errors, and data errors; Upon receiving any of the above-mentioned anomalies, an error code and error description are generated, written to the log, and immediately reported to the host computer treatment control software through the status feedback interface, so that the host computer treatment control software can execute the corresponding safety policy according to the error level.

[0014] Specifically, the lower-level machine physical address information is the data block address of the Siemens S7 series PLC, and the data type information includes at least one of bit, byte, word, double word, integer, double integer, and real.

[0015] Specifically, when the middleware system detects a communication interruption with the lower-level machine, it automatically triggers a reconnection mechanism; The reconnection mechanism employs a configurable tiered reconnection interval and performs an unlimited number of retries until the connection is restored or the system stops. During the reconnection period, the system's operating status is marked as a communication anomaly and reported.

[0016] According to a second aspect of the present invention, a communication decoupling middleware system for a radiotherapy device is provided, comprising: The interface layer is used to receive read and write requests from the host computer treatment control software. The read and write requests carry predefined custom business key values ​​and return the read data or the result of the write operation. The mapping layer is used to store a pre-loaded mapping relationship dictionary, receive custom business key values ​​passed in by the interface layer, and obtain a mapping entity that uniquely corresponds to the custom business key value. The mapping entity contains at least lower-level machine physical address information and data type information. The communication layer is used to construct data read / write messages adapted to the lower-level machine communication protocol based on the lower-level machine physical address information and the data type information provided by the mapping layer, interact with the lower-level machine to perform data read / write operations, and send the results back to the mapping layer.

[0017] Specifically, the system further includes an error handling layer, which is used to receive exceptions during the operation of the interface layer, mapping layer, and communication layer, and to classify the exceptions. The categories include configuration anomalies, interface anomalies, communication anomalies, and data anomalies. According to the preset standard error code system, the corresponding error code and error description are generated for the anomaly, written into the log, and reported to the host computer treatment control software in real time through the status feedback interface provided by the interface layer.

[0018] Beneficial effects: This invention provides a communication decoupling method and middleware system for radiotherapy equipment. By constructing an independent communication decoupling middleware and adopting an indirect addressing mechanism of custom business key-mapped entity-physical address, it avoids the direct dependence between the host computer's business code and the slave computer's hardware parameters. The volatile hardware address information is extracted to an external configuration file, and the middleware uniformly manages data conversion and protocol adaptation. This allows the host computer to be programmed only for stable business semantics, significantly improving system maintainability. When the slave computer hardware changes, only the configuration file needs to be updated, without modifying or recompiling the host computer code, eliminating regression testing risks and enhancing functional safety. Through the middleware's automated type verification and deserialization, it avoids address misalignment or type resolution errors caused by manual hard coding, ensuring the accuracy of treatment parameters and further improving system availability. Attached Figure Description

[0019] Figure 1 This is a flowchart of a communication decoupling method for radiotherapy equipment provided in a specific embodiment of the present invention; Figure 2 This is a schematic diagram of the system composition of the communication decoupling middleware system for radiotherapy equipment provided in a specific embodiment of the present invention; Figure 3 This is a flowchart of the communication service between the upper and lower computers provided in a specific embodiment of the present invention; Figure 4 This is a flowchart illustrating the operation of the communication decoupling method provided in a specific embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Based on the embodiments in this application, other similar embodiments obtained by those skilled in the art without creative effort should all fall within the scope of protection of this application. Furthermore, directional terms mentioned in the following embodiments, such as "up," "down," "left," and "right," are only for reference to the directions in the accompanying drawings; therefore, the directional terms used are for illustrative purposes and not for limiting the invention.

[0021] The present invention will be further described below with reference to the accompanying drawings and preferred embodiments.

[0022] Example 1 Please see Figure 1This embodiment provides a communication decoupling method for radiotherapy equipment. The method is applied to an independently running middleware system and specifically includes: receiving read / write requests from host computer treatment control software, the read / write requests carrying predefined custom business key values; querying a pre-loaded mapping dictionary to obtain a mapping entity uniquely corresponding to the custom business key value, the mapping entity containing at least lower-level machine physical address information and data type information; constructing a data read / write message adapted to the lower-level machine communication protocol based on the lower-level machine physical address information and the data type information in the mapping entity, and interacting with the lower-level machine to perform data read / write operations; and returning the read data or the result of the write operation to the host computer treatment control software.

[0023] It is understood that the middleware system in this embodiment is not integrated into the host computer treatment control software in the form of a dynamic link library or embedded code module, but is deployed as an independent process or service in the host computer operating system. It interacts with the host computer treatment control software through a standardized network interface or inter-process communication mechanism. This independently deployed architecture design allows the communication middleware to have independent resource management space and life cycle. When the underlying communication fails or needs to be upgraded or maintained, it will not directly cause the host computer treatment control software to crash or restart, thereby significantly improving the stability and maintainability of the radiotherapy equipment control system.

[0024] See Figure 1 The communication decoupling method in this embodiment specifically includes the following steps: Step S1: Receive read / write requests from the host computer's treatment control software. The read / write requests carry predefined custom business key values.

[0025] In this embodiment, the custom business key value is a semantic abstraction layer connecting the upper-layer business logic and the lower-layer hardware implementation. Unlike the existing technology that directly uses register addresses or variable names, the custom business key value adopts a string identifier with a clear business meaning in the application scenario, such as "Gantry_Angle" to represent the gantry angle, "Dose_Rate" to represent the dose rate, or "Table_Vertical" to represent the vertical position of the treatment table. These key values ​​can be uniformly defined by the system designer according to the business model of the radiotherapy equipment and remain globally unique and stable throughout the entire system. When the host computer treatment control software needs to obtain or set a certain treatment parameter, it only needs to specify the corresponding custom business key value in the read / write request, without needing to know the specific storage location or data format of the parameter in the lower computer. For example, when the host computer sends a read request containing the key value "Gantry_Angle", the middleware system recognizes that the host computer intends to obtain the current rack angle data. In this way, the custom business key value effectively shields the differences and complexities of the underlying hardware, allowing host computer developers to focus entirely on the control logic of the treatment process without having to worry about the implementation details of the underlying communication protocol.

[0026] Step S2: Query the pre-loaded mapping relationship dictionary to obtain the mapping entity that uniquely corresponds to the custom business key value. The mapping entity must contain at least the lower-level machine physical address information and data type information.

[0027] Understandably, the mapping dictionary is the core data structure for the middleware system to achieve decoupling. It is fully loaded into memory when the middleware system starts to ensure efficient runtime queries. The mapping dictionary is a collection of key-value pairs, where the keys are custom business keys and the values ​​are mapping entities. A mapping entity is a structured object encapsulating all the metadata required for underlying communication. Besides containing lower-level physical address information (such as data block number, byte offset, bit offset, etc.) and data type information (such as integer, floating-point, boolean, etc.), it can also contain auxiliary information such as data length, read / write permissions, and unit conversion factors. When the middleware system receives a read / write request carrying a custom business key, it uses that key as an index to quickly search the mapping dictionary in memory, thereby obtaining the mapping entity uniquely bound to that business semantics. This process is equivalent to translating the business-oriented logical language into the hardware-oriented physical language in real time. Because the mapping relationships are pre-configured and centrally managed, when the underlying hardware address changes, only the configuration of the mapping dictionary needs to be updated, without modifying any runtime code, thus achieving separation of configuration and code.

[0028] Step S3: Based on the lower-level machine physical address information and data type information in the mapping entity, construct a data read / write message that is compatible with the lower-level machine communication protocol, and interact with the lower-level machine to perform data read / write operations.

[0029] Understandably, after acquiring the mapping entity, the middleware system possesses all the technical parameters required for precise communication with the lower-level machine. Specifically, the communication driver module within the middleware system determines the exact location of the target register based on the lower-level machine's physical address information recorded in the mapping entity, and determines the byte length to be read or written and the parsing rules based on the data type information. On this basis, the built-in communication driver module automatically assembles data read / write messages conforming to the protocol format according to the standard specifications of the specific industrial communication protocol (such as the S7 protocol) supported by the lower-level machine. For example, if the mapping entity indicates that the target data is located at a specific offset in a data block and is a 32-bit floating-point number, the communication driver module will generate a read command frame containing the correct function code, starting address, and length, and send it to the lower-level machine through the network interface. Subsequently, the middleware system receives the response message returned by the lower-level machine and parses the original byte stream according to the data type information in the mapping entity, converting it into a standard data format that the upper-level machine can understand. The entire message component and interaction process is completely transparent to the upper-level machine, which does not need to care about the complex details of the underlying protocol's frame structure, timing requirements, or byte order conversion.

[0030] Step S4: Return the read data or the result of the write operation to the host computer treatment control software.

[0031] Understandably, after completing the data interaction with the lower-level machine, the middleware system encapsulates the operation result into a unified response format and returns it to the upper-level treatment control software. If the data was successfully read in the previous step, the response contains the converted business data value. If a write operation was performed, the response contains a status code indicating success or failure. If an exception occurs during communication (such as timeout, address error, etc.), the response will contain standardized error information. Through this unified return mechanism, the upper-level treatment control software can handle all types of read and write request results in a consistent manner, further simplifying the complexity of the business logic code.

[0032] In this embodiment, the lower-level machine physical address information is the data block address of the Siemens S7 series PLC, and the data type information includes at least one of bit, byte, word, double word, integer, double integer, and real.

[0033] It should be noted that for the Siemens S7 series controllers used in radiotherapy equipment, the lower-level physical address information in the mapping entity is defined as a data block address identifier conforming to the S7 protocol addressing specification, for example, using the standard format "DB[block number].DB[X / W / D][offset]", where DBX represents bit addressing, DBW represents word addressing, and DBD represents double word addressing. At the same time, the data type information strictly corresponds to the above address format, covering commonly used industrial control types such as Boolean (BOOL), 8-bit byte (BYTE), 16-bit word (WORD / INT), 32-bit double word (DWORD / DINT), and 32-bit floating-point number (REAL). This metadata definition constitutes the basis for the middleware system to understand the underlying hardware data layout. By binding the address rules and data types in the same mapping entity, the legality of the configuration can be verified from the semantic level, thereby avoiding communication anomalies caused by address boundary alignment issues at the source.

[0034] In this embodiment, in order to further improve the security and accuracy of data interaction, the mapping entity also includes data length information. After interacting with the lower-level machine and reading data, it also includes: automatically performing deserialization and type conversion on the raw byte stream obtained from the lower-level machine according to the preset data type information and data length information in the mapping entity, so as to obtain target data that matches the data type information.

[0035] It's important to note that when the middleware system receives the raw hexadecimal byte stream from the lower-level machine, it doesn't directly pass it through to the upper-level machine. Instead, it immediately triggers the built-in automatic parsing engine. This engine uses the data type and length information encapsulated in the mapping entity as execution instructions to automatically complete a series of low-level conversion operations, such as byte order adjustment, sign bit extension, and floating-point number decoding. For example, when the mapping entity indicates that the data type corresponding to a key value is real and the length is 4 bytes, the parsing engine will automatically extract the 4 bytes at the corresponding offset position in the response message and convert it into a single-precision floating-point number that the upper-level machine can recognize, according to the IEEE 754 standard. If the data type is integer and the length is 2 bytes, it will automatically perform high-low byte swapping and parse it as a signed integer. This process is entirely driven by the pre-defined metadata and automatically completed by the middleware system's built-in parsing program. When the underlying hardware or data format changes, developers do not need to modify, compile, or deploy any running business logic code; they only need to update the metadata in the mapping entity.

[0036] By employing the above mechanism, a robust data parsing security defense is constructed. In the existing hard-coded model, developers must manually calculate the byte offset of each variable in the business code and write specific type conversion functions. This is not only a huge workload, but also extremely prone to serious consequences due to human negligence. In this embodiment, since the deserialization logic relies entirely on the verified mapping entity metadata, as long as the configuration file is correct, the data parsing result has mathematical determinism. This automated processing method of configuration as code avoids the uncertainty risks brought about by manually calculating offsets and manually writing conversion logic, ensuring the absolute accuracy of reading critical treatment safety parameters such as dose, position, and speed during radiotherapy, and guaranteeing the functional safety of medical equipment from the underlying software architecture.

[0037] In this embodiment, the mapping relationship dictionary is stored and loaded through a configuration file. The method further includes: loading and parsing the configuration file when the middleware system starts, loading all mapping relationships into memory, and recording the initial summary value of the configuration file; periodically detecting the current summary value of the configuration file according to a preset period; and automatically reloading and parsing the configuration file when the current summary value is detected to be inconsistent with the initial summary value, so as to refresh the mapping relationship dictionary without restarting the middleware system and the host computer treatment control software.

[0038] It should be noted that the configuration file, as the physical carrier of the mapping dictionary, exists independently of the middleware system's executable code and supports XML, JSON, or other structured text formats. This external storage method makes changes to the mapping relationship no longer dependent on code recompilation and deployment. During the middleware system startup phase, the system reads the configuration file and parses the key-value pairs into a complete memory data structure. At the same time, the system calculates the digest value of the configuration file content (such as MD5 hash value or SHA checksum) and saves it in memory as the initial digest value. This initial digest value constitutes the basis for subsequent judgment of whether the configuration has changed.

[0039] To enable real-time awareness of configuration changes, the middleware system runs an independent timed monitoring task. This task triggers a file status check at a preset period. Each time it is triggered, the system simply reads the configuration file and calculates its current digest value. Then, it compares the current digest value with the initial digest value stored in memory. Since the digest calculation only involves hashing the file content and not complex semantic parsing, this detection process consumes very little system I / O and CPU resources and will not interfere with normal communication services. Only when the current digest value is inconsistent with the initial digest value is it determined that the configuration file has been modified externally, thus triggering the reload process.

[0040] When the reload process is triggered, to ensure the continuity and safety of the radiotherapy equipment control business, the system first attempts to load and parse the new configuration file in a background thread, generating a new temporary mapping dictionary object. During this process, the original mapping dictionary continues to provide services normally, and all read and write requests are unaffected. Only when the new configuration file is successfully parsed and passes the integrity check will the active dictionary in memory be instantly pointed to the new object through pointer switching or reference replacement, and the initial summary value will be updated synchronously. This mechanism ensures that at any time during configuration updates, the upper-layer business can always access a complete and valid mapping dictionary, avoiding communication interruptions caused by temporary data loss or incomplete structure during the update process.

[0041] In this embodiment, the reception of read / write requests and the return of results are achieved through a pre-established network service interface. This network service interface includes a synchronous call interface based on the HTTP protocol and an asynchronous call interface based on the WebSocket protocol. After receiving the read / write request, the synchronous call interface maintains the connection until the data read / write operation is completed and the result is returned. The asynchronous call interface returns immediately after receiving the read / write request, and actively pushes the result through the established long connection after the data read / write operation is completed.

[0042] It should be noted that this dual-interface design is specifically adapted to two distinct business characteristics in radiotherapy equipment. When the middleware system starts up, it listens on both the HTTP port and the WebSocket port, exposing two sets of standardized API endpoints to the outside world. However, internally, these two interfaces will eventually converge on the same core processing logic. This decouples the interface protocol layer from the core business logic layer, enabling the middleware to support diverse external communication needs with a unified internal model without having to repeatedly develop data processing code for each protocol.

[0043] Furthermore, when the host computer treatment control software initiates an HTTP request carrying a custom business key value, the middleware system suspends the HTTP session and immediately triggers the internal decoupling process. During this period, the HTTP connection is in a hold state, and the host computer client is in a blocking waiting mode. Only when the middleware system successfully reads data from the lower-level machine and completes deserialization, or when the write operation receives a confirmation response from the lower-level machine, will the middleware encapsulate the result into an HTTP response body and close or reuse the connection. The deterministic timing and simple transaction model of the HTTP synchronous interface can effectively avoid logical errors caused by out-of-order or lost asynchronous messages, ensuring the reliability of critical medical command execution. On the other hand, the asynchronous call interface based on the WebSocket protocol adopts a subscription-push model. The host computer treatment control software first establishes a full-duplex long-duration WebSocket connection with the middleware, and then sends a subscription or write command containing a custom business key value. After receiving the command, the middleware system only performs syntax verification and task enqueueing operations, and then returns an acknowledgment message to the client without waiting for the actual execution result of the underlying hardware. At the same time, the asynchronous processing thread inside the middleware begins to execute data interaction with the lower-level machine. Once the latest data is obtained or the operation is completed, the middleware actively pushes the result frame containing the business data, that is, the structured response result, to the host computer client that subscribed to the key value through the previously established long-duration WebSocket connection. The WebSocket asynchronous push mechanism eliminates invalid polling requests and ensures that the host computer interface can smoothly and in real time reflect the physical status of the lower-level machine.

[0044] It should be understood that in actual deployments, the middleware system can also be extended with other types of network interfaces, such as gRPC or MQTT, as long as they can be connected to the middleware's core mapping and communication layer via an adapter pattern. Furthermore, for the same custom business key-value pair, the host computer can flexibly choose the invocation method based on the current business stage. For example, during the treatment preparation stage, all preset parameters can be read at once via an HTTP interface to ensure correct configuration, while during the treatment beam exit stage, it automatically switches to subscribing to the real-time stream of key state variables via a WebSocket interface. This allows the middleware system to serve as a universal communication hub, seamlessly adapting to the diverse data interaction needs throughout the entire lifecycle of radiotherapy equipment, ensuring the security and reliability of critical control commands.

[0045] In one specific embodiment, the lower-level machine communication protocol is the Siemens S7 protocol. The method for constructing a data read / write message adapted to the lower-level machine communication protocol based on the lower-level machine physical address information and data type information in the mapping entity includes: determining the maximum length of the protocol data unit corresponding to the pre-specified lower-level machine PLC model; when the amount of data read / written in a single operation exceeds the maximum length of the protocol data unit, automatically splitting the read / write request into multiple sub-messages that meet the length limit, and performing packet transmission.

[0046] It should be noted that the Siemens S7 protocol has strict hardware limitations on the length of data units (PDUs). Different PLC models have different PDU upper limits. However, in actual communication, protocol header overhead must be deducted. In the data interaction scenario of radiotherapy equipment, the host computer treatment control software often needs to read continuous parameters in a certain data block in batches. The sum of these data volumes can easily exceed the effective payload limit of a single PDU. If the middleware system directly transmits such large-span read and write requests to the lower computer, it will directly trigger a protocol layer rejection response or truncation error, resulting in the failure to acquire critical treatment data. Therefore, the adaptive packet transmission mechanism introduced in this embodiment at the communication layer ensures the feasibility of large-volume data interaction from the bottom layer.

[0047] Furthermore, before executing packet transmission, the middleware system first needs to accurately determine the maximum message length that the currently connected lower-level machine can handle. This process does not rely on static configuration files or hard-coded constants, but rather dynamically reads the actual PDU size parameters fed back by the lower-level machine during the first communication by querying the system status list or connection negotiation process specified by the S7 protocol. This dynamic detection mechanism enables the same middleware software to adapt to various Siemens controllers, from older to the latest models. Even if the PLC hardware is replaced or the firmware is upgraded on-site, resulting in changes in PDU capacity, the middleware can automatically sense and adjust its strategy without manual intervention or redeployment.

[0048] Specifically, after the middleware system parses the target address range and data length of the current read / write request based on the mapping entity, it immediately compares them with the maximum effective payload of the acquired PDU. If the requested data volume exceeds the limit, the system will automatically trigger a splitting algorithm. This algorithm calculates the required number of sub-messages, the starting address offset, and the data length of each sub-message based on the PDU upper limit. Subsequently, the communication driver module sends these sub-messages to the lower-level machine in sequence and allocates a temporary buffer in memory with the same size as the original request. During the response reception phase, the middleware system performs integrity verification on the returned sub-response data and writes it to the corresponding position in the temporary buffer according to the offset order. Only when all sub-messages have successfully responded and the data is concatenated will the system pass this complete buffer data as the final result to the upper layer. If any sub-message times out or fails verification during packet transmission, the system will retransmit the specific sub-message according to the preset retry policy, or mark the entire read / write operation as abnormal after a retry failure. It should be noted that the entire complex process of splitting, sending, receiving, reassembling, and exception handling is completely encapsulated within the communication layer. For the upper mapping layer and interface layer, what is sent is always a logically complete read / write command, and what is received is also a logically complete data result. This means that the host computer developers and business logic code do not need to be aware of the physical limitations of the underlying protocol, nor do they need to write any compensation code for packet splitting.

[0049] In a preferred embodiment, the exception handling and fault recovery mechanism of the middleware system is further defined, specifically including defining a standard error code system, including configuration exceptions (such as XML format errors, duplicate key values), interface exceptions (such as key value non-existence exceptions), communication exceptions (such as connection timeout exceptions, PLC access denied exceptions), and data exceptions (such as length or type mismatch exceptions). When any of the above exceptions is received, an error code and error description are generated, written to the log, and immediately reported to the host computer treatment control software through the status feedback interface, so that the host computer treatment control software can execute the corresponding safety policy according to the error level.

[0050] It should be noted that the four types of anomalies defined in the above embodiments cover the risk points of the entire link from static configuration to dynamic interaction. Configuration anomalies usually refer to corrupted mapping dictionary file format, missing fields, or duplicate key-value pairs. These errors mean that the middleware has lost the correct translation basis and must be caught immediately during startup or hot reloading. Interface anomalies, such as key-value non-existence anomalies, mean that the business identifier requested by the host computer cannot find the corresponding entity in the current mapping dictionary. This often indicates that the host computer software version is inconsistent with the lower-level computer configuration version or that the configuration is incorrect. If not blocked in time, it may lead to the inability to read address data. Communication anomalies, such as communication connection timeout anomalies, reflect the instability of the physical link or the lack of response of the lower-level PLC, which is the most direct fault manifestation of the network layer. Data anomalies, such as data type mismatch anomalies, occur in the deserialization stage. For example, the actual length of bytes read does not match the expected length defined in the mapping entity, or the floating-point number decoding result exceeds the reasonable physical range. These anomalies directly point to data integrity damage. When any of the above anomalies is triggered, the middleware does not simply throw a general error, but generates structured information containing a unique error code and readable description according to the preset standard error code system and writes it to the local log. The aforementioned error messages are pushed to the host computer treatment control software in real time through the status feedback interface, enabling the host computer to accurately execute the corresponding safety interlocks and issue alarm prompts based on the severity of the error code, rather than simply judging it as a communication failure. This ensures that every problem that occurs during treatment can be characterized, located, and properly handled, thereby maximizing the safety of patients and equipment.

[0051] In a preferred embodiment, when the middleware system detects a communication interruption with the lower-level machine, it automatically triggers a reconnection mechanism. This reconnection mechanism uses a configurable tiered reconnection interval and performs an unlimited number of retries until the connection is restored or the system stops. During the reconnection period, the system's operating status is marked as a communication anomaly and reported.

[0052] It should be noted that traditional fixed-frequency reconnection strategies generate a large number of invalid handshake requests when the network is interrupted for a long time. This not only wastes bandwidth resources, but may also impact the vulnerable lower-level PLC. The step-by-step reconnection strategy (or exponential backoff algorithm) adopted in this embodiment can effectively avoid this risk. For example, the system can be configured with an initial reconnection interval of 1 second. If the first reconnection fails, the interval for the next attempt will automatically double to 2 seconds, then 4 seconds, 8 seconds, 16 seconds, and so on, until the preset maximum interval limit is reached, at which point the retry frequency is maintained. This gradual probing rhythm ensures rapid connection recovery during brief network fluctuations and avoids excessive occupation of network resources during faults. Moreover, during the entire reconnection process, the middleware system will explicitly mark its external service status as communication abnormal and continuously broadcast this status flag to the host computer treatment control software through the status feedback interface. This clearly informs the host computer that the currently acquired data has lost its real-time guarantee, forcing the host computer to suspend the automatic control logic that relies on real-time data or enter a safe standby mode. This avoids treatment deviations caused by misjudgments due to the use of old data in the cache. Only when the reconnection is successful and data interaction returns to normal will the abnormal flag be cleared and the host computer be notified to resume the business process.

[0053] In another specific embodiment, as an alternative storage and loading method for the mapping relationship dictionary, the mapping relationship dictionary can be stored in a database, that is, the mapping relationships are stored in a relational database independent of the middleware system, such as SQL Server or MySQL. When the middleware system starts, it reads all the mapping relationships from the database and loads them into memory. The middleware system periodically reads and refreshes the mapping relationship dictionary in memory from the database according to a configurable refresh interval, so that changes to the mapping relationships can take effect without restarting the middleware system.

[0054] It should be noted that, under the database storage scheme, when the middleware system starts up, it establishes a connection with the relational database through preset database connection parameters, executes query operations to read all mapping relationship records stored in the database, and loads them into memory to construct the mapping relationship dictionary data structure required for runtime. Simultaneously, the middleware system starts a timed refresh task, periodically initiating queries to the database at configurable refresh intervals to retrieve mapping relationship records that may have changed. When a difference is detected between the mapping relationships in the database and the current mapping relationship dictionary in memory, the middleware system automatically reloads the changed mapping relationships into memory, completing the refresh of the mapping relationship dictionary. This ensures that changes to the mapping relationships take effect immediately without requiring a restart of the middleware system.

[0055] Understandably, the essential difference between the database storage solution and the aforementioned configuration file storage solution lies only in the carrier of the mapping relationship dictionary. The database storage solution uses a relational database, while the configuration file uses a structured text file. The core content they both carry—the mapping relationship between custom business keys and mapped entities, and the middleware system's operational mechanism for decoupling communication between upper and lower level machines based on this mapping relationship—remains consistent. In actual deployment, those skilled in the art can flexibly choose between the configuration file method or the database method based on the specific operation and maintenance environment and configuration management requirements of the radiotherapy equipment. They can also support both methods simultaneously and select one based on a preset priority. The advantage of using the database storage solution is that it can leverage the mature functions of the database management system, such as built-in access control, concurrent access, and data backup and recovery, to provide higher reliability and security for the storage and management of mapping relationships. In scenarios where multiple accelerator devices in a large radiotherapy center are uniformly operated and maintained, the mapping relationship configurations of each device can be centrally managed through a central database, further improving operational efficiency.

[0056] It should be noted that this embodiment constructs a complete indirect addressing mechanism of custom business key-value-mapping entity-physical address. Structurally, this mechanism separates the business semantics of the host computer from the physical address of the slave computer. During runtime, the connection is achieved through dynamic translation and protocol adaptation of the middleware system. Compared with the existing technology of directly hard-coding the physical address in the business code, the technical solution of this embodiment improves the flexibility and scalability of the system. When the physical address changes due to hardware upgrades or PLC program adjustments to the radiotherapy equipment, only the mapping configuration of the middleware system needs to be modified to ensure that the business logic of the host computer remains unchanged and normal use is restored. The code of the host computer treatment control software does not need to be modified, avoiding the hidden danger of human error introduced by manually modifying the hard-coded address, and ensuring the safety and reliability of the radiotherapy process.

[0057] Example 2 Please see Figure 2This embodiment provides a communication decoupling middleware system for radiotherapy equipment, specifically including an interface layer, a mapping layer, and a communication layer. The interface layer receives read / write requests from the host computer's treatment control software. These requests carry predefined custom business key values, and the system returns the read data or the result of the write operation to the host computer. The mapping layer stores a pre-loaded mapping dictionary, receives the custom business key values ​​from the interface layer, and obtains the mapping entity uniquely corresponding to each custom business key value. Each mapping entity contains at least the lower-level machine's physical address information and data type information. The communication layer, based on the lower-level machine's physical address information and data type information provided by the mapping layer, constructs data read / write messages adapted to the lower-level machine's communication protocol, interacts with the lower-level machine to perform data read / write operations, and sends the results back to the mapping layer, which then returns them to the interface layer.

[0058] In a preferred embodiment, the system further includes an error handling layer, which receives exceptions during the operation of the interface layer, mapping layer, and communication layer, and classifies the exceptions. The classification includes configuration exceptions (such as XML format errors, duplicate keys), interface exceptions (such as non-existent key values), communication exceptions (such as communication connection timeouts, PLC access denied), and data exceptions (such as data type mismatches or length mismatches). According to a preset standard error code system, the system generates corresponding error codes and error descriptions for the exceptions, writes them to the log, and reports them to the host computer treatment control software in real time through the status feedback interface provided by the interface layer.

[0059] It should be noted that the error handling layer adopts the design concept of aspect-oriented programming. Unlike the traditional architecture that disperses exception handling logic within various modules, this embodiment centralizes all exception capture, classification, encoding, and reporting logic in an independent error handling layer. When the interface layer encounters an illegal request format, the mapping layer discovers missing key values ​​or configuration conflicts, or the communication layer encounters network timeouts or data verification failures, these exceptions are uniformly sent to the error handling layer. The error handling layer, based on a predefined standard error code system, converts the underlying technical exceptions into structured error information with clear business meaning and security level, and records it in a local log file for traceability. At the same time, through the status feedback channel reserved in the interface layer, the error information is pushed to the host computer treatment control software in real time, triggering the corresponding security interlocks. This centralized error management mechanism improves code readability and maintainability, and ensures the consistency and predictability of abnormal behavior throughout the system.

[0060] See Figures 2-4 The working principle of this embodiment will be illustrated below using a middleware system for radiotherapy equipment as a specific example: The middleware is deployed on the host computer of the radiotherapy equipment (such as the treatment console computer), is compatible with Windows and Linux systems, and can interact with the host computer treatment software (such as the treatment control system TCS) through a standardized interface. The lower computer is a Siemens S7 series PLC (controlling motion, dose, and safety interlocks), which communicates using the S7 protocol. All radiotherapy-related parameters are stored in a designated DB block.

[0061] like Figure 2 As shown, this middleware software adopts a layered architecture design, divided into an interface layer, a mapping layer, a communication layer, and an error handling layer from top to bottom. Each layer runs independently and works collaboratively. The specific implementation details are as follows: (1) Mapping layer: key-value semantic mapping mechanism; The mapping layer is the core module of the middleware, responsible for establishing the mapping relationship between the host computer's custom key and the PLC data parameters, realizing data decoupling and unified management. The specific implementation is as follows: The definition of key: It is defined by the developer according to the business needs of industrial equipment. It uses a string with business meaning, such as "Radiation_Dose" representing radiotherapy dose and "Gantry_Speed" representing rack speed. The key value is globally unique and does not change with the PLC parameters. Definition of value: value is a custom entity class containing the following 5 core fields, comprehensively covering all parameters required for PLC data reading, and adapting to the address rules of PLC DB blocks (e.g., DB1.DBD100 corresponds to double-word data): PLC Data Type: Specify the PLC data type corresponding to the key, including bit (BOOL), byte (BYTE), word (WORD), double word (DWORD), integer (INT), double integer (DINT), real (REAL), etc., corresponding to the address types such as DBX, DBB, DBW, DBD in the PLC DB block, to ensure type matching when reading data; PLC specific register address: accurate to the specific address of the PLC DB block, such as "DB1.DBD100" (double word starting from the 100th byte of the DB1 data block) and "DB2.DBX5.0" (bit 0 of the 5th byte of the DB2 data block). PLC data length: determined according to the data type, such as 8 bits (1 byte) for single-byte type and 32 bits (4 bytes) for double-word type, to ensure that there are no truncation errors or redundancy when reading data; PLC specific value: Used to store real-time data read from the PLC as a data cache. The host computer can directly obtain the content of this field by calling the key value interface without participating in the PLC communication process. Protocol version identifier: Used to specify the version number of the protocol field; Mapping relationship storage: All key-value mapping relationships are stored in an independent configuration file (supporting XML, JSON and other formats, which are easy to edit and maintain). The configuration file can be edited manually or modified through the visual interface provided by the middleware without modifying the middleware code and the host computer business code. Loading of mapping relationships: When the middleware system starts, it will load the configuration file once. The middleware will automatically parse the configuration file, load all key-value mapping relationships into memory, and record the MD5 value (digest value) of the current configuration file. The system will also start a scheduling task, which will be executed every 5 seconds. When the MD5 value of the configuration file is found to have changed, it means that the file has been modified, and the configuration file will be reloaded and parsed. In this way, the mapping relationship can be refreshed without restarting the middleware and the treatment system. In addition, the middleware does not support duplicate key values. The core reason is to ensure the uniqueness and accuracy of the interaction between the host computer, the middleware, and the slave computer. If a duplicate key value occurs, the entire system state will be changed. The status feedback interface in the interface layer will return the configuration file error status. Table 1 shows an example of key-value mapping relationship attributes. Table 1 Key-value mapping relationship attribute table (2) Interface layer: host computer interaction interface The interface layer provides a simple and unified calling interface for the host computer business software, shielding it from S7 protocol details and PLC parameter details. Host computer developers do not need to master PLC communication-related knowledge; they only need to call the interface and pass in a custom key value to complete data reading. Specifically, the interface layer includes a data reading interface, a mapping relationship query interface, and a status feedback interface. Data Reading Interface: Designed using HTTP and TCP protocols, supporting both synchronous and asynchronous calling modes. Synchronous calls use the HTTP protocol. The host computer sends an HTTP request to the interface layer, passing in a custom key value. It then waits for the middleware to complete subsequent processing (key value verification, mapping layer query, and communication layer data reading) until the middleware returns a "reading status (success / failure) + specific data (the PLC specific value field in the value)" response via HTTP. Only then can the host computer continue executing subsequent logic. This mode is only suitable for urgent reading of critical parameters. Asynchronous calls use the WebSocket protocol. The host computer first subscribes to the interface layer's preset WebSocket address. After successful subscription, it passes in a custom key value and initiates a data reading request. It can immediately return and continue executing its UI rendering, main logic operations, etc., without waiting. Upon receiving the request, the interface layer verifies the key value's validity (whether it exists in the mapping layer hash table). If verification is successful, it forwards the request to the mapping layer to query PLC parameters and calls the communication layer interface to complete the data reading. After the data reading is complete, the result is asynchronously pushed to the host computer via the established WebSocket long connection, effectively avoiding blocking the host computer's UI or main logic.

[0062] Mapping relationship query interface: used by the host computer to query or modify all current key-value mapping relationships, facilitating debugging and maintenance by developers; Status feedback interface: Used to report the middleware's running status to the host computer, such as normal communication, communication interruption, configuration file error, etc., so that the host computer can handle abnormal situations in a timely manner; (3) Communication layer: PLC communication protocol implementation; The communication layer is responsible for establishing an S7 protocol communication connection with the lower-level PLC and performing specific data reading operations. It is compatible with different PLC models such as S7-200 SMART, S7-1200, and S7-1500. The specific implementation steps include: PLC Model Compatibility: Before connection, determine the PDU length based on the target PLC model, as different PLC models have different PDU (Protocol Data Unit) lengths. The biggest difference between PLC models is the length of a single PDU data packet, which directly determines the maximum number of bytes the program can read / write at once and whether automatic packet splitting is required. The relationship between PLC model and PDU is shown in Table 2: Table 2 Maximum PDU length for different PLCs Connection Establishment: When the middleware starts, the communication layer automatically reads the PLC connection parameters (such as IP address and port number) from the configuration file and establishes a connection with the PLC corresponding to the IP address and port. The communication layer supports an automatic reconnection mechanism. When communication is interrupted, it attempts to re-establish the connection at preset intervals (which can be set through the configuration file) to ensure communication continuity. When communication interruption or connection timeout is detected, a reconnection process is triggered, using a tiered configurable reconnection interval (the initial interval can be set to 1000ms, increasing gradually to a preset maximum value, which can be set through the configuration file). The maximum number of retries cannot be configured, and the connection will be retried indefinitely until the connection is successful or the program exits. Connection failure or timeout error logs are recorded, and the system status is set to communication abnormal. Data reading: Receive entity parameters passed from the mapping layer, construct S7 protocol messages, read data from the specified DB block, parse and update the PLC specific value field of the custom entity Value in the corresponding mapping layer, so that the interface layer can quickly return to the host computer through the key. When reading fails, return a clear error code and description. (4) Error handling layer: responsible for the unified capture, classification and handling of runtime exceptions of the system; Define a standard error code system to cover configuration anomalies (such as XML format errors, duplicate keys), interface anomalies (such as keys not existing), communication anomalies (connection timeouts, PLC access denied), and data anomalies (length or type mismatch). All errors are automatically written to the log and the status feedback interface of the interface layer is updated in real time to report the specific error codes and descriptions to the host computer treatment control system. The host computer executes corresponding strategies based on the severity of the error: for example, prompting the user and pausing the current treatment request when communication is interrupted; preventing the system from entering the ready state when there is a configuration error, thus ensuring the safety of treatment operations from the software level; The host computer treatment control software needs to obtain the rotation angle of the accelerator gantry in real time for dose calculation or motion control. When writing the host computer business code, the developers only need to call the read request containing the custom business key value "Gantry_Angle", without needing to know the specific physical address (such as DB500.DBD18) or data type (such as FLOAT32) corresponding to this parameter in the lower computer PLC. When the middleware system receives the request, it will automatically query the mapping relationship dictionary in memory, locate the mapping entity uniquely bound to "Gantry_Angle", and then construct an S7 protocol message based on the address information and type information encapsulated in the entity and interact with the lower computer. For the host computer developers, the underlying protocol details are completely shielded, and the business code exhibits extremely high semantic clarity and stability. Even if the storage address of the rack angle data is changed to DB500.DBD22 due to subsequent hardware upgrades, or the data type is adjusted to double integer, the host computer business code does not need to be modified in any way, thus avoiding the risk of human error introduced by code refactoring. Furthermore, such as Figure 4 As shown, after the middleware system starts, when the aforementioned hardware parameters change, the maintenance personnel only need to modify the external XML configuration file of the middleware system and then load the file. For example, if the address of the original rack angle changes after replacing the PLC, it is necessary to change the mapping entity in the configuration file. Simply update the offset field corresponding to "Gantry_Angle" from 18 to 22, save the file, establish a communication connection, and the timed monitoring task inside the middleware system will detect the change in the configuration file summary value in the next detection cycle. Then, it will automatically trigger the reload process, complete the parsing of the new mapping relationship and memory replacement in the background, and then return the data. The entire process does not require stopping the middleware service or restarting the host computer treatment control software. This greatly shortens the equipment maintenance window time, avoids clinical treatment interruption or abnormal state initialization that may be caused by frequent system start-stop, and significantly improves the availability and maintenance efficiency of radiotherapy equipment.

[0063] Suppose that during a configuration update, the maintenance personnel mistakenly configured the data type of "Gantry_Angle" as INT (2-byte integer), while the PLC actually returns 4-byte floating-point data. When the middleware system attempts to deserialize based on the incorrect metadata, it will immediately detect the data length or format mismatch, triggering a data type mismatch exception. In this case, the middleware will not return an incorrect value to the host computer, but will generate a structured exception message containing a specific error code and report it in real time through the status feedback interface. After receiving the error code, the host computer's treatment control software can accurately identify the configuration error type and execute the corresponding safety interlock strategy, thereby preventing the risk of mistreatment due to parameter parsing errors. Similarly, if a network interruption occurs during treatment, causing a communication timeout, the middleware system will automatically enter a tiered reconnection state and mark the system operation status as a communication exception and continuously report it. During this period, the host computer can clearly know that the current data has lost its real-time guarantee, thereby avoiding the use of old angle values ​​in the cache for incorrect motion control.

[0064] It should be noted that this embodiment provides a communication decoupling middleware system, including an interface layer, a mapping layer, and a communication layer. Data flow is achieved through standardized internal interfaces, realizing physical isolation between protocol adaptation, semantic translation, and underlying execution. Through a key-value mapping mechanism, the host computer does not need to manually write PLC register addresses, data types, and other parameters, avoiding problems such as accidental coding, parameter matching errors, and address writing deviations. This achieves decoupling between the host and host computers, significantly reducing maintenance costs. When the host computer's PLC register address changes, the model is replaced, or the S7 protocol version is upgraded, only the mapping relationship in the configuration file needs to be modified; no further modifications are required. Modifying the host computer business code and middleware code reduces coding and eliminates the need for full-process retesting, significantly improving maintenance efficiency and lowering development and maintenance costs. The standardized interface shields the professional knowledge of S7 protocol details and PLC address rules, so host computer developers do not need to master PLC communication-related technologies. They only need to call a simple key value interface to complete data reading. It has strong adaptability and high compatibility, supports all mainstream PLC models in the Siemens S7 series, is compatible with S7 protocol versions, and can be adapted to PLC devices with different configurations. It also supports all mainstream versions of Windows and Linux systems, further improving the versatility of this invention.

[0065] Example 3 In a preferred embodiment, this application also provides an electronic device, the electronic device comprising: The computer device includes a memory and a processor. The memory stores computer-readable instructions that, when executed by the processor, implement the communication decoupling method for a radiotherapy device. This computer device can be broadly categorized as a server, terminal, or any other electronic device with the necessary computing and / or processing capabilities. In one embodiment, the computer device may include a processor, memory, network interface, communication interface, etc., connected via a system bus. The processor of the computer device can be used to provide the necessary computing, processing, and / or control capabilities. The memory of the computer device may include a non-volatile storage medium and internal memory. The non-volatile storage medium may store an operating system, computer programs, etc. The internal memory can provide an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface and communication interface of the computer device can be used to connect and communicate with external devices via a network. When the computer program is executed by the processor, it performs the steps of the method of the present invention.

[0066] This invention can be implemented as a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the steps of the methods of embodiments of the invention to be performed. In one embodiment, the computer program is distributed across multiple network-coupled computer devices or processors, such that the computer program is stored, accessed, and executed in a distributed manner by one or more computer devices or processors. A single method step / operation, or two or more method steps / operations, may be executed by a single computer device or processor or by two or more computer devices or processors. One or more method steps / operations may be executed by one or more computer devices or processors, and one or more other method steps / operations may be executed by one or more other computer devices or processors. One or more computer devices or processors may execute a single method step / operation, or execute two or more method steps / operations.

[0067] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0068] The technical features described above can be combined arbitrarily. Although not all possible combinations of these technical features are described, any combination of these technical features should be considered to be covered by this specification, provided that such combination does not contain contradictions.

[0069] The specific embodiments of the present invention described above do not constitute a limitation on the scope of protection of the present invention. Any other corresponding changes and modifications made in accordance with the technical concept of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A communication decoupling method for radiotherapy equipment, applied to an independently operating middleware system, characterized in that, include: S1. Receive a read / write request from the host computer treatment control software, wherein the read / write request carries a predefined custom business key value; S2. Query the pre-loaded mapping relationship dictionary to obtain the mapping entity that uniquely corresponds to the custom business key value. The mapping entity contains at least the lower-level machine physical address information and data type information. S3. Based on the lower-level machine physical address information and the data type information in the mapping entity, construct a data read / write message adapted to the lower-level machine communication protocol, and interact with the lower-level machine to perform data read / write operations. S4. Return the read data or the result of the write operation to the host computer treatment control software.

2. The communication decoupling method for radiotherapy equipment according to claim 1, characterized in that, The mapping entity also contains data length information. After interacting with the lower-level machine and reading the data, the process further includes: Based on the preset data type information and data length information in the mapping entity, the raw byte stream obtained from the lower-level machine is automatically deserialized and type-converted to obtain target data that matches the data type information.

3. The communication decoupling method for radiotherapy equipment according to claim 1, characterized in that, The mapping dictionary is stored and loaded through a configuration file, and the method further includes: When the middleware system starts, it loads and parses the configuration file, loads all mapping relationships into memory, and records the initial summary value of the configuration file. The current summary value of the configuration file is checked periodically according to a preset cycle; When the current summary value is detected to be inconsistent with the initial summary value, the configuration file is automatically reloaded and parsed to refresh the mapping relationship dictionary without restarting the middleware system and the host computer treatment control software.

4. The communication decoupling method for radiotherapy equipment according to claim 1, characterized in that, The reception of the read / write request and the return of the result are achieved through a pre-established network service interface, which includes: The synchronous call interface based on the HTTP protocol maintains the connection after receiving the read / write request until the data read / write operation is completed and the result is returned. An asynchronous call interface based on the WebSocket protocol returns immediately upon receiving the read / write request. After the data read / write operation is completed, the result is actively pushed through the established long connection.

5. The communication decoupling method for radiotherapy equipment according to claim 1, characterized in that, The lower-level machine communication protocol is the Siemens S7 protocol. The method for constructing data read / write messages adapted to the lower-level machine communication protocol based on the lower-level machine physical address information and data type information in the mapping entity includes: Determine the maximum length of the protocol data unit corresponding to the pre-specified lower-level PLC model; When the amount of data read or written in a single operation exceeds the maximum length of the protocol data unit, the read / write request is automatically split into multiple sub-messages that meet the length limit, and packet transmission is performed.

6. The communication decoupling method for radiotherapy equipment according to claim 1, characterized in that, The method further includes: Define a standard error code system, including configuration errors, interface errors, communication errors, and data errors; Upon receiving any of the above-mentioned anomalies, an error code and error description are generated, written to the log, and immediately reported to the host computer treatment control software through the status feedback interface, so that the host computer treatment control software can execute the corresponding safety policy according to the error level.

7. The communication decoupling method for radiotherapy equipment according to claim 1, characterized in that, The lower-level machine physical address information is the data block address of the Siemens S7 series PLC, and the data type information includes at least one of bit, byte, word, double word, integer, double integer, and real.

8. The communication decoupling method for radiotherapy equipment according to claim 1, characterized in that, When the middleware system detects a communication interruption with the lower-level machine, it automatically triggers a reconnection mechanism. The reconnection mechanism employs a configurable tiered reconnection interval and performs an unlimited number of retries until the connection is restored or the system stops. During the reconnection period, the system's operating status is marked as a communication anomaly and reported.

9. A communication decoupling middleware system for radiotherapy equipment, characterized in that, include: The interface layer is used to receive read and write requests from the host computer treatment control software. The read and write requests carry predefined custom business key values ​​and return the read data or the result of the write operation. The mapping layer is used to store a pre-loaded mapping relationship dictionary, receive custom business key values ​​passed in by the interface layer, and obtain a mapping entity that uniquely corresponds to the custom business key value. The mapping entity contains at least lower-level machine physical address information and data type information. The communication layer is used to construct data read / write messages adapted to the lower-level machine communication protocol based on the lower-level machine physical address information and the data type information provided by the mapping layer, interact with the lower-level machine to perform data read / write operations, and send the results back to the mapping layer.

10. The communication decoupling middleware system for radiotherapy equipment according to claim 9, characterized in that, The system also includes an error handling layer, which is used to receive exceptions during the operation of the interface layer, mapping layer and communication layer, and to classify the exceptions. The categories include configuration anomalies, interface anomalies, communication anomalies, and data anomalies. According to the preset standard error code system, the corresponding error code and error description are generated for the anomaly, written into the log, and reported to the host computer treatment control software in real time through the status feedback interface provided by the interface layer.

Images