A simulation environment for ITER PCS development

A simulation environment known as the Plasma Control System Simulation Platform (PCSSP), specifically designed to support development of the ITER Plasma Control System (PCS), is currently under construction by an international team encompassing a cross-section of expertise in simulation and exception handling for plasma control. The proposed design addresses the challenging requirements of supporting the PCS design. This paper provides an overview of the PCSSP project and a discussion of some of the major features of its design. Plasma control for the ITER tokamak will be significantly more challenging than for existing fusion devices. An order of magnitude greater performance (e.g. [1], [2]) is needed for some types of control, which together with limited actuator authority, implies that optimized individual controllers and nonlinear saturation logic are required. At the same time, consequences of control failure are significantly more severe, which implies a conflicting requirement for robust control. It also implies a requirement for comprehensive and robust exception handling. Coordinated control of multiple competing objectives with significant interactions, together with many shared uses of actuators to control multiple variables, implies that highly integrated control logic and shared actuator management will be required. It remains a challenge for the integrated technologies to simultaneously address these multiple and often competing requirements to be demonstrated on existing fusion devices and adapted for ITER in time to support its operational schedule. We describe ways in which the PCSSP will help address these challenges to support design of both the ITER PCS itself and the algorithms that will be implemented therein, and at the same time greatly reduce the cost of that development. We summarize the current status of the PCSSP design task, including system requirements and preliminary design documents already delivered as well as features of the ongoing detailed architectural design. The methods being incorporated in the detailed design are based on prior experience with control simulation environments in fusion and on standard practices prevalent in development of control-intensive industrial product designs.     

An integrated architecture for the ITER RH control system

The ITER remote handling (RH) system has been divided into 7 major equipment system procurements that deliver complete systems (operator interfaces, equipment controllers, and equipment) according to task oriented functional specifications. Each equipment system itself is an assembly of transporters, power manipulators, telemanipulators, vehicular systems, cameras, and tooling with a need for controllers and operator interfaces.From an operational perspective, the ITER RH systems are bound together by common control rooms, operations team, and maintenance team; and will need to achieve, to a varying degree, synchronization of operations, co-operation on tasks, hand-over of components, and sharing of data and resources. The separately procured RH systems must, therefore, be integrated to form a unified RH system for operation from the RH control rooms.The RH system will contain a heterogeneous mix of specially developed RH systems and off-the-shelf RH equipment and parts. The ITER Organization approach is to define a control system architecture that supports interoperable heterogeneous modules, and to specify a standard set of modules for each system to implement within this architecture. Compatibility with standard parts for selected modules is required to limit the complexity for operations and maintenance. A key requirement for integrating the control system modules is interoperability, and no module should have dependencies on the implementation details of other modules.The RH system is one of the ITER Plant systems that are integrated and coordinated through the hierarchical structure of the ITER CODAC system. It is distinguished from other Plant systems by the man-in-the-loop nature of RH operations and the need for control rooms at a level below the main control room. The RH control system architecture has been designed to also support the central monitoring and coordination of the RH activities.     

Physics of the conceptual design of the ITER plasma control system

The ITER plasma control system (PCS) will play a central role in enabling the experimental program to attempt to sustain DT plasmas with Q = 10 for several hundred seconds and also support research toward the development of steady-state operation in ITER. The PCS is now in the final phase of its conceptual design. The PCS relies on about 45 diagnostic systems to assess real-time plasma conditions and about 20 actuator systems for overall control of ITER plasmas. It will integrate algorithms required for active control of a wide range of plasma parameters with sophisticated event forecasting and handling functions, which will enable appropriate transitions to be implemented, in real-time, in response to plasma evolution or actuator constraints.In specifying the PCS conceptual design, it is essential to define requirements related to all phases of plasma operation, ranging from early (non-active) H/He plasmas through high fusion gain inductive plasmas to fully non-inductive steady-state operation, to ensure that the PCS control functionality and architecture will be capable of satisfying the demands of the ITER research plan. The scope of the control functionality required of the PCS includes plasma equilibrium and density control commonly utilized in existing experiments, control of the plasma heat exhaust, control of a range of MHD instabilities (including mitigation of disruptions), and aspects such as control of the non-inductive current and the current profile required to maintain stable plasmas in steady-state scenarios. Control areas are often strongly coupled and the integrated control of the plasma to reach and sustain high plasma performance must apply multiple control functions simultaneously with a limited number of actuators. A sophisticated shared actuator management system is being designed to prioritize the goals that need to be controlled or weigh the algorithms and actuators in real-time according to dynamic control needs. The underlying architecture will be event-based so that many possible plasma or plant system events or faults could trigger automatic changes in the control algorithms or operational scenario, depending on real-time operating limits and conditions.     

Progress in control and data acquisition for the ITER neutral beam test facility

SPIDER, the ion source test bed in the ITER neutral beam test facility, is under construction and its operation is expected to start in 2014. Control and data acquisition for SPIDER are undergoing final design. SPIDER CODAS, as the control and data acquisition system is referred to, is requested to manage 25 plant units, to acquire 1000 analogue signals with sampling rates ranging from a few S/s to 10 MS/s, to acquire images with up to 100 frames per second, to operate with long pulses lasting up to 1 h, and to sustain 200 MB/s data throughput into the data archive with an annual data storage amount of up to 50 TB. SPIDER CODAS software architecture integrates three open-source software frameworks each addressing specific system requirements. Slow control exploits the synergy among EPICS and Siemens S7 programmable controllers. Data handling is by MDSplus a data-centric framework that is geared towards the collection and organization of scientific data. Diagnostics based on imaging drive the design of data throughput and archive size. Fast control is implemented by using MARTe, a data-driven, object-oriented, real-time environment. The paper will describe in detail the progress of the system hardware and software architecture and will show how the software frameworks interact to provide the functions requested by SPIDER CODAS. The paper will focus on how the performance requirements can be met with the described SPIDER CODAS architecture, describing the progress achieved by carrying out prototyping activities.     

ITERDB—The Data Archiving System for ITER

For ITER, acquiring, managing and archiving its data is an essential task. ITER is foreseen to produce up to one terabyte of data per pulse and several petabytes of data per year. All the produced data needs to be stored and managed. The stored data is expected to serve the data access needs of ITER researchers located both on the ITER premises as well as worldwide during ITER's lifetime and beyond.ITERDB is a data management system being designed for centralized ITER data archival and data access. It is designed to manage and serve both unprocessed and processed data from the ITER plant systems and data analysis workflows.In this paper, we report the ITER Data Archiving System software requirements and priorities that have been identified by working with ITER staff and a large number of stakeholders. We will describe the design challenges and the proposed solutions. We will also present the current state of the ITERDB software architecture design.     

Concept design of fusion power shutdown system for ITER

ITER is a nuclear facility. It is essential to maintain operational safety or to bring this facility to a safe state in case of accidents or incidents. During plasma operation ITER plasma will generate significant heat loads on the plasma facing components. For a few reference accidents there is the need to stop plasma reliably within a certain time. Fusion power shutdown system is the safety system to implement this termination function for ITER. It is based on the concept of massive gas injection.This paper summarizes the safety requirements, logics and the physics requirements on this system for reliable termination of ITER plasma. With regard to the quantity of gas, transient behavior simulation is shown, subsequently providing guideline for laboratory bench-testing. Conceptual engineering design of the system is given together with instrumentation and control specifications.     

Mechanical design features and challenges for the ITER ICRH antenna

The ITER Ion Cyclotron Resonant Heating (ICRH) antenna provides plasma heating at a power of 20 MW. Operation in the ITER environment imposes significant thermal power handling capability, structural integrity, shielding and operations requirements. The design will require a step change over any predecessor in terms of power, scale and complexity. This paper reports the main mechanical design features that address the challenges and often conflicting requirements during the conceptual design phase.     

Design and application of an EPICS compatible slow plant system controller in J-TEXT tokamak

J-TEXT tokamak has recently implemented J-TEXT COntrol, Data Access and Communication (CODAC) system on the principle of ITER CODAC. The control network in J-TEXT CODAC system is based on Experimental Physics and Industrial Control System (EPICS). However, former slow plant system controllers in J-TEXT did not support EPICS. Therefore, J-TEXT has designed an EPICS compatible slow controller. And moreover, the slow controller also acts the role of Plant System Host (PSH), which helps non-EPICS controllers to keep working in J-TEXT CODAC system. The basic functionalities dealing with user defined tasks have been modularized into driver or plug-in modules, which are plug-and-play and configured with XML files according to specific control task. In this case, developers are able to implement various kinds of control tasks with these reusable modules, regardless of how the lower-lever functions are implemented, and mainly focusing on control algorithm. And it is possible to develop custom-built modules by themselves. This paper presents design of the slow controller. Some applications of the slow controller have been deployed in J-TEXT, and will be introduced in this paper.     

ITER CODAC interface for the visible and infra-red wide angle viewing cameras

The amount of data generated by the infra-red and visible cameras at ITER is expected to be considerably larger than most diagnostics. ITER will have 12 infra-red cameras plus 12 visible cameras in four different equatorial port plugs. Each of the ports will have a Plant System Host (PSH) that will provide a standard image of the plant system to the ITER's Control and Data Access and Communication (CODAC) system.The two key functions of these cameras will be the scientific exploitation with the detection of interesting physics events and the operational protection of the machine, namely the first wall. Already assuming high bandwidth requirements for both audio and video, ITER will provide a separate network for this kind of communication, which will be used to transmit both the experimental and informational data provided by the cameras.This paper presents the current camera plant system design and its interaction with ITER CODAC system and networks. Starting from the camera specifications several alternatives for data collection and compression are discussed. The required inputs from CODAC and a first specification for the internal finite state machine are also presented. Finally, a possible hardware straw man design solution for the plant system hardware is proposed.     

Unified software development approach for the safety-critical ITER maintenance devices

The RH devices used for ITER divertor maintenance are movers or manipulators composed of electro-hydraulic and electrical actuators. Such devices are CMM, CTM and WHMAN to assist CMM and CTM. These devices execute complex and safety-critical operations while supporting ITER reactor elements weighting several tons. Despite the differences in the load capacity and functionality, the control system of these devices can be categorized as position servo control or force servo control. In this paper we propose the use of unified software development approach currently developed and demonstrated at the DTP2. This new approach takes into account the ITER RH requirements for all maintenance devices, not only the water-hydraulic maintenance devices. The need for extensive software verification and validation utilizing international standards for safety-critical systems is addressed. This applies both to control software architecture and user interface design. In principle, we propose that all ITER maintenance devices are developed and tested with the common software architecture and user interface. This makes it possible to reuse generic software modules that are well documented and tested, resulting decreased verification and validation period and development cost. Utilising this approach also improves reliability and safety of the maintenance operations.     

Towards the conceptual design of the ITER real-time plasma control system

ITER will be the world's largest magnetic confinement tokamak fusion device and is currently under construction in southern France. The ITER Plasma Control System (PCS) is a fundamental component of the ITER Control, Data Access and Communication system (CODAC). It will control the evolution of all plasma parameters that are necessary to operate ITER throughout all phases of the discharge. The design and implementation of the PCS poses a number of unique challenges. The timescales of phenomena to be controlled spans three orders of magnitude, ranging from a few milliseconds to seconds. Novel control schemes, which have not been implemented at present-day machines need to be developed, and control schemes that are only done as demonstration experiments today will have to become routine. In addition, advances in computing technology and available physics models make the implementation of real-time or faster-than-real-time predictive calculations to forecast and subsequently to avoid disruptions or undesired plasma regimes feasible. This requires the PCS design to be adaptable in real-time to the results of these forecasting algorithms. A further novel feature is a sophisticated event handling system, which provides a means to deal with plasma related events (such as MHD instabilities or L-H transitions) or component failure. Finally, the schedule for design and implementation poses another challenge. The beginning of ITER operation will be in late 2020, but the conceptual design activity of the PCS has already commenced as required by the on-going development of diagnostics and actuators in the domestic agencies and the need for integration and testing. This activity is presently underway as a collaboration of international experts and the results will be published as a subsequent publication. In this paper, an overview about the main areas of intervention of the plasma control system will be given as well as a summary of the interfaces and the integration into ITER CODAC (networks, other applications, etc.). The limited amount of commissioning time foreseen for plasma control will make extensive testing and validation necessary. This should be done in an environment that is as close to the PCS version running the machine as possible. Furthermore, the integration with an Integrated Modeling Framework will lead to a versatile tool that can also be employed for pulse validation, control system development and testing as well as the development and validation of physics models. An overview of the requirements and possible structure of such an environment will also be presented.     

Actuator and diagnostic requirements of the ITER Plasma Control System

The ITER Plasma Control System (PCS) requires an extensive set of about 50 diagnostic systems to measure the plasma response and about 20 actuators to act on the plasma to carry out its control functions. The specifications and real limitations of the actuators and diagnostics are being assessed as part of the ongoing conceptual design of the PCS to understand the potential impact on plasma control. The actuators include magnetic coils (central solenoid (CS), poloidal field (PF), vertical stability (VS), edge localized mode (ELM), correction coils (CC)), heating and current drive (electron cyclotron (EC), ion cyclotron (IC), neutral beam injection (NBI), and possibly lower hybrid (LH)), glow discharge cleaning, fueling and impurity gas and pellet injection, vacuum pumping, and disruption mitigation systems. Diagnostic systems are prioritized according to their role in machine protection (MP), basic control (BC), advanced control (AC), and physics studies (PS). At the conceptual design phase, detailed control algorithms do not yet need to be specified, but conceptual solutions must be chosen that satisfy the PCS requirements for control within the real constraints of the diagnostics and actuators. The feasibility of the chosen solutions must be proven either through established control schemes on existing machines or through an R&D program to develop them before they will be required on ITER. The diagnostic and actuator requirements of the PCS will evolve from first plasma through the high performance DT phase. A comparison is made of the expected requirements to control vertical stability, sawteeth, neoclassical tearing modes (NTMs), edge localized modes (ELMs), error fields, resistive wall modes (RWMs), Alfvén eigenmodes, and disruptions with the ITER baseline actuator and diagnostic specifications.     

RAMI analysis of the ITER Central Safety System

ITER is the first worldwide international project aiming to design a facility to produce nuclear fusion energy. The technical requirements of its plant systems have been established in the ITER Project Baseline. In the project, the Reliability, Availability, Maintainability and Inspectability (RAMI) approach has been adopted for technical risk control to help aid the design of the components in preparation for operation and maintenance. A RAMI analysis was performed on the conceptual design of the ITER Central Safety System (CSS). A functional breakdown was prepared in a bottom-up approach, resulting in the system being divided into 2 main functions and 20 sub-functions. These functions were described using the IDEF0 method. Reliability block diagrams were prepared to estimate the reliability and availability of each function under the stipulated operating conditions. Initial and expected scenarios were analyzed to define risk-mitigation actions. The inherent availability of the ITER CSS expected after implementation of mitigation actions was calculated to be 99.80% over 2 years, which is the typical interval of the scheduled maintenance cycles. This is consistent with the project required value of 99.9 ± 0.1%. A Failure Modes, Effects and Criticality Analysis was performed with criticality charts highlighting the risk level of the different failure modes with regard to their probability of occurrence and their effects on the availability of the plasma operation. This analysis defined when risk mitigation actions were required in terms of design, testing, operation procedures and/or maintenance to reduce the risk levels and increase the availability of the main functions.     

ASDEX Upgrade Discharge Control System—A real-time plasma control framework

ASDEX Upgrade is a fusion experiment with a size and complexity to allow extrapolation of technical and physical conditions and requirements to devices like ITER and even beyond. In addressing advanced physics topics it makes extensive use of sophisticated real-time control methods. It comprises real-time diagnostic integration, dynamically adaptable multivariable feedback schemes, actuator management including load distribution schemes and a powerful monitoring and pulse supervision concept based on segment scheduling and exception handling. The Discharge Control System (DCS) supplies all this functionality on base of a modular software framework architecture designed for real-time operation. It provides system-wide services like workflow management, logging and archiving, self-monitoring and inter-process communication on Linux, VxWorks and Solaris operating systems. By default DCS supports distributed computing, and a communication layer allows multi-directional signal transfer and data-driven process synchronisation over shared memory as well as over a number of real-time networks. The entire system is built following the same common design concept combining a rich set of re-usable generic but highly customisable components with a configuration-driven component deployment method.We will give an overview on the architectural concepts as well as on the outstanding capabilities of DCS in the domains of inter-process communication, generic feedback control and pulse supervision. In each of these domains, DCS has contributed important ideas and methods to the on-going design of the ITER plasma control system. We will identify and describe these essential features and illustrate them with examples from ASDEX Upgrade operation.     

ITER prototype fast plant system controller

ITER CODAC Design identified the need for slow and fast control plant systems, based respectively on industrial automation technology with maximum sampling rates below 100 Hz, and on embedded technology with higher sampling rates and more stringent real-time requirements. The fast system is applicable to diagnostics and plant systems in closed-control loops whose cycle times are below 1 ms. Fast controllers will be dedicated industrial controllers with the ability to supervise other fast and/or slow controllers, interface to actuators and sensors and high performance networks (HPN).This contribution presents the engineering design of two prototypes of a fast plant system controller (FPSC), specialized for data acquisition, constrained by ITER technological choices. This prototyping activity contributes to the Plant Control Design Handbook (PCDH) effort of standardization, specifically regarding fast controller characteristics. The prototypes will be built using two different form factors, PXIe and ATCA, with the aim of comparing the implementations. The presented solution took into consideration channel density, synchronization, resolution, sampling rates and the needs for signal conditioning such as filtering and galvanic isolation. The integration of the two controllers in the standard CODAC environment is also presented and discussed. Both controllers contain an EPICS IOC providing the interface to the mini-CODAC which will be used for all testing activities. The alpha version of the FPSC is also presented.