[evla-sw-discuss] Software System Design

[Barry Clark]

Suggested system design

1.  Changes to the design will be posted to the evla-sw-discuss
email list.  Since a wide knowlege of the system design among the
group is highly desirable, I also urge posting a general note
of the contents of messages exchanged between program elements
(that is, those not already defined).  The schemata per se make too
difficult reading for general familiarity purposes.

2.  OPT/Scheduler will provide setups in XML according to the VCI
as previously defined.  The schema will be compiled by JAXB.  Setups
will be either separate files, with the file name mentioned in the
Executor script, or will be simply prepended to the script (not
yet decided).

3.  The Executor will be responsible for sending these setups and
their modifications (adding information not known to the PST)
to both the VCI (ConfigurationMapper) and MCAF.

4.  ConfigurationMapper will forward commands to Station Boards,
Baseline Boards, and the CBE.  ConfigurationMapper will assign
NIC addresses, from a list; the mechanism for maintaining the list
is an issue to be decided by discussion between ConfigurationMapper
and CBE.

5.  Executor will provide, via an expansion of the current observation
document, the information necessary for MCAF and CBE to construct
the SDM and BDF respectively.  We should explore whether the current
CBE to MCAF document path can be eliminated.

6.  MCAF will collect information from Executor observation documents,
from the correlator setup documents, from the AlertServer and alerts (in
emulation of current idcaf), and from the Station Boards' calibration
data.  It will in turn send messages to Telcal.

7.  Telcal will operate on a subscan basis, on observations marked as
calibrators.  Antsol solutions will be broadcast as documents (with
the proximate use of operator displays equivalent to the current D10
and F, and for autophasing), and as local files, to facilitate easy
inspection of history.  Pointing solutions will be broadcast as 
documents (for use in reference pointing), and written in local files
for use of the pointing solver routines.

8.  Station boards will implement a timed command to set the
requantizer gain, using data from the last integration.

9.  Station boards will have the integration time on the integrators
for cal on/off set equal to the integration time for records output
from the CBE, preferably synchronous with those integrations.
(This is the desired state for the moment, but is likely to be
implemented through a more general command from the
ConfigurationMapper.)

10.  Station boards will calculate cal_on-cal_off power, and multiply
that by the requantizer gain to make the station board's main
calibration output (one number per subband every integration).

11.  There will be a new entity within the correlator system which will
receive the calibration outputs of the station boards and repackage
them in a form convenient to MCAF, with proper antenna and subband
IDs, etc.  This entity will eventually have to be told by the
ResourceManager how to do this.  Communication protocol between StBs
and this entity is yet to be specified.  Alternately, the station boards
may multicast directly to MCAF, which may be able to figure out what
to do with the information.

12.  Alerts will be multicast in the same fashion as antenna alerts,
for the same purposes.  It may be necessary to have an alert forwarder
within the correlator system to provide translation to understandable
antenna and subband identifications, although Station Boards probably
have enough information to be able to construct an alert.

13.  Delay polynomials will be transmitted from the Executor in the
current fashion, and distributed as now, with the expectation that
eventually the polynomial distributor will need information from the
ResourceManager to know where to send them.

Limitations for initial implementation.

Note that there is no Station Board to CBE data path (other than
the main data path through the Baseline Boards).  I think such a
path is unnecessary even in the long term, but certainly for OSRO
purposes it is not needed.

Although the quick set of requantizer gain is mentioned above,
it is not vital for OSRO, and could be deferred a bit.

I have not called for StBs to calculate mean/meansquare delay
residuals because I think it is acceptable to defer this past the
beginning of OSRO.  Others may differ.

ResourceManager issues are deferred until after initial operations
in March.

Discussion of handing of Tcals is deferred to a time when it becomes
absolutely convenient.

There is no discussion here of an array operator console.  There
will absolutely have to be one.  For this initial implementation
the emphasis should be only on information display; operators should
not be expected to have to issue commands.