54th International Astronautical Congress of the International Astronautical Foundation, IAC-03-IAA.13.1.02the International Academy of Astronautics, and the International Institute of Space Law29 September – 3 October 2003, Bremen, Germany

1

This material is declared a work of the U.S. Government and is not subject to copyright protection in the United States.

INTEGRATED SYSTEM HEALTH MANAGEMENT FOR REUSABLE, IN-SPACE TRANSPORTATION

SYSTEMS

By

Anthony R. Gross, Associate Director (anthony.r.gross@nasa.gov),Ann Patterson-Hine, Senior Research Scientist (ann.patterson-hine @nasa.gov),

Brian J. Glass, Senior Research Scientist (brian.j.glass@nasa.gov), andJoan Pallix, Senior Research Scientist (joan.b.pallix@nasa.gov)

Information Sciences & Technology DirectorateNASA Ames Research Center, Moffett Field, CA, USA

Abstract

New missions of exploration and space operationsenvision architectures that are based on powerful new in-space transportation systems. Such missions as thedevelopment of human-tended operations nodes at the L1or L2 Lagrange points, very large telescope assemblies,and planetary missions developed and operated from suchpoints, will all require highly capable space transportationsystems to transfer cargo and humans crews from lowEarth orbit (LEO) to these locations. Such missions couldinvolve a complex transportation infrastructure,containing a few elements or many “independent agents”,i.e., space tugs, refueling stations, and an overall controland communication system. New informationtechnologies, which take advantage of knowledge-basedsoftware, model-based reasoning, and high performancecomputer systems, will enable the development of newgenerations of planner/schedulers, and autonomouscontrol systems with diagnosis and recovery capabilities.Integrated system health management (ISHM)frameworks use these technologies to increase thereliability and robustness of vehicles. This paper willdescribe design considerations for implementing theISHM concept on reusable, in-space transportationsystems. Topics to be presented will include a missiondescription and needs assessment, brief description of keyISHM concepts, potential architectures for ISHM asapplied to in-space transportation systems, and howISHM concepts will be implemented for the system-of-systems of “independent agents” mentioned above.

Introduction

New generations of space exploration missions willinevitably evolve from current capabilities to new levelsof complexity and longer duration. As we reach out toexplore planets further out in the solar system, thearchitectures necessary to support such missions willrequire spacecraft that will spend their entire workinglifetimes in the space environment, without returning toEarth. Such in-space systems will perform a wide range offunctions, including crew transfer, ferrying supplies andscientific instruments systems, and as refueling tankersfor long duration missions. Each will embody its ownpropulsion system, and will require a high degree ofautonomy and the ability to manage its operational status.

Such intelligent modular systems will signal a newapproach to space exploration and, in this paper, thesystems and technology necessary to assure the reliableoperation of in-space vehicle systems will be discussed.The capability for such reliable operation is known asIntegrated System Health Management (ISHM) and willbe described in general terms first, then in specific detailas it is applied to intelligent, modular, in-space propulsionsystems. The discussion will begin by describing potentialexploration scenarios that involves many independentspacecraft systems, all required to work together toachieve the complex goals of the mission. ISHMcapability will be a required part of such systems in orderto assure their success. Some of the technologies requiredfor the implementation of such systems include:automated reasoning, data mining and fusion, human-

Copyright ©2003 by the American Institute of Aeronautics and Astronautics, Inc. No copyright is asserted in the UnitedStates under Title 17, U.S. Code. The U.S. Government has a royalty-free license to exercise all rights under the copyrightclaimed herein for Governmental purposes. All other rights are reserved by the copyright owner. Presented at the 54thInternational Astronautical Congress, Bremen, Germany, September 29 - October 4, 2003.

2

system computing, and advanced decision systems. Thefollowing sections discuss where these technologies willbe required, and how they might be implemented.

Mission and Problem Description

Gateway-like Mission Concepts

Some concepts for future remote exploration envision oneor more “gateway” stations – located at a libration point –as human logistics and resupply outposts. Unlike lunar orMartian-orbiting space stations, relatively low-energytransfer trajectories may be used.

These low-energy trajectories allow bulk transfer andresupply with modest velocity changes (delta-v). Givenradiation concerns, their long flight durations will makethem unsuitable for human crew transfer, so a separateclass of smaller, high-delta-v crew transfer vehicles willbe necessary, as shown by the notional vehicle in Figure1. Logistics resupply transport vehicles can then beexpected to be both automated and

Figure 1. Notional LEO-Gateway crew transfer vehicle.

in long-duration transfers. Minimal deep-space bandwidthcan be expected to be made available for real-timemonitoring of these cargo carriers.

While LEO-to-gateway crew transfer vehicles will haveon-board crew available for systems management, thevehicles will have additional safety and certificationburdens and can be expected to have greater systemsredundancy. Operations will be both ongoing in space(like the Space Station) and will include frequent high-energy propulsive segments (like the Space Shuttle).Unlike the latter, there can be no teardown or intrusivemanual inspection between flights.

SHM Requirements Drivers

The logistics transfer vehicle will be expected to likewisesupport multiple flights – with different payloads –

without extensive maintenance or reconditioning. A 30-50 metric ton capability is necessary to place a gatewaystation. Candidate propulsion technologies include solar-electric, nuclear-electric or nuclear-thermal systems, witha design lifetime of five years with only periodic LEOmaintenance at the ISS. Deep-space cruise would eitheroperate autonomously, or with minutes of time lag ifcontrolled from Earth.

By comparison, Earth-to-Orbit (ETO) and low-Earth-orbiting systems operate within milliseconds to secondsof the Earth’s surface, in terms of monitoring and controllags. Minimal lag makes stable and safe control possiblefor these systems, as has been performed historically fromground-based mission control centers.

ETO systems have another advantage, in that humaninspection and maintenance is possible, and currentlyrequired, between flights of reusable systems. Theseoperations take place under convenient shirtsleeveconditions, with effectively-unlimited supplies of power,labor and spares, and under uniform 1-g conditions.

Needs for automated health management

Given that deep-space transfer vehicles (crewed or cargotransfer) will necessarily function out of communicationwith Earth control for long periods of time, safety requiresactive monitoring and control (rather than a “fire andforget” approach). Due to the transmission time lags,traditional Earth-centralized mission operations will notbe feasible in deep-space exploration architectures.Single-string lunar exploration can be done, given just afew seconds lag, but not multiple ongoing missions andexploration at distances beyond the Moon. Large dynamicsolar-electric array or nuclear reactor control both requirereal-time responses – in terms of seconds or faster –without large gaps in coverage.

There are a number of partial solutions to address theproblem of remote operations. One of them, discussed inthis paper, is the use of automation to implement on-boardsystem health management. Another complementarystrategy is the eventual decentralization of mission controlauthority, moving the locus of responsibility for vehiclesto the humans on the nearest gateway station.

Crew transfer vehicles have perhaps an option of limitedin-flight Line Replaceable Unit (LRU) replacement bytheir passengers or by integral robotics, but otherwisethey and bulk cargo transfer vehicles will have to wait formaintenance or repair until their next station docking.

3

In ETO systems, ISHM is enhancing, rather than required– for increased safety, faster ground turnarounds, andlower operations costs. But in deep space transferapplications, ISHM is essential. Complex, high-energy,quick-responding, robotic systems deployed to regionsbeyond the timely reach of terrestrial control requireISHM and other automation in order to safely operate.Given the difficulty of intrusive inspections on-orbit –even while docked to a station – transfer vehicles musthave adequate built-in sensors and instrumentation toobserve all high-criticality failure modes and predictrequired maintenance actions prior to failure.

Overview of Integrated System Health Management

Exploration missions such as those described in theprevious section require many system elementscoordinating their activities to achieve the goal of themission. It is important to determine the health status ofthe individual elements, but often it is essential tounderstand the relationships of the elements to oneanother. System designers study the propagation offailures throughout subsystems and systems. Missiondevelopers analyze the effects of the element failures onmission scenarios. During operation, the intelligentsystem health manager must have access to all of thisinformation in order to effectively manage the health ofthe entire system of systems.

Intelligent system health management (ISHM)architectures have been developed under NASA’s SpaceLaunch Initiative. Since the goal of this program is launchvehicle development, the health management task iscalled IVHM, and that nomenclature will be used in thissection for consistency with the referenced architectures.One of these architectures, developed by HoneywellSpace Systems. is illustrated below in Figures 2 and 31.Its inherent modularity and ability to represent large,distributed systems makes it a candidate for application inthe exploration area. The architecture is developedhierarchically to provide expansion capability. For thepresent application, the elements could include the crewtransfer vehicle (CTV), the gateway, a lander, and ahabitat. Each of these elements would be decomposedinto sub-elements. In the case of the crew transfer vehicle,the elements would include the boosters, the CTV andperhaps a payload module. As shown in Figure 2, eachelement consists of components in which an IVHM kernelwould reside. The subsystem interface provides themechanism by which information is distributed among thevarious subsystems. During design, a subsystem interfacespecification can be used to control the information flowat the subsystem interfaces. If a component complieswith the specification, it is called a Member Subsystemand it will supply its health status in well-definedparameters and formats. If a component is not able to

comply with the Subsystem interface specification, itshealth can still be integrated into the architecture. Anadaptor is custom-designed to provide an interface to aNon-member Subsystem. The IVHM kernel providesreasoning across the subsystem and also acrosssubsystems at the system level. Issues arise such as howto provide communication of health status amongsubsystems as well as up and down the hierarchy in atimely manner. These issues must be addressed early inthe design of the health management architecture.Another challenging issue is the incremental constructionof space systems such as these and how that impacts thehealth assessment, monitoring, and reconfiguration ofsystems which are changing periodically dueconstruction. Strict model specifications, updating, andconfiguration management will be essential to thesuccessful application of IVHM strategies.

Figure 3 contains the functions provided in the IVHMKernel. The System Level IVHM Manager coordinatesIVHM operations across multiple elements. The MissionReadiness Manager assesses the capability of specificsubsystems to perform a mission profile. Maintenanceand Troubleshooting Support can coordinate themaintenance activities among the available maintenancedepots. For instance, there could be maintenanceperformed during flight of the CTV or it could beperformed while the CTV is docked to a Gateway station,with all of the information archived to support furtherhealth management activities. The Event Managermanages events such as crew caution and warnings,information directing the System Level IVHM Managerto reallocate management responsibility, and eventsidentifying diagnostic or prognostic results fromsubsystems. The architecture is designed to accommodatevarious reasoners and knowledge fusion tools. Thesetools, located in each element, perform diagnostics andprognostics across all subsystems within the element.They can also be used to perform these functions at highersystem levels. Reference 1 describes several tools well-suited for application to larger systems. Model-basedreasoning capability has been demonstrated for spaceapplications on the Deep Space 1 mission in 19992. Aheterogenous architecture utilizing multiple, disparatereasoners was demonstrated under the SLI program and isdescribed in Reference 3. Because this IVHM architecturewas designed to be open and scalable, its structure andfunctionality can be used for the broader System HealthManagement function required by Gateway-like Missions.

Applications to In-Space Transportation Systems

New space exploration missions will be increasinglycomplex and of longer duration. Increased functionalgoals often result in increased implementation

4

complexity, making it much more challenging to achieveboth reliability and affordability. In order to meet thechallenges of future mission complexity, NASA will needto make use of all of the recent advances incommunications, computers, software, sensors, design,and engineering technologies. Despite significanttechnological advances, all mission risks will not be

mitigated during the mission design phase: software andcomponents will fail or degrade; operators will makemistakes; and operating environments may be uncertain.Implementation of critical future mission systems torecover from these unanticipated problems and willsignificantly reduce the cost of system operations.

Vehicle Element Health Management

Extendable set of Subsystems

Subsystem 1Health

Management(Member)

Subsystem nHealth

Management(Non Member)

Subsystem 2Health

Management(Member)

IVHM Kernel

AdaptorSubsystem Interface

Component Component Component

Component

Figure 2 Vehicle Element Health Management

Case Based

Example SystemLevel Reasoners

Event Mgmt Service

Etc.

7 56

121110

8 4

21

9 3

System Level IVHM Mgr

IVHM ElementInterface

System LevelKnowledge

Fusion

Model BasedConfig. 1

Config. n

StandAlone

ModelBased

Reasoner

Rule Based

Config. 1

Config. n

StandAlone

RuleBased

Reasoner

Config. 1

Config. n

StandAlone

CaseBased

Reasoner

IVH

M

Ker

nel

M

essa

gin

g

Subsystem AdaptorMgr

Sub SysUnique

Adaptor#1

Sub SysUnique

Adaptor#2

Sub SysUnique

Adaptor#N

Other VehicleInterfaces

Data Mgmt Service

Services

Non MemberSub System

Adaptors

Non MemberSub systemInterfaces

Su

bsy

stem

In

terf

ace

Subsystem Interface

Maintenance andTroubleshooting

Support

Data andEvent Storage

Mission ReadinessMgr

SystemTime

Figure 3 IVHM Kernel Component

5

The mission described in this paper will require ISHMtechnologies to be integrated with all mission systems.Studies of past mission failures can be used to establishISHM technology application priorities that address costand risk reduction for this mission4. Studies indicate thatcurrent mission technologies are not optimal for carryingout effective risk mitigation strategies as they lacksignificant capability to assess system condition or tovalidate system performance. System robustness,redundancy and capability for rapid recovery are currentlyinadequate. In addition, incorporation of informationtechnology in the maintenance process is insufficient forthe required reduction in life-cycle costs for the future.

It is reported that flight control subsystem failures rankamong the highest as initiators of mishaps. Majorcontributing factors in past accidents included componentfailures, lack of proper human-machine interactions,operator error on-board or on the ground (often due to anuninformed operator) and unanticipated operatingenvironments. Reference 4 contains data from a numberof mishaps described in several important agency reportsincluding the NASA Integrated Action Team Report, theShuttle Independent Assessment Team Report, the Faster,Better, Cheaper Task Report and the USAF Broad AreaReview of 1999. All of the factors outlined in the reportscan be addressed by future implementation of ISHMTechnology.

The human-machine interaction will be extremelyimportant for the gateway mission because there will be asignificant robotic component of the mission. Humanswill need to effectively interact with robots and otherautonomous systems. Today, the primary responsibilityfor fault management lies with the crew or groundpersonnel. In fact, pilots have pointed out the demand forreal-time, on-board integrated diagnostics that provide“answers not just clues” to the causes of multipleanomalous conditions occurring during all phases of flightoperations. Nonintegrated caution warnings are notsufficient because pilots and controllers are responsiblefor cognitive integration that consumes valuable time.Pilots are often required to refer to on-board manuals todetermine the cause of an anomalous event.

As was described in the previous section, next generationintelligent systems are expected to automate much of thefault management process and enable real-time faultmanagement for remotely operated or autonomousvehicles. The incorporation of these advancedtechnologies into the fault management process carrieshuman factors risks, including over-reliance onautomation, information overload, poorly designed userinterfaces, and mode confusion: insufficientunderstanding of automated activity and/or insufficientawareness of the effects of automated actions on systems

functioning. ISHM will be essential to inform bothhumans and autonomous systems of component failuresas well as failures induced by the human-machineinteraction itself. This will inform humans and beenabling to autonomous operations. Numerous mishapshave been reported that were due to the human’s lack ofawareness of the function of the autonomous system. Theautonomous system must also be aware of the goals of thehumans and any obstacles to meeting those goals. Ahuman centered approach to design of these complexsystems will be pursued.

For unmanned, long duration or distant missions theautonomous systems will need to be self-aware. Forexample, the Mars Polar Lander4 could have benefitedfrom a simple integrated health management system.There is evidence to suggest that the lander crashed intothe surface of Mars as a result of misinformation relayedto the landing control system resulting in shut off of theengines at 40 meters above the ground. There were othersensors on board that could have clarified the ambiguousdata but there was no system integration and no intelligentreasoner available to evaluate the overall state of thesystem and take the appropriate course of action. Thecommunication delay between the Earth and Mars is toolong for ground controllers to have had any impact on thiscritical real-time control issue.

For in-space vehicles involved in the Gateway mission,other critical control capabilities may be shared byhumans and autonomous systems such as docking, launchand landing on the moon, aerocapture maneuvers, andcontrol of multiple coordinated micro-spacecraft. For themanned portions of the mission, reliable control of lifesupport systems (including human habitats) will becritical. The control systems will consist of a network ofintelligent agents that work with the ISHM system (Figure4) to sense the environment and reason based on internalstate (stored information that may include sensory dataand goals). Predetermined procedures, constraints, anddomain models allow the determination of the internalstate.

These agents will maintain stability or recover in thepresence of subsystem or system level anomalies andenvironmental uncertainties. They will reconfigure thecontrol system to compensate for damage/failure tocontrol effectors or will gracefully degrade performance,while maintaining functionality to the greatest extentpossible, if unable to fully recover from damage/failure.They will also optimize achievable control performancethrough integration of motion control, power, propulsion,and structural subsystems.

Figure 4, shows how the ISHM architecture may beintegrate with a general purpose integrated reasoningframework for an intelligent agent controlling a vehicle.

6

Figure 4. Intelligent Control System Reasoning Framework

This framework is similar to that used in the RemoteAgent Demonstration that autonomously controlled theion-engine propelled Deep Space One spacecraft in 19992.

Goals or commands are input to the system from a crewmember, remote operator, or another system and areentered into a data and event storage database where theyare sequenced and decomposed by various reasoningengines into primitive commands. Sensory informationand subsystem feedback from previous commands, whichmay be fused or used by the reasoning engines todetermine states that are not directly sensed, (e.g., adiagnosis) are also entered into the database. Thereasoning engines and the temporal database use the flightmodels, rules, etc…, to insure that any commandsequence in the database does not violate a constraint.This will enable the command sequences to adapt tochanges in the system and environment. The executivesends the primitive commands to the specified controlsystem at the appropriate time. As shown in Fig. 4, thesystem also contains a planner, which plays a key role ingoal decomposition, scheduling, and planning repairsrequired from command failures, new or altered goals, orother unexpected information.

Using this approach, plans can be dynamically updated atexecution time. This allows the agent to respond tochange in the system or environment, e.g., reconfiguringitself due to the failure of a component, and achieve thesystem goals or a subset of them. With such a closed loopsystem, commanding and sensing are unified so thatconflicts are resolved prior to execution and decisions aremade based on a consistent state of the system and itsenvironment. An agent may make use of several ofdifferent reasoning engines and be flexible so that it candynamically generate plans to achieve complex goals.The system also enables prognostics through analysis ofhistorical data related to faults/failures, observations,successful response strategies, and trending.

The modular architectures of the systems shown inFigures 3 and 4 have many advantages in thedevelopment, cost and function of complex spacesystems. They allow components to be exchangedwithout redesigning the entire system. This is of particularvalue since it facilitates the integration of specificintelligent system and ISHM technologies withoutrequiring them to meet all the requirements of the vehiclethat it will be used to control.

Low -levelCommands

Integration of Software with

physical systemsPlanner

Domain Models of Vehicle and Flight rules

Domain Models of Vehicle and Flight rules

Domain Models of Vehicle and Flight rules Command

Responses

Pilot/Ground Control Interface

ReasoningEngine

ReasoningEngine

ExecutiveExecutive

Goals, high or low -level commands

Intelligent Control System Reasoning Framework

Telemetry

Robust GoalAchievement

HazardAvoidance

AdaptiveControl

VehicleHealth

Assessment

Capabilities

Faults

Observations

Data and Event Storage

IVHM Kernel

7

The architectures are also amenable to being distributedover multiple computers and controlling multiplevehicles. In order to achieve low latencies betweensensing and acting, particularly when this may involvecomputationally intensive activities such as planning andimage recognition, it is helpful to distribute thecomputational load over multiple processors in a straight-forward manner. Moreover, the framework can be used tocontrol multiple vehicles in a manner similar to how itwould control a single vehicle with multiple subsystems.Thus one vehicle could be used to repair another vehicle.

Modular system software designs allow for information tobe used not only for safe control but for cost effectivemaintenance operations. A properly instrumented ISHMsystem will be able to report maintenance requirementsautonomously. Many hours of routine system inspectioncan be avoided and costly scheduled maintenanceoperations will be replaced with conditioned-basedmaintenance. ISHM will ultimately reduce system lifecycle costs by many orders of magnitude. Significantlyless human interaction will be required for systemdiagnostics and maintenance. This will be essential to thesuccess of the Gateway Mission.

Mission and Technology Challenges

It is possible that the current state of automation could beused to begin development of remote ISHM. However,there are several unresolved issues requiring furtherdefinition, or in some cases, future research. In remoteoperations beyond terrestrial mission control, criticalcontrol capabilities may be shared by humans and anautonomous agent-based ISHM system. How will humansand automation execute “shift changes”, either withonboard crew or when a transfer vehicle comes into rangeor leaves the vicinity of a gateway station?

Current onboard ISHM in space and aircraft iscentralized, while supporting scale-up and increasedcomplexity is leading the field towards decentralizedagent-based architectures. Given networks of automation,who/what intermediates? And how can a critical safetysystem dependent on ad-hoc agent network interactionsbe verified and eventually certified?

Just as in hardware standardization, a wide variety ofdisparate ISHM software approaches across future spacesystems will lead to unnecessary development cost, highrecurring software maintenance and a greater possibilityof induced errors. Some process must define a modularsoftware approach that can be consistent across a broadbase of vehicles and systems.

Given transmission delays, it will be unreasonable to treatthe Deep Space Network as a star architecture for futurevehicle-to-gateway station communications. Someindependent point-to-point in-space communicationscapability will be necessary.

Directions for the Future

Many advances have occurred over the past decade in thesoftware and sensor technologies required for integratedsystem health management. The actual integration ofthese components has not been explored as rigorously. Itis difficult to find testbeds that enable the exploration ofsystem-level architectures to any detail. It is very difficultto find testbeds which are robust enough, and withsufficient fidelity to thoroughly validate all modes ofoperation and the performance of the health managementsystem under failure or degraded conditions.

The modularity required by in-space transportationsystems must be leveraged by the health managementarchitecture for these systems. The process forincremental, staged construction required to buildoutposts, for example, is only now being explored duringthe construction of International Space Station. Manychallenges have arisen in the staged construction of thedata and power management systems for ISS; most of thetroubleshooting has been carried out by ground supportteams. The systems needed for future missions must beable to operate autonomously and must be robust enoughto withstand a variety of failures and still provide thefunctionality required by the mission.

The technologies and processes developed thus far arecapable of supporting the exploration missions of thefuture given proper attention to the final, and perhapsmost difficult, step – the integration.

Acknowledgements

The authors would like to thank the reviewers, GregoryDorais (ARC), Claudia Meyer (GRC), Lui Wang (JSC),Amir Fanjay (JPL), and Anupa Bajwa (ARC), forvaluable input to ISHM planning for this and many othermissions.

References

1. Preliminary Software Design Document (SDD), 2nd

Generation Reusable Launch Vehicle (RLV, IntegratedVehicle Health Management (IVHM), SDD8270370 RevB, Honeywell Space Systems, Contract No. NAS2-01060, October 4, 2002.

8

2. Remote Agent Final Report; http://nmp-techval-reports.jpl.nasa.gov/DS1/Remote_Integrated_Report.pdf

3. R. Wayne Dixon, et al, “Demonstration of an SLI VehicleHealth Management System with In-flight and Ground-based Subsystem Interfaces,” 2003 IEEE AerospaceConference, Big Sky, Montana, March 9-14, 2003.

4. Mishap Cause Classification Report, T. Panontin et al (Tobe Published)