The ITER Data System Challenges presented by

Jo Lister, CRPP-EPFL, Switzerland

with

Izuru Yonekawa, JAEA-Naka, Japan

John How, CEA-Cadarache, France / ITER-IT

So Maruyama, ITER-IT, Germany

ITER update

Where are ITER’s main data challenges ?

Lead up to today’s round-table discussion

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 2

Where will ITER be sited ?

After long negotiations, a European site was agreed at the end of June 2005

Cadarache (CEA), Bouches du Rhône, France

Commissioning in or after 2016!

Now we have structural discussions

Director general

Staffing structure

Financing

etc etc

ITER parties are still EU+CH, JA, China, Korea, Russian Federation, USA

Long lead item procurement starts as soon as possible

At least 7 year construction

At least 1 year integrated commissioning

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 3

Reminder of what ITER looks like - physically

Fusion Power = 500MW

Fusion Power/Auxiliary Heating Power

= Q>10

Neutron wall loading = 0.57 MW/m2

Plasma major radius = 6.2 m

Plasma minor radius = 2.0 m

Plasma Current = 15 Megamp

Toroidal Field = 5.3T

Plasma Volume = 837 m3

Heating power = 73 MW

Pulse lengths = 300 - 5000 sec

PF supra coils = 925+6*130-390 tons

TF supra coils = 18*312 tons

Vessel = 9*575 tons

Total in hall = 23,000 tons

28m

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 4

ITER’s data rates and volumes - OK

Conclusion in 2003 Rate is probably not a problem with existing technology Volume is not a problem

But it will be hard work of course, even if we do have solutions

… but…. we can not obviously USE the data we are archiving This will be a challenge, mentioned by Martin Greenwald Knowledge or model-based filters will have to be developed

That was the feeling 2 years ago

Take the potential source rate 100 GB/s peak Take 500’000 to 1’000’000 hardware channels, 0.1 – 108 Hz Take 1PB per year

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 5

So what are we thinking about for CODAC ?

ITER COntrol Data Acquisition and Communication architecture will consider

Political “in kind” procurement

Procurement interface definitions

Procurement standards definitions

General life-cycle issues of procured systems, associated perenity issues

ITER data flow performance : data rates and volumes - technical

Combining acquisition and control into “data flow” - tokamak specific

Networking inside and outside an ITER sanitised area - topic this week

Remote participation and remote operation - covered by Martin Greenwald

Remote maintenance of procured systems

Discharge design and modifications - tokamak specific

Discharge monitoring and control - tokamak specific

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 6

Procurement, integration and operation

Most of procurement of “External” systems will be “political” in-kind

Procurement of the “internal” systems (IT infrastructure) is central

Parties (e.g. EU, USA) will have to deliver full systems with an agreed value

They will procure through their own administration

Procurement may involve research institutions

Manufacturing may involve local/foreign industry

Industry may outsource some of the components

Then it will be integrated under high visibility and operated as fast as possible

How do we optimise this integration ?

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 7

Major issues

Can we aim at plug-and-play of all “external systems” ?

Standards for hardware

Standards for software

Standards for data exchange

Security

Respect for these standards is implicit, but is it guaranteed ?

Google “plug and play” is interesting, the top hit is…(from Microsoft)This update resolves a newly-discovered, privately-reported vulnerability.

A remote code execution vulnerability exists in Plug and Play (PnP) that could ...

Are we being naïve - if so, we should stop now ! Are we being visionary - if so, we should be brave !

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 8

What do we mean by a system ?

SystemLocal control

Local store

ITER Specs

Water/air/power/hydraulics

Network 1

Network 2

Interlock

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 9

Hardware standards

Can we impose hardware standards on what is inside a procured system ?

Is it better to have a supplier work with what he knows best ?

Is it better to have common spares ?

Who is responsible for maintaining the hardware after 10-20 years ?

Who will actually end up keeping old equipment going ?

Remember we are talking of large planetary differences in work practice and

technology

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 10

Software standards

Can we impose software standards on what is inside a procured system ?

Is it better to have a supplier work with what he knows best ?

Is it better to have common products ?

Is it necessary to have common methodology ?

Who is responsible for maintaining the software after 10-20 years ?

Who is responsible for software updates (security?) for 20 years ?

Who will actually end up keeping old software going ?

Remember we are talking of large planetary differences in work practice and

technology

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 11

Data exchange standards

Can we impose data exchange standards on a procured system ?

Is it better to have a supplier work with what he knows best ?

The other software issues are all here again

Remember we are talking of large planetary differences in work practice and

technology

Can we use internationally recognised (i.e. not fusion-specific) norms ?

Do we have to copy others and make an ITER-specific generic framework ?

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 12

Remote integrators for procurement

Can ITER procure at the level of wiring ? – ITER will never enough staff

Can ITER procure at the level of subsystem ? - homogeneity, staff

Can ITER procure at the level of full “identical” systems? - norms

ITER-qualified/trained local integrators could be a good solution – multi-national

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 13

Service Oriented Architecture

Could ITER go this way ?

External External

Internal Internal

External External

RTDB1 RTDB2

Internal

state state state

Service communication

This model is natural when

designing an integrated plant,

when integration is not just

the last act It is

extendable

not necessarily scalable

has hidden middleware

has a hidden framework

has a general API

Each system can interface to

a given API e.g. VSYSTEM,

PVSS, EPICS ??

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 14

Integration of complex equipment

“Slow controls” will generate a a lot of data, but ITER will have slower time-

scales than present tokamaks. We assume 500’000 to 1’000’000 channels

This is data handling rather than technical - we have to use and understand

this data Requires more effort on Finite State Machine system description than on

hardware/software techniques Corresponds again to a structured data view of the world Needs a universal description of the FSM - see ongoing work elsewhere

Generating the working control software will still require lots of inventiveness,

but most of all will require a complete data-driven description of the systems

Can we combine plug and play devices into a full inter-operating system?

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 15

Security

We wish remote users to be able to service their equipment This is inevitable

However, this opens the door into the machine control from outside

We can impose a gateway, content sensitive, to relay instructions coming in,

with strict control (like PVSSII), but will the hackers win?

Can we guarantee that the outside world cannot penetrate a content-sensitive

gateway in one direction ? - in 8 years time….

The other security issues are conventional - i.e. extremely difficult

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 16

Vision of ITER integration in a SOA

SOA are in and out of favour, but were “sold” for Enterprise Application

Integration in heterogeneous environments with dominant legacy problems.

Is it the right model for integrating complex physics plant ?

What Web Services appear to offer is

Strong control over the communication method between supplier and ITER

Strong content over the data exchange content

Internationally established norms, internationalisation

Security, traceability

Management transactions for configuration, commands, documentation,

description, essential for plug-and-play

Inadequate performance for the sustained high rate data flow - probably

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 17

Summary

ITER will presents a tremendous scientific and technological challenge for the

optimal handling of all the data of the project

Procurement will bring interesting international challenges

Architecture must consider the procurement and integration problems

“Strong control” does not create a partnership, the SOA is an enabling

technology, not a guarantee

How do we minimise the risks of less than total success ? On time On cost Required performance

Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005 18

Round Table

We are opening the round table discussion on procurement for large

international research projects

We hope that you will stay and share your advice and experience