Status of the ITER ECRH&CD control system development

. The ITER ECRH&CD system is designed to inject 20 MW of millimetre-wave at 170 GHz into the vacuum vessel. The system is composed of many sub-systems, namely High-Voltage Power Supplies (HVPS), Gyrotrons, Transmission Lines (TL), Ex-vessel Waveguides (EW), Launchers. It is the role of the EC Plant Controller (ECPC) to integrate all the Sub-system Control Units (SCU), to prepare the system for operation and to execute the real-time requests coming from the plasma control system. Plant level protections are also implemented by the ECPC, in charge of ensuring the safe operation of the plant, while optimizing the power availability. While control and protection functions are always pushed to the lower possible controller able to implement them, the operational requirements and flexibility of the system make it impossible to fully segregate many functions, since each gyrotron is connected to at least two different launching mirrors. To simplify the SCUs’ development and to respect the responsibility boundaries imposed by the procurement strategy, all the functions involving more than one sub-system are implemented in the ECPC, which exposes a single operational interface towards the ITER Central I&C. The status of the control system development is presented in this work.


Introduction
The ITER Electron Cyclotron Heating and Current Drive (ECH&CD) System is designed to inject 20 MW of millimetre-wave at 170 GHz into the vacuum vessel. The system is being procured by 5 domestic agencies, Europe (F4E) [1], Japan (JA-DA), India (ITER-India), Russia (RFDA), United States (USIPO), plus the ITER Organization (IO). The EC system is composed of different sub systems, each one with its own local controller called Subsystem Control Unit (SCU). The main sub-systems are the High Voltage Power Supplies (HVPS), RF sources (Gyrotrons), Transmission Lines (TL), Ex-vessel Waveguides (EW) and Launchers. Due to the complexity of the ITER EC system, the number of the contributing parties and the staged installation [2], the Electron Cyclotron Plant Controller (ECPC) was added to the architecture. The main ECPC functions are the integration of all the sub-systems, the system preparation for operation and the execution of the realtime requests coming from the Plasma Control System (PCS). Even though coordination and supervision of the subsystems are the essential roles of the ECPC, the most important function is to provide protection at plant level, ensuring safe operation while fully optimizing the power availability.
The ECPC together with the SCUs forms the Electron Cyclotron Control System (ECCS). Control and protection functions are always pushed to the lower possible controller able to implement them. To facilitate the SCUs' control system development and to reduce the risk of re-implementation of components, all the functions involving more than one sub-system are implemented in the ECPC. * Corresponding author: giuseppe.carannante@iter.org The expected operation scenarios of the EC System are classified as those that are synchronous and those that are asynchronous to the ITER pulse. As high availability of the EC System is required, the ECCS will allow a part of the EC plant to be operated synchronously on the plasma, while another part of the plant will be operated asynchronously (e.g. for commissioning and maintenance). The coordination of the ECPC with ITER Central Instrumentation and Control (I&C) and SCUs is done using a set of hierarchical state machines and sequences, detailed in sections 3 and 5.
The ECPC development was divided into stages as it will firstly be used only for the acceptance and integration tests of the SCUs, and later also for the plasma operation:  Stage 1: Transportable system able to verify the correct functionality of the SCUs interfaces to the ECPC  Stage 2: Gyrotron Commissioning control system able to implement integrated protection of a partial EC plant and support SAT (Site Acceptance Tests) of a Gyrotron, HVPS and TL SCUs  Stage 3: First Plasma system  Stage 4: Fully functional system implementing complete control techniques Stage 1 and 2 control systems were successfully developed, manufactured, and delivered to ITER in December 2021. The delivered system architecture of the ECPC supports testing of all the interfaces and functionalities of the SCUs. The first use-case of the developed ECPC control system is the SAT campaign of the EUDA HVPS planned to start at the beginning of 2023. During the development of the EUDA HVPS system, a conclusion was reached that no market available components were able to satisfy the specifications of the Gyrotron to HVPS interface (for references and measurements). Therefore, bespoke modules (section 6) were developed.
Even though first plasma just requires the ability to schedule the gyrotron operation for short pulses, many advanced functionalities are already present in the following plasma campaign, e.g. switching gyrotrons to different launchers in real-time, modulating the gyrotron power to synchronize with the rotation of the neoclassical tearing mode (NTM), automatic conditioning of gyrotrons. These advanced functions require all the systems to minimise the preparation time and to accept real-time references. The need to condition a gyrotron for a long pulse is one of the weakest points in this context. A research activity is being conducted to develop a model-based control of the gyrotron heater to maintain it always prepared for long pulse operation.

Functions and architecture
The implementation was based on the ECCS design presented on the Conceptual Design Review (CDR) in November 2013. All the control and protection requirements were identified and allocated to the different controllers of the I&C architecture. The main functions of the ECPC as per [3] are the following: -Manage EC subsystems parameters and waveforms -Allow operation of each single EC subsystem -Coordinate the state machines of the EC plant -Control the EC plant following real-time requests and references coming from the PCS -Implement fast and slow protection functions (the choice of components given in section 2.2) -Publish to CODAC (Control, Data Access and Communication) signals to be monitored The ECCS architecture, with the ECPC components marked in the dashed box, is given on Fig. 1. A brief description of the components follows.

ECCS Networks and interfaces
Given the uncertainties in the project, reducing the number of physical interfaces and at the same time allowing for increasing and changing them has been attained by adopting standard network interfaces, like Synchronous Databus Network (SDN) among fast controllers and Profinet among PLCs. Moreover, the interfaces towards CODAC, as shown in [4], had to be respected. CODAC System and Networks provide overall plant systems coordination, supervision, plant status monitoring, alarm handling, data archiving, plant visualization (HMI) and remote experimental functions.
The allows SCU state machine and protection functions management in synchronous operation The majority of the SCUs have all the listed network interfaces. However, the HVPS SCU also has an interface towards the PSS-OS (Plant Safety System for Occupational Safety), as it includes control of high voltage components which have to be operated in a way compliant with occupational safety.
In addition to the CODAC services and internal EC connections, the ECPC interfaces with the following ITER central I&C services: -The Central Safety System (CSS): plant-wide nuclear (CSS-N) and occupational safety (CSS-OS) -The Central Interlock System (CIS): plant-wide investment protection Moreover, the ECPC will implement an interface towards the PCS for real-time power requests.

Protection functions implementation
The Slow Controllers (PLC) and the Fast Protection Controller (FPGA) are used to implement the protection functions, based on the following criteria: -PLCs are used for protection functions that require reaction times of >50 ms. -FPGAs are used for protection functions that require faster reaction times. -Optical fiber is the preferred solution for fast protection functions in order to improve the speed, noise reduction and isolation In addition to the implementation of the plant level slow protection functions (e.g. over-temperatures, lack of flows), the Plant Slow Controller configures the Fast Protection Controller protection functions and it is therefore the master of the plant protection.
The Plant Fast Protection Controller sends shutdown requests to the HVPS SCUs based on the configured protections. After receiving the shutdown request, the HVPS will remove the output voltage in less than 10 μs.

Control functions implementation
The Plant Fast Controller is the master of the plant operation, it defines which SCUs operate synchronously and manages the state machines of the synchronous subsystems. The Plant Fast Controller interfaces with the Central I&C to receive requests which are then translated into SCU commands and waveforms. It will schedule the EC operation by assigning the available Gyrotrons and Launchers to different control functions. It will compute in real-time the power references for the Gyrotrons, the polarization for the TL and the mirrors positions for the launchers.
The Plant Fast Controller receives from the Plant Fast Protection Controller a packet containing the information of the faults and events that have happened in the plant. These events are then timestamped using the central TCN time and are published to the Central I&C on DAN.
The Plant Slow Controller relays the state machine commands and statuses between the Plant Fast Controller and the SCU Slow Controllers, which manage the SCUs' state machines.

State machine and operation management
The orchestration and operation synchronization between all the EC plant systems is based on a set of state machines and sequences.
The ECPC state machine, given on Fig. 2 is the highest node in the hierarchy of state machines. It interfaces to Central I&C and coordinates all the systems of the plant which are to be operated synchronously. To define which systems are to be operated synchronously, the concept of mode is introduced. A mode will indicate which SCUs are expected to be slaves of the ECPC. The evolution through the states of the ECPC state machine will automatically trigger actions on the state machines of the SCUs which will then trigger sequences of SCU subsystems (e.g. auxiliary power supplies). The conditions of each ECPC state and sub-state transitions are linked to the states of the SCUs defined for a given mode. Plant protections will automatically be updated with the selection of a different mode.
Each ECPC state has three sub-states: -Progress -a transition has been started and is ongoing in one or more SCUs. A command is issued to the SCU to start a sequence. The SCU sequence then issues commands to SCU subsystem sequences -Stable -the transition is finished and the conditions for a given state have been fulfilled. SCU states are compliant -Error -the transition which was started has failed or the condition for the stable sub-state has been lost The main ECPC states are: -Idle -checking that all the services have been started and that communication is established between the different ECPC controllers -Configure Protections -a state in which new definitions of the plant protections can be transferred -Standby -SCUs required for the mode are in Standby state (e.g. gyrotron auxiliaries in operation) -Ready -SCUs are ready to receive a trigger to start a pulse -Online -power generation according to received inputs. Trigger signals sent to SCUs An example of the state machine coordinated behaviour follows. One of the standby modes definitions of the GCU is normal operation of one gyrotron. Normal operation means that all the auxiliary sub-systems of the gyrotron are required to be functioning. The GCU will receive a command from the ECPC to prepare the system for Standby. The GCU will automatically issue commands, in a given order, to the different gyrotron sub-systems. When all the sub-systems are functioning, the GCU condition for Standby will be fulfilled. This information will then be transmitted back to the ECPC and the state of the ECPC state machine will be updated accordingly.
A prototype of both the ECPC and the Gyrotron SCU were deployed and tested at the FALCON test facility at the Swiss Plasma Centre (SPC) [5].

Frameworks and libraries
To ease the development process, the implementation of the control system is based on frameworks and libraries. This facilitates debugging and application maintenance, and it presents a time-saving, a more efficient and cleaner way of implementing. When possible, the frameworks already in place in other ITER systems were re-used, and when not, custom solutions for the EC system were developed.
The Fast Controller development is based on the MARTe [6] framework. MARTe is a C++ modular and multi-platform framework for the development of realtime control system applications. The main advantages of the framework are the separation between the platform specific implementation, the environment details and the user code, as well as the software quality assurance process of the components. This framework is used in many ITER projects and it is spread throughout the entire fusion community.
The Slow Controller integration with instrumentation uses the Unified Control Library (UCL) objects. UCL has been developed as part of a joint IO and F4E effort to facilitate the development, commissioning, and maintenance of industrial ITER systems (e.g. Vacuum system, Cooling Water System). The UCL objects are divided into families (e.g. input/output, alarm, control) where each of them covers a certain layer within the application. The benefit of the UCL objects is that they provide standardized interfaces towards the field, as well as towards CODAC.

Gyrotron controller
The SCU with the most complex set of controllers and interfaces is the Gyrotron Controller SCU (GCU), managing a pair of gyrotrons. The GCU is defined with a Standby and a Ready mode which describe the set of sub-systems that should be operational in a given state. The modes present degrees of freedom as the plant can easily be reconfigured for different types of operation, ranging from gyrotron conditioning on a dummy load to firing with the pair of gyrotrons. System protections are automatically updated based on the selected Standby and Ready modes.
The GCU Fast Controller implements a set of state machines, linked to the preparation of the system and the real-time interface and operation. It receives the trigger from the Plant Fast Controller to start the power on the HVPS. It interfaces to the HVPS SCU to which it sends analogue references and digital triggers and acquires the HVPS measurements and statuses.
Measurements and references are received and sent using analogue optical cards (described in section 5).
The GCU Slow Controller is the master of the SCU control system and responsible for the preparation of all the auxiliary power supplies of the gyrotron pair, the HVPS state machine and the GCU Fast Controller state machine. The GCU Slow Controller implements a set of configurable slow protections which are defined for the different modes of the operation of the GCU (e.g. operation with one or two gyrotrons). It configures the fast protections of the system in the GCU Fast Protection Controller.
The GCU Fast Protection Controller gathers protection information from the plant, e.g. arcs, and issues a fast shutdown petition to the HVPS used for the operation of the pair of gyrotrons.
The GCU Fast Controller implements the real-time control of the gyrotron. It receives requests to switch on and off the gyrotron from the Plant Fast Controller and propagates this request to the HVPS. This architecture allows to switch on the gyrotron power after only few milliseconds from the request.

Universal Gyrotron Controller framework
A Universal Gyrotron Controller (UGC) framework was developed to provide the mechanisms to manage all types of ITER Gyrotron Controllers (SCUs) using a variety of hardware platforms. UGC is a software framework used to perform the following functions: -Manage Gyrotron auxiliaries -Manage HV power supplies -Implement protection functions -Implement the standardized ECPC-SCU interface -Implement the standardized CODAC interface The software architecture of the SCU identifies multiple layers interconnected by a number of internal buses, as shown on Fig. 3. Starting from the bottom layer, the Device Access Layer, contains all the software that is necessary to handle any peripheral. This ranges from IO cards to complex digital/analogue interfaces to auxiliary devices.
The main components of the Device Access layer are the following blocks: -Basic step -performs a single action on the auxiliary device, e.g. sets one output on the PLC -Level 0 sequence -description of a fixed set of functions, e.g. switching on of a power supply -Communication block -standard interface block for the different communication protocols, e.g. RS232, MODBUS -Subsystem Status monitor -checks and publishes the different states of a subsystem -HVPS reference generator and data acquisition -provides an interface of the Fast Controller to the HVPSs. Sends voltage and current references, trips and commands. Receives measurements as well as statuses. Measurement acquisition and reference generation are done via Hotlink modules (described in section 6) The layer above the Device Access layers consists of SCU Process Blocks, which are components that process data that is read from or written to one of the internal buses. The main blocks are: -Command Manager -pre-processing of the different sources of sequence commands and priorities. Issues individual commands to each level 0 sequence of a subsystem -State Manager -implements a state machine to manage the transitions between the subsystem manual/auto and segregation states Above that, we find the SCU State Machine layer. This is used to control the SCU operation logic with a cluster of state machines and sequences. The main state machine of the SCU manages the overall operation of the SCU. It prepares the system outside of a pulse and manages the operation during a pulse. Another SCU state machine defines if the SCU is in asynchronous operation (management done through PON) or if it is in synchronous operation (slave to ECPC, as described in section 3). The command manager uses this state to filter and issue the commands to the bottom layer.
The SCU state machine takes into consideration the current state of the whole plant, the state machine and the commands coming from the command manager. When a condition is fulfilled, the state of the state machine will be changed.
The top layer is the Slave SCU Layer. It contains the description of the SCU behaviour toward the ECPC.
An additional function implemented in the UGC is the gyrotron protection. The protection layer implements this function by issuing trips to the different power supplies based on a defined set of protections. The protections are configured for different modes of operation of the plant, and when changing from one mode to another, the corresponding protections are loaded automatically. The protection functions can be executed either in the Slow Controller or in the Fast Protection Controller (see Section 2.2). The processing of the input information in the Fast Protection Controller is done in stages (as per figure Fig. 4): -Input stage -synchronizes the digital inputs to the system clock through a chain of flip flops. Analyses each input (positive/negative logic; pulse train) and generates an alarm for further stages -Logic function block stage -performs logical function operations on the alarms coming from the input stage or the logic function block stage -Output stage -selects which alarms coming from the input stage or the logic function block stage should issue a fast shutdown signal to the HVPS The Slow Protection Controller implements the same stages and can process both digital and analogue inputs.

Hotlink modules
The requirements on the reference generation and data acquisition for the HVPS were such that no "off the shelf" IO card available on the market was adequate. There was a need for a solution which provides a high speed interface with optical isolation; is compatible with the National Instruments Compact RIO (cRIO) chassis and compatible with the solution of the HVPS supplier. Therefore, Hotlink (HOTLink® family of data communication products provides a simple and low-cost solution to high-speed data transmission) modules, were designed and manufactured. The main application of the modules is to implement a high speed analogue interface between the HVPS SCUs and the Gyrotron Controller SCU.
The CRIO-Hotlink TX and CRIO-Hotlink-RX modules are respectively a high speed analogue to optical converter and a high speed optical to analogue converter.
The modules have three interfaces (as shown on figure Fig. 5): -Analogue interface -two differential inputs and two single ended output channels -Optical serial interface -transmission / reception of 200 Mbit digital data The Hotlink RX operation mode is to receive data from the optical interface and to send data both to the analogue output channel and the digital interface. The Hotlink TX operation modes are to transmit data: -acquired from the analogue input channel to both the optical and the digital interface; -read from the cRIO 8bit digital bus to the optical interface and the analogue outputs. An example of the interfaces and modules operation modes is given on figure Fig. 6, where a pair of Hotlink modules is in the following setup: a signal is generated on the oscilloscope and fed into the analogue input of the TX module. That signal is then transmitted on the optical interface of the TX module to the optical interface of the RX module and also on the analogue output of the TX module. The analogue output of the TX module is displayed on the oscilloscope as CH1. The acquired optical signal on the RX is transmitted on the analogue output of the module and displayed as CH2 on the oscilloscope.

Future activities
One of the biggest challenges of the gyrotron long pulse operation is how to keep the gyrotron ready. Nowadays, the gyrotron has to be conditioned with a series of short pulses before it reaches conditions which are suitable for a long pulse campaign. In order to maintain the gyrotron ready, the state of the gyrotron heater should be known. To be able to estimate the state, a model-based control of the gyrotron heater is being investigated.
Other future activities include the start of the SAT of the EUDA HVPS in the beginning of 2023, the SAT of gyrotrons in the second half of 2023 and the preparation of the first plasma control system final design review which is planned for 2024.

Conclusion
A description of the current status of the ECCS control system was presented. The ECCS system consists of the Plant Controller and different SCU subsystems. Both the ECPC and the SCU controllers are a cluster of Fast, Slow and Fast Protection Controllers, where each implements a given set of functions. The interfaces and networks used in the control system comply with the ITER standards. The coordination of the ECPC with Central I&C and SCUs is done using a set of hierarchical state machines and sequences. To define which SCU systems are operated synchronously to the pulse and which asynchronously, the ECPC mode is introduced. Software standardization is achieved with the usage of frameworks. Hardware of the ECCS is based on "offthe-shelf" components. However, the HVPS reference generation and measurement acquisition requirements were such that bespoke modules, Hotlink modules, were designed and manufactured.
The views and opinions expressed herein do not necessarily reflect those of the ITER Organization.