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.
|
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 3 -- Session Level Automation Services
|
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
|
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.