260 likes | 395 Views
This document outlines the critical requirements for optimizing machine settings through effective multiplexing, archiving, and persistency. Key discussions, led by experts like M. Benedikt and J-J. Gras, emphasize the necessity for live machine settings within Front-ends, robust archiving facilities, and the dynamic naming and management of setting sets. It covers equipment-specific settings, critical settings for LHC and SPS transfer lines, and vital tools for instantiating these configurations. The document aims to enhance the operability and management of advanced equipment settings effectively.
E N D
Multiplexing, archiving& persistency Topics coming across CO, OP & Equipment Groups ! From discussions involving : M. Benedikt, B. Frammery, J-J. Gras, M. Lamont, J. Lewis, J-L. Nougaret, R. Steerenberg, J. Wenninger, M. Zerlauth
Main requirements b.frammery
OP requirements • Availability of a number of machine settings “alive” in the Front-ends (for multiplexing those machines) • Availability of a large number of machine settings archived in database • Storing complete machine settings to archive • Loading complete machine settings from archive to replace any of the “alive” machine settings • Naming and renaming dynamically sets of machine settings to clarify their usage (mainly requested for PS Complex) . • Create new sets of machine settings starting from settings stored in database b.frammery
Equipment specialists requirements • 3 types of experts settings • Equipment settings beam-dependent: multiplexed on different kind of criteria and with archiving facilities • Configuration parameters : settings only related to hardware configuration. No archiving, no multiplexing needed • Critical settings for LHC and transfer lines from SPS : archiving and solid persistency needed • Specific tools needed to instantiate and manage these settings b.frammery
A first look at the concepts b.frammery
Settings Configuration parameters Settings Front-Ends S1 S2 S3 “Slots” for multiplexed settings S4 Configuration parameters … S22 S23 S24 Settings & parameters in FECs non-multiplexed Front-end memory space b.frammery
Settings Settings Configuration parameters Configuration parameters Front-Ends Front-Ends S1 S1 USER_X S2 S2 USER_D … S3 S3 USER_M … S4 S4 USER_U … … … S22 S22 USER_A non-multiplexed non-multiplexed S23 S23 USER_K S24 S24 USER_J Timing system Basic ingredients Edited by operations T e l e g r a m USER_D … USER Destination Part. type … USER_D d2 p Look up table Front-end memory space b.frammery
Configuration parameters Configuration parameters Configuration parameters Settings Settings Settings S1 S1 S1 USER_X USER_X USER_X S2 S2 S2 USER_D USER_D USER_D S3 S3 S3 USER_M USER_M USER_M S4 S4 S4 USER_U USER_U USER_U … … … … … … S22 S22 S22 USER_A USER_A USER_A S23 S23 S23 USER_K USER_K USER_K non-multiplexed non-multiplexed non-multiplexed S24 S24 S24 USER_J USER_J USER_J Multiplexing Front-Ends USER_D USER_D USER_U USER_K USER_D USER_U USER_D USER_U USER_U Sequence of cycles USER_U USER_K USER_K non-multiplexed USER_K non-multiplexed non-multiplexed Front-ends b.frammery
Configuration parameters Configuration parameters Configuration parameters Settings Settings Settings S1 S1 S1 USER_X USER_X USER_X S2 S2 S2 USER_D USER_D USER_D S3 S3 S3 USER_M USER_M USER_M S4 S4 S4 USER_U USER_U USER_U … … … … … … S22 S22 S22 USER_A USER_A USER_A S23 S23 S23 USER_K USER_K USER_K non-multiplexed non-multiplexed non-multiplexed S24 S24 S24 USER_J USER_J USER_J Storing into archive Front-Ends Front-Ends USER_D USER_D Database USER_D USER_D h/d/m/y non-multiplexed non-multiplexed non-multiplexed b.frammery
Configuration parameters Configuration parameters Configuration parameters Settings Settings Settings S1 S1 S1 USER_X USER_X USER_X S2 S2 S2 USER_D USER_D USER_D S3 S3 S3 USER_M USER_M USER_M S4 S4 S4 USER_U USER_U USER_U … … … … … … S22 S22 S22 USER_A USER_A USER_A S23 S23 S23 USER_K USER_K USER_K non-multiplexed non-multiplexed non-multiplexed S24 S24 S24 USER_J USER_J USER_J Loading from archive USER_Z USER_Z USER_Z Database non-multiplexed non-multiplexed non-multiplexed USER_Z h/d/m/y Front-Ends b.frammery
Configuration parameters Configuration parameters Configuration parameters Settings Settings Settings S1 S1 S1 USER_X USER_X USER_X S2 S2 S2 USER_D USER_D USER_D S3 S3 S3 USER_M USER_M USER_M S4 S4 S4 USER_U USER_U USER_U … … … … … … S22 S22 S22 USER_A USER_A USER_A S23 S23 S23 USER_K USER_K USER_K non-multiplexed non-multiplexed non-multiplexed S24 S24 S24 USER_J USER_J USER_J Persistency Every x minutes Database Backup Archives Front-Ends b.frammery
Handling settings b.frammery
Handling settings (1) • 24 “slots” are defined in every Front-End to hold 24 active sets of machine settings • USER is the only key for archiving machine settings • USER is the main key for multiplexing machine settings • Then, how to multiplex on other keys than USERs? b.frammery
t e l e g r a m … USER Destination … … USER_N d2 … Handling settings (2) • Device settings not multiplexed on USERs are considered as different devices “inside” a USER • Exclusive enabling of one of the devices driven by telegram N Y N USER_N USER_W • Valid only for a few devices ! b.frammery
Handling settings (3) • Complete machine settings are archived: • all the machine settings • all non-multiplexed machine settings • This includes expert settings & critical settings • Archives are organized by USER names & dates • Configuration parameters are not archived b.frammery
Handling settings (4) • Settings are restored from archive • according to USER names & dates • globally per machine … or • by subsets for a given machine …and possibly • with authentication procedures (critical settings) • possibility to restrict the management of subsets of settings to specific specialists b.frammery
Handling settings (5) • Transmission of settings from applications to the FECs according to “strings” containing a USER name • Ex : CPS. SFTPRO. Xxx • The strings are converted to FEC slot numbers by a routine of the timing library (“referred to as “lookup table”). • Active USER names are propagated throughout the control system when a name of an active USER is changed: • Renaming of an active USER, • Replacement of an active USER by another from archive b.frammery
Handling beams in LHC • Beams are managed through “Beam types” • List of these different types not yet known • Critical settings archived separately • Two possibilities (still an opened question) : • Multiplex the LHC on Beam types • then the USER is the Beam type • Not multiplex the LHC • download before every change of Beam type the settings of the parameters sensitive to Beam types (as for critical settings) b.frammery
Who does what ? b.frammery
Timing system • Provides the multiplexing keys (telegram) • Provides the lookup table mechanism to correlate USER name and FEC slots • Propagates USER name changes to the Front-ends and to the application programs (console manager) b.frammery
FESA • As the new Front-end software infrastructure for all the CERN accelerators, FESA has to: • Allows the multiplexing of the injectors including the SPS • Takes care of persisting active machine settings (backup storages ~ every 5 minutes) • Allows for a good management of operations settings, expert settings (and critical settings ?) • Is adequate for non-cycled machines as LHC • Preserve/enhance the functionality existing in the present multiplexing scheme • Propagates a “default” value into the 24 “slots” active in the Front-Ends at instantiation of a new parameter. b.frammery
LSA • LSA handles the archive mechanisms • (few words but heavy task !) • Currently, lots of legacy: transition to be defined b.frammery
Equipment groups • Specific software (RT tasks) for the running of non-USER multiplexed settings • Expert program to access configuration parameters • … b.frammery
Discussion opened … b.frammery
The 2006 SPS USERs 24 USERs defined by OP to cover the whole 2006 year b.frammery