1. EVLA Monitor & Control Bill Sahr NSF Review May 11 - 12, 2006
The presentation in total consists of one main presentation plus two embedded presentations. The names of the three presentations are:
WJS_NSF_2006May.ppt (the main presentation)
WJS_EVLA_DataFlow3.ppt (embedded, 1 page, portrait orientation)
WJS_EVLA_Components.ppt (embedded, 2 pages, portrait orientation)
Bill Sahr
NSF Review
May , 2006

2. Contents Transition System & Final System EVLA M&C Components
Carryover from Transition System to Final System
Architecture & Data Flows – Transition & Final System
Selected Subsystems
The Alert Subsystem
Correlator Backend, Fast Formatter, TelCal, Post-Processing
User Interfaces – Screen Shots
Bill Sahr
NSF Review
May , 2006

3. EVLA Data Flow - Overview
Bill Sahr
NSF Review
May , 2006

4. Transition System vs. Final System
In broad terms, there will be two major versions of the EVLA Monitor & Control System – a Transition System and a Final System
The Transition System bridges the gap between the old Modcomp-based VLA Control System and the final version of the EVLA Monitor & Control System, while maintaining operational capabilities
The Transition System will be responsible for controlling a wide array of old and new hardware – EVLA Antennas, VLA Antennas, the VLA Correlator, and the prototype WIDAR correlator
The Transition System will incrementally shift its software architecture toward the desired architecture of the final system
Bill Sahr
NSF Review
May , 2006

5. Selected Transition System Milestones
Support for EVLA antenna hardware development
Use of EVLA Antennas in scientific observations
Monitor and control of EVLA antennas
Retirement of the Modcomp-based VLA control system
Monitor and control of VLA antennas
Monitor and control of VLA correlator
Distribution of VLA correlator output
Formation & writing of VLA format archive records
Support WIDAR prototype correlator
Implement target architecture of final system
Support for EVLA antenna hardware development (done)
Use of EVLA Antennas in scientific observations (nearly done)
Monitor and control of EVLA antennas (done)
& other tasks such as Operations Software, UIs, etc
Retirement of the Modcomp-based VLA control system
Monitor and control of VLA antennas (nearly done)
Monitor and control of VLA correlator (new correlator controller online, under control of Modcomps “soon”)
Distribution of VLA correlator output
Formation & writing of VLA format archive records
Support WIDAR prototype correlator
Implement target architecture of final system
Bill Sahr
NSF Review
May , 2006

6. Current State of the Transition System

7. Transition vs. Final System Components & Carryover
Items in blue:
Either transfer directly from the transition system to the final system, such as the software in the EVLA antennas
Or provide a degree of carryover such as
The design of the Interim Observation Executor providing a lot of lessons learned and the basis of a design for the final version of the Observation Executor, or
The interface to the prototype correlator serving as a testbed for the interface to the full correlator
Items in red – transition elements that will not be used in the final system
Items in green – items in the final system that either have no counterpart in the transition system or that will be radically different from the corresponding transition system elements
Bill Sahr
NSF Review
May , 2006

8. EVLA M&C Transition System Data Flows & Status
This diagram shows the basic data flows in the transition system. Might want to point out:
EVLA antennas are represented as a collection of MIBs while the CMP presents a collection of VLA virtual antennas. Within the CMP, IP aliases is used to provide a separate IP address for each virtual VLA antenna, and multithreading is used to provide a separate MIB-style interface for each virtual antenna.
Alerts & a monitor data archive stream emitted by EVLA & VLA antennas as multicasts of UDP datagrams containing XML messages.
Commands come to the antennas us UDP datagrams, unicast
Currently no real-time monitor data stream (the ostream). The code is in place but it has a not yet been enable because no one is using it yet. Round trip phase & total power will change that situation.
There is an alert server, but currently it’s only client is Array Operator Screen. The flagging task gets its alerts directly from the alert multicast group used by the antennas.
Flagging – currently sends flagging info to the Modcomps. Later, will either forward this info to DCAF, or will actually be absorbed by DCAF.
The New VLA Correlator Controller is given as “nearly done”, but carries a completion date of Q This apparent discrepancy is due to the fact that while it is nearly ready to move into the operational state, it will, at first, be controlled by the Modcomps, coming under control of the EVLA Monitor & Control System at a later date.
The Q shown at the output to the Array Processor associated with the new correlator controller is a reference to the “visibility pipe”, i.e., the distribution of visibility data within the EVLA M&C System.

9. EVLA M&C Final System Data Flows
The architecture and data flows for the final version of the EVLA M&C system.
Possible points of note:
First & foremost, note the presence of the antenna “servers” and correlator “server” (objects). The antenna servers will send low-level commands to the antennas & receive a real-time monitor data stream from the antennas. The antenna servers will, therefore, know both the commanded state and the actual state, putting them in a position to act to rectify deviation from the commanded state. The antenna servers will also receive alerts, directly from the antennas, which puts them in a position to do fault analysis and other sorts of processing of the alerts.
Areas to watch:
The network between the correlator baseline boards and the CBE, including the strategy for swapping in new nodes to replace failed CBE nodes
The relationship between the CBE and the Fast formatter
The relationship between the fast formatter & TelCal (real-time)
The relationship between the fast formatter and the near real-time post processing elements IF it is discovered that getting the data from the archive is too slow.
The near real-time elements are:
The Quick Look Pipeline
The Observation Status Screen
The Default Image Archive Image Pipeline

10. The Alert Subsystem Bryan Butler & Rich Moeser
Block diagram of the Alert subsystem:
MIBs, CMIBs and VLA antenna devices (blue and purple)
Intermediate Servers – Antenna, Correlator, Auxiliary Device, and CMP (green)
The Alert Description Database (gray)
Alert Server (red)
Checker Clients (orange)
Flagger Clients (cyan)
Logger Clients (pink)
The Alert Log (brown)
Subsystem Components
There are six main components of the Alert subsystem:
MIBs and VLA devices. The devices themselves, where the lowest level Alerts are generated.
Intermediate Servers. These intercept the low level Alerts, perform any fault tree analysis, combine Alerts with information in the Alert Description Databases, and broadcast the resultant Alerts (many will be passed directly through after combination with the database information).
Alert Server. This accepts the Alerts from the Intermediate Servers, and communicates them to the clients.
Alert Description Database. These contain descriptions associated with each Alert, any action necessary when activated, and flagging information.
Alert Log. This is the persistent log (database) of Alerts.
Clients. These are processes that wish to receive the communicated Alerts. There are three main types of these:
Checker clients – clients interested only in displaying information about Alerts;
Flagger clients – clients interested in the flagging information carried along with the Alerts;
Logger clients – clients used to log results.
In principle any type of client can ask for and receive the Alerts, and in addition some clients may combine some of the functionality listed separately above. We list the three main types here only to expose our thinking on the early implementation.
Bryan Butler & Rich Moeser

11. EVLA M&C Final System Data Flows Areas to watch:
The network between the correlator baseline boards and the CBE, including the strategy for swapping in new nodes to replace failed CBE nodes
The relationship between the CBE and the Fast formatter
The relationship between the fast formatter & TelCal (real-time)
The relationship between the fast formatter and the near real-time post processing elements IF it is discovered that getting the data from the archive is too slow.
The near real-time elements are:
The Quick Look Pipeline
The Observation Status Screen
The Default Image Archive Image Pipeline

12. Fast Formatter, TelCal, Post-Processing Worst Case Scenario

13. EVLA M&C, Deployment
Don’t forget to mention mctest & mc2host, used as an integration testbed, are a response to a point made in the 2004 EVAC Report

14. Screenshot of the Array Operators Screen
- Has been in daily use for over a year

15. A module subsystem screen – the ACU Screen

16. Screenshot of the Device Browser
- URL for software releases: