LSA TB 10.11.2016 - Indico

Settings persistency
for the LHC
Enrico Bravin
CERN BE-BI
BI technical board - 10 November 2016
Status and motivation
•
•
For many BI systems settings managed by FESA
persistency only
•
No trace of changes
•
Difficult to recover the proper values in case
persistency is lost or wrong values are set by
mistake
Ad hoc solutions invented by experts to cope with
this (logbook, private setting files, LDB etc.)
CO Supported solution
•
To operate LHC zillions of dynamic settings are needed
•
LSA (LHC software architecture) designed for the LHC
•
A database of settings and the tools to manage/drive them
•
Later the concept was expanded to the injectors → INCA
•
CO provides an LSA API + number of tools to access/manage
the settings
•
INCA concept added to JAPC (if you incaify the application) to
simplify the introduction of INCA in the existing injector systems
Equipment access
Application
Application
JAPC
Application
JAPC
INCA
RDA
RDA
FESA
FESA
Direct access
RDA (C++)
PyRDA/PICA
Direct access
JAPC (JAVA)
PyJAPC ?
LSA DB
RDA
FESA
LSA/INCAified applications
Equipment access
Application
Application
JAPC
Application
JAPC
INCA
RDA
RDA
FESA
FESA
Direct access
RDA (C++)
PyRDA/PICA
Direct access
JAPC (JAVA)
PyJAPC ?
LSA DB
RDA
FESA
LSA/INCAified applications
The good
Equipment access
Application
Application
JAPC
Application
JAPC
INCA
LSA DB
RDA
RDA
FESA
FESA
Direct access
RDA (C++)
PyRDA/PICA
Direct access
JAPC (JAVA)
PyJAPC ?
LSA/INCAified applications
The bad
The good
RDA
FESA
Equipment access
Application
Application
JAPC
Application
JAPC
INCA
LSA DB
RDA
RDA
FESA
FESA
Direct access
RDA (C++)
PyRDA/PICA
Direct access
JAPC (JAVA)
PyJAPC ?
LSA/INCAified applications
The ugly
The bad
The good
RDA
FESA
Win and lose
•
•
Advantages of using INCA/LSA
•
History of settings (can tag “golden” values using labels)
•
Easy to revert to values at any point in history
•
Settings can be dynamic (beam process/hyper cycle)
•
Possible to re-drive settings at start of cycle
Disadvantages
•
Access only with JAVA: JAPC (PyJAPC) + LSA-API
•
Limitations on the data types (minimal)
•
No partial settings
•
Fields should not be duplicated in different properties
Data types
•
•
Supported
•
scalars
•
1D and 2D arrays
Not supported
•
Array of enums (enums are stored as strings)
•
Bit sets (can be stored as Int though)
How should we implement
LSA?
•
We typically have many settings that do not require management
•
•
Settings that are automatically updated, settings that are actually acquisitions
etc.
We typically have several properties to access the same field
•
Settings, Expert settings, Guru settings etc.
•
We often use partial settings because we don’t dear to send the whole thing 😰
•
The easiest solution would be to add one or more dedicated properties like
LSASettings to each class with a copy of the interesting fields
•
Can still play around with old expert tools bypassing LSA for setting up / testing
etc.
•
Capture a working state into LSA as production values
Conclusions
•
LSA/INCA is the only official supported way of managing
settings
•
No reason to reinvent the wheel!
•
Probably most FESA classes need modifications before
importing into LSA
•
Need to compile a list of classes/devices/fields that need
settings management (by the equipment manager)
•
As this goes on top of present BI-SW workload need to
define priority