Brian muirhead v1-27-12

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.

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?

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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)

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

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

Conceptual

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

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

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

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

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:

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.

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

Brian muirhead v1-27-12

by NASAPMC

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Brian muirhead v1-27-12 Presentation Transcript