• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Bhasin reinert barnes_golden

Bhasin reinert barnes_golden






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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.

Bhasin reinert barnes_golden Bhasin reinert barnes_golden Presentation Transcript

  • 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
  • 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 andNavigation (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 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 missionsSpace Network (EBRE) - constellation of geosynchronous relays (TDRSS) and associated ground systemsDeep Space Network (DSE) - ground stations spaced around the world providing continuous coverage of satellites from Earth Orbit (GEO) to the edge of our solar systemNASA Integrated Services Network (NISN) - not part of SCaN; provides terrestrial connectivity 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
  • 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
  • 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 – Methodology3Architecture LanguagesFrameworksProcesses 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 toSCaN 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 StudiesOption Service Management Network ControlINM-1 Functions Common Functions Asset-specific Integrated NetworkINM-2 Common Common Management (INM) &INM-3 Central Asset-specific Integrated ServiceINM-4 Central Common Execution (ISE)INM-5 Central Central • 20 different OptionISE-1 Description Both processing and data delivery/ transfer at architecture option Ground Station SitesISE-2 Processing at ground station sites; data combinations were delivery/transfer at the Integrated NetworkISE-3 Operations Center (INOC) Both processing and data delivery/ transfer at compared, contrasteISE-4 the INOC Both processing and data delivery/ transfer at d and analyzed the INOC 34
  • SCaN Network Architecture Trade Studies (continued)Network Control Network Control Integrated NetworkOperations SoftwareNCO-1: Fully NCS-1: Common Controlintegrated network network control • Network Assetcontrol operations frameworkNCO-2: Partially NCS-2: Common Configuration & Controlintegrated network network control and Network Assetcontrol operations interface MonitoringNCO-3: Asset- NCS-3: Centralspecific network gateway • 6 architecturecontrol operations combinations were ----- NCS-4: Network element gateway compared, contrasted and analyzed 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 ModelLanding Page and Model Hierarchy created to make navigation of modeleasier 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 DiagramsNCO-1NCO- 2/3 53
  • 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
  • References1. A Practical Guide To SysML, Sandford Friedenthal, Alan Moore and Rick Steiner2. “Model-Based Systems Engineering with SysML”, Seminar Notes, Cris Kobryn3. “Survey of Model Based Systems Engineering (MBSE) Methodologies”, Jeff Estefan, JPL4. “Vitech: Insight Through Integration” – CORE 7.0, Presentation 59
  • SCaN Legend 60