A Federated Ground Station Network

1
A Federated Ground Station Network

• James Cutler, Armando Fox, Peder Linder
• Stanford University
• Space Systems Development Laboratory
• Software Infrastructures Group
• SpaceOps 2002

2
Overview

• Motivation
• Reducing missions operations costs
• Increasing mission yield and capabilities
• Long term objectives
• Provide baseline satellite infrastructure to make
  science data more accessible and enable
  experiments to have wider impact
• Make this infrastructure robust and affordable
• Primary Technical Approach
• Develop a loose federation of networked virtual
  ground stations

3
Trends in Space Operations

• Space mission trends
• Drastically increased coverage opportunity with
  end-to-end data delivery.
• Support for future mission (such as clustered
  satellites) and legacy systems.
• Generalization of current ground station
  limitations
• Limited ground station coverage (1 or 2 stations
  per mission).
• Stove pipe solutions for single missions.
• Current Research Efforts
• Network-centric approaches horizontal
  architectures and hardware level APIs via
  middleware such as CORBA.
• SLE (Space Link Extension) by ESA/NASA to
  standardize data transfer services between ground
  stations and control centers.
• End-to-end delivery via IP by NASA Goddards OMNI
  group.
• There is still a need for increasing access
  windows, providing greater capability in
  configurations, and making COTS based systems
  robust.

4
FGN Overview

• A federated ground station network (FGN)
• 100s of stations under different administrative
  domains.
• Globally distributed facilities that can
  dynamically join and leave the federation.
• Heterogeneous and networked via Internet.
• Ability to designate teams of stations
• Teams collaborate on high level task (e.g. track
  this spacecraft).
• Global teams to increase access windows.
• Local clustering to optimize ground stations and
  provide path and node redundancy.
• Centralized service infrastructures
• User and installation authentication.
• Registration of installation capability/availabili
  ty.
• Repository of satellite configuration information.

Internet
Network Infra- structure
5
Technologies Virtualization

• Distributed GS components can be composed to
  form a virtual ground station.
• A GS is decomposed into core components.
• These are then assembled to form virtual ground
  station services.
• Local teams for optimization, global teams for
  increased contacts.

6
Technologies ROC
If a problem has no solution, it may not be a
problem, but a fact, not to be solved, but to be
coped with over time Peress Law

• Failures are a facteven the most robust systems
  still fail due to
• human operator error
• transient or permanent hardware failure
• software anomalies resulting from Heisenbugs or
  software aging
• We cope with them through recovery/repair.
• Our design philosophy is recovery-oriented
  computing (ROC). ROC emphasizes recovery from
  failures rather than purely failure-avoidance.
• Improving recovery/repair improves availability
• Availability MTTF / (MTTF MTTR)
• Make MTTF very large then Availability gt 1,
  but, what if MTTR ltlt MTTF
• Further motivationCOTS often have a fixed MTTF.
  We can only work with MTTR.

7
Prototype FGN

• Developing a prototype FGN
• The Mercury Ground Station Network (MGSN)
• Global, university, low-cost OSCAR ground
  stations
• Supporting university satellites such as
  Stanfords OPAL and Sapphire. Also for the
  Cubesat program 10-20 satellites a year.
• Status of Prototype
• Currently focus software for a ROC-enabled,
  FGN-ready single ground station installation.
• Developed basic abstraction for OSCAR station.
  XML-based language called the Ground Station
  Markup Language (GSML). Key is methodology, not
  necessarily acceptance of GSML.
• Secure web interface with hierarchical control.
  Both human and agent-based access. Automated
  sessions with product generation.
• Developing hand-off capabilities for AX.25 and IP
  networked satellites.
• Software development is in Java and will be
  releasing open-source by the end of the year.
• On ROC work, partnering with U.C. Berkeley (David
  Patterson), IBM, Microsoft, etc.

8
Initial Results

• Summary of Internet Lessonsreliability from
  unreliable parts
• Internet services programmed with a bunker
  mentality
• Preserve fault isolation boundariesexploit
  natural isolation boundaries to contain faults
  (clusters,virtual machines)
• Explicitly encapsulate stateall state in a
  well-known, protected place (HTTP)
• Separate data format from implementationdata
  exchange is independent of transport (HTML over
  HTTP, WAP, etc.)
• Design for recoveryROC.

• Summary of application of recursive
  restartability
• Recursive Restartability systematic exploration
  of how to minimize recovery time when using
  partial restarts to recover from transient
  failures
• Biggest improvement MTTF/MTTR-based boundary
  redrawing
• Lower MTTR may be strictly better than higher
  MTTF. High MTTF doesnt guarantee failure-free
  operation interval, but sufficiently low MTTR may
  mitigate impact of failure

9
Conclusions

• Current space mission trends are forcing ground
  station infrastructure to evolve and increase
  capabilities.
• Our research efforts are focused on increasing
  access windows, providing greater capability in
  GS configurations, and making COTS based systems
  robust.
• We are developing a prototype federated ground
  station network to develop and experiment with
  highly networked, distributed ground stations
  that can be composed to form virtual ground
  stations.
• This prototype, called the Mercury Ground Station
  Network, will also provide space/ground access
  for university satellite missions.
• More information is online at
• http//swig.stanford.edu/
• http//ssdl.stanford.edu/
• http//www.mgsn.net/