Document work in progress. Last updated: 08 April 2004.

(Work is currently underway on Mercury 1.2. As the design develops, these pages will contain documentation on the system.)

1. Development Progress
2. Architecture Overview
3. Internet Accessibility
4. Implementation

1. Development Progress

Mercury 1.2.0 will have significant enhancements over 1.1.2. The core of the development efforts are to enable MGSN capability and to deploy recovery-oriented computing techniques for high availability.

Planned Upgrades:

1. Enable GSM to register with MGSN servers.
2. Upgrade to SSL
   1. Fix key store management for access servers and data servers.
   2. Use session keys, good for that session only, instead of user keys for accessing session servers.
3. Develop access for session level GSML messages.
   1. SSL protected using user SSL keys.
   2. Enables agent based scheduling.
4. Develop a Java GUI application and/or applet for monitoring GS state during a satellite contact session.
5. Enhance hardware configuration and management
   1. Enable XSLT transforms on GSML to enhance commanding.
   2. Generic hardware DB table instead of custom radio/antennas, etc.
   3. Enable web gui configuration of master session hardware.

Implemented Upgrades:

1. Times are now displayed in UTC.
2. Restructured side menu.
   1. Added a "Process" status page.
3. Added the Process Manager (PM).
   1. Currently it starts and stops processes needed to run passes. The Ground Station Manager (GSM) updates an internal DB with process information.
   2. Performs ping-based failure detection of master session components.
   3. Recovers with restarts.
4. Upgrade GSM to handle session and network level GSML messages.
   1. GSMs to handle session level GSML messages sent through master message server.
5. Added "Process" management page.
   1. Tracks Mercury process and monitors.
   2. Added capability to restart and stop Mercury system from Web gui.
6. Upgraded to SSL:
   1. Dataserver and MessageServer now correctly start SSL server sockets.
   2. MessageServer can do TCP and SSL servers at the same time.

If you're interested in Mercury development, please subscribe and send email to the MGSN development mailing lists. See contact info.

2. Architectural Overview

Mercury is a loosely coupled system of networked software components for providing Internet accessible, mixed-initiative control of ground station installations. It implements the GSML protocol standard for controlling a hiearchical ground station network. Figure 1 is a high level diagram of the Mercury software components. This "master" group of software provides scheduling and process execution capabilities. Session groups of software are spawned to handle individual contact sessions. Detailed component descriptions are below.

Figure 1 -- High level Mercury Architecture -- 1.2.0.

2.1 Master Message Server
Messaging between master group components is through the master message server (MMS). Similar to a networking hub, all messages are broadcast to all clients. Although GSML messages contain a destination field, the current MMS does perform routing functions. The MMS is configurable to enable multiple TCP or SSL listening sockets.

2.2 Database
Stable, durable storage of ground station configuration and scheduling data is held in a database. The process manager stores information about which processes to monitor. The station manager accesses schedules of contact sessions and hardware usage. The web server displays all database information. Currently, we are using MySQL version 4. More detailed information is below.

2.3 Ground Station Manager
The ground station manager (GSM) is the contact session scheduler and executive. GSML session level messages from the access server or web front end are handled by the GSM for scheduling of GS contact sessions. At the scheduled times, the GSM tasks the process manager to spawn contact session software to perform a pass.

2.4 Process Manager
The process manager (PM) performs failure detection and recovery of Mercury components. Currently, all software components. Dedicated hardware monitoring has not yet been added. Our approach to high availability is through recovery-oriented computing.

2.5 Web Server
The web server provides an HTTP front-end for accessing Mercury control systems. Currently, it's designed for human usage and may be extended for agent based protocols such as SOAP. Virtual hardware level commanding and session scheduling is available.

2.6 Access Server
Enables SSL authenticated and encrypted access to Mercury for remote software agents. Other potential interfaces include SOAP or Grid.

2.7 Master Drivers
Group of hardware drivers that are shared across contact sessions, such as power drivers. Master hardware components can be added via the web GUI.

2.8 Session Groups
For each contact session that is run in the ground station, a separate session process group is spawned to handle the pass. Figure 2 shows the processes within a session group and the components are described below.

Figure 2 -- Session group components.

3. Internet Accessibility

4. Implementation