<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Kevin Ryan wrote:
<blockquote cite="mid:D82ED838-4DE7-4399-BEF5-2FC90B0FB58B@aoc.nrao.edu"
type="cite">
<pre wrap="">On Sep 30, 2009, at 11:42 AM, Barry Clark wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Suggested system design
...
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.
</pre>
</blockquote>
<pre wrap=""><!---->
I'm hoping this is meant just for simple things like logging/archiving
and not as a basis of acquiring system state for control/monitor
purposes.
The MCCC should provide an operator user interface for the functional
operation of the correlator in a manner similar to that provided by
CPCC for the correlator's physical control/monitor (power,
temperature, smoke alarms, power plant ...).
WIDAR has a nice package of REST/HTTP communication classes that are
mature and tested and that can easily be used by EVLA components for
WIDAR interface purposes and everyone is certainly welcome to use them.
</pre>
</blockquote>
Kevin,<br>
it was agreed long ago, and clearly stated at various meetings and in
the VCI Protocol Specification, that VCI is a machine-to-machine
interface, and <i>not</i> user interface (i.e. human to machine
interface). <br>
<br>
It was always understood that WIDAR team will provide messaging
interface and that it is up to the EVLA Monitor & Control team to
integrate correlator M&C in the system. <br>
<br>
You have done great work in providing "engineering" view of the
correlator, in CPCC GUI and system GUI. <br>
<br>
I always assumed that the visual representation of what is used by
which subarray (or scan) will be provided by a tool that provides
integrated view of the system (antennas, correlator and CBE). The same
applies for the alarm monitor. It would be absurd to have two or three
alarm monitors, one for each subsystem (antennas, correlator, CBE...).
All the alarms should be displayed and handled by one tool. <br>
<br>
The status of the correlator will be obtained via VCI (i.e. from MCCC
/ VCI Configuration Mapper) using VCI messages (XML over HTTP or any
other protocol stack selected by the NRAO team). <br>
<br>
<blockquote cite="mid:D82ED838-4DE7-4399-BEF5-2FC90B0FB58B@aoc.nrao.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
The information where to send Delay Models will be obtained from the
VCI Configuration Mapper (either via Resource Manager or directly). VCI
Configuration Mapper has information which Station Board belongs to
which "station" or "antenna".<br>
<br>
Sonja <br>
<blockquote cite="mid:D82ED838-4DE7-4399-BEF5-2FC90B0FB58B@aoc.nrao.edu"
type="cite">
<pre wrap=""><!---->
Currently the CPCC is doing this but it really should be relieved of
this duty by MCCC at some convenient point in time.
Kevin
_______________________________________________
evla-sw-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:evla-sw-discuss@listmgr.cv.nrao.edu">evla-sw-discuss@listmgr.cv.nrao.edu</a>
<a class="moz-txt-link-freetext" href="http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss">http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>