1 / 14

Summary of Working Group 3 Software

This work group explores the importance of standardizing software development in fusion research, addressing issues like open-source vs. commercial software, obsolescence, quality assurance, and data protocols. It presents insights on key aspects such as self-description of data, PSH, mini-CODAC, and the need for industry collaboration to facilitate software operations. The discussion emphasizes the significance of early availability of development environments, robust quality assurance, and the adoption of existing open standards to streamline the software development life cycle in fusion research.

dlake
Télécharger la présentation

Summary of Working Group 3 Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related