LICOS/MOOT Interface

Write- or Command-like Services

Register a new parameter file

Information to be supplied includes

• Location of file
• Parameter class; see this table of proposed parameters for examples
• quality – values come from an enumerated set, such as {'PROD', 'DEV', 'TEST', 'SUPSED', 'INVALID'}
• File format
• Start of time interval and, optionally, end of interval, during which information in the file is valid
• Human-readable description of any features of interest
• (Maybe) Instrument to which the information applies (to distinguish, e.g., flight instrument from teststand instruments)
• flavor – a sort of wildcard for marking variants of the standard file of this type. Could default to something like "default" or "vanilla"
• other fields as necessary so that it is possible to look up parameters of interest; TBD. For example, for certain kinds of parameters, like thresholds, we might need different values for muon runs.

Here register means, at a minimum, make a new entry in the Parameters table of MOOD. It may also entail archiving the file somehow; e.g., put it in a CVS repository. If so, the source field for the new entry will point to the archived version of the file.

Form a new configuration

Mode (data or charge-injection calibration are the only options to start) is the first input. From this MOOT can figure out which kinds of parameter files it needs to form a complete configuration. In the very simplest case it would find everything—that is, appropriate instances for each kind—it needs in the Parameters table without any need for further input by picking out the unique (because we're assuming simplest case) file of each type which is both of standard flavor and is valid at the current time. Otherwise either

• the user specifies more information to select among different possible files; e.g., for each parameter needing a variant file, specify flavor to search for. The "more information" might consist of values to be matched for the new TBD fields in the Parameters table, as mentioned above.
• the user is presented with menus of possibilities

Need to support the first option for batch-type requests; the second is nicer for interactive requests.

Once the collection of parameter files is determined, MOOT should go off and determine whether the output products (e.g., LATC-produced binaries) exist, and build any that don't. Conceivably it could discover that the "same" configuration (i.e., identical collection of parameter files as input) already exists, and abort at that point.

Activate a configuration

First step is for user to select the configuration to activate. Either the user

• already somehow knows the config_key (unique serial number) for the desired row in the Configs table
• finds it in the table by querying other fields, such as name
• is presented with a menu of configurations and selects one

Next MOOT has to determine whether all the binaries have been uploaded. If not, it, or its agent, will have to issue the necessary commands.

Finally it (or agent) will have to issue commands to activate.

Assume that LICOS handles the actual upload and activate commands. Then sequence might be:

1. LICOS asks MOOT to activate Config #xx
2. MOOT determines corresponding list of FSW_inputs.
3. If not all exist, it outputs error and quits. Otherwise, it queries FMX to determine upload state.
4. MOOT returns list of FSW binaries to be uploaded (if any)
5. LICOS handles the actual upload; then reports back (to MOOT? or directly to FMX?) successful uploads, or quits if not successful. If LICOS invokes MOOT service for this, MOOT will in turn tell FMX. The uploaded/not uploaded information is maintained only by FMX.
6. MOOT determines which parts of the configuration need to be activated (how? who keeps track of this?) and reports back to LICOS.
7. LICOS issues commands needed for the activation, then informs MOOT when complete.
8. MOOT updates History table and informs other facilities as needed about activation.

Look-up Services

Look up what configuration was active at a particular time, what parameter files are associated with a particular configuration.

What else is needed?

Initial draft: 8 September 2005 Last revised:

J. Bogart