Initial MOOT

Goal

A version of MOOT (Modes Of Operation Tracking) and associated interfaces suitable for the initial use of Flight Software to do calibrations.

Ground rules

The database structure for the stripped-down MOOT will be as described in the relevant section of MOOT Report for 12 August (that is, the schema will be unchanged in the reduced version though for both reduced and full version, may want to dispense with History table), however MOOT will be limited in scope in two respects:

• Only three categories of configuration information will be tracked: LATC configurations, LCI input, and software configuration (e.g. for Filter). Several categories included in the full-blown scheme, such as house-keeping scheduling parameters, thermal control parameters and PIG input will be left out. Configuration for these categories should be very stable, so a sophisticated tracking scheme won't be necessary to start. To be confirmed
• Each FSW binary belonging to a configuration will have a single source, even though the MOOT design allows for the possibility of several sources being used to produce a single FSW binary.

Some idea of the simplification can be seen by comparing diagrams of the complete model and the reduced one.

Defining a configuration

The end result will be some FSW binaries and several entries in MOOT's database: a top-level one in the Configs table, several in the FSW_inputs table, several in the Parameters table, and entries in auxiliary tables so that, given a Config id, one can trace it to the FSW_inputs and parameter files of which it is composed. In the stripped-down model FSW_inputs are in one-to-one correspondence with parameter files. A Config will be made up of 1 or more software configuration files (exactly which will be tracked TBD), up to 16 LATC-related files, including a LATC master, and, for calibration mode configurations, one LCI source file.

In order to ease the migration from Latte methods of settting registers to LATC, a utility is being written to translate a Latte xml file to the equivalent LATC file. It should be straightforward to implement another step to break up an arbitrary LATC file into the pieces (DFT, GEM, AEM and one for each additional LATC component with exceptional register settings) required for the stripped-down model. Assuming these pieces, as well as software configuration files and LCI file if applicable, are all available, steps are:

• Store the sources in CMX, or else come up with some other place for them. Avoid duplicate source files. Different configurations may share some of the same source files.
• Register all the source files in the Parameters table and also in the FSW_inputs table.
• Invoke appropriate FSW service to create corresponding binaries or will this be done either by CMX, as part of build process, or by fmx add?
• Do fmx add or other command to add the files to the fmx Logicals table. FMX is geared to handling code, not configuration. It should be possible to use it for configuration as is, but some adjustments would be welcome.
• Do fmx upload of at least the LATC files (so that file_ids will be assigned).
• Determine file_id for uploaded files; store in FSW_inputs.
• Make LATC master file, register in MOOD as was done for the other files.
• Do fmx add and fmx upload for the master file.

Along the way, various other updates will have been made to MOOD to keep track of the state of these files.

Are there any changes to the above if the files are uploaded to RAM?

Using a configuration

At some point before use, perhaps well before, need to do fmx commit for all the files. Since this is so closely tied to fmx upload it might be part of the previous procedure.

Is the request to use these binaries part of a run command, or an independent request?
Sergio: It's part of start run. What exactly does get specified at start run?

FMX questions

1. Is there a programming API as well as command-line interface? I don't see one in the code.
   Answer from Sergio: no, command-line only.
2. An api that would suit my needs well would look something like

           logical_id = add(source file)

   where source file description is similar to that for existing add

           file_id = upload(logical_id)
           status = commit(file_id)

   (or substitute physical_id for file_id, but then also include easy way to get file_id from physical_id)
   From Sergio: one can use sql queries to get physical_id or file_id.
3. Current FMX version apparently knows how to transform sbx (whatever that is) and lhk input xml files to binary and does so as part of "add". Will FMX ultimately do this for other file types, such as LATC and LCI?

Initial draft: 24 September 2005 Last revised:

J. Bogart