1

Role of MBSE in NASA’s Space Communications NetworksNASA Project Management (PM) Challenge 2012

February 22-23, 2012

Kul Bhasin, Bert Golden, Jessica Reinert, Patrick BarnesGlenn Research Center

Outline

• Space Communications and Navigation (SCaN) Program: Introduction

• Model Based Systems Engineering (MBSE) & Document Based Systems Engineering: Overview

• Applying MBSE to SCaN Architecture• MBSE Products & Demonstration• Summary

2

Space Communications and Navigation (SCaN) Program: Introduction

3

Background

• In 2006, NASA Administrator assigned roles and responsibilities for the Agency’s space communications and tracking assets to the SCaN Office.

• This mandate centralized the management of NASA’s space communications and navigation networks: the Near Earth Network (NEN), the Space Network (SN), and the Deep Space Network (DSN).

• In a September 2007 memo, the Associate Administrator described the concept of an integrated network architecture.

• The new SCaN integrated network architecture is intentionally capability-driven and will continue to evolve as NASA makes key decisions involving technological feasibility, mission communication needs, and funding .

• It also illustrates the progression and the planned transformation from the current configuration of loosely coupled networks into a single, unified, integrated network.

• This presentation summarizes the evolution of the integrated network architecture of NASA’s communication and navigation infrastructure.

4

SCaN Current Networks

Space Network (EBRE) - constellation of geosynchronous relays (TDRSS) and associated ground systems

The current NASA space communications architecture embraces three operational networks that collectively provide communications services to supported missions using space-based and ground-based assets.

NASA Integrated Services Network (NISN) - not part of SCaN; provides terrestrial connectivity

Deep Space Network (DSE) - ground stations spaced around the world providing continuous coverage of satellites from Earth Orbit (GEO) to the edge of our solar system

Near Earth Network (NEE) - NASA, commercial, and partner ground stations and integration systems providing space commun-ications and tracking services to orbital and suborbital missions

5

NASA Level 0 Requirements(Baselined on January 28, 2010)

• SCaN shall develop a unified space communications and navigation network infrastructure capable of meeting both robotic and human exploration mission needs.

• SCaN shall implement a networked communication and navigation infrastructure across space.

• SCaN’s infrastructure shall provide the highest data rates feasible for both robotic and human exploration missions.

• SCaN shall assure data communication protocols for Space Exploration missions are internationally interoperable.

• SCaN shall provide the end space communication and navigation infrastructure for Lunar and Mars surfaces.

• SCaN shall provide communication and navigation services to enable Lunar and Mars human missions.

• SCaN shall continue to meet its commitments to provide space communications and navigation services to existing and planned missions.

6

Architectural Goal and Challenges

• Goal: To detail the high-level SCaN integrated network architecture, its elements, architectural options, views, and evolution until 2025 in response to NASA’s key driving requirements and missions. The architecture is a framework for SCaN system evolution and will guide the development of program requirements and designs.

• Challenges:

– Forming an integrated network from three preexisting individual networks– Resource constraints– Addressing requirement-driven, capability-driven, and technology-driven

approaches simultaneously

– Interoperability with U.S. and foreign spacecraft and networks

– Uncertainty in timing and nature of future communications mission requirements

– Requirements for support of missions already in operation, as well as those to which support commitments have already been made

– Changes in high-level requirements and direction

7

Key Requirements, Mission Drivers, and Capabilities Flowdown

8

SCaN Notional Integrated Communication Architecture

9

SCaN Integrated Network Service Architecture

10

Model Based Systems Engineering (MBSE) & Document Based Systems Engineering:

Overview

11

IntroductionIn The Past

Today and In The Future

• The “push pins & yarn” approach• Easily applied only to the project at

hand• Data is published in a document

that is distributed to the team

• Output is the result of a simulation of a system model

• Model elements can be modified and reused for other projects

• Data is stored in a common repository accessible to the team

12

Approaches To Systems Engineering2

• Document Based1

– Characterized by • The generation of text-based specifications and design documents, in hardcopy or electronic

file format, that are then exchanged between customers, users, developers and testers• System requirements and design information are expressed in these documents and drawings• Emphasis is placed on controlling the documentation and ensuring it is valid, complete, and

consistent and that the developed system complies with the documentation

– Limitations• Because the information is spread across multiple documents, the completeness, consistency

and relationships among requirements, design, engineering analysis, and test information can be difficult to assess.

• Also difficult to understand the a particular aspect of the system to perform traceability and change impact assessments

• Difficult to maintain or reuse the system requirements and design information for a an evolving design

• Progress based on documentation status that may not be adequately reflect the system requirements and the design quality

13

Document Based Approach2

14

Approaches To Systems Engineering

• Model Based Systems Engineering (MBSE)1

– The formalized application of modeling to support (beginning in conceptual design and continuing):• System Requirements• Design• Analysis• Verification• Validation

– Limitations:• Upfront investment required in:

– Tools– Training

• Transition period where both existing document based practices must be supported in addition to new MBSE processes

15

Model Based Approach2

16

MBSE – Methodology3

Architecture Frameworks

Languages

Processes Tools

17

Architecture Frameworks

• DoDAF – Department of Defense Architecture Framework (USA)

• MoDAF – Ministry of Defense Architecture Framework (U.K.)

• DNDAF – Department of National Defense Architecture Framework (Canada)

• NAF – NATO Architecture Framework (NATO) • UPDM – Unified Profile for DoDAF/MoDAF (USA/U.K.)• TOGAF – The Open Group Architecture Framework

(commercial)

18

Architecture Views

• Note: Each DoDAF view conveys a different perspective of the architecture.

View examples: DOD Architecture Framework (DoDAF) 19

Languages

• SysML – System Modeling Language (Systems Engineers)

• UML2 – Unified Modeling Language 2 (Software Engineers)

• AADL – Architecture Analysis and Design Language (Society of Automotive Engineers)

• BPMN/UML – Business Process Modeling Notation/Unified Modeling Language (Business Analysts)

20

Tools (Typical)

• Magic Draw• Rhapsody• Enterprise Architect• CORE• DOORS• CRADLE• Artisan Studio

21

Processes4

• Harmony-SE: Designed to be tool neutral. Elements of the process are supported by Rhapsody.

• RUP SE: Rational Unified Process for Systems Engineering, primarily used to support software development projects.

• OpenUP: Open Unified Process, RUP is a refinement of OpenUP.

• OOSEM: Object-Oriented Systems Engineering Method, an integrated top down approach that uses OMG SysML.

22

Applying MBSE to SCaN Architecture

23

SCaN “As-Is” Networks Operational Model

• The SCaN Network Operational Model provides a simplified abstraction of the SCaN network elements

• Provides introduction to existing Networks for those working on integration activities – Facilitates understanding of diverse and complex network elements– Compartmentalizes for ease of comparison and contrast

• Documents “As-Is” Networks in common terminology (Services, Functions, Elements)

• SCaN Network program documentation refers to the Networks as “Elements”– Deep Space Network → Deep Space Element– Near Earth Network → Near Earth Element– Space Network → Earth Based Relay Element

24

Deep Space Network → Deep Space Element (DSE)

25

Space Network → Earth Based Relay Element (EBRE)

26

Near Earth Network → Near Earth Element (NEE)

27

Network Element Service Architectures

• All 3 network elements have the same components

• Internal functions and where they are performed differs across network elements

28

SCaN “To-Be” Network

29

SCaN Network Standard Services

30

SCaN Service Model

31

SCaN Operational Scenarios

32

SCaN Network Architecture Trade Studies

33

SCaN Network Architecture Trade Studies

Integrated Network Management (INM) & Integrated Service Execution (ISE)• 20 different

architecture option combinations were compared, contrasted and analyzed

Option DescriptionISE-1 Both processing and data delivery/ transfer at

Ground Station SitesISE-2 Processing at ground station sites; data

delivery/transfer at the Integrated Network Operations Center (INOC)

ISE-3 Both processing and data delivery/ transfer at the INOC

ISE-4 Both processing and data delivery/ transfer at the INOC

Option Service Management Functions

Network Control Functions

INM-1 Common Asset-specific

INM-2 Common Common

INM-3 Central Asset-specific

INM-4 Central Common

INM-5 Central Central

34

SCaN Network Architecture Trade Studies (continued)

Integrated Network Control• Network Asset

Configuration & Control and Network Asset Monitoring

• 6 architecture combinations were compared, contrasted and analyzed

Network Control Operations

Network Control Software

NCO-1: Fully integrated network control operations

NCS-1: Common network control framework

NCO-2: Partially integrated network control operations

NCS-2: Common network control interface

NCO-3: Asset-specific network control operations

NCS-3: Central gateway

----- NCS-4: Network element gateway

35

Integrated Network Control Trade Study using MBSE

• Upfront planning and infrastructure implemented to make the model more usable by System Engineers, Subject Matter Experts and reviewers

• Network element software and operations modeled individually• Documentation for a particular software component or

operation task was stored in the model• Comparison, contrasting and analysis of 2015 network elements • Creation of “To-Be” architecture option models• Comparison, contrasting and analysis of “To-Be” architecture

options

36

Integrated Network Control Trade Studies Model

Landing Page and Model Hierarchy created to make navigation of model easier for users and reviewers

37

Integrated Network Control Operations Trade Studies Model

• 2015 Architecture for all Networks (DSN, NEN, SN)– GRC:

documented Operational Process flows

– JPL: documented Systems Architecture

Network Control Operations Process Flow examples 38

Adding documentation to modeled Tasks

39

MBSE Operations comparison

• Three diagrams in model comparing the same timeframe for each network

• All information contained in the model itself• Tasks contain definitions

and further description• Hyperlinks used to link

tasks across models• Further analysis can be

achieved through modeling• Cost analysis, complexity

comparison, quick link to deeper levels of software/system

40

MBSE Products & Demonstration

41

DSE Operational Process Flow (2015)

DSE Setup Activity Diagram

42

DSE Setup Activity (2015)

43

DSE Tracking & Teardown Activities (2015)

44

EBRE Operational Process Flow (2015)

Insert Latest Version

45

EBRE Pre-Event & Event Activities (2015)

46

EBRE Post-Event Activities (2015)

47

TDRS Operational Process Flow (2015)

48

NEE Operational Process Flow (2015)

Insert Latest Version

49

NEE Pre-Contact Activity (2015)

50

NEE Contact & Post-Contact Activities (2015)

51

NCO-1 Operational Process Flow

52

NCO Cross-Support Diagrams

53

NCO-1

NCO- 2/3

NCO-1 Anomaly Resolution Process

54

NCO-1 Workforce

55

Summary

• System Engineers must understand the complexity of the systems to be modeled before MBSE can be implemented

• MBSE allowed the trade study teams to compare, contrast and analyze multiple complex different architecture options– 2015 Network Elements– Future Architecture Options

• MBSE models have the capability to model infinite levels of software/operational complexity while linking each level to the one above and below

• Centralized information (diagrams, definitions) and common terminology made trade study efforts significantly more efficient

• MBSE has value when modeling complex systems, the magnitude of that value will be better understood when SCaN Architecture trade studies are concluded

56

Acknowledgements

• The SCaN Program System Engineering is supported by numerous team members from:– Jet Propulsion Laboratory– Goddard Space Flight Center– Glenn Research Center– NASA Headquarters

• This team would like to give special thanks to:– SCaN Integrated Network Architecture Teams– SCaN Architecture & Requirements Team– SCaN Network Subject Matter Experts

57

Reference Material

58

References

1. A Practical Guide To SysML, Sandford Friedenthal, Alan Moore and Rick Steiner2. “Model-Based Systems Engineering with SysML”, Seminar Notes, Cris Kobryn 3. “Survey of Model Based Systems Engineering (MBSE) Methodologies”, Jeff

Estefan, JPL4. “Vitech: Insight Through Integration” – CORE 7.0, Presentation

59

SCaN Legend

60