The document discusses systems engineering challenges and opportunities, including: 1) Growing mission complexity is exceeding our ability to manage risk, and system designs emerge from pieces rather than sound architectures, resulting in brittle systems. 2) Technical and programmatic sides of projects are poorly coupled, hampering decision making and increasing risk. 3) Too much focus on process comes at the expense of design quality, driving up costs and risk. The document proposes addressing these with model-based systems engineering, architecture frameworks, and integrating technical and programmatic considerations through architecture.

1. Systems Engineering, Architecting and Model Based SE Challenges and Opportunities Presentation to PM Challenge February 22, 2012 Brian Muirhead Chief Engineer Jet Propulsion Laboratory , California Institute of Technology © 2012 California Institute of Technology. Government sponsorship acknowledged.

2. Project Manager Questions about Systems Engineering Why the hell do I need 450 systems engineers at level 2? Isn’ t the systems engineering job done at PDR SE is all about process and I hate process “ How do we fix systems engineering?” What is systems engineering anyway?

3. What SE Can Do for a PM Get the architecture and the design right up front, where it counts Own the end-to-end technical design and its operation Manage the technical baseline and the technical resources Help manage the risks Help control costs On the spectrum of process-to-invention/entrepreneur, help use process where it applies and not where it doesn ’t

4. What a PM Can Do for SE Don’ t support what we know doesn’t work: Requirements define the design Document our way to success Process our way to success There are new approaches that can/will work better to enable SE to do the job you need but needs strong support from project leadership (and our institutions) Effective architecting at all levels Model-based systems engineering

5. Five Major SE Problem Areas Mission complexity is growing faster than our ability to manage it … increasing mission risk from inadequate definition & incomplete verification/validation System designs emerge from the pieces, not from a sound architecture … resulting in systems which are brittle, difficult to test, and complex and expensive to operate. Technical and programmatic sides of projects are poorly coupled … hampering effective project decision-making; increasing development risk. Too much pressure on and attention to process at the expense of getting the design right … driving costs up and increasing risk. Knowledge and investment are lost at project lifecycle phase boundaries and between projects … increasing development cost and risk, of late discovery of design problems, and limiting savings from commonality

6. What is Architecture?? Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment and the principles governing its design and evolution (IEEE Std 1471-2000) Links Systems Engineering & Management by balancing technical and programmatic considerations Architecture addresses why a system is the way it is and how this understanding of the system is to be sustained It underlies the designs ability to meet objectives/constraints and satisfy stakeholders A design is the embodiment of an architecture. Designs address what is to be built and how As systems become more complex the need for an effective architecting effort becomes essential Architectures are fractal: the nature of the problems and solutions are the same at any scale Architecture Systems Engineering Management

7. What Architecture Is Not!! Architecture is not opaque pictures, block diagrams, lists, or other schematic representations of the design Architecture is not a broad brush effort confined to early development Dictates what possibilities are allowed, while still remaining faithful to stable concepts selected to fulfill system objectives Architecture is not requirements Architecture provides the rationale for requirements Architecture is not fickle, or subject to routine refinement Architecture provides a stabilizing influence through its well-considered form, expectations, rules, and attention to fundamentals

8. Architecture Framework Tool (AFT) Captures architecture information without SysML learning curve Complements CDF, RMA by improving capture of the “why” Report output will form backbone of concept study report Inexpensive in-house development Django-based

9. System Model as an Integration Framework We now have a formal modeling language, SysML, to describe and analyze a system Supports system requirements, design, analysis, V & V and operations activities through all phases MBSE + integration standards/tools enable Integrated Model-Centric Engineering (IMCE) System Model Requirements Repository Req ’ts Allocation & Design Integration Software Models Hardware Models Q Q SET CLR S R  G ( s ) U ( s ) Analysis Models Verification Models

10. Modeling Landscape Level 1 (program) Level 2 (project) Level 3 (system) Level 4 (subsystem) Level 5 (component) Architecture Science EEIS Payload Ground System Flight System S/S V&V CAD Cabling Flight S/W SMAP Component V&V System V&V S/S Models SE margins & analysis … … … Electrical SE Model-centric engineering integrates models at multiple levels Operations

11. Sample of Pilot Activities Across Agency Project Architecture: EHM (JPL) Project Planning: TBD Project Control: TBD Requirements Mgnt: Morpheus (JSC) Functional/Performance Analysis: EHM (JPL) SLS (ARC), System Design: Misc. AES (JSC) Integration, V&V: MMSEV (JSC) Operations Habitat Demo (JSC) MOD (JSC) OFT-1 communications (JPL) Research & Technology: TBD Reviews - TBD Configuration & Data Management VMDB/PRACA Integration (ARC) Modeling Infrastructure: Model Intg & Std Testbed (GSFC) Digital Collaborative Envir. (KSC) IMCE (JPL) Samples of implementing and monitoring pilots that study, demonstrate and/or prove out activities in the NIMA Concept of Operations:

12. Mission Domain Top Level View, front door to lower level views

13. Flight System Deployment (AKA: System Block Diagram) Deployment: a specific arrangement of parts from the product list. The authoritative statement of the Flight System decomposition The Mass Equipment List and Margin Report are produced directly from the model underlying this diagram Waveguide assembly CDH electronics Power electronics Pyro & Propulsion Orbiter deployment diagram

14. Work Breakdown Subsystems are seldom delivered as integrated components Better understood as aggregations of convenience, in this case delivery responsibility Product breakdown is about part/whole relationships Work breakdown is about work package responsibilities

15. Equipment List and Mass Margin Collects products from FS Deployment, grouped by subsystem per WBS Produced directly from the model Enables completeness and correctness checks Used during recent cost validation analyses

16. Integrated Analysis Products in Flight System Deployment can be exercised analytically through their data production and/or processing modes as driven by mission scenarios Transitioning from Excel to symbolic computation models

17. Cost Models System model can be used to directly produce inputs for independent cost estimation Have done integration with: NICM, PRICE-H, SEER, CATE NICM being used internally as a design aid (can get early results within the model)

18. Requirements Subsystem Design Electrical System Design Electrical Interface Procedures Electrical Measurements Test results and Documentation Traceability report and ECR impact generation Cabling Design Potential Manual Entry Error Points 11/11/2011 Independent DB Independent DB Independent DB Independent DB Independent DB Independent DB Independent DB Independent DB

19. Requirements Subsystem Design Electrical Measurements Test results and Documentations Traceability report and ECR impact generation Electrical Interface Procedures Cabling Design Electrical System Design 11/11/2011 MBSE Pilot on SMAP UNIFIED Data Repository

21. Conceptual

22. V&V Pilot Model and Products Created SysML model-based simulations of the following items, and validated the models against flight hardware in a testbed, including: HW model, FSW sequence engines, bus controller Early validation of nominal behavior flow via simulations generated directly from the model Provide better visibility of V&V and support system issues during design Earlier discovery of possible errors and issues Validate requirements by running simulations generated by system model Identify and extract test procedures, requirements, and rationale from the nominal SMAP model Expressing system design in a rigorous way with multiple viewpoints makes the necessary V&V easier to define Map system test program activities to requirements and test-as-you-fly exceptions

23. Notional Model of V&V test environment Diagram is notional – proper ontology patterns are not implemented Acts as an inventory diagram for the V&V parts list and functional purposes of GSE

24. Integration and Test Models Mechanical View Data Flow View Each I&T test can be viewed through multiple filters to enable a full understanding of the test configuration Diagram is notional – proper ontology patterns are not implemented

25. Requirement Verification and TAYF Exceptions I&T tests can be traced to requirement verification, as well as any test-as-you-fly exceptions. Diagram is notional – proper ontology patterns are not implemented

26. Auto-generated Documents Developed DocGen “model” of Functional Description Document (FDD) U ses queries to get information from System Model and embed in FDD. DocGen Plugin for MD allows for fast compilation to DocBook standard representation, which is easily translated to PDF or HTML. Can produce very similar-looking product to current FDD; sample pages:

27. Education and Training NASA Symposium and Workshop on Model-Centric Engineering, January 24-26, 2012, NASA Jet Propulsion Laboratory First NASA symposium and workshop on model-centric engineering This first workshop will focus on MBSE and its connections to the other communities. Purpose: Survey state of practice of model-centric engineering across NASA, ESA, industry, academia, INCOSE (breadth, not depth) Showcase pilot activities that can benefit NASA, Share lessons learned and best practices Identify/address common model-centric issues and challenges Further understand and develop the business case for MBSE Identify investments needed in infrastructure and training Identify topics for coordination and collaboration Provide training in specific modeling techniques Audience: NASA’s MBSE community; NASA HQ and NESC; ESA members engaged in model-centric engineering; industry partners, academic researchers, INCOSE MBSE. Approximately 60-70 people.

28. Summary Value and use of architecting, as a core part of SE, is just starting to get traction within NASA but is an important tool in meeting agency goals Modeling is not new but tools and techniques for system-level modeling are new and are starting to be used in meaningful and powerful ways Can produce better formulation products, at lower cost with better potential for getting the design right and thereby controlling costs Can begin to bridge the information divide between project teams and reduce the need for voluminous requirements and documents Current work supported by NASA OCE and the individual initiatives across the agency is building a capability that will enable the adoption of MBSE to the advantage of projects Need a coordinated effort between engineering and project management of education and learning about architecting and MBSE to enable advancements to the benefit of both communities