1. Systems, their relations & information. Concepts and Status of the new central service for tracking relations between CERN accelerator systems TE/MPE TM 20.06.2013 On behalf of MPE/MS software section & S. Jensen, D. Csikos from BE/CO Arek Gorzawski

2. Menu arkadiusz.gorzawski@cern.ch te/mpe technical meeting Why we need it? With what users will contribute. We do the framework, users will fill it up. What users will gain S ervice of U nified, I ntegrated and S implified S ystems What’s already in place. 20/06/20132

3. Why? Unique way to access information - regardless of origin across all applications. Key Concept: Use existing Sources, do not replace them, and DO NOT create yet another one Existing sources: LayoutDB, CCDB, LSA, MTF, EDMS, ELQA, WISH, others? 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 3

4. Why? Simplification of queries to ‚framework‘ User doesn‘t want to deal with files, sql or any other ‚special format‘ used to store relevant information. One programming interface exposed to clients. Easy and accessible from all OP tools (JAVA) Common need across CERN groups ( ie. BE-CO-DO ) 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 4

5. Where does it help? As User/Operator I‘d like to see: … see issues on a system … see a history of a system … see faults of a system, which occured over time and are automatically detected. … create an Issue on a system … the dependencies/relations between systems static runtime … the common point of several systems (E.g. Diamon) 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 5

6. We found pattern… 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 6

7. Visions and needs become clear As a prototype, already in AccTesting long time ago We had a tiny wish to put is as stand alone server (yet another one ;-)) While designing AccTesting framework extensions, With respect to pre powering tests of ELQA With respect to other systems needed for beam commissioning Discussion was turbulent and fruitful and then… 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 7

8. Similarity appears on ‘the other side’ 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 8 courtesy S. Jensen, D. Csikos, BE/CO

9. What we deal with? SYSTEM 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 9 Hardware: Power switch Terminal Detector board Current lead Magnet … Software: Application Library Firmware … Common things: Name, Identifier (unique key, contains type and information about source of system) everything is a

10. What we deal with? 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 10 RELATION Hardware: Crate holds a set of detector cards Detectors are powered from one source Circuit is built of magnets, power converter, busbars etc. Software: Application needs to use some libraries One computer in control room can run number of processes that access some hardware crates Common things: type

11. What we deal with? 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 11 INFORMATION Hardware: State of the system Parameters of the system An issue on hardware An non conformity Test history … Software: Revision, author, changes recently done State JIRA issue Test history Time of deployment …

12. What we deal with? 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 12 Attributes For Systems: Location Colour Interlock type Powering subsector … For Relations: Type Lifecycle: Runtime static

13. Basic concept: Framework. 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 13

14. Contribution: how to get systems into the framework? Contributors have to provide: Systems provider Systems relations provider Systems information provider Why? They know the storage structure the best, they know (very often) what SQL queries to use in case source is a DB, they know what files to search and parse. 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 14

15. Core Providers feed core with systems and their relations. For the time being, all information is cached and kept in memory. Update mechanism for changing relations (mainly for software part). 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 15

16. Core All references based on keys Framework knows (via unique key) where to get more information about given system. Possibilities for external caching: Sql NoSql Neo4j (Graph DB) 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 16

17. Usage: What the user wants to know? the most common use cases: I need to work with all systems: of type X, some funny name (filterable), some funny attribute (filterable). I need to know what systems are related (1 st order of relation) to my favourite one. (Some specific logic to be applied by user) 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 17

18. Status Server itself with debug application (for tracing some performance and consistency issues) Top layer to navigate trough ‘environment’ via WEB (still TO BE done!) 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 18

19. 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 19

20. What is in place. AccTesting Since not only circuits are possible to test, we need relations between ie. magnets and circuits for scheduler. 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 20

21. What is in place. QPS Swiss Tool Power cycling needs certain information about relations within the system 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 21

22. Will it growth? Sure … Some figures for actual load : 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 22 Nb of relations stored: 48446 Whole system takes ~200Mb in memory

23. Summary Easy to use, avoids fundamental queries very often copied and cloned over the projects. Covers needs across accelerator controls system Can be extended 20/06/2013 arkadiusz.gorzawski@cern.ch te/mpe technical meeting 23

24. The End TE/MPE TM 20.06.2013