William A. Maul and Christopher E. Fulton

QinetiQ North America, Cleveland, Ohio

Software Users Manual (SUM)

Extended Testability Analysis (ETA) Tool

NASA/CR—2011-217240

November 2011
NASA STI Program . . . in Profi le

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA Scientifi c and Technical Information (STI) 

program plays a key part in helping NASA maintain 

this important role.

The NASA STI Program operates under the auspices 

of the Agency Chief Information Offi cer. It collects, 

organizes, provides for archiving, and disseminates 

NASA’s STI. The NASA STI program provides access 

to the NASA Aeronautics and Space Database and 

its public interface, the NASA Technical Reports 

Server, thus providing one of the largest collections 

of aeronautical and space science STI in the world. 

Results are published in both non-NASA channels 

and by NASA in the NASA STI Report Series, which 

includes the following report types:

• TECHNICAL PUBLICATION. Reports of 

completed research or a major signifi cant phase 

of research that present the results of NASA 

programs and include extensive data or theoretical 

analysis. Includes compilations of signifi cant 

scientifi c and technical data and information 

deemed to be of continuing reference value. 

NASA counterpart of peer-reviewed formal 

professional papers but has less stringent 

limitations on manuscript length and extent of 

graphic presentations.

• TECHNICAL MEMORANDUM. Scientifi c 

and technical fi ndings that are preliminary or 

of specialized interest, e.g., quick release 

reports, working papers, and bibliographies that 

contain minimal annotation. Does not contain 

extensive analysis.

• CONTRACTOR REPORT. Scientifi c and 

technical fi ndings by NASA-sponsored 

contractors and grantees.

• CONFERENCE PUBLICATION. Collected 

papers from scientifi c and technical 

conferences, symposia, seminars, or other 

meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientifi c, 

technical, or historical information from 

NASA programs, projects, and missions, often 

concerned with subjects having substantial 

public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientifi c and 

technical material pertinent to NASA’s mission.

Specialized services also include creating custom 

thesauri, building customized databases, organizing 

and publishing research results.

For more information about the NASA STI 

program, see the following:

• Access the NASA STI program home page at 

http://www.sti.nasa.gov

• E-mail your question via the Internet to help@

sti.nasa.gov

• Fax your question to the NASA STI Help Desk 

at 443–757–5803

• Telephone the NASA STI Help Desk at

 443–757–5802

• Write to:

 NASA Center for AeroSpace Information (CASI)

 7115 Standard Drive

 Hanover, MD 21076–1320
William A. Maul and Christopher E. Fulton

QinetiQ North America, Cleveland, Ohio

Software Users Manual (SUM)

Extended Testability Analysis (ETA) Tool

NASA/CR—2011-217240

November 2011

National Aeronautics and

Space Administration

Glenn Research Center

Cleveland, Ohio 44135

Prepared under Contract NNC06BA07B, Task NNC06E014T
Available from

NASA Center for Aerospace Information

7115 Standard Drive

Hanover, MD 21076–1320

National Technical Information Service

5301 Shawnee Road

Alexandria, VA 22312

Available electronically at http://www.sti.nasa.gov

Trade names and trademarks are used in this report for identifi cation 

only. Their usage does not constitute an offi cial endorsement, 

either expressed or implied, by the National Aeronautics and 

Space Administration.

Level of Review: This material has been technically reviewed by NASA expert reviewer(s).
NASA/CR—2011-217240 iii 

Table of Contents 

1.0 Scope .................................................................................................................................................... 1

1.1 Identification ............................................................................................................................... 1

1.2 System Overview ........................................................................................................................ 1

1.3 Document Overview ................................................................................................................... 1

1.4 Formats and Conventions ........................................................................................................... 1

2.0 Referenced Documents......................................................................................................................... 1

3.0 Software Summary ............................................................................................................................... 2

3.1 Software Application .................................................................................................................. 2

3.2 Software Inventory ...................................................................................................................... 2

3.3 Software Environment ................................................................................................................ 3

3.4 Software Organization and Overview of Operation .................................................................... 4

3.5 Security and Privacy ................................................................................................................... 4

3.6 Assistance and Problem Reporting ............................................................................................. 4

4.0 Software Operations ............................................................................................................................. 4

4.1 Installation and Setup .................................................................................................................. 4

4.2 Basic Operation ........................................................................................................................... 7

5.0 Processing Reference Guide ................................................................................................................. 9

5.1 Capabilities ................................................................................................................................. 9

5.2 Processing Procedures ................................................................................................................ 9

5.2.1 Generation of the ETA Tool Detectability Report ........................................................ 9

5.2.2 Generation of the ETA Tool Test Utilization Report .................................................. 11

5.2.3 Generation of the ETA Tool Failure Mode Isolation Report ...................................... 13

5.2.4 Generation of the ETA Tool Component Isolation Report ......................................... 17

5.2.5 Generation of the ETA Tool Effect Mapping Report ................................................. 23

5.2.6 Generation of the ETA Tool Sensor Sensitivity Report .............................................. 31

5.3 Related Processing .................................................................................................................... 36

5.4 Messages ................................................................................................................................... 36

5.5 Quick-Reference Guide ............................................................................................................ 38

6.0 Notes................................................................................................................................................... 38

6.1 Acronyms .................................................................................................................................. 38

6.2 Terms and Definitions ............................................................................................................... 39

Appendix A.—Diagnostic Modeling Conventions ..................................................................................... 41

A-1 Conventions for Tests ................................................................................................................. 41

A-2 Conventions for Failure Mode Modules ..................................................................................... 41

A-3 Conventions for Component Modules ........................................................................................ 42

A-4 Conventions for Technology Labels ........................................................................................... 42

A-5 Conventions for Switch Modes ................................................................................................... 42

A-6 Hierarchical Labels ..................................................................................................................... 42

Appendix B.—Diagnostic Model Example ................................................................................................ 45
 
NASA/CR—2011-217240 v 

Change Record 

Extended Testability Analysis (ETA) Tool Software Users Manual 

Revision 

Effective 

Date Description of Change 

Draft 12/15/2010 Initial draft of Users manual 

Version 1.3 01/07/2011 Draft for formal RHC Technical Review 

Version 1.4 01/10/2011 Updated draft—added error code messages to Section 5.4 

Version 1.5 01/21/2011 Small modifications based on updated error codes and compiler 

information 

Version 1.6 02/22/2011 Incorporated initial reviews from the two principle reviewers to 

both the User guide and the software package. As a result of 

some of the software modifications, several of the figures and 

some of the text discussions required modification 

Version 2.0 04/25/2011 Draft completed peer review 

Version 2.1 06/02/2011 Draft completed Branch Chief review

Version 2.2 06/07/2011 Approved by NASA management for publication as NASA TM 

NASA/CR—2011-217240 1 

1.0 Scope 

1.1 Identification 

This document applies to the Extended Testability Analysis (ETA) Tool software, Version 6.7, release 1.0. 

1.2 System Overview 

The purpose of the ETA Tool software is to process the testability analysis results from the Testability Engineering 

And Maintenance System (TEAMS) Designer program and provide the user with detailed documentation of the 

results. The TEAMS Designer is commercial-off-the-shelf software with the capability to analyze a diagnostic 

model of the system under study. The diagnostic model is a directed graph representation of the failure effect 

propagation paths within the system’s physical architecture. The ETA Tool extracts information from the TEAMS 

Designer analysis output and the associated diagnostic model to provide a detailed set of reports highlighting aspects 

of the system’s diagnostic performance. The ETA Tool was developed under the NASA Constellation Program to 

support the Functional Fault Analysis (FFA) team for the Ares I Launch Vehicle. 

The ETA Tool software was initially developed in response to system engineering requests to summarize the 

testability results from the diagnostic model and was extended to incorporate specific system information captured 

within the diagnostic model. The ETA Tool relies on the testability analysis output from TEAMS Designer and the 

diagnostic modeling conventions established by the Ares I FFA team (Appendix A). However, the version of the 

tool associated with this user manual was generalized for public distribution and application to a broad spectrum of 

systems requiring testability analysis. 

1.3 Document Overview 

This user manual describes the implementation and use of the ETA Tool software. The manual first provides an 

overview of the software package. It then provides directions for software installation, setup, and execution. The 

ETA Tool is a command line process with several user-selectable report output options. Example reports used to 

demonstrate the output options were generated for a generic system, the details of which are provided in 

Appendix B. The intent of this manual is to provide the user the information needed to operate the ETA Tool 

successfully and generate specific testability analysis reports. This manual is not intended to educate the user in the 

operation of the TEAMS Designer software package nor in the broader context of diagnostic analysis and 

assessment. 

1.4 Formats and Conventions 

Sans-serif Directory names, file names, function names and screen output are displayed in this 

font. For example: xls2csv.exe 

Italics Book or report titles and names of book or report sections, mathematical symbols 

and notation, and the introduction of new terms. For example: Introduction

2.0 Referenced Documents 

Documents referenced in this report are listed below 

Document number Title 

NPR 7150.2 NASA Software Engineering Requirements 

GLPR 7150.1 GRC Software Engineering Requirements 

GRC-TPLT-SUM Software Users Manual Template 

MIL-STD-1629A Military Standard Procedures for Performing a Failure Mode, Effects and 

Criticality Analysis 

<TBD> NASA Constellation Program Fault Management Terminology Report, Johnson, 

S.B.; and Day, J.C.: September 10, 2010 (unpublished). 
NASA/CR—2011-217240 2 

3.0 Software Summary 

3.1 Software Application 

The ETA Tool extracts information from the TEAMS Designer analysis output and the associated diagnostic model 

to provide a detailed set of reports highlighting aspects of the system’s diagnostic performance. Here, diagnostic 

performance implies the systems ability to detect the effects propagated from failure modes and to isolate system 

faults or faulty components The TEAMS testability analysis is performed on a diagnostic model of a physical 

system. The testability results and the diagnostic model are accessed by the ETA Tool so that further processing can 

extend the testability analysis. The extended analysis provides failure effect detection and fault isolation information 

in a consistent report format. The ETA Tool is capable of generating the following extended analysis reports: 

 Detectability Report provides details that show how each tested failure mode was detected 

 Test Utilization Report identifies all failure modes detected by each system test. 

 Failure Mode Isolation Report demonstrates the ability of the system to discriminate between failure 

modes. 

 Component Isolation Report demonstrates the ability of the system to discriminate between failure modes 

relative to the components containing the failure modes. 

 Effect Mapping Report identifies failure modes that result in user specified system-level effects. 

 Sensor Sensitivity Analysis Reports describes the impact of the loss of a sensor on the ability of the 

system to detect and isolate the various failure modes. 

The ETA Tool reports can be converted into printable formats or viewed directly from computer Internet browsers. 

3.2 Software Inventory 

The following files are included in the ETA Tool, Version 6.7—Release 1.0 package 

Basic_System <directory>

 Contains files for the example diagnostic model, including an example testability output cycle for 

TEAMS Designer which can be used to demonstrate the ETA Tool. 

Sample Output <directory>

 Contains the output file from an ETA Tool example case for the Basic_System model. 

Basic_System_sensor_file.csv <file>

 Example sensor file in comma separated variable (CSV) format 

 Required for any ETA Tool analysis.

Basic_System_Sensor_Sensitivity_Study.csv <file>

 Example instrumentation information file in CSV format 

 Required for the sensor sensitivity analysis option

ETAT_v6_7.c <file>

 ETA Tool source code written in the C programming language 

ETAT_v6_7.exe <file>

 Windows executable version of the ETA Tool 

 Compiled with GCC version 4.5.0 compiler using MinGW headers and libraries (10/30/2010 released 

package)
NASA/CR—2011-217240 3 

makefile <file>

 Contains compiler directives used to compile, link, and create executable software 

 Tested using GCC version 4.5.0 compiler using MinGW headers and libraries (10/30/2010 released 

package)

README File.docx <file>

 Lists contents of the ETA Tool zip-file 

 Provides a brief example showing how to run the program 

 Contains code revision history

set-env.bat <file>

 Example DOS batch file to set a DOS environment variable for the highest-level directory used by 

the ETA Tool 

xls2csv.exe <file>

 Windows executable program used by the ETA Tool internally to convert the EXCEL file to a 

comma-separated variable (CSV) file during processing 

XLStoCVS.vbs <file>

 Visual basic script used to convert an EXCEL file to a CSV-formatted file. 

 Pre-compiled code for previously described xls2csv.exe executable. 

 Can be run from a command window 

The software release package contains two directories: Basic_System and Sample Output. The first directory, 

named Basic_System, contains the diagnostic model from an example system. Under the Basic_System directory 

structure are two subdirectories; a model subdirectory that contains the TEAMS diagnostic model and a description 

subdirectory which contains two documents that detail the general design and operation of the example system 

modeled. The description directory in this package also contains an example output report set from the ETA Tool 

for the Basic_System model. The Sample Output directory contains sample analysis output files from a single 

processing cycle of the ETA Tool. 

3.3 Software Environment 

This section identifies the hardware and software resources that are required for a user to install and run the ETA 

Tool. The software is intended to be multi-platform operational. However, at this time, the software has only been 

tested with an Intel Processor-based Windows XP system. The program requires the following external software 

program: 

 The included executable has been compiled with the GCC (version 4.5.0) compiler using MinGW headers 

and libraries (10/30/2010 released package) 

The software has been developed and tested on the following platform: 

 Operating System: Microsoft Windows XP Professional 2002, Service Pack 3 

 Operating Platform: Q37 XPPro Multi Platform Load Intel® CoreTM 2 Duo CPU T7500, 2.20 GHz, 3.5 GB 

RAM
NASA/CR—2011-217240 4 

3.4 Software Organization and Overview of Operation 

The ETA Tool executable and the xls2csv.exe file should be located in the same directory. The ETA Tool program 

is operated from the command line. The ETA Tool assumes that the system environmental variable TEAMS is 

defined prior to ETA Tool execution. This variable is used to define the location of the TEAMS diagnostic model on 

the hard drive of the user’s computer. The model information and testability reports used by the ETA Tool are stored 

by TEAMS in pre-defined subdirectories under the TEAMS directory. During execution, the ETA Tool will copy 

certain testability analysis output files to the local directory containing the ETA Tool executable and further process 

them. The program will also remotely access certain diagnostic model files to extract design information. Files 

containing final analysis reports from the ETA Tool will also be placed in the directory containing the ETA Tool 

executable. The types of reports generated will depend on the command line syntax used by the user to run the ETA 

Tool software. 

3.5 Security and Privacy 

The ETA Tool is Class E software as defined in Glenn Procedural Requirement (GLPR) 7150.1 GRC Software 

Engineering Requirements, developed with U.S. government funding. As such, it is free and available without 

restriction for use by the general public. The user accepts any risks to their system or damage or loss of data with the 

operation of this software program. 

3.6 Assistance and Problem Reporting 

This software is officially unsupported. If there are any issues or questions concerning the software, the user may 

contact the principal developer, but an immediate response should not be expected. Further, the government makes 

no guarantees regarding compatibility with operating system software or compilers with which the ETA Tool 

software has not been test. 

4.0 Software Operations 

4.1 Installation and Setup 

ETA Tool version 6.7 is packaged in a compressed file. The contents can all be extracted into a file directory that 

will be hence forth named ETAT_HOME directory. A list of files included in the compressed file is given in 

Section 3.2. 

A pre-compiled version of the ETA Tool is included for Windows-based computers. The makefile provides the user 

with an example that demonstrates the process for generating the ETA Tool executable. The file will need to be 

modified to reflect the available C compiler, compiler options and compiler location on the user’s computer. 

The ETA Tool expects a system environmental variable to be set prior to ETA Tool execution that defines the 

location of the TEAMS diagnostic model. The process for setting the environmental variable will be dependent on 

the computer platform and operating system. The ‘set-env.bat’ file included with the distribution package contains 

an example of syntax required to define the environmental variable for a DOS shell session. Also, it sets the 

environmental variable to reference the example model included in the package to allow exercising the ETA tool 

without requiring a TEAMS installation. However, during normal use of the ETA tool, this command should be 

modified to reference the installed TEAMS diagnostic model. For example, 

>> set TEAMS=C:\TEAMS\Basic_System\model

Setting the environmental variable by running the batch file at the command line or by directly typing the ‘set’ 

commands, should define the variable for the current DOS shell session. Environmental variables can also be 

defined in Microsoft Windows in the ‘Control Panel’ under the ‘System’ icon. 

Two instrumentation files are required as inputs for the ETA Tool processing and must be created by the user prior 

to processing. In order for the ETA Tool to access these files, they must be placed in the same directory as the ETA 

Tool executable. These files contain basic design information that requires updating only if the instrumentation in 

the system under analysis is changed. 
NASA/CR—2011-217240 5 

The first file is the sensor input file. This file, in a CSV format, is required for every ETA Tool analysis report. The 

sensor input file developed for the example system is provided as a template for use in creating customized sensor input 

files for user applications. The sensor input file for the example problem is named Basic_System_sensor_file.csv 

and is located in the ETAT_HOME directory. Table 1 displays a portion of this file. The following information is 

contained in the sensor input file: 

 Measurement Identifier—Required unique string that is used to identify the sensor. Within the diagnostic 

model, the test name should contain this string (see Appendix A—Diagnostic Modeling Conventions). The 

ETA Tool attempts to match these values to the “Measurement Identifier” field used in the test naming 

conventions of the diagnostic model. 

 Other Measurement Identifier—Optional measurement identifier that could be used in future reporting 

needs. The ETA Tool will also check to see if this string is utilized in the diagnostic model test naming 

convention field for “Measurement Identifier”. Often within a program instrumentation can have multiple 

identifiers that various groups employ. 

 Schematic Identifier—Optional identifier that represents the schematic design representation of the sensor. 

The ETA Tool uses this field to align the sensor to the proper hierarchical module within the diagnostic 

model. Reported if available. 

 3rd Measurement Identifier—Optional identifier that could be used in future reporting needs. Often within a 

program instrumentation can have multiple identifiers that various groups employ. 

 Subsystem—Optional. Portion of the system where the sensor resides. Currently not used by the ETA Tool. 

 Component—Optional. Lower level portion of the system where the sensor resides. Currently not used by 

the ETA Tool. 

 Short Description—Optional. Brief description of the sensor. 

If there are no entries for any of the optional columns, then the ‘None’ string is required. This file can have any 

name and can be specified as part of the command line syntax. If the naming convention, 

<Model Name>_sensor_file.csv is used, where the model name is the diagnostic model being evaluated, the ETA 

Tool will access the file from the current directory without command line specification. 

TABLE 1.—PORTION OF THE SENSOR INPUT FILE REQUIRED BY THE ETA TOOL PROCESSING 

Measurement 

Identifier 

Other 

Measurement 

Identifier 

Schematic 

Identifier 

3rd 

Measurement 

Identifier Subsystem Component Short Description 

SEN0001 SEN0001 SS1 None Hydraulic 

Pump 

Assembly 

Turbine Pitch Turbine Speed 

Sensor 

SEN0002 SEN0002 SS2 None Hydraulic 

Pump 

Assembly 

Turbine Yaw Turbine Speed 

Sensor 

SEN0003 SEN0003 PV11 None Hydraulic 

Pump 

Assembly 

PSV Pitch Propellant 

Supply Valve 

Position 

SEN0004 SEN0004 PV12 None Actuator PSV Pitch Pressure 

Selector Valve 

Position 

SEN0005 SEN0005 PV21 None Hydraulic 

Pump 

Assembly 

PSV Yaw Propellant 

Supply Valve 

Position 

SEN0006 SEN0006 PV22 None Actuator PSV Yaw Pressure 

Selector Valve 

Position 
NASA/CR—2011-217240 6 

TABLE 2.—Concluded. 

Measurement 

Identifier 

Other 

Measurement 

Identifier 

Schematic 

Identifier 

3rd 

Measurement 

Identifier Subsystem Component Short Description 

SEN0007 SEN0007 dP1 None Hydraulic 

Fluid 

Assembly 

Filter Pitch Delta Pressure 

Filter Sensor 

SEN0008 SEN0008 dP2 None Hydraulic 

Fluid 

Assembly 

Filter Yaw Delta Pressure 

Filter Sensor 

SEN0009 SEN0009 P11 None Hydraulic 

Pump 

Assembly 

Turbine Pitch Turbine 

Propellant Inlet 

Pressure 

SEN0010 SEN0010 P12 None Hydraulic 

Fluid 

Assembly 

None Pitch Hydraulic 

Supply Pressure 1 

The second sensor input file, the sensor sensitivity study input file, is only required when the sensor sensitivity 

analysis option is specified on the command line. The sensor sensitivity study input file for the example problem is 

named Basic_System_Sensor_Sensitivity_Study.csv and is located in the ETAT_HOME directory. 

For illustrative purposes, a portion of the file is shown in Table 2. This file defines the sensor groupings for the 

analysis. The sensor sensitivity analysis cycles through the available sensors three times. The first pass removes 

individual sensors from the system and determines the diagnostic impact. During the second and third passes, groups 

of sensors are removed one group at a time. The first column in this file, Measurement Identifier, specifies the 

individual sensors to be analyzed in the sensor sensitivity analysis. The unique label must be identical to an entry in 

the basic sensor file, Measurement Identifier column, presented above. The second column in this sensor file, 

Group 1 Identifier, tags individual sensors with a group name that will be used to extract those sensors together 

during the second sensor sensitivity analysis cycle. The third column, Group 2 Identifier, performs the same 

function for the third sensor sensitivity analysis cycle. If a sensor is not involved in a group for the second or third 

analysis cycle, a ‘None’ entry is required in the respective columns. This file should be saved in a comma-separatedvariable format. 

TABLE 3.—PORTION OF THE SENSOR INFORMATION INPUT FILE REQUIRED BY 

THE ETA TOOL SENSOR SENSITIVITY ANALYSIS PROCESSING 

Measurement 

Identifier Group 1 Identifier Group 2 Identifier 

SEN0001 None Turbine Speed Sensor 

SEN0002 None Turbine Speed Sensor 

SEN0003 None Propellant Supply Valve Position 

SEN0004 None Pressure Selector Valve Position 

SEN0005 None Propellant Supply Valve Position 

SEN0006 None Pressure Selector Valve Position 

SEN0007 None Delta Pressure Filter Sensor 

SEN0008 None Delta Pressure Filter Sensor 

SEN0009 None Turbine Propellant Inlet Pressure 

SEN0010 Pitch Hydraulic Supply Pressure Hydraulic Supply Pressure 

SEN0011 Pitch Hydraulic Supply Pressure Hydraulic Supply Pressure 

SEN0012 None Turbine Propellant Inlet Pressure 

SEN0013 Yaw Hydraulic Supply Pressure Hydraulic Supply Pressure 

SEN0014 Yaw Hydraulic Supply Pressure Hydraulic Supply Pressure 

SEN0015 None Propellant Supply Valve Current 

SEN0016 None Actuator Power Valve Solenoid Current 
NASA/CR—2011-217240 7 

4.2 Basic Operation 

The ETA Tool program is executed from the DOS command line with user-selectable options. The following text 

provides a description of the proper syntax for the ETA Tool version 6.7; 

ETAT_v6_7 {-i ins_file.csv} {-d} {-s1 ss_file.cvs} {-D} {-T} {-E} {-I} {-iso label} 

where 

 {-i ins_file.cvs} Specifies the CSV-formatted sensor file to use in the ETA Tool analysis. 

If this option is not specified, the ETA Tool will attempt to access a 

default sensor file by the naming convention 

“<Model Name>_sensor_file.csv” 

 {-d} Indicates a debugging option which turns on certain screen printing 

output for ETA Tool developers. 

 {-s1 ss_file.cvs} Indicates that the sensors sensitivity analysis is to be performed and the 

CSV-formatted file to use containing additional sensor information. 

 {-D} Generates the Detectability Report 

 {-T} Generates the Test Utilization Report 

 {-E} Generates the Effect Mapping Report 

 {-I} Generates the Failure Mode Isolation Report 

 {-iso label} Generates the Component Isolation report and indicates the hierarchical 

label to be used in the component-isolation analysis 

Upon completion of the ETA Tool processing, a main output file is generated. The main output file is in HyperText 

Markup Language (HTML) format and is displayable within any of the common Internet browsers. It has been 

tested and is known to work correctly with Internet Explorer, 7.0, Mozilla Firefox 3.6.13, Google Chrome 9.0, 

Safari 5.0 and Opera 11.0 browsers. The naming convention for the main output file is as follows: 

<TEAMS diagnostic model name>_TestAnalysis_Main.htm 

The main output file for the example problem is: 

.\ ETAT_HOME \Basic_System_TestAnalysis_Main.htm 

The main output file has three sections separated by blue horizontal lines. The top section contains testability 

conditions for the analysis conducted by TEAMS. The second section contains hyper-linked documents from the 

TEAMS Designer testability analysis. These documents are not modified by the ETA Tool and are provided to the 

user for reference information. The last section contains hyper-linked documents of reports generated by the ETA 

Tool based on the options selected by the user at run time. Note that only the reports specified by the user as part of 

the command line syntax will be linked by the main report. Figure 1 illustrates an example of the ETA Tool main 

report file. 
NASA/CR—2011-217240 8 

Figure 1.—Main output report file generated by the ETA Tool software. 
NASA/CR—2011-217240 9 

5.0 Processing Reference Guide 

This section provides a demonstration and explanation for each of the six ETA Tool reports. In addition, the output 

from a simple TEAMS model is used to demonstrate and explain the processes that generate each of the available 

ETA Tool reports. As part of the example, command line syntax for the various reports is discussed. 

5.1 Capabilities 

Each report output option is independent of the others. The user may select any or all of the options during a single 

processing cycle. 

5.2 Processing Procedures 

The command line syntax for each report will be discussed individually in subsequent subsections by describing any 

special input requirements and the resulting output report. In each case, the example system provided was utilized to 

generate the reports for illustration. 

5.2.1 Generation of the ETA Tool Detectability Report 

Syntax for generating a Detectability Report: 

>> ETAT_v6_7.exe –D 

Special Input Requirements: 

None 

Output Report Description: 

The Detectability report generated for the example system provided in the software package is named:

.\ETAT_HOME \Basic_System_Detectability_Report.htm. 

The report can be either opened directly into an Internet browser or accessed by the “Detectability Report” link on 

the main output file, Basic_System_TestAnalysis_Main.htm.

The Detectability report provides details regarding the detection or missed detection of failure modes using the 

available suite of detection tests. This analysis and reporting capability proved useful during the design phase of 

NASA’s Ares I Project, when verifying the ability of subsystem designs to meet requirements regarding the 

detection of specific failure modes. The Detectability report identified the sensors and tests capable of providing 

detection of effects propagated by the failure mode. 

The Detectability report generated by this command line syntax may be found in the ETAT_HOME directory. 

Figure 2 illustrates the ETA Tool Detectability report for the example diagnostic model. The report contains three 

sections separated by a blue horizontal line. The top section lists the testability conditions for the analysis conducted 

by TEAMS. 

The second section contains metrics generated by the ETA Tool during the detectability analysis. 

 Number of Failure Modes—the number of failure modes that are active for the specified testability analysis 

conditions. 

 Number of Tests—the number of tests available for the specified testability analysis 

 Overall Detection Coverage—a calculated metric that is equal to the number of detected failure modes 

divided by the total number of failure modes

This section also lists the failure modes, if any, that were not detected by any test during this analysis. For large lists 

of undetected failures (greater than 10 failure modes), a separate report is generated and hyper-linked to this section. 

The last section of this report presents information for each detected failure mode where results for the individual 

failure modes are separated by a green horizontal line. For each failure mode, the component from which the failure 

mode originated, the failure mode name, and Failure Mode and Effect Analysis (FMEA) number are reported. A 

table is reported containing the tests that detected the failure mode, including the sensor identifier, sensor description 

and test name. 
NASA/CR—2011-217240 10 

Figure 2.—ETA tool detectability report for the example diagnostic model. 
NASA/CR—2011-217240 11 

5.2.2 Generation of the ETA Tool Test Utilization Report 

Syntax for generating a Test Utilization Report: 

>> ETAT_v6_7.exe -T 

Special Input Requirements: 

None 

Output Report Description: 

The Test Utilization report generated for the example system provided in the software package is named: 

.\ ETAT_HOME \ Basic_System_Test_Utilization_Report.htm

The report can be either opened directly into an Internet browser or accessed by the “Test Utilization Report” link on 

the main output file, Basic_System_TestAnalysis_Main.htm.

The Test Utilization report provides details regarding the ability of each test to detect system failure modes. This 

information provides justification for retaining a test and the associated sensor. As with any launch vehicle, during 

the design phase of NASA’s Ares I Project studies were continuously conducted to scrub down (i.e., remove 

unnecessary) sensors from the instrumentation suite. During these studies, system designers were required to 

demonstrate the usefulness of each sensor—this analysis could support that demonstration from the diagnostic 

perspective. 

The Test Utilization report generated by this command line option contains four sections that are separated by blue 

horizontal lines. The top section contains testability conditions for the analysis conducted by TEAMS. The TEAMS 

analysis date and time, as well as the diagnostic model are reported. This section also includes the TEAMS analysis 

options selected such as the technology labels, test labels and system modes. 

The second section displays a simple reminder notice to the user that the results presented here do not include tests 

that solely detect their own sensor failure modes. 

The third section contains metrics generated during the ETA Tool process relevant to the system’s test utilization 

analysis. The number of tests evaluated in this analysis, less the tests that provided detection solely for their own 

sensors failure mode, and the number of tests that provided no detection for the failure modes considered in the 

testability analysis are reported here. This section also lists the tests not utilized for detection in this analysis in a 

table format, providing the test name, corresponding sensor identifier and sensor description. 

In the last section, each test is presented, separated by a green horizontal line. For each test, the test name, 

corresponding sensor and sensor description are reported. In addition, a table containing all the failure modes 

detected by that test is also reported here. The tabulated data includes the failure mode name, the FMEA identifier, 

the name of the component from which the failure mode originated, and the criticality value assigned to the failure 

mode for the current phase of operation. 

Figure 3 illustrates the ETA Tool Test Utilization report for the example diagnostic model. 
NASA/CR—2011-217240 12 

Figure 3.—ETA tool test Utilization report for the example diagnostic model. 
NASA/CR—2011-217240 13 

5.2.3 Generation of the ETA Tool Failure Mode Isolation Report 

Syntax for generating a Failure Mode Isolation Report: 

>> ETAT_v6_7.exe -I 

Special Input Requirements: 

None 

Output Report Description: 

The Failure Mode Isolation report generated for the example system provided in the software package is named; 

.\ ETAT_HOME \ Basic_System_Failure_Mode_Isolation_Report.htm

The report can be either opened directly into an Internet browser or accessed by the “Failure Mode Isolation Report” 

link on the main output file, Basic_System_TestAnalysis_Main.htm.

The Failure Mode Isolation report provides information on the system’s ability to isolate each of the system’s failure 

modes. This analysis and reporting capability proved useful during the design phase of NASA’s Ares I Project for 

verifying the ability of subsystem designs to meet requirements for fault isolation. Here, failure mode isolation is the 

determination of the possible physical locations of a failure cause. 

This analysis is performed by grouping failure modes that have identical detection signatures. Groups that contain a 

single failure mode are considered to be isolated—meaning, that the system is able to uniquely identify that single 

failure mode based on the tests that it fails. Failure mode groups containing more than one failure mode are 

ambiguous. In other words, the system is unable to distinguish which failure mode or modes within the group may 

be occurring based on their detection signature. 

The Failure Mode Isolation report generated by this command line option contains four sections that are separated 

by blue horizontal lines. The top section contains testability conditions for the analysis conducted by TEAMS. The 

TEAMS analysis date and time, as well as the diagnostic model are reported. This section also includes the TEAMS 

analysis options selected such as the technology labels, test labels and system modes. 

The second section contains metrics generated during the ETA Tool process relevant to the system’s failure mode 

isolation analysis. This section reports the following metrics: 

 Number of Failure Mode Groups—the number of failure mode groups generated in this analysis for the 

number of active failure modes in the model 

 Number of Failure Modes—the number of failure modes that are active for the specified testability analysis 

conditions 

 Number of Isolated Groups—Failure mode groups containing a single failure mode 

 Maximum Failure Mode Group Size—The number of failure modes in the largest group 

 Calculated Ambiguity Score—a simple metric that allows comparison between system design changes with 

respect to the impact on failure mode isolation. The calculated ambiguity score represents the maximum 

number of tests required to fully isolate all the failure modes. This metric is the sum of each group’s failure 

mode population minus one, or in equation form.

ሻ 1 െ௜ ܲሺ෍  ൌ ݁ݎ݋ܿݏ ݕݐ݅ݑܾܽ݉݅݃

௡

௜ୀ଴

where Pi is the population of the i

th failure mode group and n is the number of failure mode groups. 

This second section also displays the population distribution of the failure mode groups, both in a text format and 

graphically. 

The third section displays a simple reminder notice to the user that the results presented in the final sections are the 

failure mode groups displayed in ascending population. 
NASA/CR—2011-217240 14 

The final section of this report displays each failure mode group separated by a green horizontal line. The groups are 

presented in ascending population size. For each group, two tables are provided. The first table displays the 

detection signature information for the group, including the sensor identifier, sensor schematic identifier, sensor 

description and test name. The second table contains all the failure mode information for each failure mode 

contained in this group. If the higher level ‘Element’ and ‘System’ components are defined in this diagnostic model, 

then they are presented here in the table’s initial columns, otherwise those columns are removed. This table also 

reported the failure mode’s component, failure mode name, FMEA identifier and the criticality of the failure for the 

phase of operation under analysis, if available. 

Figures 4 and 5 illustrate the ETA Tool Failure Mode Isolation report, upper portion and lower portion respectively, 

for the example diagnostic model. 
NASA/CR—2011-217240 15 

Figure 4.—ETA tool failure mode isolation report, upper portion, for the example diagnostic model. 
NASA/CR—2011-217240 16 

Figure 5.—ETA tool failure mode isolation report, lower portion, for the example diagnostic model. 
NASA/CR—2011-217240 17 

5.2.4 Generation of the ETA Tool Component Isolation Report 

Syntax for generating a Component Isolation Report: 

>> ETAT_v6_7.exe -iso <Component Label>

where <Component Label> is selected from the set of TEAMS module labels assigned for the current diagnostic 

model.

Special Input Requirements: 

The component label input on the command line must be a hierarchical label assigned within the diagnostic model. 

If a component label is entered on the command line that is not in the diagnostic model, the ETA Tool will notify the 

user and discontinue processing. Also a basic assumption for component isolation analysis is that the designated 

components cannot be nested, meaning that a designated component cannot contain another designated component. 

If a nested designated component is uncovered by the ETA Tool during processing, the tool will report the discovery 

and discontinue processing. 

Within the example diagnostic model, the following component labels are used; System, Assembly, LRU, 

Component, Sensor and Failure_mode. The Component Isolation analysis works for each label, except for two. The 

‘Failure_mode’ label, which is essentially the Failure Mode Isolation analysis. And the ‘System’ label because the 

highest level module in TEAMS Designer is by default assigned the ‘System’ hierarchical label and therefore 

creates a nested designated component situation. 

Output Report Description: 

The Component Isolation report generated for the example system provided in the software package is named: 

.\ ETAT_HOME \ Basic_System_<Component Label>_Isolation_Report.htm

where <Component Label> is provided by the user on the command line. The report can be either opened directly 

into an Internet browser or accessed by the “Component Isolation Report” link on the main output file, 

Basic_System_TestAnalysis_Main.htm.

The Component Isolation report provides information regarding the system’s ability to isolate failures to a specific 

component within the system. From a maintenance perspective it may not be imperative to identify the exact failure 

mode, but rather to identify the component where the failure occurred. For the Ares I project, launch pad logistics 

and maintainability personnel required that components identified as line replaceable units—meaning they were 

intended to be replaced on the launch pad—contained only failure modes that could be isolated to that component. 

For the Component Isolation report, the user provides the label of the components within the diagnostic model to 

which failure modes are to be isolated. As with the failure mode isolation analysis, failure modes are grouped by 

detection signatures. Here, the failure mode groups are further divided into physical components where the failure 

originates. The depth to which failure mode components are derived is determined by the user-selected isolation 

level. The output report is similar in format to that generated by the Failure Mode Isolation Report, except the 

diagnostic metrics are relative to the components identified for isolation. 

The Component Isolation report (Figs. 6 and 7) generated by this command line option contains four sections that 

are separated by blue horizontal lines. The top section contains testability conditions for the analysis conducted by 

TEAMS. The TEAMS analysis date and time, as well as the diagnostic model are reported. This section also 

includes the TEAMS analysis options selected such as the technology labels, test labels and system modes. 

The second section contains metrics generated during the ETA Tool process relevant to the system’s component 

isolation analysis. Note that, for this analysis, failure mode groups that contain no failure modes from model 

components labeled with the same label specified on the command line option are not included in the final analysis. 

This section reports the following metrics: 

 Number of Failure Mode Groups—the number of groups generated in this analysis for the number of active 

components in the model 

 Number of Active Components—the number of components that have failure modes that are part of the 

testability analysis 
NASA/CR—2011-217240 18 

 Number of Active Non-Components—the number of non-components that have failure modes that are part 

of the testability analysis 

 Number of Isolated Groups—failure mode groups containing a single component or non-component 

 Maximum Failure Mode Group Size—the number of components and non-components in the largest group 

 Calculated Ambiguity Score—a simple metric that attempts to provide a tool for comparison with system 

design change impacts on component isolation. This metric is simply the sum of each group’s component 

and non-component population minus one, or in equation form.

ሻ 1 െ௜ ܲሺ෍  ൌ ݁ݎ݋ܿݏ ݕݐ݅ݑܾܽ݉݅݃

௡

௜ୀ଴

where Pi is the population of the i

th failure mode group and n is the number of failure mode groups. 

This second section also displays the population distribution of the failure mode groups, both in a text format and 

graphically. 

The third section is the component isolation summary for this analysis. This includes a listing of the number of 

isolated components and a hypertext link to a detailed isolation assessment report for all the components analyzed. 

This detailed report will be discussed later in this section. 

The final section of this report displays each failure mode group separated by a green horizontal line. The groups are 

presented by ascending population size. For each failure mode group, multiple tables are provided. The first table 

displays the detection signature information for the group, including the sensor identifier, sensor schematic 

identifier, sensor description and test name. For each component or non-component member of the group, a table is 

presented containing the failure mode’s component, failure mode name, FMEA identifier and the criticality of the 

failure for the phase of operation under analysis, if available, for each failure mode associated with that component. 

Figures 6 and 7 illustrate the ETA Tool Component LRU Isolation report, upper portion and lower portion 

respectively, for the example diagnostic model. To generate this report, the user should specify “LRU” as the 

component label. 
NASA/CR—2011-217240 19 

Figure 6.—ETA tool component isolation report, upper portion, for the example diagnostic model where the selected 

designated component label was ‘LRU’. 
NASA/CR—2011-217240 20 

Figure 7.—ETA Tool Component Isolation report, lower portion, for the example diagnostic model where the selected 

designated component label was ‘LRU’. 

 
NASA/CR—2011-217240 21 

The detailed component isolation assessment table is presented in a separate report that is hypertext linked to the 

Component Isolation report. Figure 8 illustrates this table report. The report reiterates the testability analysis 

conditions and pertinent ambiguity analysis metrics; 

 Number of Active Components—the number of components that have failure modes that are part of the 

testability analysis 

 Number of Active Non-Components—the number of non-components that have failure modes that are part 

of the testability analysis 

 Number of Failure Mode Groups—the number of groups generated in this analysis for the number of active 

components in the model 

 Number of Isolated Groups—failure mode groups containing a single component or non-component 

 Number of Isolated Components—components that belong solely to isolated groups 

The table then presents for each component analyzed, the component’s name, the number of active failure modes 

contained in the component, the number of groups containing those failure modes; then for each failure mode: the 

group identifier containing that failure mode, failure mode name and the Detection/Isolation status assigned to the 

failure mode. The Detection/Isolation status is either ‘Not Detected’, ‘Not Isolated’ or ‘Isolated’. If the failure mode 

is not detected, then it is highlighted in red in the table. If the failure mode is isolated, then it is highlighted in green. 

The intention of the table is to provide a visual summary of the isolation assessment with respect to the components. 
NASA/CR—2011-217240 22 

Figure 8.—ETA Tool Component Isolation Assessment Table report for the example diagnostic model where the 

selected designated component label was ‘LRU’. 
NASA/CR—2011-217240 23 

5.2.5 Generation of the ETA Tool Effect Mapping Report 

Syntax for generating an Effect Mapping Report: 

>> ETAT_v6_7.exe -E 

Special Input Requirements: 

Within the model, certain tests must be established with a naming convention that identifies it as an effect test rather 

than a sensor detection test. For example an effect test could be a “loss of functional redundancy”, where a sensor 

test would be “loss of fluid pressure”; even though they may both detect the same functional effect. The distinction 

is subtle, but this analysis allows the establishment of system level effects that can be analyzed simultaneously with 

the sensor testability analysis. 

The naming convention for an effect test in the TEAMS diagnostic model is, 

<Effect Description>_Effect, 

for example, “Loss-of-Redundancy_Effect”. 

Output Report Description: 

The Effect Mapping report generated for the example system provided in the software package is named: 

.\ ETAT_HOME \ Basic_System_Effect_Report.htm

The report can be either opened directly into an Internet browser or accessed by the “Effect Mapping Report” link 

on the main output file, Basic_System_TestAnalysis_Main.htm.

For the Effect Mapping analysis the software utilizes the established naming conventions to distinguish between 

modeled tests attributed directly to physical sensors and tests that were intended to represent system-level 

conditions. An example of the latter test implementation would be a system condition representing the loss of 

redundancy due to loss of component function. Whether or not there was a physical sensor that could measure the 

effect, a pseudo sensor test point could be modeled that contained this system-level effect test. By taking advantage 

of this capability, the ETA Tool can combine a testability analysis that is conducted with physical sensor 

measurements and an effects analysis that within TEAMS Designer could only be applied to effect nodes. The 

combined analysis provided the mapping of failure modes to system level effects, while at the same time providing 

detection signatures aligned to those system level effects. This level of analysis was utilized by Ares I vehicle 

integration systems engineers responsible with the vehicle level loss of mission analysis and probability risk 

assessment. 

The analysis performed by this option creates an Effect Mapping Report that provides the summary analysis 

information along with hyper text links to three analysis reports: a detectability report and two ambiguity reports for 

the active failure modes relative to the system effects. Figure 9 illustrates the summary information report for the 

effects analysis. The top section contains testability conditions for the analysis conducted by TEAMS. The TEAMS 

analysis date and time, as well as the diagnostic model are reported. This section also includes the TEAMS analysis 

options selected such as the technology labels, test labels and system modes. 
NASA/CR—2011-217240 24 

Figure 9.—ETA tool effect mapping main report for the example diagnostic model. 

 
NASA/CR—2011-217240 25 

The second section contains the following summary information specific to the effect mapping analysis; 

 Number of Effects—this is the number of effects available from the current testability analysis 

 Effects Not Mapped—this is a list of effects that did not have a failure modes mapped to them 

 Failure Modes Not Mapped—this is a list of failure modes that did not map to an effect. If this list is 

greater than ten, then a hyperlinked document will display the list. 

This section also contains the three hyperlinked reports: the Effect Mapping Report, the System Effect Ambiguity 

Report (Basic Format) and the System Effect Ambiguity Report (Detailed Format). 

The Effect Mapping Report is displayed in Figure 10 and contains two sections divided by a blue horizontal line. 

The top section repeats the testability conditions information for the analysis conducted by TEAMS. The second 

section reports the failure modes that result in the individual system effects, grouped by the system effects. Each 

system effect is presented separated by a green horizontal line. For each system effect, the report presents a table of 

the failure modes that contains the following information from the diagnostic model; the failure mode name, failure 

mode identifier and the component where the failure originated. 
NASA/CR—2011-217240 26 

Figure 10.—ETA tool effect mapping report for the example diagnostic model. 
NASA/CR—2011-217240 27 

The last two hyperlinked reports linked on the Effects Mapping main page, provide details about the ambiguity 

analysis performed from these testability results. The first report, System Effect Ambiguity Report (Basic Format), 

provides the ambiguity analysis with respect to the system effects in a basic format, shown in Figure 11. The report 

contains two sections separated by a blue horizontal line. The top section reiterates the testability analysis 

conditions. The bottom section is further subdivided by green horizontal lines for each failure mode grouping in the 

analysis. For each group, two tables are reported. The first table lists the system effects that define the detection 

signature for the group and the second table reports for each failure mode contained in this group; the element, 

system and component of the failure mode, if they are assigned within the diagnostic model, the failure mode name, 

failure mode identifier and the assigned criticality. 
NASA/CR—2011-217240 28 

Figure 11.—ETA tool effect ambiguity report in the basic format for the example diagnostic model. 

 
NASA/CR—2011-217240 29 

The second system effect ambiguity report presents additional information about the failure modes contained within 

the groups. This report is only useful if the available sensor tests are also included in the testability analysis 

performed in TEAM Designer. Figure 12 shows the breakdown of the report. In this report, for each failure mode 

group a single table is generated with the following columns; 

 Element—the element module as defined in the diagnostic model from which the failure mode originates. 

If there are no element modules defined, then this column is removed. 

 System—the system module as defined in the diagnostic model from which the failure mode originates. If 

no system modules are defined, then this column is removed. 

 Component—the module from which the failure mode originates. 

 Failure Mode 

 FMEA Identifier 

 Criticality—the criticality assigned to the failure mode in the diagnostic model for the current testability 

conditions 

 Outcomes—The system effects which define this failure mode group 

 Test Sensors—The sensor tests which detect this failure mode. The sensor information includes the sensor 

identifier and sensor name 

 Initial Failure Effects—The column reports the physical failure effects propagated by this failure mode. 
NASA/CR—2011-217240 30 

Figure 12.—ETA tool effect ambiguity report in the detailed format for the example diagnostic model. 
NASA/CR—2011-217240 31 

5.2.6 Generation of the ETA Tool Sensor Sensitivity Report 

Syntax for Generating a Sensor Sensitivity Report: 

>> ETAT_v6_7.exe -s1 <sensor sensitivity file> 

Special Input Requirements: 

Sensor Sensitivity input file. The format of this file is presented in section Installation and Setup. 

Output Report Description: 

Three reports are generated for the example system provided in the software package: 

.\ ETAT_HOME \ Basic_System_Sensor_Sensitivity_Report-Sensor_Level.htm 

.\ ETAT_HOME \ Basic_System_Sensor_Sensitivity_Report-Measurement_Level.htm 

.\ ETAT_HOME \ Basic_System_Sensor_Sensitivity_Report-Measurement_Group_Level.htm 

These reports can be either opened directly into an Internet browser or accessed by the “Sensor Sensitivity Analysis 

by Individual Sensors”, “Sensor Sensitivity Analysis by Measurements” and “Sensor Sensitivity Analysis by 

Measurement Groups” links, respectively, on the main output file, Basic_System_TestAnalysis_Main.htm.

The sensor sensitivity analysis was created to assess the impact of the removal of individual sensors or groups of 

sensors on the system’s diagnostic capabilities. The analysis can facilitate various design studies to determine the 

importance of measurements and tests, as well as diagnostic strategies to overcome sensor signal loss. 

The analysis currently performs three distinct cycles where individual and groups of sensors can be systematically 

removed. The definition of the sensors and groups of sensors to be removed for each cycle is defined in an external 

input file supplied by the user on the command line. 

Prior to the sensor sensitivity analysis, the failure modes are reviewed to determine if they are failure modes of the 

sensors or of the general system. Sensor failure modes are removed from consideration during the analysis and the 

remaining failure modes are used to establish a set of baseline diagnostic metrics for the system. Changes to the 

diagnostic capability of the system are made relative to these baseline metrics. This ensures that sensor-related 

failure modes do not bias the diagnostic evaluation. For example, given a sensor ‘X’ has two inherent failure modes, 

the simple removal of the sensor will eliminate two failure modes from the system being evaluated, unfairly biasing 

the analysis in a positive direction if the failure modes have not been filtered out. 

One caveat to this aspect of the analysis is that sensor failures that are essentially system failure modes do remain in 

the baseline and therefore are removed when the sensor is removed. For example, a sensor can have two failure 

modes: one failure mode is a sensor signal fault and the other failure mode is a fluid leak at the insertion point of the 

duct. The former failure mode is removed from the baseline metrics, but the latter remains because the fluid leakage 

is a system failure mode caused by the physical presence of the sensor. 

The sensor sensitivity analysis option produces three reports. Each report has a similar format. The first report 

displays the impact on the system’s diagnostic capabilities (failure mode detection and isolation) with the loss of 

each sensor individually. The second report, again displays the impact of the system’s diagnostic capability, but this 

time with sensors being removed by hardware redundancy groups. The third report looks at the impact on system 

diagnostic capability with the removal of the sensor across the entire system. 

Figures 13, 14, and 15 display each of the reports, respectively. Each report has four sections divided by a blue 

horizontal line. The top section in each reiterates the testability analysis conditions. The second section reports the 

following sensitivity analysis metrics; 

 Number of Tests—the number of available tests that are part of the testability analysis 

 Number of Active Sensors—Number of sensors with at least on active test 

 Active Sensors that provide zero contribution—Active sensors that provide no detection for the failure 

modes in this analysis 

 Number of Failure Modes—the number of failure modes that are part of the testability analysis 
NASA/CR—2011-217240 32 

 Number of failure modes involving only sensor signal faults—failure modes that are only related to the 

sensor signal failure. 

 Overall Detection Coverage—a calculated metric that is equal to the number of detected failure modes 

divided by the total number of failure modes 

 Overall Detection Coverage w/o Sensor Faults—the Overall Detection Coverage metric with sensor signal 

failure modes removed from both the number of detected failure modes in the numerator and the total 

number of failure modes in the denominator.

In this analysis, these metrics provide a baseline from which the impact values can be compared. 

The third section in each of the three reports provides a reminder statement about the current analysis process. 

Note: For this report, tests that solely detect their own sensor fault, and failure modes that result in sensor fault are 

not used in the analysis. The fault detection coverage and the failure mode groupings are recomputed with the 

removal of all sensor-fault-only tests and failure modes.

Re-stating this notice, the sensor sensitivity analysis excludes failure modes that are the sensor signal faults and the 

tests that detect those sensor signal faults exclusively. The reason is that these will unduly bias the results. If a 

sensor is to be considered for inclusion in the diagnostic system it must detect more than just its own failure modes. 

The final section in each report provides a table of the diagnostic impacts due to the removal of the sensor or 

sensors. The following columns are reported in the table for the Sensor Level report; 

 Sensor Removed—the sensor identifier 

 Sensor Description 

 Removed Sensor-Related failure Modes—These are the failure modes that are removed from the analysis 

process because they are caused by faults in the sensor under consideration 

 Detection Coverage Loss | Coverage Percentage—the change in the system’s overall detection coverage if 

the sensor-related failure modes were not present in the baseline value 

 Detection Coverage Loss | Failure Modes Undetected—failure modes that are now undetected as a result of 

the removal of the sensor 

 Fault Isolation Loss | Change in Number of Failure Mode Groups—the total number failure mode groups 

lost or gained as a result of the removal of the sensor. The baseline groups are generated with the removal 

of the faults from the sensor under study. 

 Fault Isolation Loss | Change in Number of Isolated Failure Modes—the number of isolated failure modes 

lost or gained as a result of the removal of the sensor. The baseline groups are generated with the removal 

of the faults from the sensor under study. 

 Fault Isolation Loss | Ambiguity Score Change—the change in the ambiguity score compared to baseline 

score. The baseline ambiguity score is generated with the removal of the faults from the sensor under study.

The final section tables in the reports for the Measurement Level and the Measurement Group Level are similar to 

the one described for the Sensor Level report except the initial column shows the Measurement or Group removed, 

respectively, and the following column consolidates the sensor identifier and description information for the sensors 

removed. 
NASA/CR—2011-217240 33 

Figure 13.—ETA tool sensor sensitivity analysis report for individual sensors for the example 

diagnostic model. 
NASA/CR—2011-217240 34 

Figure 14.—ETA tool sensor sensitivity analysis report for hardware redundant sensors for the example diagnostic 

model. 
NASA/CR—2011-217240 35 

Figure 15.—ETA tool sensor sensitivity analysis report for common sensors across the system for the example 

diagnostic model. 
NASA/CR—2011-217240 36 

5.3 Related Processing 

During the ETA Tool processing, the software will attempt to copy specific required files from the TEAMS model 

directory to the directory containing the ETA Tool executable. In addition, the ETA Tool will convert the TEAMS 

Designer Testability output D-Matrix from the Microsoft Excel format to a comma-separated-variable formatted 

file. It is recommended that the user close all Excel files prior to operating the ETA Tool program. 

5.4 Messages 

The following error messages and exit codes are generated by the ETA Tool; 

Error code Message 

-98 Unable to open the standard log file 

-99 Unable to open the debug log file 

-101 No arguments entered on the command line 

-102 Only Command line argument entered was a debugging option 

-103 No valid command line inputs found 

-104 The auto-setup could not be performed because the environmental variable is not established for TEAMS 

model location. 

-201 Unable to locate the TEAMS model file. 

-202 More than one TEAMS model file available in the TEAMS directory. Unable to determine which model to 

select. 

-203 No TEAMS model in the TEAMS directory 

-204 Unable to locate the TEAMS testability options file which should be in the REPORTS directory. 

-205 Unable to locate the TEAMS model hierarchical file which should be in the REPORTS directory. 

-206 Unable to obtain a listing of the REPORTS directory. 

-207 Unable to find a Testability output directory in the REPORTS directory. 

-208 Unable to locate the testability D-Matrix which should be in the REPORTS directory. 

-209 Unable to convert the EXCEL formatted D-Matrix into a CSV format file. 

-210 Unable to open <filename>, the D-Matrix file. 

-211 Unable to locate the TEAMS testability ambiguity-dynamic file which should be in the REPORTS

directory. 

-212 Unable to locate the TEAMS testability failure-detection-isolation file which should be in the REPORTS

directory. 

-213 Unable to locate the TEAMS testability figures-of-merit file which should be in the REPORTS directory. 
NASA/CR—2011-217240 37 

Error code Message 

-214 Unable to open the TEAMS Designer Analysis Options file (<filename>). 

-215 Unable to open the TEAMS hierarchical file (<filename>). 

-216 Unable to open the TEAMS testability figures-of-merit file (<filename>). 

-301 No components were located in the model labeled with the name specified for the component isolation 

analysis. 

-302 Problem in the process of assigning the submodules to this module (<module name>). The number of 

submodules assigned in the first pass was <count 1> and the second pass was <count 2>. 

-303 Unable to open the Instrumentation Listing file (<filename>). 

-304 Unable to open the Sensitivity Instrumentation Listing file (<filename>). 

-305 Unable to locate the MTTF string in the header of the D-Matrix file. Therefore the format is not what is 

expected. 

-306 Unable to locate the MTTF string in the header of the D-Matrix file after rewinding the file. 

-307 TEST <test name> was not properly assigned to either a sensor test or an effect test. 

-308 No effects were detected in the model, so the failure mode mapping to effects report cannot be generated. 

-309 There are <count> failure modes found within nested components selected for isolation. Need to fix the 

nested components reported. 

-310 Unable to assign the following active failure mode - <failure mode> to either the component to be isolated 

(<isolated component label>) or to one of the currently recognized component label designations of 

“Sensor”, “RBD”, “Subsystem”, “Component”, “System”, “Element”, “Assembly”, “Subassembly”, 

“Module” or “Submodule”. 

-311 There are <count> active failure modes that are improperly labeled within the diagnostic model. 

-312 Could not reallocate the size of the failure mode module array within the failure mode structure. 

-401 The total number of failure modes for this <isolated component label>, (<module name>) does not match 

the number reported out to the Ambiguity table. Need to investigate the cause. 
NASA/CR—2011-217240 38 

5.5 Quick-Reference Guide 

ETA Tool Command Line Syntax 

ETAT_v6_7 {-i instrumentation_file.csv} {-d} {-s1 file.cvs} {-D} {-T} {-E} {-I} {-iso label} 

where 

 {-i instrumentation_file.cvs} Specifies the CSV-formatted instrumentation file to use in the 

ETA Tool analysis. If this option is not specified, the ETA Tool 

will attempt to access a default instrumentation file by the 

naming convention “<Model Name>_sensor_file.csv” 

 {-d} Indicates a debugging option which turns on certain screen 

printing output for ETA Tool developers. 

 {-s1 file.cvs} Indicates that the sensors sensitivity analysis is to be performed 

and the CSV-formatted file to use containing additional sensor 

information. 

 {-D} Generates the Detectability Report 

 {-T} Generates the Test Utilization Report 

 {-E} Generates the Effect Mapping Report 

 {-I} Generates the Failure Mode Isolation Report 

 {-iso label} Generates the Component Isolation report and indicates the 

hierarchical label to be used in the component-isolation analysis 

6.0 Notes 

6.1 Acronyms 

CPU Central Processing Unit 

CSV Comma Separated Variable 

DOS Disk Operating System 

ETA Extended Testability Analysis 

FFA Functional Fault Analysis 

FMEA Failure Mode and Effects Analysis 

GCC GNU C Compiler 

GLPR Glenn Procedural Requirement 

GRC Glenn Research Center 

HTML HyperText Manuscript Language 

ID Identifier 

LRU Line Replacement Unit 

PSV Pressure Selector Valve 

RAM Random Access Memory 

RBD Reliability Block Diagram 

TEAMS Testability Engineering and Maintenance System 
NASA/CR—2011-217240 39 

6.2 Terms and Definitions 

TABLE 4.—CORE FAULT MANAGEMENT TERMS1

Term Definition 

Anomaly The unexpected performance of intended function. 

Failure The unacceptable performance of intended function 

Fault A physical or logical cause, which explains a failure

Root Cause In the chain of events leading to a failure, the first fault or environmental cause used to explain 

the existence of the failure. 

TABLE 5.—OTHER FAULT MANAGEMENT TERMS 

Term Definition 

Component Isolation Determining the possible locations of a hypothesized failure or anomaly cause to the 

component level. For this analysis, it is not important to discriminate between failure 

modes within the component. Components may have failure modes in multiple failure 

mode groups. 

Failure Detection Deciding that a failure exists1

Failure Mode Group set of failure modes that are detected by the same unique detection signature 

Detection Signature A set of tests that detect a given failure mode

Failure Mode Modes of a component’s behavior that can cause failure effects1

Failure Effect A potentially measureable change in system behavior or state property; the 

consequence(s) a failure mode has on the operation, function, or status of an item 

Isolated Failure Mode 

Group 

A failure mode group that has only one member 

Fault or Failure Mode 

Isolation 

Determining the possible locations of a hypothesized failure or anomaly cause to a 

defined level of granularity1

Reliability Block Diagram Defines the series dependence or independence of all functions of a system or 

functional group for each life-cycle event 

 

1

 Johnson, S.B.; and Day, J.C.: NASA Constellation Program Fault Management Terminology Report, September 10, 2010. 

NASA/CR—2011-217240 41 

Appendix A.—Diagnostic Modeling Conventions 

This section describes the diagnostic model naming conventions established by the NASA Constellation Ares I 

Functional Fault Analysis (FFA) modeling group to ensure consistency across the independently developed 

TEAMS-based subsystem models. These conventions were designed to incorporate a significant amount of system 

information intended to improve the user’s understanding of the output from the various testability analysis reports. 

For this paper, only those model elements pertinent to the ETA Tool are presented; other model elements were 

defined by the NASA developers, but are not relevant here. 

Note: A cursory knowledge of modeling in TEAMS will improve the reader’s comprehension of the following 

discussion. 

The following are a list of general syntax used throughout the naming conventions, 

 Dashes are used to separate words within a text field. 

 Underscores are used to separate text fields within a label. 

 ‘[ ]’ within a naming definition indicates an optional field. 

A-1 Conventions for Tests 

Tests are assigned within test points. In general, a test can be attached to multiple test points; however, current 

modeling practice has been to create unique tests that reflect a specific test point. The test name can contain three 

distinct fields, separated by the ‘_’ character. The first field is a unique test name which can be a simple test 

description, such as “High-Fluid-Pressure”. The second field, which is optional, is the schematic identifier for the 

sensor. The third field, which is also optional, is the unique measurement identifier usually taken from the integrated 

system measurement list. 

<Test Name/Description>[_Sensor Schematic Identifier][_<Measurement Identifier>] 

For example, “Low-Turbine-Rotation_SS-1_CLVUS13534”) 

For the third field, the ETA Tool will attempt to match the “Measurement Identifier” text with either the first or 

second measurement identifier columns from the sensor information file loaded in the command line. If this field 

contains the text string, ‘Effect’, the ETA Tool interprets this as an effect test and treats it distinctly from the other 

tests. General system or subsystem conditions not aligned to a specific sensor can be represented in the diagnostic 

model with these tests identified by this ‘Effect’ text string. If any of the optional fields are unavailable, the ETA 

Tool enters a ‘None’ text value into the internal placeholder for that piece of information. The ETA Tool assumes 

that if there are only two fields available, then it is the “Sensor Schematic Identifier” field that is omitted. 

A-2 Conventions for Failure Mode Modules 

Failure mode modules are a special case module in the TEAMS diagnostic model. These modules represent the 

failures and contain the failure effects, the failure criticalities (assigned by phase), and the failure probability values. 

The failure mode module name can contain two distinct fields, separated by the ‘_’ character. The first field is the 

failure mode description. The second field contains the Failure Mode and Effects Analysis (FMEA) identifier, if 

available. 

<Failure description>[_<FMEA Identifier>] 

For example, Rupture_J-2X-FIDA-001 

If the optional FMEA Identifier field is unavailable, the ETA Tool enters a ‘None’ text value into the internal 

placeholder for that piece of information. 
NASA/CR—2011-217240 42 

A-3 Conventions for Component Modules 

Within the diagnostic model, all modules that contain other modules are called component modules. These modules 

represent the breakdown structure of the system. The component module name can contain three distinct fields, 

separated by the ‘_’ character. The first field is the component description. The second field is optional and is the 

schematic identifier for the module, if available. The third field, which is also optional, is the Reliability Block 

Diagram (RBD) identifier usually developed for the FMEA process for the system. The RBD is a decomposition of 

the system to a level determined by the Safety and Mission Assurance analysts. Usually the RBD identifier is the 

prefix portion of the FMEA identifier. 

<Module Description>[_<Schematic Identifier>][_<RBD Identifier>] 

For example, LH2-Fill-and-Drain-Valve_HD-100_CLV-US-MPS-BB-01 

If any of the optional fields are unavailable, the ETA Tool enters a ‘None’ text value into the internal placeholder for 

that piece of information. The ETA Tool assumes that if there are only two fields available, then it is the schematic 

ID field that is omitted. 

A-4 Conventions for Technology Labels 

A set of technology labels are available for each failure mode in the diagnostic model. The ETA Tool will extract 

the technology labels from the failure mode module files (if accessible) and attempt to match the testability analysis 

switch mode settings. The format for the technology labels start with the failure mode criticality designation and end 

with the phase of operation. The phase of operation corresponds to the switch mode setting for the model. Since the 

system mode is defined by a set of switch modes, the ETA Tool program will also search the technology labels for 

any that match the system mode, if none of the switch modes were matched. 

[<Criticality>_]<Switch-Mode> 

For example, Crit-1_Phase-A 

A-5 Conventions for Switch Modes 

Switch modes are used to establish the operational configuration of a system. The TEAMS Designer uses the 

“Switch” model element to direct the propagation paths during the Testability analysis process. Switch mode names 

can include an optional subsystem prefix (e.g., MPS_LOX-Tank-Repress) 

A-6 Hierarchical Labels 

Hierarchical labels are assigned to the modules of the model and are the user-defined breakdown of the modeled 

system. These labels convey the level of decomposition of the system. The model developer should assign the 

modules with care and consistency. Two special labels are utilized within the ETA Tool, 

 ‘Failure_mode’ or ‘Failure_Mode’—defines the failures modeled in the system. These should be at the very 

lowest level of the hierarchical model, meaning there are no other modules under these modeled elements. 

 ‘Sensor’—a special module label that is used only in the sensor sensitivity analysis currently and only to 

provide a distinction between failure modes detected by the sensor that are external and those detected that 

are internal to the sensor itself. For example, one of the sensor internal failure modes may result in a faulty 

signal that is detectable by a sensor test, but in the sensitivity analysis, the ETA Tool would remove that 

failure mode from the sensor’s list of failure modes that it can detect because the sensor actually was the 

cause of the failure. 

 
NASA/CR—2011-217240 43 

The following hierarchical labels are currently explicitly sought out by the ETA Tool; have the following suggested 

order of system decomposition 

1. ‘Element’—assigned at the highest level modules 

2. ‘System’—assigned to the second highest level modules 

3. ‘Subsystem’ 

4. ‘Assembly’ 

5. ‘Subassembly’ 

6. ‘Module’ 

7. ‘Submodule’ 

8. ‘Component’ 

9. ‘RBD’ 

Note: This is only a suggested order. The user may choose to adopt a different order structure and/or may develop a 

model that has different labels altogether. 

NASA/CR—2011-217240 45 

Appendix B.—Diagnostic Model Example 

This section presents an example system with which the ETA Tool can be applied and demonstrated. The purpose of 

the example system is to provide a reportable output that exposes the processing capabilities of the ETA Tool. 

A schematic of the example system is shown in Figure B-1. This system is a generic hydraulic actuator system that 

could drive the orientation of an aircraft or spacecraft. The system has two independently powered hydraulic 

actuators, but the power supplies are cross-strapped to provide redundancy due to loss of function at the power 

source. The hydraulic actuators and the associated power source define a subsystem and are color separated in the 

schematic and named Pitch and Yaw. In the schematic each component and line segment is designated with a name 

which is typical for system development. Also sensors are represented in the systematic as white circles or ovals. 

The hydraulic power source is a turbine pump component driven by an external propellant flow. Each hydraulic 

power source contains a reservoir and a filter. Propellant flow to the hydraulic turbines is controlled by propellant 

supply valves, PPSV and YPSV. Each actuator contains a pressure selector valve, PHPSV and YHPSV, which 

senses loss of primary supply pressure and switches over to the available secondary power source. The actuators 

also contain a power valve which controls the direction of the actuator and is controlled by an external computing 

source. 

Table B-1 provides a list of sensors in the example system. The first column is the assigned schematic identifier (ID) 

for the sensor and corresponds to the designation on the schematic. The second column provides a brief description 

of the sensor. The third column is a simple sensor identifier that could possibly be used at the system controller or 

data management level. Often in system design process the same sensing element may be associated with a number 

of identifiers. The fourth and fifth columns report the tests assigned to the sensor and the periods of operation they 

are available. 

Figure B-1.—Schematic of example system. 
NASA/CR—2011-217240 46 

TABLE B-1.—EXAMPLE SYSTEM SENSOR LIST 

Schematic ID Description Sensor ID Assigned Tests Applied 

SS1 Pitch Turbine Speed 

Sensor SEN0001 

Faulty-Sensor-Data Pre-Flight 

Flight 

No-Rotation Flight 

Unexpected-Rotation Pre-Flight 

SS2 Yaw Turbine Speed 

Sensor SEN0002 

Faulty-Sensor-Data Pre-Flight 

Flight 

No-Rotation Flight 

Unexpected-Rotation Pre-Flight 

PV11 Pitch Propellant Supply 

Valve Position SEN0003 

Faulty-Sensor-Data Pre-Flight 

Flight 

PSV-Open Pre-Flight 

Flight

PSV-Closed Pre-Flight 

Flight 

PV12 Pitch Pressure Selector 

Valve Position SEN0004 

Faulty-Sensor-Data Pre-Flight 

Flight 

Selector-Valve-PrimaryPosition 

Pre-Flight 

Flight 

LCC-2

Selector-Valve-SecondaryPosition 

Pre-Flight 

Flight

Selector-Valve-IntermediatePosition 

Pre-Flight 

Flight 

PV21 Yaw Propellant Supply 

Valve Position SEN0005 

Faulty-Sensor-Data Pre-Flight 

Flight 

PSV-Open Pre-Flight 
NASA/CR—2011-217240 47 

Schematic ID Description Sensor ID Assigned Tests Applied 

Flight

PSV-Closed Pre-Flight 

Flight 

PV22 Yaw Pressure Selector 

Valve Position SEN0006 

Faulty-Sensor-Data Pre-Flight 

Flight 

Selector-Valve-PrimaryPosition 

Pre-Flight 

Flight 

LCC-2 

Selector-Valve-SecondaryPosition 

Pre-Flight 

Flight 

Selector-Valve-IntermediatePosition 

Pre-Flight 

Flight 

dP1 Pitch Delta Pressure 

Filter Sensor SEN0007 

Faulty-Sensor-Data Pre-Flight 

Flight 

High-Delta-Pressure Flight 

dP2 Yaw Delta Pressure 

Filter Sensor SEN0008 

Faulty-Sensor-Data Pre-Flight 

Flight 

High-Delta-Pressure Flight 

P11 Pitch Turbine Propellant 

Inlet Pressure SEN0009 

Faulty-Sensor-Data Pre-Flight 

Flight 

Low-Propellant-Pressure Flight 

Unexpected-PropellantPressure Pre-Flight 

P12 Pitch Hydraulic Supply 

Pressure SEN0010 

Faulty-Sensor-Data Pre-Flight 

Flight 

Low-Hydraulic-Pressure Flight 
NASA/CR—2011-217240 48 

Schematic ID Description Sensor ID Assigned Tests Applied 

Unexpected-HydraulicPressure Pre-Flight 

P21 Yaw Turbine Propellant 

Inlet Pressure SEN0011 

Faulty-Sensor-Data Pre-Flight 

Flight 

Low-Propellant-Pressure Flight 

Unexpected-PropellantPressure Pre-Flight 

P22 Yaw Hydraulic Supply 

Pressure SEN0012 

Faulty-Sensor-Data Pre-Flight 

Flight 

Low-Hydraulic-Pressure Flight 

Unexpected-HydraulicPressure Pre-Flight 

Lv1 Pitch Hydraulic 

Reservoir Level Sensor SEN0013 

Faulty-Sensor-Data Pre-Flight 

Flight 

Low-Hydraulic-Fluid-Level 

Pre-Flight 

Flight 

LCC-1 

Lv2 Yaw Hydraulic 

Reservoir Level Sensor SEN0014 

Faulty-Sensor-Data Pre-Flight 

Flight 

Low-Hydraulic-Fluid-Level 

Pre-Flight 

Flight 

LCC-1 

Cur11 Pitch Propellant Supply 

Valve Current SEN0015 Faulty-Sensor-Data Pre-Flight 

Flight 

No-Electrical-Power Flight 

Cur12 

Pitch Actuator Power 

Valve Solenoid A 

Current 

SEN0016 Faulty-Sensor-Data Pre-Flight 

Flight 

No-Current Flight 
NASA/CR—2011-217240 49 

Schematic ID Description Sensor ID Assigned Tests Applied 

Cur13 

Pitch Actuator Power 

Valve Solenoid B 

Current 

SEN0017 Faulty-Sensor-Data Pre-Flight 

Flight 

No-Current Flight 

Cur21 Yaw Propellant Supply 

Valve Current SEN0018 Faulty-Sensor-Data Pre-Flight 

Flight 

No-Electrical-Power Flight 

Cur22 

Yaw Actuator Power 

Valve Solenoid A 

Current 

SEN0019 Faulty-Sensor-Data Pre-Flight 

Flight 

No-Current Flight 

Cur23 

Yaw Actuator Power 

Valve Solenoid B 

Current 

SEN0020 Faulty-Sensor-Data Pre-Flight 

Flight 

No-Current Flight 

D1 Pitch LVDT 

Displacement Transducer SEN0021 

Faulty-Sensor-Data Pre-Flight 

Flight 

No-Position-Change Flight 

Actuator-Position-Errors Flight 

D2 Yaw LVDT 

Displacement Transducer SEN0022 

Faulty-Sensor-Data Pre-Flight 

Flight 

No-Position-Change Flight 

Actuator-Position-Errors Flight 

P13 Pitch Hydraulic Return 

Pressure SEN0023 Faulty-Sensor-Data Pre-Flight 

Flight 

Low-Pressure Flight 

P23 Yaw Hydraulic Return 

Pressure SEN0024 Faulty-Sensor-Data Pre-Flight 

Flight 

Low-Pressure Flight 
NASA/CR—2011-217240 50 

Table B-2 provides a simple Failure Modes and Effects Analysis (FMEA) for the system. For a typical FMEA the 

system is broken down into a set of components. The level to which a given system is broken down is dependent on 

the system analysts. The failure modes for each component are compiled and the effects and impacts of those 

failures during various phases of operation are determined. Based upon the impact of the failure to the overall 

system, a criticality value is assigned. For our analysis example the following criticality were used, 

‘1’—Loss of system causing a safety hazard that could cause loss of life or vehicle 

‘1R’—Loss of redundancy where a similar second fault would cause a criticality 1 scenario 

‘1S’—Loss of system safety feature which puts the system at risk in the event of a particular criticality 1 

failure. This includes sensor loss where the sensor could be monitoring a failure condition. 

‘2’—Loss of system function that could compromise overall mission success 

‘None’—No impact on system function 

Table B-2 lists the name of the component, all the schematic identifiers of the components in this system and a 

description of the component. For each component, all the failure modes are listed with a description of the failure, 

and the effects assigned and criticality for each phase of operation. For this example, three operational phases were 

established: Phase A (system dormant phase), Phase B (system operating phase) and Phase C (system recovery 

phase which is intended to represent possible failure effects during recovery from loss of a single hydraulic supply 

circuit). 
NASA/CR—2011-217240 51 

TABLE B-2.—EXAMPLE SYSTEM FMEA 

Component Schematic 

ID 

Description FMEA ID Failure Mode Phase A 

(Non-Operating) 

Criticality Phase B 

(Operating) 

C

Hydraulic Turbine PTURB 

YTURB 

Hydraulic turbine transfers propellant flow to rotational energy 

MS-SS-HPump-01-001 

Fail to generate rotational energy 

None None Low-Rotation 1R 

MS-SS-HPump-01-002 

External Leakage of propellant 

None None Propellant-Leak 3 

Hydraulic Pump PPUMP 

YPUMP 

Hydraulic pump converts rotational energy into hydraulic pressure 

MS-SS-HPump-02-001 

Fails to produce hydraulic pressure 

None None Low-Hydraulic-Pressure 1R 

MS-SS-HPump-02-002 

External Leakage of hydraulic fluid 

Hydraulic-Fluid-Loss 1R Hydraulic-Fluid-Loss 1R 

Upstream Propellant Line Segments 

PPLIN1 PPLIN2 YPLIN1 YPLIN2 

Propellant line segments that are upstream of the propellant supply valve 

MS-SS-HPump-03-001 

External Leakage of propellant 

Propellant-Leak 2 Propellant-Leak 

Low-Propellant-Flow Low-PropellantPressure 

1R 

Midstream Propellant Line Segments 

PPLIN3 YPLIN3 

Propellant line segments that are between the propellant supply valve and Turbine 

MS-SS-HPump-04-001 

External Leakage of propellant 

None None Propellant-Leak 

Low-Propellant-Flow Low-PropellantPressure 

1R 

Propellant Check Valve 

PPCKVAL YPCKVAL 

Check valves in the propellant lines that prevent flow back to the main propulsion supply system. 

MS-SS-HPump-06-001 

Fails to open None None Low-Propellant-Flow 1R 

MS-SS-HPump-06-002 

External Leakage of propellant 

Propellant-Leak 2 Propellant-Leak 

Low-Propellant-Flow Low-PropellantPressure 

1R 

MS-SS-HPump-06-003 

Internal Leakage Propellant-Leak 2 None N

Propellant Supply Valve 

PPSV YPSV 

Propellant supply valve. Energized to open. 

MS-SS-HPump-07-001 

Fails to Open None None Low-Propellant-Flow 

Low-PropellantPressure Valve-Closed 

1R 

MS-SS-HPump-07-002 

Fails to Close Unexpected-PropellantFlow 

Valve-Open 

2 None N
NASA/CR—2011-217240 52 

TABLE B-2.—Continued. 

Component Schematic 

ID 

Description FMEA ID Failure Mode Phase A 

(Non-Operating) 

Criticality Phase B 

(Operating) 

Critica

(continued) (continued) (continued) MS-SS-HPump-07-

003 

External Leakage of propellant 

Propellant-Leak 2 Propellant-Leak 

Low-Propellant-Flow Low-PropellantPressure 

1R 

MS-SS-HPump-07-004 

Internal Leakage Unexpected-PropellantFlow 

Propellant-Leak 

2 None None 

Hydraulic Supply Lines 

PHLIN01 PHLIN02 PHLIN03 PHLIN04 PHLIN05 PHLIN06 YHLIN01 YHLIN02 YHLIN03 YHLIN04 YHLIN05 YHLIN06 

Hydraulic fluid lines that supply high pressure hydraulic fluid to actuator 

MS-SS-HYD-01-001 External Leakage of 

hydraulic fluid 

Hydraulic-Fluid-Loss 1R Hydraulic-Fluid-Loss 1R 

Hydraulic Supply Lines - DS of Selector Valve 

PHLIN06 YHLIN06 

Hydraulic fluid lines that supply high pressure hydraulic fluid to actuator 

MS-SS-HYD-10-001 External Leakage of 

hydraulic fluid 

Hydraulic-Fluid-Loss-DS 1 Hydraulic-Fluid-LossDS 1 

Hydraulic Return Lines 

PHLIN08 PHLIN09 PHLIN10 PHLIN11 YHLIN08 YHLIN09 YHLIN10 YHLIN11 

Hydraulic fluid lines that return low pressure hydraulic fluid from actuator 

MS-SS-HYD-02-001 External Leakage of 

hydraulic fluid 

Hydraulic-Fluid-Loss 1R Hydraulic-Fluid-Loss 1R 
NASA/CR—2011-217240 53 

TABLE B-2.—Continued. 

Component Schematic 

ID 

Description FMEA ID Failure Mode Phase A 

(Non-Operating) 

Criticality Phase B 

(Operating) 

C

Hydraulic Return Lines - DS of Selector Valve 

PHLIN07 YHLIN07 

Hydraulic fluid lines that return low pressure hydraulic fluid from actuator 

MS-SS-HYD-11-001 External 

Leakage of hydraulic fluid 

Hydraulic-Fluid-Loss-DS 1 Hydraulic-Fluid-LossDS 1 

Hydraulic Check Valve 

PHCKVAL YHCKVAL 

Allow forward pressurized flow of hydraulic fluid 

MS-SS-HYD-03-001 Fails to open None None Low-HydraulicPressure 1MS-SS-HYD-03-003 External 

Leakage of hydraulic fluid 

Hydraulic-Fluid-Loss 1R Hydraulic-Fluid-Loss 1

Hydraulic Filter PHFILT 

YHFILT 

Filter the hydraulic fluid 

MS-SS-HYD-04-001 Flow Blockage None None No_Hydraulic_Pressur

e High_Delta_Pressure 

1

MS-SS-HYD-04-002 External 

Leakage of hydraulic fluid 

Hydraulic-Fluid-Loss 1R Hydraulic-Fluid-Loss 1

Hydraulic Reservoir 

PHRES YHRES 

Store hydraulic fluid and provide pump inlet pressure 

MS-SS-HYD-05-001 Lose bootstrap 

pressure 

None None No_Pump_Inlet_Press

ure 

1

MS-SS-HYD-05-002 External 

Leakage of hydraulic fluid 

Hydraulic-Fluid-Loss 1R Hydraulic-Fluid-Loss 1

Hydraulic Pressure Selector Valve 

PHPSV YHPSV 

Hydraulic pressure selector which switches from primary to secondary power source with loss of hydraulic pressure 

MS-SS-ACT-01-001 Stuck in an 

intermediate position 

Selector-ValveIntermediate-Position 1 Selector-Valve- Intermediate-Position 1 

MS-SS-ACT-01-002 Stuck in the 

primary position 

None None None N

MS-SS-ACT-01-003 Stuck in the 

secondary position 

None None Selector-ValvePosition-Secondary 1

MS-SS-ACT-01-004 External 

Leakage of hydraulic fluid 

Hydraulic-Fluid-Loss-DS 1 Hydraulic-Fluid-LossDS 1 
NASA/CR—2011-217240 54 

TABLE B-2.—Continued. 

Component Schematic ID Description FMEA ID Failure Mode Phase A 

(Non-Operating) 

Criticality Phase B 

(Operating) 

C

Hydraulic Power Valve 

PHPOWVAL YHPOWVAL 

Controls hydraulic power to drive the actuator 

MS-SS-ACT-02-001 Stuck in an operating 

position (A or B) 

None None Actuator-Full-Extend 1 

MS-SS-ACT-02-002 Stuct in NULL 

position 

None None No-Actuator-Movement 1 

MS-SS-ACT-02-003 External Leakage of 

hydraulic fluid 

Hydraulic-Fluid-Loss-DS 1 Hydraulic-Fluid-LossDS 1 

Actuator PACT 

YACT 

hydraulic actuator MS-SS-ACT-03-001 Actuator locked in 

place 

None None No-Actuator-Movement 1 

MS-SS-ACT-03-002 External Leakage of 

hydraulic fluid 

Hydraulic-Fluid-Loss-DS 1 Hydraulic-Fluid-LossDS 1 

MS-SS-ACT-03-003 Actuator detaches 

from hinge point 

None None Actuator-Uncontrollable 1 

Turbine Speed Sensor 

SS1 SS2 

Measures the rotation speed of the turbine 

MS-SS-HPump-08-001 

Faulty signal Faulty-Signal 1S Faulty-Signal 1

Propellant Supply Valve Position 

PV11 PV21 

Measures the propellant supply valve position 

MS-SS-HPump-09-001 

Faulty signal Faulty-Signal 1S Faulty-Signal 1

Pressure Selector Valve Position 

PV12 PV22 

Measures the pressure selector valve position 

MS-SS-ACT-04-001 Faulty signal Faulty-Signal 1S Faulty-Signal 1

Delta Pressure Filter Sensor 

dP1 dP2 

Measures the pressure difference across the hydraulic filter 

MS-SS-HYD-06-001 Faulty signal Faulty-Signal 1S Faulty-Signal 1

Turbine Propellant Inlet Pressure Sensor 

P11 P21 

Measures the inlet pressure for the turbine 

MS-SS-HPump-10-001 

Faulty signal Faulty-Signal 1S Faulty-Signal 1

Hydraulic Supply Pressure 

P12 P22 

Measures the hydraulic supply pressure 

MS-SS-HYD-07-001 Faulty signal Faulty-Signal 1S Faulty-Signal 1
NASA/CR—2011-217240 55 

TABLE B-2.—Concluded. 

Component Schematic 

ID 

Description FMEA ID Failure Mode Phase A 

(Non-Operating) 

Criticality Phase B 

(Operating) 

C

Hydraulic Reservoir Level Sensor 

Lv1 Lv2 

Measures the hydraulic fluid level in the reservoir 

MS-SS-HYD-08-001 Faulty signal Faulty-Signal 1S Faulty-Signal 1S 

Propellant Supply Valve Current 

Cur11 Cur21 

Measures the current supplied to the propellant supply valve 

MS-SS-HPump-11-001 

Faulty signal Faulty-Signal 1S Faulty-Signal 1S 

Actuator Power Valve Solenoid Current 

Cur12 Cur13 Cur22 Cur23 

Measures the current supplied to the power valves solenoids 

MS-SS-ACT-05-001 Faulty signal Faulty-Signal 1S Faulty-Signal 1S 

LVDT Displacement Transducer 

D1 D2 

Measures the linear displacement of the actuator 

MS-SS-ACT-06-001 Faulty signal Faulty-Signal 1S Faulty-Signal 1S 

Hydraulic Return Pressure 

P13 P23 

Measures the hydraulic return pressure 

MS-SS-HYD-09-001 Faulty signal Faulty-Signal 1S Faulty-Signal 1S 
NASA/CR—2011-217240 56 

With the schematic, sensor listing and FMEA, a diagnostic model was generated in TEAMS Designer. The entire 

model is called Basic_System. At the top-level view of the Basic_System model, shown in Figure B-2, the entire 

system consists of the Vector-Control-System and two external systems, External-Propellant-Supply-System and 

Avionics. These two external systems have failure modes that could introduce effects into the system model being 

analyzed. Also displayed are two system effect testpoints that represent the impact of the vehicle to failure effects. 

Figure B-3 shows the further breakdown of the system model, Vector-Control-System. Similar to the schematic, the 

diagnostic model creates two distinct effect flow paths, one for the Pitch actuator and the other for the Yaw actuator. 

Each flow path is further broken up into components or groups of components, called assemblies. Note that the 

Component modules in this figure are internally labeled with ‘Component’, this being their assigned hierarchical 

label. For the assemblies, four are assigned a hierarchical label of ‘Assembly’, but two have a label of ‘LRU’. This 

is to facilitate demonstration of the ambiguity analysis applied to component replacement requirements. 

Each assembly is further disseminated into components. Figures B-4, B-5, and B-6 display the Propellant Inlet 

Assembly, the Hydraulic Pump Assembly and the Hydraulic Fluid Assembly, respectively. Note that in this model 

individual line segments are modeled distinctly. Also displayed in the assembly figures are the defined testpoints 

that are linked to the sensor components. The color coding of the links between modules and testpoints help in the 

visual review of the model, but do not affect the model operation or the testability analysis. 

Each component can contain various modules including failure mode modules, effect mapping modules and even 

other components. Figure B-7 is the internal view of the Hydraulic Power valve component. The failure modes align 

to failure modes defined in the example FMEA, Table B-2. 

Figure B-2.—Top-level module representation of the example diagnostic model displayed within the 

TEAMS Designer interface. 
NASA/CR—2011-217240 57 

Figure B-3.—Module breakdown of the example model viewed with TEAMS Designer interface. 

 
NASA/CR—2011-217240 58 

Figure B-4.—Example diagnostic propellant inlet assembly module displayed within TEAM Designer interface. 

 
NASA/CR—2011-217240 59 

Figure B-5.—Example diagnostic hydraulic pump assembly module displayed within TEAM Designer interface. 

 
NASA/CR—2011-217240 60 

Figure B-6.—Example diagnostic hydraulic fluid assembly module displayed within TEAM Designer interface. 

 
NASA/CR—2011-217240 61 

Figure B-7.—Internal view of the hydraulic power valve component within TEAM Designer interface. 
REPORT DOCUMENTATION PAGE Form Approved 

OMB No. 0704-0188 

The 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 Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. 

Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB 

control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 

1. REPORT DATE (DD-MM-YYYY)

01-11-2011 

2. REPORT TYPE

Final Contractor Report 

3. DATES COVERED (From - To)

4. TITLE AND SUBTITLE

Software Users Manual (SUM) 

Extended Testability Analysis (ETA) Tool

5a. CONTRACT NUMBER

NNC06BA07B 

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S)

Maul, William, A.; Fulton, Christopher, E. 

5d. PROJECT NUMBER

5e. TASK NUMBER

NNC06E014T 

5f. WORK UNIT NUMBER

WBS 136905.08.05.07.01.03 

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

QinetiQ North America 

8. PERFORMING ORGANIZATION

 REPORT NUMBER

E-17996 

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

National Aeronautics and Space Administration 

Washington, DC 20546-0001 

10. SPONSORING/MONITOR'S

 ACRONYM(S)

NASA 

11. SPONSORING/MONITORING

 REPORT NUMBER

NASA/CR-2011-217240 

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified-Unlimited 

Subject Categories: 38, 66, and 61 

Available electronically at http://www.sti.nasa.gov 

This publication is available from the NASA Center for AeroSpace Information, 443-757-5802

13. SUPPLEMENTARY NOTES

14. ABSTRACT

This software user manual describes the implementation and use the Extended Testability Analysis (ETA) Tool. The ETA Tool is a software 

program that augments the analysis and reporting capabilities of a commercial-off-the-shelf (COTS) testability analysis software package 

called the Testability Engineering And Maintenance System (TEAMS) Designer. An initial diagnostic assessment is performed by the 

TEAMS Designer software using a qualitative, directed-graph model of the system being analyzed. The ETA Tool utilizes system design 

information captured within the diagnostic model and testability analysis output from the TEAMS Designer software to create a series of six 

reports for various system engineering needs. The ETA Tool allows the user to perform additional studies on the testability analysis results 

by determining the detection sensitivity to the loss of certain sensors or tests. The ETA Tool was developed to support design and 

development of the NASA Ares I Crew Launch Vehicle. The diagnostic analysis provided by the ETA Tool was proven to be valuable 

system engineering output that provided consistency in the verification of system engineering requirements. This software user manual 

provides a description of each output report generated by the ETA Tool. The manual also describes the example diagnostic model and 

supporting documentation - also provided with the ETA Tool software release package - that were used to generate the reports presented in 

the manual. 

15. SUBJECT TERMS

System health monitoring; Fault detection; Systems engineering; Systems analysis; Diagnostics; Failure analysis 

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF

 ABSTRACT

UU 

18. NUMBER

 OF 

 PAGES

67 

19a. NAME OF RESPONSIBLE PERSON

STI Help Desk (email:help@sti.nasa.gov) 

a. REPORT

U 

b. ABSTRACT

U 

c. THIS 

PAGE

U 

19b. TELEPHONE NUMBER (include area code)

443-757-5802 

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std. Z39-18