ITR-IEBH-108-3 v1.0
TITLE
ITER Engineering Basis Handbook Vol. 1: Genesis, Design and Evolution
Chapter 8 - Managing the Design and Construction of ITER Section 3 - Project Management
CHIEF EDITOR
Dr. Gianfranco Federici CHIEF EDITOR'S EMA IL
gianfranco.federici@euro-fusion.org October 15th, 2026
This work has been carried out within the framework of the EUROfusion Consortium, funded by the European Union via the Euratom Research and Training Programme (Grant Agreement 2025 No 101052200 — EUROfusion). Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Commission. Neither the European Union nor the European Commission can be held responsible for them. The views and opinions expressed herein do not necessarily reflect those of the ITER Organization.
ITER Engineering Basis Handbook
About the ITER Basis Engineering Handbook This handbook consists of two volumes which describe the ITER design from its inception up to the design, construction and assembly in 2025. The handbook is not designed to be read as a continuous sequence of chapters. Instead, it is composed of focused, self-contained sections that address specific topics. Each chapter can be read and understood independently, allowing readers to engage with the material most relevant to their needs without requiring familiarity with preceding chapters. As a result, the reader will find certain overlapping content in chapters. It is to be noted that at the time of writing, the design for some systems is still on-going. Therefore, the reader should consider that whilst there is significant value of this important point-in-time study, an update would be required as the Project progresses. A broad Project overview is given in the first volume, to provide the reader with background information necessary to understand the context in the subsequent moredetailed chapters of the second volume, dedicated to the individual systems composing ITER. For the overall table of contents of the Handbook and to access each one of the chapters, please refer to https://www.iter.org/scientists/iter-technical-reports.
Authors and Contributors of this Chapter This chapter is authored by Stefano Chiocchio, Richard Hawryluk, and Bill Spears, and coauthored by the Handbook Editors Federico Casci, Gianfranco Federici, John How, Juan Knaster, Akko Maas, Masanori Onozuka, René Raffray, and Gabriella Saibene, with contributions from Roberto Hinojosa and Jesus Izquierdo.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. i
ITER Engineering Basis Handbook
Volume 1 GENESIS, DESIGN AND EVOLUTION
Chapter n. 8 MANAGING THE DESIGN & CONSTRUCTION OF ITER
Section n. 3 PROJECT MANAGEMENT
Table of Contents 8.3
Project Management .................................................................................................... 1
8.3.1
Summary of Challenges ........................................................................................... 1
8.3.2
Technical Management and Control ........................................................................ 2
8.3.3
Cost and Schedule.................................................................................................. 16
8.3.4
Governance............................................................................................................ 26
Glossary …………………………………………………………………………………………………………………………….30 References ........................................................................................................................... 31
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. ii
ITER Engineering Basis Handbook
Chapter 8 MANAGING THE DESIGN & CONSTRUCTION OF ITER 8.3
Project Management
8.3.1
Summary of Challenges
The ITER Project, after the International Space Station, is the largest and most complex scientific project in the world. The design, fabrication, assembly and testing pose formidable challenges as will be discussed. The components in ITER are at a scale and complexity greater than in any existing fusion facility driven in large part by physics requirements and those associated with being the first licensed nuclear fusion facility. To support the technical challenges has required extensive research and development as well as prototype fabrication to increase the technological readiness level and ensure that the components can be manufactured. Tokamak fusion facilities are highly integrated due to the proximity of the magnetic coils, heating, and heat and particle extraction systems to the vacuum chamber, where the fusion reactions occur. The implication is that a change to one system can impact another system in both obvious and subtle ways. This has strong implications for the need for systems integration and engineering, configuration control and quality assurance. Furthermore, the underlying understanding of plasma behavior and performance was still being developed when the ITER Organization, responsible for project delivery, was formed (and in some
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 1
ITER Engineering Basis Handbook
areas still is evolving) requiring targeted changes to the design requirements to ensure that the programmatic goals were met. Changes to the design have not only technical implications but also cost and schedule implications, which in a large project must be managed carefully. While the management of a first-of-a-kind scientific project is always challenging and there is now an extensive literature on this, an international project has specific challenges as well as advantages. ITER project management has an important dual function. First is to deliver the project on cost, schedule and meet its performance objectives and second to work with a diverse group of stakeholders by keeping them informed about developments and getting their support. As signatories to the ITER Agreement, the seven ITER Members contribute to the cost of project design, construction, operation and decommissioning, and will share the experimental results and any intellectual property generated by the project.
8.3.2
Technical Management and Control
8.3.2.1
The ITER Systems Engineering Approach
ITER is a tightly integrated system of diverse technological components with many complicated and intertwined interfaces. Although the function of the basic components of the reactor was well defined at the very initial stage of the project, the design of the whole reactor is a complex, iterative process in which the behaviour of any single component (and of the whole facility) can be highly dependent on the behaviour and/or structure of other components. Minor changes to one component may result in major changes in the behaviour of one or several other components. In such a complex project, the best engineering management approach is to employ a formal systems engineering methodology to ensure a unified approach that defines and allocates requirements for facilities and systems, permits to establish configurations (i.e. combinations of systems, components, etc. and facilities) which satisfy the stated needs, allows defining the interfaces and controlling them among different systems and different working teams, and provides the basis to manage the impact of changes that may occur during the lifecycle of the project. The ITER systems engineering methodology was adopted since the establishment of the Engineering Design Activities phase in 1992 (See Ref. 8.2.2-1). However, until the creation of the ITER Organization, the project lacked a formal Quality Management Program, and the design activities were controlled through ad hoc work instructions. With the approval of the FDR 2001, a formal system to control the change to the baseline was introduced, but only after the establishment of the ITER Organization in 2007 the project adopted a formal Management and Quality Program (MQP, see section 8.2). which includes procedures, plans and working instructions for the realisation of the project. The system engineering approach was implemented
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 2
ITER Engineering Basis Handbook
through the System Engineering Management Plan, based ISO 15288, similar to what is implemented in other Projects of similar complexity. Essential for the successful implementation of this approach is to have: • • •
•
Clear information of what work needs to be done. Clear responsibility and authority for each organizational group to set up and deliver the work assigned to it. Clear and readily available current information on the status of the design to help decision making. This is particularly important since information sharing amongst all actors of the project is vital. Traceable and well understood processes for making design decisions at the lowest practical level in the organization, while at the same time maintaining the authority of groups and individuals charged with the integration of the overall design. A system for change control, efficient and transparent to all elements of the organization and collaborators.
The key elements of the systems engineering implementation in ITER are • • • •
The planning and control of the design activities The management of the requirements The management of the interfaces The establishment and management of the configuration including the management of the technical documents.
Figure 8.3.2.1.1 presents a simplified illustration of ITER systems engineering process and associated history from the conceptual design phase (CDA), engineering design phase (EDA) with specific R&D efforts for the critical components, and through the present construction project phase, to future operations & maintenance phase and decommissioning phase. Following the fundamental systems engineering practices, the figure summarizes how the ITER design has been evolved with project phases, various input requirements and regulations, then how the final design has been verified and validated through the procurement and assembly / construction. The figure also shows some of the difficulties which have been encountered through the process / history, addressing the complex set of scientific, engineering and integration issues in a selfconsistent project which led to substantial evolutions of the design, sometimes resulting in significant differences compared to the original.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 3
ITER Engineering Basis Handbook
CDA
EDA Concept Selection (FEAT, etc.)
GDRD (Requirements)
System Requirements High cost resulting in a reduced objective and cost design
ITER Site Selection to France EDA
Regulatory Interactions
First-of-kind licensing activities
Site-Specific Requirements (Regulations)
Regulatory License Permit
Engineering Design
Operations Upgrades Decommissioning & & (TBM, etc.) Dismantling Maintenance
(Non-Site-Specific)
Critical Component Detailed Design
EDA R&D Final for Design Design Verification Report (L-Projects, etc.)
Commissioning (Plant Validation)
Final Concept of Operations
System Verification System Integration
Final System Requirements
D Sub-system
Detailed Design (Sub-system requirements)
Procurement Arrangement
Verification Assembly & Installation
Procurements and Manufacturing Design
Additional interfaces due to the fragmented procurement sharing
1
Additional physical and functional integrations due to the fragmented procurements
Component/System Testing & Inspection
Site Preparation & Hardware Fabrication
Maintenance for Stored Items Additional efforts for the temporary stored items Low design maturity for some components / systems; numerous deviations, nonconformities, and design changes
G. Federici et al. | ITER Design Handbook Primer| April 2025
Figure 8.3.2.1.1 ITER systems engineering process and associated history[1].
8.3.2.1.1
Requirements Management
In most Projects the requirements that must be met by the plant are specified upfront by the customer, quite often after discussion with the regulatory bodies; in many cases the customer also chooses and imposes industry codes and standards (such as ISO, ASME, IEEE and ASTM) to be adopted in the engineering work. In the case of ITER, the definition of the programmatic and technical objectives of ITER has been achieved under the direction of the ITER Council by working groups appositely established for this (as was the case by the Special Woking Group in 1992 at the launch of the EDA phase and then the selection of reduced technical objectives in 2001). However, this set of high-level objectives needed to be translated into a set of operational and technical requirements (both functional and physical requirements) that are of direct use to the designer. The functional type and physical type of requirements need to be properly traced. In addition, the requirement propagation goes not only to the design of the components and systems, but also to the fabrication and operations. Then, some of the requirements will be finally validated during the testing operation and/or even during the commissioning. To properly implement the systems engineering process as described above, the requirements need to be properly tracked by a designated engineering group. Furthermore, because of the one-of-a-kind nature of ITER, the Project did not have since its onset a complete and clearly defined body of regulatory and in many cases industrial documents to serve as requirements to be met by the design.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 4
ITER Engineering Basis Handbook
The ITER Project had therefore to develop the design and engineering requirements for the plant and for each part of it. The output of this effort is organised to facilitate the control of these documents. During the EDA, design requirements in line with the project specification were developed at the project level and derivatively for each major system defined by the PBS, and recorded respectively in a general design requirements document and in the first section of the design definition document for each major system. This process evolved after the establishment of the ITER Organization: •
•
The programmatic objectives defined by external special working groups on mandate of the ITER Council were collected in a document called Project Specification[2]. These objectives represent what in other projects call client requirements, so the control and update of this document are exclusively under the responsibility of the ITER Council itself. The results of the translation of the project specifications into a set of technical requirements applicable to the whole facility and its lower elements were organized in a set of documents that include the Project Requirements (PR) and its annexes and at lower level the System Requirements Documents (SRDs) and Sub-System Requirement Documents (SSRDs).
The process to ensure (ref 8.3.2-2) the consistency of the requirements throughout the whole project and verify the achievement of the requirements in the design solutions is schematically illustrated in the figure 8.3.2.1.1 above. In addition to the documents in which the requirements are collected, an important role is played by the Requirements Propagation Matrices (RPM) which establish the relations between higher level requirements and lower-level specifications and the Design Compliance Matrices (DCM), where the results of the verification of the design are collected. 8.3.2.1.2
Development of the Design and Verification and Validation
To mitigate the risk on the development of the design and converge on a satisfactory solution, the ITER design process is divided into three phases: Conceptual Design (CON), Preliminary Design (PRE) and Final Design (FIN), which in fact are linked with the three types of in-kind procurement arrangements as discussed in Section 8.3.3.1 below. During this process the technical requirements are continually broken down into lower-level requirements and, at the same time, the design is advanced while implementing the requirements from the phase before. At the end of each phase design reviews are organized (CDR, PDR and FDR) that ensure the compliance of the design solutions adopted with the requirements and interfaces.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 5
ITER Engineering Basis Handbook
The implementation of the design process progresses recursively, with the requirements being allocated to lower elements and the results of the design solutions being integrated in the upper system. This is shown schematically in Figure 8.3.2.1.2.1 below.
Figure 8.3.2.1.2.1 ITER design sequence.
The control of the design activities is done through: • •
• •
•
The preparation and acceptance of a Design Plan for each system to be designed in accordance with the Plant Breakdown Structure; The implementation of the Transverse Functions that are responsible to analyse the global project needs and refine them into detailed requirements/constraints and/or design input for each sub-element of the project; The performance of periodic Design Integration Review (DIR) to ensure the consistency among the design of each element; The verification of the compliance of the design with the specified requirements through the System Design Review at the end of each phase and the Design Compliance Matrix that provides evidence that the product of the phase is fulfilling the input for the activity phase; Definition and development of interfaces as the design evolves by mutual agreement among the interfacing systems responsible officers.
The generic design workflow comprised the following activities that were often performed in parallel: •
Architecture definition, whose purpose was to generate system architecture alternatives and to select the most appropriate one that framed stakeholder concerns and met system requirements. The output of this activity included a set of documents such as Function Tree, Requirement Allocation Matrix, Functional Flow Block Diagram (FFBD), Process Flow Diagram (PFD), Instrumentation & Control Architecture Diagram, Piping and
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 6
ITER Engineering Basis Handbook
•
•
Instrumentation Diagram (P&ID), Interface Sheet-IS (Preliminary Functional and Physical Interfaces), System Detailed Performance Definition-SDPD, Single Line Diagram (SLD), or One Line Diagram, Arrangement or Layout Drawing. Design definition, whose purpose was to provide sufficient detailed data and information about the system and its elements to enable the implementation (manufacturing, assembly, installation, etc.) consistent with the selected system architecture. Typical outputs of this activity were Systems Design Description (DD), lower-level technical specifications, Detailed Models, Bill Of Material (BOM), Item Type List, Interface SheetsIS, Part Drawings, Assembly or Component Definition Drawing. System Analysis, whose purpose was to provide quantitative evaluation that supports the development, providing confidence in the performance, dependability, integrity and quality of the selected architecture/design. The output of these activities was generally in the form of engineering analysis and calculations, Return of Experience (ROX) and Research & Development (R&D) reports.
The execution of these complex tasks required in many cases specialized resources obtained through contract with Industry either directly by the ITER Organization or through specific contracts issued by the Domestic Agencies. For instance, in 2008 ITER placed a so called “Pre Architect Engineering” contract to finalize the conceptual design of the ITER buildings and site, and to prepare the associated baseline documents specification. At the completion of this work, the European Domestic agency placed a new Architect Engineering contract to execute the detailed design of ITER buildings, including electrical plant and services systems, follow-up of interfaces and changes, integration of all the design in Catia 3D models, definition of the architectural choices, follow-up of the construction work, support of the site coordination and administration, provide topological survey, monitor the pro-rata account, and provide data bases to follow-up exchange between Fusion for Energy and suppliers. This design activity started with an engineering value assessment allowing to identify any possible optimisations on the buildings and associated systems which were further considered during the preliminary design (see Ch.10.2.5) At the end of the manufacturing stages, the validation of the product is performed, to demonstrate the compliance of the product with the stakeholder requirements and with expected conditions of use. This is typically performed at the product acceptance and during the commissioning phase before the system is released for use. 8.3.2.1.3
Management of the Configuration
The ITER Configuration Management (CM) process has been implemented to establish and maintain consistency between the project’s requirements, the intended and achieved performances of the product, and its technical documentation, throughout the life cycle of the project, as represented schematically in the Figure 8.3.3.1.2.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 7
ITER Engineering Basis Handbook
As discussed in Section 7.2 its scope was initially to control the changes introduced by the project with respect to the Final Design Report that in 2001 had been handled to the participants members to negotiate their contribution. The main objective then, was to ensure that these changes were properly recorded and communicated to the potential members and their implications on the cost, schedule and performance had been properly identified. The CM process itself evolved together with the evolution of the project, to ensure that the consistency of the project with the stated technical objectives and with the licensing documentation were maintained during the realization phases of the project. The main activities of the ITER configuration management are summarised below: The configuration identification is the process of identifying the items that are critical for the achievement of the project missions, selecting the technical documentation that provides the functional and technical characteristic of these items, ensuring that each item and document is uniquely identified and establishing the project baselines, i.e. the configuration of the entire product that serves as a unique reference for the whole project and a point of depart in case of changes. The ITER Product Breakdown Structure (PBS) shown in Figure 8.3.2.1.3.1 provides a hierarchical and functional map to identify all Systems, Structures and Components that form the ITER plant. The documentation is similarly organised in a hierarchical structure, with at the top the documents that describe the objectives, performance and safety characteristics that the plant must achieve, and at the lower level the propagation of these requirements to the different systems and sub-systems and their functional and physical characteristics.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 8
ITER Engineering Basis Handbook
Typical structure of the PBS
Top level and Plant Breakdown Structure level 1
Figure 8.3.2.1.3.1 ITER top-level Plant Breakdown Structure.
Configuration control is the process to control the evolutions of, or departures from, agreed configuration baselines. This activity comprises the evaluation of the need for a change, its formulation, the execution, the impact on analysis, and the approval or rejection of the change proposals at the appropriate levels within the Project. The ITER Project change control procedure defines different levels of approval of the change in accordance with the level of impact of the proposed changes. As the impact normally includes a modification to one of the controlled documents (e.g.: a component specification) the level of impact is evaluated based on the higher documents impacted as schematically shown in Figure 8.3.2.1.3.2 below.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 9
ITER Engineering Basis Handbook
Figure 8.3.2.1.3.2 ITER top-level Plant Breakdown Structure.
Configuration control is also executed during the manufacturing phase. In this case Deviation Requests and Non-Conformities arising during the realisation process must be assessed and disposed. When needed new version of the documents or drawings (as built, as installed) describing the modified items must be issued. 8.3.2.1.4
Management of the Interfaces
One of the main challenges in a project involving many systems and dispersed entities in charge of the design is the management of the concurrent design and development activities of systems which are strongly dependent on each other, as could be the case of utility systems that provide services to other parts of the plant or plant systems that have complicated physical interfaces due to spatial proximity or transfer of mechanical loads. In ITER a formal process is used to identify the interfaces among different systems and sub-systems, to define the interface requirements and to control the implementation of these requirements in the design solutions. The scheme below describes the relations between the different phases of the process, the documents that are generated and controlled, and the verification gates at which these documents must be verified and approved. In the Figure 8.3.2.1.4.1 below the process for the management of the interfaces is schematically represented: •
• •
The Interface Control Document (ICD) represents the agreement between the two interfacing systems designers and defines what data is required, when the information is needed, and by whom it has to be provided, and for which use; The Interface Sheet (IS) identifies the list of interfacing components and the full set of Interface Requirements (IRs) at the Interface Points (IPs); The Interface Definition Documents (IDDs) capture the design solution which implements the Interface Requirements on one side of the interface;
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 10
ITER Engineering Basis Handbook
•
The Interface Compliance Matrix (ICM) is a tool (like the Design Compliance Matrix used to verify the compliance with the requirements discussed in chapter 8.3.2.1.1 above) that enables the monitoring and control of the evolution of the interface requirements implementation into the system design and the justification of the achievement of the IR objective.
Figure 8.3.2.1.4.1 Overview of the interfaces management process.
The status of the documentation generated by the process is controlled by predefined reports that provide, among other items, the list of ICD, the status of ICD definition by PBS, and the report on the modified interface sheets. 8.3.2.2
Hardware and Software Available
Many software (SW) packages are used for the ITER engineering activities, including SW for design, such as CATIA by Dassault Systems, verification and analyses tools (such as ANSYS) or SW for data management and document management. ITER employs either commercial software used without any modifications or customized to the ITER needs, or ad-hoc software developed either in house by the ITER team or by laboratories under specifications provided by ITER. The selection or development of the appropriate Software for the management of the ITER activities is extensively discussed in section 7.2.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 11
ITER Engineering Basis Handbook
8.3.2.3
A centralized Approach to Engineering Data Management
The availability of a centralized control of the data generated throughout the different engineering activities was recognized as a critical factor for the success of the Project since the establishment of the ITER Organization. The specific aspect of the management of the ITER technical documentation is discussed in section 7.2. However, other information is generated throughout the life of the project such as drawings, non-conformities reports, vendors sheets, commercial items technical characteristics, etc. The ability to access and retrieve in a timely manner these design and as-installed information associated with the components in a plant is vital to achieve cost-effective construction and operation, to maintain the configuration of the plant, to be able to take informed decision in case of changes, to assess the impact of non-conformities during the construction phase or to support plant upgrades during the operations. At the time the ITER organization was being established, most of the nuclear and engineering industry was still in the transition from essentially paper-based information management to a computer-based control and distribution of the data. Several challenges were being found in this transition. One could see for instance the 2004 report by the NIST (National Institute of Standards and Technology) on the “Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry” (NIST GCR 04-867) which conservatively estimated at 15.8 billion US$ for year 2002 the efficiency losses in the U.S. capital facilities industry resulting from inadequate interoperability. Interoperability is defined here as the ability to manage and communicate electronic product and project data between collaborating firms and within individual companies’ design, construction, maintenance, and business process systems. Interoperability problems in the capital facilities industry stemmed from the highly fragmented nature of the industry and were further compounded by the large number of small companies that have not adopted advanced information technologies. The challenges identified in studies performed by NIST were the following: • lack of understanding on the part of industry participants of how to achieve integrated information and workflows through the application of information technology; • gaps in the availability of information technology tools and data standards to support integrated information and workflows throughout the facility life cycle; • industry structure and business practices, including procurement practices and regulatory, insurance, and contractual requirements, that present obstacles to integrated work and information flows. In this respect the case of ITER was not different from the general industry landscape, as also in ITER there Is a large fragmentation of the entities involved in the realization of the project, with the notable additional difficulty that at the onset of the Project all procedures for the management of the engineering activities and contracts had to be established from scratch, the
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 12
ITER Engineering Basis Handbook
users needed to be trained to their application and that in most cases the procedures had to be progressively improved to fit the ITER needs. By 2004 ITER had, however, successfully developed IDM (see 7.2.3) and by 2006 was using it for design documentation and to re-store versions of related drawings and models from CATIA at specific decision/approval points such as definition of the baseline or technical specifications for procurement arrangements. A first attempt to integrate all engineering data in a single software was done by assessing the DASSAULT PLM System (Matrix) in 2010, However at the conclusion of the assessment phase, it was decided not to proceed with this approach, because of the investment and resources needed to implement a single system, the cost of licenses for the IO and the DA’s and the risk that some the functionalities that ITER had already developed and were working well, could not be easily maintained. In consultation with experts from Industry and software vendors, and mirroring the general tendency in industry, ITER adopted a system to integrate in house developed tools with commercially available tools. However, some of the commercial software still required significant customization to fit the ITER needs and this has proven to be both costly and time-consuming. The lack of a well-defined Data Management Strategy including the availability of resources has resulted in a progressively fading support to this initiative, and to the growth of tools purchased or developed on demands of the different units to address similar or overlapping scopes resulting in a general difficulty to access valid data by the users. The complexity of the software landscape was reported to the ITER Council in 2023 as it is summarized in Table 8.3.2.3.1 below.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 13
ITER Engineering Basis Handbook
Table 8.3.2.3.1 Software used for the management of engineering data in 2023[3]
Name
Scope
IDM
ITER Document Management (an ICP application), used for most of ITER’s documents. Some exceptions exist for construction activities, where documents were managed inside SmartPlant (see below).
ICP
ITER Collaborative Platform hosts many engineering data sets and manages about 30 engineering processes. Among them are the magnet manufacturing database, 2D diagram and 3D model approval.
3DX
Managed project change requests (previously done in ICP), component management (much of it done before and/or in parallel in ICP), Applicability and scope of engineering documents and HOP (‘Hand-over- Package’) management,
Smart Plant
Construction Work Packages, Handover Packages (HOP), Material Management
SAP PM
Plant maintenance module of SAP
Enovia/Catia
3D CAD models and their management
Aveva
2D diagram authoring tool (including 3d representation, fluid systems)
See Vision
Yet another 2D authoring tool (control, electrical diagrams)
ESX
Yet another 2D authoring tool (cubicles)
Doors
Project requirement management
Primavera
Resource Loaded Scheduling tool
On top of the above, dozens of widely used excel spreadsheets were in use at that date to manage engineering data of various disciplines. Such distribution and variety of tools presented several challenges both for engineers and for SW developers such as the difficulty to find the applicable version of the diagrams and related information or the heavy burden to customize and maintain the configuration of these tools. Furthermore, some of the proprietary tools rely on data stored in specific formats and that posed serious concerns about the ability to retain full control of all data for the entire duration of the project. MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 14
ITER Engineering Basis Handbook
To redress the situation, it was decided in 2023 to move towards a single data management system that provides a central repository and hub for all relevant engineering data. The system has to manage and display the approval state and the applicability of the data. The organization of the data is based on the existing Plant Breakdown Structure (PBS) described in subsection 8.2.3.1), for the data affecting the ITER systems, structures and components and the Geographic Breakdown Structure (GBS) for the environmental and contextual data (SEE Figure 8.3.2.3.1).
Figure 8.3.2.3.1 Organization of the Engineering data based on PBS or GBS
The backbone for the entire engineering data management is the ITER Collaborative Platform (ICP) , having considered that this was already well known by all ITER stakeholders who have used IDM and it was open to all persons working for the ITER project without any additional cost, provided efficient security settings for access and change authorization, and it was entirely in-house developed based on the Microsoft ASP.NET and MS SQL. The above strategy is still in implementation. In an initial step all tools in production have been modified to share their data with ICP, leading to all engineering data being viewable through a single system as shown in figure 8.3.2.3.2 below.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 15
ITER Engineering Basis Handbook
Figure 8.3.2.3.2 Centralization of data management in ICP
After this phase, the progressive decommissioning of the existing tools and the integration of the needed functionalities in ICP has been pursued; to date the status is as follows: • • •
the decommissioning of 3DX has been achieved in first quarter 2025; the completion of the decommissioning of Smartplant and Doors is foreseen by end 2025; the integration of schedule, financial and contractual data in ICP is planned for 2026.
In addition, an AI -driven search chatbot (see also 7.2.3) has been introduced: this helps find information in IDM documents through semantic search, that focuses on understanding the meaning and intent behind a user's search query, rather than just matching keywords.
8.3.3
Cost and Schedule
8.3.3.1
In-kind Procurement
The contributions from the ITER Members are mainly in-kind in the form of engineering, completed components, systems or buildings. Through the allocation of procurement scope to the ITER Members, the aim was that each Member would be better prepared for the step after ITER, the conception and realization of a fusion facility that will demonstrate industrial-scale fusion electricity. For all Members, the benefits of participation are significant: by contributing a portion of the project's costs, Members benefit from 100 percent of the scientific results and all generated intellectual property.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 16
ITER Engineering Basis Handbook
Figure 8.3.3.1.1 IO and Domestic Agencies formalize the delivery of specific components via Procurement Arrangements. The Domestic Agencies issue contracts to industries and laboratories via contracts to execute the work.
Each Member has created a Domestic Agency to fulfil its procurement responsibilities to ITER. These agencies have their own budget, and contract directly with industry. Collaboration between the ITER Organization and the Domestic Agencies over the years has been enhanced by implementing state-of-the-art collaborative CAD design tools, specific document management systems, integrated project teams for specific components or projects but also joint management decisions via the Executive Project Board that brings together IO DG and the DA Heads. These are discussed in more detail in Chapter 7.2 and earlier in this section. Per the ITER Agreement, Europe is responsible for the largest portion of construction value (45.5 percent); the remainder is shared equally by China, India, Japan, Korea, Russia and the United States (9.1 percent each). The value of specific components and systems to be delivered by each Member, the so called “procurement packages” was negotiated as part of the signature of the ITER Agreement and consolidated in a series of accompanying files called “Common Understandings”.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 17
ITER Engineering Basis Handbook
Figure 8.3.3.1.2. Allocation of the main DA procurement packages among the parties. The units of the vertical axis are kIUA.
In-kind procurements are complemented by direct procurements managed by the ITER Organization, funded (in the above proportions) by the Members. IO and DAs formalize the corresponding responsibilities on those procurement packages via Procurement Arrangements (PAs). Each PA establishes the management and technical specifications including the quality assurance requirements for the delivery of structures, systems and components in three different types: •
•
•
Build-to-print – The IO completes the final design of the components subject of the PA. The DA is responsible for manufacturing, for example the first wall or the vacuum vessel. In some cases, the IO sub-contracts the DA to complete the design or perform R&D. Detailed Design – The IO completes the preliminary design of the components. The DA is responsible for the final design and the manufacturing. Examples include several elements of the neutral beam injectors and most of the diagnostics. Functional Specifications – The IO completes the conceptual design. The DA is responsible for the preliminary design, final design, and manufacturing. Examples include the buildings, the remote handling system, and the cryoplant.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 18
ITER Engineering Basis Handbook
8.3.3.2
Cost Reporting
DAs are responsible for the cost and delivery on schedule of the components meeting the technical requirements. They are only responsible for reporting on costs to their respective governments. The DAs provide information about the status of the PAs as part of a high-level integrated project schedule, which is used to manage the Project, using Primavera (P6). This includes the deliverables managed by the IO. Each DA maintains more detailed schedules for the management of the contracts under their responsibility; however, these are not directly included in the project schedule. The level of detail in Primavera has varied throughout the project history. Too many schedule elements, besides being difficult to track and update, would generate an unmanageable number of links, making the Project schedule extremely fragile. However, too few elements create the risk of not tracking some important issues. Cost reporting by the IO to stakeholders is only for the IO scope based on input from its financial system, SAP, and the software package COBRA. The IO uses the results from Primavera and the cost reporting to perform earned value management system (EVMS) analysis for the IO scope using the standard Electronic Industries Alliance Standard 748 (EIA-748). The DAs use their internal reporting systems to monitor costs. Schedule and cost variances are tracked. Given the above procurement scheme, the total cost of the project, summed over all Members, is not available but it is widely accepted that costs for some procurements significantly exceed the originally estimated value. The common understanding of values was established at the time of signature of the Joint Implementation Agreement (JIA) in 2006, under several caveats indicated in 2001 regarding value and schedule[4]: •
•
"As recognized by experts from the four Parties, who have reviewed the details of the component/systems costing which support these estimates, they are not intended to be the lowest values which could be obtained. There is room to achieve savings in some areas already identified and more might be found through the needed and expected industry feedback on design to optimize manufacturing processes." "The lead-times for the different components of ITER vary widely. Also, some items – including the buildings, parts of the cryostat, magnets, and vacuum vessel - are logically on the critical path whereas others can be delayed until an ultimate date when they will become part of the critical path. In addition, cash flow may pose constraints in conflict with the need to make procurements at a date compatible with the smooth planning of implementation. For the purpose of evolving this schedule, procurement is assumed to occur such that systems/components are delivered just in time, i.e. at the latest time, on the critical path, for assembly and installation/construction, in accordance with the construction logic."
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 19
ITER Engineering Basis Handbook
•
"The critical path of the plan starts with the regulatory licensing procedure and the construction of the tokamak buildings. To start excavation immediately at T = 0, the manufacturing design of the complex must be complete by then. The contract for the vendor’s preparation of the complex thus has to be awarded at least twelve months before. Considering a period for the procurement bid process, the tender documents have to be released 18 to 24 months before T = 0. After the establishment of the ILE, if the license process can be completed in less than 24 months, the construction period defined from the establishment of the ILE to first hydrogen plasma discharge is minimal, equal to ten years. If the regulatory process takes more than two years from establishment of the ILE, the construction period becomes correspondingly longer."
Not all these assumptions turned out to be valid. Furthermore, the lack of design maturity, which varied from one procurement package to another, has a strong impact in estimating the value of the procurement packages. The implications of this were not appreciated at the time. The IO maintains four major budget lines during the construction phase: Direct Capital, which captures the major procurements; Management and Support of the ITER Organization (i.e. IO staff and infrastructure), limited R&D (the R&D in support of the procurement arrangements done by the Domestic Agencies is not captured here), and the Reserve Fund used by the Director General to address cost impact of IO driven design changes. Beyond that is an estimate of operation costs per year, an estimate of costs during a deactivation phase, and finally a cost for decommissioning the site. The budget is in ITER Units of Account (kIUA, $1000 US in January 1989). Delivery of scope results in an allocation of credit. The values of the in-kind PAs provided, except for design and scope changes including scope transfer from the IO has not changed from those in the ITER Agreement. Deviations of cost from the originally estimated value are the responsibility of the Domestic Agencies. Expenditures by the IO, in management support, direct capital costs including for example assembly, and changes agreed to be covered by the Reserve Fund, require financial contributions from the Members to reflect actual and estimated costs in real currencies, though also expressed in ITER Units of Account. The Project has undergone several major baseline changes as reflected in 7.1. The management support costs for the IO reflect increased number of staff over a longer period, which also reflects increased design activity and coordination with DAs. The IO staff increased significantly since the formation of the Project in 2007 reaching 1100 staff in 2023. Relative to the staffing estimates developed during the EDA, actual staffing requirements have been higher than originally anticipated, contributing to the observed cost growth. In addition, schedule delays have extended the period over which these resources have been required, resulting in a higher cumulative number of person-years than initially planned. The re-baselining of the project in 2024 described in Chapter 7.1, with its major design revisions and schedule changes, implies a further significant change in scope and annual cost profiles. At
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 20
ITER Engineering Basis Handbook
the time of writing, while the principle is agreed, this change is in the process of being finalised with the Members. The Reserve Fund was established in 2015, and the size of the Reserve Fund was implemented in 2016. The Reserve Fund is identified as a separate budget category and represents a firm commitment of the Members to cover design related issues to that level. The Reserve Fund is a valuable tool for the Director-General to expedite and implement decisions. The “Reserve Fund Management Plan”[5] defines what changes are eligible for this funding and illustrates which are not. The changes which are eligible include: a. “IO-directed changes in the requirements specified or referenced in Procurement Arrangements (PAs) or contracts placed by the IO and DAs under execution which have a cost impact on the DAs and/or IO. As further clarification, whenever the contract is signed, if the related technical specification portions of the contract (and any relevant modification thereafter) have been reviewed and agreed by the IO in writing, such specifications become the reference to be used to determine eligibility; b. Additions to the scope of systems or contracts under execution for improving overall project performance, including tools and materials required during Plant installation; c. Changes to the Project Requirements (PR) (IDM Ref: 27ZRW8 v5.3) and the configurationcontrolled annexes in Section 2.1 of the PR, and the Systems Requirement Documents as they were by 5 March 2015, irrespective of whether they were before or after PA signature, or before or after fabrication or manufacturing contract award; d. Changes in quantity, size, or volume of items without a change in function, e.g. increase in number of radiation sensors after fabrication or manufacturing contract award by the DAs; e. IO-directed changes to the Project Baseline to allow for a design solution that meets project requirements, including requirements for spares and specific consumables which have not been clearly stated in the PA, PR, SRDs, or other document.” 8.3.3.3
Schedule Reporting
Prior to the establishment of the ITER Project, the ITER team developed as part of the 2001 Final Design Report a schedule, which informed the Parties during the negotiation process, as shown in Fig. 8.3.3-4. It shows 8 years between issuing the license and first plasma but the period before, for detailed design and procurement selection is left unspecified. The text notes large uncertainties associated with the Parties budgets and engineering work for Procurement. At the end of the negotiation process in 2005, the working assumption was that ITER first plasma would occur in 2016, but the detailed schedule analysis was yet to be developed.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 21
ITER Engineering Basis Handbook
Figure 8.3.3.3.1 Schedule up to First Plasma (ref: Fig 1.8.3.1, FDR-2001 Report).
The ITER Project Schedule has undergone several major revisions in 2010, 2016, and most recently 2024. The schedule revisions were driven by multiple considerations. The response to the design review when the ITER Organisation was formally established in 2007 were primary drivers in defining the first OPS of the new organisation in 2010. At that point the concept of a First Plasma with limited research potential, as part of the commissioning of the machine was introduced, followed up by further installation of components, operation in hydrogen and helium, and commissioning of the heating and current drive systems. Operation in deuterium and deuteriumtritium occurred after this phase. Key milestones are summarized in Table 8.3.3.3.1. In response to delays in the design work and construction of components, a new baseline was developed in 2016. Conceptually, this was like the previous 2010 schedule with First Plasma followed by a series of outages and research phases. Deuterium and deuterium-tritium operation, which constituted the beginning of nuclear operations, would begin in 2035. More time was allocated to the research activities than in the 2010 baseline prior to deuterium operation. In response to the impact of the COVID pandemic, the difficulties arising from a complex international situation, failure of the vacuum vessel to meet the tolerance specification, and corrosion cracking in the helium cooling lines on the thermal shields, the Project developed in 2024 a new baseline that was conceptually significantly different than the 2016 baseline, and much closer to the 2001 original operation plan. This schedule is currently under review by the ITER Council. The milestone for a First Plasma with limited research potential, was eliminated. Major in-vessel components will now be installed before the first research operation period, enabling the start of research operations and the commencement of the research program in the very first operating period. This phase of operations will also include deuterium operation albeit
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 22
ITER Engineering Basis Handbook
with restricted neutron fluence to enable the completion of installation activities at a later stage. The actively cooled beryllium first wall plasma-facing components were removed from the plan and replaced with tungsten tiles (inertially cooled in SRO), thus eliminating various health and safety risks and minimizing the likelihood in-vessel water leaks eliminating various health and safety risks. The electron cyclotron heating power will be increased to ensure sufficient power to overcome the L-H power threshold. By advancing deuterium operation and increasing the ECH power, valuable experience with H-mode operation will be obtained. In addition, high current operation in L-mode will enable the commissioning of disruption avoidance and mitigation tools. After the first phase of research operations, further assembly will be performed in preparation for the next phase of deuterium-tritium operation. Key Milestones
Project Schedule 2011
Project Schedule 2016
First Plasma
2019
2025
Start of Research Operations Completion Assembly
Project Schedule 2024*
2034
of 2023
2035
Start of Deuterium 2026 Operation Start of Deuterium- 2027 Tritium Operation
2039
2035
2035
2040
*The 2024 Schedule is currently under review by the ITER Council and has not been approved.
Table 8.3.3.3.1 Major Milestone in Project Schedule.
8.3.3.4
Lessons Learned
The schedule delays reflect a range of contributing factors, consistent with the complexities inherent in delivering a large-scale, first-of-a-kind project. The Project committed to a cost and schedule baseline before the design was sufficiently mature and a schedule before those organizations and people who would deliver it were in place. Even in 2024, significant changes to the design are taking place such as the elimination of beryllium plasma-facing components. This
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 23
ITER Engineering Basis Handbook
is more the norm than the exception for large science projects, which are responsive to scientific and technical developments. An illustration of this is that when ITER FEAT was scoped out, the concepts of internal coils for ELM mitigation and shattered pellet injection for disruption and runaway mitigation did not exist. Lack of experience with tungsten plasma-facing components motivated the start of research operation with carbon plasma-facing components. This has evolved to a design which incorporated tungsten-beryllium and now just tungsten. While the inclusion of new systems is one example of the impact of design maturity, this is a much broader topic. A mature design with procurement commitments is needed to develop a detailed cost and schedule baseline. The design has undergone significant changes to support the procurement and eventual manufacturing of the components. While some systems were relatively mature early on, many were not. The ramifications of ITER being a nuclear facility were also not fully understood and incorporated from the beginning. Another important aspect was the evolution of the organizational and governance arrangements. As the project progressed, the respective roles and responsibilities of the IO and the Domestic Agencies, as well as the ways in which they worked together, continued to develop and mature. In the earlier stages, this evolving framework sometimes contributed to longer decision-making and implementation timelines. Mechanisms introduced subsequently, such as the ITER Reserve Fund, illustrate how the organization adapted its processes to facilitate more timely and effective decision-making. Finally, delays and adjustments to the plan can also reflect the challenge of balancing the need for sufficiently early cost and schedule information to support stakeholder planning and budgetary processes with the evolving level of technical information available to underpin reliable estimates. Particularly in the earlier stages of a complex, first-of-a-kind project, estimates necessarily develop as the technical basis becomes more complete and uncertainties are progressively resolved.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 24
ITER Engineering Basis Handbook
Figure 8.3.3.4.1 ITER Project Schedule 2011.
Figure 8.3.3.4.2 ITER Project Schedule for the Baseline 2016.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 25
ITER Engineering Basis Handbook
Figure 8.3.3.4.3 ITERl Project Schedule issued 2024 and currently under review.
8.3.4
Governance
The governance of the ITER Project was defined by the members, People’s Republic of China, EURATOM, the Republic of India, Japan, the Republic of Korea, the Russian Federation and the United States of America, in the “Agreement on the Establishment of the ITER International Fusion Energy Organization for the Joint Implementation of the ITER Project”[6], subsequently called the ITER Agreement in this document. Several of the key aspects of this document provide important background information on the governance of the Project. The Agreement states that “The purpose of the ITER Organization shall be to provide for and to promote cooperation among the Members…. on the ITER Project, an international project that aims to demonstrate the scientific and technological feasibility of fusion energy for peaceful purposes, an essential feature of which would be achieving fusion power generation.” This introduces the concept that ITER is an international organization, and that the “ITER Organization shall have international legal personality, including the capacity to conclude agreements with State and/or international organizations. It will have the legal capacity to: “conclude contracts, acquire, hold and dispose of property, obtain licenses and institute legal proceedings”. The ITER Council (IC) is the principal organ of the ITER Organization governance and is composed of Representatives of the Members. The Agreement describes how the Council operates and its role in the appointment of the Director-General, adopting and amending proposals by the Director General on Staff Regulations, Project Resource Management, the main management structure, appointment of senior staff, budget, and changes to cost sharing. The IC also appoints members of the Financial Audit Board and defines the terms of reference of the Management Assessor and sets up subsidiary bodies such as the Scientific and Technical Advisory (STAC) and Management Advisory Committee (MAC), among other responsibilities. The Council normally meets twice a year. The Agreement states that “The Director-General shall be the chief executive officer and the representative of the ITER Organization in the exercise of its legal capacity” and act consistently with the Agreement and decisions of the Council. In addition to preparing proposals and reports
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 26
ITER Engineering Basis Handbook
as noted above, the Director-General is responsible for safety and undertakes all organizational measures needed to observe the laws and regulations…” as well as other responsibilities expected for a chief executive. The ITER Council Members not only provide the funding for the Project, but also the legal framework for the functioning of the Project and the Council has oversight of how the Project is managed. The following table outlines the main management and administrative functions and how they are implemented in ITER. Table 8.3.4.1 Relationship of functions to implementation.
Functions
Implementation
Governance
ITER Agreement, ITER Council
Legal framework
ITER Agreement
Liability
ITER Agreement
Financial Rules
ITER Agreement and Project Management Regulations (PRMR)
Cost Financial Accounting
IPSAS
Procurement
ITER Agreement, Implementing Measures and PRMR
Financial Audit
ITER Agreement set up a Financial Audit Board
Management Assessment
ITER Agreement
Employment Regulations
Internal regulations: Staff regulations, Administrative Circulars, and ILOAT
Information and Intellectual Property
ITER Agreement
Nuclear licensing
French regulations
Safety
French regulations
Resource
The Agreement states that the “ITER Organization shall observe applicable national laws and regulations of the Host State in the fields of public and occupational health and safety, nuclear safety, radiation protection, licensing, nuclear substances, environmental protection and protection from acts of malevolence.”
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 27
ITER Engineering Basis Handbook
The ITER Agreement and the ITER Council have a major role in defining how these functions are implemented and executed. However, nuclear licensing and safety has to observe French regulations. These functions are like those in other large national projects though not identical. Developing a common approach was an important element in both the negotiations leading to the approval of the ITER Agreement and in subsequent discussions. This was informed, in part, by how other large international projects were managed but also by specific issues associated with the ITER Project. 8.3.4.1
Role of Management Advisory Committee (MAC)
The terms of reference of the Management Advisory Committee (MAC), as approved by the ITER Council, are described in the Terms of Reference of the Management Advisory Committee (MAC)[7]. The role of the MAC is succinctly described by “The ITER Council Management Advisory Committee (MAC), shall, upon request of the ITER Council (IC), review and advise the ITER Council (IC) on management and administrative issues arising during the implementation of the ITER Project…” Proposals from the DG on matters requiring IC approval are typically reviewed by the MAC including for instance annual budget requests. In addition, “MAC shall, at the request of the IC, review and evaluate matters of strategic management importance to the ITER Project and make recommendations to the IC to facilitate the successful development of the ITER Organization and the successful execution of the ITER construction project on schedule and within budget, while meeting its mission objectives.” The MAC has been delegated powers of decision on behalf of the IC on certain administrative issues as described in the terms of reference. The MAC, like the IC, is composed of representatives from each Member. Each Member designates two committee members and up to three of its own experts, who are not members of the MAC. The Chair of the MAC can also invite additional committee members. The relationship of the members from each party is described in the following: “The Members' representations in MAC should be capable of reflecting official positions of their respective Members and have relevant expertise in the management of major projects”. Due to its role in advising the IC on items such as budget and procurements, the membership reflects the opinions of the Members. It is not constituted as an independent review committee but facilitates the execution of the responsibilities of the IC. 8.3.4.2
Role of Science and Technical Advisory Committee (STAC)
The terms of reference of the Science and Technical Advisory Committee (STAC), as also approved by the ITER Council, are described in the Terms of Reference of the Science and Technology Advisory Committee (STAC)[8]. Once again, the role is succinctly described by the “STAC shall, upon the request of the ITER Council (IC), review and advise the IC on science and technology issues concerning the implementation of the ITER Project…” Scientific and technological aspects of proposals from the DG that go to the IC are typically reviewed by the STAC. These include for example aspects of the ITER Project Plan and Resource Estimates, the ITER Research Plan for the
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 28
ITER Engineering Basis Handbook
Operations Phase and other matters as agreed by the IC, upon proposals by the Members or of the DG. The STAC has conducted technical reviews in support of important project decisions such as the introduction of the shattered pellet injector. Each Member is represented by two members of STAC as designates. In addition, the STAC members are supported by experts, up to three experts per Member. The experts are selected by the ITER Council Chair in liaison with the STAC to cover the topics of the meeting. In consultation with the STAC members, the STAC Chair may also invite additional experts. In contrast with the MAC, “each member of STAC, as well as each expert, is required to avoid situations of conflict of interest regarding any matter on which they are required to contribute and give an opinion.” The IC provides a written charge to STAC.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 29
ITER Engineering Basis Handbook
Glossary ASME BOM CAD CDA CDR CM DA DG ECH EDA EIA-748 ELM EURATOM EVMS FDR FEAT FFBD GBS GCR HOP IC ICD ICM ICP IDM ILOAT IS ISO L-H MAC MQP NIST PA PBS PDR PFD PLM PM PR PRMR RPM SAP SDPD SLD SQL
American Society of Mechanical Engineers Bill of Materials Computer-Aided Design Conceptual Design Activities Conceptual Design Review Configuration Management Domestic Agency Director-General Electron Cyclotron Heating Engineering Design Activities Electronic Industries Alliance Standard 748 (Earned Value Management Systems) Edge Localized Mode European Atomic Energy Community Earned Value Management System Final Design Review Fusion Energy Advanced Tokamak Functional Flow Block Diagram Geographic Breakdown Structure Global Change Request Handover Package ITER Council Interface Control Document Interface Control Management ITER Collaborative Platform ITER Document Management International Labour Organization Administrative Tribunal Interface Sheet International Organization for Standardization Low-to-High confinement mode transition Management Advisory Committee Management and Quality Program National Institute of Standards and Technology Procurement Arrangement Plant Breakdown Structure Preliminary Design Review Process Flow Diagram Product Lifecycle Management Plant Maintenance Project Requirements Project Resource Management Regulations Requirements and Project Management Systems, Applications and Products in Data Processing System Detailed Performance Definition Single-Line Diagram Structured Query Language
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 30
ITER Engineering Basis Handbook
SRD SRO SSRD STAC
System Requirements Document Start of Research Operations System/Subsystem Requirements Document Science and Technology Advisory Committee
References [1]
Project Management Plan for the International Thermonuclear Experimental Reactor ITER, ITER EDA publication S 91 PR 10 98-03-03 W 0.1. [2]
IDM, 2DY7NG, IC-2/ 7.1.
[3]
Project Management Plan for the International Thermonuclear Experimental Reactor ITER , ITER EDA publication S 91 PR 10 98-03-03 W 0.1. [4]
Summary of the ITER Final Design Report, ITER EDA Documentation Series No 22, July 2001, sections 9.1.4, 8.3.1 and 8.3.2 respectively. [5]
ITER_D_RZ2YUL v1.0.
[6]
ITER_D_2EW6RK v1.1.
[7]
ITER_D_VPEKPR v1.0.
[8]
ITER_D_VQV32K v2.0.
MANAGING THE DESIGN & CONSTRUCTION OF ITER
Vol.1, Ch. 8/3, p. 31