Mercury 1.1.2a
CVS Tarball
|
|
|
|
|
Mercury Reference Model -- Version 0.2.0 Mercury Ground Station Reference Model -- Version 0.2.0
by the Mercury Design Team
Introduction
We are in the process of identifying the core services common to typical ground station systems and capturing them in an API called the Ground Station Markup Language (GSML). Providing basic building blocks to ground station users will enable them to compose ground services in ways not foreseen by station builders. We captured these services in a preliminary reference model (version 0.1). Here, we expand this informal reference model by capturing additional state and services associated with core ground station capabilities.Our model is hierarchical and layered according to autonomy level. The virtual hardware level provides control of low-level hardware resources in the ground station. The session level provides single station automation services. The network level captures the services of a ground station network.
Currently, we are focused on university ground stations built for orbiting satellites carrying amateur radio (OSCAR). They are typically LEO satellites with UHF, VHF, or S-band radios with data speeds less than 100Kbps. Packet protocols such as IP, AX.25, or IP over AX.25 are typical. However, nothing about this model prevents it from being used or expanded upon for ground stations with greater capabilities and services.
Virtual Hardware Level
The virtual hardware level (VHL) captures the fundamental capabilities of low-level ground station hardware and enables generic commanding of heterogeneous hardware components. At this level, we abstract away device-specific commanding protocols and present a standard interface to ground station hardware (comparable to device drivers found in computer operating systems). Control of the station at this level is a master/slave paradigm with no autonomy in the GS; all commanding is done from remote, master operators (or their software). Table 1 lists the hardware objects and their externally visible state.The amount of specialized hardware is shrinking as general purpose computing platforms increase in capability. Therefore, we have not explicitly modeled traditional hardware components such as (de)modulators, bit synchronizers, forward error correctors, and cryptographic equipment.
In an effort to simplify the specification of ground station capabilities, we group communication hardware into pipelines. Receive pipelines convert space radio transmissions into digital bits that can be placed on terrestrial networks. Transmit pipelines perform the inverse of this. Transceive pipelines do both. Many ground stations have multiplexing capabilities to allow diverse hardware configurations, such as allowing multiple radios to interface to multiple antennas. Pipeline descriptions allow ground station administrators to specify what hardware combinations are possible for satellite contacts.
Table 1 -- Virtual Hardware Level Object Descriptions
Object State Antenna Azimuth Angle
Elevation Angle
Brake Status
Preamp (LNA) Enabled Status
Gain Level
Radio Transmit Frequency
Transmit Mode
Transmit Output Power
Receive Frequency
Receive Mode
Receive Attenuation
Receive Squelch Level
Receive Signal Strength
Output Amplifier Enabled Status
Output Level
Digital IO Channel State
Number of Channels
Analog IO Channel State
Number of Channels
Power Controller Channel Value
Channel Name
Number of Channels
CPU Network Bytes In
Network Bytes Out
CPU Usage Times
Disk Usage (Free/Total)
Load Averages
Processes Total
Processes Running
Memory Usage (Free/Total)
Status
Uptime
Name
IP Address
Virtual Machine (Includes CPU state from above.)
Type of VM
Ground Station Name
Location
Pipelines
Status
Environment Parameters
(common to all hardware)Temperatures
Voltages
Session Level
The session level (SL) captures typical automation tasks and services of a single ground station installation. Users define a session, which reserves station hardware over a specific interval of time and tasks automation services to maintain communication channels with a target. Session level services employ the virtual hardware level primitives to control lower level ground station resources. Users can bypass these automation services to directly control all or part of station hardware. This enables operators to execute specialized, mission specific control of GS resources.At the heart of this level is the session. It is an object the ground station "executes" on a reserved set of hardware to maintain communication with a target. Table 2 is a list of data in a session description. Table 3 contains a list of session level automation services.
A session scheduling service is available to users for reserving ground station hardware. Users view ground station availability and schedule sessions appropriate to their priority levels. Customized user virtual machines can also be uploaded and attached to session.
Table 2 -- Session Description
Data State Description Start Time Start time of a session. End Time End time of a session. Pipelines Reservation list of transmit, receive, and/or transceive pipeline hardware. VM's List of virtual machines to be running during a session. These perform all bit manipulation, such as (de)modulation, bit synchronization, and packetization. Target List of parameters of the target satellite to track such as target name and keplerian element set. Automation Services A list of automation services to execute during a session, see table 3. User List of contact information for the session user. Used to notify user of session start and end action, errors during execution, and scheduling conflicts. Table 3 -- Session Level Automation Services
Service Description AutoTracker Provides automatic tracking of station antennas. A variety of algorithms are possible for this: open-loop based on estimated satellite positions and closed loop based on equipment feedback. AutoTuner Similar to AutoTracker but tunes radios to account for Doppler shift or other factors. Estimator Calculates satellite position based on Keplerian elements sets. Production Unit Logs all ground station telemetry and satellite channel data during a session. Available for post pass download. VHL Server Provides access to lower virtual hardware level commanding. Enables custom control of hardware.
Network Level
The network level (NL) captures the services of a federated ground station network (FGN). An FGN coordinates ground stations that are under different administrative domains and allows users to task teams of ground stations to cooperate and optimize satellites contacts. Ground stations register with the FGN and advertise their services. Stations dynamically leave and join based on local administrative needs such as routine maintenance or local usage. Users request available ground stations from FGN servers and task them individually or in teams to maintain satellite contact sessions. Teams can be grouped locally to optimize single contacts or distributed world wide to maintain continuous contacts with hand-offs. We have not yet modeled primitives for peer to peer ground station coordination. Table 4 details the objects and services of the network level.Table 4 -- Network Level Services
Service Description Registration Enables FGN ground stations to register and deregister their services. FGN users can query registered stations. Scheduler Provides scheduling of FGN stations centrally by FGN servers. Provides a layer of indirection to ease user management. Not all GS's have to know about all users. Prioritization of users is handled here. VGS Virtual Ground Station services allow ground stations to be composed to form a more capable "virtual" ground station.
Conclusions
The above informal model attempt to capture core ground hardware and services. This model will be used to generate an XML-based messaing API for controlling ground station resources which we call the Ground Station Markup Language.This model is underdevelopment, as seen by the version numbers, and we request all types of comments and critiques. Please post to the MGSN Development or Discussion lists if you have question or comments.
Further information and published papers on this subject is found online at SWIG's research pages.