InCA overview and plans

1. InCA overview and plans G.Kruk on behalf of the InCA team

2. Agenda • What is LSA? • Introduction • Scope • Basic Concepts • Settings Management with LSA • Why InCA? • Pre-InCA vs. InCA • Summary of 2011 • Plans for 2012 • Resources • Support G.Kruk

3. Agenda • What is LSA? • Introduction • Scope • Basic Concepts • Settings Management with LSA • Why InCA? • Pre-InCA vs. InCA • Summary of 2011 • Plans for 2012 • Resources • Support G.Kruk

4. What is LSA? • LHC Software Architecture • Project started in late 90’s as SPS2001 • Mike Lamont became PL around 2001/2002 • Several OP people involved: L.Normann, G.Crockford, M.Albert, D.Jacquet, J.Wenninger, A. Rey, … • SPS Transfer Line tests in 2003/2004, LEIR in 2005, SPS in 2006, LHC in 2007/2008 • Few concepts were suppressed over the years • Many new functionalities were added • But the core ideas stayed G.Kruk

5. What is LSA? • Sizable project • > 500K lines of code • ~ 150 applications using services provided by LSA • Highly data-driven • ~150 database tables • Shared between OP and CO • CO: Framework, database, generic libraries, generic GUI applications • OP: • Domain knowledge • Code requiring expert knowledge: MakeRules, ValueGenerators, … • Generic GUI applications: Trim Editor, Generation App., … • Equipment specific GUI applications G.Kruk

6. Scope • Machine Layout • Accelerators and transfer lines • Device types, devices and properties • Attributes of specific devices • Optics • Optic strengths • Twiss parameters • Settings Management & Trim • Generation of initial settings based on Optics • Coherent modifications • History of changes and rollback • Archives and References • Hardware Exploitation • Abstraction of the hardware • Writing/reading settings to/from the hardware • Equipment control • Hardware protocol e.g. PS MPS G.Kruk

7. Key Concepts • Particle transfer • Parameter • Context • Setting G.Kruk

8. Particle Transfer • Accelerator is composed of Accelerator Zones • PS, F16, F61 • SPS, TT40, TT41, TI8, WEST_EXTRACTION • Every device belongs to a single accelerator zone • Particle Transfer - Sequence of accelerator zones that beam passes through • PSRing: PS • CNGSTransfer: TT40, TT41 • PSBInjection: LT, LTB, BI, … • Optics are defined per particle transfer G.Kruk

9. Parameter • Settable or measurable entity on a device (real or virtual) • Is of a certain type: MOMENTUM, K, I, GFAS/CCV#value, … • Value Type (function, double, int), min, max, unit, … • High level physics (virtual) orhardware (external) • Relation with hardware properties • FGC: IREF parameter  two properties (time, current) • FESA: one LSA param  property field (Dev1/Prop1#field1) • GM: one LSA parameter  single device property G.Kruk

10. Parameter Hierarchies (1) LSS4_EXT_BUMP/KNOB • Parameters can be organized in hierarchies • Each hierarchy describes relations between parameters • Change of parameter affects its all dependent parameters • In the first approach (SPS/LHC) • Roots  physics parameters • E.g. momentum, tune, chromaticity • Leaves  hardware parameters • E.g. current, voltage, … MPLH.419994/K MPSH.42198/K MPLH.419994/I MPSH.42198/I MPSH4219/IREF MPLH4199/IREF G.Kruk

11. Parameter Hierarchies (2) • Single parameter can belong to several hierarchies • But one of them is default • We use it to: • (Re) calculate high level parameters from HW parameters • Model logic currently implemented in some GM classes • Sometimes it get’s tricky K DEFAULT I UP CCV G.Kruk

12. Context • Context  “Container” for a set of parameter values (settings) • Three categories of contexts: • Beam Process • Defines a specific process of the beam e.g. injection, ramp, extraction • Cycle • Composed of Beam Processes • Defines a lifespan of a beam from injection to extraction • Corresponds to the timing cycle • Super Cycle • Sequence of cycles in a fixed order • Used when the order of cycles is important and cannot be changed • e.g. because of magnetic history G.Kruk

13. Context Type • BeamProcess Type • Defined for a particle transfer • Length • Optics Function: time in the beam process  optic • Custom attributes used for settings generation • E.g. Ramp type, start/end energy, Bdot, etc • Cycle Type • Scheduling of beam process types • What Beam Process Type at what time • Custom attributes used for settings generation and trims • Super Cycle Type • Sequence of Cycle Types • All contexts are instances of corresponding types G.Kruk

14. Fixed target p+ cycle MD cycle SPS Ring SPS Injection Context Example CNGS Transfer G.Kruk

15. More about Contexts • Cycle and Beam Process can be used as a part of Super Cycle or independently (stand alone) • StandAloneBeamProcessand Cycle can be mapped to a timing user • We say then that the context is RESIDENT • Only settings from RESIDENT context can be sent (driven) to the hardware • In each accelerator there is one special NON_MULTIPLEXED context • It is always RESIDENT • Used to keep non-PPM settings G.Kruk

16. Setting • Value of a parameter for a given context • Every setting is assigned to a beam process • Setting is composed of two parts • Target – theoretical (generated) value • Correction – corrections added by manual trims or calculated/acquired for specific devices • Setting value = target + correction 1 * * 1 Parameter Setting Beam Process G.Kruk

17. Managing settings with LSA Make sure that you have sufficient (and correct) information about devices and parameters you plan to control Import Optics for each particle transfer Prepare your context(s) Initialize settings for parameters you want to control Adjust the settings when necessary (Trim) Send settings to the hardware (Drive) Measure and Validate G.Kruk

18. Settings Initialization • Generation with Value Generators • Implementations depend on parameters and are based on: • Optics (that are known via BeamProcess) • e.g. Tune • Beam Process and Cycle Type attributes • e.g. MOMENTUM, B, Timing • Hardcoded values • e.g. initialize to ZERO • Specific sources • e.g. FiDeL corrections (LHC) • Initialization via Acquisition from the hardware • Copy Settings from another context Beam Process Parameter ValueGenerator Initial Setting G.Kruk

19. Trim • Coherent modifications of parameter settings • Propagates change of a parameter to all its dependent parameters • Keeps history of changes • Allows rollbacks • Translation between source and dependent parameters is done usingMake Rules • It’s a bit more complicated than that: • LinkRule, IncorporationRule, • AdaptationRule, RevisionRule P1 P2 Make Rule P3 G.Kruk

20. Hardware Access • Writing/Reading settings to/from the hardware • The central entity is SettingAwareDevice • Per Device Type or DeviceType/Property • Translation of Settings into hardware properties and vice versa • Supports transactional drive • Hardware Commands  Custom operations on the hardware • E.g. check if collimator positions are correct Setting SettingAwareDevice Hardware Representation (JAPC Param Values) G.Kruk

21. Agenda • What is LSA? • Introduction • Scope • Basic Concepts • Settings Management with LSA • Why InCA? • Pre-InCA vs. InCA • Summary of 2011 • Plans for 2012 • Resources • Support G.Kruk

22. Why InCA? ... G.Kruk

23. Why LSA wasn’t sufficient? • FEC 2 FEC comm.  Parameter Hierarchies, Make Rules • Device Access  SettingAwareDevice • Archives/References  compatible with contexts and settings • Monitoring, acquisitions and status calculations  ? • Configuration service for WS and Knobs  ? • Advanced function editor ? G.Kruk

24. Injector Controls Architecture •  scalability •  performance •  security ... G.Kruk

25. Agenda • What is LSA? • Introduction • Scope • Basic Concepts • Settings Management with LSA • Why InCA? • Pre-InCA vs. InCA • Summary of 2011 • Plans for 2012 • Resources • Support G.Kruk

26. Summary of 2011 • Deployment of InCA in the Booster and Linac2 (July) • Deployment in Linac3 (October) • Acquisition Core • Stabilized architecture • Supports virtual acquisition parameters • Enabled for • CPS: BLM, FGC_53 • PSB: QSTRIP, MATCHING, OPENBUMP, RFFunction,FGC_61 • Well progressed the LKTIM renovation • Renovated • PSB: LINC, RFFunctions • PS: PCALC, HARM • GM COMPAR  SIS (study started) • YASP: fully available in PS and integration started in PSB G.Kruk

27. Summary of 2011 • New GUIs and improvements in existing ones • Function Editor • Simplifications in the Generation App. • Resident Context Manager • Settings Copy • Settings Compare • Drive Log GUI (during shutdown) G.Kruk

28. Agenda • What is LSA? • Introduction • Scope • Basic Concepts • Settings Management with LSA • Why InCA? • Pre-InCA vs. InCA • Summary of 2011 • Plans for 2012 • Resources • Support G.Kruk

29. Plans for 2012 (1) • Fix / improve things reported in 2011 • We didn’t mange to complete them all last year • There are quite a lot of them • Complete renovation of LKTIM • YASP validation for PSB • GM renovation with virtual classes • COMPAR, LINC/S (PS), OP_XYFunction, Virtual GFAS… • Enable progressively AcqCore for subsequent device types • InCA deployment for • SPS (RF) – mostly prepared. Will be used from startup • ISOLDE – we aim for May/June • Study InCA deployment for AD and CTF3 G.Kruk

30. Plans for 2012 (2) – GUI, GUI, GUI • Function Editor • Requested improvements + missing functionality • Open from Working Sets - panels implemented in LSA App Suite • Working Set view in LSA App Suite (selection of parameters) • Compare Settings & Online Check • Settings Copy • Perhaps also other panels • Context Mapping History • Generation Application • Improvements requested also from SPS and LHC • Trim Editor • Configuration Tools • Devices, parameter types and parameters, working sets, … G.Kruk

31. Resources in 2012 • Two persons leave the project • Stephane: became FESA Project Leader • Valery (main developer of the AcqCore and release manager): leaves CERN • Maciej Peryt joins in February (part time) • Configuration Tools • Technical Student coming in March • Generation App, Configuration tools • A Fellow – July in the best case • A Project Associate – not yet sure when G.Kruk

32. Resources in 2012 • For the first couple of months we’ll be less than 5FTE • ~ 0.5 FTE  Injectors support • ~ 1 FTE  SPS and LHC support + new functionalities • Eric  Working Sets, Knobs, Function Editor • This gives ~2.5 FTE for everything else •  less than 2FTE for coding • Doing good GUIs takes a lot of time • Later in the year we’ll get more people • but it will take some time to train them • So please “soyezcompréhensif”… • … and help us prioritize the work G.Kruk

33. InCA Support in 2012 • The same principle as last year • 7 people • Eric, Jakub, Greg, Marine, Pablo, Stephane, Olga (day time) • One week each • Support meeting on Friday(?) with Machine Supervisor(s) • This is “Best Effort” support(no min. time to intervention) • Try to call the support number • If doesn’t respond  call me • If I don’t respond  try other people from the list • Last year – very few calls out of the working hours and only in serious/blocking cases • We appreciate that • During the working hours – DO use the support phone • Especially with issues that might not be easy to reproduce G.Kruk

34. Questions? G.Kruk