OMG Systems Modeling Language

(OMG SysML™)
Tutorial

19 June 2008

Sanford Friedenthal
Alan Moore
Rick Steiner
(emails included in references at end)

Copyright © 2006-2008 by Object Management Group.

Published and used by INCOSE and affiliated societies with permission.
 OMG SysML™ Specification

• Specification status
– Adopted by OMG in May ’06
– Available Specification v1.0 in Sept ‘07
– Revision task force for v1.1 in July ‘07

• This tutorial is based on the OMG SysML available

specification (formal/2007-09-01)

• This tutorial, the specifications, papers, and vendor info

can be found on the OMG SysML Website at
http://www.omgsysml.org/

4/15/2008 Copyright © 2006-2008 by Object Management Group. 2

 Objectives & Intended Audience
At the end of this tutorial, you should have an awareness of:
• Motivation of model-based systems engineering approach
• SysML diagrams and language concepts
• How to apply SysML as part of a model based SE process
• Basic considerations for transitioning to SysML

This course is not intended to make you a systems modeler!

You must use the language.

Intended Audience:
• Practicing Systems Engineers interested in system modeling
• Software Engineers who want to better understand how to
integrate software and system models
• Familiarity with UML is not required, but it helps

4/15/2008 Copyright © 2006-2008 by Object Management Group. 3

 Topics

• Motivation & Background

• Diagram Overview and Language Concepts
• SysML Modeling as Part of SE Process
– Structured Analysis – Distiller Example
– OOSEM – Enhanced Security System Example
• SysML in a Standards Framework
• Transitioning to SysML
• Summary

4/15/2008 Copyright © 2006-2008 by Object Management Group. 4

Motivation & Background
 SE Practices for Describing Systems
Past Future
• Specifications

• Interface
requirements

• System design

• Analysis & Trade-off

• Test plans

Moving from Document centric to Model centric

4/15/2008 Copyright © 2006-2008 by Object Management Group. 6
 System Modeling
Requirements

Start Shift Accelerate Brake Control Power Vehicle

Input Equations Dynamics

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

Integrated System Model Must Address Multiple Aspects of a System

4/15/2008 Copyright © 2006-2008 by Object Management Group. 7
 Model Based Systems Engineering
Benefits
• Shared understanding of system requirements and design
– Validation of requirements
– Common basis for analysis and design
– Facilitates identification of risks
• Assists in managing complex system development
– Separation of concerns via multiple views of integrated model
– Supports traceability through hierarchical system models
– Facilitates impact analysis of requirements and design changes
– Supports incremental development & evolutionary acquisition
• Improved design quality
– Reduced errors and ambiguity
– More complete representation
• Supports early and on-going verification & validation to reduce risk
• Provides value through life cycle (e.g., training)
• Enhances knowledge capture

4/15/2008 Copyright © 2006-2008 by Object Management Group. 8

 System-of-Systems
Interactions

Boundaries

Modeling Needed to Manage System Complexity

4/15/2008 Copyright © 2006-2008 by Object Management Group. 9

 Modeling at Multiple Levels
of the System
MCE (CRC)

MCE (CRC)
MCE (CRC)
AWACS

LINK 16
LINK 16
AMDPCS

FAAD C3I

LINK 16
LINK 16
Patriot ICC

E-2C
AWACS F/A-18

RIVET JOINT
MCE

F-15C

ABMOC Subsystem
Operator Interface Voice Comm
Power

SIAP Hardware Hardware includes

Operational Models
Power Generation
and Distribution MSE
ACDS (CVN)
Power
Data Processing Power
Terminal Power TCIM
JTIDS
Hardware
Terminal

DDG-51 AEGIS Destroyer Software Power

CG EPLRS or SINGARS Force Level
Terminal Control System
TAOM Power Voice & TADIL-B Data
PLGR (GPS)
Patriot ICC Power
A2C2 Subsystem
Operator Interface Power
Voice Comm
Hardware Power Power Generation Hardware includes
and Distribution MSE
CEC Information Exchange Requirements - Classified SECRET when filled in
Power
Data Processing 1 2 3 4 5 6 7 8 9 10 11
FAAD C3I Terminal TCIM
Rationale/UJTL Number Event/Action Information Characterization
Sending Receiving
Critical Format Class
Latency: SA/Eng Message
Remarks
Voice & TADIL-B Data Node Node Support Error Rate
Hardware Power
JTIDS Radar measurements to REF: CEC A-spec
Provide SA/Support
AMDPCS Terminal OP 5.1.1 Comm Op Info support data fusion composite Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % Table 3-3 and
Software Engagements
tracking Host reqmts
IFF measurements to support
Provide SA/Support
OP 5.1.1 Comm Op Info data fusion and composite Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx %
Engagements
EPLRS or SINGARS tracking
Terminal IFF interrogation requests to
Power Provide SA/Support Respond w hen
OP 5.1.1 Comm Op Info support data fusion and Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx %
Engagements requested
Force Level Power composite tracking
Provide SA/Support ID Changes to support data
Control System PLGR OP 5.1.1 Comm Op Info Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx %
Engagements fusion and composite tracking
(GPS)
Provide SA/Support Navigation data to support data REF:CEC SRS and
Power OP 5.1.1 Comm Op Info Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx %
Engagements fusion and composite tracking Host Nav. spec

Engagement Support Requests

Provide SA/Support
OP 5.1.1 Comm Op Info to support data fusion and Host CEP Yes Binary IAW IDD Secret xx secs/xx secs xx % AEGIS only
Engagements
composite tracking
Track number management to
Provide SA/Support Changes sent
OP 5.1.1 Comm Op Info support data fusion and Host-CEP CEP-Host Yes Binary IAW IDD Secret xx secs/xx secs xx %
Engagements immediately
composite tracking
Composite Track State Update
Provide SA/Support REF: CEC IDDs for
OP 5.1.1 Comm Op Info to support data fusion and CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx %
Engagements each host
composite tracking
Associated Measurement REF: CEC A-spec
Provide SA/Support
OP 5.1.1 Comm Op Info Reports to support data fusion CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Table 3-3. SPY
Engagements
and composite tracking only
IFF Assignments to support
Provide SA/Support When assigned
OP 5.1.1 Comm Op Info data fusion and composite CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx %
Engagements or changed
tracking
ID recommendations to
Network Plan OP 5.1.1 Comm Op Info
Provide SA/Support
support data fusion and CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx %
When assigned
Engagements or changed
CID Criteria composite tracking
REF: CEC A-spec
Provide SA/Support Sensor cues to support data
OP 5.1.1 Comm Op Info CEP Host Yes Binary IAW IDD Secret xx secs/xx secs xx % Table 3-3. SPY
Network Engagements fusion and composite tracking
only

Network Track Data Receive Network Track Data

Track File

11 Correlate Track
Correlated Track
Files

12
Manage BMDS
Track File Data BMDS Track
JDN
Correlation S/W Network Interface Track Management Module Correlation Module Track File HIC
Module Module 13
Request
Attempt to

System Models
Track Data Correlate with Track Data Possible
Network BMDS Track
BMDS Track
File Matches
Interface S/W Network Track MSG Track File Request

Track Data Send Track

HIC File Data
Track Mangement S/W Module

BMDS Track Data Correlate Tracks BMDS Track Data

Correlation Results Session Activated

Verify CID,
Correlation, and
Assoicated Track yes Update Track
File Data
Data
Correlation no / initialize
Possible
CreateCorrelation
New Complete ( Correlation
Results
BMDS Track ) [ set not null ] / Send Results Idle Network Track File Received ( File Data ) [ number tracks
> 0 ] / Input Network Track

Correlating TracksMonitor
BMDS Track Display Correlation Receiving Network Track File
Process Data
On entry / match state vectors
BMDS Track Data Do / corr state vectors
Do / corr LPE On entry / receive file data
Do / corr PIP Do / store track data
Track MSG Data

Prepared Track MSG

Send BMDS
Track Data to
JDN
Do / corr RCS
Do / corr CID
On exit / corr BMDS Track #
On exit / request matching data
<TITLE>System Design<TITLE>
corr fail / is new BMDS Track
corr success / is corr BMDS Track
<META http-equiv="REFRESH"
BMDS Track File Request Sent ( Request

BMDS Track File Data

Received ( File Data ) /
Correlate Tracks
) / Pull BMDS Track Files
<!--CSSDATA:966533483-->
Receiving BMDS Track File
Data

On entry / receive file data

Do / store track data
<SCRIPT src="/virtual/2000/code
<LINK rel="stylesheet" href="/
<SCRIPT language="javascript"
Track Mangement Module
HIC
/current tracks
1..* /associated track data
manages
/CID data
uses 1..*
assign CID () 1..*
JDN recommend CID ()
1..* retrieve track file data ()
display track file data ()
communicates with ABMOC Subsystem
1
Operator Interface Voice Comm
Power
0..* Hardware Power Generation Hardware includes
interface for
1 <<entity>> and Distribution MSE
1 1
Track File
Correlation Module
Power
<<interface>>
Track Number Network Interface Module Data Processing Power
CID 0..* algorithm Power
/State Vector /tracks to be correlated
Terminal TCIM
buffer capacity JTIDS
/Date-Time /msg data correlation data Hardware
decorrelation data Terminal
received from
send track data () receive msg ()
parse msg () correlate tracks ()
route msg data () decorrelate tracks () Software Power
build msg () retrieve track data ()
send msg () send track data () EPLRS or SINGARS Force Level
Terminal Control System
1
0..* Voice & TADIL-B Data
Power

Component Models
correlates PLGR (GPS)
<<entity>>
Network Track <<entity>>
Customer
BMDS Track Power
Software License
owning element Primary Key Client Call
<<derived>> /associated data Primary Key is subject to A2C2 Subsystem
Received Date-Time owns
traces to /history Customer_ID [PK1] Serial_Number [PK1] Primary Key Operator Interface Power
local track number
Non-Key Attributes Voice Comm
Non-Key Attributes Hardware
Serial_Number [PK1] [FK] Power Power Generation
create () Customer_Name Hardware includes
receive ()
store () update () Technical_Contact and Distribution MSE
destroy () Purchase_Contact
update ()
retrieve () Customer_Address
send () Power
createsData Processing
consists of Terminal TCIM
Voice & TADIL-B Data
Hardware Power
JTIDS
Software Release Terminal
Software
Tech Support System Entry
Primary Key
Version_Number [PK1] Primary Key
TSS_Entry_Number [PK1]
Non-Key Attributes EPLRS or SINGARS
Windows_Version Terminal
Power
TSS_Description
Force Level Power
Control System PLGR
(GPS)
Power
Status
Location is a currently has
Primary Key
Primary Key
Status [PK1]
Status [PK1] [FK]

4/15/2008 Copyright © 2006-2008 by Object Management Group. 10

 Stakeholders Involved
in System Acquisition
Developers/
Customers Integrators

Project
Managers

Vendors

Regulators Testers

Modeling Needed to Improve Communications

4/15/2008 Copyright © 2006-2008 by Object Management Group. 11

 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

4/15/2008 Copyright © 2006-2008 by Object Management Group. 12

 What is SysML (cont.)

• Is a visual modeling language that provides

– Semantics = meaning
– Notation = representation of meaning
• Is not a methodology or a tool
– SysML is methodology and tool independent

4/15/2008 Copyright © 2006-2008 by Object Management Group. 13

 UML/SysML Status

• UML V2
– Updated version of UML that offers significant capability for
systems engineering over previous versions
– Issued in 2005 with on-going minor revisions

• UML for Systems Engineering (SE) RFP

– Established the requirements for a system modeling language
– Issued by the OMG in March 2003

• SysML
– Industry Response to the UML for SE RFP
– Adopted by OMG in May ’06

4/15/2008 Copyright © 2006-2008 by Object Management Group. 14

Diagram Overview & Language Concepts
 Relationship Between SysML and UML

UML 2
SysML

SysML
UML
extensions
reused by
to UML
SysML
(SysML
UML (UML4SysML)
Profile)
not required
by SysML
(UML - SysML Extensions
UML4SysML) -Blocks
-Item flows
-Value properties
-Allocations
-Requirements
-Parametrics
-Continuous flows
-…
4/15/2008 Copyright © 2006-2008 by Object Management Group. 16
 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

4/15/2008 Copyright © 2006-2008 by Object Management Group. 17

 4 Pillars of SysML – ABS Example
1. Structure sd ABS_ActivationSequence [Sequence Diagram] 2. Behavior
stm TireTraction [State Diagram]
m1:Brake
interaction
d1:Traction
Detector Modulator
LossOfTraction state
machine
detTrkLos()Gripping Slipping

activity/
RegainTraction
sendSignal() function
modBrkFrc(traction_signal:boolean)

modBrkFrc()
definition use
sendAck()

3. Requirements
4/15/2008 4. Parametrics
Copyright © 2006-2008 by Object Management Group. 18
 SysML Diagram Frames
• Each SysML diagram represents a model element
• Each SysML Diagram must have a Diagram Frame
• Diagram context is indicated in the header:
– Diagram kind (act, bdd, ibd, sd, etc.)
– Model element type (package, block, activity, etc.)
– Model element name
– User defined diagram name or view name
• A separate diagram description block is used to indicate if the
diagram is complete, or has elements elided Diagram Description
Version:
Description:
Completion status:
Header Reference:
(User-defined fields)

«diagram usage»
diagramKind [modelElementType] modelElementName [diagramName]

Contents
4/15/2008 Copyright © 2006-2008 by Object Management Group. 19
 Structural Diagrams

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

4/15/2008 Copyright © 2006-2008 by Object Management Group. 20

 Package Diagram

• Package diagram is used to organize the model

– Groups model elements into a name space
– Often represented in tool browser
– Supports model configuration management (check-in/out)
• Model can be organized in multiple ways
– By System hierarchy (e.g., enterprise, system, component)
– By diagram kind (e.g., requirements, use cases, behavior)
– Use viewpoints to augment model organization
• Import relationship reduces need for fully qualified
name (package1::class1)

4/15/2008 Copyright © 2006-2008 by Object Management Group. 21

 Package Diagram
Organizing the Model
pkg SampleModel [by diagram type] pkg SampleModel [by level] pkg SampleModel [by IPT]

Architecture
Use Cases Enterprise
Team

Requirements
Requirements System
Team

Behavior Logical Design IPT A

Physical
Structure IPT B
Design

EngrAnalysis Verification IPT C

By Diagram Type By Hierarchy By IPT

4/15/2008 Copyright © 2006-2008 by Object Management Group. 22

 Package Diagram - Views
pkg SampleModel[by level]
• Viewpoint represents the
stakeholder perspective
Enterprise • View conforms to a
«import»
particular viewpoint
– Imports model elements
«import»
«view» from multiple packages
System EngrAnalysis
– Can represent a model
«import»
query based on query
criteria
«conforms»
Logical Design
«import» • View and Viewpoint
consistent with IEEE
EngrAnalysisViewpoint 1471 definitions
Physical
Design «viewpoint»
stakeholders=”…”
purpose=”…”
constructionRules= ”…”
concerns=”…”
languages=”…”
Verification

4/15/2008 Copyright © 2006-2008 by Object Management Group. 23

 Blocks are Basic Structural Elements

• Provides a unifying concept to describe the structure of an element or

system
«block» Compartment
– System
BrakeModulator Label
– Hardware
– Software allocatedFrom
– Data «activity»Modulate
– Procedure BrakingForce
– Facility
values
– Person
DutyCycle: Percentage

• Multiple standard compartments can describe the block characteristics

– Properties (parts, references, values, ports)
– Operations
– Constraints
– Allocations from/to other model elements (e.g. activities)
– Requirements the block satisfies
– User defined compartments

4/15/2008 Copyright © 2006-2008 by Object Management Group. 24

 Property Types

• Property is a structural feature of a block

– Part property aka. part (typed by a block)
• Usage of a block in the context of the enclosing (composite) block
• Example - right-front:wheel
– Reference property (typed by a block)
• A part that is not owned by the enclosing block (not composition)
• Example – aggregation of components into logical subsystem
– Value property (typed by value type)
• A quantifiable property with units, dimensions, and probability
distribution
• Example
– Non-distributed value: tirePressure:psi=30
– Distributed value: «uniform» {min=28,max=32} tirePressure:psi

4/15/2008 Copyright © 2006-2008 by Object Management Group. 25

 Using Blocks

• Based on UML Class from UML Composite Structure

– Supports unique features (e.g., flow ports, value properties)
• Block definition diagram describes the relationship
among blocks (e.g., composition, association,
specialization)
• Internal block diagram describes the internal structure
of a block in terms of its properties and connectors
• Behavior can be allocated to blocks

Blocks Used to Specify Hierarchies and Interconnection

4/15/2008 Copyright © 2006-2008 by Object Management Group. 26

 Block Definition vs. Usage
Block Definition Diagram Internal Block Diagram

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

4/15/2008 Copyright © 2006-2008 by Object Management Group. 27

 Internal Block Diagram (ibd)
Blocks, Parts, Ports, Connectors & Flows

Enclosing
Block

Connector

Item Flow

Port Part

Internal Block Diagram Specifies Interconnection of Parts

4/15/2008 Copyright © 2006-2008 by Object Management Group. 28

 Reference Property Explained

•S1 is a reference part*

•Shown in dashed outline box

*Actual name is reference property

4/15/2008 Copyright © 2006-2008 by Object Management Group. 29

 SysML Ports

• Specifies interaction points on blocks and parts

– Integrates behavior with structure
– portName:TypeName
• Kinds of ports
– Standard (UML) Port
• Specifies a set of required or provided operations and/or signals
• Typed by a UML interface
– Flow Port
• Specifies what can flow in or out of block/part
• Typed by a block, value type, or flow specification
• Atomic, non-atomic, and conjugate variations

Standard Port and Flow Port

Support Different Interface Concepts
4/15/2008 Copyright © 2006-2008 by Object Management Group. 30
 Port Notation

provided interface
(provides the operations)

Standard
part1: part2:
Port

required interface
(calls the operations)

Flow Port

Flow part1: part2:

Port
item flow

4/15/2008 Copyright © 2006-2008 by Object Management Group. 31

 Delegation Through Ports

ibd [block]Block1[delegation]
• Delegation can be used to
preserve encapsulation of
block (black box vs white box) Child1:

• Interactions at outer ports of

Block1 are delegated to ports
Child2:
of child parts
• Ports must match (same kind,
type, direction, etc.)
• Connectors can cross
boundary without requiring
ports at each level of nested
hierarchy

4/15/2008 Copyright © 2006-2008 by Object Management Group. 32

 Parametrics
• Used to express constraints (equations) between value
properties
– Provides support for engineering analysis
(e.g., performance, reliability)
– Facilitates identification of critical performance properties
• Constraint block captures equations
– Expression language can be formal (e.g., MathML, OCL) or
informal
– Computational engine is provided by applicable analysis tool and
not by SysML
• Parametric diagram represents the usage of the constraints in
an analysis context
– Binding of constraint parameters to value properties of blocks (e.g.,
vehicle mass bound to parameter ‘m’ in F= m × a)

Parametrics Enable Integration of Engineering

Analysis with Design Models
4/15/2008 Copyright © 2006-2008 by Object Management Group. 33
 Defining Vehicle Dynamics

Defining Reusable Equations for Parametrics

4/15/2008 Copyright © 2006-2008 by Object Management Group. 34

 Vehicle Dynamics Analysis

Using the Equations in a Parametric Diagram to

4/15/2008 Constrain
Copyright Value
© 2006-2008 Properties
by Object Management Group. 35
 Behavioral Diagrams

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

4/15/2008 Copyright © 2006-2008 by Object Management Group. 36

 Activities

• Activity specifies transformation of inputs to outputs

through a controlled sequence of actions
• Secondary constructs show responsibilities for the
activities using activity partitions (i.e., swim lanes)
• SysML extensions to Activities
– Support for continuous flow modeling
– Alignment of activities with Enhanced Functional Flow Block
Diagram (EFFBD)

4/15/2008 Copyright © 2006-2008 by Object Management Group. 37

 Activity Diagram
Activity
act Example

Output
Input Action
out1
in1 a2
a1 out1
in1
out1

[x>0] [x<=0]

in1

a3 a4

Input out1 out1 Output

in1
in2 out1
in2 a5
out2

Activity Diagram Specifies Controlled Sequence of Actions

4/15/2008 Copyright © 2006-2008 by Object Management Group. 38
 Routing Flows
Initial Node – On execution of parent control token placed
on outgoing control flows

Activity Final Node – Receipt of a control token terminates parent

Flow Final Node – Sink for control tokens

Fork Node – Duplicates input (control or object) tokens

from its input flow onto all outgoing flows

Join Node – Waits for an input (control or object) token on all

input flows and then places them all on the outgoing flow

Decision Node – Waits for an input (control or object) token on its

input flow and places it on one outgoing flow based on guards

Merge Node – Waits for an input (control or object) token on

any input flows and then places it on the outgoing flow

Guard expressions can be applied on all flows

4/15/2008 Copyright © 2006-2008 by Object Management Group. 39
 Actions Process Flow of
Control and Data
• Two types of flow
– Object / Data
– Control
• Unit of flow is called a “token”
(consumed & produced by actions)

Control Input

Control Output input2 and output2 are

‘required’ by default

Actions Execution Begins When Tokens Are Available

on “all” Control Inputs and Required Inputs

4/15/2008 Copyright © 2006-2008 by Object Management Group. 40

 An Action Can Invoke Another Activity
act Activity n

<<optional>> action1 <<optional>>

input1 output1

action2
input2 output2

Control Input

Control Output

Activity is Invoked When an Action Begins to Execute

4/15/2008 Copyright © 2006-2008 by Object Management Group. 41

 Semantics for Activity Invocation
A call behavior action can have
• 0..* control inputs & outputs
• 0 ..* optional item inputs & outputs Note: The summary is an approximation of the semantics.
The detailed semantics are specified in the UML and SysML specification.
• 0..* required item inputs & outputs
• 0..* streaming (and continuous) item inputs & outputs

Starting an action:
• An action starts when a token is placed on all of its control inputs and all of its required inputs
(must meet minimum multiplicity of its input pins) and the previous invoked activity has
completed
• An action invokes an activity when it starts, and passes the tokens from its input pins to the
input parameter nodes of the invoked activity

During an execution:
• An action continues to accept streaming inputs and produce streaming outputs

Terminating an action:
• An action terminates when its invoked activity reaches an activity final, or when the action
receives a control disable, or as a side affect of other behaviors of the parent activity
• The tokens on the output parameter nodes of the activity are placed on the output pins of the
action and a control token is placed on each of the control outputs of the action

Following action termination:

• The tokens on the output pins and control outputs of the action are moved to the input pins of
the next actions when they are ready to start per above
• The action can restart and invoke the activity again when the starting conditions are satisfied
per above
4/15/2008 Copyright © 2006-2008 by Object Management Group. 42
 Common Actions
act Activity n

<<optional>> action1 <<optional>>

input1 output1

action2
input2 output2

Call Operation Action Call Behavior Action

(can call leaf level function)

Accept Event Action Send Signal Action

(Event Data Pin often elided) (Pins often elided)
4/15/2008 Copyright © 2006-2008 by Object Management Group. 43
 Activity Diagram Example
With Streaming Inputs and Outputs
act Activity
Start

action 4
output3

out1

«optional»
[x>1]
in1 [else]
<<optional>> {stream}
action 1 [y>0] <<optional>>
input1 action 2
output1
{stream} «optional» «optional» out1
{stream}
in1 {stream}
in2 out1
{stream}
{stream} «optional»
in1
input2 [else] {stream} action 3
output2

out1

Streaming Inputs and Outputs Continue to Be

Consumed and Produced While the Action is Executing
4/15/2008 Copyright © 2006-2008 by Object Management Group. 44
 Distill Water Activity Diagram
(Continuous Flow Modeling)
Continuous flow means ΔTime
Actions are enabled by default between tokens approaches zero
when activity is enabled Continuous Flow

Accept Event Action

Interruptible
Will Terminate Execution
Region

Continuous Flow Is Representative

of Many Physical Processes
4/15/2008 Copyright © 2006-2008 by Object Management Group. 45
 Example – Operate Car
act Operate Car

Turn Key
to On :Driving Turn Key
to Off

Brake Pressure
«continuous»

«continuous» «continuous»
Brake Pressure Braking Pressure
:Braking «controlOperator»
:Enable on Brake
Pressure > 0
Modulation
Frequency
«continuous»
«optional »

«continuous»
Modulation
Frequency
:Monitor Traction {control}

Enabling and Disabling Actions

With Control Operators
4/15/2008 Copyright © 2006-2008 by Object Management Group. 46
 Activity Diagrams
Pin vs. Object Node Notation
• Pins are kinds of Object Nodes
– Used to specify inputs and outputs of actions
– Typed by a block or value type
– Object flows connect object nodes
• Object flows between pins have two diagrammatic
forms
– Pins shown with object flow between them
– Pins elided and object node shown with flow arrows in and out
act [Activity] Prevent Lockup [ Actions ] act [Activity] Prevent Lockup [ Actions ]
Pins must
have same
characteristics
p1 : TractLoss a1 : Detect Loss of a2 : Modulate
(name, type
a1 : Detect Loss of of1 a2 : Modulate tl :
Traction Braking Force Traction
TractLoss
Braking Force
etc.)
p2 : TractLoss

Pins ObjectNode
4/15/2008 Copyright © 2006-2008 by Object Management Group. 47
 Explicit Allocation of Behavior to
Structure Using Swimlanes
act [Activity] Prevent Lockup [ Actions ]

Activity Diagram a1 : Detect Loss of

p1 : TractLoss
of1 a2 : Modulate
Traction Braking Force

(without Swimlanes) p2 : TractLoss

act [Activity] Prevent Lockup [ Swimlanes ]

<<allocate>> <<allocate>>
d1 : Traction Detector m1 : Brake Modulator

Activity Diagram p1 : TractLoss

a1 : Detect Loss of a2 : Modulate
(with Swimlanes) Traction of1

p2 : TractLoss
Braking Force

allocatedTo
<<connector>> c2 :

4/15/2008 Copyright © 2006-2008 by Object Management Group. 48

 Activity Decomposition

bdd [Pa ck age] Beh avior [ Beh avior De comp ] act [Activity] Prevent Lockup [ Actions ]

<< activity> >

Prevent
Loc kup

a1 a2 p1 : TractLoss
<< activity> > << activity> > a1 : Detect Loss of a2 : Modulate
of1
Traction Braking Force
De tect Modulate
Los s of Braki ng p2 : TractLoss
Tra ction For ce

p1 p2
<<block >>
Tra ctLoss

Definition Use

4/15/2008 Copyright © 2006-2008 by Object Management Group. 49

 SysML EFFBD Profile
EFFBD - Enhanced Functional Flow Block Diagram
«effbd»
act
2.4 Function in
Multi-exit
Construct
{cc#1}

«optional»
2.2 Multi-exit
Item 1
Function
{cc#2}

[ before third time ]

Item 2

External 2.1 Serial «optional» [ after External

Input Function third Output
2.5 Function in time ]
an Iterate

Item 3
«optional»

2.6 Output
Function

2.3 Function in
Concurrency «optional»
Item 4

Aligning SysML with Classical Systems Engineering Techniques

4/15/2008 Copyright © 2006-2008 by Object Management Group. 50
 Interactions

• Sequence diagrams provide representations of

message based behavior
– represent flow of control
– describe interactions between parts
• Sequence diagrams provide mechanisms
for representing complex scenarios
– reference sequences
– control logic
– lifeline decomposition
• SysML does not include timing, interaction overview,
and communications diagram

4/15/2008 Copyright © 2006-2008 by Object Management Group. 51

 Black Box Interaction (Drive)
sd DriveBlackBox

driver:Driver vehicle: HybridSUV

:

ref
StartVehicleBlackBox

par

alt controlSpeed [state = (idle)]

ref
Idle

[state = (accelerating/cruising)]

ref
Accelerate/Cruise

[state = (braking)]

ref
Brake

ref
Steer

ref
Park/ShutdownVehicle

UML 2 Sequence Diagram Scales

by4/15/2008
SupportingCopyright
Control Logic and Reference Sequences
© 2006-2008 by Object Management Group. 52
 Black Box Sequence (StartVehicle)

sd StartVehicleBlackBox

vehicle:HybridSUV
driver:Driver ref StartVehicleWhiteBox

turnIgnitionToStart
1: StartVehicle
References Lifeline
Decomposition
For White Box
Interaction

Simple Black Box Interaction

4/15/2008 Copyright © 2006-2008 by Object Management Group. 53

 White Box Sequence (StartVehicle)
sd StartVehicleWhiteBox

ecu:PowerControlUnit epc:ElectricalPowerController

1: StartVehicle

1.1: Enable

1.2:ready

Decomposition of Black Box Into White Box Interaction

4/15/2008 Copyright © 2006-2008 by Object Management Group. 54
 Primary Interaction Operators
• ref name
– reference to a sequence diagram fragment defined elsewhere
• opt [condition]
– has 1 part that may be executed based on a condition/state value
• alt
– has 2 or more parts, but only one executes based on a condition/state
– an operand fragment labeled [else] is executed if no other condition is true
• par
– has 2 or more parts that execute concurrently
• Concurrence indicates does not require simultaneous, just that the order
is undetermined. If there is only one processor the behavior could be (A
then B), (B then A), or (A and B interleaving) …
• loop min..max [escape]
– Has a minimum # of executions, and optional maximum # of executions, and
optional escape condition
• break [condition]
– Has an optional guard. If true, the contents (if any) are executed, and the
remainder of the enclosing operator is not executed
Provided by Michael Chonoles
4/15/2008 Copyright © 2006-2008 by Object Management Group. 55
 Other Interaction Operators
• critical
– The sequence diagram fragment is a critical region. It is treated as atomic –
no interleaving with parallel regions
• neg
– The sequence diagram fragment is forbidden. Either it is impossible to
occur, or it is the intent of the requirements to prevent it from occurring
• assert
– The sequence diagram fragment is the only one possible (or legal)
• seq (weak, the default)
strict
– Strict: The message exchange occurs in the order described
– Weak: Each lifeline may see different orders for the exchange (subject to
causality)
• consider (list of messages)
ignore (list of messages)
– Consider: List the messages that are relevant in this sequence fragment
– Ignored: List the messages that may arrive, but are not interesting here
Provided by Michael Chonoles
4/15/2008 Copyright © 2006-2008 by Object Management Group. 56
 Trial Result of Vehicle Dynamics
tim MaxAcceleration [100 Wheel Horsepower] «diagramDescription »
Satisfies version=”0.1"
«requirement»
Acceleration description=”Constant
100 wheel horsepower,
4000 lb vehicle weight,
0.5
simple drag"
0.45 reference=”Equations of
0.4 Motion”
completeness=”assumes
0.35
Accelleration (g)

perfect tire traction”

0.3
0.25
0.2
0.15

Lifeline are
0.1
0.05
0
0 5 10 15 20

value properties
Time (sec)
140

120

100
Velocity (mph)

80

60

40

20

0
0 5 10 15 20
Time (sec)
1800

1600

Timing Diagram Not

1400

1200
Distance (ft)

1000

800

Part of SysML
600

400

200

0
0 5 10 15 20
Time (sec)

Typical Example of a Timing Diagram

4/15/2008 Copyright © 2006-2008 by Object Management Group. 57
 State Machines

• Typically used to represent the life cycle of a block

• Support event-based behavior (generally
asynchronous)
– Transition with trigger, guard, action
– State with entry, exit, and do-activity
– Can include nested sequential or concurrent states
– Can send/receive signals to communicate between blocks
during state transitions, etc.
• Event types
– Change event
– Time event
– Signal event

4/15/2008 Copyright © 2006-2008 by Object Management Group. 58

 Operational States (Drive)
stm HSUVOperationalStates

Off keyOff/

start[in neutral]/start engine shutOff/stop engine Nominal

states only

Operate

Transition notation:
Idle
trigger[guard]/action
accelerate/
when (speed = 0)

releaseBrake/

Accelerating/
Braking
Cruising

engageBrake/

4/15/2008 Copyright © 2006-2008 by Object Management Group. 59

 Use Cases

• Provide means for describing basic functionality in

terms of usages/goals of the system by actors
– Use is methodology dependent
– Often accompanied by use case descriptions
• Common functionality can be factored out via
«include» and «extend» relationships
• Elaborated via other behavioral representations to
describe detailed scenarios
• No change to UML

4/15/2008 Copyright © 2006-2008 by Object Management Group. 60

 Operational Use Cases
uc HSUV_UseCases [Operational Use Cases]

HybridSUV

Flat_Tire

«extend»

Accelerate
Drive_The_Vehi «include»
cle

Driver «include»

Steer
«include»

Park «include» Brake

4/15/2008 Copyright © 2006-2008 by Object Management Group. 61

 Cross-cutting Constructs
• Allocations
• Requirements
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

4/15/2008 Copyright © 2006-2008 by Object Management Group. 62

 Allocations

• Represent general relationships that map one model

element to another
• Different types of allocation are:
– Behavioral (i.e., function to component)
– Structural (i.e., logical to physical)
– Software to Hardware
– ….
• Explicit allocation of activities to structure via swim
lanes (i.e., activity partitions)
• Both graphical and tabular representations are
specified

4/15/2008 Copyright © 2006-2008 by Object Management Group. 63

 Different Allocation Representations
(Tabular Representation Not Shown)
«allocate»
Element part name : Element Name
Name2
«allocate»
Element action name :
Name1 Activity Name
«allocate»
Element
Name3

Allocate Relationship Explicit Allocation of

Action to Part Property

«block»
Block Name «block»
Block Name allocatedFrom
«elementType»Element Name
part name
part name
allocatedFrom
«elementType»ElementName

Compartment Notation Callout Notation

Read as follows
“part name has constraints that are allocated to/from an <<element type>> Element Name” OR
“part name has an <<element type>> allocated from Element Name”
“Element Name is allocated to a part called part name”
4/15/2008 Copyright © 2006-2008 by Object Management Group. 64
 SysML Allocation of SW to HW
• In UML, the deployment diagram is used to deploy artifacts to nodes
• In SysML, «allocation» on an ibd and bdd is used to deploy software/data to
hardware
ibd [node] SF Residence

«node
»
SF Residence Installation

* 2
«hardware » «hardware»
«hardware»
: Optical Sensor : Alarm
: Video Camera

«hardware»
: Site Processor
«hardware»
allocatedFrom : NW Hub «hardware»
«software» Device Mgr : DSL Modem
allocatedFrom
«software» Event Mgr
«software» SF Comm I/F
«software» Site Config Mgr
«software» Site RDBMS
«software» Site Status Mgr
«software» User I/F 2
«software» User Valid Mgr «hardware »
: DVD-ROM Drive
allocatedFrom
«data» Video File

«hardware»
«hardware » : User Console
: Site Hard Disk
allocatedFrom
«data» Site Database

4/15/2008 Copyright © 2006-2008 by Object Management Group. 65

 Requirements

• The «requirement» stereotype represents a text

based requirement
– Includes id and text properties
– Can add user defined properties such as verification method
– Can add user defined requirements categories
(e.g., functional, interface, performance)
• Requirements hierarchy describes requirements
contained in a specification
• Requirements relationships include DeriveReqt,
Satisfy, Verify, Refine, Trace, Copy

4/15/2008 Copyright © 2006-2008 by Object Management Group. 66

 Requirements Breakdown
req [package] HSUVRequirements [HSUV Specification]

HSUVSpecification
RefinedBy
«useCase» HSUVUseCases::Accelerate

«requirement» «requirement»
Eco-Friendliness Performance
«requirement»
Power

«deriveReqt»

«requirement» «requirement» «requirement»

Braking FuelEconomy Acceleration

«requirement»
Emissions
Id = “R1.2.1” VerifiedBy SatisfiedBy
text = “The vehicle shall meet Ultra-Low «testCase» MaxAcceleration «block» PowerSubsystem
Emissions Vehicle standards.”

Requirement Relationships Model the Content of a Specification

4/15/2008 Copyright © 2006-2008 by Object Management Group. 67
 Example of Derive/Satisfy Requirement
Dependencies
«requirement» «requirement» «requirement»
OffRoadCapability Acceleration CargoCapacity

Supplier
«deriveReqt»
«deriveReqt» «deriveReqt»

Client
«requirement»
Client depends on supplier Power

(i.e., a change in supplier Supplier

results in a change in client) «satisfy»
Client
«block»
PowerSubsystem

from OMG

Arrow Direction Opposite Typical Requirements Flow-Down from OMG

4/15/2008 Copyright © 2006-2008 by Object Management Group. 68

 Problem and Rationale

bdd Master Cylinder requirements

«block»
«requirement» Brake System
Loss of Fluid
«satisfy»

m:MasterCylinder
«requirement»
Reservoir
«satisfy»

«rationale» «problem»
The best-practice solution consists in The master cylinder in previous
assigning one reservoir per brakeline. version leaked.
See "automotive_d32_hdb.doc"

Problem and Rationale can be attached to any

Model Element to Capture Issues and Decisions
4/15/2008 Copyright © 2006-2008 by Object Management Group. 69
 Stereotypes & Model Libraries

• Mechanisms for further customizing SysML

• Profiles represent extensions to the language
– Stereotypes extend meta-classes with properties and
constraints
• Stereotype properties capture metadata about the model element
– Profile is applied to user model
– Profile can also restrict the subset of the meta-model used
when the profile is applied
• Model Libraries represent reusable libraries of model
elements

4/15/2008 Copyright © 2006-2008 by Object Management Group. 70

 Stereotypes

«metaclass»
NamedElement

«configurationItem»
Engine
author=”John Doe”
version=”1.2"
«stereotype» lastChanged=Dec12, 2005
ConfigurationItem
author: String
version: String
lastChanged: Date

Defining the Stereotype Applying the Stereotype

4/15/2008 Copyright © 2006-2008 by Object Management Group. 71

 Applying a Profile and
Importing a Model Library

pkg ModelingDomain [Establishing HSUV Model]

«profile»
SysML

«apply» {strict}
«apply»
{strict}

«modelLibrary» «import»
HSUVModel
SI Definitions

4/15/2008 Copyright © 2006-2008 by Object Management Group. 72

 Cross Connecting Model Elements
1. Structure 2. Behavior

c ate
allo

value
binding
satisfy
req [package] VehicleSpecifications
[Requirements Diagram - Braking Requirements]

Vehicle System Braking Subsystem

Specification Specification

«requirement» «requirement»
StoppingDistance Anti-LockPerformance

id=“102” id=”337"
text=”The vehicle shall stop text=”Braking subsystem
from 60 mph within 150 ft shall prevent wheel lockup
on a clean dry surface.” under all braking conditions.”

SatisfiedBy
«block»Anti-LockController

«deriveReqt»
Verify
3. Requirements
4/15/2008 Copyright © 2006-2008 by Object
(via intera 4. Parametrics
ctionManagement
) Group. 73
 SysML Modeling
as Part of the SE Process
Distiller Sample Problem
 Distiller Problem Statement

• The following problem was posed to the SysMLteam in Dec ’05 by D. Oliver:
• Describe a system for purifying dirty water.
– Heat dirty water and condense steam are performed by a Counter Flow Heat Exchanger
– Boil dirty water is performed by a Boiler
– Drain residue is performed by a Drain
– The water has properties: vol = 1 liter, density 1 gm/cm3, temp 20 deg C, specific heat
1cal/gm deg C, heat of vaporization 540 cal/gm.
• A crude behavior diagram is shown.
Energy to Pure
Dirty water Dirty water condense water
Steam
@ 20 deg C @ 100 deg C

Condense
steam
Heat Dirty water Boil Dirty water and
and
To 100 deg C
Drain
Residue
Residue
Heat to Dirty Disposed
water Heat to Boil residue
water

What are the real requirements?

How do we design the system?
4/15/2008 Copyright © 2006-2008 by Object Management Group. 76
 Distiller Types

Batch
Distiller

Continuous
Distiller

Note: Not all aspects of the distiller are modeled in the example
4/15/2008 Copyright © 2006-2008 by Object Management Group. 77
 Distiller Problem – Process Used

• Organize the model, identify libraries needed

• List requirements and assumptions
• Model behavior
– In similar form to problem statement
– Elaborate as necessary
• Model structure
– Capture implied inputs and outputs
• segregate I/O from behavioral flows
– Allocate behavior onto structure, flow onto I/O
• Capture and evaluate parametric constraints
– Heat balance equation
• Modify design as required to meet constraints
• Model the user interaction
• Modify design to reflect user interaction

4/15/2008 Copyright © 2006-2008 by Object Management Group. 78

 Distiller Problem – Package Diagram:
Model Structure and Libraries

package Value Types [ value types for distiller ]

<<ValueType>>
Real

<<ValueType>> <<ValueType>> <<ValueType>>

<<ValueType>>
ºC N/m^2 gm/sec
efficency
<<ValueType>> <<ValueType>> <<ValueType>> {0<=n<=1}
dimension = temperature dimension = pressure dimension = mass flow rate
unit = degrees celcius unit = newtons per square meter unit = grams per second

<<ValueType>> <<ValueType>> <<ValueType>>

cal/sec cal/(gm*ºC) cal/gm
<<ValueType>> <<ValueType>> <<ValueType>>
dimension = heat flow rate dimension = specific heat dimension = latent heat
unit = calories per second unit = calories per gram degree celcius unit = calories per gram

4/15/2008 Copyright © 2006-2008 by Object Management Group. 79

 Distiller Example
Requirements Diagram

4/15/2008 Copyright © 2006-2008 by Object Management Group. 80

 Distiller Example:
Requirements Tables

table [requirement] OriginalStatement[Decomposition of OriginalStatement]

id name text
S0.0 OriginalStatement Describe a system for purifying dirty water. …
S1.0 PurifyWater The system shall purify dirty water.
S2.0 HeatExchanger Heat dirty water and condense steam are performed by a …
S3.0 Boiler Boil dirty water is performed by a Boiler.
S4.0 Drain Drain residue is performed by a Drain.
S5.0 WaterProperties water has properties: density 1 gm/cm3, temp 20 deg C, …
S5.1 WaterInitialTemp water has an initial temp 20 deg C

table [requirement] PurifyWater[Requirements Tree]

id name relation id name

Rationale
The requirement for a boiling function and a boiler
S1.0 PurifyWater deriveReqt D1.0 DistillWater implies that the water must be purified by distillation

4/15/2008 Copyright © 2006-2008 by Object Management Group. 81

 Distiller Example – Activity Diagram:
Initial Diagram for DistillWater
• This activity diagram applies the SysML EFFBD profile, and formalizes the
diagram in the problem statement.

Energy to Pure
Dirty water Dirty water condense water
Steam
@ 20 deg C @ 100 deg C

Condense
steam
Heat Dirty water Boil Dirty water and
and
To 100 deg C
Drain
Residue
Residue
Heat to Dirty Disposed
water Heat to Boil residue
water

Activities (Functions) Control (Sequence) Things that flow (ObjectNodes)

4/15/2008 Copyright © 2006-2008 by Object Management Group. 82

 Distiller Example – Activity Diagram:
Control-Driven: Serial Behavior

«effbd»
act [activity] DistillWater [Simple Starting Point)

pure:H2O
recovered:Heat [liquid]
steam:H2O
[gas]
coldDirty:H2O
[liquid]
hotDirty:H2O
[liquid]

a3:CondenseSteam

a1:HeatWater a2:BoilWater

a4:DrainResidue

external:Heat discharge :Residue

predischarge :Residue

Continuous Distiller Here

Batch
Distiller
4/15/2008 Copyright © 2006-2008 by Object Management Group. 83
 Distiller Example – Block Definition
Diagram: DistillerBehavior
Control
Activities
(not shown
(Functions)
on BDD)

Need to
consider
phases
of H20

Things that flow (ObjectNodes)

4/15/2008 Copyright © 2006-2008 by Object Management Group. 84
 Distiller Example – State Machine
Diagram: States of H2O
States Transitions

4/15/2008 Copyright © 2006-2008 by Object Management Group. 85

 Distiller Example – Activity Diagram:
I/O Driven: Continuous Parallel Behavior

Continuous
Distiller
Batch Distiller Here

4/15/2008 Copyright © 2006-2008 by Object Management Group. 86

 Distiller Example – Activity Diagram:
No Control Flow, ActionPin Notation,
Simultaneous Behavior

4/15/2008 Copyright © 2006-2008 by Object Management Group. 87

 Distiller Example – Activity Diagram
(with Swimlanes): DistillWater

Parts

Allocated ibd
4/15/2008 Copyright © 2006-2008 by Object Management Group. 88
 Distiller Example – Block Definition
Diagram: DistillerStructure

4/15/2008 Copyright © 2006-2008 by Object Management Group. 89

 Distiller Example – Block Definition
Diagram: Heat Exchanger Flow Ports

pkg Initial Distiller Structure [ distiller breakdown (ports) ]

<<block>>
Distiller

condenser evaporator drain

<<block>> <<block>> in : Fluid <<block>> out : Fluid

Heat Exchanger Boiler Valve
c in : Fluid constraints h in : Fluid middle : Fluid top : Fluid
{h out.temp<=120,
c out : Fluid c in.temp<=60, h out : Fluid bottom : Fluid bottom : Heat
h in.temp<=120,
c out.temp<=90}

Constraints Flow Ports

(on Ports) (typed by things that flow)

4/15/2008 Copyright © 2006-2008 by Object Management Group. 90

 Distiller Example – Internal Block
Diagram: Distiller Initial Design

4/15/2008 Copyright © 2006-2008 by Object Management Group. 91

 Distiller Example –Table:
Functional Allocation

-a1 : Distiller::Dis...

-a2 : Distiller::Dis...

-a3 : Distiller::Dis...

-a4 : Distiller::Dis...
Object Flow:of1[...

Object Flow:of2[...

Object Flow:of3[...

Object Flow:of4[...

Object Flow:of5[...

Object Flow:of6[...

Object Flow:of7[...
Initial Distiller Structure[Distill...
Distiller [Distiller::Distiller St...
-condenser : Distiller::D...
-drain : Distiller::Distiller...
-evaporator : Distiller::...
-main1 : Distiller::Item ...
-main2 : Distiller::Item ...
-main3 : Distiller::Item ...
-main4 : Distiller::Item ...
-q1 : Distiller::Item Typ...
-sludge1 : Distiller::Ite...
-sludge2 : Distiller::Ite...

Exercise for student:

Is allocation complete?
Swimlane Diagram Where is “«objectFlow»of8”?
4/15/2008 Copyright © 2006-2008 by Object Management Group. 92
 Parametric Diagram: Heat Balance

4/15/2008 Copyright © 2006-2008 by Object Management Group. 93

 Distiller Example – Heat Balance
Results
table IsobaricHeatBalance1 [Results of Isobaric Heat Balance]

specific heat cal/gm-°C 1

main2 : H2O frm condenser

latent heat cal/cm 540

main2 : H2O into evap

Satisfies «requirement»
WaterSpecificHeat

Satisfies «requirement»
WaterHeatOfVaporization

main3 : H2O

main4 : H2O
main1 : H2O
Satisfies «requirement»
WaterInitialTemp

mass flow rate gm/sec 6.8 6.8 1 1 1

temp °C 20 100 100 100 100

dQ/dt cooling water cal/sec 540

Note: Cooling water
dQ/dt steam-condensate cal/sec 540 needs to have 6.75x
condenser efficency 1 flow of steam!
Need bypass between
heat deficit 0
hx_water_out and
bx_water_in!
dQ/dt condensate-steam cal/sec 540
boiler efficiency 1
dQ/dt in boiler cal/sec 540

4/15/2008 Copyright © 2006-2008 by Object Management Group. 94

 Distiller Example – Activity Diagram:
Updated DistillWater

4/15/2008 Copyright © 2006-2008 by Object Management Group. 95

 Distiller Example – Internal Block
Diagram: Updated Distiller

4/15/2008 Copyright © 2006-2008 by Object Management Group. 96

 Distiller Example – Use Case and
Sequence Diagrams
sd [Interaction] Operational Sequence [ simple seqence ]

uc [Package] Distiller Use Cases [ use case example ]

: Operator <<block>>
: Distiller
Distiller
1: Turn On
Operator
2: Power Lamp On Operate Distiller

3: Operating Lamp On

loop
[while state=Operating]

alt
[level=high]
4: High Level Lamp On

[level=low]
5: Low Level Lamp On

[state=draining residue]
6: Draining Lamp On

7: Turn Off

8: Power Lamp Off

4/15/2008 Copyright © 2006-2008 by Object Management Group. 97

 Distiller Example – Internal Block
Diagram: Distiller Controller
class Distiller [ block diagram revised & elaborated ]
diverter assembly

splitter : Tee Fitting m2.2 : H2O

m2.1 : H2O

feed : Valve
main1 : H2O main2 : H2O sludge2 : Residue
sludge1 : Residue
v : V Ctrl
m2.1 : H2O

condenser : Heat Exchanger evaporator : Boiler drain : Valve

p in : Elec Power v : V Ctrl

c : Boiler Signals
main3 : H2O htr pwr : Elec Power

blr ctl : Blr Sig

feed ctl : V Ctrl

main4 : H2O drain ctl : V Ctrl

blr status : Blr Sig

distiller pwr : Elec Power
pwr in : Elec Power

v2 : V Ctrl b : Boiler Signals bp : Elec Power v1 : V Ctrl

pwr : Elec Power
user : Control Panel heat & valve : Controller

iPanel iPanel

4/15/2008 Copyright © 2006-2008 by Object Management Group. 98

 Distiller Example – State Machine
Diagram: Distiller Controller

stm Controller State Machine [ simple diagram ]

[power = on] Off [bx level low]

do /Power Light Off

Filling Operating
do /open feed : Valve do /bx heater on
[bx1 level high] Draining
[bx1 level low]
do /open drain : Valve

Level Low Level OK Level High

do /open feed : Valve do /shut all Valves do /open drain : Valve [bx1 temp = 30]
[NOT bx1 level low]

Warming Up [NOT bx1 level low] [NOT bx1 level high] Cooling Off
entry / bx1 heater OFF
do /bx1 heater on do /open feed : Valve, open drain : Valve
Building Up Residue [residue timer] Purging Residue
do /close drain : Valve [drain timer] do /open drain : Valve

[bx1 temp = 100] [shutdown command]

4/15/2008 Copyright © 2006-2008 by Object Management Group. 99

OOSEM – ESS Example
 System Development Process

Stakeholder Manage Plan

Reqts System
Development

Status
Test procedures
Technical data Define System Integrate
Reqt's & & Test System
Design System arch System
Allocated reqt's
System
Modeling Procedures Verified
Activities Data System
Hardware Component
Software
Develop
Component System
Modeling Components
Activities

Integrated Product A Recursive V process

Development (IPD) is that can be applied to
essential to improve multiple levels of the
communications system hierarchy

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 101
 System Modeling Activities – OOSEM
Integrating MBSE into the SE Process
Analyze
Needs
Requirements Traceability is Managed
Through the Entire MBSE Process
•Mission use cases/scenarios
•Enterprise model Define
System
Requirements

•System use cases/scenarios

•Elaborated context
•Req’ts diagram Define
Logical
Optimize & Architecture
Evaluate
Alternatives •Logical architecture

Synthesize
•Engr Analysis Models Physical
•Trade studies Validate & Architecture
Verify
System
•Node diagram
•HW, SW, Data architecture
•Test cases/procedures

4/15/2008 Copyright © Lockheed

Copyright Martin Corporation
© 2006-2008 2000 – 2003Group.
by Object Management & INCOSE 2004-2006 102
 Enhanced Security System Example

• The Enhanced Security System is the example for

the OOSEM material
– Problem fragments used to demonstrate principles
– Utilizes Artisan RTS™ Tool for the SysML artifacts

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 103
 ESS Requirements Flowdown

req [package] ESS Requirements Flowdown

«document» «trace»
ESS Enterprise Models
Market Needs

«trace»

«requirement» «satisfy» ESS System Models

ESS System Specification
id# = SS1 «refine»

«requirement»
IntruderDetection «requirement»
R111
id# = SS102
txt = System shall id# = SS111
«deriveReqt»
detect intruder entry «satisfy»
and exit ...

ESS Logical Design Models

«requirement» «refine»
satisfiedBy ESS Logical Requirements
Entry/Exit Subsystem
verifiedBy id# = LR1
Entry/Exit Detection Test
«satisfy»
«deriveReqt»

«requirement» ESS Allocated Design

ESS Allocated Requirements Models
id# = AR1 «refine»

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 104
 Operational View Depiction

bdd [package] Enterprise (As Is)

Central Monitoring Station As-Is

Comm Network

Residence

Dispatcher Intruder

Police

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 105
 ESS Enterprise As-Is Model

bdd [package] ESS Enterprise (As Is)

Domain
As-Is

* * «enterprise»
Residence Enterprise As-Is

Customer As-Is Intruder

«system» «external» «external»

Sec Sys Comm Network Emergency Services As-Is

1 *
Site Installation Central Monitoring
As-Is Station As-Is

Dispatcher Police

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 106
 ESS Operational Enterprise To-Be
Model

bdd [package] ESS Enterprise (To Be)

Domain «enterprise»
* ESS Operational Enterprise
* To-Be

«moe» OperationalAvailability = {>.99}

«moe» MissionResponseTime = {<5 min}
Intruder «moe» OperationalCost = {TBD}
«moe» CostEffectiveness
«external»
1..* MonitorSite () Emergency Services
1..*
DispatchEmergencyServices () *
Protected Site ProvideEmergencyResponse () Assess Report ()
Report Update ()
Customer Dispatch Police ()

*
«system» «external»
ESS Comm Network *

* Responder
* «external»
Property Dispatcher
«external»
Physical Environment

«external» «external»
Single-family Residence «external» Business
Multi-family Residence Police
Fire Paramedic

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 107
 System Use Cases - Operate

uc [package] System Use Cases

Activate/Dea-
ctivate
«include» Operate

«include» «extend»

Respond
Monitor Site

Respond to Respond to Respond to

Break-In Fire Medical

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 108
 System Scenario: Activity Diagram
Monitor Site (Break-In)
act Monitor Site (break in)
«actor» «system» «external»
Intruder ESS Emergency Services

System On
Enter Property
Status Update System Off

DetectEntry

ValidateEntry

Validated Entry

Conduct Theft

[Alert]
GenerateAlarm ReportEntry

Exit Property Assess Report

InternalMonitor

[Alert]

DetectExit

Report Update Dispatch Police

ReportExit
[Alert]

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 109
 ESS Elaborated Context Diagram

ibd [domain] Domain-To-Be

: EmergencyServicesIn
«external» «system»
: Emergency Services : EmergencyServicesOut : ESS
«perf» Power = {<100 watts}
«perf» Reliability
«phys» SiteInstallDwg
«store» EventLog
: CustomerOut : CustomerIn «store» SystemState
DetectEntry ()
: Customer DetectExit ()
ReportEntry ()
ReportExit ()
GenerateAlarm ()
ValidateEntry ()
: AlarmSignal : IntruderSignal InternalMonitor ()
DetectFire ()
: Intruder DetectMedicalEmergency ()
RequestUserID ()
«external» ValidateUserID ()
: Property
: Power : Door Input : Window Input SetTimer ()
ActivateSystem ()
ProtectPrivacy ()
Status Update ()
«external» DetectFault ()
: Physical Environment
: Envronmental_In

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 110
 ESS Logical Decomposition (Partial)
bdd [package] ESS Logical Decomposition
«logical»
Customer Output Mgr
«system»
ESS «logical»
Customer Input Mgr
* «logical» «logical»
Entry Sensor «logical» I/O Item Manager
Entry/Exit Monitor
«logical»
* Exit Sensor «logical»
Emergency Monitor
«logical»
* Perimeter Sensor «logical»
Event Monitor
* «logical»
Environment Sensor «logical»
Sensor

«logical»
Emer Serv I/F

«logical»
Customer I/F
«logical»
«logical» External I/F Manager
Alarm Generator

«logical»
Alarm I/F

«logical»
Fault Mgr «logical»
Support Service Manager
«logical»
User Validation Mgr

«logical»
Sys Config Mgr

4/15/2008 Copyright © 2006-2008 by Object Management Group. 111

 Detect Entry Subsystem Scenario

act detectEntry
«subsystem»
entry/exit subsystem
«logical» «logical» «logical»
Entry Sensor Entry/Exit Monitor Event Monitor

«continuous»
Door Input

«continuous» Alert Status

Window Input
di : Door Input
wi : Window Input ee : SensedEntry estatus status
Sense State Change Detect Event Record Event
sensor : SensorOutput status[State=BreakInResponse]
log : Event

[Else]

«store»
Event Log

4/15/2008 Copyright © 2006-2008 by Object Management Group. 112

 Elaborating Logical Component

«logical» «logical» «logical»

Entry Sensor Entry/Exit Monitor Event Monitor

Sense State Change() Detect event() Record event()

«store»: Event Log

•Added operations from Detect Entry / Detect Exit logical scenario

•These operations support entry/exit subsystem

4/15/2008 Copyright © 2006-2008 by Object Management Group. 113

 ESS Logical Design –
Example Subsystem
subsystem Entry/Exit S ubsystem

ibd [subsystem]Entry/Exit Subsystem

: Door Input m+n : SensedEntry

«logical»
«logical» : Entry/Exit Monitor
: Entry Sensor
: Door Input
: SensedExit : Entry/Exit Alert Status
: Window Input

m+n «logical»
: Window Input : Event Monitor
«logical»
: Alert Status
: Exit Sensor
«store»
: Event Log

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 114
 ESS Logical Design (Partial)
ibd [system] ESS

: AlarmSignal
«logical»
: Window Input
: Alarm Generator
«logical»
: Entry Sensor
: SensedEntry
: Door Input
: AlarmCmd

: BIT «logical»
: Entry/Exit Monitor : Alert Status
«logical»
: Alarm I/F

: Window Input : Entry/Exit Alert Status

«logical» : SensedExit
: Exit Sensor «logical»
: Door Input : Event Monitor
«logical»
: Alert Status : Emergency Monitor
«store»
: Event Log
: BIT
: EmergencyData

«logical» : BIT «logical» «logical»

: Perimeter Sensor : Fault Mgr : Emer Serv I/F : Emergency
ServicesOut

: BIT
: Fault

: FaultReport : Lamp
«logical» «logical» «logical»
: Environment Sensor : Customer Output Mgr : Customer I/F

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 115
 ESS Allocation Table (partial)
• Allocating Logical Components to HW, SW, Data, and Procedures
components

Logical Components
Entry Perimeter Entry/Exit Event Site Customer Customer System Alarm
Type Sensor Exit Sensor Sensor Monitor Monitor Comms I/F Event Log I/F Output Mgr Status Fault Mgr Generator Alarm I/F

«software» Device Mgr X

SF Comm I/F X
User I/F X
Event Mgr X X
Site Status Mgr X
Physical Components

Site RDBMS X X
CMS RDBMS X
«data» Video File X
CMS Database X
Site Database X X
«hardware» Optical Sensor X X
DSL Modem X
User Console X
Video Camera X
Alarm X

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 116
 ESS Deployment View
ESS

ibd [system] ESS

«node»
«node» * : Central Monitoring Station
: MF Residence Installation
«hardware»
«hardware» : Help Desk Client
: Phone Lines
«node» * «hardware»
: Business Installation «hardware»
«external» : MS LAN
: Application Server
: Comm
Network allocatedFrom
«software» MS Comm I/F «internal actor»
: SF Residence Installation * «software» MS Event Monitor : Help Desk Operator
«software» PS Report Mgr
«hardware» «software» PS Request Mgr
: PS Comm «software» Site Interface Mgr
* 2 I/F
«hardware» «hardware» «hardware»
: Optical Sensor : Video Camera : DSL Modem

«hardware»
: DB Server
«hardware» «hardware»
: Site Processor : NW Hub «hardware» allocatedFrom
: Alarm «hardware» «software» CMS RDBMS
allocatedFrom allocatedFrom «hardware» «data» CMS Database
«software» SF Comm I/F : CM Server
«software» Device Mgr : Video Server
«software» Event Mgr allocatedFrom
«software» Site Config Mgr «software» S/W Distrib Mgr
«software» Site RDBMS «software» System CM
«software» Site Status Mgr
«software» User I/F
«software» User Valid Mgr 2
«hardware»
: DVD-ROM Drive
allocatedFrom
«data» Site Database
«hardware» «hardware»
: Site Hard Disk : User Console
allocatedFrom
«data» Site Database

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 117
 ESS Parametric Diagram
To Support Trade-off Analysis

par [block] EnterpriseEffectivenessModel

{CE= Sum(w1*u(OA)+w2*u
(MRT)+w3*u(OC))}
«moe»
MissionResponseTime

of1 : ObjectiveFunction

MRT CE
«moe» «moe»
OperationalAvailability CostEffectiveness
OA
OC

«moe»
OperationalCost

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 118
 Entry/Exit Test Case

sd Entry/Exit Detection Test

Description «testComponent» «sut» «sut» «sut» «sut»

:IntruderEmulator «hardware» «hardware» «hardware» «hardware»
Door[1] Window[4] :Site Processor :DSL Modem
/:Optical Sensor /:Optical Sensor

seq seq
Intruder enters through front Enter
door
Door sensor detects entry : SensedEntry
New alert status sent to central IntruderEntry :
system Alert Status
Intruder leaves through lounge Exit
window
Window sensor detects exit : SensedExit
Changed alert status sent to Intruder Exit :
central system Alert Status

4/15/2008 Copyright
Copyright © 2006-2008
© Lockheed by Object Management
Martin Corporation 2000 – 2003Group.
& INCOSE 2004-2006 119
 OOSEM Browser View
Artisan Studio™ Example

4/15/2008 Copyright © 2006-2008 by Object Management Group. 120

Copyright © Lockheed Martin Corporation 2000 – 2003 & INCOSE 2004-2006
SysML in a Standards Framework
 Systems Engineering Standards
Framework (Partial List)

Process
Standards EIA 632 ISO 15288 IEEE 1220 CMMI

Architecture
FEAF DoDAF MODAF Zachman FW
Frameworks

Modeling
Methods HP OOSE SADT Other

Modeling &
IDEF0 SysML MARTE HLA MathML
Simulation
Standards System Modeling Simulation & Analysis

Interchange &
Metamodeling MOF XMI STEP/AP233
Standards

4/15/2008 Copyright © 2006-2008 by Object Management Group. 122

 ISO/IEC 15288
System Life Cycle Processes
Enterprise Processes Project Processes Technical Processes
5.3.2 5.5.2
Enterprise Environment Stakeholder Reqts
5.4.2
Management Process Definition Process
Project Planning Process
5.5.3
5.3.3
Reqts Analysis Process
Investment 5.4.3
Management Process Project Assessment 5.5.4
Process Architectural Design Process
5.3.4
System Life Cycle 5.5.5
Processes Management 5.4.4 Implementation Process
Project Control Process
5.3.5 5.5.6
Quality Integration Process
Management Process
5.4.5
5.5.7
5.3.6 Decision-
Decision-Making Process Verification Process
Resource
Management Process 5.5.8
5.4.6
Risk Management Transition Process
Process 5.5.9
Agreement Processes Validation Process
5.4.7
5.5.10
Configuration Management
5.2.2 Operation Process
Process
Acquisition Process
5.5.11
5.4.8 Maintenance Process
5.2.3 Information Management
Process 5.5.12
Supply Process Disposal Process

4/15/2008 Copyright © 2006-2008 by Object Management Group. 123

 Standards-based Tool Integration
with SysML

Systems Modeling Other Engineering

Tool Tools
Model/Data
Interchange
SV4 OV2

AP233/XMI
•
• .....
• ... .. -
• ..... -
-
-
-

OV7 TV2
-
-
-
-
• ..... • -
• ..... -
• ..... -
- -
- -
- -
-

AP233/XMI
-
-
-
-
-
-
-
-
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
-
-
-
-
-
-
-
-
-
-

4/15/2008 Copyright © 2006-2008 by Object Management Group. 124

 Participating SysML Tool Vendors

• Artisan (Studio)
• EmbeddedPlus (SysML Toolkit)
– 3rd party IBM vendor
• No Magic (Magic Draw)
• Sparx Systems (Enterprise Architect)
• IBM / Telelogic (Tau and Rhapsody)
• TopCased
• Visio SysML template

4/15/2008 Copyright © 2006-2008 by Object Management Group. 125

Transitioning to SysML
 Using Process Improvement
To Transition to SysML

4/15/2008 Copyright © 2006-2008 by Object Management Group. 127

 MBSE Transition Plan
• MBSE Scope
• MBSE Responsibilities/Staffing
• Process guidance
– High level process flow (capture in SEMP)
– Model artifact checklist
– Tool specific guidance
• Tool support
– Modeling tool
– Requirements management
– CM
• Training
• Schedule
4/15/2008 Copyright © 2006-2008 by Object Management Group. 128
 Typical Integrated Tool
Environment

Project Management

SoS/ DoDAF / Business Process Modeling

Requirements Management
Product Data Management

Simulation & Visualization

Verification & Validation

Engineering Analysis
System Modeling
SysML
CM/DM

Software Modeling Hardware Modeling

UML 2.0 VHDL, CAD, ..

4/15/2008 Copyright © 2006-2008 by Object Management Group. 129

Summary and Wrap up
 Summary

• SysML sponsored by INCOSE/OMG with broad industry and

vendor participation and adopted in 2006
• SysML provides a general purpose modeling language to support
specification, analysis, design and verification of complex
systems
– Subset of UML 2 with extensions
– 4 Pillars of SysML include modeling of requirements, behavior,
structure, and parametrics
• Multiple vendor implementations available
• Standards based modeling approach for SE expected to improve
communications, tool interoperability, and design quality
• Plan SysML transition as part of overall MBSE approach
• Continue to evolve SysML based on user/vendor/researcher
feedback and lessons learned

4/15/2008 Copyright © 2006-2008 by Object Management Group. 131

 References
• OMG SysML website
– http://www.omgsysml.org
– Refer to current version of SysML specification, vendor links, tutorial, and papers
• UML for Systems Engineering RFP
– OMG doc# ad/03-03-41
• UML 2 Superstructure v2.1.2
– OMG doc# formal/2007-11-02
• UML 2 Infrastructure v2.1.2
– OMG doc# formal/2007-11-04

PAPERS
• Integrating Models and Simulations of Continous Dynamics into SysML
– Thomas Johnson, Christiaan Paredis, Roger Burkhart, Jan ‘2008
• Simulation-Based Design Using SysML - Part 1: A Parametrics Primer
– RS Peak, RM Burkhart, SA Friedenthal, MW Wilson, M Bajaj, I Kim
• Simulation-Based Design Using SysML - Part 2: Celebrating Diversity by Example
– RS Peak, RM Burkhart, SA Friedenthal, MW Wilson, M Bajaj, I Kim
• SysML and UML 2.0 Support for Activity Modeling,
– Bock. C., vol. 9 no.2, pp. 160-186, Journal of International Council of Systems Engineering, 2006.
• The Systems Modeling Language,
– Matthew Hause, Alan Moore, June ' 2006.
• An Overview of the Systems Modellng Language for Products and Systems Development,
– Laurent Balmelli, Oct ' 2006.
• Model-driven systems development,
– L. Balmelli, D. Brown, M. Cantor, M. Mott, July ' 2006.

TUTORIAL AUTHORS
• Sanford Friedenthal ([email protected])
• Alan Moore ([email protected])
• Rick Steiner ([email protected])

4/15/2008 Copyright © 2006-2008 by Object Management Group. 132