System Engineering and Configuration Management

1
System Engineering and Configuration Management
in ITER
Pietro Barabaschi, Hans-Werner Bartels, Stefano
Chiocchio, John How, Akko Maas, Eric Martin,
Bill Spears, Eisuke Tada

Presented by Stefano Chiocchio ITER JWS
2
Synopsis

• System Engineering and Configuration Management
• The ITER Challenges
• Configuration management elements and tools in
  ITER
• Conclusions

3
System engineering

• The realization of large civil and industrial
  construction works,
• the management of large interconnected systems,
• big science endeavors, require that
• different engineering disciplines and specialized
  design groups are organised and their efforts
  converge to the achievement of the common goal.
• The scope of the SE is to
• establish the requirements and physical
  architecture of the project,
• manage its development from conceptual to
  detailed definition, and
• assess and control its performance.

4
Relationship between System Engineering and
configuration management
5
Configuration management

• The scope of configuration management (CM) is to
  ensure that
• accurate information consistent with the physical
  and operational characteristics of the project is
  available at any point of time.
• The ability to rapidly identify and retrieve this
  information is vital
• to ensure that all participants to the design
  activity use consistent information,
• to assess the implication of design changes
  during the design and construction,
• to manage the assembly and installation
  operations,
• to plan for the maintenance operations
• to be able to react to unexpected or emergency
  situations,
• to support future upgrades,
• to safely manage the decommissioning phase.

6
Basic relationship in Config. Management
7
SE and CM during the ITER design and
construction process
Objectives definition
Requirement v performance check
Parameters selection
config control assembly
Digital mock-up Clash detection
Requirements management
Definition of config (envelope) models
Detailed design definition
Integrated design definition
Conceptual design
Component design
Overall architecture
Functional design
Component Procurement installation
Systems Integration
Operation
Time Bar
Conceptual definition
Detailed design
Procurement phase
Value engineering
Change (non conformity) control
Concurrent engineering
8
The ITER challenges The Scientific Mission

• The Physics parameters are strongly linked to
  design choices
• It is a First of a Kind Plant
• many specialistic skills are required
• but even more difficult is to find people with a
  wide knowledge of the entire plant

9
The ITER challenges The Technology

• The tokamak assembly
• very highly integrated design,
• small clearances,
• large number of parts (few millions),
• few components using well proven fabrication
  technology.

Unusual operational conditions (nuclear, vacuum,
cryogenic, magnetic) and processes (e.g. heavy
items handling, remote maintenance,etc)

• The tokamak building
• many systems,
• equally important for the mission of the project,
• not spatially separated,
• with many functional interfaces.

10
The ITER challenges The Project Organisation

• International collaboration, multi-cultural
  environment
• Distributed design activities
• Communications
• Concurrent engineering
• Procurement scheme

11
Configuration Management Elements in ITER

• Management of requirements
• Identification of the configuration
• Document and project data control
• Change control
• Management of interfaces
• Risk Management

12
Management of requirements
The Plant Design Specification defines the
externally imposed essentially and design
indepedent requirements of ITER
The Project Integration Document describes 1)
elements of Project Management 2) overall
machine configuration, basic parameters,
configuration tables and operation states, 3)
general requirements, parameters, loads and
interfaces grouped by broad subjects 4) main
configuration of each system
The DRG2 (Design Requirements and Guidelines
level 2) covers all specific requirements for
each system This is responsibility of the WBS RO
13
The Plant Break-down Structure and the ITER
Digital mock-up
All systems and parts of the ITER project are
organised around a tree structure called PBS
(Plant Breakdown structure) Drawings , Documents,
procurement and operational data can be accessed
by navigating this structure. The management of
the 3D models representing the plan is done
throuh ENOVIA, (a sotware by Dassault Systemes
for the management of the Virtual Product
Data) The data stored in Enovia can be accessed
by all members of the design team either by
active connection or in passive modes using a
web based client application . The parts can be
visualised, reviewed and relevant information can
be retrieved.
14
The ITER Documents Management System (IDM)
http//www.iter.org/idm

• Open Source Software (Zope)
• ITER Owned and Managed
• Use through Internet Browser http//www.iter.or
  g/idm
• Powerful search capability
• Easy (intuitive) use
• Integrated workflow with
• Signing, approval (electronic signature)
• Comments
• Versions
• Security settings allowing read/write access to
  be set by users
• Online and printed users manuals, online bug and
  feature request forms

15
Management of Information The ITER Tech web site

• http//www.iter.org Public Web
• http//www.iter.org/bl Technical Baseline Web
• http//www.iter.org/cad PDF Drawing library
  (Passworded for ITER and Collaborators)
• http//www.iter.org/idm ITER Document Management
  vault (Passworded)
• http//www.iter.org/team Internal ITER Team
  web (IP and Password protection)

• Available for ITER Staff, Partners and
  Collaborators
• Generic User name and Password

16
The ITER design change process
Every proposed design change is assessed at the
system level, first...

• Consistency between requirements and design
  concept
• Consistency between design concept and the actual
  design of each part (at this stage the CAD model
  of it later the real part)

... and then at machine level

• Integration issues (management of the interfaces)
• Impacts on overall performance
• Impacts on cost

... and if approved by the Technical Coordination
meeting a Design Change Request is issued and a
number is assigned to it.
17
Management of Design Changes
18
ITER Interfaces Management Process

• Interface identification
• Identify the interfacing systems, and type of
  interfaces (geometrical, functional, importance)
• Interface initial description by cognizant part
• The most affected user have the first go
• Interface reviews
• This is done in parallel to the design reviews of
  the affected components
• Assessment of the assembly and maintenance
  implications
• Together with design review of each system
• Creation of Interface description documents
• These documents are integral part of the
  technical documentation of the procurement specs.
• Definition of the interface ownership and
  interface monitoring
• A clear identification of the responsibility is
  critical.

19
The ITER Interfaces Matrix
Colour coding
partner interface X
normal interface X
complex interface X
very complex interface X

 
20
Risks/opportunities management Issues
Identification
We started this process end of 2004 with a set of
broad scope Design reviews, to initiate a
critical review of the status of the design and
to organise the further work. The issues cards
have been reviewed and prioritized with the IT
leader and since then at Technical coordination
meetings Issues can be raised by all People
involved in the ITER activities (ITER ORG and
ITER PTs/DAs members. The issue are classified
according to the WBS structure and the
Responsible officer of that activity become the
issue RO. About 260 Issue cards have been
proposed so far and stored in a database.
21
Risks/opportunities management Issues database
The database of all issues are available on the
web
www.iter.org/tech
The database provides summary of the issues by
status and by role of the user, Search functions
and possibility to add new issues
Help and explanation are provided by S.Chiocchio
and C. Capuano.
22
Risks/Opportunities Analysis

• Probability (the likelihood of risk occurrence)
• High (3) Very Likely More than 90
• Moderate (2) Likely more than 10 to 90
• Low (1) Not Likely up to 10
• Time ( time to start action or mitigation)
• Near Term (N) lt3 months
• Mid Term (M) 3 months to 1 year
• Far Term (F) gt1 year

23
Risks/Opportunities Analysis
Risk type
High (3) Very likely gt 10
Moderate (2) Likely gt10 up to 90
Low (1) Unlikely gt 90
3
Consequence
2
1
3
2
1
Likelihood
Low (1) Moderate (2) High (3)
Technical minor modifications required Some adjustments to baseline required Descope, or extensive workaround required
Cost less than 1kIUA between 1 and 10 kIUA above 10 kIUA
Schedule impact week gt1month lt 6 months gt 6months
High implement new process or change baseline
Medium Aggressively manage considerr
alternative process
Low Monitor
24
Conclusions

• During the ITER Transitional Activities (starting
  in 2001) a large effort and dedication has been
  spent to ensure that appropriate procedures and
  tools for the technical management of the project
  are deployed at the start of the ITER
  construction.
• Thanks to the commitment of the few people
  involved, we have succeeded
• in reviewing the present working practices,
• clarify and envisage future needs,
• assess different tools available and in use on
  the markets,
• test and deploy the new software,
• and introduce procedure for the management of
  designc hange and document management.
• The systematic approach that we have developed
  and applied and the tools that we have been using
  compare favourably with those in use in similar
  large projects.
• further effort is neededto be done to
• a) to adapt the tools to the new process that the
  ITER team has to manage, and
• b) to fully deploy these tools also to the
  participant teams
• c) to apply consistently the interfaces and risk
  tracking procedures .
• We believe that this will enable the ITER
  organization to manage the challenging task
  ahead.