The document discusses applying Model-Based Systems Engineering (MBSE) to analyze trade studies for NASA's Space Communications and Navigation (SCaN) integrated network architecture. It provides an overview of MBSE and compares it to traditional document-based approaches. The document then details how MBSE was used to model existing network elements, potential architecture options, and operational scenarios to enable comparison and analysis. Products of the MBSE analysis included models of network element workflows and proposed integrated network control concepts. MBSE allowed more efficient evaluation of the complex SCaN system architecture alternatives than traditional documentation-based methods.
1. Role of MBSE in NASA’s Space Communications Networks
NASA Project Management (PM) Challenge 2012
February 22-23, 2012
Kul Bhasin, Bert Golden, Jessica Reinert, Patrick Barnes
Glenn Research Center
1
2. 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
4. 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
5. SCaN Current Networks
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.
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
Space Network (EBRE) - constellation
of geosynchronous relays (TDRSS)
and associated ground systems
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
NASA Integrated Services Network
(NISN) - not part of SCaN; provides
terrestrial connectivity
5
6. 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
7. 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
11. Model Based Systems Engineering
(MBSE) & Document Based Systems
Engineering: Overview
11
12. Introduction
In The Past
• 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
Today and In The Future
• 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
13. 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
15. 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
18. 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
19. Architecture Views
• Note: Each DoDAF view conveys a different
perspective of the architecture.
View examples: DOD Architecture Framework (DoDAF) 19
20. 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
22. 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
24. 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
28. Network Element Service Architectures
• All 3 network elements
have the same
components
• Internal functions and
where they are
performed differs across
network elements
28
34. SCaN Network Architecture Trade Studies
Option Service Management Network Control
INM-1
Functions
Common
Functions
Asset-specific
Integrated Network
INM-2 Common Common Management (INM) &
INM-3 Central Asset-specific Integrated Service
INM-4 Central Common
Execution (ISE)
INM-5 Central Central
• 20 different
Option
ISE-1
Description
Both processing and data delivery/ transfer at
architecture option
Ground Station Sites
ISE-2 Processing at ground station sites; data combinations were
delivery/transfer at the Integrated Network
ISE-3
Operations Center (INOC)
Both processing and data delivery/ transfer at
compared, contraste
ISE-4
the INOC
Both processing and data delivery/ transfer at
d and analyzed
the INOC
34
35. SCaN Network Architecture Trade Studies
(continued)
Network Control Network Control Integrated Network
Operations Software
NCO-1: Fully NCS-1: Common
Control
integrated network network control • Network Asset
control operations framework
NCO-2: Partially NCS-2: Common
Configuration & Control
integrated network network control and Network Asset
control operations interface
Monitoring
NCO-3: Asset- NCS-3: Central
specific network gateway • 6 architecture
control operations
combinations were
----- NCS-4: Network
element gateway compared, contrasted
and analyzed
35
36. 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
37. Integrated Network Control
Trade Studies Model
Landing Page and Model Hierarchy created to make navigation of model
easier for users and reviewers
37
38. 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
40. 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
56. 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
57. 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
59. References
1. A Practical Guide To SysML, Sandford Friedenthal, Alan Moore and Rick Steiner
2. “Model-Based Systems Engineering with SysML”, Seminar Notes, Cris Kobryn
3. “Survey of Model Based Systems Engineering (MBSE) Methodologies”, Jeff
Estefan, JPL
4. “Vitech: Insight Through Integration” – CORE 7.0, Presentation
59
Documents “As-Is” Networks in common terminology (Services, Functions, Elements)Provides introduction to existing Networks for those working on integration activities
Talk about the different trade studies that are completed and planned. How the SCaN Service Model is being broken apart to be studied.The SCaN Service Model consists of 3 different components, each component is made up of multiple different functions.
Patrick starts here
Traditional document based SE methodology would create countless documents and spreadsheets to detail the same information that MBSE can provide in a unified model.MBSE models are a clean and efficient visual solution for an SE problem. MBSE models are scalable and highly extensible. The models can be customized to provide further data analysis, such as cost estimation, while still maintaining the unified, single solution.
