Mercury Architecture

Mercury Architecture Description - Version 1.1.2 Mercury Architecture Description - Version 1.1
by the Mercury Design Team

1. Introduction
2. Architecture
3. Implementation
4. Connecting to Mercury
5. Release Information
6. Future Work

1. Introduction
The 1.1 version of the Mercury system is actually the third generation of the Mercury system, but the first to be released as open source to the community. Originally, Mercury began as a satellite operations system but quickly evolved into a ground station system since the ground stations could not support our concepts of operations, basically operating satellite as if they were nodes on the Internet.
Mercury 1.1 provides the following capabilities:

Computer based command and control low level ground station hardware. Interfaces currently include external HTTP interfaces and internal TCP connections to Mercury message servers.
Web-based scheduling of satellite contact sessions.
Automated session execution of antenna tracking and radio tuning via open-loop position calculations.
Archiving of all ground station telemetry and satellite data during a session in a standardized XML format.

2. Archictecture
The Mercury architecture is extended from the classic three-tiered Internet web architecture: a web server front-end, application logic captured in middleware, and a back-end database. We've extended this architecture to include a suite of back-end contrl software for managing satellite contact session.
The heart of Mercury is the web frontend software, the database, and the ground station manager (GSM). The web frontend provides a basic, complete command and control interface to all ground station services. This interface will be extended in the future to also enable remote software agent command and control to facilitate station automation. Through the web interface, you are able to configure the ground station, control hardware, and schedule ground station resources. The database provides robust, stable storage for all this information. The GSM is an independent application polls the database for active sessions and spawns the software to enable session execution. Figure and table 1 provide an architectural diagram and component description. Mercury components.

Figure 1 -- An architectural diagram of the Mercury system. Components are described in Table 1.

Table 1 - Mercury 1.1.2 Components

Antenna/Radio/Power Drivers - Convert GSML commands to lower level hardware specific commands (usually sent over an RS-232 serial port). They can also be configured to communicate to a TCP socket.
Data Server - Communicates to the station TNCs (through a serial port usually) and allows outside TCP or SSL connections. Interfaces to the Production Unit to log all data received and transmitted from and to the satellite. Future Mercury versions will enable connetions to different data sources, such as Cisco routers.
Production Unit - Provides a post session summary of a pass. Collects ground station telemetry and logs all data sent to and received from the satellite.
Session Controller - Automates a session by providing automatic tracking of antennas and tuning of radios. It communicates to the drivers via the Session Messages Server. It interfaces to the satellite position predictors calculated azimuth/elevation angles and doppler corrections. It currently provides only open loop control.
Session Message Server - Provides a shared message bus to allow session components to exchange GSML messages.
Predict - Provides calculations for azimuth/elevation antenna pointing angles and doppler shift corrections. Note, we use a patched version that the author hasn't included into the main release. See our Sourceforge site for more information.
Ground Station Manager - Polls the database looking for sessions to execute. Starts up and executes software needed to run the session. This currently includes the antenna driver, the radio driver, the data server, the production unit, the session message server, the session controller, and predict. It's also polls the database for sessions that have been requested to be killed and it then kills them.
Master Message Server - Used by the master group to pass GSML messages. Currently this group consists of the ground station manager and the power driver.
Database - Provides stable store for ground station configuration information, user information, and session scheduling information. The web front end interfaces to it. The ground station manager polls it for active and killed sessions. The production unit publishes it end of session data to it. We currently use MySQL.
HTTP GUI - Provides an HTTP/web front to control the ground station. Pages are encrypted with SSL and valid user/password pairs are needed for entry. We are currently using Apache with PHP.

Each satellite contact session is handled by a separate, independent session group of software. Multiple sessions can be run (limited by hardware constraints) and each session has it own, entire session software. This promotes software isolation and helps prevents transient errors and faults from propogating across session groups.
The ground station is externally accessible via the web front end and via the the data server (DS). The web front end provides encryption through HTTPS ( HTTP over SSL protected sockets) and username/password pairs. The DS is accessible through open, unprotected TCP sockets or through SSL sockets with public key cryptography. TCP or SSL sockets are a configuration option when the session is scheduled. The ground station generates and keeps track of session public/private keys.
Mercury 1.1.2 is centered around human control of GS functionalities. Extensions will be added in future releases to enable agent-based control and scheduling of GS resources.
3. Implementation
Mercury's web front-end is the Apache web server. It was chosen because of its wide use in the Internet world. It is secure, reliable, open-source and runs on a variety of platforms. The database is MySQL. Like Apache, it was chosen because of its wide use in the Internet world. It is secure, reliable, open-source and runs on a variety of platforms. We are considering the use of PostgreSQL because of its crash-only characteristics.
The control software (which includes the drivers, message servers, managers, etc) was all written in Java. We have run these Java apps on Linux and Windows boxes as well as Java-enabled embedded processors such as as the TINI.
Linux was chosen for the operating system for Mercury based on security and reliability constraints. If one desires, all the COTs (commercial off the shelf) software used in Mercury (Apache, MySQL, etc) as well as the Java control program can be run on Windows.
4. Connecting to Mercury
A goal of Mercury is to provide flexible connectivity to GS services from the Internet. This includes both command and control of GS hardware as well as satellite data services.
Currently, Mercury supports two methods of controlling GS resources: an HTTP-based graphical user interface (GUI), and a TCP-based session message server. The HTTP GUI uses PHP scripts embedded in Apache served web pages to configure the ground station, manage persistent data (such as satellite keplerian elements and frequencies), and command and control resources during satellite contact sessions. Connections can also be made into the TCP-based session message server where GSML messages are passed. These servers are not usually open to the public network for obvious security reasons but can be accessed on local are networks in ground station protected by firewalls. Future Mercury versions with have SSL enabled message servers to provide secure remote access. This will allow custom GUIs to be developed as well as software-agent based control.
The Mercury system is currently designed to work with OSCAR (orbiting satellite carrying amateur radio) satellites, and thus for using in OSCAR-class ground stations. The typical data services for OSCAR stations center around the terminal node controller (TNC). TNC's provide moduluation/demodulation, HDLC framing, as well as AX.25 packetization. Some can be placed in KISS mode, which forwards all AX.25 packets, wrapped in a KISS packet, to a processing CPU. Mercury is designed to work with these types of TNCs. The data server essentially provides a TCP (plain or SSL protected) socket connection to the TNC. It's converts an RS-232 port to a TCP socket.
This method works well when using the TNC's non Kiss interfaces. When using the TNC in KISS mode, the software that handles the AX.25 packets is traditionally designed to talk only to the serial port. For instance, the Linux kernel has wonderful modules and drivers for talking to KISS TNC's. (The Linux kernel also allows you to run IP over AX.25. Very nice. We can telnet, ftp, etc into QuakeSat this way.) However, they only speak to the serial port. They are designed to use the Internet. So, we have to be creative because Mercury exports the TNC interface as a TCP socket.
With a couple of serial ports and a second data server, you can use serial port software with Mercury. We have done this successfully with the Linux KISS drivers mentioned above as well as the Pacsat software, WISP. In the ground station, Mercury maps a serial port to a TCP socket with a data server. On the ops end, we use a data server (connected on one end to the Mercury data server and on the other to a serial port) to unmap the TCP data to the serial port. Then, we connect a null modem cable from this serial port to a second. Finally, we connect our serial-only software to this second port. The data is then relayed through the two serial ports to the local data server and on to the Mercury system. A bit of a hack, but it works quite well, especially considering we didn't have to modify the orginal software source code. (Note, a similar trick can be done with virtual machines and their serial port configurations.)
We've also run Mercury with a Cisco router installed with ground station modems. The router has a sychronous serial port interface that is compatable with most modems. In this case the data server is not used. Currently, Mercury does not have extensions for supporting configuration of the router, but since it is networked, it can be reached externally by the satellite operations team if needed.
5. Release Information
Mercury 1.1.x releases are described below:

1.1.1 - Initial Mercury release. Provides basic virtual hardware level control with session level control through the HTTP GUI. Unfortunately, quite buggy.
1.1.2 - Second release of Mercury with substantial bugs fixes. This version, as of 22 Aug 2003, is supporting full time operations for the QuakeSat mission.

6. Future Work
Much remains to do on Mercury. Some is bug fixing. Some is feature addition, such as making the HTTP GUI more user friendly. Some is fundamental to the way space systems are operated. Mercury is part of a university research effort where we are attempting to reduce the cost and improve space system capabilities. This list is by no means exhaustive. Other improvements are listed and can be requested here.

Future Mercury versions with have SSL enabled message servers to provide secure remote access. This will allow custom GUIs to be developed as well as software-agent based control.
Suite of software agents to monitor performance and update time critical information such as keplerian elements.
Integrate Mercury systems into the MGSN to enable a global sharing of ground station resources.
Add ROC techniques to automate failure detection and recovery.
Our ultimate goal is flexible application level support. Mercury will enable control of basic, fundamental ground station services such as antenna pointing and session scheduling. It will also have a standardized mechanism for running flexible application level software. We will be using virtual machines, with a standardized protocol for running them, that will encapsulate all application level services that an operations team could dream of. Thus the GS will not have explicit knowledge of what they are, but will still be able to run them.