BLM settings management in LSA

1. BLM settings management in LSA BLM Audit 10/06/2008 Grzegorz Kruk (AB-CO-AP)

2. Agenda • LSA settings management basics • Parameter space for BLMs • Generation of initial BLM settings • Trims & sending settings to the HW • MCS for BLMs • Testing • Operational validity checks • Summary BLM settings management

3. Agenda • LSA settings management basics • Parameter space for BLMs • Generation of initial BLM settings • Trims & sending settings to the HW • MCS for BLMs • Testing • Operational validity checks • Summary BLM settings management

4. Settings management basicsKey Concepts Parameter Settable or measurable entity on a device (real or virtual) e.g. LHCBEAM/QPH, MPLH.41994/K, MPLH4199/IREF In case of FESA – one parameter corresponds to one property field e.g. BPMOPOS_1/Setting#gain (<device>/<property>#<field>) Context Super Cycle Cycle Beam process (LHC) Non-Multiplexed (context independent) – BLM thresholds case Setting Value of a parameter for a given context Parameter Setting Context BLM settings management

5. Settings management basicsParameter space Parameters can be organized in hierarchies Each hierarchy describes relations between parameters Change of a parameter affects all its dependant parameters Roots usually physics parameters e.g. momentum, tune, chromaticity,… Leaves hardware parameters e.g. reference current on power converters LSS4_EXT_BUMP/KNOB MPLH.419994/K MPSH.42198/K MPLH.419994/I MPSH.42198/I MPSH4219/IREF MPLH4199/IREF BLM settings management

6. Settings management basicsLHC Horizontal Tune parameter space BLM settings management

7. Settings management basicsSettings initialization In order to manage settings we need to initialize them: • Using ValueGenerators • Compute initial setting based on optics • Typically defined for a parameter type e.g. LHCMomentumValueGenerator • By acquisition from hardware • This can be done at the moment only for parameters which directly correspond to device properties i.e. for parameters which represent FESA properties (fields) BLM settings management

8. Settings management basicsTrim BLM settings management

9. Agenda • LSA settings management basics • Parameter space for BLMs • Generation of initial BLM settings • Trims & sending settings to the HW • MCS for BLMs • Testing • Operational validity checks • Summary BLM settings management

10. Parameter space for BLMs Threshold values for all energy levels and integration times BLM family Master table Set up by BLM experts x Factors [0 -> 1] for all monitors belonging to given family Edited (trimmed) by operators Monitor factors = Sent to the hardware Applied table Product of the multiplication BLM settings management

11. Parameter space for BLMs BLM family 1 BLM family N Threshold values for all energy levels and integration times Master table Master table … x x Factors [0 -> 1] for monitors belonging to given family Monitor factors Monitor factors = = Product of the multiplication Applied table Applied table Thresholds (72 fields) - thresholdsCard1 - thresholdsCard2 - … Applied tables must be combined into the format of the FESA property Sent to the crate over CMW BLM Crate BLM settings management

12. Parameter space for BLMs Tables in LSA DB Master table BLM_INFO BLM_FAMILIES BLM_FAMILY_THRESHOLDS x BLM_1 / MONITOR_FACTOR … Monitor factors Parent-child relation between all monitor factors and field parameters BLM_256 / MONITOR_FACTOR = CRATE_X / Thresholds# monitorThresholdCoefficients CRATE_X / Thresholds# thresholdsCard1 Applied table CRATE_X / Thresholds# thresholdsCard2 CRATE_X / Thresholds# … LSA Parameters BLM settings management

13. Agenda • LSA settings management basics • Parameter space for BLMs • Generation of initial BLM settings • Trims & sending settings to the HW • MCS for BLMs • Testing • Operational validity checks • Summary BLM settings management

14. Generation of initial BLM settings • Parameters representing Thresholds property fields (applied table) are not trimable • They are computed from monitor factors using a dedicated MakeRule • Values are kept in LSA DB as settings but they cannot be changed by LSA Trim API • What we generate are MONITOR_FACTOR parameters • Done with a dedicated ValueGenerator which initializes factor value with 1 BLM settings management

15. Generation of initial BLM settings BLM settings management

16. Agenda • LSA settings management basics • Parameter space for BLMs • Generation of initial BLM settings • Trims & sending settings to the HW • MCS for BLMs • Testing • Operational validity checks • Summary BLM settings management

17. Trim BLM_X / MONITOR_FACTOR Tables in LSA DB BLM_INFO <uses> BLM_MakeRule BLM_FAMILIES BLM_FAMILY_THRESHOLDS CRATE_X / Thresholds# monitorThresholdCoefficients CRATE_X / Thresholds# thresholdsCard1 CRATE_X / Thresholds# thresholdsCard2 CRATE_X / Thresholds# … BLM settings management

18. Trim BLM settings management

19. BLM Threshold Factors Editor Slides by Fabio Follin, AB/OP BLM settings management

20. BLM Threshold Factors Editor • Security assured by RBA and LSA Trim API • The BLM threshold factors are loaded from LSA • Possibility to load all monitors or load only the monitors of a family • Possibility to add a filter to the threshold factors loaded: • Location (Quad, …) • Type (IC, SEM) • Section (LSS, DS, ARC) • Sector Part (Left, Right) • Sector Number (1 to 8) • Beam (1 or 2) • Transverse position (External, Internal, Top, Bottom) • Position on Element (Entrance, Center, Exit) • Observed Element Slides by Fabio Follin, AB/OP BLM settings management

21. BLM Threshold Factors Editor • Threshold factors can be displayed and edited in a graph or a table • Edition is like normal Trim Editor • Possibility to set, add or subtract an offset or multiply with a factor • The range of the threshold factors is from 0 to 1 • The editor prevents to send values out of range • A Trim History management will be provided • The threshold factors modified are send to Hardware via the LSA Trim API Slides by Fabio Follin, AB/OP BLM settings management

22. Sending settings to the HW • Every time a single or a group of monitor factors are modified – the corresponding applied table is sent to the crate • Setting the whole property for a one crate takes quite some time • We observed from 20s to over a minute BLM settings management

23. Agenda • LSA settings management basics • Parameter space for BLMs • Generation of initial BLM settings • Trims & sending settings to the HW • MCS for BLMs • Testing • Operational validity checks • Summary BLM settings management

24. MCS for BLMs Every time any monitor factor is modified  applied table together with digital signature are recomputed BLM_1 / MONITOR_FACTOR … BLM_256 / MONITOR_FACTOR CRATE_X / Thresholds# monitorThresholdCoefficients CRATE_X / Thresholds# thresholdsCard1 signature field is sent to the crate together with all other fields and verified on the front-end CRATE_X / Thresholds# thresholdsCard2 CRATE_X / Thresholds# … CRATE_X / Thresholds#signature LSA Front-end MCS verification BLM Crate BLM settings management

25. Agenda • LSA settings management basics • Parameter space for BLMs • Generation of initial BLM settings • Trims & sending settings to the HW • MCS for BLMs • Testing • Operational validity checks • Summary BLM settings management

26. Testing Where can we possibly have a problem? (from LSA point of view) • Incorrect master table • ? • Incorrect parameter space e.g. wrong hierarchy between monitor factors and corresponding crate fields • Validation of the hierarchy in the BLMMakeRule (on each trim) • Bugs in BLMMakeRule or in the code reading BLM info and master table • Unit testing (Junit) • Driving to the hardware can be buggy • Unit testing (Junit) • Bugs on the front-end • ? • Bugs in the hardware (e.g. in electronics) • ? BLM settings management

27. ‘Read-back’ test The master table and monitor factors where defined in DB with such values that the test code can deduce what should be the correct threshold value (what it should expect) e.g. threshold on card 1, channel 1, energy level 1 and running sum 1 should be 1111 Master table Parameter space DAO objects (finders, persisters BLMMakeRule Drive settings to HW Test code Send test thresholds to the tested crate The test code doesn’t use any DAO or master table and it was written by a different person Front-end Hardware BLM settings management

28. Testing Where can we possibly have a problem? (from LSA point of view) • Incorrect master table • ? • Incorrect parameter space e.g. wrong hierarchy between monitor factors and corresponding crate fields • Validation of the hierarchy in the BLMMakeRule (on each trim) • Bugs in BLMMakeRule or in the code reading BLM info and master table • Unit testing (Junit) + ‘Read-back’ test • Driving to the hardware can be buggy • Unit testing (Junit) + ‘Read-back’ test • Bugs on the front-end • ‘Round Trip’ test • Errors in the hardware (e.g. in electronics) • ‘Round Trip’ test The ‘Read-back’ test doesn’t ensure that there are no bugs, but significantly decreases the risk BLM settings management

29. Agenda • LSA settings management basics • Parameter space for BLMs • Generation of initial BLM settings • Trims & sending settings to the HW • MCS for BLMs • Testing • Operational validity checks • Summary BLM settings management

30. Operational validity checks The unit testing or ‘Round-trip’ test can be used when new software/hardware version is released, but what if piece of electronics breaks or somebody changes thresholds on the crate somehow bypassing LSA? • MCS check – functionality provided by LSA (exposed via an API) • Checks whether signature correspond to settings (it might be not true if somebody edits settings directly in DB tables) and compares settings stored in LSA DB with values on the front-end (whether they are equal) • Returns OK or NOT OK – plus some more detailed info if NOT OK • Can be executed by the LHC sequencer e.g. before each injection or periodically by SIS (Software Interlock System) • Such a functionality has been already requested by OP for other MCS devices BLM settings management

31. Agenda • LSA settings management basics • Parameter space for BLMs • Generation of initial BLM settings • Trims & sending settings to the HW • MCS for BLMs • Testing • Operational validity checks • Summary BLM settings management

32. Summary • We (LSA) are ready to manage BLM thresholds – BLMMakeRule, drive to HW, DAO have been implemented and tested • The whole mechanism hasn’t been used yet operationally –tested only by an LSA developer on one crate • We have unit tests for the make rule, drive and DAOs and we have also a set up for the ‘Read-back’ test • a bit provisional • If operators / BLM experts would like to use it – it should be set up more properly – e.g like MCS check or with some small dedicated GUI • Can we check correctness of the master table? • The thresholds editor is almost ready (by F.Follin) • The operational validity check (by LHC sequencer and SIS) could be implemented with not very big effort • by developers responsible for these products • Sending thresholds to the crate is a bit long • Might be annoying for operators • Not very comfortable for LSA itself (need to extend CMW timeout) BLM settings management

33. Questions?