Configuration Tracking

LAT Subsystem Managers Face to Face 10/11/05

J. Bogart

Goals

Reconstruct the configuration used for a run

Avoid creating and uploading redundant information

Quickly implement something which satisfies above for upcoming calibration runs and smoothly evolves to handle test data runs and, ultimately, flight.

Reconstruct Config

Input from data stream: identifiers (FMX logical_id) for files in use during the run.

Work backwards from these through config file creation stages to recover intent.

Only possible if MOOT participates along the way.

Conceptual Stages Involving MOOT

Define and create a configuration. End product is collection of binaries.

Determine destination, upload.

Select among uploaded configurations; run.

Analyze data

Implementation

Identify information to work backwards to intent

Design suitable database structure

Implement services needed at each stage

Config Contents

Input to LATC

Input to LCI for calibration runs

Input to Filter, etc., for data runs

For now, at least, MOOT will not keep track of thermal parameters, power-on state, etc. These can be added later if needed.

MOOT will not keep track of code modules.

Config File Pipeline (MOOT view)

Parameter

FSW source

Binary

Uploadable

CAL CFE

enables

CAL

thresholds

LATC CFE

component

source

LATC

output

Has FSW

header, etc.

Only first stage may be many-to-one; all others are one-to-one.

Imagine parallel pipeline for each LATC component

Has

logical_id

Known

to FMX

LATC

FMX

FMX (SIB)

?? (RAM)

??

Plan for Calibration Runs

In addition to reducing definition of configuration to a minimum, will

also simplify by insisting that there be only one Parameter file per

FSW source, and in fact that they be identical.

This eliminates one of the ?? on the previous slide, and will make it

easier to translate LATTE4 register descriptions to a form MOOT

can handle.

Have lost some descriptive power, probably not needed here.

Pipeline for Calib Runs

Parameter

FSW source

Binary

LATC CFE

component

source

LATC

output

LATC

reference

LATC CFE

component

source

Addional

processing

as before

LATTE4

full

blob

source

LATC

full

blob

source

LATC CRC

component

source

LATC

output

LATC CRC

component

source

LATC TFE

component

source

LATC

output

LATC TFE

component

source

splitter

translator

Database design

Primary tables to represent Parameters, FSW inputs, and Configs (History table is gone).

Secondary tables to describe classes of parameter files and classes of FSW inputs.

Secondary tables to relate Parameter file instances to FSW input instances; FSW input instances to Configs.

Design is done; still subject to minor tweaks

Primary Tables

FSW File Classes

Conceptual Stages (again)

For details of implementation for services MOOT will provide during the first three stages – configuration creation, transport, and use – see

http://www.slac.stanford.edu/exp/glast/ground/notes/moot/ConfigSteps.shtml

Or see the excerpt in the next slide, probably more than you wanted to know.

MOOT has a lot to do with building a configuration but is only a very minor player in transport and use.

Support for the fourth stage – data analysis – flows from the database design.

It contains the information needed to relate the logical ids in the data stream to

parameter files.

For each LATC file created {

// If it's a duplicate just retrieve relevant information, otherwise

// have to make a bunch of entries in MOOD and invoke FSW services

// when the print gets small and ugly like this you can probably skip it

// calculate a checksum this will help when looking for duplicates

search Parameters table for match of Parameter_class value and checksum value;

If (find any) {

bool match=false;

for each found entry {

retrieve file corresponding to the db entry, do diff against our file

if match {

handleMatch(... ); // gets and saves information about existing entry

match=true;

break;

}

}

}

if (!match) {

makeNew(.. ); // makes a dbs entries, creates binary, does fmx add

}

Make entry in Config_FSW table so we know which files belong to this config;

// At this point, have key for this file in MOOD Parameters table,

// MOOD FSW_input table, and have FMX logical_id

}

Status

Non-MOOT preprocessing (Byron's translator, Jim's splitter) is well in hand or done.

Database design is done; will continue to tweak.

Detailed design and implementation of MOOT services underway.

Hope to have enough code written in a week or two to go through some of the motions.

Input Needed

Confirmation that the path outlined is adequate to satisfy requirements and in tune with reality. If there is a high-level flaw, I need to know it now. Changes in details are not a problem.

Communication: need to be kept in the loop about changes made to anything MOOT touches.

Analog of fmx upload, fmx commit for uploads to RAM.

Guidance on preferred environment for building code.

2005-10-10T12:11:56