Monitor and Control Software Green Bank Software Development Division Mark Whitehead

GBT General GBT Design Goals - Provide high sensitivity, low-noise observing platform - Allow for expansion and upgrades - Minimize interdependencies - Allow expert users to manipulate and use every capability of the hardware, allow novice users to think about astronomy, rather than device settings - Create a laboratory of instruments, rather than a monolithic telescope - The key design element: VERSATILITY

GBT General GBT Design Goal Results - GBT monitor and control software has been used with the 140 foot telescope, the Green Bank Interferometer, the 85 meter telescope and the GBT. - “Part of the scientific strength of the GBT is its flexibility and ease of use, allowing for rapid response to new scientific ideas…” - “The GBT is also readily reconfigured with new and experimental hardware, adopting the best technology for any scientific pursuit.” - “The GBT was designed to readily allow upgrades and changes to all aspects of its hardware and software.”

GBT 4 How to address versatility? Modularity

GBT Ygor: GBT Software Design The general GBT design goals influenced the monitor and control software design principles. The key principles are: - System composed of autonomous units, coordinated by time. - Object-oriented development - Code re-use where possible - Consistent device state machine

GBT Ygor: GBT Monitor and Control What is Ygor? - Ygor is the name selected for the generic portion of the GBT monitor and control software. What does Ygor do? - Ygor monitors and controls the many pieces of hardware that make up the GBT. - Ygor provides monitoring for logging purposes. - Ygor provides an alarm and messaging system for unexpected failures. Why the name Ygor? - Ygor is based on the icon of a faithful (but not too bright) laboratory assistant.

GBT 7 Ygor: What does it do? Control Monitor Alerts Data

GBT Ygor: Core Libraries Core LibrariesYgor Path Coordinators and Managers../ygor/libraries/Control Communication Support../ygor/libraries/RPC++ Monitor System../ygor/libraries/Monitor../ygor/libraries/Sampler../ygor/monitor Message System../ygor/libraries/Message FITS System../ygor/libraries/FitsIO

GBT Ygor: Manager Details There is a one-to-one correspondence between an Ygor Manager and a piece of hardware. Managers encapsulate two main functions: - Managers contain the mechanism to sequence a scan based on the basis of clock time. - Managers receive and compute options to configure the device.

GBT 10 Ygor: Managers Manager Instance Manager Instance Hardware (e.g. RX) Hardware (e.g. RX) Application Manager Base Class Manager Base Class The Control library provides base classes used to construct Coordinators and Managers. There is a one-to-one correspondence between an Ygor Manager and a piece of hardware. Managers encapsulate two main functions: - Managers contain the mechanism to sequence a scan based on the basis of clock time. - Managers receive and compute options to configure the device.

GBT Ygor: Coordinators and Managers Scan Coordinator Antenna Coordinator LO1 Manager Spectrometer Manager Antenna Manager Active Surface Manager For a telescope to perform an observation, the various autonomous units must be coordinated. A Coordinator is responsible for the synchronization and operation of Managers or other Coordinators. These base classes allow us to arrange a control hierarchy of Coordinators and Managers.

GBT Ygor: Coordinators and Managers Recall a general design goal: systems should be implemented as autonomous units, coordinated by time. For a telescope to perform an observation, the various autonomous units must be coordinated. The Control library provides base classes used to construct Coordinators and Managers. A Coordinator is responsible for the synchronization and operation of Managers or other Coordinators. A Manager is responsible for receiving device options and using the options to configure/control hardware. These base classes allow us to arrange a control hierarchy of Coordinators and Managers.

GBT Ygor: Coordinator Details A daemon (process) called the ScanCoordinator resides at the top of the control hierarchy. When a user starts a scan, the ScanCoordinator uses a three phased approach to coordinate it’s children. First, a signal is issued to all systems requesting a start-time estimate. Second, when all the children have reported back, the ScanCoordinator issues the activate/arm command to command the children to start at the agreed upon time. Finally, each child then performs it’s function, relative to the start time. For example, the antenna follows a precise trajectory or a backend starts integrating. Where high synchronization rates are needed (e.g. switching signals) hardware signals are used.

GBT Ygor: Manager Details - Scans Upon receiving an activate command from a parent, managers connected directly to hardware automatically sequence themselves through a state machine. Each manager derives from a Manager base class that contains the state machine. Standby Ready Stopping Running Activating Committed Aborting Off

GBT Ygor: Manager Details - Scans StateAction OffManager is dormant/inactive. StandbySimilar to Off, but Manager monitors device (e.g. receiver temperatures). ReadyManager/device is ready for configuration and use. ActivatingScan is being initiated but has not started – can be re-initiated/restarted. Device settings updated. CommittedScan is about to start - can no longer be re-started. RunningScan is in progress. StoppingScan is ending normally. AbortingScan is ending abnormally. Terminated by Manager/device or user.

GBT Ygor: Manager Details – Device Options Configurable device options are represented using a Parameter class. The Ygor framework defines 16 base Parameters for scan coordination (all are known to the Manager base class). Programmers add additional Parameter classes to represent device-specific settings. Parameters contain arbitrary C++ data; Parameters add validation and can express dependencies. Example: - Consider three inputs – m, x and b. - Each input would be a Parameter. A fourth Parameter, y, depends upon the other three inputs to represent the expression y = m*x + b. - If m, x or b change then the system automatically re-computes y.

GBT Ygor: Communications Support The Communications library was built using Open Network Computing Remote Procedure Calls (ONC-RPC). ONC-RPC uses ‘eXternal Data Representation’ (XDR) to encode data. XDR allows binary communication with heterogeneous computing architectures. Very fast, low-latency, maintains data-integrity, automatic recovery on network errors. Eliminates inter-system dependencies and alleviates the need to restart processes due to inter-dependence.

GBT Ygor: Communications Support Recall that: (1) “Managers receive and compute options to configure the device.” and (2) Options are expressed via Parameter classes. Programmers create Data Description libraries (DDL) which express Parameter and ancillary type information (e.g. a Parameter’s units, precision or accuracy). There is a one-to-one correspondence between a Manager or Coordinator and it’s Data Description Library. The Communications library uses the Data Description Libraries to encode/decode data and transmit/receive data between communication end- points (e.g. device managers and user-interfaces). Analogy: The DDL is a cookbook of recipes. The Communications library looks up in the DDL an ID (cookbook page number) and type information (a recipe) to encode/decode data for transmitting over the wire.

GBT Ygor: Monitor System Just as the Parameter class is used to set hardware options, a Sampler class is used to read hardware options. In addition to expressing Parameter type information, Data Descriptor libraries are used to express Sampler type information. Processes use the Sampler library to place data into a ring-buffer. Processes use the Monitor library to receive sampled data from other systems. Two support programs, the Transporter and the Accessor, allow for monitoring across a distributed system. The Transporter makes Sampler data available to the Accessor. The Accessor multiplexes data to user-interfaces or other applications.

GBT Ygor: Monitor System

GBT 21 Ygor: Manager Details

GBT Ygor: Message System A message system is used to provide alarm or information events to users or operators. The Message library includes a Message class which encapsulates state (asserted or not asserted). Messages express event severity (e.g. Notice, Warning, Error, etc.). Messages have printf-like capability: message.check(x>0, “The value of x is %f”, x); A support program, the Message Multiplexor, is used to manage all system messages. Specifically, the Message Multiplexor: - Receives all messages - Publishes messages to user interfaces - Logs message events for archival - Clears messages when a device is turned off or restarted

GBT Ygor-based Monitor System

GBT 24 Ygor gives us FITS VEGAS Antenna LO FITS sdfits SDFITS Pipeline

GBT Ygor: FITS System All system data are written to FITS files. The Ygor FITS library, FitsIO, encapsulates the CFITSIO library. See for details about CFITSIO. The library provides an interface: - for manipulating data tables - for writing custom device data - for accessing a wide variety methods associated with scan information (e.g. start time, scan ID, etc.) and spectrometer information (e.g. blanking, switching signals, etc.)

GBT 26 ASTRID: Astronomer’s Integrated Desktop

GBT 27 CLEO: Control Library for Engineers and Operators

GBT 28 Beamforming Instrument Integration 1 Straw man proposal: recommend minimal integration for the beamforming backend on initial GBT tests. - Deriving from Manager Base class and implementing control and monitor logic with parameters and samplers in C++ is straight-forward. Graduate students would not need much guidance to accomplish this. - Get the manager state machine and start-of-scan signals for free. - Get ASTRID configuration and observation scripts for free. - We have experience with a similar architecture (VEGAS) and may be able to reuse code. - We took this approach with FLAG and it worked well. - If there is a long term path for the instrument on the GBT, all the infrastructure will be in place so making it a user instrument could be easier.

GBT 29 Beamforming Instrument Integration 2 Antenna Front End DC & D Back End M&C DF Data Questions for discussion: Assume we’ll re-use and modify RcvrArray1_2? Does the down converter/digitizer need a manager? WVU – manager development? WVU – HI pipeline development? BYU – core beamformer firmware? ??? – pulsar search software? What is the firmware architecture for the modes (spectral, pulsar, calibration)? Similar to VEGAS?

GBT 30 Questions?