brian muirhead v1-27-12
DESCRIPTION
TRANSCRIPT
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?
2
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
3
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
4
Five Major SE Problem Areas
1. Mission complexity is growing faster than our ability to manage it
…increasing mission risk from inadequate definition & incomplete verification/validation
2. 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.
3. Technical and programmatic sides of projects are poorly coupled
…hampering effective project decision-making; increasing development risk.
4. Too much pressure on and attention to process at the expense of getting the design right
…driving costs up and increasing risk.
5. 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
5
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
ArchitectureArchitecture
Systems
EngineeringSystems
Engineering
Management
Management
6
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
7
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-based8
System Model as an Integration Framework
We now have a formal modeling language, SysML, to describe and analyze a system
System Model
Req’ts Allocation &Design Integration
Software ModelsHardware Models
Q
QSET
CLR
S
R
G(s)U(s)
Analysis Models Verification Models
Supports system requirements, design, analysis, V & V and operations activities through all phases
MBSE + integration standards/tools enable Integrated Model-Centric Engineering (IMCE) 9
Modeling Landscape
Level 1(program)
Level 2(project)
Level 3(system)
Level 4(subsystem)
Level 5(component)
ArchitectureArchitecture ScienceScience
EEIS EEIS
PayloadPayload
Ground SystemGround SystemFlight SystemFlight System
S/S V&VS/S V&V
CAD CAD CablingCabling
Flight S/WSMAP
Flight S/WSMAP
Component V&VComponent V&V
System V&VSystem V&V
S/S ModelsS/S Models
SE margins & analysis
SE margins & analysis …
…
…
Electrical SEElectrical SE
Model-centric engineering integrates models at multiple levels
OperationsOperations
10
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
12
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
Orbiter deployment diagram
13
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
Product breakdown is about part/whole
relationships
Work breakdown is about work package
responsibilities
Work breakdown is about work package
responsibilities
14
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
15
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
16
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)
17
RequirementsRequirements
Subsystem Design
Subsystem Design
Electrical System Design
Electrical System Design
Electrical Interface
Procedures
Electrical Interface
Procedures
Electrical Measurements
Electrical Measurements
Test results and DocumentationTest results and Documentation
Traceability report and ECR
impact generation
Traceability report and ECR
impact generation
Independent
DB
Independent
DB
Independent
DB
Independent
DB
Independent
DB
Independent
DB
Independent
DB
Cabling Design
Cabling Design
Independent
DB
Potential Manual Entry Error Points
11/11/2011 18
RequirementsRequirements
Subsystem Design
Subsystem Design
Electrical Measurements
Electrical Measurements
Test results and Documentation
s
Test results and Documentation
s
Traceability report and ECR
impact generation
Traceability report and ECR
impact generation
Electrical Interface
Procedures
Electrical Interface
Procedures
Cabling Design
Cabling Design
UNIFIED
Data Repository
Electrical System Design
Electrical System Design
11/11/2011 19MBSE Pilot on SMAP
20
Conceptual21
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
Diagram is notional – proper ontology patterns are not implemented
Notional Model of V&V test environment
Acts as an inventory diagram for the V&V parts list and functional purposes of GSE
Acts as an inventory diagram for the V&V parts list and functional purposes of GSE
23
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
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
24
Requirement Verification and TAYF Exceptions
I&T tests can be traced to requirement verification, as well as any test-as-you-fly 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 implemented25
Auto-generated Documents Developed DocGen “model” of Functional Description
Document (FDD)
Uses 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.
27
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
28