Monitor and Control Software

Green Bank Software Development DivisionMark Whitehead

GBTGeneral GBT Design Goals (1993-2000)- 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

GBTGeneral GBT Design Goal Results (2011)- 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.”

GBTGBT Software DesignThe general GBT design goals influenced the monitor and control software design principles. The key principles are:

- Systems implemented as autonomous units, coordinated by time.

- Object-oriented development

- Code re-use where possible

- Consistent metaphor for devices

- Consistent device state machine

GBTYgor: GBT Monitor and Control

What is Ygor?

- Software is intangible, so we often create names for it.

- Ygor is the name selected for the generic portion of the GBT monitor and control software. The GBT control system is built using Ygor.

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.

GBTYgor: Core Libraries

Core Libraries Ygor 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

GBTYgor: Coordinators and ManagersRecall 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 controlled and 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.

GBTYgor: Coordinators and Managers

Scan Coordinator

Antenna Coordinator

LO1 Manager

Spectrometer Manager

Antenna Manager

Active Surface Manager

GBTYgor: 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.

GBTYgor: 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.

GBTYgor: Manager Details - ScansUpon 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

GBTYgor: Manager Details - Scans

State Action

Off Manager is dormant/inactive.

Standby Similar to Off, but Manager monitors device (e.g. receiver temperatures).

Ready Manager/device is ready for configuration and use.

Activating Scan is being initiated but has not started – can be re-initiated/restarted. Device settings updated.

Committed Scan is about to start - can no longer be re-started.

Running Scan is in progress.

Stopping Scan is ending normally.

Aborting Scan is ending abnormally. Terminated by Manager/device or user.

GBTYgor: Manager Details – Device OptionsConfigurable 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.

GBTYgor: 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.

GBTYgor: 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.

GBTYgor: 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.

GBTYgor: Monitor System

GBT

18

Ygor: Manager Details

GBTYgor: 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

GBTYgor: Monitor System

GBTYgor: FITS SystemAll system data are written to FITS files.

The Ygor FITS library, FitsIO, encapsulates the CFITSIO library.

See http://heasarc.gsfc.nasa.gov/fitsio/ 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

22

Questions?