Last revised:
A MOOT Config can be thought of as a collection of input sources, typically in a text-like format such as xml, and the uploadable binaries produced from them. LATC source and binaries is the standard and motivating example, but other forms of source (lci script, ltc files) can be included and still more are being contemplated. We need to decide
The complexity and idiosyncrasies of the LATC parser and the hardware registers it controls are the chief motivation for MOOT and for the concepts of precincts and votes.
LCI scripts describe register settings and iterables (registers which will take on a sequence of values) to be applied during a charge injection run. MOOT knows how to compile LCI source. That source will be created by a gui in a manner similar to the way LATC source is created.
A LATC Ignore file specifies registers which should not be read back during the verification phase of register loading, typically because they are known not to operate properly during this readback. MOOT can compile a LATC ignore file also. Most likely this file will change only rarely; it might not be worth the effort to build a lot of machinery to create and manage this file.
Parameters for thermal control are specified in XML source files which MOOT can compile. Probably these parameters will change only rarely and will not normally be linked to run type.
Filter configuration source files are compiled into binary form by the Flight Software build system; MOOT will never have any part in this. However, we could invent a procedure whereby the source and binary forms of filter configuration are registered with MOOT so that it would be possible to recover the source from the binary key stored in the data or from a MOOT Config key.
One could imagine some sort of registration linking a binary key to a form of intent description. The only thing that might conceivably be of interest to code wishing to track configuration would be a version string.
Binding all of these configuration types into a single MOOT Config could make some kinds of look-up easier if Science Operations (or someone) keeps a log of which MOOT Config was used for each run. Discovery of the complete configuration would flow from a single MOOT Config key. The disadvantage of this arrangement is the potential for an explosion in the number of MOOT configs. For example, if the LATC ignore file changes, that could affect every type of run. All Configs would have to be regenerated. The only binary to change would be the LATC ignore binary so there would be no extra uploads, but there would be a management burden.
We need to decide where along the spectrum (independence of different forms of configuration versus binding them all together) we want to be, based on requirements of those wishing to query configuration information after the fact (online monitoring, offline processing in Gleam, other forms of offline processing,...) and the likelihood for error or confusion. The needs of those wishing to test some piece of the over-all configuration (e.g., a new lci script) are different from production operations; perhaps a different standard should be applied.
| Created: 18 May 2007 Last revised: |
J. Bogart | |