**Launch Vehicle Health Management:**

**An Overview**

Edward N. Brown[^1]

*The Boeing Company, Huntington Beach, CA 92647*

> **Launch Vehicle Health Management (LVHM) is a technology that is
> presently maturing but still suffers from terminology confusion.
> Health maintenance systems, first as "monitoring" and more recently as
> "management," have been in use by the airlines and the military (with
> varying levels of sophistication) for over 30 years. Similar concepts
> for launch vehicles are also evolving from single discipline
> instrumentation-based measurement systems to interdisciplinary and
> integrated health management systems that combine fault detection with
> health assessment and display, operational flight control, and
> operational launch preparation/maintenance control. LVHM has two
> separate areas of emphasis: supporting operational readiness and
> supporting the safety and effectiveness of operational flight. The
> "management" aspects of LVHM are generally organized and structured
> under conventional programmatic entities (flight/subsystem control,
> mission/maintenance management) that are extensively covered
> elsewhere, whereas the "monitoring" aspects, generally recognized as
> data acquisition, instrumentation, or measurement processing
> (non-subsystem specific), form the thrust of this Overview.**

**Introduction**

Integrated System Health Engineering and Management (ISHEM) is the
enabling factor for intelligent launch operations. It is a key
contributor to overall safety, reliability, launch readiness, mission
effectiveness, and affordability.

The Launch Vehicle (LV) and its associated ground-based infrastructure
form the heart of an overall space system, such as a Crew Transportation
System or a Cargo Delivery System (sometimes the crewed vehicle or cargo
payload is considered to be part of the Launch Vehicle during ascent).
When ISHEM is employed within this environment, the LV unique aspects
are known as Launch Vehicle Health Management (LVHM). Although many of
the basic tenets of LVHM apply equally to all launch vehicles, there are
differences in implementation depending upon whether the LV is reusable
or expendable, and whether the payload is a human occupied spacecraft or
a satellite, transfer, or cargo vehicle.

**Launch Vehicle Health Management Functionality**

LVHM functionality is partitioned into critical functions (flight
critical / ground critical) and non-critical functions (maintenance or
readiness related). LVHM functionality is then further partitioned into
processes implemented on-ground and processes implemented onboard the
flight vehicle. An alternate method of identification (Fudge et.al.
2003) refers to "post-flight LVHM" for maintenance related data and
"in-flight LVHM" for flight critical data (where processes for each may
exist onboard or on-ground). Within the on-ground or onboard
environment, a single architecture can accommodate both pre-flight and
flight operations. The on-ground and onboard processes are integrated
together within an overall program-specific LVHM framework.

The active management aspects of LVHM (the actions taken to initiate
tests, the decision-making on how best to respond to identified test or
operational anomalies, and the actions taken to implement the decisions)
are generally accommodated within existing programmatic infrastructure.
On the ground prior to launch, maintenance/readiness actions are handled
by established Ground/Sustaining Operations processes and personnel.
After launch, flight critical actions are handled by automated processes
onboard (e.g. flight control, engine control, mission manager software)
or by Launch/Mission Control processes and personnel on the ground.
Flight critical actions involving the LV may also originate from the
flight crew if a crewed vehicle is the payload (e.g. abort initiation).
Although there is ample opportunity to improve established active
processes (especially for onboard integration of LVHM with mission
management for autonomous control), the emphasis to date within LVHM has
been on the passive monitoring aspects (accumulating, processing, and
distributing data), with one exception. That exception is the critical
action of automated abort initiation (for crewed launches) and is
discussed later.

The passive monitoring component of the LVHM functionality is often
called Systems Health Monitoring (SHM) (Not to be confused with
Subsystem Health Management which goes by the same acronym), or
Integrated Health Monitoring (IHM). This is an integrated data
monitoring function devoted to collecting, processing, and distributing
meaningful health & status data. It includes both ground/flight critical
data and maintenance/readiness data. This functionality generally
resides on the ground.

The onboard sensing, conditioning, multiplexing, modulation, and
telemetric transmission of qualitative and quantitative, discrete and
continuous health-related data, is functionality that is assigned to the
Avionics and Instrumentation subsystems (note that the physical sensors
are usually owned by the subsystem in which they are resident).

Fault detection functionality, such as for diagnostic testing (threshold
comparison being a simple example), loss of signal/data testing,
reasonableness testing, software testing, or algorithmic bit error
checking, is often implemented both onboard and on-ground to varying
levels depending upon whether or not digital controllers/computers are
incorporated in the design.

For quantitative continuous sensor data (and to a lesser extent for
discrete data that is generated by specific sensor types such as limit
switches), when no subsystem controller/computer is involved, the fault
detection generally occurs on-ground. Raw parametric data is sent to the
ground by telemetry. This is the usual operational mode for non-critical
flight data.

For both qualitative and quantitative data, discrete and continuous,
when subsystem control computers (or flight control computers) are
involved that incorporate signal/data processing and Built-In-Test
functionality, the fault detection process may be capable of being
performed onboard, thus allowing only the fault detection results
(messages representing an abnormal condition derived from the results of
a test or operation) to be sent to the ground by telemetry. However,
although this may save telemetry bandwidth, it deprives the ground
support engineering personnel of visibility into the actual physical
state of the launch vehicle during the flight. Consequently, ground
support personnel generally want access to all of the data and not just
a pre-processed subset. This is especially true for critical flight data
(it also enhances the availability of investigative data in the
unfortunate instance of an accident, assuming that recorders on
recoverable components are not utilized). However, this places demands
on the bandwidth and performance of the onboard instrumentation and
communications subsystems. Size and update rate constraints on downlink
telemetry present a constant source of programmatic pressure on the
design team. There is never enough bandwidth to satisfy everyone, and
design tradeoffs continually occur.

For the exceptional case of a crewed launch, additional sensors and
processing functionality can be added for the purpose of improving the
fault detection and isolation capability, as well as the reliability of
that capability (ensured functionality and reduced false alarms), such
that abort operations (manual or automatic) can be undertaken in a safe
and timely manner. Functionality may also be added for the purpose of
improving flight crew situational awareness (data for presenting on
cockpit display screens). The additional processing functionality may
reside in dedicated hardware and/or software on-ground or onboard, but
the strong preference is to include this functionality onboard because
of the short time-to-effect properties and catastrophic nature of
certain failure modes.

**Launch Services and the Launch Function**

When referring to launch services, the "system" may be defined slightly
different by the U.S. Air Force or by the National Aeronautics & Space
Administration (NASA). The Air Force is primarily concerned with
launching unmanned satellite or ballistic payloads whereas NASA is
primarily concerned with launching both manned and unmanned orbital and
near/deep space vehicles. In keeping with currently fashionable
"system-of-systems" concepts for managing complex technological
endeavors, the LV itself can be considered to be one "segment" within a
broader overall crew transportation or cargo delivery "system."
Following NASA architectural terminology, other "segments" would include
a spacecraft or payload "segment" and a common support services
"segment" (which includes the ground-based launch processing, pre-launch
integration test/checkout, and mission/flight operations). The LV
"segment" includes both the crew and cargo LV "elements." The crew or
cargo LV "element" is commonly composed of various "modules," such as
the main stage "module," the upper stage "module," a booster "module,"
or a payload adapter "module." Within each "module" reside the various
familiar "subsystems" such as the avionics "subsystem," propulsion
"subsystem," or electrical power "subsystem." Sometimes the "subsystems"
are called "assemblies," sometimes the "modules" are called "elements,"
and often "modules," "assemblies," "subassemblies," and aggregates of
"parts" are interchanged, so confusion can easily exist. Figure 1
illustrates the current NASA terminology.

![](media/image1.png){width="6.495833333333334in"
height="4.319444444444445in"}

**Launch Vehicle Segment Requirements**

Usually, there are LV "segment" level requirements to:

-   integrate and fully test the assembled vehicle "modules" and
    "subsystems" before shipment to the launch site

-   implement a documented fault monitoring approach for each critical
    design requirement

-   have rapid fault isolation (FI) with an objective of X%\* of the
    time to 3 or less Line Replaceable Units (LRU), Y%\* of the time to
    2 or less LRUs, and Z%[^2] of the time to 1 LRU (a quantitative
    maintainability requirement)

-   have rapid failure detection (FD) of X%\* or more of the identified
    critical equipment failure causes, weighted by analytical or
    measured percentage failure rates of the identified failure causes
    (a quantitative reliability requirement). \[This failure detection
    requirement is applicable to the design parameters of "subsystem"
    level devices (and below), such as the pneumatic, hydraulic,
    electromechanical, electrical, avionics, and environmental
    "subsystems." However, the ability to detect structural and ordnance
    faults is generally not included in the calculation of "segment" or
    "element" level fault detection, although each structural and
    ordnance subsystem may include stand-alone sensors and measurement
    data based on factors such as feasibility, mission/flight
    criticality, and availability of indirect failure detection methods
    such as with visual, auditory, and/or environmental design
    techniques.\]

> \[Note that the functionality to achieve the FD and FI capabilities
> may be spread across "segments" and "elements" to minimize cost and
> maximize operability. Therefore, they are sometimes considered to be
> "system" level requirements.\]

Furthermore, there is usually a specific requirement to:

-   provide a System Health Monitoring (SHM) capability, at all levels
    and throughout the operational lifecycle, in order to support the:

    -   collection of data and evaluation of status and performance

    -   detection and isolation of faults, with resulting potential
        initiation of corrective actions

    -   design of flight critical onboard and on-ground equipment with
        automated monitoring so that no post processing or analog data
        review is required

    -   recording of all faults detected and their causes (recording may
        be on the ground or in returnable "modules" or "subsystems")

At the "element" level within the common support services "segment,"
there are ground-based launch support infrastructure requirements to:

-   provide an on-ground SHM capability that supports the onboard SHM as
    well as the mission critical ground support equipment (GSE)

-   provide automated SHM to collect LV and GSE health data, evaluate
    status and performance, automatically display fault information on a
    GSE console, record fault, status, and performance information, and
    eliminate post processing and analog data review

At the "element" level within the LV "segment," there are requirements
to:

-   provide vehicle health data and evaluation sufficient to detect
    faults during the integration activities

-   provide the necessary capability to support the higher level FD and
    FI requirements (Note that this decomposition from the higher level
    requirements is not quantitative. The performance value is usually
    the same since numerical allocation of FD or FI capability among
    "segment" or "element" family members is usually quite difficult.)

-   include redundancy and fault tolerance as necessary to support the
    reliability and safety requirements (although not a part of the
    "monitoring" aspect of LVHM, redundancy and fault tolerance can be
    considered to be part of the "management" aspect of LVHM)

Also, there are avionics "subsystem" level requirements to:

-   have the capability to monitor the state of all effectors, valves,
    actuators, pyrotechnics, and motors

-   provide the health and status signal sources for SHM that enables
    compliance with the LV "segment" and "element" level requirements
    for FD and FI of the various avionics, mechanical, propulsion,
    ordnance, and structures subsystems and components, within the
    context of the associated operating modes/environments

The avionics "subsystem" is integral to an SHM/LVHM capability and
generally provides the onboard functionality for the following:

-   Electrical power sources, distribution, grounding, and bonding

-   Commands and controls for LV sequencing, guidance, navigation, and
    control

-   SHM data generation, communication, and telemetry

-   Automatic or ground commanded destruction of the LV

-   LV tracking

-   Controls for booster, stage, fairings, and payload separation

-   Interfaces between the ground-based launch support "element" and the
    LV "element"

-   Interfaces between the payload "element" and the LV "element"

The overall avionics "subsystem" hardware and software requirements
enable all of the avionics functions to successfully perform pre-flight
and flight operations, as well as the status checkouts and/or tests
during the assembly and integration of the LV "modules" and
"subsystems."

**System Health Monitoring (SHM) Design**

To minimize recurring costs SHM coincides with existing aspects of the
design, using their functionality to execute its roles. SHM relies on
the individual subsystems to generate the data that it collects and
distributes. Those new to SHM might be surprised to learn that no stand
alone, identifiable SHM subsystem exists. No black box possesses an "SHM
part number." No group of "SHM guys" (from the organizational
perspective) is responsible for designing and performing the acceptance,
integration, and verification tests. Instead, the normal subsystem
oriented Integrated Product Teams (IPTs), in a concurrent engineering
development environment, weave SHM throughout the design.

**Measurements Management**

The objective is to identify and document all measurements necessary to
detect and isolate LV "element" failures, and to verify the success or
failure of tests and operations performed. Here "element" is defined as
all "modules" and "subsystems" as they flow through the manufacturing
and operational phases from authorization-to-proceed (ATP) forward. The
engineering goal is to create an optimum design that contains just the
right number of measurements necessary to detect and isolate failure
modes and to perform the required tests and operations in the allocated
times. Measurements are frequently classified into one of four
categories: guidance, navigation, & control (GN&C), primary engine,
vehicle "subsystem," and payload (sometimes associated hardware and
software is similarly partitioned).

SHM derives from three user requirements: the need to operate, the need
to test and checkout, and the need to detect, isolate, and recover from
failure. Each area requires that the LV "element" take measurements of
its health and respond appropriately. A concurrent engineering
development tool and an SHM database developed early in the design phase
are instrumental in satisfying these needs. The Delta IV LV utilizes a
commercially available relational database for this application.
Instrumentation and measurements are managed by this relational
database. It provides a set of tools to develop and store health data
that are used for test and check-out (at the factory, integration
facility, and pad), launch support during countdown and liftoff, and
monitoring support during ascent (Garbos et.al. 1997). Figure 2 shows
the operational life-cycle profile of SHM involvement.

![](media/image2.wmf){width="6.419444444444444in"
height="3.622916666666667in"}

SHM involvement begins during the initial development testing when
operating signatures start to be collected. The SHM becomes "live"
during the "assembly"/"subsystem"/"module" manufacture and is used in
conjunction with performance of many of the verification and readiness
tests. Operating signatures are collected during this and subsequent
operations. During the latter parts of the production cycle ("subsystem"
and "module" integration), most software and automated testing used is
essentially identical to that implemented during preflight checkout and
test at the launch pad. In fact, nearly similar ground test equipment
can be used in the factories and integration facilities.

SHM is used to monitor the health of the affected "assemblies,"
"subsystems," and "modules" during transport from the manufacturer to
the integration site and the launch site. During transportation, some
measurements (i.e. temperature, shock) are recorded by equipment
external to the LV. During final assembly and integration of the
"modules" into the LV "element," the SHM is a component of the
integrated verification tests and continues to collect signatures. In
fact, measurements made during integration checkout and on the launch
pad are identical, although maintenance accessibility to hardware is
much more constrained when the LV is on the launch pad. SHM is also
operational during transit to the launch pad and during
fluid/fuel/oxidizer loading at the pad to continuously monitor LV
health.

At the launch pad, SHM is used to verify readiness for launch, including
final verification of Launch Commit Criteria. During countdown, LV power
is switched from external ground power (via the umbilical) to internal
batteries. Telemetry signal paths are direct to a ground station through
to conclusion of first stage flight, and may be routed via relay
satellite (e.g. Tracking and Data Relay Satellite System \[TDRSS\])
after that. SHM is a critical function that provides vital information
for crew/mission abort, performance/trajectory modification, and range
safety management in the event of a significant failure during launch.
SHM measurements provide continuous health and status of the LV
throughout the launch.

The management of measurements can be considered to be a Systems
Engineering undertaking. Measurements are selected based on their
overall utility in terms of FD and FI. Each measurement is assigned a
"figure of merit" derived from its justification and relationship to
other measurements, thus enabling tradeoffs and optimization to be made
objectively. Any given measurement MUST meet one or more of the
following criteria:

-   The measurement is needed to detect faults and initiate corrective
    action as identified by hardware failure modes. The hardware failure
    modes are analyzed via the Failure Modes, Effects, and Criticality
    Analysis (FMECA).

-   The measurement is needed to support launch readiness (per a Launch
    Preparation Document and Sequence of Events).

-   The measurement is needed to perform an acceptance, integration, or
    pre-flight checkout test (per an Integrated Test and Evaluation
    Plan).

The previously mentioned SHM relational database tool is used to help
select the most appropriate and effective measurements and to enable
consistent and quantitative measurement trade-off decisions. It is also
used as an analysis tool to assess progress in complying with the high
level LV "segment" FD and FI quantitative requirements. A number of
evaluation and optimization exercises are run to determine:

-   Failure mode detection coverage (FD)

-   Failure mode isolation to the LRU capability (FI)

-   Adequacy of telemetry throughput

-   Adequacy of software design

-   Adequacy of avionics throughput

-   Adequacy of ground data handling systems throughput

**On-ground System Health Monitoring Design**

Once the core capability exists to adequately fault detect and isolate
failures, it is necessary to develop a strategy to evaluate the health
of the LV "element." The approach followed today is to establish a
health "baseline" in the on-ground launch support "element," by
enhancing the use of onboard Built-In-Test (BIT) capability, and
thereafter identify deviations from the "baseline" as represented by
operational instrumentation and continuous background test (by
electronic computer/controller equipment). To accurately evaluate the
health of an "module," "subsystem," or "assembly," a variety of tests,
with varying levels of intrusiveness, are necessary in order to
accommodate the active and passive states of the functions and equipment
being utilized. For example, if a subsystem function is active, then a
passive test, such as Continuous Monitor BIT, would be used to monitor
the changes in the function's state without affecting the current
operability of the function or subsystem. Alternatively, a more
intrusive test could change the function's state at an appropriate time
and induce a fault, mode, or state. These test modes must be designed to
be compatible with the overall mission states and operational modes of
the LV. For example, BIT can activate and test pyro drive circuits prior
to the actual pyro firing (Bailey et.al. 2000). Typical SHM test modes
recognized or controlled by the on-ground software include the
following:

-   Power-On BIT

    -   One time comprehensive foreground test

    -   Verify functionality prior to transition to normal processing

-   Periodic Monitoring BIT

    -   Verify functionality as a background test

    -   Less comprehensive than Power-On BIT

    -   May be continuous or intermittent

-   Initiated BIT

    -   One time comprehensive test, may interrupt normal processing

    -   Initiated via external control, manual or automatic

-   Initiated BIT -- Memory Inspect

    -   Real-time display of memory contents

-   Maintenance BIT

    -   Specialized mode to facilitate fault detection and isolation

    -   Replaces normal processing -- a separate program or routine

    -   Provides control visibility via external source

Enhancing the BIT functionality involves adding ground processing to
provide a diagnostics capability for improved fault isolation. Different
types of model-, rule-, and state-based algorithms are being evaluated
to augment extensive limits-based monitoring (Aaseng et.al. 2005). The
overall approach is illustrated in Fig. 3.

![](media/image3.wmf){width="5.992913385826772in"
height="3.519291338582677in"}

*NASA and the Human-rated Space Transportation System (STS)*

The SHM approach for the NASA human-rated STS (Space Shuttle) is to
utilize existing onboard avionics equipment-centric BIT functionality
coupled with extensive sensors and multiple onboard instrumentation
systems (Data Processing System \[DPS\] for flight critical guidance,
navigation, & control (GN&C) and Space Shuttle Main Engine (SSME) data,
Operational Instrumentation \[OI\] system for mission critical subsystem
data, Modular Auxiliary Data System \[MADS\] for non-critical data, and
the post-Columbia Integrated Vehicle Instrumentation System for special
measurements), and then utilize the on-ground automated Launch
Processing System (LPS) at the Kennedy Space Center (KSC) Launch
Complex, which is the brain of the KSC Launch Control Center (LCC), and
the Data Computation Complex (DCC) at the Johnson Space Center (JSC),
which is the brain of the JSC Mission Control Center (MCC), to control
and perform testing and data gathering during pre-launch preparation,
countdown, and launch operations.

At KSC, the health and status data is transmitted from the onboard
instrumentation systems to the LCC by umbilical cable and RF telemetry.
In addition, health and status data from launch critical ground systems
are sent to the LCC. The LPS is composed of a Central Data Subsystem
(CDS), a Checkout, Control, & Monitor Subsystem (CCMS), and a Record &
Playback Subsystem. The CDS consists of mainframe computers that store
test procedures, vehicle data, processing programs, historical data, and
analyzed data. The CCMS, consisting of consoles and minicomputers
located in the LCC Firing Rooms, is used in concert with the CDS to
process vehicle data in support of checkout, countdown, and launch.
Pre-countdown checkouts occur during flight readiness engine firings,
tanking tests, countdown simulations, propellant loading, and closeout
preparations. Computer programs monitor and record the performance of
all electrical and mechanical functions and devices by sending command
signals and by receiving data in response. Data sent from the LV to the
LPS is compared against stored pre-established limits and displayed to
the CCMS. Only a predetermined subset of measurements related to test
requirements, launch commit criteria, or performance specifications are
actually limit-checked. Outputs from the computer checkout programs
indicate whether performance is satisfactory or whether additional fault
isolation is needed. However, the actual process of isolating the fault
to the root cause, and determining the operational effects, is a
manually intensive exercise that may involve many engineers and
operations personnel. The launch countdown, which begins about 43 hours
beforehand, is relatively routine and procedurally standardized. At T
minus 9 minutes, the Ground Launch Sequencer (GLS) is activated and all
countdown functions are controlled by the GLS computer in the Firing
Room. The GLS monitors more than several hundred launch-commit functions
and is able to call a "hold" or "cutoff" if a problem occurs.

Once the vehicle has cleared the service tower on ascent, mission
control functions are taken over by the MCC at JSC in Houston. Telemetry
data is processed instantaneously by the DCC and presented to flight
controllers on display/control consoles in the Flight Control Rooms
(FCR). The DCC processes incoming tracking and telemetry data and
compares what is happening with what should be happening. Normally,
detailed information is displayed only if a problem is detected by data
comparison against stored pre-established limits. Again, the actual
process of isolating any fault to the root cause, and determining the
operational effects, is a manually intensive exercise that may involve
many engineers and operations personnel.[^3]

A large portion of the expense associated with the Launch "segment" is
the requirement for large teams of support personnel (management,
engineering, and operations) and the existence of disparate
non-integrated ground systems, together resulting in long processing
times (Peralta 2003). To help overcome these limitations by using
automation and integration, a proof-of-concept launch system was
developed under Next Generation Launch Technology (NGLT) and Reusable
Launch Vehicle (RLV) program auspices. Called the Advanced Checkout,
Control, and Maintenance System (ACCMS), its objective was to combine an
operations oriented design concept with automation, information systems
integration, and command and control technologies. ACCMS provides
integration points for SHM, flexible front-ends, maintenance, resource
planning, and logistics. Successful demonstrations were conducted in
April and May of 2003.

*U.S. Air Force and the Evolved Expendable Launch Vehicle*

The SHM approach for the Air Force Evolved Expendable Launch Vehicle
(EELV) program is to utilize onboard avionics equipment-centric BIT
functionality coupled with sensors and instrumentation (mostly from
pre-EELV design variants), and then utilize the on-ground Launch
Processing Subsystem (LPSS) at the Cape Canaveral Air Force Station
(CCAFS) or at the Vandenberg Air Force Base (VAFB), which is the heart
of the Launch Control Center (LCC), to control and perform testing and
data gathering during pre-launch preparation, countdown, and launch
operations. By adding improved and automated diagnostic functionality
within the ground-based launch support infrastructure, the analysis and
accurate determination of LV health can be enhanced. In addition, test
control is managed from a ground-based test station that is part of the
launch support infrastructure. For the Delta IV LV, this infrastructure
is called Ground Command, Control, and Communications Mission Equipment
(GC3ME). It includes the LPSS (among other subsystems) and is the brains
behind LCC operations. This approach has the obvious benefits of reduced
weight, size, power, and cost burdens imposed on the LV. However, the
need for robust telemetry remains, as does the need for ground-based
engineering support personnel to review the data and provide
inputs/recommendations to the launch operations team.

Launch operations are remarkably similar to STS although more
streamlined and not reflecting an LCC/MCC distinction. Payload control
may occur at a physically different location. The GC3ME monitors and
commands the LV and ground equipment from computer workstations in the
LCC. It monitors the health of the LV during pre-launch tests,
countdown, launch, and ascent, and commits the LV to liftoff in addition
to other control functions.

*NASA, the Exploration Mission, and a Shuttle Derived Launch Vehicle
(SDLV)*

For the NASA Exploration application, there is a desire to further
reduce the ground support staff and move more of the analysis
functionality to onboard the LV (Zuniga et.al. 2005). However, an SDLV
would utilize much of the ground-based launch support infrastructure
that currently services the STS, including the LCC, LPS, CDS, and CCMS.
Modifications to equipment, software, and facilities of the CDS and CCMS
are required, for obsolescence/upgrade purposes, to interface with new
SDLV onboard avionics and instrumentation subsystems, and to accommodate
new SDLV operational concepts (incorporation of portions of the
previously developed ACCMS is possible). A revamped centralized system
supporting ground preparation of the LV "element," "modules," and
"subsystems," their integration, and launch to orbit would be
accomplished by a new Ground Processing and Launch Processing (GP&LP)
system (an "element" in the NASA architecture terminology). Some SHM
functionality would be incorporated into the GP&LP although the extent
is still uncertain. In addition, the GP&LP would assume ascent services
currently performed by the MCC. Any payload launched by an SDLV, such as
a manned Crew Exploration Vehicle (CEV), would have its own Ground
Processing System for monitoring of RF telemetry, although a full
systems verification using CEV signals sent to the GP&LP would be
performed at the pad, and a "go for launch" status would be provided to
the GP&LP by the CEV. It is expected that extensive SHM will be
incorporated both onboard the CEV and in the CEV Ground Processing
System.

The SDLV will include more onboard SHM functionality than either STS or
EELV. The actual number of measurements will likely be less than STS
(because of the Orbiter-less configuration) but greater than EELV
(because of the manned payload). However, the need for additional
diagnostic functionality for isolating and confirming faults,
degradations, and incipient failures is driven by the need to support
launch abort operations and enable the greatest probability of crew
survivability (Brown, E. et.al. 2005). This is discussed further in a
subsequent section.

**System Health Monitoring Analysis**

During the design phase, the LV development team utilizes concurrent
engineering to design-in the hardware and software necessary for an
integrated health monitoring capability. They examine design documents
(schematics, layouts, flow charts, block diagrams, etc.) and operations
documents (functional descriptions, procedures, etc.) and generate the
Failure Modes and Effects Criticality Analyses (FMECA). Using the FMECA,
the team conducts a failure mode by failure mode analysis to determine
the measurements necessary to detect and isolate failures. The team also
performs test-by-test and operation-by-operation analyses of the overall
LV "element" in order to determine if additional measurements are
necessary for the timely and effective completion of these tests and
operations. The team then examines these derived monitoring requirements
to determine what affiliated software processing capabilities are
required. Finally, the team verifies the software\'s functional
capabilities through simulated operations in an integrated system test
lab.

An additional analytical requirement under the responsibility umbrella
of SHM is to provide a quantitative assessment of the FD and FI
capabilities in support of top level LV "segment" requirements. The FD
and FI assessment addresses the life cycle from manufacturing through
assembly at an integration facility, checkout and countdown on the
launch pad, and ascent flight. Instrumentation and measurements needed
to implement a SHM capability are managed by a ground-based relational
database. The SHM database provides a set of information management
tools to develop and store data that are used for test, checkout, and
launch activities. The database supports both manual and electronic
inputs from many groups, tools, and automated processes. It also
provides an efficient means to organize measurement (and other) data to
support flight operations at the launch site for all configurations and
missions. The SHM database exists within a global ground database
system--- a relational data repository that shares data with other
ground support applications. Data are supplied to the SHM database from
external entities via the global database. The SHM database generates
and manages output files for use by the ground support mission equipment
for vehicle test and checkout at the various manufacturing, integration,
and launch sites.

From the system analysis standpoint, the SHM inputs are:

-   Hardware data (hardware identification number, quantity, failure
    rates for ground and flight)

-   Configuration data (relating the specific hardware to the as-used
    configuration)

-   Mission information (whether 'production,' 'special flight,' or
    'other')

-   Phase information (one or more of 'manufacturing,' 'transportation,'
    'integration,' 'pad,' 'launch and flight')

-   FMECA information (modes, criticalities)

-   Measurement information (identifies the measurements contributing to
    the detection of each failure mode)

and the SHM outputs are:

-   FD metrics (the percentage of failure rate associated with detected
    faults)

-   FI metrics (the percentage of failure rate associated with fault
    isolation to each level of ambiguity, i.e. to one, two, or 'three or
    more' replaceable units)

A documented step-by-step process provides the methodology and
procedures for calculation of numerical FD and FI metrics. These metrics
are failure-rate- (λ) based. Each hardware item has one or more modes of
failure, and has associated failure rates for each phase of the
operating environment[^4]. FD and FI algorithms look at failure rates
associated with each failure mode plus the specific measurements
associated with detecting each mode. FI algorithms also look at the
measurement patterns for each mode, and perform a pattern recognition
process. The FD metric is the ratio of λ~detectable~ to λ~total~ and can
be calculated at each level of the architectural hierarchy. The FI
metric is the proportion of detectable failure rates associated with
each level of fault isolation ambiguity (for maintenance purposes, to
one, two, three, or more replaceable units -- for
recovery/reconfiguration purposes, the level is dependent upon design
and redundancy and is more difficult to quantify). Low levels of
ambiguity are highly desirable, since they greatly reduce the amount of
maintenance time expended to fix a problem.

**Onboard System Health Monitoring Design**

On the Delta IV EELV, a dedicated SHM software program in the avionics
Flight Control Computer (FCC) is used to control BIT functioning and
acquire operational data in response to tests performed on the ground
during integration and pre-launch preparation. However, the program is
not active during ascent flight. During ascent, flight critical
measurements are processed by the GN&C software in the FCC and a
predetermined set of GN&C and engine parameters (determined by available
downlink bandwidth) are transmitted to the ground by telemetry
equipment.

On the Space Shuttle, an SHM software program, called Systems Management
(SM), in the avionics General Purpose Computer (GPC), provides the data
processing capabilities necessary to monitor the performance of all
Shuttle "subsystems"/"assemblies" excluding flight critical GN&C and
engine parameters. Its primary function is automatic fault detection and
presentation of failures for annunciation (the actual annunciation is
performed by separate software and hardware), although it also performs
the management functions of measurement formatting for displays, vehicle
mode configuration control, consumables management, payload bay door
commanding, and ground checkout, control, and diagnostics support. The
SM program is not run in the primary avionics GPCs (a quad redundant
set) during ascent (it is run during orbital operations and pre-flight
checkout only). However, the fault detection and annunciation portion of
the program [does]{.underline} run in the Backup Flight Computer (BFC)
during ascent. The BFC provides no active flight control unless manually
engaged by the flight crew (it is hot and running). But the abbreviated
SM program running in the BFC performs fault detection through the use
of limit checks (static and dynamic), reasonableness tests, BIT
monitoring, correlation checks, and other techniques as applicable. In
fact, the SM functionality provides a backup capability for the
independent hardware-based Caution & Warning System. Sufficient
measurements and correlation techniques are used in the process to
insure a high degree of accurate fault detection and false alarm
avoidance (in general, two or more consecutive out-of-tolerance
comparisons are required before a fault is annunciated). In addition,
out-of-tolerance identification (too hot, too cold, too high, too low,
etc.) is provided for measurements detected as being out-of-limits.
Similar to the EELV design, monitoring of flight critical measurements
is performed in the GN&C software in the GPCs and in the engine control
software in the SSME Controllers, and a predetermined set of GN&C,
engine, and SM parameters are transmitted to the ground by telemetry
equipment. Non-critical measurements are also recorded onboard by the
MADS for post-flight analysis (a benefit of reusability).

**Future Directions**

Most all "elements" in all "segments" require some form of SHM to help
realize the goal of launching a perfect LV and payload into space. The
vehicle processing and launch support team are focused on this goal,
which includes:

-   Ensuring that the LV and payload are ready for flight (no anomalies
    after system integration)

-   Ensuring that the LV and payload remain fully functional during the
    pre-launch checkout and countdown, and

-   Monitoring the health of the LV and payload during ascent flight
    (for post-flight reliability/maintenance purposes and for advising
    the operations team on possible recovery actions if anomalies are
    encountered during the flight)

To improve upon the effectiveness of these functions, it is generally
accepted that a real-time determination of health state is highly
desirable. To achieve this, more advanced capabilities in symptom
detection, diagnosis, prognosis, and impact analysis are needed (Aaseng
et.al. 2005).

**Reusable Launch Vehicles and Operationally Responsive Spacelift**

The next generation LV, whether reusable or expendable, will necessarily
have requirements to simplify and reduce the on-ground vehicle
processing operations. A key capability for achieving this is health
state information support for informed maintenance activities. This is
especially important when operational responsiveness is needed (Brown,
K. 2004). This capability is focused on supporting the technician as
maintenance is conducted on the vehicle, utilizing current knowledge of
the health state, improved diagnosis, and reduced ambiguity of
isolation. Informed maintenance will require real-time updates of the
vehicle health state information as well as a resource of system-related
information, such as procedure/technical manual databases and historical
planning data. However, understanding the current health state of the
vehicle represents the first step towards executing the required actions
needed to ready the LV for flight, and improving the performance of
in-flight health checks will enable better understanding of the
operational health state. An important metric that must be minimized is
the "Can Not Duplicate" condition where reported faults no longer exist
or are not reproducible (Goforth et.al. 2005). A robust design for
informed maintenance will provide better visibility into these
troublesome conditions. Other performance metrics such as
"turn-around-time," "call-up-time," and "number-of-support-personnel"
can be used to evaluate the effectiveness of an overall LVHM design. For
example, in the Orbital Space Plane (OSP) program it was determined that
to achieve a quick "turn-around time," an SHM with integrated
diagnostics that could reduce the failure ambiguity to a single LRU
would be necessary (Bullman 2004).

Some experiments on Space Shuttle flights STS-95 and STS-96 confirmed
that ground processing activities (for both planned and unplanned work)
could be greatly simplified and reduced by implementing a design with
the capability to monitor health state with improved visibility, and
with streamlined fault isolation in real-time during flight (Fox et.al.
2000).

SHM functions that monitor LV health over all the architectural levels
will be critical to operationally responsive (launch-on-demand)
spacelift, such as the Space Operations Vehicle (SOV) for the Air Force.
When SHM is integrated with flight/mission management and maintenance
management, two critical roles are fulfilled: (1) the real-time
identification of an impending failure coupled with the initiation of
in-flight mitigation actions to save the vehicle or mission - and then
guiding the maintenance activity during its turn-around to restore it to
a fully mission capable status; and (2) the continual monitoring of the
LV performance, in order to identify trends and determine which
"subsystems," "assemblies," or "parts" need an inspection or maintenance
action. The maintenance goal on a reusable LV is to replace critical
components before they fail, but not replace them prematurely. SHM data
captured during flight, and used as the basis for prognostic assessment,
is key to achieving this goal (Clancy 2000).

**Human-rated Launch Vehicles**

SHM for manned operations will be more highly developed and more capable
than that used for unmanned operations. Prognostics will be more
developed. Due to the human-rating of the LV and crew-centered
operations orientation, there will be greater sensor coverage with more
redundancy and faster data rates. Coverage, timing, and trustworthiness
are the three primary risks to a successful LVHM design, as shown below:

-   Coverage considerations -- Sufficient depth and breadth of
    measurements are required to assure that all critical failure modes
    can be detected, isolated, and understood as to effect

-   Timing considerations -- Failure event horizons ranging from a few
    hundred milliseconds to tens of seconds dictate that the SHM
    function have unique real-time constraints (fast and with minimal
    latency)

-   Trustworthiness considerations - The ultimate management action
    taken as a result of decision processes utilizing SHM data involves
    the extreme step of flight abort or crew escape. There is very
    little tolerance for false alarms when human life and high value
    equipment are at risk. The SHM function must be performed with high
    reliability, high accuracy, and with minimal false alarms.

*Priority of Requirements*

The highest priority functional and performance requirement for an SHM
design is to provide a contribution, commensurate with need, to the
attainment of a system level numerical value for "the probability of
crew survival" during ascent that meets the top level program
requirement. This can be accomplished through the detection, isolation,
and understanding of catastrophic failure event sequences (including
emerging/developing sequences \[detection of such is sometimes called
Failure On-Set Detection (FOSD)\]) prior to these sequences reaching the
undesirable end state, and communication of the information that
provides this knowledge to the crewed vehicle for use by the flight crew
and/or flight management computer functionality, and to Launch/Mission
Control on the ground, for making timely decisions (which for certain
failure mode phenomena may drive rapid and automated management and
control processes concerning flight abort or other flight recovery
actions) (Zuniga et.al. 2005).

Said in a simpler way, the LV must provide to the CEV, and to
Launch/Mission Control, sufficient insight into its health state so as
to allow the CEV or Launch/Mission Control to determine IF and WHEN an
abort is necessary. Of particular importance is the extent to which the
LV can provide early indications prior to any failure that could
directly threaten the integrity of the CEV and the safety of the crew.

The second highest priority functional and performance requirement for
an SHM design is to provide a contribution, commensurate with need, to
the attainment of a system level numerical value for "the probability of
mission success" during ascent that meets the top level program
requirement. This can be accomplished through the detection, isolation,
and understanding of critical failure event sequences prior to these
sequences reaching an undesirable end state, and communication of the
information that provides this knowledge to the CEV for use by the
flight crew and/or flight management computer functionality, and to
Launch/Mission Control on the ground, for making timely decisions
concerning flight recovery actions, or back to the LV subsystem
processing functionality for automated preprogrammed recovery actions.

Extensive analysis of failure modes is necessary for the SHM function to
support these priorities. Both identification of end-state and timeline
to end-state are needed. Since this includes rapid short term and longer
developing failure sequences, SHM must support both automatic and manual
flight abort, mission recovery, and subsystem reconfiguration decisions.

The third highest priority functional and performance requirement for an
SHM design is to provide a contribution to the overall situational
awareness of critical functions during ascent for the flight crew and
for Launch/Mission Control on the ground. This can be accomplished
through the detection, isolation, and understanding of operating modes,
test modes, normal conditions, and anomalous conditions of all severity
levels associated with critical functions.

*Allocation of SHM Functionality*

The initial detection of faults and failures that originate in the LV is
by direct sensor measurement or electronic monitor. The isolation (or
identification) of failures and the corresponding impact analysis,
however, could possibly reside in the CEV, the LV, or on the ground,
since it is basically a processing function and processing capability
exists in all three "elements." The LV could continuously pass large
amounts of raw sensor data to the CEV or to the ground (downlink
bandwidth limited), which would then be responsible for isolating and
analyzing the failure (by developing diagnostics and effects analysis in
order to fully understand the nature of the anomaly). Alternatively, the
LV could incorporate its own failure isolation/analysis functionality.
The CEV then would receive only relevant high level Warning & Caution
alarms, or messages such as "will not reach planned orbit" or "explosive
failure predicted within 10-15 seconds, 80% confidence." Processing for
confirmation of alarm determination and avoidance of false alarms would
also be accomplished in the LV. Although the CEV may only
receive/require relevant high level messages/alarms, it may be desirable
to send all (or most) of the raw sensor data to the ground for failure
isolation/analysis processing that would duplicate or support the
onboard processing. There are many factors that go into such an
allocation decision (available computational resources, development
costs, human element considerations, etc.). Moreover, this functionality
may be critical to achieving mission success or flight crew safety in
the event of certain failure situations. The outstanding issue is how
much health monitoring functionality should exist on the ground and how
much should exist onboard. On-ground processing could be as a substitute
for, or as an adjunct to, onboard processing. The approach depends not
only on the processing capabilities for understanding the fault
mechanisms, fault propagation (including derivative/sympathetic faults),
failure modes, and timelines, but also on the quantity, quality, and
cycle rate of sensor data that can be detected, conditioned,
multiplexed, and transmitted over the down link.

*Redundancy, Fault Tolerance, and Human-Rating*

The question exists as to whether the presence of onboard SHM can be
used to offset design redundancy. The choice of whether to be
2-fault-tolerant (fail-operational / fail-operational, or
fail-operational / fail-safe) or 1-fault-tolerant (fail-operational or
fail-safe) is a complicated issue. NASA human-rating requirements
specify that most vehicle functions (primary structure and thermal
protection excepted) be designed so that no two failures result in human
fatality or permanent disability. However, this requirement applies to
the "system" level, which includes the LV, spacecraft, and common
support services "segments" as well as their affiliated "elements" and
inclusive hierarchical structure. At issue is whether a flight abort
capability can be used to satisfy the requirement for a safe response to
a first or second failure (as a leg of redundancy). Guidance on this is
not totally clear (contingency abort modes that are verified by flight
test represent the current most favored approach). The reliability of
the overall flight abort "module" (especially the separation, controlled
descent, and landing) becomes an important piece of the puzzle, and the
LV SHM is an important part of the flight abort "module." From the
standpoint of the LV alone, the depth of onboard redundancy will
directly affect affordability, so this is an important issue. In
general, today's EELV is fail-operational while the Space Shuttle is
fail-operational / fail-safe. Of course, the EELV does not launch crewed
vehicles and the Space Shuttle is an integrated LV/crew vehicle. Future
human-rated LVs (that separate the LV from the crewed vehicle) will need
to make critical trade-offs in this area. There is an ongoing tug-of-war
in the effort to improve both safety and affordability, and this will
directly affect not only the design of any onboard LV SHM, but also the
design of LV avionics (and many other LV "subsystems"), the on-ground
SHM, the crewed vehicle SHM, and the "subsystems," "assemblies," and
"parts" within the flight abort "module." However, it is likely that a
LV SHM (both on-ground and onboard in real-time) will be needed to
satisfy crew survivability requirements regardless of level of fault
tolerance design (Tobias and Hawkins 2005). Because of short
time-to-effect considerations, an emphasis will be placed upon onboard
SHM, but the level of needed performance and reliability is still an
open issue. Systems Engineering analysis intended to effectively
allocate and decompose requirements from the crew transportation
"system" level down to the "element," "module," and "subsystem" levels,
will eventually drive the design requirements for the onboard LV SHM.

**Conclusions and a final caveat**

The requirements of atmospheric/space launch/flight and the limitations
of as-designed vehicle performance often limit vehicle operational
margin. When "parts" and "assemblies" are operated "at or near the
limit," reliability is reduced. This reduced reliability drives the
development of management and control designs capable of fault recovery
(automatic or human-in-the-loop, real-time or non-real-time), of which
SHM plays an integral part. The benefits of such a design must be
weighed against its developmental costs. While it might be quite
beneficial to have health monitoring on a complex unit that fails every
100 hours, it might be impractical to spend money for health monitoring
on a unit that fails every 100,000 hours, or to spend many dollars to
monitor for simple sensor failures. There are some key factors that
affect health monitoring decisions: failure frequency, failure
consequence, design complexity, and the ability to understand all the
failure modes / operating characteristics during system design.
Determining the balance between onboard SHM versus on-ground SHM, or the
optimum "pay-back" for implementing SHM, is a difficult task that
requires considerable analysis for a given project. These decisions are
best made prior to entering into an operational phase (the OSP program
provided "lessons-learned" on human-rating an EELV).

When applied effectively, SHM can provide substantial benefits to future
launch, space, and ground support operations. These benefits include
improvements to safety, reliability, maintainability, flight and ground
operational support, and extensibility to future space exploration
systems. Determining the optimal level of the cost-benefit tradeoff will
depend upon critical systems engineering and integration studies/trades
that must be made early in the program life cycle.

**Reference List**

Aaseng, G. B., Patterson-Hine, A., and Garcia-Galan, C., January 2005, A
Review of System Health State Determination Methods, *AIAA 1^st^ Space
Exploration Conference*.

Bailey, R., and McSharry, M., March 2000, K-1 Integrated Vehicle Health
Management System: Design for Operational Efficiency, *IEEE Aerospace
Conference Proceedings*

Brown, E. N., Chidambaram, B., and Aaseng, G. B., August 2005, Applying
Health Management Technology to the NASA Exploration System-of-Systems,
*AIAA Space 2005 Conference*.

Brown, K. K., June 2004, A Concept of Operations and Technology
Implications for Operationally Responsive Space, *Air & Space Power
Chronicles*.

Bullman, J. (study lead), March 2004, OSP -- ELV Human Flight Safety
Certification Study Report Vol. 1, NASA MSFC-OSP Program Office.

Clancy, D., September 2000, Model-Based System-Level Health Management
for Reusable Launch Vehicles, *AIAA Space 2000 Conference*.

Fox, J, and Glass, B., March 2000, Impact of Integrated Vehicle Health
Management (IVHM) Technologies on Ground operations for Reusable Launch
Vehicles (RLVs) and Spacecraft, *IEEE Aerospace Conference Proceedings*

Fudge, M., Stagliano, T., and Tsiao, S., ITT Industries, Advanced
Engineering & Sciences Division, August 2003, Non-Traditional Flight
Safety Systems & Integrated Vehicle Health Management Systems -- Final
Report to Office of the Associate Administrator for Commercial Space
Transportation, Federal Aviation Administration.

Garbos, R., Melvin, L., Childers, B., and Jambor, B., October 1997,
System Health Management / Vehicle Health Management for Future Manned
Space Systems, *IEEE/AIAA Digital Avionics Systems Conference*.

Goforth, A., Karsai, G., Orosz, M., Neches, R., Szekely, P., and Ashish,
N., January 2005, Attaining Program Affordability through Integration of
Logistical Operations and Health Maintenance", *AIAA 1^st^ Space
Exploration Conference*.

Peralta, G., April 2003, Lessons Learned from Past Reusable Launch
System Designs, *AIAA 1^st^ Responsive Space Conference*.

Tobias, M. E., and Hawkins, D. K., August 2005, Crew Survivability
Aspects for a Human Rated Exploration Launch Vehicle, *AIAA Space 2005
Conference*.

Zuniga, F. A., Maclise, D. C., Romano, D. J., Jize, N. N., Wysocki, P.
F., and Lawrence, D. P., January 2005, Integrated Systems Health
Management for Exploration Systems, *AIAA 1^st^ Space Exploration
Conference*.

[^1]: Engineer/Scientist, NASA Systems Division, 5301 Bolsa Avenue.,
    H012-C214

[^2]: Values for X, Y, and Z differ for the various Air Force and NASA
    missions.

[^3]: Interestingly, the DCC uses a computer setup nearly identical to
    the onboard computer setup in order to insure that the ground
    displays exhibit the same unique computer caused irregularities as
    do the onboard flight displays.

[^4]: Hardware failure rates are based on historical data when
    available. Failure rates of electronics are usually based on
    predictive analyses per MIL-HDBK-217. Failure rates are specified
    for the ground and flight environments.