Plasma control system configuration parameter distribution method

Abstract

The invention relates to the technical field of plasma control of a nuclear fusion Tokamak device, in particular to a plasma control system configuration parameter distribution method. According to the technical scheme, the method comprises the following steps: deploying parameter analysis plug-ins of an auxiliary component and an algorithm component at a real-time node, wherein the auxiliary component and the algorithm component interact through a shared memory; and in the discharge preparation stage, the auxiliary component acquires configuration parameters from the configuration parameter management component of the main node, the parameter analysis plug-in of each algorithm component performs parameter preloading, and the parameter analysis plug-in performs real-time parameter analysis in the discharge control stage. According to the method, memory occupation and time consumption of configuration parameter distribution are remarkably reduced, and the mass parameter management requirement of long-pulse operation is met; through shared memory communication and a preloading mechanism, high real-time performance of the system is guaranteed, and sufficient time margin is reserved for algorithm operation; in combination with dynamic parameter analysis and modular design, flexible expansion of algorithm components and dynamic switching of control strategies are supported, and resources are prevented from being occupied by redundant parameters.

Description

Technical Field

[0001] The present invention relates to the technical field of nuclear fusion tokamak device plasma control, and in particular to a method for distributing configuration parameters of a plasma control system. Background Art

[0002] Nuclear fusion tokamaks (such as BEST, CFETR, and ITER) are important experimental devices for achieving long-pulse steady-state fusion energy. The plasma control system is the core control system of the tokamak nuclear fusion experiment. During the experiment, the plasma control system collects plasma state data in real time, executes control algorithms based on configuration parameters, and calculates control commands to achieve discharge control of the nuclear fusion experiment.

[0003] like Figure 1 As shown, the plasma control system hardware deployment adopts a cluster model, consisting of one master node server and at least one real-time node server. Nuclear fusion discharge experiments are conducted on a "shot" basis. Before each shot discharge begins, operators configure parameters through a human-computer interface (hereinafter referred to as the interface) deployed on the master node server. The configuration parameter management (CS) component provides data management services. These configuration parameters are ultimately applied to the real-time node algorithm execution and control during the discharge process.

[0004] System configuration parameter distribution is an indispensable component of the plasma real-time control system. However, it faces the following challenges in system implementation:

[0005] First, the goal of nuclear fusion experiments is long-pulse or even steady-state operation. The next-generation plasma control system needs to support long-pulse steady-state operation. Long-pulse operation requires a larger amount of data for system configuration parameters. Therefore, configuration parameter distribution needs to consider system memory limitations during long-pulse operation.

[0006] Second, the shortest control cycle of the algorithm in the plasma control system is 100 microseconds, which includes the time to obtain the current configuration parameters, logical operations, and current data archiving. Therefore, the distribution and acquisition of configuration parameters must have high enough real-time performance to leave sufficient time margin for subsequent operations.

[0007] Third, the control algorithm of the plasma control system is adjusted according to the real-time operating status of the plasma, so the configuration parameters of the algorithm also need to dynamically adjust the parameter items that need to be analyzed according to the algorithm operation requirements of the system.

[0008] The above three requirements are not independent, but rather interrelated and constrained. The distribution of configuration parameters requires a comprehensive solution among the three to obtain a real-time distribution and deployment solution for plasma control system configuration parameters that meets these requirements. Therefore, this application proposes a method for distributing plasma control system configuration parameters. Summary of the Invention

[0009] The purpose of the present invention is to propose a plasma control system configuration parameter distribution method in response to the background technology that needs to take into account high real-time performance, low memory usage and dynamic expansion capability, so as to meet the core requirements of long-pulse operation of future nuclear fusion devices.

[0010] The technical solution of the present invention is a method for distributing configuration parameters of a plasma control system, comprising the following steps:

[0011] Deploy the auxiliary component (Support) and the parameter parsing plug-in of the algorithm component on the real-time node. The auxiliary component (Support) and the algorithm component interact through shared memory;

[0012] During the discharge preparation phase, the configuration parameter management component of the master node broadcasts the gun number to the auxiliary component through the publish-subscribe mechanism. The auxiliary component sends a configuration parameter request to the configuration parameter management component. The configuration parameter management component generates a configuration parameter data packet in JSON format based on the request and returns it to the auxiliary component, which then stores it in shared memory.

[0013] The shared memory of each algorithm component and auxiliary component is named with the logical CPU identifier and is managed in a queue manner. After the algorithm component parameter parsing plug-in detects the parameter ready command in the shared memory queue, it loads the shared memory configuration parameters into the local memory configuration parameter management structure.

[0014] In the discharge control stage, the parameter parsing plug-in traverses the configuration parameter management structure (WaveformManager), dynamically determines the activated control sequence (Sequence) and control phase (Phase), and calculates the current parameter value based on the vertex value pair (t, y) interpolation.

[0015] Optionally, the interface data structure between the configuration parameter management component and the auxiliary component is defined by an interface description language, and the interface description language generates a cross-platform data serialization code.

[0016] Optionally, the communication content of the shared memory message queue is a Command object, and the Command object includes:

[0017] Type field: identifies the command category, including parameter data packet ready commands and control instructions;

[0018] Length field: indicates the size of the data payload in bytes;

[0019] Source field: marks the logical CPU ID of the command initiator;

[0020] Data payload: Pointer to the configuration parameter data packet in shared memory.

[0021] Optionally, the configuration parameter management structure (WaveformManager) is divided into a hierarchical structure according to control items (Category), specifically including:

[0022] Category: manages multiple control sequences using a hash table and records the currently active control sequence.

[0023] Control sequence: multiple control phases are associated through a linked list, and each control phase contains a Vertex array at the execution time;

[0024] Control Phase: Binds a unique algorithm and its configuration parameters. The configuration parameters are stored as vertex value pairs (t, y). Data between vertices is generated by interpolation. The interpolation methods include static hold, step hold, or linear interpolation.

[0025] Optionally, in the discharge control stage, the time timing method for real-time parameter analysis includes:

[0026] Absolute timing: based on the discharge start time, the global time starts to accumulate from -9 seconds;

[0027] Relative timing: The algorithm startup time is taken as time 0, and is used for local timing when the algorithm's internal state switches.

[0028] Optionally, during the real-time parameter parsing process, only the configuration parameters corresponding to the currently activated Algorithm are parsed, and the parameters of the inactivated algorithms are retained in the shared memory to avoid redundant data occupying the local memory.

[0029] Optionally, the shared memory message queue adopts a full-duplex communication mechanism, specifically using an independent read buffer and write buffer for bidirectional data transmission, and the buffer cyclically manages queue elements through a head pointer and a tail pointer.

[0030] Optionally, the configuration parameters include:

[0031] Algorithm scheduling scheme: Dynamically switch control strategies by setting the time execution combination of control items (Category);

[0032] Plasma control target parameters: defined in the form of waveform data, including plasma current, shape and density parameters.

[0033] Optionally, the interpolation calculation of the vertex value pair (t, y) is specifically as follows:

[0034] Static hold: the y value remains unchanged throughout the discharge cycle;

[0035] Step hold: The y value remains at the previous vertex value before time t until the next vertex takes effect;

[0036] Linear interpolation: According to the formula of adjacent vertex values:

[0037]

[0038] Calculate the current time y value, where y is the configuration parameter value at the current time t, y m is the parameter value of the mth vertex, y m-1 is the parameter value of the m-1th vertex, t m is the time point of the mth vertex, t m-1 is the time point of the m-1th vertex.

[0039] Optionally, the naming rule of the shared memory message queue is "shm.rt.cpuID.command", where cpuID is the logical CPU number bound to the algorithm component, and the message queues corresponding to different cpuIDs are physically isolated.

[0040] Compared with the prior art, this application has at least one of the following beneficial technical effects:

[0041] Through the "overall transmission, real-time analysis" mode, only necessary parameters are loaded and dynamically analyzed, which significantly reduces memory usage and adapts to the massive data processing needs of long pulse operation.

[0042] The shared memory communication and preloading mechanism is adopted to reduce the time consumption of parameter distribution, ensure the time margin within the algorithm control cycle, and meet the real-time requirement of 100 microseconds.

[0043] It supports algorithm components to parse parameters on demand and dynamically switch control strategies to avoid redundant parameters occupying resources and improve system flexibility and responsiveness.

[0044] By decoupling the Support component and the algorithm component, the subsequent algorithm expansion process is simplified. There is no need to reconstruct the core distribution logic when adding new algorithms, which enhances the maintainability of the system.

[0045] Based on IDL definition interface and JSON format transmission, it ensures the consistency of data protocol between the master node and the real-time node, reducing the risk of communication errors.

[0046] The present invention significantly reduces the memory usage and time consumption of configuration parameter distribution through the "overall transmission, real-time analysis" mode, meeting the massive parameter management needs of long pulse operation; through shared memory communication and preloading mechanism, it ensures the high real-time performance of the system, leaving sufficient time margin for algorithm calculation; combined with dynamic parameter analysis and modular design, it supports flexible expansion of algorithm components and dynamic switching of control strategies, avoiding redundant parameters occupying resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 This is the hardware architecture diagram of the plasma control system;

[0048] Figure 2 Diagram for the division of discharge phase;

[0049] Figure 3 Deployment diagram for configuration parameters;

[0050] Figure 4 This is the parameter transmission timing diagram;

[0051] Figure 5 Design diagram for shared memory message queue structure;

[0052] Figure 6 Management structure diagram for configuration parameters;

[0053] Figure 7(a) shows the target parameter waveform of the IP current set in the limited algorithm interface of the shape configuration control directory;

[0054] FIG7( b ) is a waveform diagram of the plasma current IP target parameter analyzed in real time during the discharge process;

[0055] Figure 8 Provide time statistics for experimental gun parameter analysis service;

[0056] Figure 9 This is the memory change curve of the 25-hour simulation experiment system. DETAILED DESCRIPTION

[0057] The technical solution of the present invention is further described below with reference to the accompanying drawings and specific embodiments.

[0058] Example

[0059] The present invention proposes a method for distributing configuration parameters of a plasma control system, which is described in detail below.

[0060] The nuclear fusion discharge experiment is carried out in units of "shots", and each shot fusion experiment runs within the set time. After starting, the plasma control system controls each shot experiment cyclically, such as Figure 2The corresponding system operation can be divided into the following stages, namely the inter-shot stage before the start of discharge, the discharge preparation stage after the system receives the shot signal, and the formal discharge control stage after receiving the discharge start trigger. In this stage, each algorithm component runs cyclically until the discharge ends and returns to the inter-shot stage to wait for the next discharge.

[0061] Discharge parameters are configured through the master node's human-computer interface during the inter-shot phase before the next shot begins. This configuration encompasses two aspects: the system's algorithm scheduling scheme and the target plasma control parameters. The goal of this invention is to distribute master node configuration parameters to real-time node algorithm components while ensuring system real-time performance and long-pulse operation requirements. These parameters are ultimately applied to the execution of the real-time node's algorithms during the discharge control phase.

[0062] (1) System deployment

[0063] To achieve the above functions, the system structure of the present invention is deployed as follows Figure 3 shown.

[0064] (1) Deploy auxiliary components (hereinafter referred to as Support) in real-time nodes to achieve unified acquisition of all configuration parameters from the main node. The reason for this deployment is to ensure the real-time performance of each algorithm component and reduce its unnecessary workload. Second, as the "general manager" component of the real-time node, Support is easier to obtain the timing of parameter transmission, and because it has no real-time requirements and fewer restrictions, it can deploy flexible and diverse data communication methods. Third, each algorithm component and between the algorithm component and Support run independently, which eliminates the coupling relationship between modules. Therefore, when adding algorithms later, there is no need to add or change the logic of Support, thereby ensuring the scalability of configuration parameter distribution.

[0065] (2) Deploy parameter parsing plug-ins in each algorithm component of the real-time node to implement the organization and parsing services of the configuration parameters of each algorithm component.

[0066] (3) The Support component and each algorithm component perform efficient data interaction through shared memory (SHM).

[0067] (2) Process design

[0068] To ensure the real-time performance of the discharge control stage and support long pulse operation, the implementation of this process is divided into three parts: "parameter package transmission" and "parameter preloading" in the discharge preparation stage, and "parameter parsing" in the discharge control stage.

[0069] 1. Parameter transfer (CS→Support)

[0070] Parameter transfer refers to the process of transferring configuration parameters from the master node to the real-time nodes. After parameters are set on the master node interface, they are managed by the configuration server (CS). On the real-time nodes, the support node is responsible for receiving the configuration parameters. Therefore, configuration parameter transfer is an interactive process between the master node CS and the real-time node support.

[0071] Parameter data packet content

[0072] Configuration parameters include the user's settings for the algorithm scheduling scheme for the system's planned operation, plasma expected performance parameters, etc. The setting of the algorithm scheduling scheme is implemented based on the organizational structure of the system control. The system control content is divided into multiple control items (hereinafter referred to as Category), and each Category is composed of multiple algorithms (hereinafter referred to as Algorithm) that implement different control functions. In the parameter configuration stage, the algorithm execution combination of each control item (hereinafter referred to as Category) in the time dimension is set, and the algorithm scheduling is implemented in combination with the algorithm configuration parameters. In order to achieve the above-mentioned algorithm combination and configuration parameter combination, two levels are deployed between Category and Algorithm: control sequence (hereinafter referred to as Sequence) and control segment (hereinafter referred to as Phase). Phase is a combination of an algorithm and its set of specific configuration parameters, and Sequence is the execution sequence of different Phases in the time dimension. By configuring multiple different Sequences, each Category can execute different control strategies under different plasma states.

[0073] It should be noted that the interface parameter configuration does not set the data at all times, but only sets the key vertex value pairs (including time t and data value y) when the data changes. The data at each moment between vertices is obtained by interpolation. Therefore, CS does not store parameter data at all times, but only stores relevant information such as data vertex values ​​and data types.

[0074] Parameter transmission communication protocol

[0075] Data transmission between Support component and CS component:

[0076] The publish-subscribe mechanism is used for transmission to ensure the timeliness of data transmission and processing.

[0077] JSON is used as the data transmission format. It is universal, readable and flexible. Its universality enables it to exchange data between multiple programming languages ​​and platforms. Its readability and flexibility make the data exchange process more intuitive and easy to handle.

[0078] Use IDL to define the interface data structure between systems to ensure the consistency of the communication interface between the two servers.

[0079] Parameter transmission process

[0080] In order to ensure the real-time operation of the system during the discharge process, the "parameter transmission" opportunity is deployed in the preparation stage before the start of discharge. Figure 3 As shown, it includes the following three steps:

[0081] ① Data Ready: The system workflow engine (Workflow) publishes the shot number information to the CS. The CS component binds the configuration parameter data packet to the shot number and broadcasts a "Data Ready" message with the shot number to the Support component through the publish-subscribe communication mechanism. Upon receiving the message, the Support component writes the shot number to the system common memory and responds with a confirmation message.

[0082] ② Configuration Parameter Request: During system startup, the system loads the algorithm component's Category information into a list in the system's public memory. Support traverses the list, composing a message with the parameter information "rtCsRequest" (including the gun number, the current algorithm component's logical CPU number, and the current component's Category list), and then issues a parameter request message to the CS. Support requests configuration data for all algorithm components from the CS in a non-blocking manner.

[0083] ③ Configuration parameter acquisition: CS composes a response message based on the Category information list in the configuration parameter request message and returns it to Support. Support obtains the response message in parallel using a callback function and stores it in a specific shared memory area based on the CPU number corresponding to the message.

[0084] 2. Parameter preloading (Support→Algorithm component)

[0085] To ensure real-time parameter parsing during the discharge control phase, the system preloads all configuration parameters before discharge, enabling rapid parameter parsing during each discharge cycle. Parameter preloading involves loading configuration parameter data packages stored in shared memory into the memory of each algorithm component. Parameter preloading is implemented by parameter parsing plug-ins deployed on each algorithm component, and involves two processes: transferring data packages to shared memory and loading parameter data into the algorithm component.

[0086] (1) Parameter data shared memory transmission

[0087] The parameter parsing plug-in of each algorithm component and Support use a shared memory-based message queue mechanism to achieve full-duplex communication. To distinguish algorithm components, the shared memory is named "shm.rt.cpuID.command", where cpuID is the logical CPU identifier of each algorithm component. It is managed by a custom data structure Communication. Its structure design is as follows: Figure 5 Included are:

[0088] Command Queue: This area is used to store data queues. It is managed as a Command array in the data structure, where the communication content is carried out by the Command objects in the queue. The Command data structure contains type (Command type), length (Command size), source (Command issuer), and payload (Command accompanying data).

[0089] Head pointer front: points to the first element in the queue, and the record format is the Command array element index.

[0090] Tail pointer tail: points to the next position of the last element of the queue, and the record format is the Command data element subscript.

[0091] Support stores the configuration parameter data packet in the corresponding "shm.rt.cpuID.command" shared memory area according to the cpuID. Each algorithm component cyclically checks the shared memory queue. When the Command element type popped out of the queue is the parameter data packet ready command (RT_CMD_SHOT_START_REQ), it obtains the parameter data packet payload pointer of the Command. Each algorithm component enters the running state and drives the local loading of parameter data.

[0092] (2) Algorithm component parameter data loading

[0093] The purpose of local loading of parameter data is to load the parameter data package of shared memory into the memory data structure of the algorithm component so as to quickly obtain the algorithm configuration parameters at the corresponding moment when the system is running. Figure 6 As shown in Figure 1, the configuration parameters of the algorithm components are organized and managed by the tree-structured Waveform-Manager to achieve flexible and diverse control functions. Therefore, the process of loading algorithm component parameters is the process of the parameter parsing plug-in filling the WaveformManager objects layer by layer from top to bottom based on the shared memory configuration parameter data package.

[0094] The WaveformManager is organized into categories. A category contains multiple control sequences, each containing all phases and an array of vertices at the time of each phase's execution. A phase carries a unique execution algorithm, called an Algorithm, and its configuration parameters to implement a specific function. Configuration parameters are composed of multiple Waveforms, each managed by its own function within a subset of parameter data sets. Each Waveform itself consists of multiple consecutive Vertex values, each containing a pair representing the moment a data change occurred (time t and data value y). In the WaveformManager structure, parent elements in the previous layer are managed as a map of their child elements. Sibling elements in the same layer are linked together in a linked list for quick lookup. For example, Waveform and Vertex contain pointers to the next sibling element. Furthermore, each parent element records the currently active child element, such as the currently active Sequence in the Category and the currently active Phase in the Sequence.

[0095] 3. Real-time parameter analysis

[0096] The data preloaded into the memory are only the vertex values ​​of the configuration parameters. These data need to be further deduced from the configuration data of the algorithm at the corresponding moment (i.e. parameter analysis) before they can be applied to the algorithm operation. If only from the real-time perspective, parameter analysis can be pre-interpolated before the start of discharge control. However, since the system needs to be suitable for long pulses or even steady-state operation, storing a large number of parameters in the memory in advance will result in huge memory usage. In addition, given that the algorithm run by the system is switched and adjusted according to the real-time state of the plasma, the configuration parameters are redundant settings, and not all algorithm configuration parameters will eventually be used for discharge control. Parameter pre-analysis will cause unnecessary memory consumption. Therefore, the parameter real-time analysis mode is adopted in this scheme, that is, according to the vertex value of the configuration parameters of the algorithm being run, the configuration parameter y value at the current running moment is analyzed and updated for subsequent algorithm logic operations.

[0097] In each run cycle, the parameter parsing plug-in traverses the Category of the current algorithm component WaveformManager one by one and performs the following three steps:

[0098] (1) Determine the sequence executed by the current category: The system dynamically requests different control sequences from each category based on the plasma operating state. The WaveformManager's Category records the currently active sequence information. By comparing the active sequence with the current system request, the system determines whether to switch to a new sequence.

[0099] (2) Determine the phase in the execution sequence: Determine whether to switch to the next execution phase based on the current running time of the system

[0100] (3) Determine the values ​​of all configuration parameters of the Phase algorithm at the current moment: All Vetex arrays (t1, y1),…, (tn, yn) with data items are recorded in the Waveform. The system determines the relevant Vetex to be selected based on the current running time and derives the y value of the data item at the current moment through Vetex. The y value derivation is divided into two steps:

[0101] Select the corresponding vertex value based on t: There are two ways to select t. The default is to use the discharge start time as -9 seconds for timing, called absolute timing. The other method uses the algorithm entry time as time 0, called relative timing, which is often used for secondary switching algorithm timing. After determining t, the selected vertex value can be confirmed.

[0102] Derivation of y value from vertex value based on data type: data type is set when defining data. There are three types: static data, i.e., y value remains unchanged throughout the process; step data, i.e., the y value before time t remains unchanged until the next vertex value arrives; waveform data, i.e., the two vertex values ​​before and after time t (t m-1 ,y m-1 )(t m-1 ,y m-1 ) Linear interpolation is obtained:

[0103] y=(y m -y m-1 )(tt m-1 ) / (t m -t m-1 )+y m-1 .

[0104] Experimental verification

[0105] The plasma control system equipped with this configuration parameter distribution scheme currently deploys 16 algorithm components, 13 of which require configuration parameter distribution. The system has been used in more than 1,000 nuclear fusion control experiments of the EAST device and conducted a 25-hour long-pulse simulation experiment with zero failures, fully verifying the stability and reliability of the configuration parameter distribution scheme.

[0106] 1. Verification of configuration parameter distribution function

[0107] The configuration parameters of the control system, such as the target value of plasma current IP, are set through the interface before discharge. The corresponding parameter values ​​at the current moment are analyzed in real time during each operating cycle during the discharge process. Combined with the collected diagnostic data, the command data for plasma control is obtained through specific control logic calculations.

[0108] Taking the target parameter analysis of the plasma current IP in the EATS device 129109 experimental gun as an example, the functionality of parameter analysis is analyzed. Figure 7(a) shows the target parameter waveform of the IP current, set in the Limit algorithm interface of the Shape Control Directory, in megaamperes (mA); Figure 7(b) shows the real-time analyzed waveform of the plasma current IP target parameter during the discharge process, in amperes (A). The system switches to the Limit algorithm at 0.2 seconds, using the Limit algorithm IP current parameter as the target plasma current control value. Comparing the IP current target value obtained by parameter analysis in Figure 7(b) after 0.2 seconds with the IP current target value set in the Limit algorithm interface in Figure 7(a), it is found that the IP waveforms in the two figures are completely consistent. Specifically, the inflection point value of the waveform near 0.35 seconds in both figures is approximately 142,000 A.

[0109] 2. Real-time analysis of configuration parameter distribution

[0110] Given that the shape control algorithm component is the one with the most parameters among the above 16 components, such as Figure 8 As shown in the figure, the longest time consumption period of the parameter parsing service of the shape algorithm component in the 2023 EAST annual 100-shot experiment was selected for statistics. It can be concluded that the maximum time consumption of the parameter parsing service is within 20 microseconds (the set operation period of the shape real-time component is 100 microseconds), which meets the real-time requirements of parameter parsing and leaves enough time margin for complex logical operations.

[0111] 3. Changes in system memory usage during long pulse operation

[0112] In order to verify the parameter analysis capability of the long pulse system, a 25-hour simulation test was conducted, and real-time statistics of the system memory were performed through Linux command scripts. The statistical results are as follows: Figure 9The statistical analysis results show that the system memory usage does not show an increasing trend related to the length of the discharge experiment.

[0113] In summary, the plasma control configuration parameter distribution scheme meets the functional requirements of parameter distribution and has good real-time performance and the ability to serve long pulse operation.

[0114] The above specific embodiments are merely several optional embodiments of the present invention. Based on the technical solutions of the present invention and the relevant inspirations of the above embodiments, those skilled in the art may make various alternative improvements and combinations to the above specific embodiments.

Claims

1. A method for distributing configuration parameters of a plasma control system, characterized in that: The following steps are involved: Deploy parameter parsing plug-ins for auxiliary components and algorithm components on real-time nodes. The auxiliary components and algorithm components interact through shared memory. During the discharge preparation phase, the configuration parameter management component of the master node broadcasts the gun number to the auxiliary component through the publish-subscribe mechanism. The auxiliary component sends a configuration parameter request to the configuration parameter management component. The configuration parameter management component generates a configuration parameter data packet in JSON format based on the request and returns it to the auxiliary component, which then stores it in shared memory. The shared memory of each algorithm component and auxiliary component is named with the logical CPU identifier and is managed in a queue manner. After the algorithm component parameter parsing plug-in detects the parameter ready command in the shared memory queue, it loads the shared memory configuration parameters into the local memory configuration parameter management structure. In the discharge control stage, the parameter parsing plug-in traverses the configuration parameter management structure, dynamically determines the activated control sequence and control segment, and calculates the current parameter value based on the vertex value pair (t, y) interpolation.

2. A plasma control system configuration parameter distribution method according to claim 1, characterized in that: The interface data structure between the configuration parameter management component and the auxiliary component is defined by an interface description language, and the interface description language generates a cross-platform data serialization code.

3. A plasma control system configuration parameter distribution method according to claim 1, characterized in that: The communication content of the shared memory message queue is a Command object, which includes: Type field: identifies the command category, including parameter data packet ready commands and control instructions; Length field: indicates the size of the data payload in bytes; Source field: marks the logical CPU ID of the command initiator; Data payload: Pointer to the configuration parameter data packet in shared memory.

4. A plasma control system configuration parameter distribution method according to claim 1, characterized in that: The configuration parameter management structure is divided into a hierarchical structure according to the control items, specifically including: Control item: manage multiple control sequences with a hash table and record the currently activated control sequence; Control sequence: multiple control segments are associated through a linked list, and each control segment contains the Vertex array at the execution time; Control section: binds a unique algorithm and its configuration parameters. The configuration parameters are stored as vertex value pairs (t, y). Data between vertices is generated by interpolation. The interpolation methods include static hold, step hold, or linear interpolation.

5. The method for distributing configuration parameters of a plasma control system according to claim 1, characterized in that: During the discharge control phase, the timing method for real-time parameter analysis includes: Absolute timing: based on the discharge start time, the global time starts to accumulate from -9 seconds; Relative timing: The algorithm startup time is taken as time 0, and is used for local timing when the algorithm's internal state switches.

6. A plasma control system configuration parameter distribution method according to claim 5, characterized in that: During the real-time parameter parsing process, only the configuration parameters corresponding to the currently activated algorithm are parsed, and the parameters of the inactivated algorithms are retained in the shared memory to avoid redundant data occupying the local memory.

7. A plasma control system configuration parameter distribution method according to claim 1, characterized in that: The shared memory message queue adopts a full-duplex communication mechanism, specifically using an independent read buffer and write buffer for bidirectional data transmission, and the buffer cyclically manages queue elements through a head pointer and a tail pointer.

8. The method for distributing configuration parameters of a plasma control system according to claim 1, characterized in that: The configuration parameters include: Algorithm scheduling scheme: Dynamically switch control strategies by setting the time execution combination of control items; Plasma control target parameters: defined in the form of waveform data, including plasma current, shape and density parameters.

9. A method for distributing configuration parameters of a plasma control system according to claim 4, characterized in that: The interpolation calculation of the vertex value pair (t, y) is specifically as follows: Static hold: the y value remains unchanged throughout the discharge cycle; Step hold: The y value remains at the previous vertex value before time t until the next vertex takes effect; Linear interpolation: According to the formula of adjacent vertex values: Calculate the current time y value, where y is the configuration parameter value at the current time t, y m is the parameter value of the mth vertex, y m-1 is the parameter value of the m-1th vertex, t m is the time point of the mth vertex, t m-1 is the time point of the m-1th vertex.

10. The method for distributing configuration parameters of a plasma control system according to claim 3, characterized in that: The naming rule of the shared memory message queue is "shm.rt.cpuID.command", where cpuID is the logical CPU number bound to the algorithm component, and the message queues corresponding to different cpuIDs are physically isolated.

Images