NASA Technical Memorandum 104463

AIAA–91–2528

The Development of a Post-Test

Diagnostic System for

Rocket Engines

June F. Zakrajsek

Lewis Research Center

Cleveland, Ohio

Prepared for the

27th Joint Propulsion Conference

cosponsored by the AIAA, SAE, ASME, and ASEE

Sacramento, California, June 24–27, 1991
develop an automated post-test, post-flight diagnostic system for rocket engines. This project is 

a cooperative effort involving engineers and scientists at NASA Lewis Research Center, NASA 

Marshall Space Flight Center, Aerojet TechSystems Propulsion Division, Rockwell International 

Corporation Rocketdyne Division, and Science Applications International Corporation. The 

automated system is designed to be generic and to automate the rocket engine data review process. 

A modular, distributed architecture with a generic software core was chosen to meet the design 

requirements. The diagnostic system is initially being applied to the Space Shuttle Main Engine ^ 

data review process. The system modules currently under development are the session/message 

manager, and portions of the applications section, the component analysis section and the intelligent 

knowledge server. This paper presents an overview of a rocket engine data review process, the 

design requirements and guidelines, the architecture and modules, and the projected benefits of the 

automated diagnostic system. 

Introduction 

The safe and reliable operation of a rocket engine depends on the proper function of each individual 

component of the engine. To insure successful engine operation many engineers and technicians 

test, troubleshoot, and where possible monitor critical engine components during operation. A 

large engineering effort is spent analyzing post-test/post-flight sensor data to determine if test 

objectives were met and if any anomalous conditions, or failures were present. This data review 

process is very time consuming and labor intensive. The core of the data review process is done 

by visually reviewing the data, which is in the form of numerous graphs. Because this data review 

process is common to all liquid propulsion rocket engines, the ability to automate the functions 

performed by the engineers would benefit both current and future liquid propulsion rocket engines. 

Thus, a need was identified for an automated diagnostic system for liquid propulsion rocket 

engines. 1~2,3 This automated diagnostic system has two basic requirements. These are 1) the system 

be developed with a generic core of software that is not engine specific, and 2) the system must 

automate the data review process. 

An effort was recently initiated by the National Aeronautics and Space Administration (NASA) to 

develop a generic post-test/post-flight diagnostic system for liquid rocket engines. This project is 

a cooperative effort involving engineers and scientists at NASA Lewis Research Center (LeRC), 

NASA Marshall Space Flight Center (MSFC), Aerojet TechSystems Propulsion Division, Rockwell 

International Corporation Rocketdyne Division, and Science Applications International Corporation 

(SAIC). After reviewing several liquid rocket engine propulsion systems, the decision was made 

to use the Space Shuttle Main Engine (SSME) as the first application of the generic post-flight 

/post-test diagnostic system. The SSME was chosen for several factors: 1) The SSME has 

approximately 135 firings and data reviews per year, 2) There is an extensive database that has 

been collected over the last ten years, and 3) The engine is currently planned to operate over the 
required analysis tools in one software package. In the future, more encompassing diagnostic 

techniques and prognostic capabilities will be added to the system, such as pattern recognition 

techniques, neural networks, and quantitative models. This will improve the current data review 

process, in that information as to the time for replacement of a component is based on need rather 

than scheduled maintenance. 

The near-term potential of a post-test/post-flight diagnostic system is to provide the engineer 

reviewing flight or test data with an expedient means of reducing and interpreting the large amount 

of sensor data. Also, by developing and using this diagnostic system, insight into the types of 

algorithms and processes beneficial to performing rocket engine diagnostics and prognostics will 

be developed. By providing a better understanding of the propulsion system and its components, 

and the automation necessary for the diagnostic analysis procedures, the groundwork for developing 

an in-flight, or real-time, diagnostic/prognostic system is being developed. 

This paper highlights the overall procedure used by the engineers to review SSME test and flight 

data, and presents the design guidelines and software architecture chosen for the automated 

diagnostic system, and the system modules required. 

Data Review Process 

After an engine has been flown or tested, the engineers spend a considerable amount of time 

determining if an engine component, subsystem, or system operated normally. The engineers that 

perform the data review process are organized into four major analysis groups. They are the 

performance/systems, combustion devices, turbomachinery, and dynamics groups. Also, there are 

data preparation support groups that produce all the graphs the engineers require to perform the 

data review. Figure 1 illustrates the amount of time spent by each engineering group to perform 

a normal data review. A normal data review is one where there are no anomalies, or where the 

anomaly can be easily resolved. As can be seen in Figure 1, the total amount time to review a 

normal firing is sixty-nine man hours. Since the results of the data review are required before any 

additional test can be conducted, this imposes a time constraint of twenty-four hours on the 

engineers. If the anomaly cannot be easily resolved the time for the data review increases by a 

minimum of twenty man hours.4 

Figure 2 shows that the amount of time required to completely review a flight engine is sixty-four 

man hours. As can be seen in this figure, the amount of time required for the 

performance/systems, turbomachinery, and dynamics groups to review the flight data is greater than 

that required for a test. This is attributed to the critical nature of the flight engines, as well as 

there are three engines required for flight. The remaining groups have either a decrease in review 

2 
The elements and logical flow of the data review process are given in Figure 4. As can be seen 

in this figure, the engineer receives the data in the form of various graphs (Block A), validates the 

data to insure proper sensor/instrumentation operation (Block B), reviews the data for anomalous 

conditions (Block C), and forms conclusions (Block D) as to the operation of the rocket engine. 

The review of the data plots is an iterative procedure which involves comparing the current data 

to past data, highlighting anomalous signatures, formulating a hypothesis as to the cause of the 

anomaly, and proving the hypothesis. 

The successful completion of the review of the data plots, Block C in Figure 4, relies heavily on 

the extensive knowledge required by the engineer. As seen in Table 1, the engineer must know 

not only general engineering principles, but also specifics about the engine operation and design, 

and how to access information sources. Table 2 illustrates some of the information sources that 

the engineer must routinely access when reviewing flight or test data. In some cases, the engineer 

may need additional information when investigating an anomaly in the test data. For example, the 

engineer at NASA MSFC may contact an engineer at Stennis Space Center to determine if anything 

unusual was observed during the test. Also, in the case of an anomaly, the NASA MSFC engineers 

rely heavily on past experience to remember the appropriate test(s) that have had a similar anomaly. 

The engineer must then retrieve the appropriate sensor plots for comparison to the current test. 

Depending on which past test needs to be retrieved, the engineer may locate the required graphs 

from a computer or paper database.‘a2*5 

By using knowledge, experience, and various information sources, the engineer visually review 

each sensor plot and formulates conclusions about the rocket engine operation (Block D in Figure 

4). There are several typical conclusions the engineers make. These are: 

o The data indicates a nominal firing 

o The data indicates an instrumentation problem 

o The data indicates an anomaly which can be attributed to hardware specifics 

o The data indicates a normal system degradation 

o The data indicates an anomaly which can be attributed to a well known and 

identifiable cause 

o The data indicates an anomaly of unknown cause 

The last of these conclusions is the worst possible conclusion; it requires at least twenty additional 

man hours to the data review time, in resolving and assessing the criticality of the cause. 

The heavy reliance on knowledge of the engine system, past tests, and information access makes 

the data review process a labor-intensive and time-consuming task. In order to assist the engineers 

an automated diagnostic system is being developed. This automated system will rely upon both 

3 
o Modular design with emphasis on nonengine specific core modules 

o Capable of handling large amounts of data 

o Include the types of knowledge required by the data review engineer 

o Interface with a variety of information sources 

The architecture chosen to implement these design guidelines is illustrated in Figure 5. 

As seen in Figure 5, the major sections of the architecture are: the intelligent knowledge server 

(IKS) section, the support application section, the component analysis section, and the 

session/message management section. Each of these sections contain a number of modules. The 

session/message manager modules, along with some of the support applications and most of the IKS 

modules are the sections that form the generic core of the diagnostic system. This is illustrated in 

Figure 5 by the shaded areas. These modules provide the backbone of the diagnostics system and 

are being developed to be non-engine specific. The component section modules are those modules 

that concentrate on individual engine component interrelations and mechanics. These four major 

sections of the automated diagnostic system, along with their associated modules, and software and 

hardware specifications are described in detail below. 

Intelligent Knowledge Server Section 

This section provides a function that is basic to the data handling of the diagnostic system. It 

handles large amounts of data and performs the “intelligent” access to the required information 

sources. The tasks involved include: maintenance of local database information, providing multidatabase management, providing high-level math and property queries, performing data retrieval, 

presenting data in standard format, performing sensor or data validation and reconstruction, 

highlighting numerical points of interest, providing user or system customized tables, and providing 

knowledge about the previous tests with a similar anomaly. Most of the functions of this module 

involve the data and its retrieval, but conclusions and diagnosis, along with system reports also are 

included. The advantages of structuring the database in this format is to permit the source data to 

be located at various computer sites. From an implementation standpoint the commercial relational 

database INGRES provides several of the above envisioned tasks. 

An important module of the IKS section is the sensor validation and reconstruction module. The 

purpose of this module is to review the sensor data and to verify the proper operation of the sensor 

at the time of measurement. If the sensor was not operating properly, then the system would 

provide a reconstructed value for the system to use in the engine diagnostic process. The 

reconstructed values and the validation are to be provided to the system by means of a database 

table. An initial study into the best methods to use for validation and reconstruction showed that 

empirical based models were most successful in validating and reconstructing a sensor signal. The 

4 
implemented is a CAE tool. This tool is being implemented as a module using PV-WAVE and will 

provide plotting, statistical analysis, and signal processing capabilities. Another tool is feature 

extraction. The feature extraction module is being written to extract characteristic and trend 

information from the data. It will produce a features table that will include data characteristics that 

engineers utilize in interpreting the data. 

Other application modules that will be included in the system are the startup analysis, mainstage” 

analysis, shutdown analysis, two sigma exception analysis, SSME component and system models, 

and briefing preparation module. The startup, mainstage, shutdown and two sigma analysis are 

application modules required by the component analysis modules. They will provide core analysis 

routines that implement standard analysis procedures used during a particular engine phase, and 

provide a map of the engine during normal operation. The component and system models are 

existing models currently used during the data review process. The requirements of this 

implementation is to provide all of the necessary protocols to the model programs. This ability to 

integrate currently used models and programs within the automated diagnostic system provides the 

engineer with all the required data review tools in one software analysis package. The briefing 

preparation module will be capable of preparing the text, plots and graphs necessary for the data 

review presentations. 

Comnonent Analvsis Section 

There are four major engine-specific technical modules in this section used to analyze the SSME 

propulsion system. These include the performance analysis module, the combustion devices 

module, the turbomachinery module, and the dynamic data module. Each of these technical 

modules will be developed using the expert system shell NEXPERT, in forward chaining mode, 

for the knowledge-bases and procedural code. The primary function of these modules is to review 

the data characteristics and assess the condition of a engine component, sub-component or engine 

system. The modules must interact with other technical modules as well as with core system 

modules. Also, each of these modules contains sub-modules to perform specialized analysis 

functions. For example, the turbomachinery module contains four sub-modules. These are: the 

high pressure oxidizer turbopump, the low pressure oxidizer turbopump, the high pressure fuel 

turbopump, and the low pressure fuel turbopump sub-modules. The first technical sub-module 

being developed is the high pressure oxidizer turbopump sub-module. SAIC is scheduled to deliver 

this sub-module to NASA for evaluation in 1992. 

Session/MessaP;e Management Section 

The session/message manager section is comprised of three modules: the message manager module, 

5 
The blackboard acts as a posting location for information. A central blackboard is used for the 

overall diagnostic system, and individual blackboards are used by each component analysis module. 

Blackboards are occupied by probes. Probes are pattern matching mechanisms that can look for 

messages, conclusions or other needed information, and send messages back to their owners when 

the pattern is matched. The blackboards will be implemented by either an INGRES file, or as part 

of the expert system’s working memory. NEXPERT currently provides this function, where the, 

blackboard is constructed of facts, and rules function as the probes. 

The session manager module tracks the overall system. It provides information as to the current 

state of the analysis. It controls the starting and stopping of the diagnostic system, and also allows 

for the re-start of a particular session without loss of previous results. 

To ensure that the data analysis process is complete and correctly implemented, an audit trail 

module is required. The audit trail provides the information as to which data was examined, which 

events occurred, which hypotheses were considered, which modules and applications were ran, and 

what conclusions were made. The audit trail module works with the session manager and 

NEXPERT, and consolidates and reports the audit trails produced by the various processes of the 

diagnostic system. 

The session/message manager section is currently being implemented by SAIC. It is scheduled to 

be completed and delivered to NASA for evaluation in 1992. 

Software and Hardware 

The initial hardware chosen to host the automated post-test/post-flight diagnostic system is Sun 4 

workstation based. Even though these workstations have been selected, any UNIX platform with 

similar performance and software support would be sufficient. The software required for the 

diagnostic system includes X windows, INGRES relational database, NEXPERT inference engine 

and expert system shell, DATAVIEWS with MOTIF user interface, PV-WAVE Computer-AidedEngineering (CAE) system, and procedural code written in C. 

Concluding Remarks 

The two basic requirements of the automated diagnostic system being developed are: 

1) The system must be generic. 

2) The system must automate the data review process used in rocket engines. 

The first requirement allows the system to be used on a variety of current and future rocket 

6 
The architecture chosen for the diagnostic system meets these guidelines by employing a distributed 

and modular architecture that is both procedural and knowledge-based. Because the diagnostic 

system is designed to be distributed and modular, any future changes to the current SSME, as well 

as applications to future engines will result in procedural and uncomplicated modifications to the 

automated diagnostic system. 

A variety of benefits can be realized by implementing a rocket engine diagnostic system. A nearterm benefit of developing this diagnostic system is to provide engineers with a tool that will allow 

for faster and easier assessment of a rocket engine system. Also, by thoroughly understanding the 

data review process, insight into future algorithms and diagnostic routines that would improve the 

procedures, as well as provide a better understanding of liquid rocket engines, can be achieved. 

In addition, development of a post-test/post-flight diagnostic system represents the first major step 

towards developing a real-time, in-flight diagnostic/prognostic system. A significant additional 

benefit of developing this system is the exchange of expertise and knowledge between NASA Lewis 

Research Center, NASA Marshall Space Flight Center, Rocketdyne, Aerojet, and Science 

Applications International Corporation. 

The post-test/post-flight automated diagnostic system is scheduled to be released for evaluation, 

with the majority of the system core modules and the SSME high pressure oxidizer turbopump submodule, in 1992. Additional modular implementations and refinements are planned over the next 

several years. 

Disclaimer 

Trade names or manufacturer’s names are used in this report for identification purposes only. This 

usage does not constitute an official endorsement either expressed or implied, by the National 

Aeronautics and Space Administration. 

References 

1. Cannon, I.D. Life Prediction for Rocket Engines Task 2: SSME Diagnostic System Final Report. 

Contract NAS3-25884, 1990. 

2. Gage, M., DeHoff, R., Development of Life Prediction Capabilities for Liquid Propellant 

Rocket Engines Task 4: Diagnostic System Architecture Study Final Report. CR 187112, 1990. 

3. Johnson, J.G., Schneemann, G.K. Automated Data Analysis For Space Launch Vehicles. AIAA 

7 
System Architecture Study Final Report. Contract NAS325883, 1991. 

RANGE OFKNOWLEDGE REQUIRED BY ENGINEER 

o Location of data, form of data, software beinp used for data display 

o Relevant historical data needed: parameters, firings, portion of firing(s) 

o How to evaluate data for sensor failures 

o How to operate modeling, data reduction, and plotting programs 

o How to manipulate data into relevant forms 

o Detailed understanding of SSME system and components, and I 

manufacturing operations 

o Recognition of specific data anomalies and profiles 

o Heuristics for dealing with new anomolies 

o Understanding of how to evaluate and conduct a data review 

o Understanding of basic engineering and scientific principles 

TABLE 1: The range of knowledge required of the data review engineer and the posttest/post-flight diagnostic system 

MAJOR SOURCES OF INFORMATION 

o CADS and facilitv data files 

o Dynamics data file 

o Test objectives 

o Hardware inspection data 

o Statistical databases of hot-fire data 

o Anomalous database 

o Documents on how failures propagate and effect the system 

o Part tracking information 

o Build information and firing times per part I 

TABLE 2: Major sources of information required by the engineer during the SSME data 

review process 

8 
REVIEW TIME PER ENGINEERING GROUP 

1 Performance/Systems Group 

2 Combustion Devices Group 

3 Turbomachinery Group 

4 Dynamics Group 

5 Data Preparation Group 

6 Total Man Hours 

FIGURE 1: Man hours per engineering group for a normal stennis test. 

80 

60 

40 

20 

0 2 3 5 

REVIEW TIME PER ENGINEERING GROUP 

1 Performance/Systems Group 

2 Combustion Devices Group 

3 Turbomachinery Group 

4 Dyunamcis Group 

5 Date Preparation Group 

6 Total Man Hours 

FIGURE 2: Man hours per engineering group for flight data 

9 
300 - 

200 - 

!i 

z 

2 

loook& TED 

1 2 

TBD TBD 

4 

1 PetformanceBystems Group 

2 Combustion Devices Group 

3 Turbomachinery Group 

4 Dynamics Group 

5 Data Preparation Group 

6 Total Man Hours 

mmv nm PER ENGINEERING GROUP 

FIGURE 3: Man hours per engineering group for a normal TTBE test . 

For groups with TBD, the data review time required cannot be reasonably estimated. 

10 
y 

Anomalies 

L / 

i 

\ 

/rCreate and Focus 

- Hypothesis 

L. / 

DONE 

FIGURE 4: Elements and logical flow diagram of the data review process. 

t Zomponentj L Analysis 1 

T-F Performa&> 

L-----ent and 

I L system models 

1 :~.:.:+: _...,...; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

-~ KEY 

,sii~~~“rili~~i~~~~~~ 

m generic 

FIGURE 5: Architecture For Post-Test/Post-Flight Diagnostic System ( engine specfic 

11 
REPORT DOCUMENTATION PAGE

2. REPORT DATE

18. SECURITY CLASSIFICATION 19. SECURITY CLASSIFICATION

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources,

gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of

this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson

Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)

Prescribed by ANSI Std. Z39-18

Form Approved

12b. DISTRIBUTION CODE

10. SPONSORING/MONITORING

8. PERFORMING ORGANIZATION

5. FUNDING NUMBERS

3. REPORT TYPE AND DATES COVERED

4. TITLE AND SUBTITLE

6. AUTHOR(S)

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

11. SUPPLEMENTARY NOTES

12a. DISTRIBUTION/AVAILABILITY STATEMENT

13. ABSTRACT (Maximum 200 words)

14. SUBJECT TERMS

17. SECURITY CLASSIFICATION

16. PRICE CODE

15. NUMBER OF PAGES

20. LIMITATION OF ABSTRACT

Unclassified Unclassified

Technical Memorandum

Unclassified

National Aeronautics and Space Administration

Lewis Research Center

Cleveland, Ohio 44135–3191

National Aeronautics and Space Administration

Washington, DC 20546–0001

1. AGENCY USE ONLY (Leave blank)

NASA TM–104463

AIAA–91–2528

E–6304

WU–590–21–41

Unclassified -Unlimited

Subject Category 61

This publication is available from the NASA Center for AeroSpace Information, (301) 621–0390.

12

A03

June F. Zakrajsek

The Development of a Post-Test Diagnostic System for Rocket Engines

Prepared for the 27th Joint Propulsion Conference cosponsored by the AIAA, SAE, ASME, and ASEE, Sacramento,

California, June 24–27, 1991. Responsible person, June F. Zakrajsek, (216) 433–8774.

Diagnosis; Automated diagnostics; Engine monitoring instruments

An effort has been undertaken by the National Aeronautics and Space Administration (NASA) to develop an

automated post-test, post-flight diagnostic system for rocket engines. This project is a cooperative effort involving

engineers and scientists at NASA Lewis Research Center, NASA Marshall Space Flight Center, Aerojet

TechSystems Propulsion Division, Rockwell International Corporation Rocketdyne Division, and Science Applications International Corporation. The automated system is designed to be generic and to automate the rocket engine

data review process. A modular, distributed architecture with a generic software core was chosen to meet the design

requirements. The diagnostic system is initially being applied to the Space Shuttle Main Engine data review

process. The system modules currently under development are the session/message manager, and portions of the

applications section, the component analysis section and the intelligent knowledge server. This paper presents an

overview of a rocket engine data review process, the design requirements and guidelines, the architecture and

modules, and the projected benefits of the automated diagnostic system.

June 1991