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. Even though this document does not explicitly address the science instrument package, the main concepts apply to all the Lowell built instruments.

Scope

The DCT RC Guider and Wavefront Sensor System (GWAVES) was developed by the Lowell Instrument Group. This document will cover the software system responsible for operating GWAVES but will not cover the details of 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 were some requirements and system constraints that had 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 science instrument control systems.
3. LOIS communication should offer the possibility of some remote operations in the future.
4. GWAVES has 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 from 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. 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 built by LIG.

XML serialization/de-serialization

GWAVES leverages XML as its message transport protocol across the different software layers. We chose the Simple framework for the Java layer. The C/C++ layer in LOIS and the LabVIEW layer both use custom code written in house.

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 includes FK6, Tyco, and UCAC4 implemented on MySQL. CAT searches the database around a point of interest, usually the current science target, and will present an 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. For more information on CAT and its operation please refer to the online documentation on Confluence.

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 applications; one for the guider (GDR) and one for the wave front sensor (WFS). Each application is composed of multiple views with the primary views being the camera control, facility summary, and the imager.
The Shack-Hartmann analysis for WFS will be done externally via existing IDL procedures. The results are displayed and relayed to AOS via the message broker. The WFS LOUI is not directly involved with the analysis.

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 standard 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