This document describes the application of model-based systems engineering techniques to develop an architecture model of the end-to-end information system supporting the first unmanned test flight of NASA's Orion spacecraft (EFT-1). A NASA-led team used the SysML modeling language and MagicDraw tool to create a conceptual model capturing the system composition, interfaces, requirements, functions, and other characteristics. The model includes multiple viewpoints and views to communicate different aspects of the evolving architecture to stakeholders. The model-based approach provided benefits such as facilitating requirements analysis, identifying unknowns, and tracing impacts of changes. Key lessons learned from applying these techniques to the complex EFT-1 system-of-systems are also discussed.

1. 1
Model-Based System Engineering of the Orion Flight Test 1
End-to-End Information System
Thomas I. McVittie, Oleg V. Sindiy, and Kimberly A. Simpson
Jet Propulsion Laboratory, California Institute of Technology
4800 Oak Grove Drive
Pasadena, CA 91109
Abstract—Recent advances in modeling tools and techniques
show the promise of significantly improving our ability to
effectively apply systems engineering techniques to complex
system-of-systems architectures. In this paper we describe our
experience with the application of a model-based approach
(based on SysML) to the capture and analysis of the end-to-end
information systems supporting the first unmanned test flight
of the Orion Multi-Purpose Crew Exploration Vehicle. The
paper describes the EFT-1 mission, the approaches used to
define the underlying models, how the models are related, and
how viewpoints are used to address specific stakeholder
concerns. The paper also provides a brief summary of the
observed benefits of this approach as well as key lessons
learned.
TABLE OF CONTENTS
1. INTRODUCTION ........................................................... 1
2. BACKGROUND AND SCOPE.......................................... 2
3. MODEL-BASED SYSTEM ENGINEERING FOR SYSTEM-
OF-SYSTEMS ARCHITECTURE DESCRIPTION.............. 3
4. BENEFITS AND LESSONS LEARNED............................. 9
5. SUMMARY.................................................................. 10
ACKNOWLEDGMENT......................................................... 10
REFERENCES ..................................................................... 10
BIOGRAPHIES .................................................................... 11
1. INTRODUCTION
1
Exploration Flight Test 1 (EFT-1) (formerly Orion Flight
Test 1/OFT-1) has been proposed as the first unmanned
orbital test of the Orion Multi Purpose Crew Vehicle
(MPCV). The mission’s primary purpose is to gather flight
performance data concerning key aspects of the Orion’s
design including the testing of the spacecraft launch, orbital,
re-entry, descent, landing, and recovery systems and
activities. Supporting this test requires an intricate system-
of-systems (SoS) infrastructure to: (1) configure and test the
MPCV initial avionics prior to launch, (2) monitor mission
progress through multiple communication configurations, (3)
manage distribution of the flight test sensor data, and (4)
issue and control contingency commands to Orion in support
of potential anomalous mission events. Many existing and
new capabilities of a number of NASA, Lockheed Martin
(LM) and supporting commercial, civil, and military
1
978-1-4577-0557-1/12/$26.00 ©2012 IEEE
provided systems are being integrated into the core mission
support infrastructure. Understanding how these
components are integrated to deliver the required
capabilities, and how they interact with the Orion MPCV to
achieve the flight test objectives, requires the development of
an end-to-end information system (EEIS).
To support the development of the EFT-1 EEIS, the authors
and their collaborators are applying formal model-based
systems engineering (MBSE) techniques to better understand
the integrated flight and ground capabilities needed to ensure
that the resulting system will support the realization of the
mission objectives. The application of the MBSE
methodology allows for representing key aspects of the EEIS
with a rich set of views extracted from a common model-
based repository of the EFT-1 EEIS architecture description.
Each view serves as a representation of a whole system from
the perspective of a related set of concerns, and conforms to
a viewpoint, which is a specification of the conventions for
constructing and using a view [1]. For this application
problem, the selected viewpoints include capture of the
system-of-systems composition, data exchanges, interfaces,
requirements, functional allocations, connectivity and
communications topologies, and other stakeholder-driven
characteristics across a set of mission test and integration
configurations and operational phases. The overview of the
approach will show how linkages between the various
viewpoints in the model enable system engineering (SE)
activities such as requirements gap analysis, identification of
design-space unknowns and trades, and ability to trace how
changes to one part of the architecture impact other areas.
The description of the approach will also explain how it
leverages existing techniques—e.g., architecture description
standards, modeling languages, modeling tools—to
collectively apply MBSE for EFT-1 EEIS architecture
description; which in turn, enables enhanced stakeholder
communications and EEIS architecture development.
The body of this paper is divided into three sections. First,
the paper provides a brief overview of the Orion MPCV
Program and EFT-1 mission in context of EEIS design.
Then, it describes how the application of formal MBSE
techniques by a NASA-led system engineering team has
allowed us to effectively assemble, capture, assess, and
communicate the EEIS architecture as a space- and ground-

2. 2
based SoS, and its evolution, to the project’s numerous
management and engineering stakeholders. Lastly, it
summarizes key observed benefits and lessons learned.
2. BACKGROUND AND SCOPE
Orion MPCV Program and EFT-1 Mission Overview
Orion is being designed as an exploration vehicle for
carrying crew to space, providing emergency launch abort
capabilities, sustaining the crew during space travel, and
providing re-entry from deep space return velocities.
Specifically, the Orion MPCV Program is charged with
delivering a spacecraft capable of serving as the primary
crew vehicle for missions beyond low Earth orbit (BEO)—
such as, crewed missions to asteroids and Mars—and for
conducting in-space operations—e.g., rendezvous, extra-
vehicular activities—in conjunction with payloads delivered
by the Space Launch System (SLS) for missions BEO.
EFT-1 is a planned debut of the Orion spacecraft aboard an
Expendable Launch Vehicle (ELV) on an orbital flight test.
It is tentatively scheduled to launch aboard a Delta IV-Heavy
Launch Vehicle in early 2014. The test will be a jointly
operated between LM Space Systems and NASA Mission
Operations Directorate (MOD) with support from multiple
commercial, civil, and military entities. The mission
duration is expected to be approximately 5 hours, with a
trajectory that would deliver a one low Earth orbit, followed
by a powered maneuver that would place the spacecraft into
High-Apogee, High-energy re-entry. A splashdown in the
ocean, under a parachute system, is expected to be off the
southern tip of the Baja Peninsula, with capsule recovery by
a U.S. Navy well-deck ship, and subsequent de-servicing of
the MPCV by Astrotech Space Operations.
Scope of the System Engineering Task in Support of the
Development of the EFT-1 EEIS
In late 2010, a response to a high-level program Ground Data
System risk identified the need to augment the LM’s existing
and proposed Ground Data System (GDS) capabilities with
NASA provided capabilities needed to support EFT-1.
Resultantly, the scope of the MPCV Flight Test Management
Office’s (FTMO) system engineering activities were
expanded to include how the NASA-owned portion of the
ground data network and NASA-led portions of the
information system would integrate with the LM provided
GDS capabilities. The scope of the task includes the capture
of EEIS for all of the end-to-end test and integration
Figure 1 – Exploration Flight Test 1 High-Level Mission Overview of the Phased End-to-End Information System

3. 3
configurations and the operational mission phases—launch
through de-servicing, and post-mission analysis. For this
task, the NASA-led team chose to employ a MBSE approach
with the goal of using the resulting models and products to
assemble, represent, and effectively communicate the
progression of the evolving EFT-1 EEIS design among many
of the project’s stakeholders, and the added benefit of being
to extend the model to other MPCV program tests—e.g.,
Ascent-Abort 2. Figure 1 provides a pictorial high-level
overview of the notional EFT-1 mission in the context of the
EEIS’s core actors and information exchanges.
3. MODEL-BASED SYSTEM ENGINEERING FOR
SYSTEM-OF-SYSTEMS ARCHITECTURE
DESCRIPTION
The Design Team and Development of the SE Approach
The task was initiated using a small core SE team with broad
set of experiences relevant to the project. For example, the
team’s core competencies include: system engineering,
system-of-systems architecture modeling, GDS design and
deployment for robotic and human space exploration
missions, and design of system-of-systems in defense and
energy domains. Armed with this collective knowledge-
base, the team also leveraged, and improves upon, previous
NASA Constellation Program efforts in capturing the design
of the program-level Computing System Architecture
Description (CCSAD) via MBSE techniques [4]. Hence, this
section of the paper specifies how the NASA-led EFT-1 SE
team has directed the EEIS design efforts from a largely
distributed and disjoint paper- and presentation-based
approach to one using a formal model to centralize the
capture and analysis of the relevant and key characteristics of
the EFT-1 EEIS architecture.
The team’s work has centered on: (1) capturing the data
provided, in a variety of documents, presentations, and
verbal and electronic communications, by the distributed set
of stakeholders and system designers, (2) refining our
understanding via continuous in person and electronic
communications, and then (3) using this information to
populate the model of the EEIS architecture. The resulting
model provides an integrated end-to-end architecture
description which is employed to generate multiple
representations (i.e., views) that cater to the multitude of
evolving concerns of the program’s stakeholders. These
products allow the team to communicate to NASA
management and key NASA and LM stakeholders: system
level functionality, as per EFT-1 concept of operations; the
end-to-end test, integration, and operational configurations;
interface, functional, and design requirements; scope of the
system; and assumptions, clarifications, unknowns to be
resolved, and alternate options under considerations.
Selected Modeling Language, Tool, and Taxonomy for
Architecture Description
The technical details of the implemented MBSE approach
consist of employing the System Modeling Language
(SysML) [2] plug-in in the MagicDraw modeling tool [3] to
produce a conceptual model of the architecture description
based on the architecture description taxonomy from IEEE
1471 Standard [1], and selected viewpoints and views for the
specific application problem.
OMG’s SysML provides a general-purpose modeling
language for systems engineering applications, which
supports the specification, analysis, design, verification, and
validation of a broad range of complex systems. These
systems may include hardware, software, information,
processes, personnel, and facilities [2]. SysML was selected
over other languages because (1) it meets the project’s
modeling needs in using a proven standard for architecture
description representation, (2) is based on proven Unified
Modeling Language (UML) for object-oriented software
engineering, (3) its abundant use at JPL which provides
access to other practitioners, and (4) access to the developers
of the specification.
No Magic Inc.’s MagicDraw is a cross-platform visual
modeling tool with team collaboration support. The tool was
selected because it meet’s the project technical needs, but
also because (1) it has been adopted as an institutional tool at
JPL which includes institutional tool training, (2) the team
has access for support from other JPL practitioners, and (3)
the team has access to support from the tool’s vendor for
resolving any tool issues and satisfying requests for needed
tool functionality additions.
According to the IEEE 1471 Standard [1], an architecture is
the fundamental organization of a system embodied in its
components, their relationships to each other, and to the
environment, and the principles guiding its design and
evolution. Further, an architecture description provides a
collection of products employed to document an architecture.
Presentation of an architecture description is organized by a
set of custom views. Each view serves as a representation of
a whole system from the perspective of a related set of
concerns. Each view conforms to a viewpoint, which is a
specification of the conventions for constructing and using a
view. A viewpoint provides a pattern or template from
which to develop individual views by establishing the
purposes and audience for a view and the techniques for its
creation and analysis. In brief, each view delivers a look
through a specialized window into the system architecture
description which assists in answering some set of questions
relevant to the key stakeholders and their concerns.
Custom Viewpoints for, and Views into, the Modeled
Architecture Description for EFT-1 EEIS
The set of current viewpoints and views selected to
communicate the EEIS design for EFT-1 are illustrated in
Figure 2. In actuality there can be as many, or as few,
viewpoints and views as deemed necessary to satisfactorily
address the specified concerns of the customer stakeholders.
Based on the project stakeholder’s current concerns, and
aforementioned work in the Constellation Program, the team
selected to employ a hybrid set of customized viewpoints for

4. 4
structuring the representation of, and establishing views for
communicating, the captured architecture description data in
the model. The selected viewpoints represent a fairly
methodical decomposition of the application problem from
the highest level of data exchanges through the more detailed
technical architecture. The idea is that the products from the
architectural description in the model can be used to navigate
up and down the architecture stack—allowing the distributed
set of stakeholders to ask questions as they navigate through
the model.
The current viewpoints and views extracted from the
architecture description captured in the EFT-1 EEIS model
include:
High-level Mission Operations Viewpoint: provides a high-
level overview that defines the key nodes/systems of the
mission and how they interact over time. This view is based
on Operation View 1 (OV-1) defined in the DoDAF [6],
which recommends the use of a high level operation concept
graphic to offer a graphical and textual description of the
operational concept for the architecture under consideration.
Figure 1 is an example view of this viewpoint.
Mission Configurations and Phases Viewpoint: defines the
major testing/integration configurations, operational mission
phases, and the transitions between them. The configurations
and phases represent some fundamental change in the
architecture which alters one or more of the aspects—e.g.,
involved actors, connectivity, types of data flows, etc.—of
the architecture description required for the system. Figure 3
provides a generic example of defining these configurations
and phases using states and properties in UML’s State
Machine (stm) Diagrams. In the EFT-1 EEIS model, we
employed two views: one to capture the key end-to-tend
testing and integration configurations, and the other to
capture the on-pad through capsule de-servicing operations.
Composition Viewpoint: sets up the decomposition of the
system (in this case, a system-of-systems) by location,
owners, facilities, systems, hardware, including how this it
evolves over time. For example, Orion (in its various
development stages) is modeled as a shared/transient element
that is part of the different facilities as its developed, tested,
integrated, launched, operated, re-covered, and de-serviced
over time. The ability to associate various hardware and
software builds with each of these configurations and phases
provided an invaluable tool for reasoning about the System’s
capabilities during any given phase or even when specific
integration tests could be performed. SysML’s containment
tree structure and Block Definition Diagrams (bdd) provide a
natural means of establishing and displaying such
information, which is then re-used in other views; examples
of these are illustrated in Figure 5 and Figure 4 respectively.
What data goes
across which
connections?
Is there enough
bandwidth?
Interface
Requirements
Needlines
What data needs
to be exchanged?
Does it match the
requirements?
Mission
Configurations &
Phases
When do
configuration
changes occur?
OV-1
What is the high-
level mission?
Connectivity
How do the
systems need to
be connected?
Hybrid Comms
Protocol Stacks
How is data
packaged/routed?
Data Exchange
Functional
Allocations
Stakeholders &
Concerns
Principles
Constraints
Trades
Core SysML Models
What
interfaces
do we
need?
Communication
Functional
Allocations
Deployments
Composition
What are the pieces &
how can they be
combined?
Who is performing which
functions and when?
Figure 2 – A Sample of Selected Viewpoints and Views from the Model of the EFT-1 EEIS Architecture

5. 5
Figure 3 – Example UML State Machine Diagram for
Capturing Testing & Integration Configurations and
Operational Phases
Figure 4 – Example SysML Block Definition Diagram to
Establish the Evolving Composition of an SoS
Architecture
Figure 5 – Example Containment Tree Structure to Show
the Evolving Composition of an SoS Architecture
entity location is transient
another deployment of an entity

6. Needlines Viewpoint: defines the majo
information between the nodes during each
phase of the mission. This viewpoint i
DoDAF OV-2 [6], where a needline docum
or actual exchanges of resources. To repre
we employed SysML’s Internal Block
Diagrams which show the data exchan
between origin and destination nodes
nodes/networks)—e.g., TLM flow from ve
center—and also, the provider and user
GPS Constellation provides time and posi
for any flight or ground systems that wishe
key parameters of each needline exchange
security configuration, completeness re
captured in the underlying model and ca
applied to the needlines if desired. Figur
example Needline diagram. For simplici
view has only a few systems, data flow
shown; in reality, most EFT-1 configuration
many more participating systems and
exchanges and services—as can be inferred
Figure 6 – Example Use of the SysML I
Diagram for a Needline Vie
For EFT-1, we generated the initial Need
combination of historical sources (say wha
Shuttle) and data exchanges implied by the
of Operations (CONOPs).
Requirements: documentation of the re
requirements (e.g., IRDs) that drive the
architecture and which may be used to va
captured in the architecture description. In
done by capturing the requirements indiv
presenting them in a tabular form, as present
6
or exchanges of
h configuration or
is based on the
ments the required
esent these views,
Definition (ibd)
nge connections
(not the relay
ehicle to control
interfaces—e.g.,
tion data service
es to use it. The
e (say data rate,
quirements) are
an selectively be
re 6 provides an
ity, the example
ws, and services
ns or phases have
d required data
from Figure 1.
Internal Block
ew
lines based on a
at we needed for
e EFT-1 Concept
elevant interface
e design of the
alidate the design
the model, this is
vidually and then
ted in Table 1.
Table 1. Example Definition o
Generic MagicDra
System–System IRD ID
Spacecraft 1–Mission
Control Center
SC1-MCC.
Spacecraft 1-Mission
Control Center
SC1-MCC.
…
These requirements can be allocate
the model and depicted visually. F
set of interfaced requirements map
Figure 7. The mapping of the IRDs
the ability to detect and resolve inst
mismatch between the IRDs and th
i.e., concept of operations.
Figure 7 – Example Mapping of I
to a Needline V
Connectivity Viewpoint: defines h
nodes needed to support the need
various types of communications m
(such as NISN), or umbilical lin
connection allows us to associated
with connection during each pha
connections include data such as th
bit error rates, COMSEC config
symbol rate. Whereas network conn
rate, media type and number, redun
and end-point addressing schemes
example of a Network Connectivit
used to track various network conf
through operations to data analysis c
of Requirements in a
aw Table
D Description
1001
S/C 1 shall send
telemetry to MCC
1002
MCC shall receive
S/C 1 telemetry
ed to various elements in
For example, an example
pping is presented in the
s to the needlines gave us
tances where there was a
he project expectations—
Interface Requirements
View
how major facilities and
dlines are connected via
media such as: RF, WAN
nes. Stereotyping each
d key configuration data
ase. For example, RF
he frequency, modulation,
guration, and maximum
nections include max data
ndancy approach (if any),
. Figure 8 provides an
ty Viewpoint that can be
figurations: from testing
configurations.

7. Figure 8 – Example SysML IBD for C
Viewpoint
Hybrid Communications Viewpoint: show
flows from the needlines views are transp
connections in the Connectivity Views.
serves two important functions. First, it all
to reason about (or model) the reliability/a
communications path and the criticality o
exchanged on it. Second, it helps the
providers better understand their role in the m
Figure 9 – Example SysML IBD fo
Communication Viewpoin
7
Connectivity
ws how the data
ported across the
This viewpoint
ows stakeholders
availability of the
of the data being
communications
mission.
or Hybrid
nt
Data Exchange Functional Allocati
key operational functions associat
transmission, and distribution of da
send, receive, process, store, etc.) in
needline during each mission phase
10 illustrates an example viewpoint
Diagrams (act) can be used to show
swim-lanes and the activities boxe
level communication functions inv
between the various mission system
that the “Telemetry” link shown
Telemetry needline shown in Figure
to the underlying information con
parameters and the specific commu
be used. As part of the on-going wo
associated with specific har
configurations which in turn allow
software/hardware is implementin
called out by the needline.
Figure 10 – Example SysML Acti
Functional Allocation
Protocol Stacks Viewpoint: details t
and data exchange protocol stacks f
in enabling the flow of needlines th
viewpoint is based on the protoc
CCSDS’s Reference Architecture
(RASDS) Recommended Practice
project, we tailored the example
RASDS to include connections an
protocol stacks; an example of thi
Figure 11. Not only does this v
understand all of the protocols tha
gives us the information to refi
ion Viewpoint: identifies
ted with the processing,
ata (e.g., create, combine,
nvolved in realizing each
or configuration. Figure
t of how SysML Activity
systems in the headers of
es to represent the high-
volved in data exchanges
ms. It’s important to note
n in the figure is the
e 6, and as such is linked
ncerning the Telemetry’s
unications paths that will
ork, the activities are also
rdware and software
ws us to verify that the
g the specific IRDs as
ivity for Data Exchange
n Viewpoint
the major communication
for each system involved
hrough the network. The
col stacks advocated in
for Space Data Systems
document [6]. For our
viewpoint provided in
nd directionality in these
s viewpoint is shown in
viewpoint help us better
at are being used, but it
ne our communications

8. models to include the impact that the protoc
overhead have on the end-to-end flow of info
Figure 11 – Example SysML IBD for P
Viewpoint
Communication Functional Allocation Vie
the functional decomposition of the commu
(functions) by involved mission systems. E
Activity (act) diagrams to show this allocati
providing headers for ownership and ac
swim-lanes demonstrated the communic
allocated to those systems for the
configurations. An example of functional a
illustrated in Figure 12.
Figure 12 – Example SysML Activity D
Communication Functions Allocation
8
col behaviors and
formation.
Protocol Stack
ewpoint: details
unication services
Employed SysML
ion, with systems
ctivities in those
cation functions
various system
allocation view is
Diagrams for
n Viewpoint
The content in Figure 12 includes so
oriented functions presented in Fi
much more in-depth decompositio
would need to occur to navigate up
stack (e.g., Figure 11) from data
destinations through the evolving c
In actuality, these three figures pres
views of the same model data fo
Whereas Figure 10 is geared toward
oriented stakeholders, Figure 11 is
and networking-oriented stakehold
geared toward the communications-o
Comment Boxes: to help identify as
unknowns, and alternate options
place small comment boxes with
them to applicable elements on v
Assumption, C for Clarification, U f
Alternate Options.
The detailed descriptions of these a
form and are exported along with a
note, while initially we had all
directly on all of the diagrams, th
because it made many of the dia
visually. Thus, a more visually eleg
to identify all of the notes. Figure 1
how comments were displayed on
shows how the comments were
elaborated upon in tabular form; wh
comment IDs and descriptions,
associated model elements, applica
exported from the model.
Figure 13 – Example Placement o
IDs onto Diagram
ome of the data exchange
gure 10, but provides a
on of the functions that
p and down the protocol
origins to the respective
communication networks.
sent related, but different,
or different stakeholders.
d the concerns of the data-
geared toward protocol-
ders, and Figure 12 is
oriented stakeholders.
ssumptions, clarifications,
under consideration, we
unique IDs and connect
various diagrams: A for
for Unknown, and AO for
are maintained in tabular
all of the other views. Of
of the comments/notes
his presented a challenge
agrams too cumbersome
gant solution was created
3 provides an example of
n diagrams and Table 2
collectively tracked and
hile this table only shows
other properties—e.g.,
able views—can also be
of Reference Comment
m Views

9. 9
Table 2. Example Tabular Elaboration for Comments
ID Description
A01 Assumption is that TDRSS Comms Status updates
will be provided as they are currently for ISS
C01 GPS is an existing service that S/C1 would use
U01 Unknown whether all of the on-board cameras
will be sending imagery at the same time.
U-AO01 Unknown whether an entirely closed loop
command and control loop is needed for all
commands sent to the S/C. Alternatively, only
mission critical commands should trigger
command responses.
AO1 Alternatively, TDRSS could be supplemented by
NEN ground stations.
Legends and Information Boxes: Due to the sheer
complexity of the system being described and volume of
views created, the modeling team also created legends for the
different views that help distinguish properties such as
system ownership, type of network connection, status of
requirements, and so forth. Additionally, information boxes
on diagrams are also employed to show type of diagram,
view name, and any other number of properties needed that
help to convey the view—e.g., content owner, modeler, data
modified, scope of view, etc.
The views (diagrams and tables) are exported using a pre-
build Reporting Wizard in MagicDraw, which allows to
establish a project-specific template and then periodically
auto-export views for of as many or few viewpoints as
desired into PowerPoint presentation—the chosen
presentation media for communicating the latest architecture
description to all of the project stakeholders. This provides
the benefit of maintaining the EEIS architecture description
in a formal modeling tool, but communicating its products
via means readily available to the large and distributed
stakeholder community.
Last but not least, many other viewpoints and ensuing views
are possible. These can be implemented as evolving
concerns of the key project stakeholders drive a need for
them. For example, the system engineering team can
integrate additional details into the architecture to produce
views that capture detailed specifics designs in technical
domains (e.g., avionics decomposition), SoS-level trades,
parametrics (e.g., data volume, latency), explicit mapping of
stakeholders to their concerns and which views address their
needs, and so forth.
Forward Work
The MBSE approach described is still under development.
The activities of our SE task must evolve to accommodate
the changing needs of the project’s stakeholders. There are
many other things we would like to accomplish with this
approach in the future. For example, we would want to
expand the approach to include: automated analysis (e.g.,
requirements gap assessment, expected data flow rates
versus available network capabilities, etc.), generate project
gateway products (e.g., architecture description document,
test plans for verification and validation), ability to
interoperate with other tools/models, and so forth. We hope
to work with NASA’s and other MBSE communities to
adopt existing, and develop new, techniques as the various
needs arise.
4. BENEFITS AND LESSONS LEARNED
Lastly, this paper highlights the observed benefits and lesson
learned in adopting the model-based system engineering
approach for the application problem.
Benefits
Key observed benefits include:
Single source of truth – the model provided a single
authoritative source for technical information needed by both
management and technical teams. The information was
configuration managed by the model which ensured that all
teams were using the most up-to-date and approved
information. This greatly improved the integrity and
consistency of all of the team’s products (e.g., changes made
to the model were automatically updated in any views which
used that information).
Tailored products – the approach allowed us to rapidly
create new/changing viewpoints which were specifically
tailored to address new stakeholders and/or concerns. Since
the information was already in the model, we only needed to
focus on which pieces of the information we wanted to
extract and how it should be represented. This allowed us to
more effectively communicate the architecture to a broader
spectrum of managers, developers, testers, and external
organizations.
Shared understanding – the process of moving from a set of
uncoordinated documents and diagrams to an integrated
model resulted in the team having better shared
understanding of the overall system, and its scope, data and
behaviors. Previously teams were heavily siloed within their
technical or organizational areas, and were largely unaware
of how the changes they were making impacted other areas.
Similarly, the approach also encouraged us to be more
deliberate and clearly understand where we were talking in
only conceptual terms and where we were talking about
concrete instances. For example, in some of the original
diagrams, lines and boxes had no clear or consistent meaning
(in one diagram a box was a process, in another it was a
system, in still another it was an organization). The
modeling approach helped us clearly and consistently define
the key concepts of the design. In turn, this helped us gauge
the maturity of various portions of the design.
Expressive and Understandable – the model was very
effective in being able to model the mission’s complex data
and relationships. In addition to being able to produce
product that were of direct use to the team (views), the

10. 10
underlying models were also able to feed the data and
configurations directly to analysis and simulation.
Extensibility and reusability – While not directly observed,
we believe that many of the high-level and/or discipline-
specific models and viewpoints created for EFT-1 can either
be directly used or modified to support other space missions.
This should significantly reduce the cost of generating these
models and products for the next project, and opens the
potential for developing and using a common set of tools to
evaluate/simulate the behavior of these models. For
example, the EFT-1 model can serve as a starting point for
defining the EEIS for Ascent-Abort 2, and any other Orion
MPCV program missions.
Lessons Learned
In implementing this approach, we gathered a list of
technical-level lessons learned to help us improve our current
approach and also apply this type of an approach for
comparable design challenges in the future. To-date, some
of the key lessons have been:
• Understanding the stakeholders is essential to designing
and implementing a MBSE approach and having it
widely adopted by the program/project; in our
experience, if the stakeholders do not feel represented
by the architecture, then they will largely ignore it.
• The MBSE approach must provide concrete value to the
project rather than just different way of generating the
same material. It needs to be able to uncover or
represent things that would be otherwise difficult or
even impossible to understand. We are after the
moments of clarity-“Aha!” moments rather than the
moments of indifference.
• Teams will readily adopt the modeling approach if (and
only if) it: (1) directly helps them do their job – i.e., by
automatically generating products or analysis they need
and in a format that they can readily use; (2) they have
easy access to the tool and are suitably trained; and (3)
they have a responsive support community that can help
them quickly resolve issues and answer questions. If
any of these are missing, teams and individuals quickly
revert to their old siloed tools and approaches.
Management must (and ours did) watch for and correct
the symptoms of this behavior.
• Cross-pollinating with other MBSE teams provided a
great source of advice as well as insights on models that
were more robust. For example, we have leveraged
concepts from JPL’s Integrated Model-Centric
Engineering team, Modeling Early Adopters teams,
proposals to the NASA SE Council, and so forth.
• Finally, the first time around, using these techniques will
seem to be more expensive than the non-model based
approaches. However, we (and our project
management!) believe that additional cost and effort are
offset by the approach’s ability to more effectively
communicate the architecture to the various
stakeholders, and identify significant
issues/inconsistencies that need to be worked more
rapidly and earlier in the life cycle. We expect that the
approach will be even more productive as we begin to
adopt common models across projects, take advantage
of previously trained staff, and become more adept at
tailoring the tools and viewpoints.
5. SUMMARY
This paper outlined a model-based approach employed for
the system engineering of the end-to-end information system
for Orion MPCV Program’s Exploration Flight Test 1. It
provided an overview of the modeling language, tool,
taxonomy, and representations (i.e., viewpoints types and
example views) used to capture, represent, and communicate
the description of a system-of-systems architecture under
development. Specifically, the paper demonstrated how the
application of formal model-based system engineering
techniques has been invaluable to effectively communicate
the scope of, and perform effective system engineering for, a
spaced-based system-of-system architecture design among
the project’s management and numerous involved
organizations’ stakeholders.
ACKNOWLEDGMENT
This task was managed out of the Jet Propulsion Laboratory,
a division of the California Institute of Technology, under a
contract with the National Aeronautics and Space
Administration. The work was funded and performed under
the leadership, guidance, and support of the Orion MPCV
Flight Test Management Office (FTMO) manager, Donald
Reed of NASA’s Johnson Space Center.
REFERENCES
[1] ISO/IEC Standard for Systems and Software
Engineering - Recommended Practice for Architectural
Description of Software-Intensive Systems, ISO/IEC
42010 IEEE Standard 1471-2000, 1st
Ed., 15 July 2007.
[2] OMG Systems Modeling Language (SysML)
Specification, Object Management Group (OMG),
Version 1.2, 1 June 2010.
[3] MagicDraw, Software Package, Version 17, No Magic
Inc., Allen, TX, 2011.
[4] Constellation Program Computing Systems
Architecture Description Document, CxP 70078 Rev B,
August 12, 2010. [ITAR controlled, not available in
public domain].
[5] Estefan, J.A., Survey of Model-Based Systems
Engineering (MBSE) Methodologies, Rev. B, INCOSE
MBSE Initiative, 23 May 2008, p. 10.
[6] Department of Defense Architecture Framework
(DoDAF), U.S. Department of Defense, Version 2.02,
August 2010.

11. 11
[7] Reference Architecture for Space Data Systems
(RASDS) Recommended Practice, The Consultive
Committee for Space Data Systems (CCSDS),
Washington DC, USA, Issue 1, CCSDS 311.0-M-1,
September 2008.
BIOGRAPHIES
Dr. Thomas McVittie is a principal software
systems engineer at NASA’s Jet Propulsion
Laboratory where he specializes in the
engineering, design and implementation of
secure and reliable command and control
systems. He currently supports the end-to-end
information systems design for the upcoming Orion test
flights and the design of resilient and secure power grids for
the Los Angeles Department of Water and Power.
Previously, he was the Chief Architect for the Constellation
Program’s Software and Avionics Integration Office and
numerous Department of Defense projects. Dr. McVittie
earned a PhD in Electrical and Computer Engineering, and
a Master of Science in Computer Architecture from
University of California-Santa Barbara.
Dr. Oleg Sindiy is a software systems
architect in the Ground Systems Engineering
section at NASA’s Jet Propulsion Laboratory
and the co-architect and modeler of the end-
to-end information architecture description
for the Orion Multi-Purpose Crew Vehicle
Program. He is currently also supporting JPL’s Ground
System process modeling work and the trade space analyses
for NASA’s modernization of the Space Communications and
Navigation Network (SCaN) assets. Oleg Sindiy is a recent
PhD graduate from the School of Aeronautical and
Astronautical Engineering at Purdue University, where his
dissertation research focused on the “Model-Based System-
of-Systems Engineering for Space-Based Command, Control,
Communication, and Information Architecture Design.” He
earned a Master of Science degree in Aeronautical and
Astronautical Engineering from Purdue University and a
Bachelors of Science degree in Aerospace Engineering from
Embry-Riddle Aeronautical University-Prescott.
Kimberly Simpson is an assistant program
manager in the Mission Systems Concepts
section at NASA’s Jet Propulsion Laboratory
and the Orion Multi-Purpose Crew Vehicle
Program Network Integration lead. Over the
past six years, Ms. Simpson has held a variety of leadership
positions within Constellation Program and the current
human spaceflight program responsible for program
integration of end-to-end hardware and software data
systems. She has also held many diverse roles within various
technical sections and divisions performing system
engineering, ground software development, and spacecraft
integration and testing. She is the recipient of the Technical
Award for Excellence, Explorer and Ranger Awards, and
has received multiple NASA Certificates of Recognition for
her support to JPL flight projects. Ms. Simpson earned a
Bachelor of Science degree in Computer Science from
California State Polytechnic University-Pomona.