Role of MBSE in NASA’s Space Communications Networks                      NASA Project Management (PM) Challenge 2012     ...
Outline• Space Communications and Navigation  (SCaN) Program: Introduction• Model Based Systems Engineering (MBSE) &  Docu...
Space Communications andNavigation (SCaN) Program:       Introduction                             3
Background• In 2006, NASA Administrator assigned roles and responsibilities for the Agency’s  space communications and tra...
SCaN Current Networks    The current NASA space communications architecture embraces three operational networks that    co...
NASA Level 0 Requirements               (Baselined on January 28, 2010)• SCaN shall develop a unified space communications...
Architectural Goal and Challenges•   Goal: To detail the high-level SCaN integrated network architecture, its    elements,...
Key Requirements, Mission Drivers, and Capabilities                   Flowdown                                            ...
SCaN Notional Integrated Communication              Architecture                                         9
SCaN Integrated Network  Service Architecture                          10
Model Based Systems Engineering(MBSE) & Document Based Systems     Engineering: Overview                                  ...
Introduction                In The Past•   The “push pins & yarn” approach•   Easily applied only to the project at    han...
Approaches To Systems Engineering2• Document Based1   – Characterized by       • The generation of text-based specificatio...
Document Based Approach2                           14
Approaches To Systems Engineering• Model Based Systems Engineering (MBSE)1  – The formalized application of modeling to su...
Model Based Approach2                        16
MBSE – Methodology3Architecture   LanguagesFrameworksProcesses      Tools                           17
Architecture Frameworks• DoDAF – Department of Defense Architecture  Framework (USA)• MoDAF – Ministry of Defense Architec...
Architecture Views• Note: Each DoDAF view conveys a different  perspective of the architecture.       View examples: DOD A...
Languages• SysML – System Modeling Language (Systems  Engineers)• UML2 – Unified Modeling Language 2  (Software Engineers)...
Tools (Typical)•   Magic Draw•   Rhapsody•   Enterprise Architect•   CORE•   DOORS•   CRADLE•   Artisan Studio            ...
Processes4• Harmony-SE: Designed to be tool neutral.  Elements of the process are supported by  Rhapsody.• RUP SE: Rationa...
Applying MBSE toSCaN Architecture                    23
SCaN “As-Is” Networks Operational Model • The SCaN Network Operational Model provides a simplified   abstraction of the SC...
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   whe...
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 ...
SCaN Network Architecture Trade Studies                (continued)Network Control      Network Control   Integrated Networ...
Integrated Network Control          Trade Study using MBSE• Upfront planning and infrastructure implemented to  make the m...
Integrated Network Control               Trade Studies ModelLanding Page and Model Hierarchy created to make navigation of...
Integrated Network Control Operations         Trade Studies Model                                                    • 201...
Adding documentation to modeled Tasks                                        39
MBSE Operations comparison                •   Three diagrams in model                    comparing the same               ...
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• MBS...
Acknowledgements• The SCaN Program System Engineering is  supported by numerous team members from:   –   Jet Propulsion La...
Reference Material                     58
References1.   A Practical Guide To SysML, Sandford Friedenthal, Alan Moore and Rick Steiner2.   “Model-Based Systems Engi...
SCaN Legend              60
Upcoming SlideShare
Loading in …5
×

Bhasin reinert barnes_golden

16,218 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
16,218
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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

    1. 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. 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
    3. 3. Space Communications andNavigation (SCaN) Program: Introduction 3
    4. 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. 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 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
    6. 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. 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
    8. 8. Key Requirements, Mission Drivers, and Capabilities Flowdown 8
    9. 9. SCaN Notional Integrated Communication Architecture 9
    10. 10. SCaN Integrated Network Service Architecture 10
    11. 11. Model Based Systems Engineering(MBSE) & Document Based Systems Engineering: Overview 11
    12. 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. 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
    14. 14. Document Based Approach2 14
    15. 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
    16. 16. Model Based Approach2 16
    17. 17. MBSE – Methodology3Architecture LanguagesFrameworksProcesses Tools 17
    18. 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. 19. Architecture Views• Note: Each DoDAF view conveys a different perspective of the architecture. View examples: DOD Architecture Framework (DoDAF) 19
    20. 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
    21. 21. Tools (Typical)• Magic Draw• Rhapsody• Enterprise Architect• CORE• DOORS• CRADLE• Artisan Studio 21
    22. 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
    23. 23. Applying MBSE toSCaN Architecture 23
    24. 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
    25. 25. Deep Space Network → Deep Space Element (DSE) 25
    26. 26. Space Network → Earth Based Relay Element (EBRE) 26
    27. 27. Near Earth Network → Near Earth Element (NEE) 27
    28. 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
    29. 29. SCaN “To-Be” Network 29
    30. 30. SCaN Network Standard Services 30
    31. 31. SCaN Service Model 31
    32. 32. SCaN Operational Scenarios 32
    33. 33. SCaN Network Architecture Trade Studies 33
    34. 34. 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
    35. 35. 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
    36. 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. 37. Integrated Network Control Trade Studies ModelLanding Page and Model Hierarchy created to make navigation of modeleasier for users and reviewers 37
    38. 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
    39. 39. Adding documentation to modeled Tasks 39
    40. 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
    41. 41. MBSE Products & Demonstration 41
    42. 42. DSE Operational Process Flow (2015) DSE Setup Activity Diagram 42
    43. 43. DSE Setup Activity (2015) 43
    44. 44. DSE Tracking & Teardown Activities (2015) 44
    45. 45. EBRE Operational Process Flow (2015) Insert Latest Version 45
    46. 46. EBRE Pre-Event & Event Activities (2015) 46
    47. 47. EBRE Post-Event Activities (2015) 47
    48. 48. TDRS Operational Process Flow (2015) 48
    49. 49. NEE Operational Process Flow (2015) Insert Latest Version 49
    50. 50. NEE Pre-Contact Activity (2015) 50
    51. 51. NEE Contact & Post-Contact Activities (2015) 51
    52. 52. NCO-1 Operational Process Flow 52
    53. 53. NCO Cross-Support DiagramsNCO-1NCO- 2/3 53
    54. 54. NCO-1 Anomaly Resolution Process 54
    55. 55. NCO-1 Workforce 55
    56. 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. 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
    58. 58. Reference Material 58
    59. 59. 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
    60. 60. SCaN Legend 60

    ×