Introduction To Model-Based

System Engineering (MBSE) and

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

Laura E. Hart
Lockheed Martin, IS&GS
Laura.E.Hart@lmco.com
610-354-6529
Copyright 2015 Lockheed Martin Corporation ©
1
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

Vertical Integration
domains across life cycle
from SOS to component

• Results in quality/productivity
improvements & lower risk
MBSE
– Rigor and precision
– Communications among
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

11
Copyright © 2006 by Object Management Group.
System Modeling
Requirement Model

Functional / Behavioral Model Performance Model

Start Shift Accelerate Brake Control Input Power Vehicle
Equations Dynamics

System Model Mass

Properties
Auto
Model Structural
Model
Safety
Model
Cost
Engine Transmission Transaxle
Model

Structural / Component Model Other Engineering

Analysis Models from OMG

Integrated System Model Must Address Multiple Aspects of a System

12
Copyright © 2006 by Object Management Group.
Modeling Helps Produce
• 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

Plan
Test
U(s) G(s) Spec

Performance, RMA,
SWaP, Cost, etc. MBSE
Mechanical &
Manufacturing Software Models
Electrical Models

SET
S 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 verify a solution
relevant 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

.....
Analyze System Level Requirements Input SatComms

Forward Message from

Regional Command

Receive Order
Weapon System Weapon

Evaluate Engagement

Start Enagement

Fire Weapon

Monitor Weapon

[Status Change]
[Correction Needed]

Analyze System Services [No]

Weapon Intercept?

Terminate Engagement
Send Guidance Command

Correct Course

Forward Message to Send Status Change

Regional Cmd

Forward Message to
Regional Cmd

Identify the Subsystem

SatComms Weapon System Weapon

Forward Message from

Regional Command

Receive Order

Evaluate Engagement

Analyze Subsystem Collaboration to Satisfy [No]

Start Enagement

Monitor Weapon

[Status Change]
[Correction Needed]

Send Guidance Command

Fire Weapon

Weapon Intercept?

the System Services Forward Message to

Regional Cmd
Terminate Engagement

Send Status Change

Correct Course

Forward Message to
Regional Cmd

Incorporate Additional Trade Studies, R&D, UC

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
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

ModelCenter
expanded to help bridge SysML
to multidisciplinary analysis
through the release of the
ModelCenter MBSE Pak Do
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

30
Copyright © 2006 by Object Management Group.
 4 Pillars of SysML – ABS Example
sd ABS_ActivationSequence [Sequence Diagram]

stm TireTraction [State Diagram]

m1:Brake
Interaction
d1:Traction
Detector Modulator
LossOfTraction State
1. Structure detTrkLos()Gripping Slipping
Machine

Activity/
2. Behavior sendSignal() RegainTraction Function
modBrkFrc(traction_signal:boolean)

3. Requirements modBrkFrc()

definition use
sendAck()

4. Parametric

31
Copyright © 2006 -2008 by Object Management Group.
Block Definition and Usage
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 s1:Sensor
Electronic c2:sensor
Controller
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 = Σwi } {result=(w < 2k
Tonne)}
parameters parameters
wt:Tonne w:Tonne
wi:Tonne result: Boolean
par [Block] Ship Weight Analysis
«usage»
«usage» tw: TotalWeight wt w mw: MaxWeight
{wt = Σwi} {result = (w < 2k Tonne) }

result
result
w1 w2 w3

ship.weight cargo.weight ammo.weight

33
Cross-Connecting Model Elements
1. Structure 2. Behavior
ibd [block] Anti-LockController
Anti-LockController satisfies
satisfies
[Internal Block
Block Diagram]
Diagram] «requirement»
«requirement»
Anti-Lock
Anti-Lock
Performance
Performance
ibd [block] Anti-LockController
[Internal Block Diagram]
d1:TractionDetector
d1:TractionDetector
allocatedFrom
allocatedFrom
c1:modulator «activity»DetectLos
«activity»DetectLos
d1:Traction
c1:modulator
Interface OfTraction
Of Traction
Detector
Interface
c1:modulator
interface
m1:BrakeModulator
m1:BrakeModulator
m1:Brake
allocatedFrom
allocatedFrom Modulator
allocatedFrom
allocatedFrom
«ObjectNode»
«ObjectNode» «activity»Modulate
«activity»Modulate
TractionLoss: BrakingForce
BrakingForce

values
DutyCycle: Percentage

satisfy
req [package] VehicleSpecifications
[Requirements Diagram - Braking Requirements]
par
par [ constraintBlock ]] StraightLineVehicleDynamics [ [ Parametric Diagramm]
]
par [ constraintBlock ] StraightLineVehicleDynamics [ Parametric Diagram ]
Vehicle System Braking Subsystem v . chassis
Specification Specification tf: . tire
tl: . vbf. :brake . abs . m 1 . v . brake . rotor .m:
v . Weight :
Friction : DutyCycle : BrakingForce :

: BrakingForce f: : Acceleration
«requirement» «requirement»
Equation Equation
StoppingDistance Anti-LockPerformance
[f = ( tf*bf )*(tf1:- tl)] tl:
bf: F: [F = ma ] m:
id=“102” id=”337"
: BrakingForce f: a : : Acceleration
text=”The vehicle shall stop text=”Braking subsystem
Equation a: Equation
from 60 mph within 150 ft shall prevent wheel lockup 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
DistanceEquation : VelocityEquation
[v = dx /dt] v: [a = dv /dt]
«deriveReqt»
«deriveReqt»
x:

3. Requirements 4. Parametrics
v . Position :
34
Copyright © 2006 by Object Management Group.
c
Topics

• 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
Capture •Logical decomposition
•Vocabulary •Logical scenarios
Domain &
Assumptions
•Justification Models •Logical subsystems

•Node diagram
7. •HW, SW, Data arch
•Parametric Diag
Optimize & •System deployment
Evaluate •Trade study
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
Analysis Modeling
Plus, RPE
Integration Rhapsody
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
Laura.E.Hart@lmco.com
610-354-6529
43