[evla-sw-discuss] Observation Executor team

[Bill Sahr]

This posting can be taken as the announcement both of the
decision concerning which path we will pursue for the design
of the Observation Executor, and of the formation of a team
to work on further development of the Executor.

We have decided to develop a design for the Executor that
breaks out some portion of what is now referred to as the
AntennaPhysical objects into a separate layer.  Further,
as Barry has pointed out, any design that uses only one
copy of Calc does not scale well, neither w.r.t. the addition
of antennas nor w.r.t obtaining more results from Calc per
unit of time.  Accordingly, the issue of using multiple
instances of Calc will also be explored as a part of this
design effort.

Executor team

Team Members
------------
Bryan Butler (team manager)
Boyd Waters
Rich Moeser
Chunai Cai
John Benson

Team Consultants
----------------
Barry Clark
Ken Sowinski
Bill Sahr


Charge to the team
------------------
The basic charge of the team is to explore, develop, and implement
a design for the Observation Executor that separates out some of the
functionality (implemented and planned) of the current Executor into
a layer separate from the Executor proper.  For convenience, we will
call this new layer the antenna server layer.  Further, the team will
also explore the feasibility and desirability of using multiple instances
of Calc.


Basic Timeline
--------------
Date of team formation: Wed, 3/2/2005

The overall goal is to be using this new version of the Executor as the
standard, operational system element by the time the Modcomps are retired.
The current date for the retirement of the Modcomps is Dec 31, 2005.

Finer-grained milestones will be tied to the phases of the M&C Transition
Plan.  For example, it would be desirable to have an implemented design,
ready for testing, either at the end of Phase II of the M&C Transition
Plan, or near the beginning of Phase III of the M&C Transition Plan.
However, changes in the hardware delivery schedule require that we
reevaluate what constitutes Phase II and III and the dates associated
with each.  The team will be supplied with a more detailed timeline as
soon as the reevaluation of the M&C Transition Plan is complete.

As a rough guideline - from the beginning of March to the end of December
is 10 months.  Probably, a minimum of 3 months should be allowed for
exhaustive testing of a _final_ design and implementation.  Working
backward, one might allocate 3 to 4 months for the determination of
requirements and detailed design, and the remaining 3 to 4 months for
the coding, testing, and refinement of prototypes.  If this schedule
were adopted, the timeline would be:

Mar - Jun 2005:  requirements, detailed design, 1st implementation

Jul - Sep 2005:  iterative testing and development of prototypes

Oct - Dec 2005:  testing, debug of final version


Discussion
----------
Broadly speaking, the Executor and antenna server layer taken together must
accept a control script, translate that control script into commands for
the configuration and conduct of an observation, communicate those
commands to the involved devices, monitor those devices for conformance to
the commands, and correct any discrepancies between commanded and reported
state.  Appropriate alerts, error messages, etc must be generated.

One of the jobs of the team will be the specification of the division of
functionality between the Executor and the antenna server layer.

The design should include provision for the monitor and control of VLA
antennas, EVLA antennas, NMA antennas and VLBA antennas.  Monitor and
control of VLA antennas and EVLA antennas must be worked out in detail,
and implemented.  Monitor and control of NMA antennas and VLBA antennas
must be shown to be a logical possibility, but neither detailed development
nor implementation is required at this time.

The design should include provision for the monitor and control of the VLA
correlator using the new VLA correlator controller, of the prototype WIDAR
correlator, the interim WIDAR correlator, and the final version of the
WIDAR correlator.

The design must benchmark the performance of Calc.  Meaningful metrics for
the performance of Calc must be developed and measured.

Clearer, more detailed statements of the most extreme drivers and
requirements for Executor performance must be obtained from the scientific
staff.  For example, during discussion of the Executor design it was
frequently stated that the most extreme case of on-the-fly mosaicing
(OTFM) requires position and delay updates from Calc at the rate of
3 X 10Hz.  Further discussion raised the issue of supporting OTFM that
uses multiple delay centers per antenna beam as an even more extreme
case.  The team must obtain a specification of _exactly_ what is
_required_ of the Executor and antenna server layer.  Specific use
cases for the most extreme drivers that will be supported are recommended.
Use cases for drivers that exceed the requirements would be useful as
they may serve to set a direction for future development efforts.

The detailed requirements that the Executor must satisfy must be
specified in a written document.

A detailed design document, updated as design and testing proceeds,
is required.

It is important that the consultants be updated on progress on a regular
basis.

A formal review of the requirements and detailed design should probably
be made a part of the development plan, in essence a combined PDR/CDR.