Robust Satellite Emulator
Roy L. Hayes, Jr., Geoff R. Becker, Yusuf K. Celik, and Gerard P. Learmonth Sr.
Abstract- The Defense Advance Project Research
Agency is funding the development of Rapidly
Reconfigurable Intelligent Fractionated Satellite
Constellation (RRIFSC). RRIFSCs are
constellations of satellites where the functionality of
a single traditional spacecraft (satellite) is
distributed among wirelessly-interconnected
orbiting spacecrafts (satellites) components. The
University of Virginia (UVA) is aiding in this
endeavor by creating an emulator capable of
modeling a wide range of satellite constellations,
including RRIFSC. This paper describes an
emulator created at UVA that is robust enough to
accurately model a wide range of satellite networks,
including networks that are comprised of different
types of orbits. Furthermore, this paper highlights
the shortfalls in pervious satellite emulators and
illustrate the advantages of UVA’s satellite emulator
and its’ benefits to the end user.
Introduction
Flaws in Current Satellite Constellations
Since the launch of Sputnik 1 there has been a
constant push to continuously improve satellite
technology. However, as satellite technology improves
the cost of designing, developing, and launching
satellites increases. Furthermore, the added complexity
increases the length of the design and development
phases. Therefore implemented satellite technology lags
behind current satellite technology.
An illustration of increasing cost and complexity is
the new Wideband Global Satellite Communication
Constellation (WGS) which is schedule to be complete
by 2012. It provides the United States military with
bandwidth between 1-10 Gbps, at an estimated cost of
1.8 billion dollars. If the current rate of technological
development continues by 2020 it will be possible to
design a satellite constellation with significantly higher
bandwidth. However, the investment in WGS will
discourage the United States from funding a satellite
constellation with this capability. A major problem in
the field of satellite design is how to reduce the cost and
time it takes to design and develop a satellite.
(Mecham)
Historically, satellites have been designed as a
transport medium that perform telecommunication task,
collect data through various sensors, and download data
received to an earth based facility for processing. These
facilities then transmit the data to the requester of service.
Although this is always the preferable option it is not
always feasible. In the event that terrestrial
telecommunication infrastructure is damaged or not
available an end users should still be able to access
satellite assets. For, example, when fighting a
wildfire, it could be advantageous for the firefighters
to have an aerial view of the fire. However, if the
fire has damaged terrestrial telecommunication
infrastructure, such as the telephone line, receiving
satellite imagery from an earth based facility may be
impossible. Therefore, the next generation of
satellites must be able to send information directly to
the end user.
To accomplish the goal of direct end user
communication general purpose data processing,
such as customization of the data to match an end
user’s telecommunication capabilities, must be
implemented on space based platforms.
Proposed Solution to Current Limitations
In July 2007, the Defense Advance Project
Research Agency (DARPA) unveiled the F6
program, which will create a Rapidly
Reconfigurable Intelligent Fractionated Satellite
Constellation (RRIFSC). The program goals are
to “demonstrate the feasibility and benefits of a
satellite architecture wherein the functionality of a
traditional (“monolithic”) spacecraft is replaced by
a cluster of wirelessly-interconnected spacecraft
modules. Each such (“fractionated”) module can
contribute one or more unique capabilities (e.g.,
command and data handling (C&DH), guidance
and navigation, payload sensor, payload
transponder, etc.)…” (System F6 BAA).
In this configuration a single traditional
satellite is decomposed into wirelesslyinterconnected orbiting spacecraft components;
specific components, such as the guidance and
navigation module, can be replaced with out
needing to create an entirely new satellite. This
capability will decrease the cost and time of
developing and implementing satellite components.
Additionally, RRIFSC design concept helps
alleviate some of the complexity of creating a
monolithic satellite by allowing components to be
created in stages and integrated with critical
systems either before or after critical systems have
been launched. This permits a satellite constellation
to be funded and implemented in phases, which
will mitigate the risk by allowing for more accurate
scheduling and budgeting.
The RRIFSC system will be able to complete
autonomous data processing task. One data processing
task could be processing raw data and transmitting it
directly to the end user. Currently satellites transmit
raw data to terrestrial based facilities. These facilities
processes data and send it to the end user over a
terrestrial based infrastructure. However, this increases
latency because the transfer of data is limited to when a
satellite is above a terrestrial facility, with specialized
software and staff capable of performing data
processing. Additionally, for a set of end users it is
impossible to receive data over a terrestrial base
infrastructure. By implementing data processing in
space it will become possible for soldiers, first
responders, and researchers to have access to timely
information in the most hazardous and remote areas of
the world.
The Advantages of Emulation
There are several methods to test this new system.
Historically during the developmental phase, a
completely integrated prototype of the system was
created, which was a time consuming and multi-million
dollar endeavor. The prototype phase was eliminated
from a number of spacecraft development cycles,
decreasing cost, but increasing risk of an integration
failure. Thus simulations were created to test and
validate systems. While the use of simulations is cost
effective and quick, it is not always reliable. The lack of
reliability comes from assumptions about the system
that must be made in order to model it, such as
hardware or software parameters (Hendricks, 2005).
A viable alternative is an emulator, a program
composed of hardware and software components that
imitate a system’s real world characteristics.
Additionally, actual software and hardware components
of the designed satellite can be implemented into the
emulation to reduce assumptions and increase accuracy.
The emulator proves to be cost effective as it replaces a
prototype by integrating real system constraints such as
delays.
On December 11, 1998 the Mars Climate Orbiter
(MCO) was launched. Its objectives were to, “orbit
Mars as the first
interplanetary weather satellite and provide a
communications relay for the Mars Polar Lander”.
Unfortunately the MCO was destroyed in the
atmosphere of Mars, after a unit conversion error
caused it to enter orbit approximately 170 kilometers
lower than planned. An emulation of the MCO could
have prevented this mistake. Data passed through an
emulated MCO, which incorporated the software of the
MCO, would have highlighted the unit conversion
mistake and saved the United States tax payers millions
of dollars.
Hayes
Historical use of Emulators
The use of emulations has been well
documented in design and validation of satellite
networks. In 2001, Pooja Wagh at the University
of Kansas designed an emulator for Earth
Observing Satellites (EOS). Like the F6 program’s
RRIFSC EOS are in low earth orbits. Satellites in
low earth orbit are challenging to emulate because
they have a high bandwidth and low data packet
transfer latency. If the emulator is not efficient, the
computing overhead associated with imposing
constraints on the system may cause data collected
on latency and throughput to be skewed. In the
Wagh emulation, all data passed between nodes
(simulated satellite and ground stations) were sent
to a traffic shaper. This piece of software queues
the packets and delays them by their simulated
delay time. There could be any number of traffic
shapers instances allowing for heavy traffic across
the network and allowing for the emulator to
operate with out skewing the results. There are
several drawbacks to Wagh emulator. It does not
incorporate bit error rate and it is limited to running
on computers using the Linux operating system.
This limitation of running on a specific operating
system is significant because it hinders the
portability and the scalability of the system. The
reliance on a specific operating system limits the
resources
people can use to run the emulator (Wagh, 2001).
In 2002 the Italian National Consortium of
Telecommunications (CNIT) embarked on creating
an emulation of a satellite network. Their emulator
was able to incorporate bit error rate but was not
able to emulate low earth orbit satellites. The
CNIT emulate emulated a geostationary satellite.
The satellite network’s primary purpose was to
deliver wide band Internet service.
The CNIT emulator is comprised of computers
acting as ground stations, geostationary satellites,
and dedicated statistical recorders. These
computers are connected via Ethernet cable. All
communications pass through one traffic shaper
where bandwidth restrictions, delay time, and jitter
in the satellite network is applied. It can be
expanded to multiple satellites, multiple ground
stations, and multiple configurations of satellite
protocols due to the modular construction of the
emulation software. The emulator applicability is
limited by computer processing speed. It takes
longer to calculate and apply communication
delays for low earth orbits that it does to transmit
data in low earth orbits. Since the CNIT emulator
operates strictly in real time the processing
limitations can not be overcome. Moreover the
2
emulator only works on the Linux operating system
(Albertengo, 2002).
In 2005, Shaun Endres presented an emulator that
he designed for deep space satellite system that
improved on several key areas of previous emulators.
Unlike the Italian emulator, Endres’s emulator has a
distributed architecture. That meant, like Wagh’s
emulator, there were multiple traffic shapers allowing
for heavier traffic in the system. Each traffic shaper is
updated by a centralized coordination system that
calculates the current network
parameters. This lessens the amount of processing
required by the traffic shapers; moreover, a
coordination system which determines network
parameters such as communication delay, is run before
the emulation is started. This increases the efficiency
of the emulator and allows the emulator to operate in
real time (Endres, 2004).
To find reliable communication delay times, a
software package named Satellite Tool Kit (STK) was
incorporated into Endres’s emulator. This commercial
software package allows a user to specify orbits of
satellites and locations of ground stations; it can also
determine communication parameters between the
objects the user specifies.
In Endres’s emulator, data packets are captured
before they are sent to the operating system. This
allows for the emulator to be independent of the
operating system, thereby increasing the portability of
the system. There are also a few draw backs to
Endres’s emulator. Since it operates in real time, not all
networks can be emulated. Given that the RRIFSC will
have high bandwidth and rapidly changing network
topology Endres’s emulator can not be directly applied,
due to the overhead associated with the emulator.
Furthermore, The emulator was written in C# meaning,
it can only run on the Window Operating System
(Endres, 2004). These drawbacks led to a University of
Virginia System Engineering Capstone.
In 2007, a University of Virginia System
Engineering Capstone team created a proof of concept.
They modified Endres original design to illustrate its
applicability to Low Earth Orbiting Satellites. However
they did not solve the two underlying problems with
Endres emulator. Since their implementation is written
in C# it can only run on the Window Operating System.
Moreover, they were not able to remove the overhead
associated with the Emulator (Cleaves, 2008).
Therefore, a new emulator was created with the
objective of being robust enough to accurately model a
wide range of satellite constellations, including
RRIFSCs.
Emulator Design
Overview of the Emulator
The emulator created at the UVA, built upon
previous research, it implemented a modular
programming methodology (Bergland) and service
oriented architecture (He). This allowed the
emulator to both accurately model a wide range of
orbital network configurations, and implement user
defined routing and networking protocols. This
methodology also made the integration of user
created software and hardware into the emulator
possible.
The emulator is written in Java and since Java
can run on many different operating systems it is
ideal from a portability and scalability stand point.
However, Java has a slower processing speed than
many other programming languages, which adds
more overhead to the Emulator. To combat this
limitation, a distributed architecture was
implemented, where each node has its own traffic
shaper. This allows for faster processing than a
centralized architecture. A distributed coordination
system is utilized in the emulator. Each
coordination system queries STK for the network
parameters of a specific emulated object for the
entire emulated scenario before the emulator is
initialized. The traffic shapers are updated
periodically on the network topology.
Components of the Emulator
As in integral part of the system’s modular
programming design, Hypercast, a Java overlay
networking library, handles the communication
between emulated objects both within a single
computer system and over the Local Area
Network. Hypercast is used for its ability to form
overlays and to communicate any data object as a
byte structure. A visual representation of the
system design in below.
Figure 1: System Architecture
Hayes
3
The STK, Routing Table, and Database components
assist in the passing of data between emulated objects,
while Applications perform the requested services. A
user interfaces with the emulator through the GUI.
Below are brief descriptions of each emulator
component.
Emulator
The main body of the emulator is a collection of
custom Java applications and is the systems main
control and storage structure. Each ground station or
satellite in the emulator is composed of three layers:
Logical Node Layer, Emulated Device Layer, and
Service Layer, which is illustrated in figure 2. These
layers form the basis of the emulator’s modular design
architecture.
Figure 2: Emulator Architecture
The classes and methods in the logical nodes use
Hypercast to transfer data packets (byte streams)
between emulated objects, each of which are
represented by a single node. The logical nodes on the
LAN collectively form the overlay network, with each
node given a unique logical address. Each node can
send and receive data with any other node, given the
destination’s logical address. This layer is also where
the traffic shaper is located. Thus, bit error rate and
propagation delays are imposed at the logical layer.
The routing tables are used to ensure that the path
of data through the system is properly traversed. The
logical layer is able to pass any data in the form of
bytes and can break large data streams into smaller
packets. However, it neither converts data objects, such
as images, into byte packages nor reconstructs them
after receipt.
The service layer has several functions. The
first is converting data objects into byte packages
for transmission and reconstructing these data
objects once they are received. Since a service
request may have multiple files and data objects,
the service layer must sort incoming information
and store it appropriately. The second function the
service layer provides is fulfilling service request.
The service layer is the only portion of the
Hayes
emulator which interacts with applications. All that
is required to interface with a new application is an
overlay network connection or socket connection
to that application. Therefore, the passing of data
between emulated objects is independent of what
that data represents or how it is manipulated.
The Emulated Device Layer serves to connect
the service layer and logical node layer to a single
emulated device such as a satellite our ground
station.
Satellite Toolkit
AGI’s Satellite Toolkit (STK) is a software
package validated by NASA, which is capable of
modeling, simulating, and analyzing satellite
constellations.
Additionally, STK can model
components such as
orbital parameters,
communication chains, geographic positions, and
remote sensor swath coverage through simulation
scenarios. Scenarios can include satellites, targets,
transmitter/receivers, and terrestrial users. STK
can model all ranges of satellite orbits, which
allows for the required flexibility in constellation
design. STK is also capable of generating a large
number of analysis reports from which routing and
communication information between emulated
objects can be extracted.
Routing Tables
The purpose of the routing tables is to
determine the intermediate satellites that must be
used for one emulated object to send a message to
another. These tables are computed by STK using
its communications chains functions. Since these
tables are prepared before the emulation begins,
they use a significant amount of system memory.
Although computing routing “chains” while the
emulator is operating would reduce memory load,
it would increase processing time due to the
complexity of such algorithms, making this option
infeasible given the emulator runs in real time.
Database
Each emulated object’s logical layer has a
unique logical address which identifies it in the
Hypercast overlay network. In order to pass data
from one emulated object to another, the
destination logical address must be acquired. A
centralized database stores the logical address
associated with each emulated object.
After
accessing the routing tables to determine the next
transmission hop, the emulated object then
retrieves the correct logical address from the
database using the destination object’s name as a
4
lookup reference. Data packets can then be sent
between two emulated objects.
It is conceivable that not all satellites in a
constellation will have the same processing abilities,
remote sensors, or roles within the system.
Additionally, certain satellites may only collect or
process data, while other satellites can be charged with
managing specific requests. The database stores the
roles of each emulated device and services it can
perform. Therefore, emulated objects can determine
which specific satellite can accomplish the service
requested.
Applications
The service oriented architecture of this system
allows for any number of data processing applications
to interface with emulator through the service layer.
Furthermore, through the use of service oriented
architecture the various services that are implemented
in the emulator can be connected to complete tasks.
Thus, a service that determines if a vehicle is a car can
be connected to an image capturing service. In this way,
chains of services can be created to perform larger
applications. This allows for modular design of services,
enabling independent modification of each service.
Results / Analysis
In order to test the emulator, ten trials of four
different scenarios were run, each with a constellation
comprised of a different orbit. The orbits consisted of
geostationary (GEO), high earth orbit (HEO), medium
earth orbit (MEO), low earth orbit (LEO). Theoretical
values of delay between emulated objects are acquired
from Satellite Toolkit (STK), a commercial software
verified by NASA, the values were compared with
results gathered from the emulator. The data was
analyzed to determine functionality and validity of the
emulator.
The comparison of the theoretical and experimental
values indicated that minor discrepancies between the
emulator and real world conditions exist. Ten trials
were conduct on each scenario and the data gathered
from the experimentation is shown in Table 1 of the
Appendix. The following chart summarizes the results.
Orbit
Type
(Altitude)
Average
Packet
Experimenta
l Delay
(seconds)
Theoretical
Packet
Delay
(seconds)
Discrepancy
(seconds)
GEO
(36,000
km)
HEO
(20,000
km)
MEO
(10,000
km)
LEO
(750 km)
0.139 s
0.135 s
0.006 s
0.064 s
0.067 s
0.005 s
0.035 s
0.034 s
0.005 s
0.016 s
0.004 s
0.013 s
The average experimental delay is the average
of the delay between emulated object of each
individual trial, while the discrepancy is the
average of the time difference between the
theoretical and experimental for
each individual trial. As such, the discrepancy
serves as an error rate for the emulator.
The discrepancies experienced for the majority
of satellite constellations is less then 6 milliseconds.
However, the discrepancies experienced for
constellations in LEO orbit are significantly higher
at 13 milliseconds. STK suggest in LEO orbit
seven transmissions between objects is necessary
to send a signal halfway around the world. Thus
the maximum difference between the theoretical
and experimental delay for this signal transmission
will be 0.2 seconds, while the average difference
between the theoretical and experimental delay will
be 0.09 seconds. For a satellite system that
performs services other than data transmission
alone, these discrepancies will be orders of
magnitude smaller than the delays experienced by a
satellite system performing the services. Therefore,
for real world applications these discrepancies are
negligible. Accordingly the emulator proves to be a
functional and cost effective system to evaluate
real world satellite constellations.
Conclusions
The objective of this research project was to
create a satellite emulator capable of accurately
modeling a wide range of satellite constellations.
Additionally, the emulator had to be modular
enough to be expanded and altered to user
specification. As illustrated by the above results,
the satellite emulator developed at the UVA
accomplishes both objectives while maintaining a
high degree of accuracy.
Hayes
5
The emulator is programmed in Java and
experimentation suggested Java’s internal clock will not
apply delays less than 15 milliseconds. As Java’s
internal clock and computer processing improves,
the accuracy of the emulator will improve
proportionally. However, in real world applications this
discrepancy is negligible for satellite constellations that
perform services other than data transmission alone. For
these satellite constellations, this emulator is a cost
effect manner of satellite development.
A one time investment in Satellite Toolkit and
other necessary hardware and software components
needed to support the emulator is approximately
$100,000. As this is a modifiable system, the one time
investment far out weighs the cost of multi-million
dollar prototype construction for each satellite.
Thus
the emulator can combine the cost effectiveness of a
simulation while retaining the accuracy of a fully
functional integrated prototype.
With the established validity of the emulator,
further studies can focus on testing a variety of
scenarios to gather more data. This data will be used to
develop algorithms, protocols, satellites, and satellite
constellations. The emulation test bed is the first step in
an on going research endeavor at the UVA. Algorithms,
protocols, satellites, and satellite constellations
designed at the UVA may someday play a major role in
a new breed of satellite constellations
Bibliography
Albertengo, Guido., & Petroianni, Stefano. (2002). On
the emulation of geostationary earth orbit
satellite. Paper Presented at the IEEE Seventh
International Symposium on Computers and
Communication, Taormina, Italy.
Bergland, G, (1981). A Guided Tour of Program
Design Methodologies, IEEE Computer,
14(10), 13-37.
Cleaves, D.W., & Berbert, T.L., & Im, B.Y., &Yeung,
D. W., & Learmonth, G.P. (2008). Design of a
simulation environment for space-based
information management and distribution.
Paper presented at IEES Systems Engineering
Design Symposium, University of Virginia,
Charlottesville, Va.
Defense Advance Research Project Agency. (2007).
System F6 for Defense Advance Research
Project
Agency
(Broad
Agency
Announcement BAA07-31).
He,
Hao ., “What is Sevice-Oriented
Architecture.” Retrieved 3/30/09
http://pesona.mmu.edu.my/~wruslan/SE2/
Readings/detail/Reading-28.pdf
Hendricks, Reinhard., & Eickhoff, Jens., (2005).
The significant role of simulation in
satellite development and verification.
Aerospace Science and Technology, 9(3),
273-283
Marchese, Mario., & Perrando, Marco., (2002). A
packet-switching satellite emulator: a
proposal
about
architecture
and
implementation. Paper presented at the
IEEE International Conference on
Communications.
NASA, Mars Climate Orbiter Mishap Investigation
Board Phase I Report. November 10, 1999.
Wagh, Pooja. (2001). Design for a satellite
communication link in a space based
internet emulation system [PowerPoint
slides]. Retrieved 3/30/09
http://www.ittc.ku.edu/research/thesis/doc
uments/pooja_wagh.pdf
Waldrop, Elizabeth., (2003). Integration of
Military and Civilian Space Assets: Legal
and National Security Implications.
Thesis McGill University, Montreal 2003
Endres, Shaun ., (2004). Simulation and emulation
of the space networking environment.
Unpublished master’s thesis, Case
Western Reserve Ybuversuty, Cleveland,
Ohio.
Mecham, Michael, (2008) “The Growing Appetite
for Military Satcom” Aviation Week &
Space Technology, 169(20), 44-46
Cynamon, Major Charles H., Protecting Commercial
Space Systems: A crictical National Security
Issue. Maxwell AFB, AL, April 1999.
Hayes
6