Introduction to Model-Based System Engineering (MBSE) and Sysml

Home , Component (UML), Profile (UML), Systems architecture, Systems engineering

Introduction To Model-Based System Engineering (MBSE) and SysML

Presented at the Delaware Valley INCOSE Chapter Meeting July 30, 2015

Topics

• MBE/MBSE Terminology and Overview • SysML Overview • Object Oriented SE Methodology (OOSEM) • Modeling Tools and the Environment

2 Terminology • Model: – A simplified version of a concept, phenomenon, relationship, structure or system – A graphical, mathematical or physical representation – An abstraction of reality by eliminating unnecessary components – The objectives of a model include; • to facilitate understanding • to aid in decision making, examine 'what if' scenarios • to explain, control, and predict events

“Model-Based Engineering (MBE): An approach to engineering that uses models as an integral part of the technical baseline that includes the requirements, analysis, design, implementation, and verification of a capability, system, and/or product throughout the acquisition life cycle.”

Final Report, Model-Based Engineering Subcommittee, NDIA, Feb. 2011

3 Terminology

• MBSE: Model Based Systems Engineering – Those aspects of MBE specifically associated with SE – includes behavioral analysis, system architecture, requirement traceability, performance analysis, simulation, test, etc.

“Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.”

INCOSE SE Vision 2020 (INCOSE-TP-2004-004-02, Sep 2007)

4 MBSE Focus

• Formalizes the practice of Life Cycle Support systems development through the use of models

• Broad in scope

– Includes multiple modeling domains across life cycle from SOS to component

• Results in quality/productivity Integration

improvements & lower risk MBSE – Rigor and precision

– Communications among Vertical development team and customer – Management of complexity

5 Model-Based Engineering: What, Why and How?

• Digital models have been Document-Centric common in engineering since the late 1960s but today’s focus on Model-based Engineering goes beyond the use of disparate models

• Model-based Engineering moves the record of authority from documents to digital models including M-CAD, E- CAD, SysML and UML Model-Centric managed in a data rich environment

• Shifting to model-based enables engineering teams to more readily understand design change impacts, communicate design intent and analyze a system design before it is built

6 Model-Based Engineering: What, Why and How?

• Model-based Systems Engineering provides a Why Model??? mechanisms for driving more systems engineering depth without increasing costs

• Data-centric specifications enable automation and optimization, allowing SEs to focus on value added tasks and ensure a balanced approach is taken

• Unprecedented levels of systems understanding can be achieved through integrated analytics, tied to a model-centric technical baseline.

7 Detect Defects Earlier

Operational Analysis Operational Tests$$$$ Affordability Requirements Analysis = System Verification $ Detect Defects Early and Validation

System and Integration Test and Architecture Design Verification $$$

Detailed Design Unit Test

$$ Implementation Design, Build, and Test Components

8 Model-Based Engineering: What, Why and How?

• The key to a successful model- based approach is scoping the problem! • What do you want to get out of your models? • What fidelity do you need to accomplish those goals? • What are the success criteria for the effort?

• Scoping and managing a modeling effort is both an art and a science • Driving change in an organization takes time and continuous investment

9 Model Based Environment Characteristics

• Set of interconnected Models – Models are an abstraction of Reality – Structure, Behavior and Requirements • Standard Language – Graphical Notation, Syntax, Semantics – Visual focus – Static and Dynamic • Shared System Information Base

10 SE Practices for Describing Systems

Past • Specifications Future

• Interface requirements ATC Pilot Airplane

• System design Request to proceed Authorize • Analysis & Trade-off Initiate power-up Power-up Report Status

• Test plans Direct taxiway

Initiate Taxi

Executed cmds Document Centric Methodology Model (OOSEM) Centric

Language Tools (SysML) (Rhapsody)

Moving from Document centric to Model centric

Functional / Behavioral Model Performance Model

Start Shift Accelerate Brake Control Input Power Vehicle Equations Dynamics

System Model Mass Auto Properties Model Structural Model Safety Model Cost Engine Transmission Transaxle Model Structural / Component Model Other Engineering

Analysis Models from OMG

• Improved system and software – Specification – Visualization – Architecture – Construction – Simulation and Test – Documentation – Validation and Verification • Improved communications – Enhanced knowledge capture and transfer – Training Support • Improved design quality  Increased ability to manage System Complexity – Decreased ambiguity  Model can be viewed from multiple perspectives – Increased precision  Supports concurrent and distributive teams – Supports evaluation of Consistency,  Traceability Correctness & Completeness  Supports impact/change analysis – Supports evaluation of trade space  Complex development lifecycles 13  Incremental, iterative, parallel Stakeholders Involved in System Acquisition Developers/ Customers Integrators

Project Managers

Vendors

Regulators Testers

from OMG Modeling Needed to Improve Communications across all Stakeholders

14 Copyright © 2006 by Object Management Group. Information Base Characteristics Document Based MBSE Based Information - Mostly Text - Visual and Textual - Add Hoc Diagrams - Constructs Defined once and - Loosely coupled, re-used repeated in multiple - Shared across Domains documents - Consistent notation in diagrams - Defined relationships Information Views - By Document - Provides Viewpoints - Filters By Domain, Problem Space, etc. Measuring Change - Spans across Multiple - Relationships define Impact Documents traceability paths - Often Text Reqts. Are - Natural part of the modeling isolated from Structure process and Behavior - Programmatically Automated Measuring Integrity - - By manual inspection - Programmatically Automated Completeness, Quality - Animation of Spec & Accuracy

15 The MBSE Integration Across Domains

Program Product Support Management

System Architectural Model Verification Models

Analytical Models

Analysis

Spec

U( s) G( s)

Test Test  Plan

Performance, RMA, SWaP, Cost, etc. MBSE

Mechanical & Software Models Manufacturing Electrical Models

S SET Q

R CLR Q

16 System Architecture Models vs. Analytical Models System Architecture Model Analytic Model • Emphasize how pieces fit • Emphasize specific aspects of together into a consistent performance, consistent with whole the Architecture Model • Repository-based to support • Mathematically-based to capture of inter-relationships computation or simulation • Used to capture • Reduce risks thru analysis, – functions, behavior validation and optimization of: – structure, components, objects – MoM, MOE, MOP, KPP, TPM – info flow, interfaces, ports – timing, probability of hit/survival – Interactions, scenarios – reliability/availability, MTBF • A vehicle to “hang” & integrate – cost, total cost of ownership analysis products • A vehicle to solve some problem or Consistency: Faithful to all known and verifyrelevant a solution aspects of the system at the current time 17 System Model

System Model – A structured representation that focuses on the overall system requirements, behavior, structure, properties, & interconnections

• Requirements – What are the stakeholder goals, purposes, and success conditions for the system – Specification of black box behavior and characteristics • Behavior – What the system has to do to meet the requirements – Transformations of inputs to outputs (functional/activity models) – State/Mode-based behavioral differences (state models) – Responses to incoming requests for services (message models) • Structure – The parts that exhibit the behavior – The component hierarchy, elements, and stores • Properties – The performance, physical characteristics and governing rules that constrain the structure and behavior • Interconnections – The way the structural elements arrange and communicate to achieve the required behavior under the given constraints

18 120-18 System Decomposition Process using SysML UC

. . . . . SatComms Weapon System Weapon

Forward Message from Analyze System Level Requirements Input Regional Command

Receive Order

Evaluate Engagement

Start Enagement

Fire Weapon

Monitor Weapon

[Status Change] [Correction Needed]

[No] Send Guidance Command Analyze System Services Weapon Intercept?

Terminate Engagement Correct Course

Forward Message to Send Status Change Regional Cmd

Forward Message to Regional Cmd

Identify the Subsystem

Analyze Subsystem Collaboration to Satisfy the System Services

UC Incorporate Additional Trade Studies, R&D, Analysis as Needed Simulation, Specification Reviews, etc......

Derive and Allocate Requirements The Subsystem shall .... to Subsystem Derived Requirements Yes Continue? No Complete Subsystem Specs

19 Beyond Specifications: Integrated Systems Models

• Model-based Systems Engineering doesn’t end with the creation of specifications and ICDs

• A Systems Architecture Model provides a “hub” for data integration and transformation across the product lifecycle

• Specifically of note is the ability to link analysis through the systems model to provide insight into architectural and system level decisions

20 Model-based Engineering Baseline: An Integrated Data Set

21 Systems Understanding and Analytics through Model-based Architectures

• A critical task in Systems Engineering is the upfront trade and analysis process to ensure the best value system is developed to satisfy the mission need

• As missions become more complex, understanding all items that can impact the system performance becomes harder

• Integrating high fidelity analytics through a consistently defined systems architecture can help provide insight into key system characteristics not evident through traditional analysis alone

• Integrated tools allow engineers to analyze many more system configurations against mission scenarios, helping to identify key driving requirements and lowest cost alternatives for systems design

22 Expanding base of MBSE Tool Capabilities

Systems Engineering • The MBSE tools marketplace System Model (SysML) has been expanding beyond • Architecture • Behavior • Traceability just graphical modeling and • Requirements • Constraints • Specifications requirement tools with a focus on data and model integration • Execution requests • Performance Estimates • Trade-Study requests Bridge gap • Updated Design • Phoenix Integration • Requirement Verification ModelCenter ® has been expanded to help bridge SysML ModelCenter to multidisciplinary analysis through the release of the Do ModelCenter MBSE Pak Mechanical Electrical Manufacturing Software Cost Analysis Analysis Analysis Design Analysis • Validate Requirements • Sensitivity Analysis • Optimization • With MBSEPak, SysML • Verify Correctness • Risk Analysis • Visualization parametric models within Domain Level Engineering Rhapsody® or MagicDraw® can be executed, linking requirements to design to analysis and back

23 Architecture Centric Analytics

• A SysML Architecture can serve as a hub for integrated analytics, capturing analysis, analysis context, requirements and key architectural parameters

• Analysis context specifies the boundaries of the analysis, parametric views define the analysis to be performed and requirements diagrams can capture design goals, thresholds and driving requirements to bound the tradespace

• This model-centric approach provides a consistent, managed framework for analysis which often tends to be ad-hoc

24 Integrated Modeling and Analysis Support for Decision Makers

• Decision makers will have more information and options from which to draw conclusions

• Integrated analytics models will both increase the amount of information available to decision makes as well as help decision makers make sense of the information

• Tools to explore, visualize and understand a complex tradespace, rooted in MBSE can provide early insight into the impact of decisions ranging from technical solutions to complex public policies

Content Credit INCOSE Systems Engineering Vision 2025

25 Model-based Engineering: What, Why and How?

• The primary focus of most current industry efforts to move toward a Model-based Architecture Cost Performance Engineering approach focus on integrating data through models

• Engineering Is Responsible To Understand All Items That Could Electronics Impact A Design And Determine CAD Manufacturing A Resolution For Those Items – an integrated end-to-end modeling environment supports this role Software Verification • By bringing together varied but related models into a data rich, architecture centric environment, new levels of systems understanding can be achieved

• Model-based Systems Engineering forms a means to achieve integration

26 MBE Summary

• What? – Extends beyond Engineering – Covers the entire Life Cycle – Standards Based – Integrated Domains/Disciplines Data Environment – Doing the same SE Tasks – Environment for Automation and Validation • Why? – Customers want “Cheaper, Better, Faster” – Reduce Design Time – Improve Quality – Make Complex Systems Affordable

27 Topics

• MBE/MBSE Terminology and Overview • SysML Overview • Object Oriented SE Methodology (OOSEM) • Modeling Tools and the Environment

28 What is SysML?

• A graphical modelling language in response to the UML for Systems Engineering RFP developed by the OMG, INCOSE, and AP233 – a UML Profile that represents a subset of UML 2 with extensions

• Supports the specification, analysis, design, verification, and validation of systems that include hardware, software, data, personnel, procedures, and facilities

• Supports model and data interchange via XML Metadata Interchange (XMI®) and the evolving AP233 standard (in-process)

SysML is Critical Enabler for Model Driven SE

29 SysML Diagram Taxonomy

SysML Diagram

Behavior Requirement Structure Diagram Diagram Diagram

Activity Sequence State Machine Use Case Block Definition Internal Block Package Diagram Diagram Diagram Diagram Diagram Diagram Diagram

Same as UML 2 Parametric Diagram Modified from UML 2

New diagram type

sd ABS_ActivationSequence [Sequence Diagram]

stm TireTraction [State Diagram] Interaction d1:Traction m1:Brake Detector Modulator LossOfTraction State 1. Structure Machine detTrkLos()Gripping Slipping Activity/ 2. BehaviorsendSignal() RegainTraction Function modBrkFrc(traction_signal:boolean) 3. Requirements modBrkFrc() definition use sendAck() 4. Parametric

Block Definition Diagram Internal Block Diagram

bdd [package] VehicleStructure [ABS-Block Definition Diagram] ibd [block] Anti-LockController [Internal Block Diagram] «block» «block» Library:: Anti-Lock Electronic s1:Sensor Controller c2:sensor Processor Interface d1:Traction d1 m1 s1 Detector c1:modulator «block» «block» Interface «block» m1:Brake Traction Brake Sensor Detector Modulator Modulator

From OMG From OMG

Definition Usage – Block is a definition/type  Part is the usage in a particular – Captures properties, etc. context – Reused in multiple contexts  Typed by a block  Also known as a role

32 Parametrics -Constraint Definition and Usage bdd [package] WeightConstraints

«constraintblock» Ship Weight Analysis {result:Boolean}

«constraintblock» «constraintblock» TotalWeight MaxWeight {wt = Σw } {result=(w < 2k i Tonne)} parameters parameters wt:Tonne w:Tonne wi:Tonne result: Boolean par [Block] Ship Weight Analysis «usage» «usage» tw: TotalWeight wt w mw: MaxWeight {result = (w < 2k Tonne) } {wt = Σwi}

result result

w1 w2 w3 ship.weight cargo.weight ammo.weight 33 Cross-Connecting Model Elements 1. Structure 2. Behavior

ibdibd [[block]] Anti--LockController satisfies [[InternalInternal BlockBlock DiagramDiagram]] «requirement» Anti--LockLock Performance ibd [block] Anti-LockController [Internal Block Diagramd1::TractionDetector]

allocatedFrom c1:modulator c1::modulator «activity»DetectLosd1:Traction Interface OfTractionOf TractionDetector Interfacec1:modulator interface m1::BrakeModulatorm1:Brake Modulator allocatedFrom allocatedFrom «ObjectNode» «activity»Modulate«activity»Modulate TractionLoss:: BrakingForceBrakingForce

values DutyCycle: Percentage satisfy req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements] parpar [ constraintBlock ] ] StraightLineVehicleDynamics [ [ Parametric Diagramm] ] par [ constraintBlock ] StraightLineVehicleDynamics [ Parametric Diagram ] Vehicle System Braking Subsystem v . chassistf: . tiretl: . vbf . : brake . abs . m 1 . v . brake . rotor . m: Specification Specification Friction : DutyCycle : BrakingForce : v . Weight :

: BrakingForce f: : Acceleration «requirement» «requirement» Equation Equation StoppingDistance Anti-LockPerformance tf: tl: bf: m : [f = ( tf* bf )*(tf1 : - tl)] tl: bf: F : [F = ma ] m : idid=“102” idid=”337" text=”The vehicle shall stop text=”Braking subsystem : BrakingForce f: a : : Acceleration a : from 60 mph within 150 ft shall prevent wheel lockup Equation Equation F : on a clean dry surface.” under all braking conditions.” [f = ( tf* bf )*(1 - tl)] [ F = ma ] v : VerifiedBy SatisfiedBy : DistanceEquation : VelocityEquation a : «interaction»MinimumStopp «block»Anti-LockController [v = dx /dt ] v : [ a = dv /dt ] a : ingDistance «deriveReqt» x : v : : DistanceEquation : VelocityEquation [ v = dx /dt ] v : [ a = dv /dt ] «deriveReqt» x :

• MBE/MBSE Terminology and Overview • SysML Overview • Object Oriented SE Methodology (OOSEM) • Modeling Tools and the Environment

35 OOSEM Model-Based SE Methodology

• Traditional top-down Scenario driven SE approach using SysML to facilitate: – Capture and analysis of requirements and design information to specify complex systems – Integration with OO Software development, hardware development and test processes – Flexibility to accommodate changing requirements and design evolution • SE method that leverages object-oriented (OO) concepts such as: – Blocks, value properties and operations – Generalizations/Specialization – Encapsulation – Use cases • Uses OO concepts however applied differently for SE vs. SW

36 OOSEM Typical Systems Req’ts & Design Activities •IPT Setup •Model Setup Major SE Development Activities

•Causal analysis •Mission use cases/scenarios •Enterprise model

•System use cases/scenarios •Elaborated context •Req’ts diagram 6. •Domain Models •Logical decomposition Capture •Vocabulary Domain & •Logical scenarios •Justification Models Assumptions •Logical subsystems •Node diagram •HW, SW, Data arch 7. •Parametric Diag Optimize & •System deployment •Trade study Evaluate Alternatives 8. Reuse •Reusable Common Sub-activities Opportunity Asset Repository Analysis •COTS/GOTS 10. Validate & Verify •Test system 9. System •Test cases Trace Reqt •Req’ts diagram and •Tables Allocations 37 Topics

• MBE/MBSE Terminology and Overview • SysML Overview • Object Oriented SE Methodology (OOSEM) • Modeling Tools and the Environment

38 A modeling tool - Rhapsody Example

• The Architecture model in Rhapsody provides dynamic database in which to store system design information • A given model object, such as a block, maintains it’s characteristics throughout the model, on every diagram in which it appears • Rhapsody provides a consistent design model that is also tied to requirements • Rhapsody is one of many UML/SysML tools

39 Rhapsody View

Drawing Browser Window

40 Typical Tool Environment

Configuration SoS Modeling Management Req Mgmt Rhapsody ClearCase Gateway DOORS Document Generation System Reporter Modeling Analysis Plus, RPE Rhapsody Integration or Model Center DocGen

SW Design Reliability Cost Rhapsody Analysis Analysis

Performance Analysis

41 How to Transition & Sustain A Practice

Developing Self Drive Adoption Sufficiency is Through Key to Programs & Transitioning a Capture Pilots Practice Codify

Support Infuse

Offer Necessary Build A Base of Training & Practitioners, Provide “Reach- Infusing MBE into Lockheed Martin’s Experts & back” Support Engineering Culture Champions

42 Laura E. Hart Lockheed Martin, IS&GS [email protected] 610-354-6529 43