Introduction

Purpose

This document provides an architectural overview of the of the software system for the DCT RC Guider and Wavefront Sensor System (GWAVES). It is intended to capture and convey the significant architectural decisions which have been made on the system.

Scope

The DCT RC Guider and Wavefront Sensor System (GWAVES) is being developed by the Lowell Instrument Group. This document will cover the software system responsible for operating GWAVES but will not cover the interface to the TCS or AOS. The interface to external systems such as TCS and AOS will be covered in Internal Interface Control Document.

Definitions, Acronyms and Abbreviations

This section gathers together some of the relevant definitions and abbreviations used in this document

Reference

GWAVES Catalog Server (http://jumar.lowell.edu/confluence/display/GWAVES/GWAVES+Catalog+Server]
GWAVES Requirements Document (http://jumar.lowell.edu/confluence/display/GWAVES/GWAVES+Requirements+Document)
Internal Interface Control Document (http://jumar.lowell.edu/confluence/display/GWAVES/Internal+Interface+Control+Document)
LOIS Commands (http://jumar.lowell.edu/confluence/display/GWAVES/LOIS+Commands)
DCT-0360S-009 GCS/WFS Requirements Document

Architectural Representation

This document presents a coarse view of the architecture for the GWAVES software system as a group of modules working together. We will also present a brief description of some of the underlying frameworks and libraries used and the reasons for choosing each one.

Architectural Goals and Constraints

There are some requirements and system constraints that can have a significant bearing on the architecture. They are:

1. The existing hardware control system (LOIS) will be part of the over all system.
2. System must be modular and provide the basis for the future instrument control systems.
3. LOIS communication should offer the possibility of some remote operations in the future.
4. GWAVES will ultimately have to interface with the DCT telescope control system (TCS) and DCT active optics system (AOS).
5. All performance and loading requirements, as stipulated in the DCT system design documents ? must be taken into consideration.

Frameworks and Libraries

GWAVES Control Software (GWAVES) is basically a client server application with an intelligent controller for routing messages. The communication between the clients and the servers is done through a message broker. GWAVES uses several frameworks and libraries which were chosen for robustness and ease of development process.

Java Message Service (JMS)

Using a message broker as the means of communication between different layers of the software allows distributed communication that is loosely coupled, reliable, and can be either synchronous or asynchronous. For GWAVES we have chosen publish/subscribe model within JMS as our messaging protocol. There are multiple JMS providers both open source and proprietary and we have chosen Apache ActiveMQ. It is important to note that it is rather easy to switch our implementation fro ActiveMQ to another JMS provider since we code against the interface and not the implementation.

Rich Client Platform (RCP)

Providing a rich and flexible user interface generally means the use of a standard framework such as wxWidgets, Qt, or XUL. The Eclipse Foundation's RCP was chosen as the GUI framework due to its portability, stability, and high quality development tools. RCP is a java framework which provides a consistent and native look and feel across applications and operating systems.

The RCP framework also provides a standardized component model (Equinox), In other words, RCP applications are composed of components that plug into the platform. This component model allows very modular design which creates a powerful foundation for control software for other instruments which will be built by LIG.

XML serialization/de-serialization

GWAVES leverages XML as its message transport protocol across the different software layers. Two specific implementations are used:

• Simple within the Java layer
• gSOAP within the C/C++ layer

Logical View

The logical view of the GWAVES software system is comprised of 4 main modules:

GWAVES Catalog Server (CAT)

CAT is an RCP application responsible for searching and identifying suitable candidates for guide and WFS stars. Current database is a combination of UCAC2 & UCAC3 implemented on MySQL. CAT searches the database around the current science target and will present a areal template for the chosen instrument where the a suitable candidate is accessible. The potential candidates are represented both graphically and textually in a table.

Lowell Observatory User Interface (LOUI)

LOUI an RCP application responsible for presenting the primary camera control interface to the operator. There will be 2 main modules; one for the guider and one for WFS. The applications is composed of multiple views with the primary views being the camera control, TCS Status View, and the imager.
The Shack-Hartmann analysis for WFS will be done externally via existing IDL procedures through an exec or RPC command. The results are displayed and relayed via the WFS module.

Joint Operations Executive (JOE)

JOE is a controller module responsible for intelligent routing of messages. JOE is basically an abstraction layer between the LabVIEW systems and GWAVES.

In addition to the camera controllers, GWAVES includes the hardware for control of:

• fold mirrors for instrument operations
• X & Y Stage of probes
• Focus Stage
• Filter Wheels

The above operations are performed in JOE by relaying the commands to the OMS cards via TCP sockets.

Lowell Observatory Instrumentation System (LOIS)

LOIS is a C/C++/TCL application responsible for direct camera/CCD control. LOIS will also perform the centroid operation on the guide star.

Architecture Overview – Subsystem Layering

Data Flow

Deployment View

Desktop Workstation

A robust workstation with multiple monitors (probably 3) will be used by the operator for main control. This workstation will support the TCS/OCS user interface along with GWAVES screens. Due to the architecture of TCS/OCS (LabVIEW) the workstation will have to run a flavor of MS Windows, probably Windows 7.

JOE/ActiveMQ/Database Server

One linux server can be used to run JOE, the message broker, and the database server. This server will need ~ 8 - 16 GB of RAM, a SSD for the database, and dual power supplies for reliability. A specific server has not been selected yet.

Camera Controllers

Each camera will need one linux box with a PCIx card to accommodate the GEN-III Leach PCI card. We have chosen Dell PowerEdge R200 for this purpose.

Performance

We do not foresee any performance issues regarding the GWAVES software under the current architecture as long as the guide rate remains at ~1 Hz. Much faster guide rates may require some modifications to the architecture. The latency requirements and constraints for the messaging between GWAVES and TCS/AOS are documented in GWAVES Requirements Document.

Appendices

Preliminary list of JMS topics