CERN Accelerating science

Sequencer Requirements

Tevatron sequencer

Draft functional sepcification [October 2006 -pdf]

LHC cycle - breakdown

LHC

Tevatron in a lot of ways similar to LHC, we have:

• A loosely coupled, finite number of, systems, some of which maybe accurately described by a state model.
• Some systems have a simple internal state model - collimators, kickers for example. Upon these one can presumably build operational state models.
• Other systems have a internal state model (power converters - on, armed, executing ramp, etc.) which if we thought about it could build up a operational state model (specify both internal & operational states in any diagram). The problem is that the data content of the states is fluid and critical. Is a corrector with a setting of 1.0 A in a different state from 1.1 A).. In physics self-transitions with a change of data content (i.e. a trim) are common, of course.
• The state of the whole accelerator is rather nebulous (except in special circumstances). This might be due to our inability to properly describe internal transitions.
• We cannot pre-load all our settings: 1. the power converter FGCs do not implement this 2. we expect re-loading to be necessary because of the machine dynamics.

From FNAL

• Language
• Harness for system state diagrams - how are we going to implement these?
• Full breakdown of all tasks performed - what are we missing?

LHC  Sequencer Requirements

Need to drive tasks (activities) that have to be performed in a given LHC mode or that have to be completed to allow the LHC transition from one mode to another. Provide a tool to allow reproducible, and reliable beam based LHC operation.

• high-level equipment and beam related tasks
• coordinated data acquisition and saving.
   
• The sequencer should be able to perform tasks in parallel. Handle multithreading/distributed processing logic
• Support multiple sequence definitions.
• Allow re-use of sub-sequences in different sequences.
• It should be easily configurable - add/delete/change task specification
• It should catch return code of executed tasks and react appropriately: - stop, continue, issue warning, abort, start another sub-sequence.
• Display progress and status of executing tasks.
• Allow operator to abort executing task(s).
• Allow operator to manually drive sequence
• Allow operator to manually drive sequence for given subsystem
• Allow operator to manually abort sequence
• Security - only executable from predefined consoles
• Logging and error reporting: records all tasks performed (& timestamp, parameters etc) and any error conditions.
• Is able to accept external input from monitoring or machine protection process and modify behaviour appropriately

Need to bear in mind that LSA provides comprehensive settings management and drive facilities. Clearly need a task based interface to LSA middle-tier functionality. Could test this with script based approach in the first instance.

Examples

PreInjection

Ramp down to ~ 600 A. [Drive] Check that power converters have performed cycle down properly. [Check]
Collimators out  [Settings][Drive] [Check]
TDI to parking  [Settings][Drive][Check]
TDCQ out  [Settings][Drive][Check]
Kickers to standby [State][Drive]
Dumps - active  [Read State][Read Parameters][Check]
Check kicker timing [Read Parameters][Settings][Check]
Check BST. 
RF: 400 MHz & transverse dampers:

• Set RF frequency to injection level [Settings][Drive]
• Set the gain of the phase loop amplifier [Settings][Drive]
• Set the gain and time constant of the synchronization loop amplifier, [Settings][Drive]
• Close the phase loop around the VCO [State][Drive]
• Switch the RF DRIVE ON, Switch the phase loop to the cavity sum signal [State][Drive]
• Reset the revolution frequency generator - see RF [State][Drive]

BI: check that BI front-ends are pre-configured with [Settings] relevant to the foreseen beams.

Implementation

• Lightweight GUI providing operator interface
• Sequence configuration, task description etc. on Oracle database
• Sequence engine - middle tier
• Possibly, possibly (Reyes) a set of supervisor processes and associated monitoring processes, which take care of fulfilling sequence requests. These could be implemented as state machines, although, perhaps. not always clear that this is necessary or useful. Her document.
• Lot of actions can be fulfilled by LSA. Here we have all settings, commands and the ability to drive.
• Error handling process
• Logging

Ramp & squeeze power converters - hwc tests - first prototype

• Switch on group of power converters - LSA
• Set PELP values (from database - actual settings - identified by context) - LSA
• Send timing or go now request - timing/LSA
• Monitor until power converters current = injection level ....
• Load ramp table (from database - functions - indentified by context) LSA
• Send timing or go now request timing/LSA
• Monitor etc. ....