Summary of Working Group 3 Software

1. Summary of Working Group 3Software Bruno Soares Gonçalves (bruno@ipfn.ist.utl.pt) with strong contribution by all participants

2. Application lists and programming standards • How to standardize and what procedures to adopt? • Working group form F4E? • Initiative from industry? • Commercial/open source software?

3. Open source • Open source is generally good but, in specialized domains, the amount of developers is reduced • However, big projects tend to attract lots of enthusiastic people, e.g. High energy physics uses EPICS • Companies prefer open-source software when its spin-offs to the outside world are clear. E.g. ESA mission Control Centre Software • ITER will have the source code in a repository (with consideration of IPR and security)

4. Open source Whichever solution ITER adopts, should aim at minimizing diversity • Include industry in the specification process will facilitate the selection • Specify the criteria for selection and make it known will help the acceptance

5. Software environment for development Standardization required to facilitate operation and maintenance, e.g. at JET only 2 duty officers are necessary during operation How to standardize? • ITER will provide standardsin thePCDH • Review of PCDH is the mechanism for feedback through DAs

6. Self-description of data and PSH • Can it work? • Is it too ambitious? • Are there similar examples already adopted in industry or elsewhere?

7. Self-description of data and PSH • Examples exist outside, e.g. web services, ESA satellite tracking systems • For ITER it is necessary to have a design schema for interoperability • It should be simple to use • PCDH should provide examples • PLCs may have similar concepts, translation tools may be required

8. PSH and mini-CODAC • PSH and mini-CODAC is top priority as it will provide the seed for all the other developments • Case studies of developments are expected • Industry expects to have a Detailed Engineering design specification and a workable engineering process • Model-driven development has as many defenders as attackers • The software development life cycle as described in PCDH requires improvement Overall, to facilitate the process, industry expects to have a facilitated channel of communication to answer their doubts • Centres of Excellence at DAs

9. PSH and Mini-CODAC • Early availability of Development environment essential • Mini scheduler, with reduced functions, to test Plant System while at factory

10. Software obsolescence How can obsolescence affect software? • Use of open-source makes job easier • Isolate software from hardware • Use of Data driven applications to protect application can mitigate the problem • Centres of Excellence critical to keep pool of skilled staff, e.g. training “If it is not broken do not fix it”

11. Diagnostic needs How standardization can affect development of diagnostic systems? • Special components and software are limited • ITER aim is not diagnostic development • Special features require dedicated obsolescence plans • Early flagging required

12. Quality assurance Does it require special software? • Robust software is essential • Software test points need to be identified and designed in • Acceptant tests are crucial • Solutions exist, e.g. test of satellites software • Failure and recovery modes design in for fault tolerance

13. Data protocols • Protocol standardization is considered more important that language standardization • Data protocols should be included in PCDH • MDSplus is a good start for functionality requirements of data acquisition

14. Overall view • Get tools to people’s hands as soon as possible even if CODAC does not exist yet • If things are done right ITER solutions may become standard in fusion community or, wishful thinking, in scientific community • Do not reinvent the wheel, use existing open standards