Source: NASA, Artist: Pat Rawlings
SISO Smackdown
Federation 2013
Project Plan
The Exploration of Aitken Basin
This plan identifies, for technical committee staff, the tasks associated with the
management and direction of the SISO Smackdown event. Products include a
Federation Agreement, Mission Scenario, the Federation Server, Technical Committee
website, a Concept Catalog, a Starter Kit, and a 3D Visualization System.
1
2
Table of Contents
1.0 Introduction ................................................................................................................... 5
2.0 Scope ............................................................................................................................. 5
2.1 Location of the Simulated Mission ............................................................................... 5
2.2 Development Process .................................................................................................... 6
2.3 Work Breakdown Structure .......................................................................................... 7
3.0 Tasks ............................................................................................................................. 8
4.0 Deliverables ................................................................................................................ 11
5.0 Resources .................................................................................................................... 11
6.0 Schedules .................................................................................................................... 11
Appendix A. Federation Agreement ................................................................................. 13
References ................................................................................................................. 13
Overview ....................................................................................................................... 14
General Agreements...................................................................................................... 15
Principles for Updating Attributes and Ownership .................................................. 16
Time........................................................................................................................... 16
Exchange of Information............................................................................................... 17
Managing the Federation ............................................................................................. 17
Handling Output ........................................................................................................... 18
Federation Specifics...................................................................................................... 18
HLA Services used in Smackdown Federation ............................................................. 18
Appendix B. Applications and Libraries .......................................................................... 19
Appendix C. Space Exploration Architecture ................................................................... 21
Appendix D. Concept Catalog .......................................................................................... 22
Appendix E. Integrated Mission Scenario Events ............................................................ 26
Appendix F Glossary ........................................................................................................ 29
Space Exploration Architecture References ..................................................................... 30
3
4
SISO Smackdown Federation2013
Technical Committee Project Plan
1.0 Introduction
Since 2011, the Simulation Interoperability Standards Organization (SISO) has hosted an
annual event known as the Smackdown. A primary objective of this international event is
to “smack-down” barriers to employment by giving college students hands-on experience
with the High Level Architecture Standard (HLA) on a distributed simulation project.
Volunteers from NASA serve as technical mentors to the participating teams, provide
the simulation context, and manage the information infrastructure enables HLA federates
to exchange data. Participating vendors provide free Run Time Infrastructure (RTI) and
supporting development tools to the student teams during the development period and the
demonstration at the annual Spring SISO Simulation Interoperability Workshop (SIW).
Starting in the Fall of the previous year, the Smackdown Technical Committee develops
the simulation context by describing a Lunar exploration architecture, defining
requirements for needed simulation infrastructure, and negotiating Federation Agreement
on how to apply the HLA standard to the simulation. In January and the months leading
up to the event, the Technical Committee mentors the teams through technical
presentations and conducting teleconferences to discuss detailed interactions and data
exchanges among the HLA federates. Additionally, the Technical Committee hosts
teleconference so teams can test federates and practice for the demonstration.
2.0 Scope
The primary objective of the SISO Smackdown Federation Simulation event is to provide
college seniors and graduate students with hands-on development experience with the
HLA Evolved simulation standard. A secondary objective is to provide university teams
from around the world an opportunity to work on an international space exploration
architecture simulation. Considering these objectives, the simulation development effort
ought to focus more on the interactions among federates and development teams than on
the detailed physics and computer graphics. The Technical Committee will focus on the
implementation of a 3D computer graphics display and associated federate, so the teams
can concentrate on the generation of the position data.
2.1 Location of the Simulated Mission
Lunar exploration provides opportunities for university teams to simulate a wide variety
of systems. Appendix D describes more than 20 systems associated with transportation,
manufacturing, communication, habitation, energy production, power distribution, and
threat detection. This variety of systems enables participation by students from several
engineering and computer science disciplines. Previous SISO Smackdown Federations
simulated lunar missions located at Hadley Rille on the side of the Moon that faces the
Earth. A distributed simulation activity at Jet Propulsion Laboratory (JPL), Johnson
Space Center (JSC), and Kennedy Space Center (KSC), produced a 280 square mile
surface model of Aitken Basin, which is located on the far-side of the Moon. Using Unity
3D game engine and the C# programming language, the simulation drives objects around
the Lunar surface. Figure 1 depicts scenes from the Lunar surface visualization
environment in development at KSC.
5
Figure 1 Aitken Basin Lunar Surface Model with a Human Operated Rover (images courtesy of Mike Conroy)
The past two Smackdown Federations included Lunar orbiting spacecraft and
communications satellites. Discussions at the Fall 2012 SISO SIW identified a desire to
conduct missions at the second Earth Moon Libration point (E-M L2) as well as at the
Lunar surface. An Environment Federate, developed at JSC, enables a wide variety of
space mission simulations because it generates a variety of Earth, Moon, and Sun centric
reference frame coordinates. During the simulation, the Environment Federate published
updated positions of the reference frames and simulated entities movement relative to
those reference frames. If two federates use different reference frames and they exchange
entity position data, they need to convert the positions to the current reference frames.
2.2 Development Process
A variety of free space mission visualization software systems, with Application
Programming Interfaces (API) are available on the Internet, including NASA GSFC’s
General Mission Analysis Tool (GMAT). The GMAT has an interface to MatLab, and
Forward Sim offers a MatLab toolkit that enables integration of MatLab simulations with
an RTI. Other free programs, such as Celestia, Orbiter, and Google Earth, have an API
that enables a C++ or Java federate to drive the display. With the wealth of distributed
simulation development tools, RTIs, environment federate, Lunar surface visualization,
and programmable space mission visualization applications, the student teams could
build any type of space mission simulation. Appendix B of this document identifies
several applications and libraries where teams can gain a lot of leverage for physicsbased simulations as well as interactive 3D computer graphics displays.
Section 6.0 below presents a high level development schedule based on the Federation
Development and Execution Process (FEDEP). Based on the primary and secondary
objectives of the SISO Smackdown Federation, a detailed development process ought to
prioritize effort in this order:
1. Interaction with federates developed by other teams
2. Physics and logic that generates the data exchanged among federates
3. Data displays and computer graphics
Initially, a federation can comprise of stub federates that publish and subscribe to
positions and statuses. Each federate can write lines to the console that identify what was
6
sent and received. A generic federate can include the time management, publish, and
subscribe, objects, and interactions. After demonstrating the generic simulation network,
teams can focus on adding the detailed physics and mission oriented logic.
Appendix C presents a space exploration architecture, Appendix D provides narrative
descriptions of the systems in the architecture as a concept catalog, and Appendix E
presents a detailed integrated mission scenario that highlights system interaction events.
A detailed timeline depicts the events and approximately when the events occur during
the simulation. The Technical Committee must decide on the duration of the simulation
and document it in the Federation agreement. Participating teams need to highlight the
events of interest to an audience and revise the timeline and integrated mission scenario.
Teams from universities that participated in previous SISO Smackdown Federation
events have the option of giving up their old federates for adoption by new teams, so they
can create new federates. Adopting a federate is a quick way for a new team to get started
in development; also, it teaches teams to develop their code for reusability.
2.3 Work Breakdown Structure
The Work Breakdown Structure (WBS), depicted in Figure 2, identifies products and
services to be developed and deployed by the Technical Committee. Appendix A
contains the Federation Agreement from the 2012 SISO Smackdown; a task described in
this plan will update the agreement for the 2013 event. Other tasks include the integration
and deployment of the Smackdown Federation Server, the creation of a Concept Catalog,
developing code and instructions for a Starter Kit to help new teams to establish their
own development and test environment, and a Technical Mentorship task, which will
produce tutorials, provide technical support to the teams, and assist in recruitment.
Figure 2 Work Breakdown Structure for Products and Services
7
3.0 Tasks
This section describes the tasks in the WBS presented in Figure 2. Task descriptions
identify the products and activities. Primarily, the products constitute the infrastructure
that facilitates the Smackdown Federation simulation, a Federation Agreement that
provides details about the application of the HLA Evolved standard, documentation of
the space exploration architecture to be simulated and supporting software and tutorials to
help new teams become participants. Other sections of this document specify the
deliverables, resources and schedule.
3.1 Deploy the 2013 SISO Smackdown Server
A team at Johnson Space Center (JSC) provided the central server for the past two
Smackdown federations, and they have agreed to deploy the server again for the 2013
event. Participating vendors, Pitch and MAK, generously provided the Central Runtime
Component (CRC) of their Run Time Infrastructure (RTI). Other Smackdown server
software includes: a Virtual Private Network (VPN) and an Environment Federate, which
publishes a one-second heartbeat and reference frames. Activities associated with this
task includes:
 Obtain licenses from the RTI vendors
 Establish a server with the VPN
 Update the Smackdown server documentation for 2013
 Provide the server access information to the university faculty sponsors
3.2 Establish the Federation Agreement and Mission Scenario
A Federation Agreement explains details about the common elements of the simulation
federation. Questions addressed by this agreement include “What is the data update
rate?”, “How do we manage time?”, “How do we coordinate reference frames?”, “What
are the modular Federated Object Models (FOM) used in the Federation?”, “What is the
duration of the simulation?”, “What version of the RTI are we using?”, and “How do I
configure the RTI to work with the VPN?”. Additionally, the Federation Agreement must
identify the participating federates. Later versions of the agreement can identify the data
exchanged among the participating federates. Appendix A contains the Federation
Agreement that was developed for the SISO Smackdown 2012 event. While some aspects
of the agreement ought to be the same from year to year, the Technical Committee needs
to update the Federation Agreement to address new modular FOMs, emphasize
interactions among the federates, and increase the level of detail regarding the VPN,
reference frames, and time management.
A Mission Scenario serves as a source for requirements regarding data exchanges and
interactions. Each team has a responsibility to identify events that will occur during the
simulation. An integrated mission scenario ought to include a Gantt chart that highlights
important events that will capture the interest of an audience. Appendix E provides a
detailed integrated mission scenario based on the space exploration architecture in
Appendix C. Appendix D provides a concept catalog that describes the systems in the
space exploration architecture. After the narrative descriptions of the integrated mission
scenario events, a Gantt style chart graphically depicts the events on a timeline. Times are
expressed as percentages so the Technical Team can decide whether to make the
simulation last for 90, 60, or 45 minutes. Event codes on the timeline correspond to event
8
descriptions in Appendix E. Teams need to think about ways to present the information
such that an audience recognizes the occurrence of the event. The space exploration
architecture in Appendix C identifies the existing federates in green. This strawman
architecture is meant to be starting point for discussion; the Technical Committee can
decide to remove, add, or revise conceptual systems in the architecture. A development
process may include the creation of stub federates that serve as place-holders for future
teams to populate with physics and logic.
A mission scenario development process:
 Establish boundaries for technologies and policies surrounding mission events
 Identify geographic coordinates for the Lunar surface activities
 Provide information from NASA studies of potential Lunar and space missions
 Develop requirements for system interdependencies based on the missions
 Define trajectories for space transportation systems and satellites
 Establish a volume of space for L2 mission activities
 Document interactions among space mission assets created by participating teams
 Highlight interesting events, so each simulation can have time in the spot-light
 Create a visual time-line that depicts the high-points of participating simulations
 Develop the back-story that the federation demonstration emcee can narrate
 Determine visualization methods for object interactions and communication
3.3 Develop a Concept Catalog for the SISO Smackdown Technical Committee website
Teams may have a clear idea of what they want to produce, or they may want to adopt an
existing simulation, or they may want to review a variety of concepts and select
something to simulate. Appendix C presents a space exploration architecture with 25
interacting systems. Appendix D contains an initial draft of concept catalog that describes
the systems in the space exploration architecture. A concept catalog would provide
details about previously developed simulations and indicate whether they are up for
adoptions and provide links to papers about concepts that have not yet been implemented
as a simulation. Activities associated with these tasks include:
 Create a web-page with descriptions of potential mission scenarios based on
previous SISO Smackdown Federations and NASA Studies.
 If teams that participated in previous Smackdown Federations would like to give
away one or more simulation federates, they can post the adoption information on
the concept catalog page.
 Use Cases for the Concept Catalog: A new team would like to develop something
but they don’t know what, so they visit the concept catalog. A team would like to
participate but they won’t be able to develop something in time, so they can adopt
an existing federate. An engineering school is not interested in creating a federate
but they would like to contribute to the concept catalog. The SISO Smackdown
website would be a logical place to host the concept catalog.
3.4 Create a Distributed Simulation Starter Kit
Use Cases for the Starter Kit – Many teams are unfamiliar with the HLA standard and
have no idea how to start studying the standard. Items in this starter kit enable a new team
to come-up to speed quickly. This starter kit and the concept catalog provide a clear path
to an idea that contributes to the over-all exploration mission scenario and the tools for
implementing a federate. The SISO Smackdown Technical Committee website can
9
provide instructions on how to assemble the starter kit. The following activities are
associated with this task:
 A beginner’s tutorial to the HLA – Bjorn Moller has this covered
 Distributed simulation overview presentations – Zack Crues, Dan Dexter, Dan
O’Neil and participating team faculty sponsors can contribute content for
presentations about distributed simulations, VPN, conference papers about
previous Smackdown federations
 Overview presentations about how to design a spacecraft, rover, or
communications system. Example code can help a team get started.
 Two vendors, Pitch Technologies and VT MAK provide a free demonstration
version of their RTI – currently available from their respective websites
 A free open-source version of the Environment Federate – could be produced with
the Java Astrodynamics Tool Kit – Zack Crues developed high-level
requirements, hopefully, he has time available to lead the development effort. An
ideal situation would be for a university to provide a graduate student who can
work with Zack starting now and completing the product by early January.
 Another federate with entities that interact with the environment federate for a
heart-beat and reference frames. Both Pitch and VT Mak’s free demonstration
RTI allow two interacting federates. With the free RTI and free NASA provided
federates, a university can immediately establish an HLA-Evolved development
laboratory and start with code examples that apply the HLA Time management
function and one or more space-based reference frames.
 RPR FOM provided by the SISO organization.
 Each participating university provides instructions on how to obtain the IEEE
HLA Evolved standard from their library.
3.5 Support Recruit Teams to Participate in the SISO Smackdown Federation
 The SISO Smackdown Executive Committee has the role and responsibilities of
recruiting new universities to participate in the SISO Smackdown Federation.
 Members of the Smackdown Technical Committee (STC) have points of contact
at NASA centers and universities, so the STC members can provide their POCs
with information about the event and how to contact the executive committee to
announce intent to participate in the event.
 Members of the STC serve as technical mentors to the student teams, so they can
contribute content to materials to overview presentations, tutorials about federate
development, and answer questions for prospective participants
 Moderated discussion forums and Frequently Asked Question (FAQ) lists can
help new teams find answers to their questions. Forums and FAQs can attract new
teams by giving them an idea of what they will learn from participation.
10
4.0 Deliverables





Smackdown Server with RTI, Communications Server, and Environment Federate
Invitation E-mail to previous Smackdown participants and potential participants
o Link to the Smackdown website
o Explain benefits of participation
o Identify the Smackdown Committee members
Web page with instructions on how to assemble the starter-kit and links to
software for a Smackdown Federation development and test server
Web page with a FAQ based on questions from the last Smackdown
Web page with an initial concept catalog with narrative descriptions of existing
and needed federates.
5.0 Resources
The SISO Smackdown Federation is a labor of love and an investment in the future
workforce. Sponsoring organizations get the benefit of working with college seniors and
graduates who are enthusiastic about distributed simulation. Students who participated in
previous events can provide new teams with lessons learned, technical mentorship, and
additional experience that they can list on their CV or resume. Vendors provide licenses
for their software to students, who may become future customers or advocates within
companies who are considering distributed simulation products. The following list
identifies a partial listing of the participating organizations and individuals on the
Technical Committee:






Participants at JSC – Smackdown server and leadership role in the development of the
free open source Environment Federate
Participants at KSC – Smackdown Website and Lunar Surface Visualization Simulation
and leadership role in development of an associated federate
Participants at MSFC – Coordinate tasks, resources, and schedule; develop content for
the concept catalog and instructions for assembling the starter kit, recruit speakers to
tutorial teleconferences, develop class-room content for a distributed simulation class,
and refine this project plan.
Participating Vendors – Pitch, MAK, and ForwardSim provide products
Paul Grogan – provides the SISO Technical Committee website
Daniel Verret and Sean Muratet – developed the MatLab federate that receives and
extrapolates position data for 3D visualization.
6.0 Schedules
Many of the infrastructure products need to be developed before January to support teams
that are developing federates as part of a Spring semester course.
Technical Committee Products and Infrastructure
 Smackdown Server – preferred availability in the first week of January
o RTI – provided by participating vendors -- November/December
o Existing Environment Federate on JSC owned Server – December
o New Free open source Environment Federate – Mid January 2013
o Communications server – provided by UAHuntsville in November
 Most of the Starter Kit by first week in January 2013
o Part 1 of the HLA Beginners Tutorial – Available Now
11


o Example code for the beginners tutorial – Late October
o Part 2 of the HLA Beginners Tutorial – Late December
o Updated free demonstration RTI from vendors – late December
o Example HLA federates – EZ Federate, Rover, Satellite – December
Concept Catalog
o Descriptions of potential lunar surface systems and spacecraft – December
o Availability of existing federates available for adoption – Early January
o Links to previous exploration concept studies via NTRS – Mid December
Supporting Infrastructure
o Configuration Management Repository – Decide in November
o Discussion Forum and FAQ – Late January 2013
Development Schedule
The following high-level schedule derives from the FEDEP. Many of the decisions about
the application of the HLA-Evolved standard via the Federation Agreement, the
Integrated Mission Scenario, and software infrastructure need to be locked-in before the
teams start developing federates in January. If the Technical Committee can find
volunteers to produce generic stub federates, the teams can start integrated testing in early
January so they immediately gain experience with the RTI, VPN, and conducting an
international simulation over the Internet. After the initial experience with the generic
network, the teams can focus on developing or integrating physics models, mission logic,
and graphics displays with their federates.
12
Appendix A. Federation Agreement
Abbreviations and Definitions
This section documents the abbreviations, acronyms and terms used in the
document.
Term
Meaning
ephemeris
http://en.wikipedia.org/wiki/Ephemeris_time
time
HLA-Evolved allows a federation's federation object model (FOM) to be
composed “from pieces” rather than in a single XML file. Each such piece is
FOM
an XML file that is possibly layered on others (in the sense of depending on
module
the definitions in those others). And these individual pieces are called FOM
modules.
HLAThe most recent IEEE HLA standard, IEEE-1516.2010. This is the version of
Evolved middleware and object model used in the Smackdown federation
An orthogonal set of three axes that may be used as a basis onto which to
reference
project the components of a three-dimensional vector. The orientation of
frame
bodies in space is specified with respect to a particular reference frame.
Runtime Infrastructure is software often referred to as “middleware” which
supports communication, transfer of data and other interoperability
RTI
requirements for the Smackdown Federation. The federation will use RTI
middleware from two vendors, MaK (www.mak.com) and Pitch
(www.pitch.se)
References
Reference
Description
The “core” HLA-Evolved FOM module contains definitions of
common information/settings and data types.
The “environment” HLA-Evolved FOM module represents the
SISO_Smackdown_1011_environ.xml
reference frames and time.
The “entity” HLA-Evolved FOM module represents physical
entities in the federation such as space vehicles, lunar rovers, etc.
SISO_Smackdown_1011_entity.xml
The PhysicalEntity class will be subclassed and extended as
necessary.
A modular FOM providing logistics-related functions such as
SISO_Smackdown_1112_logistics.xml
resource data types and resource transfer interactions.
A modular FOM providing object classes for the two MIT
SISO_Smackdown_1112_mit.xml
vehicles: a mobile resource plant and a scouting hopper.
A modular FOM providing text-based chat-related functions such
SISO_Smackdown_1112_chat.xml
as a participant object model and a chat message interaction class.
SISO_Smackdown_1011_core.xml
13
Overview
Conceptual Domain Model
The SISO Smackdown will be a multi-participant simulation of a simple solar system
with space vehicles moving through it. The base scenario will consist of a simple solar
system model consisting of the Earth, Moon and Sun, with space vehicles moving around
in the solar system. It will also include lunar surface representations such as habitat
modules, lunar rovers, transfer vehicles, etc. Since the Smackdown will use HLAEvolved, the FOM and the simulated entities may be extended by participants. This
document does not describe such extensions, but we expect the base scenario briefly
described here to be extended as additional participants join the federation and possibly
introduce new FOM modules.
The Earth and Moon inertial reference frames move with the Earth-Moon barycenter
frame. The Earth-Moon barycenter frame moves with the solar system barycenter frame.
The solar system barycentric inertial frame is the “root” frame in which all solar system
and vehicle activity occurs, and motion of any of the entities (reference frames and
vehicles) is ultimately referred back to it. Vehicles will also move around in the system,
their motion being calculated by the various federates as time-varying positions,
velocities, etc. expressed relative to some particular reference frames.
Federation and participating federates
NASA will provide two federates: an Environment federate to populate the solar system
with the relevant reference frames and their mutual locations and orientations relative to a
root frame and an Earth-Moon transfer vehicle federate to propagate the trajectory of a
single Earth-to-Moon transfer vehicle. One of the tasks in the project plan is to replace
the proprietary Environment federate with a free open source version. Participating teams
will produce federates that represent space exploration systems.
Federation Object Model
NASA will provide a federation object model (FOM) that is sufficient for the
environment and vehicle simulations. This federation object model consists of three
HLA-Evolved modular FOMs:



a core FOM module that defines common data types used in the other FOMs,
an environment FOM module that defines a ReferenceFrame object class, and
an entity FOM module that defines an entity object class. These are used to
represent physical entities in the federation (space vehicles, habitats, lunar rovers,
etc.)
For a full description of the various elements of the FOMs, you will need to read the .xml
files themselves. The <semantics> elements of the various FOM entities are filled in with
complete descriptions.
Core
This FOM module defines several data types used in the other modular FOMs. This
includes such things as mass, position vectors, attitude quaternions and so forth. For
14
details of these data types, see the core FOM module file. This module does not define
any simulation-specific object or interaction classes.
Environment
This FOM defines a single object class: ReferenceFrame. Reference frames essentially
consist of an origin point and a set of orthogonal coordinate axes. Together the origin and
the axes allow you to unambiguously specify the components of forces, torques,
positions, velocities, angular velocities, angular accelerations, etc – everything you need
to propagate vehicle dynamics through space. Read the Environment modular FOM for
the specific reference frame objects and attributes.
Entity
This FOM defines a physical entity object class which will be subclassed as necessary to
describe additional physical entities in the federation. Participants will not create an
instance of the PhysicalEntity class. They may subscribe at that class level and upon
discovery/updates, will need to examine the entityType attribute to understand what type
of entity discovered or updated. Current entity types include: LunarRover, LunarHabitat,
TransferVehicle, MobileResourcePlant, and ScoutingHopper. Teams can expand this
modular FOM to implement other entities. This FOM serves as an agreement among
teams on the name of the entities represented by federates; so, once a team names an
entity they must not change it unless they update the FOM with the knowledge of the
participating teams and Technical Committee.
Overview of the Information Flow
All scenario data described in the FOM is expected to be communicated via the RTI
middleware using HLA 1516-2010 services. Any out-of-channel data not passed through
the RTI using RTI services will need to be discussed with the Technical Committee.
Distributed Data Management (DDM) Usage
The DDM services are not used in this federation.
General Agreements
Standards, Hardware, Software and Networks
HLA Version
This federation execution will use HLA-Evolved (IEEE 1516.2010).
Hardware
Participants will be required to supply their own execution hardware and any network
cables or switches beyond the single wired network connection to the NASA network
switch.
Software
The federation execution will use the SonicWall NetExtender VPN software supplied by
NASA. All teams will be required to download, install and test the VPN connection.
15
Networks
Reference Federation Architecture network chart. Participating federates will be limited
in network bandwidth to 100kbps. Participants will need to estimate or measure their
bandwidth requirements.
The Virtual Private Network (VPN) software assigns an IP address for participating
federates for a session. Dan Dexter assigns teams a range of IP addresses and each
machine used by a team will need the VPN software, which will allocate one of the
assigned addresses for that session. The IP addresses get assigned on a first-come-firstserved basis, so the participant may have to change the IP address in a configuration file
via a user interface or manually with a text editor.
Principles for Sending Interactions
Participants will need to assess their impact on the federation network traffic. See section
3.1.4 of the HLA standard.
Principles for Updating Attributes and Ownership
Attribute Updates
Attributes will be updated as values change. Participants will need to assess their impact
on the federation network traffic. See section 3.1.4.
Ownership
Attribute ownership will not be transferred during the execution of this
federation.
Late Joiners / rejoining federates
Federates who join/rejoin in the middle of an execution often face the following
problems: First, if they crash unexpectedly, they leave any objects they created (and own)
hanging. Those object attributes may not be updated by another federate until ownership
has been acquired. The second problem is that the rejoining federate starts out with no
“knowledge” of the state of the federation. It must resubscribe to classes it wishes to
receive information about, and it must wait on updated information to populate the
instances. This is problematic when updates are sent only as values change. For some
(e.g., fixed) object instances, there may be no updates. In this case, the rejoining federate
may request updated values based on its subscription, but this may significantly impact
network traffic. In addition, if the rejoining federate employs the 6.10 Request Attribute
Value Update service, other federates will need to implement the 6.20 Provide Attribute
Value Update RTI callback service.
Time
Time Management
Time management is an option to participating federates, but it is not a requirement for
participation. The NASA-supplied environment and vehicle federates will be time
constrained and time regulating. Other participating federates are expected to be time
constrained or not time managed (neither constrained nor regulating) although such
federates will not be able to produce data with an HLA timestamp. The Environment
federate generates a heartbeat that is used for time management. While repeatability is
desirable from a demonstration perspective, it is not critical. Teams ought to identify
16
important events that occur in their simulation and provide approximate times so the
demonstration master of ceremonies or narrator can highlight those events to the
audience.
Time Representation
HLA federated logical time is represented by a big-endian 64 bit integer
(HLAinteger64BE) that measures elapsed microseconds since the start of the federation
execution. For example, a value of 1,000,000 would correspond to an instant 1 second
into the execution of the federation execution. Note that this is different from the timetag
attributes in the object classes in the base FOM modules. The floating point time attribute
in those object classes corresponds to ephemeris time.
Exchange of Information
Appendix C presents a concept graph of a space exploration architecture. Appendix D
provides narrative descriptions of the systems identified in the architecture. Appendix E
of the project plan includes an Integrated Mission Scenario of events that involve
interacting lunar exploration systems. As teams decide upon and implement specific
concepts, they will influence the architecture and integrated mission scenario. These
high-level diagrams, descriptions, and time-tables need to reflect the as-built versions.
A detailed cross-walk or N-Squared table can provide details about the data and type of
data exchange.
Managing the Federation
Setting Parameters
The SISO Smackdown Federation does not have a centralized graphical user interface or
configuration file used at start-up. Each participating team may have their own user
interface and configuration files for setting parameters.
Start
The two NASA-supplied federates are designed to coordinate (synchronize) with each
other during startup. Thus, the federation execution begins when those federates begin.
Other federates may join the federation (late) at any point after the federation execution
has begun. Many of the systems represented in the Lunar exploration scenario are
independent. If two systems interact via docking, payload exchange, entry or exit, etc., it
is up to those teams to ensure that the two systems end up at the same place at the same
time.
Scenario Handling
Without a centralized user interface or configuration file, there is no mission scenario file
that will be executed at the federation level. Individual teams may implement
configuration or script files to drive their federates. Implementing a scenario or scripting
capability in a federate is a good way to “program the program”; it eliminates “hardcoded behavior, so it is a good programming practice.
Save and Restore
This federation will not execute save or restore.
17
Shutting Down
A good design practice is to implement a method of shutting down the federate through a
command line or graphical user interface. There will be times during integrated testing
sessions that everyone will be requested to exit the federation.
Error Handling
Errors must not affect the performance of a federation. Good design practice is to apply
error trapping; especially, if there exists a possibility that the error can produce corrupted
or invalid data that is transmitted to subscribing federates. Each federate ought to include
error trapping around code that receives data.
Handling Output
Data Logging
Previous SISO Smackdown events did not require data logging. In the SISO 2011
Smackdown event, Daniel Verret captured video from the Matlab VRML visualization
and posted it on YouTube. In the SISO 2012 Smackdown event, Dennis Bulgatz, a
member of the UAHuntsville team recorded some of the data, which enabled replay of
part of the simulation. Vendors provide data logging tools to the teams, so each team can
capture interesting data. An ideal situation would be to have a volunteer record the entire
simulation of all the participating federates, so the Technical Committee can produce a
variety of visualizations. The visualizations can assist in recruiting new teams. Recorded
data can be fitted to curves to produce simplified simulation models, which teams can use
for developing system interactions or for stand-alone simulations.
Data Analysis
Data analysis is the responsibility of the individual participants. In particular, no analysis
is expected as part of the federation execution. Individual participants might choose to
inspect their data in order to analyze the execution of their federates, but no specific
analysis is required in order to participate.
Federation Specifics


Federation Name: The Name of the federation is “SISO Smackdown 2013”
Federation Scenario Start Date and Time: The environment federate will use a
scenario start date of April 10, 2013 at 1:00 PM Pacific Time (USA).
HLA Services used in Smackdown Federation
All HLA 1516-2010 services are listed. Some are marked as “NOT USED” indicating
that they may not be used by any federate participating in the Smackdown federation.
Others are marked as “Required” indicating that a participant will have to implement the
service. Others not marked are optional, but if used, should be examined for impact to the
federation participants. <Insert Services Table here >
18
Appendix B. Applications and Libraries
Learning how to write HLA Evolved federates can be a daunting task. Learning about
orbital trajectories, spacecraft design, and computer graphics in addition to HLA is even
more difficult. With the primary objective of the SISO Smackdown Federation being
hands on experience with HLA Evolved, there ought to be some relief regarding the
physics and graphics. This appendix identifies several surface and orbital simulations
with Application Programming Interfaces (API), code libraries, Integrated Development
Environments (IDE), and 3D modeling tools that can help a team produce a professional
looking simulation that is visually interesting to an audience. Federates that include
interfaces to these applications can benefit future teams via reusable code. It benefits
SISO because it increases the visibility of the HLA-Evolved standard to a broad
simulation community and it helps the sponsoring vendors because they can advertise
compatibility with a variety of API and IDE.
Delta 3D – Developed by the MOVES Institute at the Naval Post Graduate School, Delta
3D provides an IDE for developing interactive simulations with out-of-cockpit or out-ofhelmet displays for surface systems. It includes libraries for developing HLA and DIS
interfaces; however, the current HLA library does not support the IEEE 1516E version.
http://www.delta3d.org/index.php
Orbiter – This spaceflight simulator provides views of a cockpit and out of window
displays. More importantly, it has the physics and spacecraft controls. Simulation
capabilities include ascent and descent portions of a mission. A large user community has
created a variety of custom spacecraft using this simulation. Creating a federate that can
exchange data between Orbiter and an HLA Federation opens a wide variety of
opportunities to create piloted spacecraft and landers.
http://orbit.medphys.ucl.ac.uk/
Celestia – A space mission simulator, Celestia provides visualizations of trajectory paths
and the capability to plan missions through the known Universe. This simulator is better
suited for in-space assets because it does simulate ascent or descent to a surface. With the
API, a federate could use Celestia to determine current position, visualize the spacecraft
and trajectory, and provide an out-of-window display of space.
http://www.shatters.net/celestia/
General Mission Analysis Tool (GMAT) – Developed by NASA’s Goddard Space
Flight Center, the GMAT simulates spacecraft and space missions. Multiple windows can
present planetary bodies, orbital trajectories, and the spacecraft. Code libraries from Jet
Propulsion Laboratory (JPL) provide the capability to simulate the propulsion system. An
important feature of GMAT is an interface to MatLab. A team can develop their federate
in MatLab and use GMAT for its code libraries and visualization. Using Forward Sim’s
HLA Toolbox, the MatLab federate can interface with Mak or Pitch RTI.
http://gmat.gsfc.nasa.gov/
19
Java Astrodynamics Toolkit (JAT) – This Java library provides functions for
simulating positions of the planets, orbital propagation, and physics for simulating the
behavior of a spacecraft. An immediate application of the JAT is to create an open-source
version of the Environments federate for a Smackdown Starter Kit.
http://jat.sourceforge.net/
Java Monkey Engine (JME) – The JME is built on top of Netbeans, a popular Java IDE.
This IDE includes code libraries or a Software Development Kit (SDK) for creating 3D
video games. With a few function calls, a developer can create a video game with a
joystick interface and import 3D models to create custom visualizations. For the SISO
Smackdown 2012 federation, the UAHuntsville team used the JME to create a
visualization of a constellation of communication satellites orbiting the Moon. Combined
with the JAT, a team can create custom space system simulations with physics and
graphics. http://jmonkeyengine.com/
Unity 3D – This professional, yet free, IDE enables the development of video games.
Scripting languages for Unity 3D include Javascript, C#, and Boo. Creating a federate
interface to a Unity 3D game may require socket programming. Using Unity 3D, the
Smackdown Technical Committee members at Kennedy Space Center (KSC) are
developing a Lunar surface visualization. http://unity3d.com/
Blender – A powerful free open source modeling, animation, and game development
system, Blender has a tremendous user community with discussion forums, tutorials, and
videos. Unity 3D accepts native Blender files. Blender’s import, export, and vertex level
modeling functions makes it a good swiss-army-knife for translating and repairing 3D
files. A recommended use of this application is for the creation of models that would be
viewed in simulations created with the other simulators and IDE. http://www.blender.org/
Sketchup – With its brief learning curve, Sketchup is a great tool for creating 3D models
to visualize a spacecraft or Lunar surface system. More importantly, Sketchup has a
warehouse with existing models of spacecraft and Lunar surface systems. To get the
models out of Sketchup and into one of the simulation IDEs a simple approach is to
export a COLLADA file and import it into Blender. With Blender, the model can
converted to a variety of formats that are compatible with the IDEs described in this
appendix. http://www.sketchup.com/intl/en/
COLLADA - COLLADA is a COLLAborative Design Activity for establishing an
interchange file format for interactive 3D applications. COLLADA is managed by the
nonprofit technology consortium, the Khronos Group. COLLADA defines an open
standard XML schema for exchanging digital assets among various graphics software
applications that might otherwise store their assets in incompatible file formats.
COLLADA documents that describe digital assets are XML files, usually identified with
a .dae (digital asset exchange) filename extension.
20
Appendix C. Space Exploration Architecture
The space exploration architecture depicted in the following diagram includes transportation, habitation, manufacturing, communications, power, and
threat detection systems. Lines between the systems identify a type of interaction or data object exchange. Green filled ovals identify system
simulations developed for previous SISO Smackdown federations.
21
Appendix D. Concept Catalog
(Note: within carrots (< ….>), the status of the described item is listed, either “Needed”,
meaning the item has yet to be developed and added to the Smackdown “systems”, or
“Existing”, meaning the item exists and has been used in one or more Smackdown
events). “Optional” is also listed, meaning that it is one of multiple competing concepts;
for example, energy production could be done by a nuclear system, solar farm, or a solar
power satellite. If one optional system is implemented, the competing concepts are not
needed.
Astronaut – <Needed> A small crew of astronauts and cosmonauts ought to inhabit an
L2 Observation outpost, a piloted orbiting space-craft, and habitat. Arrows marked, enter
or exit, indicate potential interactions between the explorers and a piloted rover, the
landing pad, the warehouse, and the asteroid detection facility. A simulation of a space
explorer could involve several states, e.g., sleeping, eating, exercising, relaxing, donning,
doffing, driving, entering, and egressing. Variables could present health status like heart
rate, oxygen supply, and strength. With the simulation running approximately a wallclock hour during run-time, the astronauts could start in various locations and perform
specific tasks. A pair of astronauts could leave the habitat, enter the rover, and drive to
the ware-house or propellant manufacturing facility to retrieve oxygen tanks and return to
the habitat. Visual displays could be a 2D map that identifies position with trend plots for
the variables. A 3D first-person view with a joystick could allow students to move an
astronaut through mission. A 3D third person view could display the current activities or
positions of the astronauts.
Automated Cargo Lander – <Existing> Developed by Penn State Team: This federate
simulates a landing and take-off of an automated cargo lander. While sitting on the
landing pad, an automated cargo rover docks with the lander to offload the payload. The
cargo rover could transfer products the cargo lander for transfer back to the orbiting
space-craft.
Asteroid Detection Facility (ADF) – <Existing> Developed by the Italian team. This
simulation includes a database of actual asteroids. A potential event that could be
reported by this federate during the simulation is an asteroid that passes between the
Earth and Moon. A visual display could present the locations of asteroids in the database
in relationship to the Earth Moon system.
Cargo Rover – <Existing> – Originally developed by NASA Intern Ben Cowen, from
North Carolina State University, for the 2011 Smackdown and adopted by Penn State for
the 2012 Smackdown – This automated rover moves to the cargo lander and receives a
payload. In previous SISO Smackdown Federation events, the cargo rover traversed
between a warehouse and the landing pad where it exchanged payloads with the cargo
lander. The integrated mission scenario, defined in Appendix E, identifies a variety of
traversal paths for the cargo lander. While the cargo rover is waiting for the arrival of the
lander, the rover could traverse between and exchange payloads with the propellant
depot, mass driver, asteroid detection facility, and habitat.
Communication Satellites <Existing> - Developed by the University of Alabama in
Huntsville (UAHuntsville), the communications satellites relay messages when two
surface systems are not within line-of-sight.
Diggers <Needed> – Strip mining robots dig up Lunar regolith for robotic haulers to
carry to a propellant production plant. After receiving a message regarding the site of a
rich mineral deposit from the exploration hopper, one or more diggers traverse to the site.
When the digger has produced a truck-full worth of regolith, it sends a message to request
a hauler. If the digger(s) and hauler(s) are not within line of site, the communication
satellites convey the message.
Exploration Hopper <Existing> - Developed by MIT. An exploration hopper jumps
from one location to another, analyses the mineral deposits and broadcasts a report. The
mobile In-Situ Resource Utilization (ISRU) system, diggers, and haulers travel to the site
where the hopper reports on rich mineral deposits. Depending on the lunar surface, the
hopper may find itself behind a hill or down in a crater so it does not have line-of-sight
communication. The communication satellites passing overhead provide a means of
conveying messages to the stakeholder systems.
http://web.mit.edu/nconduah/www/TALARIS/papers/AIAA-2009-6712.pdf
Habitat <Needed> - Where astronauts and cosmonauts live when they are not traversing
to the other facilities. Status could include oxygen, air, and power status. An important
function of a habitat is protection from solar radiation storms. A potential scenario could
involve a Solar Particle Event Early Warning System (SPE-EWS). If the SPE-EWS
detects a radiation event, the astronauts and cosmonauts must immediately travel to the
habitat to ride out the storm.
Haulers <Needed> – Just as construction sites and mining companies need dump trucks,
utilization of lunar resources will require something to move the regolith from a strip
mine to the propellant production plant. Automated haulers get a status report from
diggers that are ready to have regolith hauled away.
L2 Space Observation Outpost <Needed> – Earth-Moon Libration point number two
(L2) exists on the far-side of the Moon at a specific distance from the lunar surface and
has line-of-sight with the Aitken basin. An observation post located at L2 can serve as a
staging area for sorties to the Lunar surface, provide a view of space on the far side of the
Moon and augment capabilities provided by the Asteroid Detection Facility. A potential
scenario that could be interesting is a warning from the Solar Particle Event – Early
Warning System (SPE-EWS) requires the astronauts and cosmonauts to evacuate the
observation outpost so they can ride out the storm in the habitat on the Lunar surface.
http://www.space.com/14518-nasa-moon-deep-space-station-astronauts.html
L2 Space Elevator <Optional> - A space elevator has one end at a platform in space
located in a synchronous orbit so that it is always over the same location on the surface.
A tether extends from the platform to the surface and a climbing-robot or car traverses
from space down to the surface and back. A space elevator could extend from an
23
observation outpost located at Libration point number two (L2). A piloted spacecraft can
dock with the observation outpost and travelers can use the elevator. Likewise supplies
for the observation outpost can be transported via the elevator. This federate is marked
optional because the functionality could be provided by a piloted lander. Benefits of the
space elevator include reduced requirements for propellant and simplified operations for
surface to space operations. http://en.wikipedia.org/wiki/Lunar_space_elevator
Mass Driver <Optional> - A mass driver is a long electromagnetic conveyer belt.
Payloads sitting on the conveyer belt platform accelerate to escape velocity so they fly off
the edge of the Moon. A space cargo vehicle or tug-boat then can capture the payloads
and deliver them to an observation post located at Libration point two (L2) or Earth.
http://en.wikipedia.org/wiki/Mass_driver
Piloted Lander – <Needed> Human in the loop landing. This federate would involve a
person piloting the lander. A good starting point for creating this concept is Orbiter.
Visual displays could present the out-of-cockpit displays. If the L2 Space Elevator exists,
this lander could serve as a back-up system for emergency evacuations.
Piloted Rover – <Needed> Astronauts and cosmonauts need transportation to traverse
between surface facilities. Like any moving system, it needs to publish the current
position and subscribe to a reference frame. Interactions with facilities may include
replacing batteries from the warehouse or recharging batteries from the solar farm.
Primary interactions will be travelers entering or exiting the vehicle. Status displays
might include position, energy level, oxygen level (or not depending on whether space
suits have enough for the duration of the trip). Graphical displays could be out of the
cockpit views of the surface.
Piloted Spacecraft - <Needed> Space travelers need a means of transportation to the
Moon. A piloted spacecraft can orbit the Moon and the travelers can go down to the
surface in a lander or it could dock with the L2 Observation Outpost. Like other moving
systems, this federate needs to publish its position and subscribe to a reference frame.
State variables include oxygen and water supplies, remaining propellant, and docking or
separation status.
Propellant Production Plant <Needed> – A large-scale production plant can process a
lot of regolith to produce propellant for landers and spacecraft and other useful products.
Such a system needs haulers to bring regolith to the facility and cargo rovers to carry
products from the facility. A potential scenario involves one or more haulers dumping
regolith into the facility. A cargo rover carries empty tanks from the warehouse to the
production plant, which fills the tanks with oxygen and hydrogen. A cargo rover carries
the full tanks from the production plan to a mass driver, which launches the tanks into
space for capture and usage by a space transfer vehicle.
http://www.sei.aero/eng/papers/uploads/archive/IAC-07-A5.1.03_present.pdf
http://www.lpi.usra.edu/meetings/ISRU-III-99/pdf/8011.pdf
24
Radioisotope Thermoelectric Generator <Optional> - An RTG uses the heat from
decaying nuclear material to produce electricity. This federate is optional if a team
produces another power generation system like a solar farm or solar power satellite. Like
any power source, the output ought to state generation and storage levels and the loads
from providing power to the other facilities. A primary benefit of this concept is it
generates power at night.
http://en.wikipedia.org/wiki/Radioisotope_thermoelectric_generator
Solar Farm <Optional>– Solar arrays collect the Sun’s energy and generate electricity
for near-by facilities. The status for this federate is optional if a team produces a federate
for a radio-thermal isotope generator. If no other power generation system is available, a
solar farm can generate power for the other lunar surface facilities, i.e., habitat,
warehouse, asteroid detection facility, propellant plant, and mass driver. Rovers could go
to a charging station to recharge with power from the solar farm. Interactions with the
other federates would deplete the energy stored in batteries at the solar farm. Periodic
status reports may include power generation and energy storage levels. An assumption
associated with this federate is the mission occurs during the two-week day.
http://en.wikipedia.org/wiki/Solar_farm
Solar Particle Event Early Warning System (SPE-EWS) <Needed> - Solar radiation
storms are the greatest threat to space explorers on the surface of the Moon. An early
warning system might give people adequate time to seek shelter. A potential scenario
could involve a warning and the crew scrambling to a piloted rover or habitat to ride out
the storm. http://conceptactivityresearchvault.wordpress.com/2011/01/02/solar-energeticparticle-event-effects/
Solar Power Satellite and Rectenna <Optional> – A solar power satellite generates
energy as it orbits the Moon. When the satellite passes over the rectenna, power is
beamed down to the surface and distributed as electricity. This federate is optional
because it competes with solar farm and radio-thermal isotope generator concepts.
http://en.wikipedia.org/wiki/Solar_power_satellite
Mobile In-Situ Resource Utilization (ISRU) Plant <Existing> – Developed by MIT.
This MatLab based federate simulates the traversal and activities of a mobile In-Situ
Resource Utilization (ISRU) plant. An ISRU system scoops up regolith and processes it
to produce products like oxygen, hydrogen, titanium, and other useful gases or minerals.
An exploration hopper jumps around to potential sites that have rich mineral deposits and
it reports the status to the Mobile ISRU plant. If the two systems are not within line of
site, the messages are conveyed by the communications satellite.
http://en.wikipedia.org/wiki/ISRU
Warehouse <Existing> - Developed by the team with representatives from Genoa, Pisa,
and Rome. This federate provides a status of supplies in the warehouse. Supplies may
include oxygen and hydrogen tanks, food and water, orbital-replacement-units for space
assets, robotically-replaceable units for rovers, and empty tanks for a propellant
production facility.
25
Appendix E. Integrated Mission Scenario Events
The simulation begins with the steady-state operations of facilities located in Aitken
Basin of the Moon and Libration Point number two (L2). All surface systems were
previously deployed. This federation simulation includes the launch of cargo launch
vehicle and the deployment of cargo space transfer vehicle. Meanwhile, another cargo
space transfer vehicle already in orbit around the Moon deploys a lander to convey cargo
to the surface. The concept catalog and this integrated mission scenario include an
optional Space Elevator and Mass Driver. If a team does not implement a space elevator,
then a piloted lander can bring people down to the surface. If no team implements a mass
driver, the cargo lander can carry payloads back into orbit.
[A] Asteroid Detection Facility
A1
Display positions of asteroids of interest.
A2
Detect asteroid passing between the Moon and Earth.
[B] Astronauts
B1
Astronauts leave Habitat use Piloted Rover for Traversal Path 1.
B2
Astronauts leave Warehouse use Piloted Rover for Traversal Path 2.
B3
Astronauts leave Landing Pad use Piloted Rover for Traversal Path 3.
B4
Astronauts leave Habitat use Piloted Rover for Traversal Path 4
[C] Automated Cargo Lander
C1
Cargo Lander separates from Cargo Transfer Vehicle.
C2
Cargo Lander lands on the Landing Pad.
C3
Cargo Lander and Cargo Rover exchange payloads.
C4
Cargo Lander launches from Landing Pad.
C5
Cargo Lander docks with Cargo Transfer Vehicle
[D] Autonomous Cargo Rover
D1
Cargo Rover departs from Warehouse and traverses to Landing Pad.
D2
Cargo Lander and Cargo Rover exchange payloads.
D3
Cargo Rover returns from Landing Pad to Warehouse.
D4
Cargo Rover traverses to Propellant Plant and exchanges payloads
D5
Cargo Rover traverses to Mass Driver to deliver payload.
[E] Cargo Launch Vehicle
E1
Cargo Launch Vehicle displays countdown and Launches from Earth.
E2
Cargo Launch Vehicle and Cargo Transfer Vehicle separate in Earth orbit.
E3
Cargo Launch Vehicle re-enters to Earth.
[F] Cargo Space Transfer Vehicle
F1
Cargo Transfer Vehicle separates from the Cargo Launch Vehicle.
F2
Cargo Transfer Vehicle travels from Earth Orbit to Lunar Orbit.
F3
Cargo Transfer Vehicle and Cargo Lander separate in Lunar Orbit.
F4
Cargo Transfer Vehicle and Cargo dock in Lunar Orbit.
[G] Communications Satellites and Communication server
G1
Satellite 1 passes overhead and relays messages.
G2
Satellite 2 passes overhead and relays messages.
G3
Satellite 3 passes overhead and relays messages.
G4
Satellite 4 passes overhead and relays messages.
26
[H] Diggers
H1
Digger traverses from Warehouse to site identified by Exploration Hopper.
H2
Digger displays data about the amount of regolith dug from site.
H3
Digger transfers regolith to Hauler.
[I] Exploration Hopper
I1
Exploration Hopper jumps to a new location and transmits data.
I2
Exploration Hopper jumps to a new location and transmits data.
I3
Exploration Hopper jumps to a new location and transmits data.
[J] Habitat
J1
Habitat reports status on oxygen and water levels and occupants.
J2
Habitat reports status on oxygen and water levels and occupants.
[K] Haulers
K1
Hauler traverses from Warehouse to the site of the Digger.
K2
Hauler receives regolith payload from the Digger.
K3
Hauler traverses from the site of the Digger to the Propellant Plant.
K4
Hauler dumps regolith into the Propellant Production Plant.
[L] Libration Point 2 Space Observation Outpost
L1
Observation outpost transmits status about oxygen and water levels.
L2
The Piloted Spacecraft docks with the Observation Outpost.
L3
Observation outpost and Asteroid Detection Facility exchange data.
[M] Libration Point 2 Space Elevator
M1
Travelers enter the Space Elevator from the Observation Outpost.
M2
Space Elevator transmits status about current location of the car.
M3
Elevator stops at Landing Site and Travelers walk to waiting Rover.
[N] Landing Site
N1
Cargo Lander lands on the landing pad.
N2
Cargo Rover docks with the Cargo Lander to exchange payloads.
N3
Space Elevator lands at another landing pad.
N4
A Piloted Rover meets the travelers at the Space Elevator landing pad.
[O] Mass Driver
O1
A Cargo Rover delivers payloads to the mass driver.
O2
Mass Driver accelerates payload to launch into orbit.
O3
Cargo Transfer Vehicle catches the payloads in orbit.
[P] Mobile In-Situ Resource Utilization (ISRU) Plant
P1
Mobile ISRU plant traverses to a site specified by Exploration Hopper.
P2
Mobile ISRU transmits status of processing regolith.
P3
Mobile ISRU traverses to the Warehouse.
P4
Mobile ISRU transfers payload to the Warehouse.
[Q] Piloted Lander
Q1
Piloted Lander separates from Piloted Spacecraft.
Q2
The Piloted Lander lands on the Landing Pad.
Q3
The Piloted Lander launches from the Landing Pad.
Q4
Piloted Lander docks with the Piloted Spacecraft.
27
[R] Piloted Spacecraft
R1
Piloted Spacecraft separates from the Piloted Lander.
R2
Piloted Spacecraft docks with the L2 Observation Outpost.
R3
Piloted Spacecraft separates from the L2 Observation Outpost.
R4
Piloted Spacecraft docks with the Piloted Lander.
[S] Piloted Rover
S1
Piloted Rover Traversal Path 1: Between Habitat and Warehouse.
S2
Piloted Rover Traversal Path 2: Between Landing Pad and Habitat.
S3
Piloted Rover Traversal Path 3: Between Habitat and Asteroid Detection.
S4
Piloted Rover Traversal Path 4: Between Habitat and Propellant Plant.
[T] Propellant Production Plant
T1
Production Plant transmits status of propellant production.
T2
Production Plant receives regolith from Hauler.
T3
Production Plant exchanges payloads with Cargo Rover.
[U] Solar Particle Event Early Warning System
U1
Early Warning System transmits all-clear status.
U2
Early Warning System transmits warning if a solar event occurs.
[V] Solar Power Farm
V1
Solar farm transmits status of power generation and energy storage.
V2
Solar farm transmits power to Habitat and Warehouse.
[W] Solar Power Satellite (SPS)
W1
The SPS transmits status on power generation and energy storage.
W2
The SPS transmits power to the Surface Rectenna.
[X] Surface Rectenna
X1
Surface Rectenna transmits status of power reception and energy storage.
X2
Surface Rectenna transmits power to Asteroid Detection Facility.
[Y] Warehouse
Y1
Piloted Rover docks with Warehouse so Astronauts can get supplies.
Y2
Warehouse transmits status of power and supplies.
Y3
Cargo Rover docks with Warehouse to exchange payloads.
28
start 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 55% 60% 65% 70%
[A] Asteroid Detection Facility
[B] Astronauts
[C] Automated Cargo Lander
[D] Autonomous Cargo Rover
[E] Cargo Launch Vehicle
[F] Cargo Space Transfer Vehicle
[G] Communications Satellites
[H] Diggers
[I] Exploration Hopper
[J] Habitat
[K] Haulers
[L] Space Observation Outpost
[M] L2 Space Elevator
[N] Landing Pad
[O] Mass Driver
[P] Mobile ISRU Plant
[Q] Piloted Lander
[R] Piloted Orbiting Spacecraft
[S] Piloted Rover
[T] Propellant Production Facility
[U] Solar Particle Event EWS
[V] Solar Power Farm
[W] Solar Power Satellite
[X] Surface Rectenna
[Y] Warehouse
75% 80% 85% 90% 95% end
A1
A2
B1
B2
B3
C1
B4
C2
D1
E1
D5
E2
F1
F3
G1
B5
C4
D4
D3
C5
E3
F2
G2
H2
H1
I1
C3
D2
F4
G3
G4
H3
I2
I3
J1
J2
K1
L1
K2 K3
K4
L2
L3
M1
M2 M3
N1
P1
Q1
R1 R2
P2
Q2 Q3 Q4
R3 R4
S1
N2 N3 N4
O1
P3
O2
S2
S3
T2
P4
T1
U1
O3
S4
T3
U2
V1
V2
W1
X1
Y1
W2
X2
Y2
Appendix F Glossary
Aitken Basin - The South Pole–Aitken basin is a huge impact crater on the far side of
Earth's Moon. Roughly 2,500 kilometres (1,600 mi) in diameter and 13 kilometres (8.1
mi) deep, it is one of the largest known impact craters in the Solar System. It is the
largest, oldest and deepest basin recognized on the Moon.[1] This moon basin was named
for two features on opposing sides; the crater Aitken on the northern end and the southern
lunar pole at the other end. The outer rim of this basin can be seen from Earth as a huge
chain of mountains located on the lunar southern limb, sometimes called "Leibnitz
mountains", although this name has not been considered official by the International
Astronomical Union.
Barycentric – The barycenter is the point between two objects where they balance each
other. When two or more celestial bodies orbit each other, the barycenter is the center of
mass. When a moon orbits a planet or a planet orbits a star, both celestial bodies are
actually orbiting around a point that is not at the center of the primary, i.e., larger body.
Rectenna - A rectenna is a rectifying antenna, a special type of antenna that is used to
convert microwave energy into direct current electricity. They are used in wireless power
transmission systems that transmit power by radio waves. A simple rectenna element
consists of a dipole antenna with an RF diode connected across the dipole elements.
29
Y3
Since the 1970s, one of the major motivations for rectenna research has been to develop a
receiving antenna for proposed solar power satellites, which would harvest energy from
sunlight in space with solar cells and beam it down to Earth as microwaves to huge
rectenna arrays. The largest current use of rectennas is in RFID tags, proximity cards and
contactless smart cards, which contain an integrated circuit (IC) which is powered by a
small rectenna element. When the device is brought near an electronic reader unit, radio
waves from the reader are received by the rectenna, powering up the IC, which transmits
its data back to the reader.
Regolith - a layer of loose, heterogeneous material covering solid rock. It includes dust,
soil, broken rock, and other related materials and is present on Earth, the Moon, some
asteroids, and other terrestrial planets and moons.
Space Exploration Architecture References
J. F. Connolly, R P. Mueller and R.J. Whitley
NASA Human Spaceflight Architecture Team Lunar Destination Activities
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20120008749_2012008446.pdf
RESOLVE MISSION ARCHITECTURE FOR LUNAR RESOURCE PROSPECTING AND
UTILIZATION. 43rd Lunar and Planetary Science Conference (2012)
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20120003304_2012003481.pdf
A Summary of NASA Architecture Studies Utilizing Fission Surface Power Technology
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20110008828_2011009415.pdf
Surface Buildup Scenarios and Outpost Architectures for Lunar Exploration
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20090012432_2009012393.pdf
30