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. INTRODUCTION1 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 1978-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

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

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

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 goesacross 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 ExchangeFunctional Allocations

Stakeholders & Concerns

PrinciplesConstraints

Trades

Core SysML Models

What interfaces

do we need?

CommunicationFunctional 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

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

Needlines Viewpoint: defines the majoinformation between the nodes during eachphase of the mission. This viewpoint iDoDAF OV-2 [6], where a needline documor actual exchanges of resources. To reprewe employed SysML’s Internal Block Diagrams which show the data exchanbetween origin and destination nodes nodes/networks)—e.g., TLM flow from vecenter—and also, the provider and user GPS Constellation provides time and posifor any flight or ground systems that wishekey parameters of each needline exchangesecurity configuration, completeness recaptured in the underlying model and caapplied to the needlines if desired. Figurexample Needline diagram. For simpliciview has only a few systems, data flowshown; in reality, most EFT-1 configurationmany more participating systems andexchanges and services—as can be inferred

Figure 6 – Example Use of the SysML IDiagram for a Needline Vie

For EFT-1, we generated the initial Needcombination of historical sources (say whaShuttle) and data exchanges implied by theof Operations (CONOPs).

Requirements: documentation of the rerequirements (e.g., IRDs) that drive thearchitecture and which may be used to vacaptured in the architecture description. In done by capturing the requirements indivpresenting 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 oGeneric MagicDra

System–System IRD IDSpacecraft 1–Mission Control Center SC1-MCC.

Spacecraft 1-Mission Control Center SC1-MCC.

…

These requirements can be allocatethe model and depicted visually. Fset of interfaced requirements mapFigure 7. The mapping of the IRDsthe ability to detect and resolve instmismatch between the IRDs and thi.e., concept of operations.

Figure 7 – Example Mapping of Ito a Needline V

Connectivity Viewpoint: defines hnodes needed to support the needvarious types of communications m(such as NISN), or umbilical linconnection allows us to associatedwith connection during each phaconnections include data such as thbit error rates, COMSEC configsymbol rate. Whereas network connrate, media type and number, redunand end-point addressing schemesexample of a Network Connectivitused to track various network confthrough 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.

Figure 8 – Example SysML IBD for CViewpoint

Hybrid Communications Viewpoint: showflows from the needlines views are transpconnections in the Connectivity Views. serves two important functions. First, it allto reason about (or model) the reliability/acommunications path and the criticality oexchanged on it. Second, it helps the providers better understand their role in the m

Figure 9 – Example SysML IBD foCommunication 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 Allocatikey operational functions associattransmission, and distribution of dasend, receive, process, store, etc.) inneedline during each mission phase 10 illustrates an example viewpointDiagrams (act) can be used to show swim-lanes and the activities boxelevel communication functions invbetween the various mission systemthat the “Telemetry” link shownTelemetry needline shown in Figureto the underlying information conparameters and the specific commube used. As part of the on-going woassociated with specific harconfigurations which in turn allowsoftware/hardware is implementincalled out by the needline.

Figure 10 – Example SysML ActiFunctional Allocation

Protocol Stacks Viewpoint: details tand data exchange protocol stacks fin enabling the flow of needlines thviewpoint is based on the protocCCSDS’s Reference Architecture (RASDS) Recommended Practice project, we tailored the example RASDS to include connections anprotocol stacks; an example of thiFigure 11. Not only does this vunderstand all of the protocols thagives 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

models to include the impact that the protocoverhead have on the end-to-end flow of info

Figure 11 – Example SysML IBD for PViewpoint

Communication Functional Allocation Viethe functional decomposition of the commu(functions) by involved mission systems. EActivity (act) diagrams to show this allocatiproviding headers for ownership and acswim-lanes demonstrated the communicallocated to those systems for the configurations. An example of functional aillustrated in Figure 12.

Figure 12 – Example SysML Activity DCommunication 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 sooriented functions presented in Fimuch more in-depth decompositiowould need to occur to navigate upstack (e.g., Figure 11) from data destinations through the evolving cIn actuality, these three figures presviews of the same model data foWhereas Figure 10 is geared towardoriented stakeholders, Figure 11 is and networking-oriented stakeholdgeared toward the communications-o

Comment Boxes: to help identify asunknowns, and alternate options place small comment boxes with them to applicable elements on vAssumption, C for Clarification, U fAlternate Options.

The detailed descriptions of these aform and are exported along with anote, while initially we had all directly on all of the diagrams, thbecause it made many of the diavisually. Thus, a more visually elegto identify all of the notes. Figure 1how comments were displayed onshows how the comments were elaborated upon in tabular form; whcomment IDs and descriptions, associated model elements, applicaexported from the model.

Figure 13 – Example Placement oIDs 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

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

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

[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.