Developing Responsive and Agile Space Systems - Space-Library

Kirk Nygren and Lisa Berenberg with the Nanosat-2 payload mated to the
Demosat as it is prepared for launch on the Delta IV heavy demo vehicle.
A more agile approach incorporates innovative
design practices on both the spacecraft
and launch vehicle sides of the interface.
Designing and testing a spacecraft to
levels that envelop multiple spacelift options
would provide more flexibility in launch
manifesting. For example, Nanosat-2 had
been tested to space shuttle requirements,
giving confidence that it could survive on
the EELV Delta IV heavy. SAPPHIRE
was designed and tested to be compatible
with almost any potential launch option.
Changes to Spacecraft Systems
STP has embraced this new paradigm in
the procurement of the so-called Standard
Interface Vehicle—essentially a generic
spacecraft bus with a standardized payload
interface. The Standard Interface Vehicle
contract was for the purchase of up to six
space vehicles that would be compatible
with five different launch vehicles—the
Minotaur I and IV, Pegasus, and the Delta
IV and Atlas V ESPA. This allows for “next
available opportunity” manifesting.
Designing a spacecraft to multiple
launch vehicle standards allows it to be
built and “put on the shelf.” The approach
is clearly feasible: two of the four satellites
on the Kodiak Star
mission (SAPPHIRE
and PICOSat) and the
Nanosat-2 spacecraft
were complete and ready
for the next available
launch opportunity.
Still, there are drawbacks
to this “satelliteon-the-shelf
” approach,
such as component
degradation, continuous
testing requirements, and
technology obsolescence,
to name a few. To combat
these issues, the Air Force
Research Laboratory has
come up with an innovative
spacecraft design and
manufacturing concept
known as plug-and-play.
Analogous to the home
personal computer, where
all the components fit
together regardless of the
manufacturer through
the use of a common
interface (the USB, or
universal serial bus), the
plug-and-play satellite
program has developed a
standard interface for all
the avionics on the bus.
Through the use of this interface, components
can be kept on the shelf, and by using
a dedicated space-vehicle integration facility,
a unique satellite that meets mission requirements
can be designed and assembled
in six days.
Changes to Launch Systems
Once the issue of standardization of physical
interfaces is resolved, additional changes
to launch-vehicle systems will be required
to meet the six-day launch goal. As with
satellites, one way to meet the six-day goal
is to build the launch vehicle and then place
it in storage to await a payload. Drawbacks
to this concept are not hard to imagine,
including the significant investment in explosive
storage requirements and the testing
and component life issues similar to those
of the satellites. However, even with this
stockpiling of launch vehicles, numerous
preparations remain, such as the development
of the flight software to fly the correct
trajectory to the correct orbit, analysis
of coupled loads to ensure no structural
coupling between the satellite and launch
vehicle, and development of guidance and
control algorithms, to name a few.
These preparations currently must be
done serially, starting with coupled loads
analysis, then guidance and control, and
then flight software; the process takes about
three months. The introduction of automated
software development tools could
bring this cycle time down to days, and is
absolutely necessary for the ORS Office to
meet its goals.
Changes to Launch Range Infrastructure
The last piece of the launch timeline, and
the one that has not been addressed by any
missions to date, is that of range infrastructure—specifically
in the area of flight safety.
The range infrastructure required to launch
national space systems is very extensive;
thus, in the United States there are only two
ranges that launch national security space
missions—Cape Canaveral in Florida and
Vandenberg in California. One way to limit
the range interface timeline would be to remove
a mission from the range, but though
that may save some time in the areas of
ground interfaces, flight safety must always
be ensured. Studies in this area are in their
infancy, and the conclusions of these studies
will be reviewed carefully.
Agile Space—A Multifaceted
Issue
The three military offices at Kirtland Air
Force Base in New Mexico—STP, the Air
Force Research Laboratory, and the ORS
Office—are working together to define
solutions to the ORS goal of a six-day mission
timeline. The concept of agile launch
implies it is not a single mission component
that will meet this ambitious goal, but
rather a collection of innovations across all
mission components—spacecraft, launch
vehicles, and launch ranges—and across all
engineering disciplines—mechanical and
electrical interfaces, software, and systems
engineering.
In supporting all of these offices, Aerospace
is uniquely positioned not only to
ensure coordination across the effort, but
to help define the architecture of the effort.
Various government and industry organizations
have been considering components of
agile launch for years, but the ORS mission
has only been codified for two years; so, the
effort is really in its infancy. In the future,
the ORS Office may transform some of
the tenets of agile launch discussed in this
article into flight demonstrations, and when
that happens, it may well revolutionize
the way space missions are conceived and
executed.
Crosslink Summer 2009 • 23