Flexible modular control system and radiotherapy equipment control system
By introducing a hardware abstraction layer of FPGA into the radiotherapy equipment control system, the controller and hardware are decoupled, solving the software modification problem caused by hardware changes in traditional PLC systems. This improves the system's flexibility and scalability, and supports rapid product iteration and diverse hardware adaptation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Utility models(China)
- Current Assignee / Owner
- OUR UNITED CORP
- Filing Date
- 2025-06-04
- Publication Date
- 2026-05-01
AI Technical Summary
In traditional radiotherapy equipment control systems, the hardware and software of PLCs are tightly coupled, which means that changes in hardware inevitably lead to modifications in software, increasing maintenance costs and development difficulty. This results in poor flexibility and makes it difficult to meet increasingly complex control needs and diversified product requirements.
By adopting an FPGA-based hardware abstraction layer, the controller and hardware are decoupled through the decoupling design between the FPGA and the controller and hardware. The hardware abstraction layer is built using FPGA to provide a unified hardware access interface for the flexible modular control system, supporting different hardware platforms and application scenarios.
It decouples the controller from the hardware, improves the system's flexibility and scalability, reduces development difficulty and maintenance costs, supports rapid product iteration and diverse hardware adaptation, and meets complex control requirements.
Smart Images
Figure CN224190419U_ABST
Abstract
Description
A flexible modular control system and a radiotherapy equipment control system Technical Field
[0001] This disclosure relates to the field of medical technology, and in particular to a flexible modular control system and a radiotherapy equipment control system. Background Technology
[0002] Radiotherapy is a crucial treatment for cancer, playing a vital role in local tumor control, symptom relief, and improving patients' quality of life. With increasing demands for better cancer treatment outcomes and improved quality of life, more advanced radiotherapy technologies and equipment are needed to achieve more precise and effective treatment while minimizing damage to healthy tissues.
[0003] The radiotherapy equipment control system precisely controls and coordinates the various hardware modules of the radiotherapy equipment to achieve radiotherapy functions. Traditional radiotherapy equipment control systems, as well as the control systems of each hardware component, typically use a Programmable Logic Controller (PLC) as the core controller. Traditional PLCs have tightly coupled hardware and software; hardware changes inevitably lead to software modifications, increasing maintenance costs and development complexity. Summary of the Invention
[0004] This disclosure provides a flexible modular control system and a radiotherapy equipment control system that can achieve decoupling of hardware and controller.
[0005] In a first aspect, this disclosure provides a flexible modular control system, including: a controller and a hardware functional module; the hardware functional module includes: a hardware abstraction layer constructed based on a field-programmable gate array (FPGA) and hardware corresponding to the hardware abstraction layer; the hardware abstraction layer includes the FPGA; the controller and the FPGA are connected via a first bus; the controller is used to send a first control instruction to the FPGA via the first bus; the FPGA is used to parse the first control instruction to obtain the physical address of the hardware corresponding to the first control instruction, and send a second control instruction to the hardware based on the physical address of the hardware to control the hardware to perform corresponding operations.
[0006] In some embodiments, the FPGA is also used to receive execution result data sent by the hardware, encapsulate the execution result data, and send the encapsulated execution result data to the controller via the first bus.
[0007] In some embodiments, the first bus is a real-time bus; the real-time bus includes any one of the following: EtherCAT bus for Ethernet control automation technology, CAN bus for controller area network, SERCOS bus for serial real-time communication, and Modbus bus.
[0008] In some embodiments, the hardware abstraction layer further includes a hardware input / output unit; the hardware input / output unit is connected to the FPGA via a second bus or an input / output interface; the FPGA is used to: send a second control instruction to the hardware input / output unit based on the hardware's physical address; the hardware input / output unit is used to control the hardware to perform corresponding operations based on the second control instruction.
[0009] In some embodiments, the input / output unit of the hardware is further configured to receive execution result data sent by the hardware and send the execution result data to the FPGA via a second bus; the FPGA is further configured to encapsulate the execution result data and send the encapsulated execution result data to the controller via a first bus.
[0010] In some embodiments, the second bus is a board-level bus; the board-level bus includes: a serial peripheral interface (SPI) bus or a CAN bus.
[0011] In some embodiments, the FPGA is configured with a correspondence between a first control instruction and the physical address of the hardware corresponding to the first control instruction.
[0012] In some embodiments, the FPGA is configured with a function library; the function library includes at least one of motion control function, data acquisition function, and communication protocol adaptation function; the FPGA is used to: call the function in the function library corresponding to the first control instruction, and parse the first control instruction.
[0013] In some embodiments, the FPGA is adapted to connect to multiple hardware devices; the multiple hardware devices are different forms of hardware capable of implementing the control function corresponding to the first control instruction.
[0014] In a second aspect, this disclosure also provides a radiotherapy equipment control system, comprising: a graphical user interface (GUI), a main controller, and at least one hardware control system; the hardware control system is the flexible modular control system provided in the first aspect above; the GUI and the main controller are connected via a transmission control protocol or an Internet protocol; the main controller and each hardware control system are connected via a first bus.
[0015] In some embodiments, the GUI is used to send an initial control command corresponding to a user operation to the main controller in response to a user operation; the main controller is used to receive the initial control command sent by the GUI and send a target control command to the hardware control system corresponding to the initial control command via a first bus; the hardware control system is used to receive the target control command sent by the main controller and control the hardware in the hardware control system to perform corresponding operations based on the target control command.
[0016] The flexible modular control system disclosed herein can construct a hardware abstraction layer using an FPGA, replacing the interaction method where the controller directly controls the hardware with the controller interacting with the hardware through the FPGA. The controller does not directly drive the hardware, thus achieving decoupling between hardware and software. The hardware abstraction layer is implemented using an FPGA, providing a unified hardware access interface for the flexible modular control system, enabling the flexible modular control system to flexibly adapt to different hardware platforms and application scenarios. Attached Figure Description
[0017] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:
[0018] Figure 1 is a schematic diagram of a general control system based on a PLC core controller;
[0019] Figure 2 is a schematic diagram of a flexible modular control system provided in an embodiment of this disclosure;
[0020] Figure 3 is a schematic diagram of another flexible modular control system provided in an embodiment of this disclosure;
[0021] Figure 4 is a schematic diagram of another flexible modular control system provided in an embodiment of this disclosure;
[0022] Figure 5 is a schematic diagram of a general radiotherapy equipment control system;
[0023] Figure 6 is a schematic diagram of the structure of a radiotherapy equipment control system provided in an embodiment of this disclosure;
[0024] Figure 7 is a schematic diagram of the structure of another radiotherapy equipment control system provided in an embodiment of this disclosure. Detailed Implementation
[0025] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.
[0026] In the description of this disclosure, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are used only for the convenience of describing this disclosure and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this disclosure. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," or "third" may explicitly or implicitly include one or more of the stated features. In the description of this disclosure, "a plurality of" means two or more, unless otherwise explicitly and specifically defined.
[0027] In the description of this disclosure, the term "exemplary" is used to mean "serving as an example, illustration, or description." Any embodiment described as "exemplary" in this disclosure is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this disclosure. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this disclosure can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of this disclosure with unnecessary detail. Therefore, this disclosure is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed herein.
[0028] As described in the background section, traditional radiotherapy equipment control systems and the control systems of various hardware typically use a PLC as the core controller.
[0029] For example, Figure 1 shows a schematic diagram of a general control system structure based on a PLC core controller. As shown in Figure 1, the control system based on the PLC core controller includes: a controller 101 and various types of hardware (such as type A hardware 102A and type B hardware 102B in Figure 1).
[0030] The controller 101 may include the CPU unit 111 of the PLC and the input / output unit of the PLC.
[0031] Different PLCs require different types of hardware to be compatible with their input / output units. For example, type A hardware 102A in Figure 1 requires PLC input / output unit 112A for compatibility. Similarly, type B hardware 102B requires PLC input / output unit 112B for compatibility.
[0032] The CPU unit 111 of the PLC can control the type A hardware 102A through the input / output unit 112A of the PLC, and control the type B hardware 102B through the input / output unit 112B of the PLC.
[0033] For example, assuming the above control module is the focusing head switching source control module in a radiotherapy device, when the radiotherapy device upgrades the focusing head switching source control module, it needs to use two different forms of hardware (e.g., hardware corresponding to two different behavior modes of the switching source control module or hardware corresponding to two different specific implementation methods of the switching source control module) to realize the switching source of the focusing head.
[0034] When the PLC's CPU unit 111 controls the focusing head switching source control module, the overall hardware control principle is the same for different types of focusing head switching source control modules; all of them switch the radiation source on and off. However, since different focusing head switching source control modules use different hardware forms to turn on the radiation source, the PLC's CPU unit 111 needs to adapt and control the two different types of focusing head control modules through two different sets of input / output units.
[0035] In this scenario, the PLC's CPU unit 111 needs to be pre-configured with two different sets of code (corresponding to two different types of focus head switching source control modules), increasing the difficulty and cost of PLC development. Furthermore, PLC development requires writing complex ladder diagrams or instruction list programs, resulting in a longer development cycle.
[0036] Secondly, as mentioned above, the PLC's CPU unit 111 connects to the hardware through the PLC's input / output units (including input / output (I / O) interfaces). However, the number and types of PLC input / output (I / O) interfaces are limited, making flexible expansion difficult and resulting in poor flexibility. Furthermore, because the controller 101 is tightly coupled with the hardware, changes to the hardware inevitably lead to modifications in the code within the controller 101, making modular development and verification difficult and increasing maintenance costs and development complexity.
[0037] Furthermore, due to the relatively fixed functions of the hardware and controller 101, product iteration is slow. With the development of medical technology, general-purpose technology is difficult to meet the increasingly complex control needs and diversified product requirements.
[0038] Based on this, this disclosure provides a flexible modular control system, which may include a controller and hardware functional modules. The hardware functional modules may include: a hardware abstraction layer built on a Field-Programmable Gate Array (FPGA) and the corresponding hardware of the hardware abstraction layer. The hardware abstraction layer may include an FPGA.
[0039] The controller and the FPGA are connected via a first bus; the controller is used to send a first control instruction to the FPGA via the first bus; the FPGA is used to parse the first control instruction to obtain the physical address of the hardware corresponding to the first control instruction, and send a second control instruction to the hardware based on the physical address of the hardware to control the hardware to perform the corresponding operation.
[0040] As can be seen from the above, the flexible modular control system provided in this disclosure can build a hardware abstraction layer through FPGA, replacing the interaction mode of the controller directly controlling the hardware with the controller interacting with the hardware through the FPGA, and the controller does not directly drive the hardware, thus achieving decoupling between hardware and software. Using FPGA to implement the hardware abstraction layer provides a unified hardware access interface for the flexible modular control system, enabling the flexible modular control system to flexibly adapt to different hardware platforms and application scenarios.
[0041] Figure 2 is a schematic diagram of a flexible modular control system provided in an embodiment of the present disclosure. The flexible modular control system may include a controller 201 and a hardware function module 202.
[0042] Among them, the hardware function module (also known as the hardware function stack) 202 includes: a hardware abstraction layer 203 built based on FPGA and the hardware 204 corresponding to the hardware abstraction layer.
[0043] Specifically, in order to decouple the controller 201 from the hardware 204, this disclosure can construct a hardware abstraction layer 203 based on an FPGA between the controller 201 and the hardware 204. The hardware abstraction layer 203 may include an FPGA 205.
[0044] It should be understood that FPGA 205 can create a unified communication interface for the hardware 204 corresponding to the hardware abstraction layer through standardized interface definitions, layered architecture design, and other general functions. Hardware 204 can communicate with FPGA 205 through this communication interface, instead of directly communicating with controller 201. Correspondingly, controller 201 only needs to communicate with FPGA 205, without directly communicating with hardware 204, thus achieving decoupling between controller 201 and hardware 204. Therefore, in this embodiment, controller 201 can control the hardware 204 corresponding to the hardware abstraction layer through FPGA 205 in hardware abstraction layer 203, avoiding direct control of hardware 204 by controller 201.
[0045] The controller 201 and the FPGA 205 are connected through the first bus, meaning that the controller 201 and the FPGA 205 can communicate through the first bus.
[0046] In some embodiments, the first bus described above may be a real-time bus. The real-time bus includes any one of the following: EtherCAT bus, Controller Area Network (CAN) bus, Serial Real-Time Communication Specification (SERCOS) bus, and Modbus bus.
[0047] It is understandable that the real-time bus has the characteristics of high real-time transmission. The controller 201 and FPGA 205 are connected through the real-time bus, which can improve the data (i.e. the first control instruction in this embodiment) transmission rate.
[0048] For example, the EtherCAT bus can employ distributed clock synchronization technology, achieving clock synchronization with errors accurate to the microsecond level or even smaller, thus reducing the impact of time errors on data transmission. Furthermore, the EtherCAT bus offers advantages such as high-speed communication and high bandwidth utilization, improving data transmission rates. Secondly, the EtherCAT bus supports various topologies, allowing for the selection of appropriate topologies for networking based on the actual module distribution, facilitating the connection of different types of devices.
[0049] The CAN bus offers advantages such as high reliability, multi-master communication, and low cost. The SERCOS bus can improve data transmission rates and enables hardware integration. The Modbus bus is simple to develop and easy to integrate.
[0050] Referring to the structure of the flexible modular control system shown in Figure 2, the process by which the controller 201 controls the hardware 204 through the FPGA 205 is as follows:
[0051] The controller 201 can be used to send a first control instruction to the FPGA 205 via the first bus. The FPGA 205 can be used to parse the first control instruction to obtain the physical address of the hardware 204 corresponding to the first control instruction, and send a second control instruction to the hardware 204 based on the physical address of the hardware 204 to control the hardware 204 to perform corresponding operations.
[0052] The first control instruction can be an instruction used to instruct the hardware 204 to perform a corresponding operation. For example, the first control instruction can be an instruction used to instruct the image acquisition device to perform image acquisition, or it can be an instruction to control the rotation of the frame, etc.
[0053] The controller 201 includes a CPU. The CPU is the core computing unit of the controller 201, which is used to parse the control instructions sent from the upper layer and send the parsed control instructions (i.e., the first control instructions) to the FPGA 205 through the first bus.
[0054] Since the first control instruction usually controls the hardware 204 to perform corresponding operations, after the FPGA 205 receives the first control instruction sent by the controller 201 through the first bus, it can parse the first control instruction to obtain the physical address of the hardware 204 corresponding to the first control instruction.
[0055] In some embodiments, the FPGA 205 is configured with a correspondence between the first control instruction and the physical address of the corresponding hardware. Thus, after parsing the first control instruction to obtain the specific control content, the FPGA 205 can obtain the physical address of the hardware 204 corresponding to the first control instruction through the pre-configured correspondence in the FPGA 205.
[0056] For example, suppose the first control command is to control the rack to rotate 10 degrees clockwise. The FPGA 205 can be configured with a mapping between the control commands for controlling the rack and the physical addresses of the hardware controlling the rack rotation (e.g., the drive motor). After receiving the first control command to control the rack to rotate 10 degrees clockwise, the FPGA 205 can parse the first control command to obtain the specific control content. By using the pre-configured mapping between the control commands for controlling the rack and the physical addresses of the hardware controlling the rack rotation (e.g., the drive motor) in the FPGA 205, the physical address of the hardware controlling the rack rotation (e.g., the drive motor) corresponding to the first control command can be obtained.
[0057] In some embodiments, the FPGA 205 may also be configured with a function library. This function library may include at least one of motion control functions, data acquisition functions, and communication protocol adaptation functions.
[0058] The FPGA205 can also be used to call functions in the function library corresponding to the first control instruction and parse the first control instruction.
[0059] Specifically, since different first control instructions may control different hardware functions, the FPGA205 can also be configured with a function library that includes various functions.
[0060] For example, by configuring motion control functions, the FPGA205 can quickly parse the first control commands that control the movement of the gantry / treatment bed.
[0061] For example, by configuring the data acquisition function, the FPGA205 can quickly parse the first control command for controlling the image acquisition device to acquire images.
[0062] For example, by configuring the communication protocol adaptation function, the FPGA205 can adapt to hardware and controllers with different communication protocols, thereby completing the parsing and encapsulation of the first control command.
[0063] In some embodiments, the FPGA 205 can also be adapted to connect to multiple hardware components. These multiple hardware components are different types of hardware capable of implementing the control function corresponding to the first control command.
[0064] Optionally, the aforementioned hardware in different forms can be different models, different manufacturers, or different versions of hardware.
[0065] In other words, since the control content of the first control instruction remains unchanged, and different forms of hardware capable of implementing the control function corresponding to the first control instruction can all execute that first control instruction, the FPGA205 can be adapted to connect to multiple different forms of hardware capable of implementing the control function corresponding to the first control instruction. This allows it to flexibly adapt to different hardware platforms and application scenarios, and enables rapid product iteration and the development of new products, increasing product categories and meeting market demands.
[0066] After parsing the first control instruction to obtain the physical address of the hardware 204 corresponding to the first control instruction, since the communication protocol between the controller 201 and the FPGA 205 may differ from the communication protocol between the FPGA 205 and the hardware 204, the FPGA 205 can repackage the physical address of the hardware 204 corresponding to the first control instruction and the specific control content in the first control instruction to obtain the second control instruction. Subsequently, the FPGA 205 can send the second control instruction to the hardware 204 based on the physical address of the hardware 204 to control the hardware 204 to perform corresponding operations.
[0067] After FPGA205 sends the second control command to hardware 204 based on the physical address of hardware 204, hardware 204 also needs to send back the corresponding execution result data. In this case, combined with the structure of the flexible modular control system shown in Figure 2 above, the process by which hardware 204 returns execution result data to controller 201 through FPGA205 is as follows:
[0068] After receiving the second control command, hardware 204 can execute the corresponding control operation and obtain execution result data. Then, hardware 204 can be used to send the execution result data to FPGA 205. Correspondingly, FPGA 205 is used to receive the execution result data sent by hardware 204, encapsulate the execution result data, and send the encapsulated execution result data to controller 201 via the first bus.
[0069] Optionally, the execution result data of hardware 204 can be the completion status data after the corresponding operation is completed or the relevant data obtained, such as the rack angle data obtained by rack angle acquisition or the completion status data after the rack rotation action is completed.
[0070] Optionally, when the FPGA205 sends the encapsulated execution result data to the controller201 via the first bus, it can do so via bus frames.
[0071] For example, assuming the first bus is an EtherCAT bus, the FPGA 205 can encapsulate the obtained execution result data into the corresponding EtherCAT frame and return the execution result data to the controller 201 through the EtherCAT bus.
[0072] As shown above in Figure 2, FPGA 205 can directly interact with the hardware 204 corresponding to the hardware abstraction layer 203 to control the hardware 204 to perform corresponding operations and obtain the execution result data sent by the hardware 204. In practical applications, FPGA 205 can also interact with the hardware 204 corresponding to the hardware abstraction layer 203 through the hardware input / output unit to control the hardware 204 to perform corresponding operations and obtain the execution result data sent by the hardware 204. In this case, referring to Figure 2, as shown in Figure 3, the hardware abstraction layer 203 also includes a hardware input / output unit 206; the hardware input / output unit 206 is connected to FPGA 205 through a second bus or input / output interface.
[0073] In some embodiments, since the FPGA 205 and the hardware input / output unit 206 are both integrated in the hardware abstraction layer 203, the second bus between the FPGA 205 and the hardware input / output unit 206 can be a board-level bus.
[0074] In other words, the second bus is a board-level bus; board-level buses include: Serial Peripheral Interface (SPI) bus or CAN bus.
[0075] Understandably, the SPI bus offers advantages such as simple connection, high data transmission rate, and easy expansion. The CAN bus, as a board-level bus, can improve data transmission reliability and can autonomously determine data priority through identifiers in data frames, prioritizing the transmission of higher-priority data.
[0076] In conjunction with another structure of the flexible modular control system shown in Figure 3, the process by which the controller 201 controls the hardware 204 through the FPGA 205 is as follows:
[0077] The controller 201 can be used to send a first control instruction to the FPGA 205 via a first bus. The FPGA 205 can be used to parse the first control instruction to obtain the physical address of the hardware 204 corresponding to the first control instruction, and send a second control instruction to the hardware input / output unit 206 based on the physical address of the hardware 204. The hardware input / output unit 206 is used to control the hardware to perform corresponding operations based on the second control instruction.
[0078] Optionally, when the FPGA205 is adapted to connect to multiple different types of hardware capable of implementing the control function corresponding to the first control command, the number of input / output units 206 of the hardware can also be multiple, and each of the multiple hardware units corresponds to one of them.
[0079] For example, referring to Figure 3 and as shown in Figure 4, assuming that hardware 204 includes type A hardware and type B hardware, the input / output unit 206 of the hardware may include the input / output unit of type A hardware and the input / output unit of type B hardware.
[0080] The FPGA205 is connected to the input / output units of both the Type A and Type B hardware via a board-level bus. The input / output units of the Type A hardware are connected to the Type A hardware, and the input / output units of the Type B hardware are connected to the Type B hardware.
[0081] After FPGA205 sends the second control command to the input / output unit 206 of hardware 204 based on the physical address of hardware 204, hardware 204 also needs to return the corresponding execution result data. In this case, combined with another structure of the flexible modular control system shown in Figure 3 above, the process of hardware 204 returning execution result data to controller 201 is as follows:
[0082] Hardware 204 can be used to send execution result data to hardware input / output unit 206. Correspondingly, hardware input / output unit 206 is used to receive execution result data sent by hardware 204 and send execution result data to FPGA 205 via a second bus. Correspondingly, FPGA 205 is also used to encapsulate the execution result data and send the encapsulated execution result data to controller 201 via a first bus.
[0083] Specifically, after receiving the execution result data, hardware 204 can send the execution result data back to the corresponding hardware input / output unit 206 through the input / output interface. The hardware input / output unit 206 can then send the data back to FPGA 205 through the second bus or the input / output interface. FPGA 205 can then encapsulate the received execution result data (e.g., encapsulate it into an EtherCAT data frame) and send the encapsulated data back to controller 201 through the first bus (e.g., the EtherCAT bus).
[0084] In summary, the core data path between controller 201 and hardware 204 is as follows: controller 201 (also known as EtherCAT master, PC) - real-time bus (e.g., EtherCAT bus) - FPGA 205 (also known as EtherCAT slave) - board-level bus (e.g., SPI bus or CAN bus) - hardware 204 (also known as peripheral unit). Based on this core data path, if hardware 204 changes, but its corresponding control logic remains unchanged, the configuration code of controller 201 will not be affected.
[0085] For example, assuming hardware 204 is a position sensor, the control data corresponding to the position sensor is a displacement. Therefore, when FPGA 205 sends the packaged execution result data to controller 201, it only needs to transmit the displacement acquired by the position sensor.
[0086] During use, the driving method of the position sensor may change (for example, from the ENDATA protocol to the SSI protocol). However, regardless of the driving method used by the position sensor, the control data that needs to be transmitted is still the displacement value acquired by the position sensor. Therefore, the controller 201 does not need to be redeveloped; only some hardware driver changes need to be made to the underlying function stack, thus enabling the overall development work to be completed quickly.
[0087] In other words, unlike traditional PLCs, the flexible modular control system provided in this disclosure does not require corresponding code adaptation changes when hardware configurations change. In this disclosure, the controller 201 only needs to focus on the actual control logic of the hardware 204, and no longer needs to be compatible with the code corresponding to different hardware configurations. Therefore, the flexible modular control system provided in this disclosure can achieve decoupling between the controller 201 and the hardware 204, enabling the flexible modular control system to flexibly adapt to different hardware platforms and application scenarios, thus improving the flexibility of the flexible modular control system.
[0088] Furthermore, the board-level bus enables expansion between the FPGA205 and the hardware 204, allowing users to add or remove hardware 204 according to actual needs. This means that hardware upgrades and different hardware configurations can be performed without changing the overall functional flow, thereby enhancing the scalability of the flexible modular control system.
[0089] Secondly, the embodiments disclosed herein can also improve the reliability and stability of the flexible modular control system by modularizing the controller 201, FPGA 205 and hardware 204, thereby achieving rapid product iteration, increasing product categories and meeting market demands.
[0090] The above describes a flexible modular control system, which can be applied to radiotherapy equipment control systems (also known as complete systems). For example, Figure 5 shows a schematic diagram of a general radiotherapy equipment control system structure. As shown in Figure 5, the general radiotherapy equipment control system adopts a three-layer architecture design, including: a graphical user interface (GUI) layer 501, a control layer 502, and a subsystem layer (also known as a hardware control system layer) 503.
[0091] The GUI layer 501 may include a Treatment Control System (TCS) client 5011 and a TCS server 5012.
[0092] The TCS client 5011 is a client with a graphical user interface. This graphical user interface can be used to provide a visual interactive service between the radiotherapy equipment control system and the user.
[0093] Of course, the TCS client 5011 can also provide users with service functions related to system business logic, quality assurance (QA) functions to ensure the control quality of radiotherapy equipment control systems, clinical application functions for processing medical clinical data or related business, administrator functions for system operation, such as user management and permission settings, autoregistration module functions for automatic registration and other related operations, view functions for displaying data to users, configuration functions for configuring parameters of radiotherapy equipment control systems, view model functions for connecting views and models and processing view-related business logic, model functions for processing business data and business logic, socket functions for network communication to realize data transmission between different components or systems, image processor communication interface (Comm.With Image processor) functions for interacting with image processors, and digital imaging and communications in medicine (Dicom) functions for processing medical image-related data communication.
[0094] The control layer 502 may include a main controller (RTC), such as the rack-mount controller (ON-RTC) 5021 and the rack-off controller (OFF-RTC) 5022 shown in FIG. 5. The rack-mount controller 5021 and the rack-off controller 5022 may be communicatively connected (e.g., via industrial Ethernet protocols such as EtherCAT).
[0095] Both the rack-mount controller 5021 and the rack-under controller 5022 can provide interfaces for communication with the TCS client 5011 via Transmission Control Protocol (TCP) or Internet Protocol (IP), so that the TCS client 5011 can communicate with the rack-mount controller 5021 and the rack-under controller 5022 via TCP or IP respectively.
[0096] The rack-mount controller 5021 and the rack-less controller 5022 may also include a finite state machine (FSM) for controlling the controllers, as well as an Ethernet for Control Automation Technology (EtherCAT Map) topology to ensure accurate transmission of control commands.
[0097] Subsystem layer 503 includes multiple subsystems, such as the Beam Scanning Module (BSM) 5031, Beam Generation Module (BGM) 5032, Image Guidance System (IGS) 5033, Respiratory Gating System (RGS) 5034, Gantry Steering Module (GSM) 5035, and Patient Support System (PSS) 5036 shown in Figure 5.
[0098] The system includes the following components: a beam scanning system 5031, which controls the radiotherapy beam to scan a specific area of the patient's body; a beam generation system 5032, which generates the high-energy beam required for radiotherapy and can precisely control parameters such as beam energy, intensity, and particle type according to different treatment needs (e.g., different tumor types, locations, and sizes); an image guidance system 5033, which acquires real-time images of the patient during treatment to allow for timely adjustments to the treatment plan; a respiratory gating system 5034, which tracks the patient's respiratory rate to accurately locate the target, reducing radiotherapy side effects while achieving better treatment outcomes; a gantry control system 5035, which controls the movement of the radiotherapy equipment gantry, including rotation and tilting; and a patient support system 5036, which is responsible for the patient's positioning and support during radiotherapy, ensuring the patient maintains a stable and accurate position.
[0099] The above subsystems can be connected to the rack-mount controller 5021 or the rack-side controller 5022 via the EtherCAT bus.
[0100] Specifically, the rack-mounted controller 5021 is connected to the beam scanning system 5031 and the respiratory gating system 5034, respectively. The image guidance system 5033 can be connected to the beam generation system 5032 and the respiratory gating system 5034, respectively. The under-rack controller 5022 is connected to the rack control system 5035 and the patient support system 5036, respectively.
[0101] Each of the above subsystems includes a business layer and a hardware abstraction layer. The business layer may include sub-controllers for each subsystem to control the corresponding hardware.
[0102] Optionally, sub-controllers can be deployed in the form of an FSM.
[0103] Optionally, the business layer may also include an EtherCAT Map. The EtherCAT Map is used to map the topology information of the subsystems or controllers that need to be connected.
[0104] The hardware abstraction layer may include I / O interfaces. Each subsystem can connect to corresponding hardware through the I / O interfaces in the hardware abstraction layer, including: beam scanning hardware (such as a beam generator) connected to the beam scanning system 5031, beam generation hardware (such as a beam switch) connected to the beam generation system 5032, image guidance hardware (such as an image acquisition device) connected to the image guidance system 5033, respiratory gating hardware (such as a heart rate monitoring device) connected to the respiratory gating system 5034, a gantry connected to the gantry control system 5035, and patient support hardware (such as a treatment bed) connected to the patient support system 5036.
[0105] It can be seen that in general technology, the controller in the business layer can communicate directly with the hardware through the I / O interface in the hardware abstraction layer, resulting in high coupling between the controller and the hardware, making it difficult to expand the subsystem and resulting in poor flexibility.
[0106] To address the aforementioned issues, this disclosure provides a radiotherapy equipment control system, as shown in Figure 6. The radiotherapy equipment control system includes a GUI 601, a main controller 602, and at least one hardware control system. The hardware control system is a flexible modular control system provided in any of Figures 2-4 above.
[0107] The GUI 601 is connected to the main controller 602 via TCP or IP; the main controller 602 is connected to each hardware control system via a first bus. In this way, the main controller 602 can adapt to the same or different hardware control systems via the first bus to meet ever-changing market demands.
[0108] In some embodiments, the GUI 601 is used to send an initial control command corresponding to a user operation to the main controller 601 in response to a user operation. The main controller 602 is used to receive the initial control command sent by the GUI 601 and send a target control command to the hardware control system corresponding to the initial control command via a first bus. The hardware control system is used to receive the target control command sent by the main controller 602 and control the hardware in the hardware control system to perform corresponding operations based on the target control command.
[0109] Optionally, the main controller 602 may include an on-rack controller 6021 and an off-rack controller 6022.
[0110] The GUI 601 and main controller 602 in Figure 6 can be referred to the relevant descriptions of the GUI layer 501 and control layer 502 in Figure 5, which will not be repeated here.
[0111] Optionally, as shown in Figure 6, at least one hardware control system may include: a beam scanning system 603, a beam generation system 604, an image guidance system 605, a respiratory gating system 606, a gantry control system 607, and a patient support system 608.
[0112] As can be seen, in the hardware control system shown in Figure 6, in addition to the sub-controllers in the same business layer as in Figure 5 and the I / O interfaces in the hardware abstraction layer, the hardware control system also includes an FPGA in its hardware abstraction layer. The FPGA and its corresponding sub-controller are connected through a first bus. Thus, this embodiment of the present disclosure can replace the interaction method where the sub-controller directly controls the hardware in the hardware control system with the sub-controller interacting with the hardware through the FPGA, while the sub-controller does not directly drive the hardware. This achieves decoupling between the hardware and the sub-controller, enabling the hardware control system to flexibly adapt to different hardware platforms and application scenarios.
[0113] Optionally, sub-controllers can be deployed in the form of an FSM.
[0114] Optionally, the business layer may also include an EtherCAT Map. The EtherCAT Map is used to map the topology information of the subsystems or controllers that need to be connected.
[0115] Optionally, as shown in Figure 6, the radiotherapy equipment control system may further include an image manager 609. The image manager 609 is used to display real-time images acquired by the hardware in the image guidance system 605. In this case, the image manager 609 can communicate with the hardware (e.g., image detector) of the image guidance system 605 via an I / O interface.
[0116] Optionally, the image manager 609 can also connect to the hardware interface in the image boot system 605 via the Modbus communication protocol.
[0117] Optionally, the image manager 609 can also communicate with the GUI 601 via TCP / IP. It should be noted that, as shown in Figure 6, the hardware abstraction layer in each of the above hardware control systems can be decoupled from the business layer (including the controller of the hardware control system) in the hardware control system, thereby completely separating the business layer and the hardware logic layer in the hardware control system. The EtherCAT bus is used as the communication method between the two, ensuring that changes to the hardware do not affect changes to the business layer code.
[0118] For radiotherapy equipment control systems, the flexibility of hardware control systems allows for richer product configurations and faster research and development.
[0119] It should be noted that the radiotherapy equipment control system provided in this disclosure is not limited to the various hardware control systems shown in FIG6. In this case, FIG7 shows a schematic diagram of another radiotherapy equipment control system provided in this disclosure, which includes: a GUI 701, a main controller 702, and at least one hardware control system. The hardware control system is a flexible modular control system provided in any of FIG2-4 above.
[0120] The GUI701 is used to acquire user control requirements. The main controller 702 is used for coordinated management and control of the overall workflow of the radiotherapy equipment control system.
[0121] The descriptions of GUI701 and main controller 702 in Figure 6 can be found in Figure 6 and will not be repeated here.
[0122] At least one hardware control system may include hardware control system 1, hardware control system 2, ..., hardware control system N. Each hardware control system may include a sub-controller and a hardware abstraction layer. The sub-controller in the hardware control system can connect to the corresponding hardware through the hardware abstraction layer. This hardware abstraction layer is built based on FPGA and includes the FPGA.
[0123] For example, sub-controller 1 in hardware control system 1 can be connected to the corresponding hardware 1 through the hardware abstraction layer, sub-controller 2 in hardware control system 2 can be connected to the corresponding hardware 2 through the hardware abstraction layer, and so on. Sub-controller N in hardware control system N can be connected to the corresponding hardware N through the hardware abstraction layer.
[0124] For a description of the sub-controller and hardware abstraction layer, please refer to the description of the controller and hardware abstraction layer in the above flexible modular control system. It will not be repeated here.
[0125] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.
Claims
1. A flexible modular control system, characterized in that, include: Controller and hardware functional modules; The hardware functional module includes: a hardware abstraction layer built on a field-programmable gate array (FPGA) and hardware corresponding to the hardware abstraction layer; the hardware abstraction layer includes the FPGA; the controller is connected to the FPGA via a first bus; the controller is used to send a first control instruction to the FPGA via the first bus; the FPGA is used to parse the first control instruction to obtain the physical address of the hardware corresponding to the first control instruction, and send a second control instruction to the hardware based on the physical address of the hardware to control the hardware to perform corresponding operations.
2. The system according to claim 1, characterized in that, The FPGA is also used to receive execution result data sent by the hardware, encapsulate the execution result data, and send the encapsulated execution result data to the controller through the first bus.
3. The system according to claim 1, characterized in that, The first bus is a real-time bus; the real-time bus includes any one of the following: EtherCAT bus for Ethernet control automation technology, CAN bus for controller area network, SERCOS bus for serial real-time communication, and Modbus bus.
4. The system according to claim 1, characterized in that, The hardware abstraction layer also includes a hardware input / output unit; the hardware input / output unit is connected to the FPGA via a second bus or an input / output interface; the FPGA is used to: send the second control instruction to the hardware input / output unit based on the physical address of the hardware; the hardware input / output unit is used to control the hardware to perform corresponding operations based on the second control instruction.
5. The system according to claim 4, characterized in that, The input / output unit of the hardware is also used to receive execution result data sent by the hardware and send the execution result data to the FPGA via the second bus; the FPGA is also used to encapsulate the execution result data and send the encapsulated execution result data to the controller via the first bus.
6. The system according to claim 4, characterized in that, The second bus is a board-level bus; the board-level bus includes: a serial peripheral interface (SPI) bus or a CAN bus.
7. The system according to claim 1, characterized in that, The FPGA is configured with a correspondence between the first control instruction and the physical address of the hardware corresponding to the first control instruction.
8. The system according to claim 1, characterized in that, The FPGA is configured with a function library; the function library includes at least one of motion control function, data acquisition function, and communication protocol adaptation function; the FPGA is used to: call the function in the function library corresponding to the first control instruction, and parse the first control instruction.
9. The system according to claim 1, characterized in that, The FPGA is adapted to connect to multiple hardware devices; the multiple hardware devices are different forms of hardware capable of implementing the control function corresponding to the first control command.
10. A radiotherapy equipment control system, characterized in that, include: The system comprises a graphical user interface (GUI), a main controller, and at least one hardware control system; the hardware control system is a flexible modular control system as described in any one of claims 1-9; the GUI and the main controller are connected via a transmission control protocol or an Internet protocol; the main controller is connected to each hardware control system via a first bus.
11. The system according to claim 10, characterized in that, The GUI is used to respond to user operations by sending an initial control command corresponding to the user operation to the main controller; the main controller is used to receive the initial control command sent by the GUI and send a target control command to the hardware control system corresponding to the initial control command through the first bus; the hardware control system is used to receive the target control command sent by the main controller and control the hardware in the hardware control system to perform corresponding operations based on the target control command.