260 likes | 383 Views
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. OP requirements.
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