Configs
History
Parameters
Config_structure
Others
|
Main Tables Configs History Parameters |
Helper tables Config_structure Others |
|
This page is of historical interest only. Some of these ideas have been discarded, in particular the kind of information envisioned for Config_structure will not be kept in a table, but probably in a configuration file for MOOT which MOOT will read during its initialization. See this design document for a more accurate idea of MOOD design.
There will be at least four: Configs, History, Parameters, and Config_structure. A row in Configs should contain enough information to retrieve a complete description of the configuration of the LAT. A row in History points to a row in Configs and has fields describing just when the configuration was requested, when it was actually uploaded, etc. A row in Parameters has fields describing how to retrieve details about some piece of the configuration. Config_structure has a row per parameter value for each config in Configs.
| Field name | Explanation, typical contents |
|---|---|
| config_key | Primary key, auto_increment; unique identifier for the row |
| mode | Major mode, one of an enumerated set (data, calibration,..) |
| name | Convenient short name for interactive use |
| notes | Longer description of what the configuration is supposed to do. |
| who | Who asked to create it |
| request_time | Time of start of process to create config |
| creation_time | Time of creation (or of end of attempt) |
| status | E.g., 'OK', 'abort', 'in_progress', ... |
| instrument | Which LAT-like instrument does it refer to? |
Exactly what is involved in creating a configuration in the sense of the creation_time field is TBD, but the final result should include the existence of all FSW files needed to implement the configuration.
This table keeps track of when a load of a particular config from Configs has been requested, when it completes, and when it is no longer the active config (next config has been loaded).
| Field name | Explanation, typical contents |
|---|---|
| history_key | Primary key, auto_increment; unique identifier for the row |
| config_fk | Foreign key, referencing an entry in Configs. |
| request_time | Timestamp for request to load |
| ack_time | Timestamp when notification was received of success or failure of load |
| active_start | Same as ack_time for successfully loaded configurations; else null. |
| active_end | Timestamp when config was overwritten by the next one |
| load_status | One of 'in_progress', 'loaded', 'superseded', 'failed',... |
Parameters are in application space rather than hardware space.
The two differ in several respects:
Fine granularity configuration information is partitioned one way by these parameters and another way by the files managed by FMX. In the short term, it's difficult to imagine a scheme which can bridge arbitrary differences between them. On the other hand, it's unlikely to be the case that parameters map one-to-one to FMX files. The constraints on this relation (between parameters and FMX files) will influence the design of MOOD tables concerned with identifying the collection of FMX files needed to implement a particular requested configuration. In the unrealistically-simple case, where a particular value for a parameter maps 1-to-1 to an FMX file, Parameters would include the following fields (and probably several more):
| Field name | Explanation, typical contents |
|---|---|
| parameter_key | Primary key, auto_increment; unique identifier for the row |
| name | E.g., something like cal_thresholds. Note this is value not unique within the table. Might be that the set of all such names should be kept in its own table, call it Parameter_defn, in which case the name field of Parameters would be replaced by a reference to an entry in Parameter_defn. |
| remarks | Could just be "default" if it's the standard set of values for the parameter; otherwise describe purpose of this set. |
| geo_scope | Does the information cover the entire LAT or are there additional entries with the same kind of information for different parts of the instrument? |
| source | E.g., xml input to Flight Software facility which knows how to convert to binary |
| fmx_id | Unique id assigned by Flight Software to the corresponding binary file. |
| enter_time | When this row was created? |
| instrument | Which LAT-like instrument does it refer to? |
| flavor | Normal value is something like 'default' or 'vanilla'.
Wildcard which can be used to identify a special set of values. Probably should not be allowed to have anything other than the normal value for standard data-taking or calibration configurations. |
Mostly they make connections between main tables or help to define expected form of one thing or another.
Relate a particular config in Configs to all the parameter values associated with it.
| Field name | Explanation, typical contents |
|---|---|
| config_fk | Foreign key, referencing an entry in Configs. |
| param_fk | Foreign key, referencing an entry in Parameters. |
To track down the composition of a particular config, query this table for all rows with config_fk equal to primary key value for that config in Configs.
Likely will want tables Parameter_defn with a row per parameter (not per parameter value), Mode_defn with a row per operating mode, and a table relating the two so that is it possible to look up the parameters associated with a particular mode.
If parameters don't have a one-to-one correspondence with FMX file types, will need an additional table or two to describe the more complex relation. This will probably complicate various procedures, such as the one to add a new row to the Parameters table.
|
Initial draft: 4 Aug 2005 Last revised: |
J. Bogart |