0. Definitions

1. MOOT Overview 1.1 Delegates and parameters 1.2 MOOD 1.3 Request to create a config 1.4 Request to load a config 1.5 Queries

2. To do 2.1 Define delegates and parameters 2.2 Equivalent forms; use of FSW 2.3 MOOD detailed design 2.4 Interface to Latte5

3. Schedule

MOOT Report for Week of 22 July 2005

0. Definitions

MOOT

This project: Modes Of Operation Tracker.

MOOD

Database for MOOT.

Mode of operation

Highest-level description of overall LAT state as defined in the LIM Design document. Maybe only a subset of these, including at least Calibration and Physics, are of interest to this project .

Delegate

Separately configurable part of a mode in the above sense (however, there may be some interaction between different delegates within a mode; they need not be entirely independent of each other). Delegates for Physics mode might include

• Housekeeping
• Event filter parameters
• Tracker hardware masks and thresholds
• Calorimeter hardware masks and thresholds

among others. Each delegate has a set of configuration parameters.

1. MOOT Overview

Provide robust, reproducible method to configure (broadly interpreted) the LAT for any supported mode of operation and a means to retrieve the description of any uploaded configuration, current or historical.

MOOT will have a database/record-keeping function and an active piece, to be invoked by Latte5 (used throughout to mean "successor to Latte4", even though it may end up with a new name), which will aid in the generation of configurations in a form suitable for input to FSW services such as LATC, LCI and so forth. [See the Flight Software Traveler Documents page for documentation of these services.]

1.1 Delegates and their parameters: design considerations

• The collection should be complete in two respects: it should include everything that an operator might conceivably want to set, and it should include everything that offline applications might want to interrogate.
• Where possible, delegates should respect boundaries defined by (front-line) Flight Software services; that is, a delegate will normally be concerned with information handled by a single FSW service. (However, the mapping need not be one-to-one; for example, more than one delegate might handle LATC-type input.)
• A single parameter can and probably often will correspond to a large amount of information (such as reference to a file of threshold values), but pieces of information covered by a single parameter should have similar properties: e.g., tend to change at similar intervals. Different parameters for the same delegate are not restricted in this way.

1.2 MOOD

Expect it will be a rdbms, most likely MySQL, with at least two main tables and perhaps other supporting tables as well. Roughly speaking, one table keeps track of requests to create a configuration (call it Configs for the time being), the other keeps track of requests to load (call it History).

A row in Configs has a field for Operating Mode (in the sense of LIM) and contains or references the list of delegates belonging to that mode and their parameters. May want to support the concepts of default and unchanged for delegates or for individual parameters. The row might also contain information about how far along this configuration is in the process of creation, e.g.

• Defined in MOOD only
• Corresponding xml files (or other input to front-line FSW services) exist; some indication of how to find them
• Binary form of configuration has been created

A row in the History table contains at a minimum a reference to a row in the Configs table, and timestamp fields for start and end times for when the configuration was active. There will probably be more fields to keep track of the status of the request to load.

Rows will never be deleted from either table. Some fields within a row will be write-once; others may be updated.

1.3 Request to create a configuration

Latte5 or similar system will invoke a MOOT service, passing as arguments the user-specified delegates and their parameters (or shorthand, such as "use default" or "delta from configuration X"). MOOT also needs to know whether it is just to make database entries or whether it is also to generate XML files or even the binaries corresponding to the request.

1.4 Request to load

It's not yet clear whether MOOT will take an active part in this or will merely provide the services needed to update MOOD.

It may be that the user request to enter a particular state requires implicitly that other intermediate states, such as Quiescent, be entered as well. If so, the intermediate states should also be recorded in MOOD.

During a request to load, other writers should be locked out of the History table.

1.5 Database queries

• Operator needs to browse both major MOOD tables interactively.
• Offline has to look up parameters of configuration active at a particular time.
• What else does ISOC need?

2. To do

2.1 Define delegates and parameters

..according to ground rules laid out above.

2.2 Translation of request; use of FSW

• Pat Hascall has already done a lot of work to understand and categorize the low-level pieces comprising a configuration. That should be of use here and also should feed back into choice of parameters in the previous item.
• Become acquainted with all relevant FSW packages. Is there anything configuration needs to touch which is not yet handled via some higher-level FSW tool?
• Understand how to resolve any indirections in parameters
• Where might delegates conflict or at least interact? That is, to what extent can translation proceed independently for the different delegates?
• Under what circumstances is it necessary or preferable to go all the way to the binary form? To defer to a later time?

2.3 MOOD detailed design

The heading pretty much says it all.

2.4 Interface to Latte5

Define MOOT's role vis-à-vis Latte5. What services does it need to provide? How are they parametrized? If Latte5 continues to be run on Windows while FSW services are available only on Linux, are there pieces of MOOT on both?

3. Schedule

It's unlikely that anything in the to-do list can be crossed off as "done" any time soon. Instead, everything, or nearly everything, will have to evolve together; that includes details of design as well as implementation. Problem is further complicated by the moving target aspect of facilities MOOT will interact with. However, it should be possible to design in detail and implement an essential fraction first, while keeping in mind a broader picture which will allow addition of the remainder without major cataclysms.

3.1 Next week

• Make a list of modes and delegates. Aim for completeness, though it likely won't be achieved.
• Make a stab at listing parameters for the major delegates involved in Calibration and Physics modes.
• Come up with one or two milestone-type jobs with a completion date on the order of a month from now.

On a slightly longer timescale, attempt to define the "essential fraction".

next week (28 July 2005)