July 2010 

NASA/TM-2010-216716 

NESC-RP-06-074 

 

System Architectural Considerations on 

Reliable Guidance, Navigation, and 

Control (GN&C) for Constellation Program 

(CxP) Spacecraft 

Cornelius J. Dennehy/NESC 

Goddard Space Flight Center, Greenbelt, Maryland 
NASA STI Program . . . in Profile

 Since its founding, NASA has been dedicated to 

the advancement of aeronautics and space science. 

The NASA scientific 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 Officer. 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 

Report 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 significant phase 

of research that present the results of NASA 

programs and include extensive data or 

theoretical analysis. Includes compilations of 

significant scientific and technical data and 

information deemed to be of continuing 

reference value. NASA counterpart of peerreviewed formal professional papers, but having 

less stringent limitations on manuscript length 

and extent of graphic presentations. 

 TECHNICAL MEMORANDUM. Scientific 

and technical findings 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. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees. 

 CONFERENCE PUBLICATION. Collected 

papers from scientific and technical 

conferences, symposia, seminars, or other 

meetings sponsored or co-sponsored by NASA. 

 SPECIAL PUBLICATION. Scientific, 

technical, or historical information from NASA 

programs, projects, and missions, often 

concerned with subjects having substantial 

public interest. 

 TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific and 

technical material pertinent to NASA’s mission. 

 Specialized services also include creating custom 

thesauri, building customized databases, and 

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 

 Phone the NASA STI Help Desk at 

443-757-5802 

 Write to: 

 NASA STI Help Desk 

 NASA Center for AeroSpace Information 

 7115 Standard Drive 

 Hanover, MD 21076-1320
National Aeronautics and 

Space Administration 

Langley Research Center 

Hampton, Virginia 23681-2199 

 

July 2010 

NASA/TM-2010-216716 

NESC-RP-06-074 

 

System Architectural Considerations on 

Reliable Guidance, Navigation, and 

Control (GN&C) for Constellation Program 

(CxP) Spacecraft 

Cornelius J. Dennehy/NESC 

Goddard Space Flight Center, Greenbelt, Maryland 
Available from: 

NASA Center for AeroSpace Information 

7115 Standard Drive 

Hanover, MD 21076-1320 

443-757-5802 

The use of trademarks or names of manufacturers in the report is for accurate reporting and does not 

constitute an official endorsement, either expressed or implied, of such products or manufacturers by the 

National Aeronautics and Space Administration. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

1 of 88

NESC Request No.:06-074-I 

 

System Architectural Considerations on Reliable Guidance, 

Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

October 22, 2009 

 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

2 of 88

NESC Request No.:06-074-I 

Report Approval and Revision History

Approval and Document Revision History 

NOTE: This document was approved at the October 22, 2009, NRB. This document was 

submitted to the NESC Director on December 8, 2009, for configuration control. 

Approved 

Version: 

Original Signature on File 12/9/09 

1.0 NESC Director Date 

Version Description of Revision Office of Primary 

Responsibility Effective Date 

1.0 Initial Release Cornelius Dennehy, 

NASA Technical Fellow 

for Guidance, 

Navigation, and Control 

October 22, 2009
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

3 of 88

NESC Request No.:06-074-I 

Table of Contents 

Volume I: Technical Assessment Report 

1.0    Notification and Authorization ........................................................................................ 5

2.0    Signature Page ................................................................................................................... 6

3.0    Team List ........................................................................................................................... 7

4.0    Executive Summary .......................................................................................................... 8

5.0    Assessment Plan .............................................................................................................. 11

5.1     Background ....................................................................................................................... 11

5.2     Scope ......................................................................................................................... ...... 12

6.0    Problem Description, Proposed Solutions, and Risk Assessment .............................. 12

6.1    Description of the Problem ............................................................................................... 12

7.0     Data Analysis ................................................................................................................... 13

7.1    The 2 x 2 GN&C System .................................................................................................. 13

7.2 Details on the 2 x 2 OPN Model ....................................................................................... 15

7.3    Details on the 3 x 2 OPN Model ....................................................................................... 19

7.4 Results ............................................................................................................................... 26

7.5    Concluding Remarks ...................................................................................................... 39

8.0    Findings and Recommendations .................................................................................... 40

8.1    Findings............................................................................................................................. 40

8.2    Recommendations ............................................................................................................. 41

9.0    Alternate Viewpoints ...................................................................................................... 42

10.0    Other Deliverables .......................................................................................................... 42

11.0    Lessons Learned .............................................................................................................. 42

12.0    Definition of Terms ......................................................................................................... 42

13.0 Acronyms List ................................................................................................................. 43

14.0    References ........................................................................................................................ 44
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

4 of 88

NESC Request No.:06-074-I 

List of Figures

Figure 7.1-1. Three Possible 2 x 2 Systems ............................................................................... 13

Figure 7.2-1. 2 x 2 OPN Decision Tree ...................................................................................... 17

Figure 7.3-1. Determination of Duplicate Architectures ............................................................ 20

Figure 7.3-2. Finding Representative Architectures ................................................................... 21

Figure 7.3-3. Using Representative Architectures to Find Duplicates ....................................... 22

Figure 7.3-4. Example of Manually-Drawn Architectures ......................................................... 23

Figure 7.3-5. Example of Rule Based on a Manually Drawn Architecture ................................ 25

Figure 7.4-1. Architecture Pareto Plots ...................................................................................... 28

Figure 7.4-2. Architecture Pareto Plots ...................................................................................... 29

Figure 7.4-3. Architecture Pareto Plots ...................................................................................... 31

Figure 7.4-4. Architecture Pareto Plots ...................................................................................... 32

Figure 7.4-5. The Architectures Described in Table 7.4-1 ......................................................... 36

Figure 7.4-6. The Architectures Described in Table 7.4-2 ......................................................... 38

List of Tables

Table 7.1-1. Reliability Expressions for the 2 x 2 Systems in Figure 7.1-1 .............................. 14

Table 7.1-2. Indicator for the Channelized and Hybrid 2 x 2 Systems in Figure 7.1-1 ............ 14

Table 7.2-1. Component Properties For Sensor Types A, B, and C ......................................... 18

Table 7.2-2. Component Properties For Computer Types A, B, and C .................................... 18

Table 7.2-3. Connection Reliabilities, Connection Weights, and Dissimilar Component 

Penalties for Each OPN Scenario Run .................................................................. 19

Table 7.4-1. Reliabilities and Weights for the 1- through 9- Connection Architectures Closest 

the Utopia Point .................................................................................................... 35

Table 7.4-2. Reliabilities and Weights for the 1- through 9- Connection Architectures Closest 

the Utopia Point .................................................................................................... 37

Volume II: Appendices

Appendix A. A Comparison of GN&C Architectural Approaches for Robotic and HumanRated Spacecraft ................................................................................................... 46 

Appendix B. A Comparison of Fault-Tolerant GN&C System Architectures Using the Object 

Process Network (OPN) Modeling Language ...................................................... 47

Appendix C. Study Summary Presentation ................................................................................ 68
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

5 of 88

NESC Request No.:06-074-I 

Volume I: Technical Assessment Report 

1.0 Notifi cation and Authorization 

A NASA Engineering and Safety Center (NESC) out-of-board assessment was approved on 

October 5, 2006. Mr. Cornelius Dennehy, NASA Technical Fellow for Guidance, Navigation 

and Control (GN&C) was selected to lead this assessment. The Assessment Plan was presented 

and approved by the NESC Review Board (NRB) on April 19, 2007. The Study Kickoff meeting 

was held at Massachusetts Institute of Technology (MIT) on April 20, 2007. Interim research 

project progress and status reviews were held at MIT in July 2007, in December 2007 and in 

March 2008. An Initial Summary was presented to the NRB on December 19, 2008. The Final 

Report was presented for approval to the NRB on October 22, 2009. 

The key stakeholders for this assessment are Mr. Frank Bauer, Chief Engineer for the 

Exploration Systems Mission Directorate (ESMD); Dr. Brian Muirhead, Constellation Program 

(CxP) Chief System Engineer; Mr. Howard Hu, Orion Crew Exploration Vehicle (CEV) GN&C 

lead; Mr. Scott Tamblyn, CEV GN&C Engineering; and Mr. William Othon, CEV GN&C 

Engineering. 

The NESC, MIT, and Draper Laboratory team performed an independent and systematic study 

on the problem of optimizing the reliability of GN&C architectures with common avionic units. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

6 of 88

NESC Request No.:06-074-I 

2.0 Signatur e Page 

Submitted by: 

Original Signature on File – 3/30/10 

Mr. Cornelius J. Dennehy Date 

Significant Contributors: 

Dr. Gregor Z. Hanuschak Date Dr. Nicholas A. Harrison Date 

Dr. Edward F. Crawley Date Mr. John J. West Date

Dr. Steven R. Hall Date Dr. Alejandro D. Domínguez-García Date 

Signatories declare the findings and observations complied in the report are factually based from 

data extracted from Program/Project documents, contractor reports, and open literature, and/or 

generated from independently conducted tests, analysis, and inspections. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

7 of 88

NESC Request No.:06-074-I 

3.0 T eam List 

Name Discipline Organization/Location 

Core Team 

Cornelius Dennehy 

NESC Lead/NASA 

Technical Fellow for 

Guidance, Navigation, and 

Control NESC/GSFC 

John West 

Fault Tolerant Space 

Systems Draper Laboratory 

Study Team 

Edward Crawley 

 MIT Study Lead 

(System Engineering) 

MIT Aeronautics and Astronautics 

Engineering Department 

Steven Hall 

MIT Study Co-Lead 

(GN&C Avionics Systems) 

MIT Aeronautics and Astronautics 

Engineering Department 

Gregor Hanuschak 

Fault Tolerance and System 

Reliability 

MIT Aeronautics and Astronautics 

Engineering Department 

Nicholas. Harrison 

Fault Tolerant GN&C 

Systems Draper Laboratory 

Alejandro 

Domínguez-García 

Fault Tolerance and System 

Reliability 

University of Illinois at UrbanaChampaign 

Administrative Support 

Roy Savage MTSO Program Analyst LaRC 

Donna Gilchrist 

Planning and Control 

Analyst ATK, LaRC 

Christina Cooper Technical Writer ATK, LaRC 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

8 of 88

NESC Request No.:06-074-I 

4.0 Executive Summary 

This final report summarizes the results of a comparative assessment of the fault tolerance and 

reliability of different Guidance, Navigation and Control (GN&C) architectural approaches. 

This study was proactively performed by a combined Massachusetts Institute of Technology 

(MIT) and Draper Laboratory team as a GN&C “Discipline-Advancing” activity sponsored by 

the NASA Engineering and Safety Center (NESC). This systematic comparative assessment of 

GN&C system architectural approaches was undertaken as a fundamental step towards 

understanding the opportunities for, and limitations of, architecting highly reliable and fault 

tolerant GN&C systems composed of common avionic components. The primary goal of this 

study was to obtain architectural ‘rules of thumb’ that could positively influence future designs 

in the direction of an optimized (i.e., most reliable and cost-efficient) GN&C system. A 

secondary goal was to demonstrate the application and the utility of a systematic modeling 

approach that maps the entire possible architecture solution space. 

The NESC team implemented a systematic approach for modeling, enumerating, and comparing 

simplified GN&C architectures using basic metrics. GN&C systems were decomposed into 

simple ‘building block’ subunits of Sensors, Computers, and Actuators, and various forms of 

subunit interconnection were defined for investigation. The resulting subunit/interconnection 

construct was used as a top-level abstraction for building candidate GN&C system architectures. 

This model was implemented using MIT’s Object Process Network (OPN) modeling language to 

more easily enumerate possible architectures, and ultimately identify which of these architectures 

have optimal properties. Dual and triple redundant GN&C system architectures, employing 

different reliability classes of components, were modeled using the OPN language. For the 

purpose of simplicity, it will be assumed that there are only three different types of GN&C 

avionic components possible for each component class. For example, the model incorporated 

three different types of GN&C Sensor components generically labeled Type A, Type B, and 

Type C, but understood to be representative of a low reliability/lightweight/low accuracy Sun 

Sensor; a medium reliability/medium weight/low-to-medium accuracy star tracker; and a high 

reliability/high weight/high accuracy Inertial Measurement Unit (IMU). The team assessed the 

avionic components typically used to implement recent space system GN&C architectures. 

Based upon this assessment, the team made a critical modeling assumption that the more reliable 

GN&C components tended to be heavier, more costly, and/or more complex. The team realized 

there are other modeling assumptions that could have been made, such as the GN&C avionic 

component with the smallest part count is a more reliable (and probably lower mass) unit than 

one with a higher part count. However, that alternate model construct did not fit either the 

team’s desire to keep the model simple and tractable, or the attributes of the GN&C avionic 

component inventory/technology base. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

9 of 88

NESC Request No.:06-074-I 

For the purposes of this study, reliability is defined as the probability that a given item will 

perform its intended function for a given time under a given set of flight conditions. This is most 

often expressed in terms of an average or mean life, such as Mean Time Between Failure 

(MTBF). Individual component reliabilities are dependent upon the component failure rate and 

desired operational time. The reliability relationships used in the model were exponential and 

governed by the equation R = e -t

, where  is the failure rate and t is the operational time. 

Operational time is a user-defined parameter and based on the length of the space exploration 

mission. An operational time of t = 10 years was assumed in the models developed. It should be 

noted that the model assumed perfect coverage – 100-percent – accuracy in detecting and 

isolating a failure. 

All enumerated architectures were evaluated based on two specific metrics: reliability and 

weight. In this study, the team elected to assume weight as a surrogate indicator of system cost 

and complexity. The team acknowledges that in some cases system cost can be driven by the 

complexity factor alone. However to keep the model simple for this top-level study, the 

assumption made was that weight is a good first-order approximation for system complexity and 

cost. 

The team used an interconnection construct as a top-level abstraction for building a preliminary 

model of GN&C system architectures. This model was implemented using the OPN modeling 

language in order to more easily enumerate possible architectures and ultimately identify which 

architectures have optimal properties. Partial 2 x 2 systems (i.e., systems with up to dual 

redundancy per component class for two component classes) and 3 x 2 systems (i.e., systems 

with up to triple redundancy per component class for two component classes) were modeled in 

OPN. Within the constraints of these models, all possible architectures were rigorously 

enumerated and the weight/reliability trade-offs of cross-strapping components and using more 

than one type of component was assessed. 

It was found that more reliable components are only beneficial in single string systems, or 

systems with single point failures. The key finding of this study was that most optimal GN&C 

system architectures employing component redundancy can be produced from generic 

connections and the least reliable type of avionic component from each component class. The 

analysis of the identified optimal architectures show that it is possible to produce nearly all 

potentially optimal architectures using only the Type A light weight/low-reliability Sensors, 

Type A light weight/low-reliability Computers, and generic connections. The identified optimal 

architectures reveal a preference to increase GN&C system redundancy of lighter, less reliable 

components rather than using smaller numbers of more reliable, heavy components. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

10 of 88

NESC Request No.:06-074-I 

The NESC team concluded there is merit in mapping the entire possible system architecture 

solution space. By showing where similar classes of solutions fall within the entire set, it allows 

one to quantitatively see how certain solution features affect Figure-of-Merit (FOM) 

performance and derive architecture ‘rules of thumb’. It also allows one to see the optimal 

system architecture solution boundary (the Pareto Front) and understand how one FOM can be 

exchanged for another. 

The approach documented in this report provides insight into a potential limitation of the 

‘Minimum Functionality/Minimum Implementation’ system architecting methodology also 

known as the ‘Iterative Risk Driven Design Approach ‘as described in [ref.6] which uses as its 

starting point a single-string non-redundant system architecture. This method involves 

performing iterative trades to improve system safety until the mass margin is exhausted. It is not 

apparent that this stepwise optimization of a single design can ever achieve the boundary of 

optimal solutions (the Pareto Front). Even if it somehow did reach the optimal boundary, it is 

not clear the system architects will have access to and be able to visualize the whole range of 

optimal solutions. System architects using the ‘Minimum Functionality/Minimum 

Implementation’ approach should be aware of the technique described in this report and consider 

using it for comparison. 

The team also concluded that with some enhancements, the systematic GN&C/Avionics 

“building block” OPN modeling techniques employed would serve as an excellent tool for 

evaluating competing GN&C system architectures for future spacecraft. This OPN-based 

approach, or other similar modeling tools, would perform the extremely useful up-front function 

of identifying the most attractive (lowest weight and overall “cost”) GN&C architectural options 

that satisfy a prescribed set of spacecraft fault tolerance, reliability, and performance 

requirements. Although less likely, but worth observing, is that such “building block” models 

could be used to identify the optimal (highest reliability/lowest weight) architectural options for 

a prescribed number and configuration of connections between adjacent GN&C components. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

11 of 88

NESC Request No.:06-074-I 

5.0 Ass essment Plan 

5.1 Background 

Historically, the United States (US) human spaceflight programs have had thorough GN&C 

analysis and design early in their lifecycles, evaluating various GN&C architectural concepts 

within the trade space of their individual mission goals, constraints, and risk postures. The 

selected GN&C architectures have been tailored for each program, which is not surprising given 

the very different mission concepts. The Constellation Program (CxP) will be no different, but 

top level program requirements drivers for reliability and affordability may flow down to 

influence GN&C architectural considerations, such as fault tolerance, in ways never before 

encountered in the US space program. 

Accomplishing the objectives of the CxP requires reliable GN&C for multiple spacecraft, both 

crewed and robotic. The up-front “architecting-in” of reliability is an integral part of the early 

steps of the GN&C Systems Engineering process. Substandard architectures may not only be 

unreliable but are typically difficult to fabricate, test, operate, support, service, and upgrade. 

These architectures can also be prohibitively costly to adapt to evolving mission scenarios as the 

system lifecycle extends beyond the anticipated time frame of service. 

The operators of systems with substandard architectures can have protracted development 

schedules and high recurring operational costs as a result of not fully informed design decisions 

made early in a project’s development cycle. Therefore, it was important that a major system 

development project not prematurely shift its focus to the challenges of implementation before 

fully defining the appropriate architecture. There is benefit to allocating the time and devoting 

sufficient attention to defining the optimum system architecture over the lifecycle by producing 

the maximum return for a given level of risk and resources. 

With some of these considerations in mind a comparative assessment activity focused on 

investigating the fault tolerance and reliability trades between different GN&C architectural 

approaches was formulated by the NASA Technical Fellow for GN&C. This led to a proactive 

study being performed by a combined MIT and Draper Laboratory team as a GN&C “DisciplineAdvancing” activity sponsored by the NESC. The motivation for performing this study was the 

observation, both on the part of NESC and MIT, that GN&C systems for exploration 

prominently stand out among all the future spacecraft systems, as a potential “sweet spot” area 

where having flight hardware commonality might be of greatest benefit. This systematic 

comparative assessment of GN&C system architectural approaches was undertaken as a 

fundamental step towards understanding the opportunities for and limitations of architecting 

highly reliable and fault tolerant GN&C systems composed of common GN&C avionic 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

12 of 88

NESC Request No.:06-074-I 

components. The primary goal of this study was to obtain architectural ‘rules of thumb’ which 

could positively influence and drive future designs in the direction of the most reliable and costefficient GN&C systems possible. A secondary goal was to demonstrate the application and 

utility of a systematic modeling approach that maps the entire possible architecture solution 

space. 

5.2 Scope 

The proposed work was a systematic GN&C architecture comparative study performed by an 

integrated MIT/Draper Laboratory study team under the leadership of Dr. Edward Crawley of the 

MIT Aeronautics and Astronautics Engineering Department. 

This study leveraged analytical methods developed at MIT as part of their program in Technical 

System Architecture, and their specialized analysis tools/methods used to support the NASA 

Exploration Systems Mission Directorate (ESMD) Concept Exploration and Refinement 

(CE&R) study. The MIT tools and methods were extended and applied to the problem of 

optimum GN&C system architectures. The existing MIT systematic architecture analysis 

capability, under Dr. Edward Crawley, was used to execute this task. Dr. Steven Hall, formerly 

of the Draper Laboratory, actively participated in this assessment as the Co-Lead and as the 

principal researcher on the assessment and evaluation of reliable GN&C avionic architectures. 

MIT’s capabilities in system architecting methods were grounded in long-term research studies 

and benchmarking of best practice in space, automotive, electronics, and oil exploration 

industries. Historical work included methods developed in support of NASA’s Advanced 

Planning and Integration office, the creation and continuous refinement of a graduate-level class 

in Technical System Architecture, and through participation in multiple previous studies 

supporting NASA’s ESMD. 

6.0 Problem Description, Proposed Solutions, and Risk Assessment 

6.1 Description of the Problem 

Sensors, Computers, and Actuators will be defined as “component classes”. The terminology “I 

x J OPN model” will be used to describe a model with up to “I” redundancy per component class 

and up to “J” component classes. For example, J = 2 could designate a model which only has 

Sensors or which has Sensors and Computers. J = 3 could designate a model with: Sensors; 

Sensors and Computers; or Sensors, Computers, and Actuators. If J = 3 and I = 2, this could 

designate a system with up to 2 Sensors, 2 Computers, and 2 Actuators. This paper will discuss 

the OPN 2 x 2 and 3 x 2 models and their applicability to a 3 x 3 model. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

13 of 88

NESC Request No.:06-074-I 

For the purpose of simplicity, it will be assumed that there are only three different types of 

components possible for each component class. In reality, three Sensor Types might include a 

Sun Sensor, star tracker, and an IMU. However, to be more generic, Types will instead be 

referred to as Type A, Type B, and Type C. 

As a first pass, all enumerated architectures were evaluated based on two specific metrics: 

reliability and weight. In this study, the team elected to use weight as a surrogate indicator of 

system cost and complexity. The team did observe and understand that in some cases system cost 

can be driven by the complexity factor alone. However to keep the model simple for this toplevel study the assumption made was that weight is a good first order approximation for system 

complexity and cost. 

7.0 Data Analysis 

Section 7.1 will discuss the design of the simple 2 x 2 model, Section 7.2 will give further details 

on the model, and Section 7.3 will discuss the design of the more complicated 3 x 2 model. 

Section 7.4 will examine the application of reliability and weight metrics to the enumerated 

architectures. Finally, Section 7.5 will provide some general concluding remarks. 

7.1 The 2 x 2 GN&C System 

This section begins the discussion of the design of the 2 x 2 model. Even with just four 

components (2 Sensors and 2 Computers), numerous architectures can be defined for a 2 x 2 

system based on how the components are inter-connected. Each of these architectures will have 

different total weight and reliability. 

Figure 7.1-1. Three Possible 2 x 2 Systems 

Figure 7.1-1 depicts three possible 2 x 2 architectures. The reliability, R, of the three models is 

shown in Table 7-1.1, where sj is the reliability of Sensor j, and ck is the reliability of 

Computer k. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

14 of 88

NESC Request No.:06-074-I 

Table 7.1-1. Reliability Expressions for the 2 x 2 Systems in Figure 7.1-1 

Architecture Reliability 

Channelized R = s1c1 + s2c2 – s1c1s2c2

Hybrid R = s1c1 + s2c1 + s2c2 – s2c1c2 – s1s2c1 – 

s1s2c1c2 + s1s2c1c2

Cross-Strapped 

R = s1c1 + s1c2 – s1c1c2 + s2c1 + s2c2 – s2c1c2 – 

s1s2c1 – 2s1s2c1c2 + 2s1s2c1c2 – s1s2c2 + 

2s1s2c1c2 – s1s2c1c2

It is important to note that no matter what the architecture, the reliability of any 2 x 2 model can 

be generated by taking the cross-strapped expression for R and then eliminating terms from the 

expression for connections which do not exist and therefore do not contribute to system 

reliability. Additional indicator variables are added to the cross-strapped reliability expression to 

specify which terms to eliminate. These indicator variables were correlated with the 

interconnections between components. A nonzero indicator variable represented a connection, 

whereas an indicator variable equal to zero represents a missing connection. 

Using the methodology described, the following general expression for R is obtained: 

R = s1i11c1 + s1i12c2 – s1i11i12c1c2 + s2i21c1 + s2i22c2 – s2i21i22c1c2 – s1s2i11i21c1 – 

s1s2i11i22c1c2 – s1s2i12i21c1c2 + s1s2i11i12i21c1c2 + s1s2i11i21i22c1c2 – s1s2i12i22c2 + 

s1s2i11i12i22c1c2 + s1s2i12i21i22c1c2 – s1s2i11i12i21i22c1c2

Where ijk is the reliability of the connection between Sensor j and Computer k, if such a 

connection exists and 0 otherwise. 

As a sanity check, the reliability expressions for the channelized and hybrid architectures can be 

derived from the general expression. Assuming perfect connection reliability (i.e., ijk = 1 for all 

connections in the architecture) the channelized and hybrid architectures would be represented 

by the indicator variables in Table 7.1-2. Plugging these indicator variables into the general 

expression gives the same reliability expressions in Table 7.1-1. 

Table 7.1-2. Indicator for the Channelized and Hybrid 2 x 2 Systems in Figure 7.1-1 

Architecture i 11 i12 i21 i22

Channelized 1 0 0 1 

Hybrid 1 0 1 1 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

15 of 88

NESC Request No.:06-074-I 

7.2 Details on the 2 x 2 OPN Model 

Like the previously mentioned 3 x 2 and 3 x 3 models, the 2 x 2 OPN model was viewed as a 

sophisticated Petri net model. In a Petri net model, information-storing tokens move via directed 

arcs from transitions to and from places to transitions. Note that there may be more than one 

directed arc feeding from or to a transition or place. Upon arrival at a transition a token is 

consumed and then processing is completed, and, if appropriate, new tokens were introduced in 

the places dictated by the directed arcs leading from the transition. 

The sequence of transitions in any of the discussed OPN models is a sequence of decision points. 

At each decision point, a token is replicated with multiplicity equal to the number of possible 

decisions. The information stored in each token represents a unique possible architecture. Taken 

together, the tokens enumerate all possible architectures given an initial set of constraints. All 

tokens are collected when they completely propagate through the model for analysis. 

Figure 7.2-1 is a visual representation of the OPN decision tree for the 2 x 2 model and the 

following questions are the decision points: 

 How many Sensors? 

 1 or 2 

 Type assignment for Sensors? 

 If only one Sensor, then choose Sensor A, Sensor B, or Sensor C 

 If two Sensors, then choose two of the same Type of Sensor or one of each of two 

Types (i.e., the possible combinations would be: AA, AB, AC, BB, BC, and CC) 

 How many Computers? 

 1 or 2 

 Type assignment for Computers? 

 If only one Computer, then choose Computer A, Computer B, or Computer C 

 If two Computers, then choose two of the same Type of Computer or one of each 

of two Types (i.e., the possible combinations would be: AA, AB, AC, BB, BC, 

and CC) 

 Which Sensors are connected to Computer 1? 

 Just Sensor 1 

 Just Sensor 2 (if Sensor 2 exists) 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

16 of 88

NESC Request No.:06-074-I 

 Both Sensor 1 and 2 (if Sensor 2 exists) 

 If Computer 2 exists, which Sensors are connected to Computer 2? 

 Just Sensor 1 

 Just Sensor 2 (if it Sensor 2 exists) 

 Both Sensor 1 and 2 (if Sensor 2 exists) 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

17 of 88

NESC Request No.:06-074-I 

Figure 7.2-1. 2 x 2 OPN Decision Tree 

During the process of token propagation, the number of components, component types, and 

connections were continuously updated for later use in reliability calculations. In addition, the 

current weight of the system was updated at execution time. Each component type was given its 

__final_state

Connections to Computer 2

Connections to Computer 1

Type assignment for 1 computer

Type assignment for 2 sensors

How many computers?

Type assignment for 2 computers

Type assignment for 1 sensor

How many sensors?

__init_state

1 sensor

__init_proc

Sensor Type A

Sensor Type C

Sensor Type B

Computer Type A

Sensor 2 connected to Computer 1

Sensors 1 and 2 connected to Computer 1

Sensor 1 connected to Computer 1

Sensor 2 connected to Computer 2

No sensor connections to Computer 2

Sensor 1 connected to Computer 2

Sensors 1 and 2 connected to Computer 2

Computer Type B

Computer Type C

1 computer

Sensor Types AA

Sensor Types AB

2 sensor

Sensor Types BB

Sensor Types CC

Sensor Types BC

Sensor Types AC

2 computers

Computer Types AC

Computer Types BC

Computer Types AB

Computer Types CC

Computer Types BB

Computer Types AA
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

18 of 88

NESC Request No.:06-074-I 

own unique reliability and weight based on the specific make and model of the component. 

These values were based on real components, but modified slightly to facilitate analysis. 

Reliabilities are dependent upon the failure rate of the component and the desired operational 

time for the component. The relationship is governed by the equation R = e -t, where  is the 

failure rate and t is the operational time. Operational time is user defined and based on the 

length of the proposed mission. An operational time of t = 10 years was used in the models 

discussed in this paper. Other component properties are illustrated in Table 7.2-1 and Table 

7.2-2. 

Table 7.2-1. Component Properties For Sensor Types A, B, and C 

Sensor Type A B C 

Failure Rate,  (/year) 0.00015 0.00 01 0.00005 

Reliability, R 0.9985 0.999 0.9995 

Weight (dimensionless) 3 6 9 

Table 7.2-2. Component Properties For Computer Types A, B, and C 

Computer Type A B C 

Failure Rate,  (/year) 0.0001 0.00 004 0.00002 

Reliability, R 0.999 0.9996 0.9998 

Weight (dimensionless) 3 5 10 

Two additional weights and one reliability were also included in the model. A “connection 

weight” and a “dissimilar component penalty” were included to ensure that weight continues to 

approximate complexity and cost. Cross-strapping components may not add significant weight 

to the overall system, but adds to the system complexity and cost. Similarly, dealing with more 

than one Type of Sensor and/or Computer also increases complexity and cost. Hence, adding 

these additional weights where appropriate worked as a first step toward simulating an 

operational system. 

The weights associated with connections and dissimilar components were chosen to be consistent 

with the weights of Sensors and Computers. To do so, assumptions were made and the 

connections were considered to be, at most, 1/3 of the complexity of the average Computer. In 

addition, the weight penalty for dissimilar components was set such that it was not larger than 

the heaviest Sensor or Computer. 

These assumptions dictated a certain range of weight values used for connections and dissimilar 

component parameters. However, rather than presuppose exact values for these weights, 

multiple OPN runs were executed varying one of the parameters each time. Assuming the 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

19 of 88

NESC Request No.:06-074-I 

connection reliability would be greater than that of a Computer, the nine OPN scenarios are 

illustrated in Table 7.2-3. 

Table 7.2-3. Connection Reliabilities, Connection Weights, and Dissimilar Component Penalties for 

Each OPN Scenario Run 

OPN Scenario 1 2 3 4 5 6 7 8 9 

Connection 

Reliability 

1 1 1 0.99995 0.99995 0.99995 0.9999 0.9999 0.9999 

Connection 

Weight 

(dimensionless) 

0 0 0 0.5 0.5 0.5 5 / 3 5 / 3 5 / 3 

Dissimilar 

Component 

Penalty 

(dimensionless) 

0 6 9 0 6 9 0 6 9 

7.3 Details on the 3 x 2 OPN Model 

Implementation of the 3 x 2 OPN model is similar to that of the 2 x 2 model with two notable 

exceptions. These exceptions relate to the overall system reliability formula and the removal of 

duplicate architectures to minimize the computer memory required to run the model. The 

reliability formula was more complicated for the larger models and was handled differently. 

Although reliability is calculated after the OPN completes execution, it can no longer be easily 

manually calculated for implementation in Microsoft® Excel®. Instead, symbolic MATLAB® 

was used to calculate the formula and a MATLAB® script was used to insert the correct “i” 

indicator values where appropriate. Only after this manipulation was performed could the 

reliability values be imported into Excel® for implementation. 

In addition, care had to be taken to ensure no architecture was represented more than once in the 

model. Running a larger 3 x 2 OPN model would take an inordinate amount of time and 

computer memory. It was found that certain architectures could be represented in multiple 

configurations and this was not taken into account by the 2 x 2 model1

. By producing tokens for 

all possible configurations of the same architecture, the model required significantly longer run 

times and used substantial memory. 

 

1

 The 2 x 2 model is smaller than the 3 x 2 model. As a result, there were no memory issues and duplicate 

architectures were removed in post-processing (i.e., they did not have to be removed in OPN). 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

20 of 88

NESC Request No.:06-074-I 

An example of duplicate architecture is shown in Figure 7.3-1. A1 and A2 represent the same 

architecture, in both cases one Sensor of Type A is connected to a Computer of Type A, the other 

Sensor A is connected to a Computer A and a Computer B, and a Sensor of Type B is connected 

to a Computer of Type C. A3 represents a different architecture, however, since both Sensors of 

Type A are connected to a Computer of Type B. 

Figure 7.3-1. Determination of Duplicate Architectures 

The process of eliminating duplicate architectures began by choosing a representative set of 

Sensor Types and Computer Types. Ten possibilities were chosen as representative orderings of 

the three Sensor Types and also the three Computer Types: AAA, AAB, AAC, ABB, ACC, 

ABC, BBB, BBC, BCC, and CCC. 

A1 in Figure 7.3-1 represents a connection pattern between three adjacent components. This 

connection pattern has four connections: Sensor 1 to Computer 1, Sensor 2 to both Computer 1 

and Computer 2, and Sensor 3 to Computer 3. Keeping this connection pattern fixed, the team 

gave a “Type” identity to the three Sensors based on the 10 possible orderings. For each possible 

ordering of the Sensor Types, there were 10 possible orderings of the Computer Types, each of 

which defines a unique architecture. In other words, for any given connection pattern such as 

A1, there are 10 x 10 = 100 possible architectures. The OPN model iterates through all possible 

connection patterns and finds all 100 possible architectures. 

Note that orderings such as ABA and BAA are not taken to be representative orderings. When 

all possible connection patterns are taken into account, these additional orderings will fail to 

produce any architecture that cannot be produced by AAB. This is because ABA, BAA, and 

AAB are equivalent (i.e., all represent two components of Type A and one of Type B). It does 

not matter in what order the Types are described as long as the case is represented. 

Searching for duplicate architectures in the OPN does not require checking 100 possible 

architectures for each connection pattern. The 100 possibilities for each connection pattern can 

be represented by 16 representative architectures. As illustrated in Figure 7.3-2, the 10 Sensor 

Type combinations and the 10 Computer Type combinations can be abstracted to just four 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

21 of 88

NESC Request No.:06-074-I 

representative combinations per component. First, AAA, BBB, and CCC represent the case 

where all three components are of the same type. Next, AAB, AAC, and BBC represent the case 

where the first two components were of the same Type and the third component was of a 

different Type. Furthermore, ABB, ACC, and BCC represent the case where the second and 

third components are of the same Type, but the first component is of a different Type. Finally, 

ABC represents the case where all three components were of a different Type. 

Figure 7.3-2. Finding Representative Architectures 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

22 of 88

NESC Request No.:06-074-I 

Figure 7.3-3 helps demonstrate why these representative architectures work for finding duplicate 

architectures. To use representative architectures to find duplicates is to claim that if architecture 

A1 is equivalent to architecture A2, but not A3, then architecture B1 is equivalent to B2, but not 

B3.

Figure 7.3-3. Using Representative Architectures to Find Duplicates 

As previously discussed, A1 and A2 represent the same architecture even though they have 

different connection patterns. It is arbitrary which form of architecture is chosen as the primary 

form and which is a duplicate (i.e., either A1 or A2 could be considered the duplicate). 

The study team implemented duplicate detection into the model, which was an involved manual 

process. The assessment had a finite schedule allocation and the development time necessary for 

automating the duplicate detection process was uncertain. It was therefore decided that a manual 

(i.e., brute force) method should be used to implement duplicate detection. All possible 

representative architectures were manually drawn and duplicate architectures were identified. In 

all, over 100 pages of architectures were drawn and compared. An example of manually drawn

architectures is shown in Figure 7.3-4. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

23 of 88

NESC Request No.:06-074-I 

Figure 7.3-4. Example of Manually-Drawn Architectures 

Based on the circled representative architectures, rules were created and inserted into the OPN to 

keep any tokens that will produce duplicate architectures from propagating. Note that all rules 

are in the form of Boolean expressions starting with “not if” instead of “if”. Although all work 

was double-checked, it is conceivable that an incorrect rule was entered due to human error. By 

using “not if” instead of “if”, the default is to pass the token. It was assessed that it is better to 

retain a duplicate architecture rather than exclude a potentially optimal architecture. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

24 of 88

NESC Request No.:06-074-I 

The Boolean rules are inserted into the OPN model on the transitions from: 

 Which Sensors are connected to Computer 1? 

 If Computer 2 exists, which Sensors are connected to Computer 2? 

 If Computer 3 exists, which Sensors are connected to Computer 3? 

To the places: 

 Just Sensor 1 

 Just Sensor 2 (if Sensor 2 exists) 

 Just Sensor 3 (if Sensor 3 exists) 

 Just Sensors 1 and 2 (if Sensor 2 exists) 

 Just Sensors 1 and 3 (if Sensor 3 exists) 

 Just Sensors 2 and 3 (if Sensor 3 exists) 

 Sensors 1, 2, and 3 (if Sensor 3 exists) 

Trivial rules govern which Sensors are connected to Computer 1. If a particular token represents 

an architecture with only two Sensors, it is not possible to make a connection to a Computer 

from a nonexistent Sensor 3. Therefore, in the two Sensor case, no new tokens are introduced 

into the places representing, “just Sensor 3”, “just Sensors 1 and 3”, “just Sensors 2 and 3”, or 

“Sensors 1, 2, and 3”. Similarly, if a particular token represents an architecture with only one 

Sensor, no new tokens are introduced into the places representing, “just Sensor 2”, “just Sensor 

3”, “just Sensors 1 and 2”, “just Sensors 1 and 3”, “just Sensors 2 and 3”, or “Sensors 1, 2, 

and 3”. 

Rules governing connections to Computer 2 and 3 are more complicated. If a token represents 

an architecture with only two Computers, the final system architecture will be evident after 

creating the Sensor connections to the second Computer. If a token represents an architecture 

with three Computers, it is known that there will be a final system architecture after creating the 

Sensor connections to the third Computer. Connections that will form duplicate (circled) 

architectures should not be allowed to propagate. Hence rules are followed to block introduction 

of these tokens. 

Figure 7.3-5 shows an example of a rule based on a manually drawn architecture. This rule 

determines whether a connection should be made between Sensor 3 and Computer 3. Note that, 

by the time a token reaches the given rule, the connections between Sensor 1 and Computer 2, 

and between Sensor 2 and Computer 1 have already been defined. No connection should be 

made if the type definitions for the Sensors and Computers match those represented by the 

circled architectures (i.e., such tokens will result in the formation of duplicate architectures). 

In other words, the connection between Sensor 3 and Computer 3 should not be made if Sensor 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

25 of 88

NESC Request No.:06-074-I 

1’s Type is the same as Sensor 2’s Type, or Computer 1’s Type is the same as Computer 2’s 

Type. 

!(Computer Redundancy < 3) && 

!(Sensor Redundancy < 3) && 

!( 

(i11 == 0 && i12 == 0) || 

(Sensor Redundancy > 1 && i21 == 0 && i22 == 0) || 

 ( 

(i11 == 0 && i12 > 0 && i21 > 0 && i22 == 0 && i31 == 

0 && i32 == 0) && 

( 

(Sensor1_Type == Sensor2_Type) || 

(Computer1_Type == Computer2_Type) 

 ) 

 ) 

)

Figure 7.3-5. Example of Rule Based on a Manually Drawn Architecture 

Eliminating duplicate architectures in the 3 x 2 OPN model significantly reduced the number of 

tokens produced from 51,902 to 9,795 tokens. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

26 of 88

NESC Request No.:06-074-I 

7.4 Results 

Despite eliminating the unnecessary duplicate architectures from the model, attempts to run a 

3 x 3 model still resulted in a memory shortage. Although it is unfortunate that the larger OPN 

model could not be completed, it is important to note that results from the 3 x 2 model can be 

applied to the 3 x 3 case. 

By taking a top-level view of a GN&C system, the interaction between adjacent Sensor and 

Computer components is identical to the interaction between adjacent Computer and Actuator 

components. Similar to the Sensors and Computers, there are different Types of Actuators, each 

with a unique set of properties. A system architect will be able to choose different redundancies 

for each of these Types. Furthermore, the connection patterns already found between Sensors 

and Computers are the same as those between Computers and Actuators. Finally, the metrics of 

weight and reliability can be calculated in the same way. 

There were nine scenarios outlined in this section, each scenario was run and Pareto plots were 

produced for each. Representative plots for the nine scenarios are reproduced in Figures 7.4-1 

through 7.4-4. In each scenario, the architectures that simultaneously had both lowest weight 

and highest reliability were identified. These architectures are “on the Pareto front.” The 

identified Pareto- architectures were found by zooming in on the “utopia point” at the lower right 

hand corner of the plot2

. Note that in most cases, there are multiple identified architectures for 

each scenario since it is somewhat subjective which architectures are closer to the utopia point. 

For example: Is an architecture with weight = 17 and reliability = 0.999999596912468 (six “9”s) 

better than an architecture with weight = 18 and reliability = 0.999999995634079 (eight “9”s)? 

The answers to such questions are made clear in the mission requirements context. For a humanrated mission, perhaps a reliability of 0.9999999 (seven “9”s) is required for safety. If this were 

the case, the architecture with weight = 18 would be better, since the architecture with weight = 

17 does not meet the seven “9”s requirement of this example. 

In the zoomed out (top) plot of each of the nine scenarios, there appear to be six clusters of 

architecture data points. The architectures in each cluster have nearly identical reliabilities. 

Looking from left to right, the first five clusters (i.e., the five clusters with the lowest reliability) 

are driven by single point failures of any of the six component Types. For example, in an 

architecture that contains one Sensor and two Computers, or an architecture that contains one 

Sensor and three Computers, the single Sensor present in the architecture must remain viable in 

order for the overall system to remain reliable. Sensor Type A has a reliability of 0.9985. 

 

2

 The utopia point represents the ideal architecture which is 100 percent reliable with weight = 0. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

27 of 88

NESC Request No.:06-074-I 

Therefore, a one-Sensor two-Computer or one-Sensor three-Computer architecture that contains 

Sensor A can have a maximum reliability of 0.9985. Architectures that have a single point 

failure at Sensor A, define the first (least reliable) cluster of data points. Both Sensor Type B 

and Computer Type A have the same reliability of 0.999. Therefore, architectures that have a 

single point failure at a Sensor of Type B, or a single point failure at a Computer of Type A, will 

fall into the second cluster. Similarly, Sensor Type C’s reliability of 0.9995 defines the third 

cluster, Computer Type B’s reliability of 0.9996 defines the fourth cluster, and Computer Type 

C’s reliability of 0.9998 defines the fifth cluster. 

The sixth and final (most reliable) cluster contains all other architectures (i.e., architectures free 

from single point failures). The additional points that do not fall into any of the six clusters are 

single-string architectures (i.e., architectures that contain one Sensor and one Computer). These 

architectures contain not one, but two single point failures and are therefore significantly less 

reliable than an identical architecture with additional Computers or additional Sensors. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

28 of 88

NESC Request No.:06-074-I 

Figure 7.4-1. Architecture Pareto Plots 

Note: (Top) Pareto plot with added details for number of connections between Sensors and Computers, (Middle) 

zoomed in version of the same plot, (Bottom) potential optimal architectures for this scenario: (From left to right) 

Architecture 1 has weight = 12 and reliability = 0.9999967, architecture 2 has weight = 15 and reliability = 

0.9999989, architecture 3 has weight = 17 and reliability = 0.99999959, and architecture 4 has weight = 18 and 

reliability = 0.9999999956
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

29 of 88

NESC Request No.:06-074-I 

Figure 7.4-2. Architecture Pareto Plots 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

30 of 88

NESC Request No.:06-074-I 

Figure 7.4-2. Concluded

Note: (Top) Pareto plot with added details for both number of Sensors and number of Computers, (Middle) zoomed 

in version of the same plot, (Bottom) potential optimal architectures for this scenario: (From left to right) 

Architecture 1 has weight = 12 and reliability = 0.99999675437371, architecture 2 has weight = 15 and reliability = 

0.999998997632005, and architecture 3 has weight = 18 and reliability = 0.999999995634079 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

31 of 88

NESC Request No.:06-074-I 

Figure 7.4-3. Architecture Pareto Plots 

Note: (Top) Pareto Plot with Added Details for Both Number and Types of Computers, (Middle) Zoomed in version 

of the same plot, (Bottom) potential optimal architectures for this scenario: (From left to right) Architecture 1 has 

weight = 14 and reliability = 0.999996754062388, architecture 2 has weight = 17 and reliability = 

0.999998992620742, architecture 3 has weight = 19 and reliability = 0.999999593334442, and architecture 4 has 

weight = 19.5 and reliability = 0.999999983481890 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

32 of 88

NESC Request No.:06-074-I 

Figure 7.4-4. Architecture Pareto Plots 

Note: (Top) Pareto plot with added details for both number and Types of Sensors, (Middle) zoomed in version of 

the same plot, (Bottom) Potential optimal architectures for this scenario: (From left to right) Architecture 1 has 

weight = 15.333 and reliability = 0.999993257523472, architecture 2 has weight = 17 and reliability = 

0.99999501059889, architecture 3 has weight = 18.667 and reliability = 0.999996753726173, architecture 4 has 

weight = 20 and reliability = 0.999997398039817, architecture 5 has weight = 21.667 and reliability = 

0.999998992071849, and architecture 6 has weight = 23 and reliability = 0.999999983481890
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

33 of 88

NESC Request No.:06-074-I 

The ideal case would be that there is no penalty for connection weight or using dissimilar 

components, which can be seen in Figure 7.4-1. In this scenario, all identified architectures are 

fully cross-strapped. This is to be expected since additional connections increase reliability yet 

cost nothing. Figure 7.4-1 also demonstrates that the weight of an architecture’s component 

plays a major role in determining the optimality of the architecture. Recall that components of 

Type A are the lightest and least reliable, and that components of Type C are the heaviest and 

most reliable. Even though components of Type A is the least reliable, Sensors of Type A and 

Computers of Type A are by far the most prevalent component Types in all the optimal 

architectures. In addition, although components of Type C are the most reliable, no components 

of this type appear in any of the optimal architectures. Furthermore, there were no Sensors of 

Type B in the optimal architectures. Architecture three contains a Computer of Type B, but this 

architecture is no longer optimal once the “dissimilar components penalty” is increased from 

penalty = 0 to penalty = 6 (see Figure 7.4-2). Since the optimal architectures for penalty = 6 

contain no dissimilar components, increasing the penalty to = 9 results in no further changes to 

the optimal architectures. 

Figure 7.4-3 provides a baseline for what can be considered a realistic system. In this scenario, 

there are no longer perfect connection reliabilities of 100 percent and there is a cost for 

producing connections (i.e., connection reliability = 0.99995 and connection weight = 0.5). As a 

result of the 0.5 connection weight, only one fully cross-strapped architecture (Architecture 1) is 

among the optimal architectures. The other optimal architectures have 3 or 4 connections. 

Among these, Architectures 2 and 3 are the most interesting. Each has three Sensors and two 

Computers with two of the Sensors having one connection to a Computer and the last having two 

connections. 

The scenario in which connection weight = 0.5 is similar with the connection weight = 0 

scenario. Once again, the component types in the optimal architectures are predominantly of 

Type A and never of Type C. Only one optimal architecture (Architecture 3) contains a 

component of Type B (Computer). This architecture is not optimal when the dissimilar 

components penalty is increased to penalty = 6. There is no change in optimal architectures for 

connection weight = 0.5 when this penalty is increased from penalty = 6 to = 9. 

Figure 7.4-4 depicts the first scenario where connection reliability = 0.9999 and connection 

weight = 5/3. This scenario produces similar optimal architectures to the connection weight = 

0.5 scenario, but with notable exceptions. 

Even with the dissimilar components penalty set to penalty = 0, connection weight = 5/3 is 

sufficiently high as to eliminate any architecture that contains a component type heavier than 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

34 of 88

NESC Request No.:06-074-I 

Type A. This means that Architecture 3 from Figure 7.4-3 is the only connection weight = 0.5 

architecture which contains a component of Type B, and is not an optimal architecture for 

connection weight = 5/3. This also means that the optimal architectures for connection weight = 

5/3 will not change if the dissimilar components penalty is increased to penalty = 6 or = 9. 

A connection weight of 5/3 makes it more desirable to have architectures with fewer 

connections. Although Architectures 1, 2, and 4 from Figure 7.4-3 are still optimal architectures 

when the connection weight is increased to 5/3, the value of these architectures was diminished 

with the heavier connection weight. As a result, these architectures are no longer closer to the 

utopia point than Architectures 1, 2, and 4 from Figure 7.4-4. 

The six potentially optimal architectures for connection weight = 5/3 produce an interesting set. 

All legal architectures with four or fewer connections that contain two to three Sensors of Type 

A and two Computers of Type A are optimal architectures for this scenario. In effect, a system 

architect is directly trading an increase in weight for additional reliability when connection 

weight = 5/3. 

By reviewing a subset of the possible architectures, specifically a subset in which all members 

have the same number of connections, the effect of the dissimilar components penalty on the 

optimal architectures is nearly identical to the penalty’s effect on the optimal architectures of the 

superset. Figures 7.4-5 and 7.4-6 depict the optimal architectures for 3 x 2 systems with 

1through 9 connections when the connection reliability equals one and connection weight equals 

zero. The reliabilities and weights for these architectures can be found in Tables 7.4-1 and 7.4-2. 

Again, as the penalty is increased from penalty = 0 to 6, nearly all architectures containing 

Sensor Type B or Computer Type B cease to be optimal. For architectures with the same 

number of connections, the same architectures which are optimal for penalty = 0 will be optimal 

no matter what the connection weight. Similarly, architectures which are optimal for penalty = 6 

or9 remained optimal no matter what the connection weight. Although the overall system weight 

of any subset member will change if the connection weight is modified, this change will be 

identical to the transformation seen by any of the other systems in this subset. This is because all 

systems in each subset have, by definition, the same number of connections. Therefore, among 

architectures with the same number of connections, the architectures closest to the utopia point 

will remain closest to the utopia point regardless of the change to the connection weight. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

35 of 88

NESC Request No.:06-074-I 

Table 7.4-1. Reliabilities and Weights for the 1- through 9- Connection Architectures Closest the 

Utopia Point 

Note: Assuming a 3 X 2 System with Connection Reliability = 1, Connection Weight = 0, and No Penalty for 

Dissimilar Components 

Connections Reliability Weight On Pareto front? 

1 0.99 9100405 14 

 0.99 9300245 19 

2 0.99 9993766 12 

 0.99 9995260 14 

 0.99 9996397 16 

 0.99 9997344 19 

 0.99 9997754 20 

 0.99 9998292 22 

 0.99 9998741 25 

3 0.99 9995260 12 

 0.99 9996756 14 

 0.99 9997499 15 

 0.99 9998996 17 

 0.99 9999984 18 

4 0.99 9996754 12 Yes 

 0.99 9998993 15 

 0.99 9999594 17 

 0.99 9999988 18 

5 0.99 9998995 15 

 0.99 9999596 17 

 0.99 9999992 18 

6 0.99 9998998 15 Yes 

 0.99 9999597 17 Yes 

 0.99 9999996 18 

7 0.99 9999994 18 

8 0.99 9999996 18 

9 0.99 9999996 18 Yes 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

36 of 88

NESC Request No.:06-074-I 

Figure 7.4-5. Architectures Described in Table 7.4-1
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

37 of 88

NESC Request No.:06-074-I 

Table 7.4-2. Reliabilities and Weights for the 1- through 9- Connection Architectures Closest the 

Utopia Point 

Note: Assuming a 3 X 2 System with Connection Reliability = 1, Connection Weight = 0, and Penalty = 6 for 

Dissimilar Components 

Connections Relia bility Weight On Pareto front? 

1 0 .999100405 14 

 0 .999300245 19 

2 0 .999993766 12 

 0 .999996397 16 

3 0 .999995260 12 

 0 .999997499 15 

 0 .999999984 18 

4 0 .999996754 12 Yes 

 0 .999998993 15 

 0 .999999988 18 

5 0 .999998995 15 

 0 .999999992 18 

6 0 .999998998 15 Yes 

 0 .999999996 18 

7 0 .999999994 18 

8 0 .999999996 18 

9 0 .999999996 18 Yes 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

38 of 88

NESC Request No.:06-074-I 

Figure 7.4-6. Architectures Described in Table 7.4-2 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

39 of 88

NESC Request No.:06-074-I 

7.5 Concluding Remarks 

There is merit in mapping the entire possible solution space. By showing where similar classes 

of solutions fall within the entire set, it allows one to see ‘and how certain solution features effect 

FOM performance and derive architecture ‘rules of thumb’. It also allows one to see the optimal 

solution boundary (the Pareto Front) and understand how one FOM can be exchanged for 

another. 

This approach provides insight into a potential limitation of the ‘Minimum 

Functionality/Minimum Implementation’ system architecting methodology [ref.6] which uses as 

its starting point a single-string non-redundant system architecture which lies somewhere in the 

interior of the solution trade space. The method involves performing one trade at a time to 

improve system safety until the mass margin is gone. It is not clear that this stepwise 

optimization of a single design can ever get to the boundary of optimal solutions (the Pareto 

Front). Even if it somehow did reach the optimal boundary it is not clear the system architects 

will have access to and be able to visualize the whole range of optimal solutions. System 

architects using the ‘Minimum Functionality/Minimum Implementation’ approach should at least 

be aware that the technique described in this report is available and they should consider using it 

to explore the entire system trade space and to provide some comparative outputs for cross-check 

their results. 

 

With some enhancements the systematic GN&C/Avionics “building block” OPN modeling 

techniques employed by the MIT/Draper Laboratory would serve as an excellent tool for 

evaluating competing GN&C system architectures for future NASA spacecraft. This OPN-based 

approach, or other similar modeling tools, would perform the extremely useful up-front function 

of identifying the most attractive (lowest weight and overall “cost”) GN&C architectural options 

that satisfy a prescribed set of spacecraft fault tolerance, reliability and performance 

requirements. Although less likely, but worth observing, is the fact that such “building block” 

models could be used to identify the optimal highest reliability/lowest weight architectural 

options for a prescribed number and configuration of connections between adjacent GN&C 

components. 

On-board GN&C flight software was, by design, not included in this GN&C system modeling 

and analysis study. Since there are potential for achieving flight software commonalty across 

multiple spacecraft this aspect of the system architecture should be considered in future work. 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

40 of 88

NESC Request No.:06-074-I 

8.0 Findings and NESC Recommendations 

8.1 Findings 

The following NESC/MIT/Draper Laboratory study team findings were identified: 

F-1. Most optimal architectures can be created by using the lowest reliability and lightest 

components. 

 The analysis of the identified optimal architectures show that it is possible to produce 

nearly all potentially optimal architectures using only the Type A light weight/lowreliability Sensors, Type A light weight/low-reliability computers, and generic 

connections. 

F-2. It is preferable to increase the redundancy of lighter, less reliable components rather than 

to use smaller numbers of more reliable, heavy components. 

F-3. There are diminishing returns to adding redundancy, connections, or components with 

greater reliability. 

 The system will experience only minimal increases in overall reliability for the large 

gains in system weight. 

F-4. For the optimal architectures in each scenario, the number of connections drops 

dramatically as the connection weight penalty is increased. 

F-5. The impact of the dissimilar components penalty is more subtle than that for connectors, 

but is still apparent. 

 Some architectures containing both Computer Type A and Computer Type B were 

identified as potentially optimal when the penalty = 0. However, when the penalty is 

increased to = 6, these architectures no longer appear to be better than other 

architectures. 

F-6. The OPN-based modeling approach employed required a time-consuming manual 

process for eliminating architectural duplicates. 

F-7. The OPN-based modeling approach employed was top-level only. 

F-8. In addition to the reliability metric, the existing OPN model could be modified to 

identify the optimal GN&C /Avionics architectural options for satisfying other driving 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

41 of 88

NESC Request No.:06-074-I 

system metrics, such as fault tolerance constraints, avionics power consumption, and/or 

attitude control performance. 

8.2 NESC Recommendations 

The following NESC recommendations were identified and directed to the ESMD 

Chief Engineer, the CxP Program System Engineering organization, and the Orion and Altair 

GN&C/Avionics Subsystem designers: 

R-1. Consider the fundamental findings of the NESC/MIT/Draper Laboratory study team to 

determine, given their reliability modeling assumptions, if the trends identified can be 

applied to architecting future CxP spacecraft GN&C/Avionics subsystems. 

(F-1, F-2, F-3, F-4, and F-5)

R-2. Com prehensively investigate, using the OPN-based model described in this report (or 

using similar GN&C/Avionics modeling tools and methods) both the pros and cons of 

incorporating dissimilar GN&C Sensor, Computer, and Actuator components in the 

GN&C architectures. Study how a small set of crew/flight safety critical GN&C 

functions can be synthesized/implemented in a backup manner with a limited 

complement of dissimilar hardware and software components. (F-5) 

R-3. Future work in on reliable GN&C should include the following enhancements of the 

GN&C/Avionics system modeling approach (F-6, F-7, F-8, and F-9): 

a) Improve the efficiency of the OPN model processing and its memory 

management. 

b) Incorporate provisions to model more than three Types of GN&C Sensors, 

Computers, and Actuators into the model. 

c) Include additional intrinsic descriptive details for each component beyond 

reliability and weight. 

d) Support expanded GN&C/Avionics architectural layouts in which the component 

redundancy for any component can be greater than three. For example the 

enhanced model should be capable of evaluating an architecture consisting of four 

Sensors, three Computers, and two Actuators. 

e) Automate the process for eliminating architectural duplicates and for creating 

rules. 

R-4. Future work on reliable GN&C should include the addition of the following metrics for 

higher-fidelity analysis and evaluation of GN&C/Avionics system architectural 

robustness, reliability, mass, power, volume, and performance (F-9): 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

42 of 88

NESC Request No.:06-074-I 

a) The fault tolerance requirements/rules for the specific spacecraft application being 

modeled. Metrics on the cost of any analytical redundancy (i.e., the redundancy 

management software) needed to detect and isolate faults should be provided for 

evaluation. 

b) The impact of common mode hardware failures. The metric could be either the 

incremental benefit of dissimilar redundancy or the incremental risk of similar 

redundancy. 

c) The values for Sensor, Computer, and Actuator component Mass, Volume, and 

Power (MVP). 

d) The 6-DOF spacecraft attitude and position control/knowledge performance 

metrics. 

9.0 Alternat e Viewpoints 

There were no alternate viewpoints or minority opinions expressed by the members of the 

NESC/MIT/Draper Laboratory study team. 

10.0 Other Deliverables 

There are no other deliverables at this time. 

11.0 Lessons Learned 

There were no lessons learned. 

12.0 Definition of Terms 

Corrective Actions Changes to design processes, work instructions, workmanship practices, 

training, inspections, tests, procedures, specifications, drawings, tools, 

equipment, facilities, resources, or material that result in preventing, 

minimizing, or limiting the potential for recurrence of a problem. 

Finding A conclusion based on facts established by the investigating authority. 

Lessons Learned Knowledge or understanding gained by experience. The experience may 

be positive, as in a successful test or mission, or negative, as in a mishap 

or failure. A lesson must be significant in that it has real or assumed 

impact on operations; valid in that it is factually and technically correct; 

and applicable in that it identifies a specific design, process, or decision 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

43 of 88

NESC Request No.:06-074-I 

that reduces or limits the potential for failures and mishaps, or reinforces a 

positive result. 

Observation A factor, event, or circumstance identified during the assessment that did 

not contribute to the problem, but if left uncorrected has the potential to 

cause a mishap, injury, or increase the severity should a mishap occur. 

Alternatively, an observation could be a positive acknowledgement of a 

Center/Program/Project/Organization’s operational structure, tools, and/or 

support provided. 

Problem The subject of the independent technical assessment/inspection. 

Proximate Cause The event(s) that occurred, including any condition(s) that existed 

immediately before the undesired outcome, directly resulted in its 

occurrence and, if eliminated or modified, would have prevented the 

undesired outcome. 

Recommendation An action identified by the assessment team to correct a root cause or 

deficiency identified during the investigation. The recommendations may 

be used by the responsible Center/Program/Project/Organization in the 

preparation of a corrective action plan. 

Root Cause One of multiple factors (events, conditions, or organizational factors) that 

contributed to or created the proximate cause and subsequent undesired 

outcome and, if eliminated or modified, would have prevented the 

undesired outcome. Typically, multiple root causes contribute to an 

undesired outcome. 

13.0 Acronyms List 

CaLV Cargo Launch Vehicle 

CE&R Concept Exploration and Refinement 

CEV Crew Exploration Vehicle 

CLV Crew Launch Vehicle 

Cx Constellation 

CxP Constellation Program 

DOF Degree of Freedom 

EDS Earth Departure Stage 

ESMD Exploration Systems Mission Directorate 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

44 of 88

NESC Request No.:06-074-I 

FOM Figure of Merit 

IMU Inertial Measurement Unit 

JSC Johnson Space Center 

LaRC Langley Research Center 

LSAM Lunar Surface Access Module 

MTBF Mean Time Between Failure 

MVP Mass, Volume and Power 

NESC NASA Engineering and Safety Center 

NRB NESC Review Board 

TDT Technical Disciple Team 

TIM Technical Interchange Meeting 

14.0 Ref erences 

1. Cameron, B., Crawley, E., Loureiro, G., and Rebentisch, E., “Value flow mapping: Using 

networks to inform stakeholder analysis” Acta Astronautica, Volume 62, Issues 4-5, 

February-March 2008. 

2. Dominguez-Garcia, A., Hanuschak, G., Hall, S., and Crawley, E., “A Comparison of GN&C 

Architectural Approaches for Robotic and Human-Rated Spacecraft” AIAA Guidance, 

Navigation and Control Conference and Exhibit, 20-23 Aug 2007, Hilton Head, SC. 

3. Hofstetter, W., Wooster, P., Nadir, W., and Crawley E., “Affordable Human Moon and 

Mars Exploration through Hardware Commonality” AIAA-2005-6757 Space 2005, Long 

Beach, California, Aug. 30-1, 2005. 

4. Sahner, R., Trivedi, K., and Puliafito, A. Performance and Reliability Analysis of Computer 

Systems: An Example-Based Approach Using the SHARPE Software Package, Kluwer 

Academic Publishers, 1995. 

5. Simmons, W., Koo, B., and Crawley, E., “Architecture Generation for Moon-Mars 

Exploration Using an Executable Meta-Language” AIAA-2005-6726 Space 2005, Long 

Beach, California, Aug. 30-1, 2005. 

6. Bay, Michael, Davis, Mitchell, and Putney, Blake, “Iterative Risk Driven Design Approach 

for CEV Avionics”, 7th Annual Space Systems Engineering & Risk Management 

Symposium, Los Angeles, CA, February 2008
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

45 of 88

NESC Request No.:06-074-I 

Volume II: Appendices

Appendix A. A Comparison of GN&C Architectural Approaches for Robotic and 

 Human-Rated Spacecraft (A copy of this report is available through AIAA)

Appendix B. A Comparison of Fault-Tolerant GN&C System Architectures Using the Object 

Process Network (OPN) Modeling Language 

Appendix C. NESC Stakeholder Outbrief
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

46 of 88

NESC Request No.:06-074-I 

Appendix A. A Comparison of GN&C Architectural Approaches for 

Robotic and Human-Rated Spacecraft 

(A copy of this report is available through AIAA)
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

47 of 88

NESC Request No.:06-074-I 

Appendix B. A Comparison of Fault-Tolerant GN&C System 

Architectures Using the Object Process Network (OPN) Modeling 

Language
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

48 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

49 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

50 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

51 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

52 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

53 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

54 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

55 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

56 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

57 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

58 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

59 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

60 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

61 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

62 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

63 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

64 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

65 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

66 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

67 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

68 of 88

NESC Request No.:06-074-I 

Appendix C. Study Summary Presentation 

All work was performed under NASA contracts:

NNG10CR13C and NNX07AE12A
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074

Version: 

1.0

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft

Page #: 

69 of 88

NESC Request No.:06-074-I 

All work was performed under NASA contracts:

NNG10CR13C and NNX07AE12A
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

70 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

71 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

72 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

73 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

74 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

75 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

76 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

77 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

78 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

79 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

80 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

81 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

82 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

83 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

84 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

85 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

86 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

87 of 88

NESC Request No.:06-074-I 
NASA Engineering and Safety Center 

Technical Assessment Report

Document #: 

NESC-RP06-074 

Version: 

1.0 

Title:

System Architectural Considerations on Reliable 

Guidance, Navigation, and Control (GN&C) for 

Constellation Program (CxP) Spacecraft 

Page #: 

88 of 88

NESC Request No.:06-074-I 
REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

2. REPORT TYPE 

Technical Memorandum

 4. TITLE AND SUBTITLE

System Architectural Considerations on Reliable Guidance, Navigation, 

and Control (GN&C) for Constellation Program (CxP) Spacecraft

5a. CONTRACT NUMBER

 6. AUTHOR(S)

Dennehy, Cornelius J.

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

NASA Langley Research Center

Hampton, VA 23681-2199

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

National Aeronautics and Space Administration

Washington, DC 20546-0001

 8. PERFORMING ORGANIZATION

 REPORT NUMBER

L-19904 NESC-RP-06-074

10. SPONSOR/MONITOR'S ACRONYM(S)

NASA

13. SUPPLEMENTARY NOTES

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified - Unlimited

Subject Category 16 - Space Transportation and Safety

Availability: NASA CASI (443) 757-5802

19a. NAME OF RESPONSIBLE PERSON

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

14. ABSTRACT

This final report summarizes the results of a comparative assessment of the fault tolerance and reliability of different 

Guidance, Navigation and Control (GN&C) architectural approaches. This study was proactively performed by a combined 

Massachusetts Institute of Technology (MIT) and Draper Laboratory team as a GN&C "Discipline-Advancing" activity 

sponsored by the NASA Engineering and Safety Center (NESC). This systematic comparative assessment of GN&C system 

architectural approaches was undertaken as a fundamental step towards understanding the opportunities for, and limitations of, 

architecting highly reliable and fault tolerant GN&C systems composed of common avionic components. The primary goal of 

this study was to obtain architectural 'rules of thumb' that could positively influence future designs in the direction of an 

optimized (i.e., most reliable and cost-efficient) GN&C system. A secondary goal was to demonstrate the application and the 

utility of a systematic modeling approach that maps the entire possible architecture solution space. 

15. SUBJECT TERMS

Avionics; Constellation Program; Crew Exploration Vehicle; Guidance, Navigation and Control

18. NUMBER

 OF 

 PAGES

93

19b. TELEPHONE NUMBER (Include area code)

(443) 757-5802

a. REPORT

U

c. THIS PAGE

U

b. ABSTRACT

U

17. LIMITATION OF 

 ABSTRACT

UU

Prescribed by ANSI Std. Z39.18

Standard Form 298 (Rev. 8-98)

3. DATES COVERED (From - To)

October 2006 - October 2009

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

869021.04.07.01.07

11. SPONSOR/MONITOR'S REPORT

 NUMBER(S)

NASA/TM-2010-216716

16. SECURITY CLASSIFICATION OF:

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- 07 - 2010