CS -Framework - Overview & Status

1. CS-Framework - Overview & Status Intro Overview Status CS-Workshop 2012, Dietrich Beck

2. Same slides as last year… Overview CS-Workshop 2012, Dietrich Beck

3. Nothing new since CS Workshop 2011 Status CS-Workshop 2012, Dietrich Beck

4. Thank you for your attention! Conclusion CS-Workshop 2012, Dietrich Beck

5. there is one more thing... CS-Workshop 2012, Dietrich Beck

6. there is one more thing... CS-Workshop 2012, Dietrich Beck

7. ( CS-Workshop 2012, Dietrich Beck

8. Towards the FAIR Timing System using White Rabbits Towards FAIR White Rabbit Timing System CS-Workshop 2012, Dietrich Beck

9. Towards FAIR… CS-Workshop 2012, Dietrich Beck

10. 23 November 2011 CS-Workshop 2012, Dietrich Beck

11. 8 December 2011 CS-Workshop 2012, Dietrich Beck

12. Bild von heute 12 January 2012 CS-Workshop 2012, Dietrich Beck

13. 12 January 2012 CS-Workshop 2012, Dietrich Beck

14. General Machine Timing System @ FAIR • parallel execution of beam production chains • cycles: 20ms to hours • trigger and sync. equipment actions • 1 µs precision in 99% of all cases • few ns precision for kickers • (ps for rf-systems: BuTiS) • many rings • > 2000 devices connected to timing system • large distances • robustness: lose at most one message per year CS-Workshop 2012, Dietrich Beck

15. Not: 1km distance:  5s propagation time 1s precision: requires compensation for cable length  Idea: Timing System Based on Time Equipment 1 Timing Master do this do this Equipment 2 CS-Workshop 2012, Dietrich Beck

16. Instead: equipment pre-programmed for autonomous action at a given time pre-programming via timing-events required: clock synchronization ns required distribution of information and execution of action are decoupled !!! timing-events must be sent “early enough” upper bound latency for transmission (e.g. 100 s): real-time! lossless transmission: robustness! Idea: Timing System Based on Time "Oh dear! Oh dear! I shall be too late!" ??? do this @ 15:03 Equipment 1 Timing Master do this @ 15:03 do that @ 15:01 Equipment 2 CS-Workshop 2012, Dietrich Beck

17. “The White Rabbit (WR) project is a multi-laboratory and multi-company effort to bring together the best of the data transfer and timing worlds …” (Proc. ICALEPCS 2009) www.ohwr.org ) CS-Workshop 2012, Dietrich Beck

18. … White Rabbit and CS CS-Workshop 2012, Dietrich Beck

19. Now the Talk Starts (if you are still interested) Intro Overview Status CS-Workshop 2012, Dietrich Beck

20. Control System Control devices (power supplies, function generators, timing, complex experimental procedure…) No process control DAQ and data processing is only a minor issue Integrate things that were not developed to work together as a system Ever changing set-up The same experiment is never done twice Reconfiguration of complete hardware (seconds!) Integration of new hardware (next beam-time) Small and medium size experiments No dedicated staff for control systems Different experiments but similar problems to solve (configuration, complex timing schemes, similar hardware,…) …  What about a “Framework”? Starting Point (2001) CS-Workshop 2012, Dietrich Beck

21. Developer: User: picture pocket knife ... a tool box ... something ready to use (sth. to solve a problem) without additional work (= the solution!) Different Points of View – A Framework is... CS-Workshop 2012, Dietrich Beck

22. control system = framework + add-ons GUI Cycle Control HV Timing+DAQ AFG Definition of the CS-Framework add-ons may become part of framework bug reports, new features requested experiment EE/KS and contributors bug fixes, new features, maintenance CS-Workshop 2012, Dietrich Beck

23. SIS Z6 HHT UNILAC PHELIX PHELIX (Petawatt High-Energy Laser for Heavy Ion Experiments) Up to 3 MJ electrical energy converted to 1kJ light energy or 0.5 Petewatt laser power. 2300 documented “shots” (Dec. 2010). About 10k process variables distributed on 15+ nodes in 2 buildings (slide by S. Götte, GSI) CS-Workshop 2012, Dietrich Beck

24. Quad-Triple Trap Mass Spectrometer ISOLTRAPHigh-precision mass determination of unstable nuclei with a Penning trap mass spectrometer at ISOLDE/CERN www.cern.ch/isoltrap • Nuclear-, Astro-, Fundamental Physics • m/m  10-8 (typically!) • via cyclotron frequency of stored ions • “sub-µs ion-juggling” every second CS-Workshop 2012, Dietrich Beck

25. One development tool  LabVIEW Standardization  object oriented approach, base classes Distribution to many nodes  DIM (www.cern.ch/dim) Event driven communication for everything Scaling to large systems by distribution Remote access … SCADA functionality (alarming, trending, …)  LabVIEW DSC module Cooking Recipe for the CS Framework CS-Workshop 2012, Dietrich Beck

26. (Over)view CS-Framework Intro Overview Status CS-Workshop 2012, Dietrich Beck

27. SourceForge: downloads, tracker (bugs, features,…) CS-Workshop 2012, Dietrich Beck

28. SCC via SubVersion @ GSI CS-Workshop 2012, Dietrich Beck

29. Domain Management System: Process Management in a Distributed Environment CS-Workshop 2012, Dietrich Beck

30. Process Monitoring CS-Workshop 2012, Dietrich Beck

31. Packaging CS-Workshop 2012, Dietrich Beck

32. Documentation via Wiki CS-Workshop 2012, Dietrich Beck

33. Class Documentation via UML Tools CS-Workshop 2012, Dietrich Beck

34. Lessons Learned… CS-Workshop 2012, Dietrich Beck

35. Stress Field of the Responsible Person: The OS (XP) and/or the intranet are always unreliable, the programming language (LabVIEW) never really fulfills the need, the framework (CS) is only close to the requirement, the classes of other CS collaborators are typically not usable, there is no way to test things since there is no test system available while the real system is always in use, the users never define what the program has to do, but are not pleased with what the programmer delivers, and they misuse the system additionally. Anyhow: The goal is an easy system where the happy user does not realize what happens behind the scene, which works reliable and for ever (better: till the next LabVIEW version is installed). Lessons Learned – What Users say about CS(from a talk by Stefan Götte, at the NI BIG PHYSICS Round Table, Paris, 2009) CS-Workshop 2012, Dietrich Beck

36. Design principles of major importance A control system must be designed to crash and (auto-)recover from failures of all kinds Fileserver down Computer down/reboot Installation of updates Switched-Off/On by users … Network down Power cuts … The system is stressed most, when everything goes wrong (failures, alarms, sub-system crash…) and all kinds of asynchronous signals fire at the same time (self-induced DoS-Attack) and availability is most important. “The OS (XP) and/or the intranet are always unreliable” (assumption for design phase) CS-Workshop 2012, Dietrich Beck

37. Stress Field of the Responsible Person: The OS (XP) and/or the intranet are always unreliable, the programming language (LabVIEW) never really fulfills the need, the framework (CS) is only close to the requirement, the classes of other CS collaborators are typically not usable, there is no way to test things since there is no test system available while the real system is always in use, the users never define what the program has to do, but are not pleased with what the programmer delivers, and they misuse the system additionally. Anyhow: The goal is an easy system where the happy user does not realize what happens behind the scene, which works reliable and for ever (better: till the next LabVIEW version is installed). Lessons Learned – What Users say about CS(from a talk by Stefan Götte, at the NI BIG PHYSICS Round Table, Paris, 2009) CS-Workshop 2012, Dietrich Beck

38. The fundamental problem about documentation Two lines of text are not enough, but Two pages of docs – (almost) nobody will read that* Docs out of date … Solutions HOW-TOs, FAQs Auto-generated documentation Class documentation, CS2JavaUML Requires well documented code (again: coding conventions!) Release notes Demo-system (delayed…) * sometimes not even the first two lines… Lessons Learned - Documentation CS-Workshop 2012, Dietrich Beck

39. Generic tools (generic control system GUI, generic device GUIs) Sometimes difficult to understand ( documentation problem) Lot’s of work to maintain Don’t match the users’ needs exactly Either least common denominator (missing features), or include all requested features (too complex) “Nobody likes them, but everybody uses them.” Lessons Learned – Generic/Common Tools CS-Workshop 2012, Dietrich Beck

40. Identifying missing features sometimes requires telepathic skills results in cool solutions that are finally not used (nice to have versus really useful) CS Access System Sequencer ObjectNets, PetriNets some base classes … Lessons Learned – Missing Features CS-Workshop 2012, Dietrich Beck

41. Backward Compatibility (“does my old code still work?”) Is maybe THE most important feature of a framework Often results in a impressive mix of different versions (core system v1, base classes v2, GUI v4, device classes v3,…) Makes it hard to correct wrong design decisions Requires clear public library routines or class methods, but… using conventions on what is public/private does not work Lessons Learned – Compatibility CS-Workshop 2012, Dietrich Beck

42. Wikipedia: “…software frameworks … reducing overall development time” (?) Amount of time for solving a problem decreases dramatically, if a problem may be solved with (generic) existing software. “configuration instead of coding” does not change – but the solution is much better may even increase (short-term), compared to a dedicated solution not (!) using the framework (required: training, courses, understanding and application of conventions) decreases (long-term): framework maintained by others, re-usability of code, replacing hardware, coding conventions enforced, maintainability, common language, know-how transfer, … Lessons Learned – The “Saving-Time-Myth” CS-Workshop 2012, Dietrich Beck

43. require high flexibility have a large variety of hardware types have up to 10,000 (1M possible) process variables require fast ( 100 ns) timing control using dedicated hardware PHELIX LEBIT SHIPTRAP ISOLTRAP POLARIS, HIJ others ... data taking Motion CaveA HITRAP commissioning REXTRAP FOPI development Experiments using the CS framework... RISING ClusterTRAP LPT GSI, Germany Mainz, Germany Greifswald, Germany CERN, Switzerland MSU, USA Lanzhou, China TrigaTRAP CS-Workshop 2012, Dietrich Beck

44. CS 3.21 released for LV2009. about 15 active applications 1,000,000 PVs demonstrated, an even larger number should be feasible 5,000 objects ( hardware devices) demonstrated, an even larger number should be feasible stability of a distributed CS system is better than a few hundred hours of continuous operation about 15 (60) hardware devices supported on SourceForge (Subversion) FAIR: MATS and parts of HITRAP have selected CS as control system framework. Conclusion and Outlook CS-Workshop 2012, Dietrich Beck

45. Holger Brand, Dietrich Beck, Mathias Richter, Alexander Schwinn, Falk Ziegler, Romain Savreux, Chabouh Yazidjian, Klaus Blaum, Dennis Neidherr, Melanie Wolf, Stefan Schwarz, Josh Savory, Stefan Götte, Maximilian Kugler, Tobias Habermann, Michael Block, Frank Herfurth, Christian Rauth, Stephen Koszudowski, Manas Mukherjee, Thomas Rechel, Martin Feldmann, IT@GSI, ……………... Acknowledgements... CS-Workshop 2012, Dietrich Beck