The ITER Data System Challenges

1. 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

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 28m 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 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. Interlock Network 2 Network 1 ITER Specs System Local control Local store Water/air/power/hydraulics What do we mean by a system ? 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. state state state External External External External Internal Internal Internal Service communication RTDB1 RTDB2 Service Oriented Architecture • Could ITER go this way ? • 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 Jo Lister, CRPP-EPFL, ITER Data Challenges, ICALEPCS 2005, Geneva, October 2005