Non-Traditional Flight Safety Systems & 

Integrated Vehicle Health Management Systems

Descriptions of Proposed & Existing Systems and

Enabling Technologies & Verification Methods

Final Report

Produced for:

The Office of the Associate Administrator for Commercial Space Transportation, 

Federal Aviation Administration

Section AST-300

Produced by:

Michael Fudge

Thomas Stagliano

Sunny Tsiao

ITT Industries, Advanced Engineering & Sciences Division

2560 Huntington Avenue

Alexandria, Virginia 22303

Contract DTFA01-01-D-03013

Delivery Order #3

August 26, 2003
i
EXECUTIVE SUMMARY

This paper describes present and future flight safety systems (FSS) and integrated vehicle 

health management (IVHM) systems relevant to reusable launch vehicle (RLV) design 

and operation.

FSS design and implementation for RLVs in the launch-regime will be based mainly 

upon the evolving flight safety infrastructure presently utilized for expandable launch 

vehicles (ELV)s and the Space Shuttle. The evolution towards a more autonomous

“space-based” range is the most significant issue within the RLV launch-phase flight 

safety paradigm, and the ability to confidently use Global Positioning System (GPS) 

receivers on both ELVs and RLVs to conduct real-time vehicle tracking and trajectory 

assessment is the key enabling technology towards this vision. Experiments utilizing 

sounding rockets to test this technology are currently ongoing.

A flight safety paradigm for RLVs in the post-reentry phase of operations (atmospheric 

powered or gliding-flight ) is postulated in this paper; it is based upon current Unmanned 

Aerial Vehicle (UAV) flight safety practices and designs. The emphasis in this paper is 

placed upon flight safety for uncrewed RLVs; however, pertinent post-reentry flight 

safety issues and possible system operations for crewed RLVs are also addressed. 

Specific vehicle systems comprising or interacting with vehicle-based FSS which will be 

of concern during licensing activities include:

• command & control link

• command & control software

• flight control systems

• structure

• guidance & navigation (G&N)

• propulsion & fuel

• thermal protection/thermal control

• vehicle recovery system (VRS)

IVHM systems can be divided into post-flight IVHM, which is used for vehicle 

maintenance purposes, and in-flight IVHM, which is diagnostic and prognostic in nature 

and is also connected closely to autonomous vehicle operations.

Post-flight IVHM has been evolving for over 30 years within the field of commercial 

aviation. The present state-of-the-art, as found on the Boeing 777, allows a technician to 

determine what sub-system or component is responsible for a fault using (basically) only 

the system on-board the aircraft itself. RLVs, including the partially-constructed Kistler 

K-1, plan to use these systems to determine when maintenance should be performed on 

certain vehicle systems or components. NASA conducted IVHM experiments on STS-95 

and STS-96; these experiments were mainly for post-flight IVHM systems but could also 

have applicability to in-flight systems. AST will have to understand and approve the 

algorithms and methods used by post-flight IVHM maintenance-centric systems as part 

of its licensing responsibilities.
ii

Complex in-flight IVHM systems are still very much in the research phase. NASA has 

conducted research and flown an IVHM experiment on the Deep Space One spacecraft. 

The experiment allowed a model-based reasoning system to autonomously control the 

spacecraft for a number of hours; most of the objectives were achieved, however, at one 

point, the system locked-up and had to be re-started via ground command. A simple inflight IVHM system is being used by what may be the world’s first true RLV, Scaled 

Composites’ SpaceShip One. The system shuts down the hybrid rocket motor in case of

burn-through. AST will have to carefully examine the complexity, intended use, 

capabilities, and testing history of future in-flight IVHM systems, as part of its licensing 

responsibilities.
iii

Table of Contents 

Executive Summary...................................................................................... i

List of Figures............................................................................................... v

1.0 Introduction................................................................................................... 1

1.1 RLV and X-Prize Background...................................................................... 2

1.2 Concerning Verification Methods................................................................ 3

2.0 Non-Traditional Flight Safety Systems........................................................ 5

2.1 Description of Existing and Proposed Designs for Non-Traditional FSS.... 6

2.1.1 Range-Centric Non-Traditional FSS............................................................ 7

2.1.1.1 Flight Safety Systems Methodologies.......................................................... 7

2.1.1.1.1 Flight Safety System Methodology #1: Range-Containment FSS............... 7

2.1.1.1.2 Flight Safety System Methodology #2: Flight Destruct Systems (FDS)...... 8

2.1.1.2 Evolution of Existing Launch Vehicle FSS.................................................. 9

2.1.1.2.1 Tracking & Surveillance............................................................................... 9

2.1.1.2.2 Telemetry...................................................................................................... 10

2.1.1.2.3 Command & Control.................................................................................... 10

2.1.1.2.4 Other Areas................................................................................................... 10

2.1.2 Vehicle-Centric Non-Traditional FSS.......................................................... 11

2.1.2.1 UAV Types................................................................................................... 11

2.1.2.2 Vehicle-Centric Flight Safety System Methodologies................................. 13

2.1.2.2.1 Methodology #3: Flight-Safing.................................................................... 13

2.1.2.2.2 Methodology #4: Thrust Termination.......................................................... 14

2.1.2.2.3 Methodology #5: Flight Termination System (FTS) / Vehicle Recovery 

System (VRS)............................................................................................... 16

2.1.2.3 Collision Avoidance..................................................................................... 17

2.1.2.4 FSS and Humans on-board an RLV............................................................. 17

2.2 Description of Enabling Technologies and Verification Methods for NonTraditional FSS............................................................................................. 18

2.2.1 Enabling Technologies and Verification Methods for Range-Centric FSS.. 18

2.2.1.1 Tracking and Surveillance............................................................................ 18

2.2.1.1.1 GPS-Based Metric Tracking......................................................................... 18

2.2.1.1.2 Low-Power Transceivers.............................................................................. 20

2.2.1.1.3 Mobile Range Platforms............................................................................... 20

2.2.1.1.4 Other Enabling Technologies within Tracking and Surveillance................. 20

2.2.1.2 Telemetry...................................................................................................... 21

2.2.1.3 Command & Control (C&C)........................................................................ 22

2.2.1.3.1 Automated FTS............................................................................................. 22

2.2.1.3.2 Automation and Evolution of Range C&C Systems.................................... 23

2.2.1.4 Other Areas of Interest.................................................................................. 23

2.2.2 Enabling Technologies and Verification Methods for Vehicle-Centric 

FSS................................................................................................................ 23

2.2.2.1 Vehicle Command & Control Link.............................................................. 24

2.2.2.2 Vehicle Command & Control Software....................................................... 24

2.2.2.3 Vehicle Flight Control Systems and Vehicle Structure............................... 25
iv

2.2.2.4 Vehicle Guidance & Navigation (G&N)...................................................... 25

2.2.2.5 Propulsion & Fuel......................................................................................... 25

2.2.2.5 Thermal Protection/Thermal Control........................................................... 26

2.2.2.6 Vehicle Recovery System (VRS)................................................................. 26

2.2.2.7 Crew Safety Systems.................................................................................... 26

3.0 Integrated Vehicle Health Management (IVHM) Systems.......................... 29

3.1 Description of Existing and Proposed Designs for IVHM........................... 29

3.1.1 Post-Flight IVHM......................................................................................... 29

3.1.2 In-Flight IVHM............................................................................................ 31

3.2 Enabling Technologies and Verification Methods for IVHM...................... 31

3.2.1 Enabling Technologies and Verification Methods for Post-Flight IVHM... 32

3.2.2 Enabling Technologies and Verification Methods for In-Flight IVHM....... 33

3.2.2.1 Deep Space One Remote Agent Experiment & Livingstone........................ 33

3.2.2.1.1 Deep Space One Overview........................................................................... 33

3.2.2.1.2 Livingstone Description................................................................................ 34

3.2.2.1.3 Specific Deep Space 1 Autonomous Flight Activities................................. 34

3.2.2.1.4 The Deep Space 1 Remote Agent’s Shortcomings....................................... 35

3.2.2.2 X-37 IVHM Experiments............................................................................. 35

3.2.2.3 Virtual Propulsion System Experiment........................................................ 36

3.2.2.4 Intelligent Flight Control.............................................................................. 37

4.0 Summary....................................................................................................... 39

4.1 Re-visiting FSS and IVHM and Future Research Areas Based on this 

Report........................................................................................................... 40

5.0 References..................................................................................................... 43

6.0 Bibliography................................................................................................. 47
v

List of Figures

1. Page 5 - Scaled Composites SpaceShip One (foreground)

2. Page 6 - Canadian Arrow, Pre-Launch and Liftoff

3. Page 11 - BAI’s Exdrone UAV

4. Page 12 – Global Hawk UAV

5. Page 13 – The Aerosonde UAV and its Flightpath across the Atlantic

6. Page 16 - Kistler K-1 First Stage with Parachutes & Airbags Deployed

7. Page 19 - GPS Orion-HD receiver for sounding rocket tracking and IIP prediction

8. Page 30 - SpaceShip One’s System Navigation Unit

9. Page 36 – X-37 Spaceplane 

1.0 INTRODUCTION

Over the past 45 years, the launching of payloads into space – whether on a sub-orbital 

trajectory, into Earth orbit, or beyond – has become a common occurrence. Until 

recently, the launch paradigm, the launch vehicles themselves, and the infrastructure 

which supports launch activities have changed little since their initial evolution in the 

1950s and 1960s.

Likewise, the public safety implications of commercial space-launch activities have 

changed little over the past several decades. Rocket-powered expendable launch vehicles 

(ELVs) ascend from coastal launch ranges, dropping their spent lower stages over broad 

ocean areas and leaving spent upper stages in orbit.

In the case of Western (and Japanese and Chinese) launch systems, the vehicle’s ascent 

was monitored manually using radar and even optical guide systems. [1, 2] Flight safety 

systems (FSS) – more specifically, flight destruct systems (FDS) – are activated 

manually when the rocket-powered vehicles stray from their intended course.

Similarly, Soviet/Russian and Soviet-heritage launch vehicles have not themselves 

evolved greatly since their inceptions. They have, however, followed a different flight 

safety system paradigm, one in which an autonomous thrust-termination system (TTS) 

on-board the launch vehicle turns off the engines if it determines the vehicle is straying 

from its designated trajectory, allowing the vehicle to crash to Earth. [3] 

Furthermore, for all launch vehicles, the extent of vehicle health management has been 

limited to telemetry (or on-board signals in the case of manned, or “crewed” vehicles) 

containing read-outs of a few metrics for key systems or locations (e.g., temperature, 

pressure) or indication of a large component or system failure with interpretation and 

action-taking (if any is possible) left to the crew on-board or to those on the ground. In 

the case of uncrewed launches, the only action to take, usually, is to leave the vehicle 

alone or to command its destruction.

Recent activities, however, indicate that the space transportation paradigm that has been 

relatively unchanged since the dawn of the Space Age is now starting what could be a 

major transformation. A part of the transformation is the progress towards having 

commercial sub-orbital and possibly orbital reusable launch vehicles (RLVs) which will 

make repeated trips to space and back. This report addresses two potentiallytransforming areas of interest to the Federal Aviation Administration (FAA) Office of the 

Associate Administrator for Commercial Space Transportation (AST): non-traditional 

flight safety systems (non-traditional FSS) and integrated vehicle health 

management (IVHM) systems.

The reason for AST’s interest in these advanced systems lies in its charter to protect the 

safety of the public and of property. 
2

• FSS are the very systems which most directly protect the public from off-nominal 

launch vehicle flight – and non-traditional FSS will expand this protection via 

new methods and to vehicles which reenter as well as launch.

• IVHM will form the basis for safe operation of launch and reentry, especially with 

regard to vehicle maintenance and interaction with future non-traditional FSS. 

In keeping within the scope of this study as directed by AST, this report emphasizes

RLV-related issues, but it does not exclude those issues which are also pertinent to ELVs. 

Specifically, this report describes existing and proposed designs for non-traditional FSS 

and IVHM, as well as detailing enabling technologies and verification methods.

1.1 RLV and X-Prize Background

Interest in RLVs reached a very high level in the mid-to-late 1990’s, and several 

companies, both entrepreneurial and established, started preliminary discussions with 

AST concerning their specific vehicle concepts and designs. All of these RLVs shared 

the following characteristics:

• high performance (either orbital {Mach 25} or Mach 12+ capability)

• a primary mission of payload delivery to orbit

Given the drastic decrease in the global satellite launch market since the late 1990s, there 

has been a corresponding decrease in demand for these types of RLVs. However, the 

search for new markets and an entrepreneurial vision have brought forth great interest in 

small sub-orbital RLVs with performance in the Mach 3 to Mach 5 regime. [13]

The entrepreneurial vision is the X-Prize. To win the $10 million prize, a vehicle must, 

by January 1, 2005, accomplish the following mission twice within 14 days: take 3 

people (or 1 person and the equivalent mass) to an altitude of 100 km and then safely 

return to the Earth. Approximately 20 entities have entered the contest to win the XPrize; out of these, there are a few which have built a significant amount of flight

hardware and one (Scaled Composites’ “SpaceShip One”) which is presently undergoing 

unpowered flight testing. The vehicles designed to compete for the X-Prize are RLVs; 

however, they are much smaller and have a great deal less performance than the payloaddeploying RLV concepts of the 1990s. For example, a typical X-Prize design will have 

little or no forward velocity at its 100 km apogee; a typical payload-delivery RLV would 

have a forward velocity exceeding (perhaps far exceeding) 13,000 km/hr.

Because of the X-Prize, RLVs, even if they are X-Prize class vehicles, will therefore soon 

be flying. Some of these vehicles are quite different in their design and planned 

operation from the ELVs which AST has licensed to-date; this includes a difference in 

the approach to flight safety and vehicle health maintenance. And while it is possible that 

the entrepreneurial X-Prize RLVs may not have complex FSS or IVHM systems, the 

success of the X-Prize class RLVs could spur the development of higher-performance 

RLVs, to which complex IVHM systems and FSS would be appropriate.
3

1.2 Concerning Verification Methods

For many components or systems of interest (and public-safety concern), there will be a 

general verification methodology which can be applied. This report refers back to this 

methodology where applicable. The methodology is based upon the one that AST’s 

predecessor (the Department of Transportation Office of Commercial Space 

Transportation) utilized for much of the COMET/METEOR payload determination 

process, and is detailed as follows:

General Verification Methodology 

1. “Paper-check.” The applicant should describe the article to an appropriate degree. 

The expected physical environment through which the article is expected to operate 

should be detailed. The expected mean level of performance for the article should be 

described, along with standard deviations of performance and the necessary performanceenvelope. The applicant’s performance needs should be compared to the manufacturer’s 

descriptions for article performance. Any specialty modifications needed by the 

applicant should be checked against the understanding of the manufacturer.

2. “Article-test.” The article should undergo performance testing either by the 

manufacturer or by the applicant. The results should be compared to the stated 

needs.

3. “System-test /Early flight test.” The vehicle system in which the article resides 

may be tested during mission simulations or during the early part of a series of 

envelope -expanding flight tests. The article’s performance should be compared to 

expected performance. This step may not always apply.

4. “Mission Simulation /Late flight test.” If the vehicle is not capable of performing 

a series of expanding-envelope flight tests (e.g., an ELV-type of RLV), then an endto-end mission simulation (utilizing real hardware) may be necessary. The article’s 

performance during simulation should be compared to expected values. Otherwise, 

as the flight-testing envelope for the vehicle expands, the article’s performance 

should be verified. This step may not always apply.

5. “Flight-test.” If the article has previously flown on another vehicle in a dynamic 

environment equal to or greater than the environment of the vehicle in question, 

then the article has demonstrated the ability to perform as expected. This does not 

mean that Step #1 is any less important; indeed, it will probably be of even greater 

importance. Another possibility is that, at some point during the flight-test regime, 

the operating environment for the article is attained.

Specific items of interest to be tested for individual articles (e.g., GPS receiver 

bandwidth) will be detailed as appropriate.
4
5

2.0 NON-TRADITIONAL FLIGHT SAFETY SYSTEMS

The role of an FSS has traditionally been – and will continue to be – to protect the public 

and property from harm in the case of off-nominal vehicle flight. Non-traditional FSS, 

especially for reusable launch vehicles (RLVs), may also assume the role of attempting to 

prevent the catastrophic destruction of the vehicle in the case of off-nominal flight; 

however, it is important to remember that even actions taken to save a vehicle are 

performed within the context of protecting public safety and property. 

Traditional launch vehicle FSS are defined to be those as presently designed and 

operated. Generally, in the West and in China & Japan, current FSS are based upon 

observation of a vehicle’s trajectory via radar and optical means (i.e., external tracking). 

In the case of a vehicle entering uncontrolled flight, or in the case of a vehicle in 

controlled flight yet straying outside of pre-determined safety boundaries, a human 

actively sends a destruct signal to the vehicle. Some amount of autonomy exists with 

regard to premature strap-on booster or stage separation triggering an inadvertent 

separation destruct system (ISDS). [1] Russian and Soviet-heritage vehicles use an 

autonomous TTS. An autonomous TTS works in the following way: if the vehicle’s 

trajectory is outside of a pre-determined boundary-box, the on-board computer shuts 

down the engines. The vehicle then continues along a ballistic trajectory until Earth 

impact. [2] Non-Traditional Flight Safety Systems, as a subject area, encompasses all 

methods of FSS beyond the existing systems just described.

When considering non-traditional FSS for RLVs (including the X-Prize class), the 

present-day ELV flight safety systems are not the only flight safety systems which bear 

relevance; unmanned aerial vehicle (UAV) flight safety systems also bear relevance. 

Current UAVs and launch vehicles lie at opposite ends of the spectrum with regards to 

velocity, size, and danger posed to people and to property if impacting the ground during 

operations. However, near-term and far-term future RLVs should lie all along that 

spectrum, with some small X-Prize vehicles like Scaled Composites’ “SpaceShip One ” 

being closer to UAVs and the “Canadian Arrow” being closer to smaller launch vehicles 

like Athena or Pegasus.

Figure 1. Scaled Composites SpaceShip One (foreground) [39]
6

Eventually, RLVs may not need FSS any more than commercial jetliners do today. 

However, until such time as demonstrated catastrophic failure-rates for RLVs are low 

enough to obviate the need for FSS to protect the safety of the public, some form of FSS 

will be necessary.

Figure 2. Canadian Arrow, Pre-Launch and Liftoff [40]

2.1 Description of Existing and Proposed Designs for Non-Traditional FSS 

Non-Traditional FSS can be broken down into two main categories: range-centric 

systems and vehicle-centric systems. This is not meant to imply mutual exclusivity –

range-centric FSS do have components on-board the vehicles, and vehicle-centric FSS 

may well have system components on a range. The distinction is based on emphasis, on 

the location of the decision-making activity and source of data, and also on heritage 

(launch vehicle FSS or UAV). Therefore, by this definition, Russian autonomous TTS 

could fall under the category of vehicle-centric FSS. Future range-centric FSS will 

generally be evolutions of the current general range methodology. Currently, for 

Western/Chinese/Japanese systems, the decision-making and actions are carried out at the 

range, with the exception of some autonomous attitude-based or separation-based action 

which is taken by the vehicle. [1] Vehicle-centric systems for reusable vehicles may be 

autonomous or crew-controlled and will generally not be destructive in nature. 

From a phase-of-flight and vehicle viewpoint, the launch of ELVs will continue to be 

covered by range-centric FSS designs. Range-centric FSS may also be utilized for RLV
7

launches; however, their use may not be necessary. Vehicle-centric FSS may be all that 

is needed for some RLV launches – especially for crewed vehicles. Range assets may 

still be used to provide redundancy, however, the primary execution of the flight safety 

function would reside onboard. Vehicle-centric FSS is needed for the descent of reusable 

vehicles.

Considering both range-centric and vehicle-centric FSS, there are five distinct FSS 

methodologies or paradigms:

• range-containment

• vehicle-destruct

• flight-safing

• thrust-termination

• vehicle-recovery

Some possible non-traditional FSS may use multiple methodologies; some may use only 

one methodology. These methodologies will be detailed below – as appropriate – as the 

range-centric and vehicle-centric FSS are described.

2.1.1 Range-Centric Non-Traditional FSS

Non-Traditional range-centric FSS will support both expendable and reusable vehicles 

for orbital as well as sub-orbital trajectories; however, excepting range-containment for 

sub-orbital missions, range-centric non-traditional FSS as defined are applicable for 

launch activities only. 

2.1.1.1 Flight Safety Systems Methodologies

2.1.1.1.1 Flight Safety System Methodology #1: Range-Containment FSS

This is the lowest-technology safety system available. 

It is conceivable for some suborbital RLVs – especially some X-Prize vehicles – that a 

chosen range may entirely contain a vehicle or its debris in the case of every possible 

malfunction. The limiting cases would be – for every direction – the loss of guidance 

after rocket motor ignition such that a maximum-range trajectory is then flown. The 

range may not have to be totally uninhabited; however, the maximum casualty 

expectation cannot be greater than 30x10

-6

for the entire mission assuming a vehicle 

failure.

If humans are aboard a vehicle relying on this type of FSS, a protocol should exist to 

determine what actions to take to ensure their safety. If the actual trajectory of the 

vehicle does not pose harm above and beyond the harm posed by a nominal trajectory, 

the humans may just ride the vehicle out to a fairly-nominal end-of-mission. However, 

the ability to ascertain that a trajectory will remain safe for human seems doubtful, 

excepting a very few specific and benign failures (e.g., pilot error results in the vehicle 
8

flying the correct trajectory profile relative to altitude and time but along an erroneous 

heading). It is most likely that the humans on-board would have to utilize a 

crew/passenger escape system to depart the vehicle. This would likely affect the 

vehicle’s aerodynamics and stability.

At least one company which has received a sub-orbital launch license from AST is using 

this methodology – Interorbital Systems is planning to launch their Neutrino rocket from 

an area of the Pacific Ocean off of the California coast. [4, 5]

2.1.1.1.2 Flight Safety System Methodology #2: Flight Destruct Systems (FDS)

The philosophy behind this methodology is the following: Certain boundaries are set 

along a vehicle’s trajectory such that the vehicle’s continued operation within those 

boundaries will not negatively affect public safety. However, should the vehicle stray 

outside of those boundaries or become uncontrollable within those boundaries, the 

vehicle is destroyed via an active command. The boundaries are defined such that the 

propagation of debris to Earth’s surface will not bring harm to the public. FDS are the 

methodology presently employed for ELVs not of Soviet heritage. 

Regarding RLVs, in general, companies owning and/or operating RLVs will likely not

want to have a destruct system on their vehicles. If a vehicle is powered by solely liquid 

fuels or hybrid rocket engines or a combination of these two, no FDS should be 

necessary. However, if a vehicle utilizes solid rocket motors, then an FDS may be a 

necessity depending upon the ability of solid rocket motors to perform thrust termination.

If an RLV uses solid rocker boosters (SRBs), then an FDS will be necessary for the 

boosters themselves – just as is done on the U.S. Space Transportation System (Space 

Shuttle). Engagement of SRB FDS should only result in the destruction of the SRBs as 

opposed to the destruction of an entire RLV. If an RLV utilizes solid rocket motors as 

part of a vertically-stacked stage, the stage would have to carry an FDS. This means that, 

in the case of anomalous flight during ascent, the desired-mode of operation would be to 

enact a stage-separation prior to activating the FDS; however, this sequence of events 

may not be able to be guaranteed, and the possibility of destruction of the entire RLV 

exists. For an RLV carrying people on board, this would not be a desirable situation.

If solid rocket motors are to be inserted within the airframe of an RLV (an exceedingly 

doubtful, yet technically possible scenario), then another flight-safety possibility exists. 

It is possible to terminate the thrust of a solid rocket motor by opening ports along the 

sides of the casing. Theoretically, an RLV with internal solid rocket motors (the 

propellant would be loaded before each flight) could use such a thrust termination 

method as an FSS. The fidelity of such a system with regard to the timeliness of engineshutdown would be the main issue of concern as to whether or not such a system would 

be suitable as an FSS. If a “blow-port” system could not be operated to the needed 

fidelity, then the only other option for FSS would be FDS, the operation of which would 

mean the destruction of the entire RLV. As with the vertical-stage example, this would 

not be a desirable situation for RLVs carrying people.
9

The systems and methods described over the remainder of Section 2.1.1 should be 

considered within the context of vehicles utilizing Flight Safety System Methodologies 

#1 or #2 (range-containment or FDS).

2.1.1.2 Evolution of Existing Launch Vehicle FSS

There have been many studies over the past several years concerning upgrading the 

technology at the United States’ Eastern & Western Ranges. Most recently, the 

Advanced Range Technology Working Group (ARTWG) has been formed including 

participants and stakeholders from across the U.S. Government, including the military

services, as well as state governments, the commercial sector, and academia.[6] Most of 

the possible changes being examined by the working group are, when considered 

separately, evolutionary in nature; however, the end-vision could be considered 

revolutionary. The eventual goal expressed by the majority of the international space 

launch community is that of a “space-based range,” i.e., a space-launch range that does 

not need ground-based systems (e.g., radar, communications links) but can rely on spacebased assets to accomplish all necessary functions. 

The ARTWG has divided the main functions of future launch and test-ranges into seven 

categories: [6]

• Tracking & Surveillance

• Telemetry

• Range Command & Control Systems

• Communications Architecture

• Decision Making Support

• Planning, Scheduling, and Coordination of Assets

• Weather Systems

The ARTWG’s May 9, 2003 Draft Report, “Mapping America’s Next-Generation 

Launch and Test Range Technologies: Roadmaps to enable Future Launch and Test 

Ranges,” goes into great detail in all of these areas; using that draft report and other 

sources, this report briefly touches on the highlights within each area. However, it should 

be noted that the area of greatest interest to AST is the area of Tracking and Surveillance, 

since this is the area which will undergo the greatest technical change from the present 

paradigm. Furthermore, as will be discussed in the enabling technologies discussion 

(Section 2.2), the evolution of tracking capability towards a truly space-based range is the 

only true technology-challenge; the evolution within the other defined areas is mostly 

organizational, or concerned with integration and automation. 

2.1.1.2.1 Tracking & Surveillance

In general, the current tracking capability relies on fixed-location ground-based metric 

radars with C-band beacons aboard flight vehicles and Inertial Measurement Unit (IMU) 

data in the telemetry stream. The long-term goal is to interface with the FAA space and 

air traffic management system (SATMS), and to have seamlessly-integrated global 
10

operability for Global Positioning System (GPS) and Inertial Measurement Unit (IMU) 

metric tracking. [6] The key step here (for tracking) is, in the near and mid-term, to 

evolve to using GPS and IMU as part of a space-based range. The use of other mobilerange assets like high altitude airships (HAA) and UAVs to supplement space-based 

coverage is also envisioned. Regarding surveillance (surveillance of the restricted launch 

and downrange areas to ascertain that members of the public are not placing themselves 

at risk), the near-term desire is to automate the collection, transfer, and integration of 

surveillance data. The long-term ARTWG goals include integrated space-based 

surveillance and real-time situational awareness within selected regions worldwide. This 

is in contrast to the current capability, which involves manual data collection, data-relay 

via voice, and table-top-and-tokens display. [6]

2.1.1.2.2 Telemetry

Currently, telemetry is obtained via fixed or mobile ground-based receivers with a limited 

number of deployable space-based and airborne assets. The ARTWG’s goal is to 

eventually have global coverage via the space-based range, supplemented by mobile 

assets as needed. [6] Telemetry is probably the area of next-greatest interest – and 

perhaps greatest concern – to AST because of the loss of spectrum as a resource and the 

growth of the data-streams being transmitted. [6] To address this increasing concern, 

various advanced modulation schemes such as Quadrature Amplitude Modulation 

(QAM) and Feher Quadrature Phase Shift Keying (FQPSK) are currently being tested 

both in the laboratory and on DoD and NASA missile launches with the goal of 

optimizing the use of the RF spectrum and alleviating the bandwidth crowding issue.

2.1.1.2.3 Command & Control

The goal of the ARTWG is to move from the present mostly-manual system through 

semi-automated and automated systems to an eventual autonomous system to improve 

interoperability, responsiveness, and flexibility. (Automation refers to machines taking 

over physical tasks from humans, autonomy refers to the ability to act without human 

control, i.e., the shift of decision-making from human to machine.) The system is 

comprised of the following functions: monitor range asset health, status, and 

configuration; configure range assets, and execute command and control of range assets 

and flight vehicles. This includes flight-termination systems (FTS) – the eventual goal is

to affect autonomous FTS (meaning flight destruct systems {FDS}) with manual 

override. Another issue (to be touched upon in the enabling technologies section) is the 

difficulty in updating legacy systems. [6]

2.1.1.2.4 Other Areas

In the remaining areas listed in Section 2.1.1.2, the only real point of interest to AST

identified by the ARTWG is the development of a single automated suite of decisionsupport tools. Eventually, the “range decision authority” would be centralized, and there 

would be seamless integration with FAA air traffic control. [6]
11

2.1.2 Vehicle-Centric Non-Traditional FSS

Much of the vehicle-centric non-traditional FSS heritage will derive from the systems 

used on present-day UAVs. Therefore, prior to a specific discussion of vehicle-centric 

FSS methodologies, a brief synopsis of UAV types is in order.

2.1.2.1 UAV Types

Differentiating via operational mode, and for the purposes of this report, there are three 

types of UAVs:

• remotely piloted vehicles (RPVs)

• semi-autonomous vehicles

• autonomous vehicles 

RPVs - RPVs can be as simple as radio-controlled aircraft flown by hobbyists. These 

types of UAVs require that someone actually pilot them from a remote location –

controlling the flight control surfaces (ailerons, elevators, and rudder) directly. For many 

modern UAVs this entails the use of a remote cockpit which is usually based on the 

ground but could be located on another aircraft or at sea. The most rudimentary of these 

vehicles will have no autonomous capability whatsoever; more advanced RPVs may have 

some degree of autonomy as a flight safety characteristic – this capability will be 

elaborated upon when detailing the different types of FSS. Examples of UAVs which 

can operate as RPVs include BAI’s Exdrone vehicle. [7]

Figure 3. BAI’s Exdrone UAV [7]

Semi-autonomous UAVs – These vehicles control their own flight control surfaces, but 

are navigated via waypoints to a destination. A remote operator plots the vehicle’s 

course from a terminal (which could be a laptop or even a hand-held computer) and the 
12

vehicle flies point-to-point. The operator could be nearby or could be on a completely 

different continent. It should be noted that many vehicles referred to by many in the 

UAV community as “autonomous” actually fall into the “semi-autonomous” category. 

Examples of semi-autonomous UAVs include Global Hawk. [8]

Figure 4. Global Hawk UAV [41]

Autonomous UAVs – These vehicles can fly without input from remote controllers. The 

complexity-level of these vehicles can vary from having the ability to only fly a preprogrammed route to having a high-level of artificial intelligence (AI) and the ability to 

chart their own route to a pre-determined goal (“autonomous free-flyers”). Autonomous 

UAVs without advanced AI (“pre-programmed autonomous UAVs”) would have to be 

programmed to fly a path around obstacles (restricted flight zones, cities, etc.), whereas 

autonomous UAVs with a high degree of AI could have a database of obstacles which it 

could consult when determining its own path. The degree of AI that a vehicle has will 

affect how an FSS profile may be developed. “Autonomous” as presently used refers to 

pre-programmed autonomous vehicles; the current level of AI does not yet permit 
13

autonomous flight without waypoint input, either before or during flight. The Aerosonde 

UAV can be considered a pre-programmed autonomous UAV. [9]

Figure 5. The Aerosonde UAV and its Flightpath across the Atlantic [42]

2.1.2.2 Vehicle-Centric Flight Safety System Methodologies

2.1.2.2.1 Methodology #3: Flight-Safing 

This is a flight safety methodology presently employed by UAVs that is applicable for 

any non-crewed vehicle capable of sustained powered flight in the atmosphere. Within 

the general methodology of flight-safing are several modes which are dependent upon the 

degree of autonomy of the vehicle; all of these modes require a minimum autonomous 

flight capability.

The first mode entails a cessation of the attempt to fly a course and the commencement of 

flight around a fixed point, and is therefore not pertinent to RLVs which will not have 

atmospheric powered-flight capability. If the vehicle in question is an RPV, the mode 

would be entered automatically if the command-link is lost, and might be entered by 

command if the pilot observes a control problem (however, the control problem could 

easily hamper the ability to maintain flight). For the very lowest level of autonomous 

capability, the mode would entail circling of the vehicle’s present position. The next 

level of capability would be a circling of the present position while gaining altitude in an 

attempt to reacquire a lost command-link. The first two modes would probably be the 

modes entered if a reentering RLV (with atmospheric powered-flight capability)

reentered far from its intended reentry area and there was no command link to be initially 

established. The next level of capability beyond circling a “present” location would be 

for the vehicle to fly to a pre-programmed waypoint. NASA’s Perseus B UAV has this 

capability even though it is an RPV. [10] The highest level of capability is one where it 

is possible for an RPV to be equipped with an auto-land system that would allow it to fly 

to a suitable landing area designated by a waypoint and then land; this capability is 

pertinent for RLVs both capable and incapable of atmospheric powered flight. A vehicle 
14

with this capability would more likely, though not necessarily, be considered a semiautonomous vehicle. 

Semi-autonomous and autonomous vehicles would have flight-safing of at least the level 

of flying to and circling one of a series of pre-determined waypoints. Like RPVs, a loss 

of command-link would be one reason to enter flight-safing mode (for semi-autonomous 

vehicles). Reentering on an off-nominal trajectory such that a command-link is not 

available (semi-autonomous), the expected waypoints are not locatable (autonomous preprogrammed) or the coordinates for the designated landing area are not within the 

vehicle’s flight range (autonomous free-flyer) would also result in the vehicle entering a 

flight-safing mode. One should keep in mind, however, that flight-safing may not be a 

viable option for those RLVs that do not have either the propulsive or glide capability to 

maintain aerial station-keeping for any significant duration.

It is logical to assume that many autonomous or semi-autonomous vehicles will have an 

auto-land capability (some vehicles presently defined as “autonomous” actually revert to 

semi-autonomous or RPV-mode for landing). [11] If the vehicle is within range of a preprogrammed alternate landing site (or of an alternate landing site resident in an on-board 

database), then part of a flight-safing mode would be (after either a pre-determined time 

circling or, more likely, when on-board fuel levels have dropped below a critical redline

state) that the vehicle would fly to the alternate site to land. In the case of a gliding 

vehicle, the traveling to a pre-programmed or database-resident alternate landing site 

could well be the first and only course of action. If there is no pre-programmed alternate 

landing site or alternate site within the on-board database within range, the vehicle –

unless it has the highest-state of AI – would have to stop its engine or engines and 

activate what is called in the UAV community a flight termination system (FTS). The 

UAV community’s FTS is a parachute which deploys to allow the unpowered vehicle to 

settle to the ground. However, an autonomous RLV with the highest state of AI could 

conceivably be able to search an unfamiliar area for either a suitable airstrip or an area of 

flat terrain sufficient to execute a landing attempt. These systems may even be able to 

identify areas of relatively high or low population density and act accordingly. If no 

suitable airstrip or flat area were found, these vehicles could fly on their own to an area of 

suitable-low population density and activate a UAV FTS. 

2.1.2.2.2 Methodology #4: Thrust Termination

Thrust termination is not a “stand-alone” type of flight safety system for RLVs; rather, it 

is a step that is taken in order for further flight safety activities to then follow.

Present-day thrust termination systems (TTS) have been the entirety of the FSS for 

Soviet-heritage and Russian ELVs since the late 1950s. The system presently consists of 

an on-board computer which determines, via inertial measurements, when the ELV is 

straying from its course sufficiently so as to place public safety in jeopardy. If public 

safety would be placed in jeopardy by continuing operation of the ELV, the on-board 

system terminates the vehicle’s thrust and the vehicle continues to Earth-impact along a 

ballistic trajectory.
15

The discussion in the previous section on flight-safing modes is most immediately 

relevant to RLVs in the realm of post-reentry atmospheric operation. However, entering 

a flight-safing mode can also be applicable in the case of flight-anomalies during the 

launch-section of the flight regime. If there is a problem with the mission during launch 

for which an abort-to-orbit (ATO) is not an option, the course of action would be to 

terminate thrust and then enter an applicable FSS mode. Given the financial investment, 

it is not logical that an RLV would continue to coast to a ballistic impact like present-day 

Soviet-heritage launch vehicles. 

After thrust termination, it is also quite possible that a vehicle would have to dump fuel in 

order to enter an appropriate FSS mode. Depending upon the altitude at which fuel 

would be dumped, there may be fuel toxicity concerns. Many of the X-Prize vehicles and 

some Russian launch vehicle designs (e.g., Angara) are utilizing fuel which is morefriendly to the environment (e.g., clean-burning hydrocarbon fuels) than some present 

fuels (e.g., hydrazine). [12, 13]

After thrust termination and possible fuel-dumping, it is assumed that the first preference 

would be for the vehicle to return to the launch site, assuming there is an acceptable 

landing facility at that site. Barring the possibility of a launch-site return, it is assumed 

that the vehicle operators will have identified alternate landing sites for the vehicle to fly 

to in the case of an abort during ascent. Operationally, the vehicle’s control center would 

coordinate the ascent-abort activities with the appropriate authorities. The flightactivities themselves would occur as a function of vehicle-control-type during or after 

any fuel-dumping. RPVs would be flown to the appropriate alternate landing site by the 

remote pilot. Some semi-autonomous vehicles and pre-programmed autonomous 

vehicles would have the abort landing-locations programmed into the vehicles in the 

same manner as the flight-safing mode in which the vehicle flies to one of a selected 

number of waypoints in the case of loss of control-signal. Other semi-autonomous 

vehicles (assuming they are capable of powered flight in the atmosphere) may simply 

circle where they are or circle a known waypoint waiting for instruction. In general, 

flight-safing modes would follow as described in the previous section, and the UAV FTS 

would be deployed as described in the following section.

One issue of interest specifically to crewed RLV operations – and most specifically to XPrize class vehicles – is the use of autonomous or remotely-controlled thrust termination 

in the case of a significant divergence from the planned trajectory while the rocket

propulsion system is engaged. This is not assuming crew incapacitation; rather, it is 

assuming crew inability to effectively manage the trajectory. Following such a thrust 

termination, the crew could take appropriate crew and vehicle survival measures, 

depending upon the vehicle design. The options might range from continuing along the 

“present” trajectory until such time as a glide can be initiated to having to don parachutes 

and bail out of the vehicle.
16

2.1.2.2.3 Methodology #5: Flight Termination System (FTS) / Vehicle Recovery 

System (VRS)

A flight termination system is defined here as any system which, either given a launchabort or a reentry anomaly, allows the vehicle to come to a “soft” landing (i.e., a landing 

after which one could reasonably expect to recover the vehicle relatively intact such that 

it would need only moderate repairs before being returned to flight-status). 

The term “flight-termination system” as used here has its heritage in the UAV 

community. However, the same term is also used in the ELV community with a different 

connotation; usually, FTS is used to mean FDS. Therefore, for the purposes of this 

paper, this type of system will henceforth be called a vehicle recovery system (VRS). In 

the case of NASA UAVs, this is simply a parachute system which allows the vehicle to 

slowly descend to a relatively soft landing on the ground. It is reasonable to assume that 

RLVs using such a system might also employ airbags to cushion a landing. For some 

vehicles, like Kistler’s K-1, the normally-employed landing system (parachutes & 

airbags) could also serve as the VRS.

Figure 6. Kistler K-1 First Stage with Parachutes & Airbags Deployed [43]

There are two separate reasons for employing a VRS; these reasons are independent of 

the vehicle phase-of-flight (ascent or descent) and may come to bear in either phase. 

First, and commensurate with the majority of the discussion in this section of the report, a 

VRS may be employed as a method of allowing the vehicle to descend to a “soft” landing 

in the case that the vehicle cannot land at an alternate or acceptable landing location. 

(This could be following the loss of control-link and after the vehicle has been in a flightsafing mode until such time as fuel-exhaustion is imminent. In the case of a vehicle with 

high-AI, a VRS would be used if no suitable landing location could be found.) A “soft” 

landing in this case will hopefully allow the vehicle to be recovered intact and protect the 

occupants, if any. Moreover, it protects public safety by restricting the impact velocity to 

a value much lower than the value would be if the vehicle were in free-fall. 
17

The second reason for employing the VRS would be in the case of a vehicle controlfailure - not the loss of a control-link, but a failure in the ability of the vehicle to maintain 

controlled flight along its directed path. In the case of a control-failure during ascent, the 

VRS would be employed following thrust-termination of the vehicle’s rocket engines 

and, possibly, the dumping of fuel (rocket fuel and possibly post-reentry atmosphericflight fuel as well). In this mode of operation, the combination of thrust-termination, 

possible fuel-dumping, and VRS serve as a replacement for present-day flight-destruct 

systems and thrust-termination systems which lead to ballistic impact. 

It should be noted that VRS may not be feasible for all RLVs. As is the case with 

parachute-technology for VRS in aircraft, it is both technically and financially feasible 

for relatively small UAVs and relatively small piloted aircraft (e.g., Cessna 172). Such 

systems have not been developed for larger aircraft such as commercial airliners. For 

some RLVs, such systems may be infeasible from a vehicle-size standpoint, from a massfraction standpoint, or even from a financial standpoint. 

2.1.2.3 Collision Avoidance

Although launch-corridors will most probably still be cleared for ELVs into the future, 

RLVs – especially during post-reentry atmospheric flight - are more likely to operate like 

commercial aircraft using the SATMS. It is in AST’s interest that returning RLVs have 

as little an impact as possible on the SATMS; the ability of a vehicle to perform 

autonomous collision avoidance is therefore desirable. Although some RPVs may have 

absolutely no autonomous capability, their pilots should have enough situationa l 

awareness to be able to avoid other traffic. One risk-mitigation technique (for all 

returning RLVs) may be to exclude aircraft without transponders from operating in the 

vicinity of returning RLVs. The relatively small degree of autonomy needed for 

collision-avoidance systems is not inconsistent with semi-autonomous or even RPV 

operation. Autonomous collision-avoidance systems are fairly routine when considering 

“cooperating” aircraft (those with transponders). Until very recently, “non-cooperating” 

aircraft – those without transponders – have been a problem which collision-avoidance 

systems have not been able to deal with. However, in April 2003, the first test-flight was 

completed of a collision-avoidance system designed to detect non-cooperative as well as 

cooperative aircraft; moreover, this system was utilized by the Proteus UAV. [14] 

2.1.2.4 FSS and Humans on-board an RLV

There are three possible scenarios to consider when discussing humans on-board RLVs: 

a crewed-RLV with no passengers, a crewed-RLV with passengers, and a non-crewed 

RLV with passengers. For a crewed-RLV, the post-reentry atmospheric flight FSS flightsafing modes are moot if the crew is healthy. If the vehicle returns from orbit seriously 

off-course the crew will find a place to land the vehicle or to engage the VRS. If the 

vehicle is undergoing control-failure post-reentry, the crew will engage the VRS. 

However, some level of autonomy or ability to conduct vehicle operations from a remote 

site may exist in the case of crew disablement, in which case the FSS flight-mode 

discussions are appropriate with the additional constraint of landing the vehicle in such a 
18

manner as to obtain medical assistance for the crew as quickly as possible while 

maximizing their safety and the safety of the public during descent and landing (e.g., it 

would not be expected nor prudent to have the vehicle engage the VRS and parachutedown hoping to land on the parking garage of Johns Hopkins Hospital in the middle of 

Baltimore City when the vehicle could land at Baltimore-Washington International 

Airport with medical personnel standing by). Likewise, it would probably be true that, in 

the case of an anomalous ascent that the crew would initiate the proper abort options; 

however, autonomous or remote engagement of vehicle abort options could take place in 

the case of crew incapacitation. For example with the Space Shuttle, the crew initiates a 

Return-to Launch Site (RTLS) abort that commands the onboard guidance & control 

system of the Orbiter to fly it back to the vicinity of the launch site in a series of 

complicated maneuvers.

In the case of a vehicle with passengers, it is reasonable to expect – and may well be a 

licensing requirement - that alternative landing sites would be reachable given an abort 

commencing at any point during an ascent. The constraints of timely medical assistance 

and the protection of humans during ascent or descent aborts would be even more 

important than if just a crew were on a vehicle; however, the protection of public safety is 

no less important. 

2.2 Description of Enabling Technologies and Verification Methods for NonTraditional FSS

2.2.1 Enabling Technologies and Verification Methods for Range-Centric FSS

2.2.1.1 Tracking and Surveillance 

2.2.1.1.1 GPS-Based Metric Tracking

The single-most important enabling technology within the area of range-centric nontraditional FSS – especially in the near-term - is GPS-based metric tracking. Presently, 

GPS has successfully been demonstrated for on-orbit position and velocity determination 

and, combined with an IMU, for the tracking of sub-orbital launches, including ballistic 

missile test launches from Kodiak, AK (as part of the Ballistic Missile Range Safety 

Technology {BMRST} program), and from the Navy’s Atlantic test range. [16,17,18]. 

Sub-orbital sounding-rocket tests have also been successfully performed at Esrange, the 

European Space Agency’s (ESA) range in Sweden; it has been recommended that 

GPS/IMU systems form the baseline for European sounding rocket range safety tracking 

systems in the near future. [19] Furthermore, the launch of the Maxus-5 mission on Aril 

1, 2003 employed a GPS-based system featuring two GPS-receivers as the operational 

range safety tracking system. To date, however, a GPS-based range safety tracking 

system has not been successfully demonstrated on an orbital launch. 
19

The difficulties in using GPS transceivers for orbital launch vehicle tracking are: [19,20]

• International Traffic in Arms Regulations (ITAR) restrictions

• Acquiring and tracking GPS signals at high speed

• Acquiring and tracking GPS signals at high accelerations

• Ionization

ITAR compliance dictates that US GPS receiver manufactures may not sell receivers that 

can track at altitudes above 60,000 ft. and/or at speeds greater than 1000 knots without a 

Non-Export Agreement and Intended-Use form from the purchaser. [20] Although this 

problem is easily surmountable from a technical viewpoint, it necessitates that GPS 

receiver manufacturers must custom-make receivers for these purposes, adding to the cost 

and complexity of a project.

A receiver’s physical bandwidth must be sufficient to allow the tracking of GPS satellites 

at high speeds due to Doppler-induced frequency offsets. In one test, a GPS receiver lost 

lock for this reason at a speed of 3000 meters/sec. Furthermore, the tracking-loops of a 

GPS receiver must be of sufficient bandwidth to allow the receiver to properly track GPS 

satellites during high acceleration. Finally, a receiver’s GPS satellite acquisition 

algorithms must account for the high-speed environment. [20]

Figure 7. GPS Orion-HD receiver for sounding rocket tracking and IIP prediction [19]

The April 1, 2003 Maxus-5 mission did suffer from temporary S-band telemetry dropouts near the end of the boost-phase of flight. [19] However, the two BMRST launches 

from Kodiak apparently suffered no problems. 

A verification plan for GPS-based metric tracking would include the following (which is 

in-line with the template presented in Section 1.1):

1. Top-level assessment of the GPS receiver’s ability to acquire and track GPS satellites 

throughout the expected flight regime. This would consist of examining the needs of the 

applicant against the specifications detailed by the manufacturer. Do the applicant and 

the manufacturer understand the environment in which this unit is supposed to operate? 

Has the communication (if any) between applicant and manufacturer been clear? Has the 
20

manufacturer demonstrated the ability of the unit to operate in the applicant’s flight 

regime? Bandwidth and algorithm needs should be specifically assessed. 

2. Modeling assessment of the GPS receiver’s ability to acquire and track GPS satellites 

throughout the expected flight regime. A GPS simulator can be used to determine if a 

receiver can perform against a modeled trajectory [20]. For the first-use of system, this 

should be accomplished.

3. Test-launches. For uncrewed vehicles for which the FSS is to be dependent upon the 

system in question, the system should be used in parallel with existing systems until it has 

successfully demonstrated its ability to operate in the flight regime. For example, the 

launches out of Kodiak tested a GPS tracking system but still relied on traditional radar 

tracking for their actual range safety. Only actual flight will fully test the system and also 

address telemetry drop-outs. This requirement may be satisfied for a system independent 

of vehicle; for instance, if a system successfully flies on a certain system and is then to be 

used by a different vehicle flying an equal or less dynamic trajectory, AST may consider 

the system proven. 

2.2.1.1.2 Low-Power Transceivers

Along with improvements/alterations to GPS receivers, low-power transceivers are also 

noted by the ARTWG as being an enabling technology. Although certainly useful, these 

notionally are a subset of GPS receivers

2.2.1.1.3 Mobile Range Platforms

The ARTWG identified mobile range platforms, based on long-duration UAVs or HAAs. 

The ability of these systems to perform their range-related duties should be examined by 

AST as any other critical range-component when considering range certification. The 

issues unique to the platforms would be related to their ability to stay on-station and 

retain the needed power for their range-supporting systems. 

2.2.1.1.4 Other Enabling Technologies within Tracking and Surveillance

Although there are no other “big-ticket” enabling technologies within this area, there are 

technology issues which deserve mention. In the Tracking area, most of the remainder of 

the evolution-vision is one of greater integration and interaction – especially with 

SATMS. In general, all proposed integration and interaction capabilities should be 

verified in the following manner:

1. All interaction between the RLV operator and other entities (e.g., air traffic control), 

the records of the scope, specifics, and responsibilities of each party should be examined.

2. All interactions should be modeled and accounted-for during vehicle mission 

simulations. The actual interacting entities should be involved in some mission 

simulations.
21

3. All systems involved in new integrations should be tested – with emphasis on the 

newly-integrated capabilities of the integratee and the capabilities previously possessed 

by the integrator. For example, if a scheduling function which was previously performed 

on a stand-alone system is integrated into an existing larger scheduling system, not only 

the new functionality but also the previous functionality should be tested. The rigor of 

the testing may or may not be equal.

With regard to Surveillance, the ARTWG report seems to be describing an exceedingly 

robust level of capability. The purpose of range surveillance is to keep the general public 

(non-mission critical vehicles and people) outside of areas restricted for safety reasons. 

New surveillance technologies and capabilities should be reviewed by AST when 

certifying ranges as appropriate; the issue should be one of integration.

2.2.1.2 Telemetry

There are two specific areas of interest within Telemetry: spectrum availability and 

telemetry transmittal and receipt through the plasma that envelops reentering spacecraft. 

The loss of available spectrum for range operations, coupled with the growth of data 

being transmitted is leading to a crisis situation. According to G. Derrick Hinton, 

Program Element Manager for the Central Test & Evaluation Investment Program in the 

office of the Director, DoD Operational Test & Evaluation, there is a “pressing need for 

research in the technologies required to enable telemetry operations at frequencies higher 

than those in which they are currently conducted.” According to Mr. Hinton, if the 

current trends continue, by 2015 the test and evaluation community can expect to only be 

able to support one mission at a time – this stands in contrast to the theoretical capability 

to support over 1,500 simultaneous missions in 1972. Mr. Hinson concludes that 

techniques must be developed to either “dramatically increase data-link capacity” or to 

“move to less-desirable, under-utilized frequency bands.” He concludes that the latter is 

the preferred solution. [6]

The verification of such a change, either frequency-shift or data-compression would be 

fairly straightforward. In the case of a change-over by the national ranges, it is logical to 

assume that all of the ranges would eventually change to the new standard. One range 

may change first as a pathfinder. Whatever the case, the new systems should be tested 

while existing systems are still operational; transition should not occur until repeated 

success of the new systems are demonstrated. In the case of a new, private range desiring 

certification, the process should prove to be the same as with any telemetry technology 

(e.g., the range-certification methodology is not a function of telemetry-system type).

The other area of interest is the ability to receive signals through the plasma surrounding 

reentering spacecraft. NASA currently has a project to build a technology-demonstrator; 

the Plasma Wave Advanced Receiver project. This capability would not be replacing a 

present capability of reentering space vehicles, rather it adds a totally new capability. 

Until the capability is flight-test proven on a vehicle with a plasma-wave intensity equal-
22

to or greater-than the applicant’s vehicle (or an identical vehicle), the system should not 

be used in a public-safety critical fashion. For example, it would not be appropriate until 

the system is proven for a mission plan to rely upon the vehicle receiving directions to 

adjust its trajectory during what would have been plasma-induced loss-of-signal. Once 

the capability has been successfully demonstrated on multiple flights spanning the limits 

of plasma intensity, AST could consider its use in safety-critical operations. It is 

probable that this technology would first be flight-tested by NASA, and it is expected that 

the researchers would work closely with those using the system early-on. The general 

verification methodology would apply, however, this would not, at first, be an off-theshelf item.

2.2.1.3 Command & Control (C&C)

2.2.1.3.1 Automated FTS

The key issue in range C&C evolution is the movement towards automated FTS (FDS). 

[6] AST has experience in licensing Sea Launch’s automated TTS; however, that is a 

system that already had thousands of launches worth of heritage. If the concern is 

autonomous FDS at the national ranges, AST’s concern-level should be low. 

Autonomous FDS would be phased-in at the national ranges, and it is assumed that the 

system would be flight-tested, both as a parallel system on vehicles using manual systems 

as their primary systems and on at least one test mission designed to trigger the 

autonomous system. AST would be one of many stakeholders in such a scenario.

However, if a private company proposes an automated FDS on its vehicle, then AST has 

a vastly different situation to consider. The general verification methodology applies, 

with certain steps specifically elaborated upon here.

The first step, including understanding the applicant’s level of technological 

understanding, is extremely important. The applicant should be able to demonstrate on 

paper that the system should work and that all of the components are being utilized 

within their design-parameters. The component-test step will be important as well, 

however, the most important step will be the ability of the applicant to conduct a series of 

viable simulations exercising the system. A test-series of trajectory data – both nominal 

cases and off-nominal cases – should be fed into the system controller, and it should take 

the correction action every single time. Obviously, the system should not be armed, but 

the proper commands should be sent. This should probably be done on the bench; it may 

not be advisable – even if it might be possible – to perform this as an end-to-end test with 

hardware-in-the-loop, even if the automated FDS is supposedly safed. Such an 

automated FTS system could need to accumulate sufficient flight hours in shadow mode 

allowing it to ARM but not issue actual DESTRUCT commands so as to preclude 

inadvertent initiation of the FDS.
23

2.2.1.3.2 Automation and Evolution of Range C&C Systems

Although systems-evolution and replacement is an issue cutting-across range upgrades, it 

is of particular interest from a safety point-of-view when considering range C&C. There 

are two technology issues touched-upon by the ARTWG report which deserve special 

mention. The first is the adaptation of “software wrapping” programs to use for range 

C&C. Boeing is developing software to “wrap-around” legacy avionics software and 

new software, allowing both to operate in a new upgraded system [6]. Again, though 

AST will be one of many stakeholders, this is of particular interest. Standard software 

testing methodologies (e.g., development-test, system-test, acceptance-test) should apply, 

and, as indicated previously, all system functionality should be assessed. Likewise, 

IVHM technology is mentioned in the context of monitoring range C&C system health 

and predicting and isolating failures. [6]

2.2.1.4 Other Areas of Interest

In the remaining range-centric non-traditional flight safety systems categories detailed in 

the ARTWG report are several other areas with some level of technology development. 

In general, the remaining areas speak to greater integration and standardization of tools 

and activities. One of these areas that is of specific interest to AST at this time is that of 

creating improved suites of tools to aid in decision-making support. The current tools are 

mostly stand-alone and are not necessarily standardized across the ranges; however, the 

vision is to have an automated suite of tools which is integrated with FAA SATMS. [6]

One other area of interest which was noted was that better modeling of atmospheric drag 

may be needed in computing instantaneous impact points (IIP). Errors in the Maxus-4 

sounding-rocket IIP calculation were assessed to stem from “residual atmospheric drag 

between burn-out and an altitude of about 45 km, which is not accounted for in the 

common IIP prediction models.” [19] This may be an area for further study, or it may be 

simply a case of not choosing the correct model for one’s mission and/or accounting for 

all variable when selecting a model. 

2.2.2 Enabling Technologies and Verification Methods for Vehicle-Centric FSS

The FSS methodologies described in Section 2.1.2 actually form a concept of operations 

for RLV flight safety. For gliding RLVs, the loitering-based flight safety methodologies 

will not be applicable, but the remainder of the discussions apply. This report is not 

meant to detail all of the safety-critical systems of an RLV; that has been accomplished 

previous to this effort; rather, this section of this report will detail the technologies or 

systems crucial to the operation of vehicle-centric flight safety systems. Specifically, the 

discussions below will concern vehicle systems as they apply to the proper operation of 

the FSS. Specific issues which call for AST verification will be noted parenthetically 

where appropriate.
24

2.2.2.1 Vehicle Command & Control Link

This vehicle system is not FSS-critical for crewed-RLVs. Moreover, it is the failure of 

the C&C link which will engage the FSS for non-crewed RLVs, both during ascent and 

descent. However, the system is critical to remote RLV FSS operation in the case of a 

vehicle system failure necessitating mission abort during ascent or descent of a vehicle 

without crew interaction (i.e., either a non-crewed vehicle or a vehicle in which the crew 

has become incapacitated). If there are any vehicle attitudes which could cause the link 

to be severed, these should be identified and abort-contingencies should be designed 

accordingly (This is a verification item). If C&C loss is nominal during certain flight 

regimes (late in the launch regime or during atmospheric reentry), flight safety 

procedures should reflect it. (Verification item).

2.2.2.2 Vehicle Command & Control Software

For non-crewed RLVs, the C&C software will control the flight of the vehicle when the 

FSS is activated (excepting when a remote site still has control of the vehic le and 

activates the VRS directly). All of the flight-safing modes detailed in Section 2.1.2.2.1 

will require the vehicle C&C software. The C&C software must therefore be verified, 

using the general methodology, to execute throughout the operating environment. This 

does not imply the actual vehicle aborts should be flown; however, software testing 

should examine all flight-safing modes to be used. Hardware-in-the-loop simulations 

would not be inappropriate. It would also be appropriate for vehicle flight testing 

(especially early in the flight-test program) to verify that the C&C software will take over 

powered-flight in the atmosphere and execute the appropriate flight-safing methods 

(traveling to waypoint and circling, gaining altitude, etc.) if the C&C link is lost. It is 

also important, if the vehicle is so-designed, to verify that the C&C system will take over 

vehicle operation of a crewed vehicle if the crew is incapacitated or as designed if the 

maneuvers for energy management to be flown are very complex as it may well be for 

certain aborts. The logic for determining if it is appropriate for the vehicle to take-over 

control will be of special consideration. Verification of this could be accomplished 

during hardware-in-the-loop simulations or during systems-test. The ability of the 

vehicle to select a landing area as a function of crew health should be verified via 

software systems testing if the vehicle is designed to do so. Likewise, if a vehicle is to be 

remotely-controlled in the case of crew incapacitation, the ability for C&C hand-off 

should be verified.

Lastly, for future systems with a high-degree of AI, the ability to find appropriate areas 

for emergency landing or VRS deployment would also be appropriate. The conducting of 

actual emergency landings or VRS deployment would not be necessary, but the finding of 

an appropriate area could be conducted during flight test by overflying an area not in the 

vehicle’s database.
25

2.2.2.3 Vehicle Flight Control Systems and Vehicle Structure

Concerning the flight-control hardware and the vehicle structure, AST should verify the 

ability of the flight control systems and the structure to physically withstand the abort 

environments – especially launch aborts. This should be done via independent analysis 

as well as via assessment of an applicant’s analysis. If certain abort modes are shown to 

place undue stress on the flight control hardware such that it’s functioning cannot be 

guaranteed (or the vehicle’s structural integrity guaranteed), then the IIP of the vehicle or 

the instantaneous impact zone (IIZ) of the vehicle’s debris should be considered 

appropriately (e.g., figured in to the casualty expectation calculations considering the 

probability of the event during the appropriate timeframe). 

The vehicle flight control software is the software which actually moves the flight control 

systems that the C&C software orders to be moved. The operation of this software 

should be noted during hardware-in-the-loop simulations. 

2.2.2.4 Vehicle Guidance & Navigation (G&N)

The vehicle G&N systems’ ability to operate throughout the abort-regime should be 

verified through steps 1 and 2 and the simulation segment of step 4 of the general 

verification methodology. Like the C&C link, any attitude which could cause an inability 

for the vehicle’s G&N systems to receive pertinent data (e.g., vehicle blocking of GPS 

signals) should be accounted for in the abort plans. It is likely that all RLVs will have 

some sort of internal navigational capability, such as an IMU, as a minimum. This 

should be tested and verified according to the standard verification methodology. This 

could include simulations where data could be fed to the IMU to simulate situations 

requiring the activation of the FSS.

2.2.2.5 Propulsion & Fuel

The consideration of the starting of the vehicle’s propulsion system during nominal postreentry atmospheric flight will be considered during nominal vehicle safety review 

activities. However, the ability of the propulsion system to start and to operate during an 

abort scenario (especially a launch abort) should be verified. Since asking an applicant to 

abort a launch is not feasible, the verification will have to rely upon independent analysis 

of the propulsion system and assessment of the applicant’s analysis. Any previous flight 

experience in a flight-regime similar to or equivalent to the vehicle’s abort flight regime 

by the vehicle under consideration of any other vehicle would be applicable (though 

probably rare). For post-reentry flight-safing modes, the primary concern will be the 

time-of-use for the propulsion system. If extended use of the system would have an 

undue effect on the vehicle, independent analysis and assessment will have to suffice. 

However, if the most extreme limit for atmospheric flight is two hours and the applicant 

is planning a two-hour flight test, verification should be straightforward.

For some vehicles, fuel dumping may be an action called for by some flight-safing 

modes. If so, AST should verify the ability of the vehicle to dump fuel. Fuel-dumping 
26

will be part of the environmental impact study, and should be assessed relative to routine 

commercial aviation fuel-dumping activities. As with the propulsion system, applicant 

flight-testing of this ability would cause its verification to be straight-forward; otherwise, 

independent analysis, assessment, and commonality with extant systems already used will 

have to suffice. 

2.2.2.5 Thermal Protection/Thermal Control 

The main concern is the ability of the thermal protection and thermal control systems to 

protect the vehicle’s systems in the case of an off-nominal atmospheric reentry. The 

temperatures at which vehicle systems (including structure, flight control hardware, 

“wiring”, etc) start to fail should be known for each system. IVHM systems would prove 

quite valuable for this case. If the vehicle undergoes an off-nominal reentry and is then 

indicating – either through its performance or via sensor readings – that it is not healthy, 

the proper steps should be taken – up-to and including VRS deployment. If the VRS is 

suspected of being impaired, then the vehicle should be commanded (or should execute 

an autonomous flight-safing mode) to fly to a non-populated area for attempted VRS 

deployment or “ditching.” The only issue for verification is for AST to be familiar with 

vehicle heating conditions as a function of trajectory profile.

2.2.2.6 Vehicle Recovery System (VRS)

Some RLVs may choose to have a VRS. Other RLVs may have a nominal landing 

system which doubles as a VRS (Kistler K-1). Other RLV designers may decide that the 

mass-penalty, cost, and complexity of a VRS preclude its use for their vehicle. This 

section is not meant to indicate whether a VRSs should be mandatory for all RLVs; this 

section does not assume that all RLVs have VRSs. This section will address the use of 

VRSs for those RLVs which will utilize them.

It is not likely that an applicant will conduct a full test of the VRS during flight testing. 

Therefore, verification will have to depend on independent analysis, applicant 

assessment, and system test. The effect of the reentry environment and the launch-abort 

environment should be considered, so that AST can be sure that the VRS parachutes will 

deploy. The actual parachute deployment systems and, if applicable, airbag deployment 

systems should be bench-tested. And the command logic which invokes the VRS should 

be tested in mission simulations. These steps, along with analysis and assessment should 

verify the VRS to the maximum extent possible.

2.2.2.7 Crew Safety Systems

In the case of a crewed vehicle, the crew is part of the FSS. Therefore, the systems which 

ensure crew-health should be considered relative not only to the nominal vehicle 

environments but relative to vehicle launch-abort and non-nominal reentry environments. 

This should be done via independent analysis and assessment of the applicant’s analysis. 

If the vehicle is planned to have remote or autonomous flight and landing capability in 
27

case of crew incapacitation, this should be covered in the testing of the Command & 

Control system.

If the crew has a crew-escape system as part of the crew safety system, the crew escape 

may actually impair the operation of the vehicle FSS. This could be true if the crew were 

needed to execute vehicle flight (i.e., the vehicle has no autonomous flight capability); 

furthermore, the departure of a crew escape system (e.g., a pod comprising the entire 

front-end of the vehicle) could render the remainder of the vehicle aerodynamically 

unstable. If possible and practical, use of a crew-escape system should be coordinated 

with the overall issue of protecting the public from the vehicle itself.
28
29

3.0 INTEGRATED VEHICLE HEALTH MANAGEMENT (IVHM) SYSTEMS

IVHM is an area that is presently maturing. Over the past several years, the term 

“IVHM” itself has evolved from the original definition of integrated vehicle health 

monitoring system to the present accepted usage of integrated vehicle health management

system. [21, 22]. 

IVHM has two separate areas of emphasis. The first area is to use IVHM to support 

vehicle maintenance. In this role, IVHM is used to record data in-flight; that data is not 

accessed until post-flight, at which time it is used to help determine when vehicle systems 

are in need of repair or replacement. For the purposes of this report, these systems will 

be referred to as “post-flight IVHM.” 

The second area of emphasis is to use IVHM to support vehicle flight operations. In this 

role, IVHM actively manages (and therefore is also monitoring) the vehicle during flight, 

and is intended to take action in the case of component or system degradation, imminentfailure, or failure. Ideally these IVHM systems would act so as to prevent component or 

system failure that in any way would affect the safety of a mission. These systems will 

be referred to in this report as “in-flight IVHM.” 

Both the post-flight and the in-flight IVHM systems are of interest to AST. Regarding 

RLVs, post-flight IVHM systems will be relevant to maintenance issues and therefore of 

direct consequence to public safety. These systems will be discussed in this report; 

however, these IVHM systems may not necessarily be considered to be greatly 

technologically enabling. They may be greatly financially enabling since the purpose for 

their use is to be able to maximize time between component maintenance functions such 

as component replacement and system overhaul. However, the historical data and 

physical models that these systems will need to operate will still exist. In-flight IVHM, 

on the other hand, may be, to a greater extent, an enabling technology for some RLVs, 

and especially for non-crewed RLVs. 

3.1 Description of Existing and Proposed Designs for IVHM

The planned and proposed uses of IVHM will be briefly described in this section of the 

report. Advances in IVHM-related research will be described in Section 3.2, which 

covers enabling technologies and verification. 

3.1.1 Post-Flight IVHM

IVHM systems, first as “monitoring,” and more recently as “management,” have been in 

use by the airlines for over 30 years. Historically, these systems are used during 

maintenance activities to determine faults or failures in components so that those 

components may be replaced. [23] Similarly, many RLVs will be designed in such a 

manner that critical systems can be serviced when necessary. A key difference is that the 

goal of RLV maintenance is to replace safety-critical components before they fail, but not 

replace them prematurely. In order to accomplish this goal, system and component 
30

performance data will have to be captured during flight so that it can form the basis for 

system and component health assessments. This activity is prognosis, rather than 

diagnosis (which is performed after a failure or fault has occurred).

Two specific RLV manufacturers/operators who plan to or may plan to employ postflight IVHM are Kistler and Scaled Composites. Kistler is planning to use IVHM in two 

roles, the first role actually being “pre-flight” at the time of engine ignition to make sure 

that the engines are functioning properly before they are ramped up for lift-off. The 

second role is that of post-flight use for maintenance. [24] Scaled Composites plans to 

use its System Navigation Unit (SNU) to acquire and store vehicle health information for 

its Space Ship One vehicle; it is not clear if this function is part of a larger IVHM system. 

Existing IVHM systems on commercial jetliners have evolved from 1960’s era built-in 

test equipment (BITE) which was used to test line-replaceable units (LRUs). [23] LRUs 

are merely vehicle components which are replaceable “on the (flight) line.” Early 

systems were somewhat helpful, but mechanics still needed schematics and voltmeters. 

By the 1970s, digital BITE allowed mechanics to isolate faults more specifically. By 

Figure 8. SpaceShip One’s System Navigation Unit [24]

1986, the ARINC 604 allowed the maintenance indications for potentially all of an 

airplane’s systems to be brought to a single display. This is known as a Central Fault 

Display System (CFDS). CFDS was used on Boeing 737s of the time, the Airbus 

A320/220/340, and the McDonnell Douglas MD-11. CFDS is not a panacea, since 

increasingly-complex airplane systems result in situations where a single fault on the 

airplane can cause fault implications for many systems, and mechanics will still have 

difficulty sorting out which indications refer to source-faults and which indications are 

merely effects. In the 1990s, ARINC developed the 624, which defines a more integrated 

system which can consolidate fault indications from multiple systems. This system is 

probably at the level of IVHM; indeed, most of the aircraft tests can be accomplished 

using this system; very little ground support is needed. It is this type of system that is 

found on the Boeing 747-400 and 777. [23]
31

3.1.2 In-Flight IVHM

In-Flight IVHM systems will be used by RLVs to monitor and to actively manage vehicle 

components and systems during flight. The goal of IVHM systems is for these systems to 

be able to: 1) determine that a component or system is either not operating nominally or 

is actually still operating nominally but in imminent danger of beginning to operate 

abnormally, and 2) then be able to effectively manage the vehicle systems so that 

nominal vehicle flight can safely continue or be safely aborted. This is the eventual goal. 

In stepping towards that goal, IVHM systems will first deal with mitigating the effects of 

actual system or component fault or failure. 

In-use IVHM systems (of which “In-Flight” systems are really but a subset) may find use 

in systems other than RLVs before they are actually used in RLVs. One basis of morecomplex IVHM systems may be “model-based reasoning.” This is in contrast to 

heuristic-based reasoning. Heuristic-based reasoning’s shortcoming is that, as systemcomplexity grows, programmers cannot conceive of all of the possible failure-modes or 

situations that may occur. The model-based solution is to give the health management 

program a physical model of the system and let it decide what actions to take. Modelbased programs named “immobots” are under development for use in automobiles;

Toyota, DaimlerChrysler, Peugeot, BMW, and other automakers are involved with 

immobot research for the automotive industry. [26] 

Interestingly, the RLV which is perhaps closest to flight, Scaled Composites’ X-Prize 

entry SpaceShip One, has an IVHM system to shut down its hybrid rocket motor in case 

of a burn-through. It consists of a fiber-optic cable wrapped around the case liner below 

the carbon-fiber overwrap. [38]

3.2 Enabling Technologies and Verification Methods for IVHM

In the area of IVHM, the enabling quantity is really research rather than specific 

technologies; this includes basic research into expanding the body of humankind’s 

knowledge concerning analytical methodologies. There has been a fair amount of 

research conducted in the field of IVHM. Some of this research has been directed 

towards in-flight IVHM, a smaller amount has been directed towards post-flight IVHM, 

and some of the research projects have applications for both types. 

One specific enabling technology could well be a complete sea-change in how aircraft 

have historically been designed; namely, the full integration of the software and hardware 

design processes from the very beginning of aircraft design. This actually means that 

software design would have an effect on the evolution of the hardware design of an 

aerospace vehicle. Vehicles designed in this manner could truly have integrated vehicle 

health monitoring. The entire area of artificial intelligence, including neural network use, 

is enabling to both types of IVHM, though probably more-applicable to in-flight systems.

Considering the verification of IVHM systems (both post-flight and in-flight) the main 

issue is the current state-of-knowledge of anomaly detection and prognostics. Anomalies 
32

are of two types: faults and novel events. A fault is a known off-nominal condition; a 

novel event is an unknown off-nominal condition. Diagnostics identify anomalies as or 

after they occur. Prognostic algorithms are designed to respond to known faults with 

known failure modes before failure occurs. They cannot respond to novel events. [23] 

Furthermore, prognostic algorithm development is still relatively immature and the most 

common algorithms are simplistic component-life algorithms with wide variances. And 

even these algorithms need relatively large amounts of performance-history data upon 

which to be based. [23] Therefore, the verification of IVHM systems which are intended 

to predict anomalous system or component performance before it occurs will be quite 

difficult. 

In general, verification of IVHM systems which use diagnostics to determine the cause of 

off-nominal system or component performance once the performance actually is 

malfunctioning will be more straightforward. Verification of these systems can proceed

using the standard verification methodology outlined in Section 1.1. Specific issues to be 

covered would include bench-testing of the IVHM system with simulated fault data so as 

to verify the response. This should be part of an overall comprehensive test plan. 

Other verification issues include assessing the capability of the IVHM sensors to 

repeatedly and consistently operate in the vehicle’s operational environment (in-flight) 

and to operate after having repeatedly been in that environment (post-flight). This 

includes issues of temperature, acceleration, acoustics, and vibration. Specific flighttesting of in-flight IVHM may not be appropriate unless it is desired by the applicant; 

however, assessing IVHM system performance during an expanding flight-test regime 

would be appropriate.

Specific post-flight IVHM verification issues will be covered in the appropriate subsections of this report.

3.2.1 Enabling Technologies and Verification Methods for Post-Flight IVHM

The latest series of NASA experiments dealing with post-flight IVHM included the 

experiments flown on STS-95 and STS-96 in the late-1990s. The purpose of these 

experiments was “to demonstrate competing modern, off-the-shelf technologies in an 

operational environment to make informed design decisions for the eventual Orbiter

upgrade IVHM.” [27] The three stated objectives of IVHM are: 

“1. More autonomous operation in flight and on the ground, which translates to reduced 

work load on the ground controller team. Near Earth space operations provide the luxury 

of having a ground team evaluate vehicle data to make real-time decisions. On a Mars 

mission for example, there is a 40-minute time delay to send and receive a message.

Therefore, future vehicles will require more autonomous capabilities.” [27]

“2. Reduced ground processing of reusable vehicles due to increased performance of 

system health checks in flight rather than back on the ground.” [27]
33

“3. Enhanced vehicle safety due to the ability to monitor system health even inside the 

harsh environment of an engine combustion chamber as well as prediction of pending 

failures.” [27] 

The STS experiments concentrated on the second objective. [28,29] The experiments 

were driven by requirements studies which showed that ground processing (planned and 

unplanned) could potentially be reduced 15 to 20%. Planned work could be reduced by 

implementing a system with predictive capabilities to monitor subsystem health in real 

time during flight and by extending the service life of life-limited components. 

Unplanned work could be reduced by improving visibility of system health and 

streamlining problem isolation. [29]

The first of the two experiments, IVHM HTD-1, was installed on Discovery, and flown 

on STS-95 in October 1998. The IVHM HTD-2 system, also installed on Discovery, was 

flown during STS-96 in May 1999. Technologies flown and demonstrated included 

micro-electro-mechanical sensing for detecting the presence of hazardous gas and sensing 

pressure in vacuum-jacketed lines in the orbiter's cryogenic distribution system. Other 

technology demonstrations included Bragg-Grating fiber-optic sensing for hazardous gas 

detection and structural strain/temperature determination, thermal flow meter leak 

detection, accelerometers for space shuttle main engine pump vibration sensing, VME 

bus architecture, and flash card memory. [29]

Although these IVHM technologies were demonstrated for the purpose of 

implementation into post-flight IVHM systems, some of them obviously have 

applicability for in-flight IVHM.

Some of these technologies flown (Bragg-Grating fiber-optic sensing for hazardous gas 

detection) were among the planned IVHM systems to be tested for the X-33 program. 

[30] 

The specific issue regarding verification of post-flight IVHM systems is not the system 

itself but the algorithms used by the system to determine when safety-critical systems and 

components are to be serviced or replaced. AST must be able to determine that the 

component and system replacement and servicing methodologies employed by the 

applicant protect the public safety.

3.2.2 Enabling Technologies and Verification Methods for In-Flight IVHM

3.2.2.1 Deep Space One Remote Agent Experiment & Livingstone

3.2.2.1.1 Deep Space One Overview

In May, 1999, the Remote Agent Experiment (RAX) took control of the Deep Space 1 

spacecraft. This is the first time that a spacecraft was allowed to operate truly 

autonomously. The demonstration included nominal operations with goal-oriented 

commanding and closed-loop plan execution, fault protection capabilities with failure 
34

diagnosis and recovery, on-board re-planning following unrecoverable failures, and 

system-level fault protection. [31]

The Remote Agent (RA) is formed by combining three separate artificial intelligence 

systems: an on-board planner-scheduler, a robust multi-threaded executive, and 

Livingstone. [31]

Livingstone is considered the centerpiece of the RA. [32] It is the software kernel for 

model-based reactive self-configuring autonomous systems, and, as such, served as the 

fault-diagnosis and recovery system. [32, 31]

3.2.2.1.2 Livingstone Description

The following is the description of Livingstone from NASA’s Model-based Diagnosis 

and Recovery Group, Computational Sciences Division:

“Livingstone accepts a model of the components of a complex system such as a 

spacecraft or chemical plant and infers from them the overall behavior of the system. It 

also notes which commands are being given to the system and what observations are 

available. From this, it is able to monitor the operation of the system, diagnose its current 

state, determine if sensors are giving impossible readings, recommend actions to put the 

system into a desired state even in the face of failures and so on. ” [32]

“Because Livingstone reasons about explicit models of the system it is interacting with, 

rather than following a program or rules, a Livingstone-based controller is highly 

capable, flexible and easy to maintain. Livingstone also takes into account all available 

information and observations, drawing conclusions which reach across a complex system 

in a way which would be difficult for a traditional software system or time consuming for 

a human operator.” [32]

“Livingstone is able to perform significant deduction in the sense/response loop by 

drawing on our past experience at building fast propositional conflict-based algorithms 

for model-based diagnosis, and by framing a model-based configuration manager as a 

propositional feedback controller that generates focused, optimal responses. Livingstone's 

representation formalism achieves broad coverage of hybrid hardware/software systems 

by coupling the transition system models underlying concurrent reactive languages with 

the qualitative representations developed in model-based reasoning. Livingstone 

automates a wide variety of tasks using a single model and a single core algorithm, thus 

making significant progress towards achieving a central goal of model-based reasoning. ”

[32]

3.2.2.1.3 Specific Deep Space 1 Autonomous Flight Activities

Since this mission is the first – and, to date, only – example of autonomous space flight, 

specific RA actions of interest will be described.
35

The very first RA activity was the generation of activity plan. The plan generated inflight was different from the plan generated during ground-test; however, it was later 

determined that the location of the target-asteroid (of which pictures were to be taken) 

was actually slightly different than had been coded during ground-test. This action 

demonstrated the “robustness” of the planner/scheduler. [31]

The next activity of note was the simulated failure of a camera power switch such that it 

was stuck in the on position. The RA reacted by attempting to toggle the switch on/off; 

when this failed, the RA took appropriate corrective action by altering the planned 

navigational maneuvers such that they could be accomplished with the diminished power 

available (given the power being sent to the camera which would have been sent to other 

spacecraft systems). [26]

The final activity of note was an actual (unplanned) failure. The RA became deadlocked 

due to a “race condition” supposedly caused by a missing section of the plan execution 

code, and had to be reset via a command from the ground. [31] If the RA was the only 

means of spacecraft operation, this would have been a fatal error.

3.2.2.1.4 The Deep Space 1 Remote Agent’s Shortcomings

Autonomous controllers are typically multi-threaded, meaning that different concurrent 

parts of the controller execute together. This can lead to the controller reacting in 

different ways to the same stimuli. [33] This would be of concern to AST for verification 

purposes.

According to one of its developers, Livingstone’s deductive algorithms do not explore the 

complete diagnosis-space, they do not rule-out all inconsistent diagnoses, and they do not 

maintain proper ranking of diagnoses in terms of posterior probability. [24]

Finally, the “race” condition that caused the RA to be stopped was not discovered after a 

year’s worth of rigorous testing of the scheduler; however, a similar problem was 

discovered using Formal Methods (runtime monitoring, static analysis, model checking, 

and theorem proving). [33] The RA verification program as originally constructed was 

inadequate.

3.2.2.2 X-37 IVHM Experiments

The X-37 IVHM Experiments have been cancelled. However, a detailing of the 

experiments is appropriate in case the funding for them is restored.

The scope of the experiment was to perform real-time fault detection and isolation for the 

X-37’s electrical power system (EPS) and electro-mechanical actuators (EMAs). The 

experiment utilized Livingstone. The IVHM software was planned to assess the health of 

the X-37 control surface and nosewheel EMAs and associated EPS status during all 

mission phases, with an emphasis on pre-de-orbit checkouts, re-entry, and pre- and postlaunch. The results that were obtained and reported upon were from normal scenario and 
36

random failure testing on a PowerPC. All of the PC-based tests were successful: for a 

nominal 21-day mission, a for a Monte Carlo of 11 21-day missions with random failures 

generated. [35] It should be noted that the definition of “success” in this case is the 

response of the system to the random failures (i.e., the system did not crash) rather then 

gauging the actual system action commanded for each failure. This experiment is the 

most applicable to AST’s RLV concerns; if it can be resurrected, it would be most 

beneficial.

Figure 9. X-37 Spaceplane [44]

3.2.2.3 Virtual Propulsion System Experiment

As a part of the NASA Propulsion IVHM Technology Experiment (PITEX) NASA 

researchers demonstrated the successful real-time fault detection and isolation of a virtual 

main propulsion system. The following is from a report on the experiment. “Using a 

detailed simulation of a vehicle propulsion system to produce synthesized sensor 

readings, the NASA team demonstrated that advanced diagnostic algorithms, running on 

actual flight-class computers, could successfully diagnose the presence and cause of 

faults in real time.” [36]

“The researchers developed a detailed simulation of a main propulsion feed system, 

which was run under both nominal and fault conditions to generate time histories of 

propulsion system parameters. Noise was then superimposed on the simulation output to 

provide realistic sensor signals. Typical propulsion system failures, such as valves 

sticking open or closed, regulator problems and sensor and microswitch failures, were 

injected at various points in a simulated mission. ” [36]

“The simulated data were fed, in real time, to IVHM software running on a computer that 

is a commercial-grade version of actual flight hardware. ‘In all cases, the PITEX 

diagnostic software detected and isolated the injected fault correctly,’ said Claudia Meyer 

of GRC, PITEX team lead.” The diagnostic software is based upon Livingstone. [36] 
37

3.2.2.4 Intelligent Flight Control

Although intelligent flight control technology may be considered at the extreme fringe of 

in-flight IVHM, recent simulations at NASA Ames should be of interest to AST. An 

intelligent flight control (IFC) system in a C-17 simulator has demonstrated the ability to 

assess a plane’s condition and automatically adjust the flight-controls to compensate for 

damaged or malfunctioning flight control surfaces. In one example, the system was able 

to successfully fly the simulator in a smooth and controlled fashion after a simulated 

missile strike severely damaged the right wing and the right side of the aircraft. The 

person piloting the simulator at the time could not bring the simulator under control; 

when the IFC was activated, the aircraft simulator immediately recovered and flew 

normally. The system utilizes a “self-learning” adaptive neural network, and is scheduled 

to be installed in an F-15 for flight tests at NASA-Dryden Test Flight Center in October, 

2003. [37]
38
39

4.0 SUMMARY

RLVs are in their infancy. Some X-Prize class vehicles are actually under construction, 

and at least one is in unpowered flight-testing as of the writing of this paper. However, 

the X-Prize vehicles lie at the very lowest segment of the RLV flight dynamics regime. 

Given their simplicity, their budgetary restrictions, and their piloted nature, there is no 

real need for X-Prize vehicles to have complex IVHM systems; there has also been a 

limited awareness of FSS by X-Prize vehicle designers. Sub-orbital RLVs with 

significant downrange footprints and orbital RLVs – to which full-fledged IVHM 

systems and FSS concerns are probably more significant – are still very much in the 

nascent stage of development; there has been correspondingly only a limited amount of 

actual development regarding FSS and IVHM systems for “major” RLVs. 

Flight safety paradigms for RLVs will draw from both the ELV experience and from the 

present and evolving state of UAV flight safety. For launch operations, flight safety 

systems and procedures for RLVs will have a great commonality with existing and future 

ELV FSS – especially for those RLVs which will operate in a manner most similar to 

ELVs (e.g., vertical rocket-powered launch to orbit). The evolution of range-based FSS 

at the national ranges and existing commercial ranges will serve both ELVs and future 

RLVs. There will also be a great commonality with Space Shuttle operations for “major” 

RLV flight safety systems and procedures during launch with regard to abort options and 

capabilities. 

The trends in launch-range operations are the movement towards a “space-based” range

and the movement towards greater automation of activities, with an eye towards eventual 

autonomous range operation with manual override capability. These two trends are 

related since the “space-based” range, which will be based upon the ability of launch 

vehicles to receive signals from the GPS constellation so that their position and velocity 

can be determined, will replace human-power intensive ground-based radar systems.

The FSS-related material pertinent to post-reentry atmospheric flight operations of 

uncrewed RLVs presented in this paper is mainly notional in nature, but based upon 

current UAV capabilities. This is due to the fact that, other than a few X-Prize vehicles 

and the Kistler K-1, RLVs remain basically “paper vehicles” at the present time. The 

majority of the material presented concentrates on the actions to be taken by uncrewed

RLVs so as to protect public safety. Excepting vehicle-recovery, flight safety during the 

post-atmospheric-reentry flight phase for crewed RLVs is not of the same level of 

concern, since the human crew will be able to take appropriate actions.

IVHM systems can be divided into two categories: systems which support post-flight 

maintenance activities and systems which manage the in-flight health of a vehicle. Postflight IVHM systems are themselves developing from two separate sources: the 

maintenance-based line-replaceable-unit (LRU) fault-detection systems used by 

commercial airliners (which have been evolving for more than 30 years) and the IVHM 

research being conducted by NASA and industry. In-flight IVHM research is being 

conducted by NASA, and the first experiment in which a satellite was allowed to operate 
40

completely autonomously was conducted in May, 1999 (Deep Space One). It should be 

noted that, although the experiment completed most of its goals, it did end up “lockedup,” and if ground-control had not been available to restart the system, the error would 

have been fatal. A more modest, but no-less important IVHM application, is the fiberoptic cable being used as an IVHM system on Scaled Composite’s “SpaceShip One ” 

vehicle. 

The most important issue of concern for AST regarding IVHM is actually the diagnostic 

and prognostic algorithms used to determine if a system or component is about to fail. It 

is one thing for an IVHM system to cue off of an actual system or component failure or 

near-failure (e.g., a critical temperature rise). This is one method by which both in-flight 

and post-flight IVHM can be conducted. SpaceShip One’s system, which covers only 

one component, the rocket motor casing, works in this method – if the casing suffers a 

burn-through, the light passing through the fiber-optic cable is interrupted, which 

prompts the cessation of oxidizer flow to the hybrid rocket motor, thus causing thrust 

termination. However, an IVHM system which attempts to prognosticate when a 

component or system is going to fail before it does so must rely on algorithms – and the 

development of such algorithms is still in its infancy. As opposed to prognostic 

algorithms, relying on diagnostics in an IVHM system to determine the cause of a fault is

a technology which has been evolving for decades. In either case, it is the algorithms 

themselves which will be of interest to AST for purposes of regulatory sufficiency.

4.1 Re-visiting FSS and IVHM and Future Research Areas Based on this Report

AST is already keeping well abreast of range-based FSS advancements, and should 

continue to do so. In general, AST should re-visit range-based flight safety issues for 

RLVs as the development of RLVs using the ranges warrants. The X-Prize vehicles

should be dealt with on a case-by-case basis; there may arise range-based FSS issues 

unique to some of these vehicles which merit investigation. 

Likewise, vehicle-based (and especially post-reentry related) flight safety issues should 

be re-examined as RLV development warrants. AST should continue, and may wish to 

expand, its interaction with and awareness of the UAV community and its operations –

especially its operations in the National Airspace System.

Some areas for future research or suggested future studies, beyond the research into 

autonomous landing, crew escape, and failsafe-reentry (which has already commenced),

include:

• UAV FSS reliability characterization

• UAV semi/fully-autonomous flight reliability

• A comparison of launch vehicle Instantaneous Impact Point (IIP) prediction based 

on wind-tunnel testing and computational fluid dynamics calculations to IIP 

predictions created from empirical models

• The change in casualty expectation when aero-thermal structural demise of a 

vehicle is accounted for
41

• Atmospheric propulsion (e.g., jet engine) start reliability in the post-reentry 

dynamic environment

• An examination of the difference in environmental concerns for a sub-orbital 

RLV mission as compared to a typical ELV mission
42
43

5.0 REFERENCES

1. International Reference Guide to Space Launch Systems, 3rd Edition. S. Isakowitz, J.P 

Hopkins, Jr., J.B. Hopkins. American Institute of Aeronautics & Astronautics, Reston, 

VA. 1999. Bibliography #56

2. Commercial Launch Baseline Assessment – U.S. Air Force Eastern Space & Missile 

Center. L. Parker et. al. Research Triangle Institute, 1988. Bibliography #57

3. “Comparison of Autonomous Thrust Termination Systems and Human-Command 

Flight Termination (Destruct) Systems,” T. Mullikin, M. Fudge. Sept. 19, 1997. 

Bibliography #53

4. Websites: Interorbital Systems. http://www.translunar.org/Expeditions.htm July 28, 

2003. Bibliography #58

5. Discussions with Mr. Stewart Jackson & Mr. Daniel Murray, FAA-AST. July, 2003

6. Advanced Range Technology Working Group Roadmap Report (Draft), May 9, 2003. 

Bibliography #59

7. Website: BAI Aerosystems. http://www.baiaerosystems.com/tairveh.html 

Bibliography #63

8. Airman Magazine. November, 2001. 

http://www.af.mil/news/airman/1101/hawk.html Bibliography #64

9. Website: Aerosonde. http://www.aerosonde.com/drawarticle/5 Bibliography #65

10. Memorandum from Mr. Mike Fudge, ITT to Mr. Stewart Jackson, FAA-AST; 

October 14, 1999. “Perseus B Remotely Piloted Vehicle (RPV) Incident.” Bibliography 

#60

11. Website: UAV Forum, “Vehicles” page 

http://www.uavforum.com/vehicles/vehicles.htm Bibliography #61

12. Website: Encyclopedia Astronautica – Rockets listed by propellant type: 

http://www.astronautix.com/stages/stattype.htm Bibliography #62

13. Website: X-Prize. www.xprize.org Bibliography #66.

14. “Flight Demonstrations Evaluate UAV Collision-Avoidance Technology.” Dryden 

Flight Research Center News Release 03-20. April 3, 2003 Bibliography #48
44

15. “A Radiation-Tolerant Low-Power Transceiver Design for Reconfigurable 

Applications.” D. Weigand, M. Harlacher, ITT Industries Advanced Engineering & 

Sciences Division. Reston, VA. Bibliography #43

16. “A Flexible GPS Tracking System for Sub-Orbital and Space Vehicles.” M. 

Markgraf, O. Montenbruck, S. Leung, DLR, German Space Operations Center. 

Bibliography #46

17. Website: Orbital Corporation – Suborbital Rocket Testbeds. 

http://www.orbital.com/LaunchVehicle/AdvancedSystemsTestbeds/Testbeds/ 

Bibliography #67

18. Website: L-3 Communications Interstate Electronics Corporation, SWS Engineering 

Services, Range Safety and Communications Systems. 

http://www.iechome.com/pages/products/SWSrngSaf.html Bibliography #68

19. “Instantaneous Impact Point Prediction for Sounding Rockets – Perspectives and 

Limtations.” M. Markgraf, O. Mont enbruck, P. Turner, DLR, German Space Operations 

Center. M. Viertotak, Swedish Space Corporation. Bibliography #47

20. “GPS Receiver Selection and Testing for Launch and Orbital Vehicles.” K. Schrock, 

T. Freestone, L. Bell, NASA MSFC. Bibliography #45

21. Website: X-33 Vehicle Health Monitoring Systems

http://nesb.larc.nasa.gov/NESB/ndetasks/2000/x-33.html Bibliography #39

22. “Flight Demonstration of X-33 Vehicle Health Management System Components on 

the F/A-18 Systems Research Aircraft.” K. Schweikhard, W.L. Richards, J. Theisen, 

NASA Dryden Research Center; W. Mouyos and R. Garbos, BAE Systems, Nashua, 

New Hampshire. 2001. NASA/TM-2001-209037. Bibliography #49

23. “An Evolvable Tri-Reasoner IVHM System.” L. Atlas, et. al. The Boeing Company, 

1999. Bibliography #50

24. Description of Scaled Composites’ Spaceship One & White Knight Flight 

Navigation Unit. 

http://www.scaled.com/projects/tierone/New_Index/data_sheets/html/flight_nav.htm 

Bibliography #51

25. Personal Communication with Paul Birkeland, Space Technology Group (formerly 

with Kistler and presently consulting for Kistler). Note – Mr. Birkeland gave his 

assurance that the information he provided was already contained in information 

previously submitted to AST.
45

26. “Immobots Take Control,” Wade Roush. Technology Review Dec 2002/Jan 2003. 

Bibliography #3

27. Website: Space Shuttle Integrated Vehicle Health Management (IVHM) Flight 

Experiment. http://technology.ksc.nasa.gov/WWWaccess/techreports/98report/10-

ei/ei01.html Bibliography #8

28. “Mission Highlights STS-95.” Oct. 1998. Bibliography #38

29. Website: Integrated Vehicle Health Monitoring HEDS Technology Demonstration 2, 

STS-96. Rick Husband. http://www.shuttlepresskit.com/sts-96/payload27.htm 

Bibliography #52

30. Website: “X-33 Integrated Vehicle Health Monitoring (IVHM).” 

http://nesb.larc.nasa.gov/NESB/ndetasks/2000/x-33.html Bibliography #39

31. “Validating the DS1 Remote Agent Experiment,” P. Pandurang Nayak, Douglas 

Bernard, Gregory Dorais, Edward Gamble, Bob Kanefsky, Jr., James Kurien, William 

Millar, Nicola Muscettola, Kanna Rajan, Nicolas Rouquette, Benjamin Smith, William 

Taylor, Yu-Wen Tung. Bibliography #31

32. Website: Model-based Diagnosis and Recovery Group, Computational Sciences 

Division. “Livingstone” description. http://icwww.arc.nasa.gov/ic/projects/mba/projects/livingstone.html Bibliography #19

33. “V&V of Advanced Systems at NASA.” Jan 25, 2002. Stacy Nelson, CSC. Charles 

Pecheur, RIACS. NASA ARC. Bibliogarphy #9

34. “Model-based Programming as Estimating, Planning, and Executing based on 

Hidden State,” Brian C. Williams, AI & Space Systems Labs, MIT. IS Program Review, 

Sep 5, 2002. Bibliography #24

35. The NASA Integrated Vehicle Health Management technology experiment for X37,” Mark Schwabacher, Jeff Samuels, NASA Ames MS269-3. Lee Brownston, QSS 

Group, Inc. 2002 SPIE. Bibliography #14

36. “Virtual Propulsion System Meets Real-Time Diagnostic System.” NASA Aerospace 

Technology Innovation Volume 10, Number 5 Sep/Oct 2002 - Aerospace Technology 

Development. Bibliography #4

37. Website: NASA Computational Sciences Division, Intelligent Flight Control 

Information. http://ic-www.arc.nasa.gov/story.php?sid=81&sec=air Bibliography #69

38. Aviation Week & Space Technology Magazine, April 21, 2003. pp.64-73 

Bibliography #55
46

39. Website: Scaled Composites SpaceShip One (foreground). 

http://www.scaled.com/projects/tierone/New_Index/photos/images/800

/Space%20program%20elements%20800.jpg. Figure 1 in Report

40. Website: Canadian Arrow, Pre-Launch and Liftoff. 

http://www.canadianarrow.com/ascent.htm Figure 2 in Report

41. Website: Global Hawk UAV. http://www.sdauvsi.org/images/globalhawk/pages/globalhawk.htm Figure 4 in Report

42. Websites: The Aerosonde UAV and its Flightpath across the Atlantic. 

http://www.aerosonde.com; http://www.aerosonde.com/drawarticle/42 Figure 5 in 

Report

43. Website: Kistler K-1 First Stage with Parachutes & Airbags Deployed. 

http://www.kistleraerospace.com/flightprofile/fpmain.html# Figure 6 in Report

44. Website: X-37 Spaceplane. 

http://www.spaceandtech.com/spacedata/rlvs/x37_sum.shtml Figure 9 in Report
47

6.0 BIBLIOGRAPHY

1. “Distributed Autonomous Control of Space Habitats.” David Kortenkamp & R Peter 

Bonasso, NASA JSC ER2 and Devika Subramanian, Rice University. 2001 IEEE 0-

7803-6599-2/01

2. “Intelligent Control of Life Support for Space Missions,” Debra Schreckenghost, 

Carroll Thronesbery, Peter Bonasso, David Kortenkamp, and Cheryl Martin, NASA JSC. 

IEEE Intelligent Systems Sep/Oct 2002.

3. “Immobots Take Control,” Wade Roush. Technology Review Dec 2002/Jan 2003.

4. “Virtual Propulsion System Meets Real-Time Diagnostic System.” NASA Aerospace 

Technology Innovation Volume 10, Number 5 Sep/Oct 2002 - Aerospace Technology 

Development. 

5. “Autonomous Sequencing and Model-based Fault Protection for Space 

Interferometry.” Michel Ingham, Brian Williams Space Systems Laboratory MIT, 

Thomas Lockhart, Amalaye Oyake, Micah Clark, Abdullah Aljabri, JPL Caltech.

6. “J.V. 2020 and Beyond: Implications for Intelligent Support Architectures.” K. Keller, 

T. Wilmening, The Boeing Corporation – Phantom Works. Sept. 30, 2002. Presentation.

7. Autonomous Non-Destructive Evaluation (NDE). Patrick H. Johnston, NASA LaRC. 

April 4, 2000.

8. Website: Space Shuttle Integrated Vehicle Health Management (IVHM) Flight 

Experiment. http://technology.ksc.nasa.gov/WWWaccess/techreports/98report/10-

ei/ei01.html

9. “V&V of Advanced Systems at NASA.” Jan 25, 2002. Stacy Nelson, CSC. Charles 

Pecheur, RIACS. NASA ARC. 

10. “Survey of NASA V&V Processes/Methods.” Oct 24, 2001. Stacy Nelson, CSC. 

Charles Pecheur, RIACS. NASA ARC. 

11. “(Reduced Public Version) New V&V Tools for Diagnostic Modeling Environment 

(DME)” Jan 25, 2001. Stacy Nelson, CSC. Charles Pecheur, RIACS. NASA ARC. 

12. “X-37 Demonstrator to Test Future Launch Technologies in Orbit and Reentry 

Environments.” NASA Fact Sheet FS-2003-05-65 May 2003. 

13. “Integrated Space Transportation Plan.” NASA March 2002. Space Launch 

Initiative.
48

14. “The NASA Integrated Vehicle Health Management technology experiment for X37,” Mark Schwabacher, Jeff Samuels, NASA Ames MS269-3. Lee Brownston, QSS 

Group, Inc. 2002 SPIE

15. “Advanced Range Safety System for High-Energy Vehicles,” Jeffrey S. Claxton, 

Range Safety Systems Office NASA-Dryden. Donald F. Linton, Infoware Systems. 

AIAA. 

16. “A Multi-Role RLV for Evolving Space Markets,” Debra Facktor Lepore, Kistler 

Aerospace Corp.

17. “Streamlining Space Launch Range Safety: Chapter 4, Flight Safety Requirements.” 

Committee on Space Launch Range Safety, Aeronautics and Space Engineering Board, 

National Research Council. 2000

18. “Livingstone (L2) in Integrated Vehicle Health Management,” Sandra Hayden, Ann 

Patterson-Hine and Scott Poll, NASA Ames Research Center. Presentation

19. Website: Model-based Diagnosis and Recovery Group, Computational Sciences 

Division. “Livingstone ” description. http://icwww.arc.nasa.gov/ic/projects/mba/projects/livingstone.html

20. “A Model-based Approach to Reactive Self-Configuring Systems,” Brian C. 

Williams and P. Pandurang Nayak, Recom Technologie s, NASA Ames. In Proceedings 

of AAAI-96.

21. “Model-directed Autonomous Systems,” (presentation) James Kurien, Autonomous 

Systems Group, Computational Sciences Division, NASA-Ames. 06/20/98.

22. “Health Management for NASA Second-Generation Reusable Launch Vehicles,” 

Wade D. Dorland, AI Signal Research Inc. 256-551-0008. Article in Sep 2002 MFPT 

Forum.

23. Website: Dr. Brian C. Williams Webpage – Lists/Links published papers. Reactive 

Agent information. http://www.ai.mit.edu/people/williams/williams.shtml

24. “Model-based Programming as Estimating, Planning, and Executing based on 

Hidden State,” Brian C. Williams, AI & Space Systems Labs, MIT. IS Program Review, 

Sep 5, 2002.

25. “A Hybrid Discrete/Continuous System for Health Management and Control,” Brian 

Williams (MIT), David Kortenkamp (Metrica), Michael Hofbaur (MIT/AI)
49

26. “An implemented architecture integrating onboard planning, scheduling, execution, 

diagnosis, monitoring and control for autonomous spacecraft,” Barney Pell, Douglas E. 

Bernard, Steve A. Chien, Erann Gat, Nicola Muscettola, P. Pandurang Nayak, Michael D. 

Wagner, Brian C. Williams, January 17, 1996.

27. “Space Launch Initiative Technology Summary: IVHM,” Space Launch Initiative 

News, June 19, 2002. 

28. NASA-Ames News Release June 17, 2002 “Diagnostic Software to Keep Launch 

Vehicles Healthy.”

29. “OMS Integrated Vehicle Health Management (IVHM) Testbed,” (1996?)

30. “Spacecraft Autonomy Flight Experience: The DS1 Remote Agent Experiment,” 

Douglas Bernard, Gregory Dorais, Edward Gamble, Bob Kanefsky, James Kurien, Guy 

K. Man, William Millar, Nicola Muscettola, P. Pandurang Nayak, Kanna Rajan, Nicolas 

Rouquette, Benjamin Smith, William Taylor, Yu-Wen Tung. AIAA-99-4512.

31. “Validating the DS1 Remote Agent Experiment,” P. Pandurang Nayak, Douglas 

Bernard, Gregory Dorais, Edward Gamble, Bob Kanefsky, Jr., James Kurien, William 

Millar, Nicola Muscettola, Kanna Rajan, Nicolas Rouquette, Benjamin Smith, William 

Taylor, Yu-Wen Tung.

32. “Integrated Vehicle Health Management (IVHM)” Dean Hooks & Chris Reisig, 

Boeing Phantom Works, Oct 2002. NDIA 5th Annual Systems Engineering Conference.

33. “Mission Highlights STS-96,” May, 1999. NASA-JSC.

34. “The New Millennium Remote Agent: To Boldly Go Where No AI System Has 

Gone Before,” Nicola Muscettola, Pandu Nayak, Barney Pell, Brian Williams, March 29, 

1998.

35. Website: NASA Model-based Diagnosis and Recovery Group. http://icwww.arc.nasa.gov/ic/projects/mba/index.html

36. “Remote Agent Experiment,” Deep Space One Technology Validation Symposium, 

Feb. 8-9, 2000.

37. “Concept Documentation: Bimese TSTO ETO RLV. ROSETTA Model 1.22.III. 15 

April 2001. John Olds, Andy Crocker, John Bradford, A.C. Charania.

38. “Mission Highlights STS-95.” Oct. 1998. NASA-JSC

39. Website: “X-33 Integrated Vehicle Health Monitoring (IVHM).” 

http://nesb.larc.nasa.gov/NESB/ndetasks/2000/x-33.html
50

40. X-34 IVHM Presentation Delivered at “AeroVision 2000 – New Technology for the 

New Millennium.” Slide 12. Vancouver, Canada. October 5, 1999.

41. “A Mach 8 Vehicle on the RLV Frontier,” Aviation Week, April 26, 1999. 

42. “NASA IVHM Technology Experiment for X-37,” M. Schwabacher. Space 

Transportation Technology, IVHM Session. Presentation.

43. “A Radiation-Tolerant Low-Power Transceiver Design for Reconfigurable 

Applications.” D. Weigand, M. Harlacher, ITT Industries Advanced Engineering & 

Sciences Division. Reston, VA

44. “Concept of NASA Space Network (SN) Support for Range Safety.” T. Sobchak, 

NASA-GFSC; J. Smith and D. Lumsden, Lockheed-Martin, Seabrook, MD

45. “GPS Receiver Selection and Testing for Launch and Orbital Vehicles.” K. Schrock, 

T. Freestone, L. Bell, NASA MSFC.

46. “A Flexible GPS Tracking System for Sub-Orbital and Space Vehicles.” M. 

Markgraf, O. Montenbruck, S. Leung, DLR, German Space Operations Center.

47. “Instantaneous Impact Point Prediction for Sounding Rockets – Perspectives and 

Limtations.” M. Markgraf, O. Montenbruck, P. Turner, DLR, German Space Operations 

Center. M. Viertotak, Swedish Space Corporation.

48. “Flight Demonstrations Evaluate UAV Collision-Avoidance Technology.” Dryden 

Flight Research Center News Release 03-20. April 3, 2003 

49. “Flight Demonstration of X-33 Vehicle Health Management System Components on 

the F/A-18 Systems Research Aircraft.” K. Schweikhard, W.L. Richards, J. Theisen, 

NASA Dryden Research Center; W. Mouyos and R. Garbos, BAE Systems, Nashua, 

New Hampshire. 2001. NASA/TM-2001-209037.

50. “An Evolvable Tri-Reasoner IVHM System.” L. Atlas, et. al. The Boeing Company, 

1999. 

51. Description of Scaled Composites’ Spaceship One & White Knight Flight 

Navigation Unit. 

http://www.scaled.com/projects/tierone/New_Index/data_sheets/html/flight_nav.htm

52. Website: Integrated Vehicle Health Monitoring HEDS Technology Demonstration 2, 

STS-96. Rick Husband. http://www.shuttlepresskit.com/sts-96/payload27.htm

53. “Comparison of Autonomous Thrust Termination Systems and Human-Command 

Flight Termination (Destruct) Systems,” T. Mullikin, M. Fudge. Sept. 19, 1997
51

54. “Integrated Vehicle Health Management,” D. Hooks, K. Keller, Boeing Phantom 

Works, June 2002. Presentation.

55. Aviation Week & Space Technology Magazine, April 21, 2003. pp.64-73

56. International Reference Guide to Space Launch Systems, 3rd Edition. S. Isakowitz, 

J.P Hopkins, Jr., J.B. Hopkins. American Institute of Aeronautics & Astronautics, 

Reston, VA. 1999. (Not included on CD)

57. Commercial Launch Baseline Assessment – U.S. Air Force Eastern Space & Missile 

Center. L. Parker et. al. Research Triangle Institute, 1988. (Not included on CD)

58. Websites: Interorbital Systems. http://www.translunar.org/Expeditions.htm July 28, 

2003.

59. Advanced Range Technology Working Group Roadmap Report (Draft), May 9, 2003

60. Memorandum: from Mr. Mike Fudge, ITT to Mr. Stewart Jackson, FAA-AST; 

October 14, 1999. “Perseus B Remotely Piloted Vehicle (RPV) Incident.”

61. Website: UAV Forum, “Vehicle Overview” page

http://www.uavforum.com/vehicles/overview.htm

62. Website: Encyclopedia Astronautica – Rockets listed by propellant type: 

http://www.astronautix.com/stages/stattype.htm (Not included on CD)

63. Website: BAI Aerosystems. http://www.baiaerosystems.com/tairveh.html

64. Airman Magazine. November, 2001. 

http://www.af.mil/news/airman/1101/hawk.html

65. Website: Aerosonde. http://www.aerosonde.com/drawarticle/5

66. Website: X-Prize. www.xprize.org (Not included on CD)

67. Website: Orbital Corporation – Suborbital Rocket Testbeds. 

http://www.orbital.com/LaunchVehicle/AdvancedSystemsTestbeds/Testbeds/

68. Website: L-3 Communications Interstate Electronics Corporation, SWS Engineering 

Services, Range Safety and Communications Systems. 

http://www.iechome.com/pages/products/SWSrngSaf.html

69. Website: NASA Computational Sciences Division, Intelligent Flight Control 

Information. http://ic-www.arc.nasa.gov/story.php?sid=81&sec=air