Thoughts from meeting of 14 July          

0. Definitions

(First guess only. These will be refined as I understand the project better.)

Mode of operation

Highest-level description of overall LAT state or related sequence of states; e.g. 'muon data acquisition' or 'calorimeter charge injection calibration'.

NOTE: If it is determined that this use of the term mode of operation is consistent with Flight Software use, I'll keep it. Otherwise, some other phrase will have to be found.

Task

A mode of operation comprises one or more task, occurring in parallel or in sequence (or some of each). Tasks are largely self-contained, but can have some impact on each other. The same task, perhaps differently parametrized, may be a constituent of more than one mode of operation.

NOTE: 'Task' will probably have to be replaced with some other term because of confusion with the VXworks task. Maybe 'delegate'?

1. Goals and requirements

Provide robust, reproducible method to configure (broadly interpreted) the LAT for any supported mode of operation.

Aim for ease of use eventually; protecting against error is crucial from the start.

Should be possible to retrieve configuration—to begin with, retrieve at least intent—in effect during a specified time.

Would like to be able to verify that configuration in place matches intent.

Need some degree of portability (exactly what needs to be portable and for whom—for what target environment, for what use—TBD).

Use of cpu and other resources needs to be kept within reasonable bounds for adequate response times, etc.

Both to optimize performance/resource usage and to maintain a high-level understanding of the state of the instrument and how it evolves over time, this application must make use of the concept of a delta between modes of operation. See related remarks in 3. below

2. Clients

Some have a shorter fuse than others.

3. Expected characteristics of the solution

In order to generate a configuration, user will specify a smallish set of parameters (a single parameter in this sense might be a pointer to a collection of values, such as thresholds) which characterize intent for each task to be configured for the desired mode of operation. Compile generates output suitable for download, taking into account interactions among the activities. One possible response is "can't do this".

"Nearby" modes of operations should differ by limited changes to the task parameters. Where technically feasible, the configuration generator should be able to generate a much-reduced object corresponding to those commands, settings, etc. necessary to get from one operating mode to another nearby mode.

Use existing facilities (or near relations) which address substantial pieces of the requirements when possible and appropriate.

For reproducibility, need version tags for critical code components, to be logged along with activity intent parameters. Persistent data must be backed up and have suitable access protection.

4. Initial steps towards a design

Educate myself by

• talking with various experts
• reading documentation
• looking at existing software, databases, etc.
• talking with representative clients

in order to better understand requirements and what now exists to help meet them.

This education will be an ongoing, iterative process, but I expect to be doing very little else for at least a week, perhaps two. As time goes on, I'll spend more time refining requirements and working on a design.

J. Bogart
Original draft: 14 July 2005
Last revised: Monday, 18-Jul-2005 22:40:39 PDT

Further discussion will take place in the ISOC LATconfig Confluence space.