SysML Tutorial Baseline To INCOSE 060524 Low Res

OMG Systems Modeling Language
(OMG SysML™)
Tutorial
11 July 2006
Sanford Friedenthal
Alan Moore
Rick Steiner
Copyright © 2006 by Object Management Group.
Published and used by INCOSE and affiliated societies with permission.
Caveat
• This material is based on version 1.0 of the SysML

specification (ad-06-03-01)
– Adopted by OMG in May ’06
– Going through finalization process
• OMG SysML Website

– http://www.omgsysml.org/
11 July 2006 Copyright © 2006 by Object Management Group. 2

Objectives & Intended Audience
At the end of this tutorial, you should understand the:
• Benefits of model driven approaches to systems engineering
• Types of SysML diagrams and their basic constructs
• Cross-cutting principles for relating elements across diagrams
• Relationship between SysML and other Standards
• High-level process 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
– Already familiar with system modeling & tools, or
– Want to learn about systems modeling
• Software Engineers who want to express systems concepts
• Familiarity with UML is not required, but it will help

Topics
• Motivation & Background (30)

• Diagram Overview (135)
• SysML Modeling as Part of SE Process (120)
– Structured Analysis – Distiller Example
– OOSEM – Enhanced Security System Example
• SysML in a Standards Framework (20)
• Transitioning to SysML (10)
• Summary (15)

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

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

Model Based Systems Engineering
Benefits
• Improved communications
• Assists in managing complex system development
– Separation of concerns
– Hierarchical modeling
– Facilitates impact analysis of requirements and design changes
– Supports incremental development & evolutionary acquisition
• Improved design quality
– Reduced errors and ambiguity
– More complete representation
• Early and on-going verification & validation to reduce risk
• Other life cycle support (e.g., training)
• Enhanced knowledge capture

System-of-Systems
Interactions
Boundaries
Modeling Needed to Manage System Complexity

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
Voice Comm
Operational Models
Operator Interface
SIAP
Power
Hardware Power Generation Hardware includes
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
Hardware Power
Node Node Support Error Rate
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
System Models
Request
Attempt to
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

Track Mangement S/W Module HIC File Data
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
<TITLE>System Design<TITLE>
Do / corr PIP Do / store track data
Track MSG Data Send BMDS Do / corr RCS On exit / request matching data
Track Data to Do / corr CID
JDN On exit / corr BMDS Track #
Prepared Track MSG
corr fail / is new BMDS Track

corr success / is corr BMDS Track
<META http-equiv="REFRESH"

BMDS Track File Request Sent ( Request
) / Pull BMDS Track Files
BMDS Track File Data
Received ( File Data ) /
Correlate Tracks
<SCRIPT src="/virtual/2000/code
Receiving BMDS Track File
Data
On entry / receive file data

Do / store track data
<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
Terminal Power TCIM
/State Vector buffer capacity /tracks to be correlated 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
Component Models
1
0..* Voice & TADIL-B Data
Power
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 Power
traces to /history Customer_ID [PK1] Serial_Number [PK1] Primary Key Operator Interface
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]

Stakeholders Involved
in System Acquisition
Developers/
Customers Integrators
Project
Managers
Vendors
Regulators Testers
Modeling Needed to Improve Communications

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 XMI and the evolving
AP233 standard (in-process)
SysML is Critical Enabler for Model Driven SE

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

UML/SysML Status
• UML V2.0
– Updated version of UML that offers significant capability for
systems engineering over previous versions
– Finalized in 2005 (formal/05-07-04)
• 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
– Addresses most of the requirements in the RFP
– Version 1.0 adopted by OMG in May ’06 / In finalization
– Being implemented by multiple tool vendors

SysML Team Members
• Industry & Government

– American Systems, BAE SYSTEMS, Boeing, Deere &
Company, EADS-Astrium, Eurostep, Lockheed Martin,
Motorola, NIST, Northrop Grumman, oose.de, Raytheon,
THALES
• Vendors
– Artisan, EmbeddedPlus, Gentleware, IBM, I-Logix, Mentor
Graphics, PivotPoint Technology, Sparx Systems, Telelogic,
Vitech Corp
• Academia
– Georgia Institute of Technology
• Liaison Organizations
– INCOSE, ISO AP233 Working Group

Diagram Overview
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 -
UML4SysML)

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 Pillars of SysML – ABS Example
1. Structure sd ABS_ActivationSequence [Sequence Diagram] 2. Behavior
bdd [package] VehicleStructure [ABS-Block Definition Diagram]
stm TireTraction [State Diagram]
m1:Brake
interaction
d1:Traction
«block» «block» Detector Modulator
«block»
Library::
Anti-Lock
Library::Elec LossOfTraction
act PreventLockup [Activity Diagram] state
Electronic tro-Hydraulic
Processor
Controller
Valve machine
detTrkLos()Gripping Slipping
ibd [block] Anti-LockController
d1 [Internal Block Diagram]
m1
activity/
RegainTraction
«block»
Traction
«block»
Brake d1:Traction
DetectLossOf
sendSignal() TractionLoss:
Modulate function
Traction BrakingForce
Detector Modulator Detector modBrkFrc(traction_signal:boolean)
c1:modulator
interface
modBrkFrc()
m1:Brake
definition use Modulator
sendAck()
req [package] VehicleSpecifications

[Requirements Diagram - Braking Requirements]
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
Vehicle System Braking Subsystem tf: tl: bf: c

Specification Specification
:BrakingForce f: :Accelleration
«requirement» «requirement» Equation Equation
StoppingDistance Anti-LockPerformance [f = (tf*bf)*(1-tl)] F: [F = ma]
id=“102” id=”337" a:
text=”The vehicle shall stop text=”Braking subsystem shall a:
from 60 mph within 150 ft prevent wheel lockup under all
on a clean dry surface.” braking conditions.”
v:
:DistanceEquation :VelocityEquation
[v = dx/dt] v: [a = dv/dt]
«deriveReqt»
x:
3. Requirements 4. Parametrics
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, seq, etc.)
– Model element type (activity, block, interaction, etc.)
– Model element name
– Descriptive 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:
Header Completion status:

Reference:
(User-defined fields)
«diagram usage»
diagramKind [modelElementType] modelElementName [diagramName]
Contents
Structural Diagrams
SysML Diagram

Package Diagram

Diagram
Modified from UML 2
New diagram type

Package Diagram
• Package diagram is used to organize the model

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

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
Allocated
Structure IPT B
Design
EngrAnalysis Verification IPT C
By Diagram Type By Hierarchy By IPT

Package Diagram - Views
pkg SampleModel [by level]
• Model is organized in
one hierarchy
Enterprise • Viewpoints can provide
«import»
insight into the model
using another principle
System «import»
«view»
EngrAnalysis
– E.g., analysis view
that spans multiple
«import» levels of hierarchy
«conforms» – Can specify diagram
Logical Design
«import» usages, constraints,
and filtering rules
EngrAnalysisViewpoint – Consistent with IEEE
Allocated
Design
1471 definitions
«viewpoint»
stakeholders=”…”
purpose=”…”
methods=”…”
Verification

Blocks are Basic Structural Elements
• Provides a unifying concept to describe the structure of an

element or system
«block»
– Hardware BrakeModulator
– Software
allocatedFrom
– Data «activity»Modulate
– Procedure BrakingForce
– Facility
values
– Person DutyCycle: Percentage
• Multiple compartments can describe the block characteristics

– Properties (parts, references, values)
– Operations
– Constraints
– Allocations to the block (e.g. activities)
– Requirements the block satisfies

Block 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 block
• Example - right-front:wheel
– Reference property (typed by a block)
• A part that is not owned by the enclosing block (not composition)
• Example - logical interface between 2 parts
– Value property (typed by value type)
• Defines a value with units, dimensions, and probability distribution
• Example
– Non-distributed value: tirePressure:psi=30
– Distributed value: «uniform» {min=28,max=32} tirePressure:psi

Using Blocks
• Based on UML Class from UML Composite Structure

– Eliminates association classes, etc.
– Differentiates value properties from part properties, add
nested connector ends, etc.
• Block definition diagram describes the relationship
among blocks (e.g., composition, association,
classification)
• 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

Block Definition vs. 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
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

Internal Block Diagram (ibd)
Blocks, Parts, Ports, Connectors & Flows
ibd [block] Anti-LockController Reference

[Internal Block Diagram] Property
Enclosing
c2:sensor (in, but not of)
Block
Interface s1:Sensor
Item Flow
c1:modulator d1:Traction
Interface Detector
Part
Connector m1:Brake
Modulator Port
Internal Block Diagram Specifies Interconnection of Parts

Reference Property Explained
S1 is a reference part in ibd

shown in dashed outline box
c2:sensor
Interface s1:Sensor
c1:modulator d1:Traction
Interface Detector
m1:Brake
Modulator

SysML Port
• Specifies interaction points on blocks and parts

– Supports integration of behavior and structure
• Port types
– Standard (UML) Port
• Specifies a set of operations and/or signals
• Typed by a UML interface
– Flow Port
• Specifies what can flow in or out of block/part
• Typed by a flow specification
2 Port Types Support Different Interface Concepts

Port Notation
provided interface
(provides the operations)
Standard
Port
required interface
(calls the operations)
Flow Port
Flow
Port
item flow

Delegation Through Ports
• Delegation can be used to ibd [block]Block1[delegation]
preserve encapsulation of
block Child1:
• Interactions at outer ports of

Block1 are delegated to ports
of child parts Child2:
• Ports must match (same kind,

types, direction etc.)
• (Deep-nested) Connectors can
break encapsulation if required
(e.g. in physical system
modeling)

Parametrics
• Used to express constraints (equations) between

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

Analysis with Design Models
Defining Vehicle Dynamics
Defining Reusable Equations for Parametrics

Vehicle Dynamics Analysis
v.chassis.tire. v.brake.abs.m1. v.brake.rotor.

Friction: DutyCycle: BrakingForce: v.Weight:
tf: tl: bf: m:
:BrakingForce f: :Accelleration
Equation Equation
{f = (tf*bf)*(1-tl)} F: {F = m*a}
a:
a:
v:
:DistanceEquation :VelocityEquation
{v = dx/dt} v: {a = dv/dt}
x:
v.Position:
Using the Equations in a Parametric Diagram to

11 July 2006 Constrain
Copyright © 2006Value
by Object Properties
Management Group. 36
Behavioral Diagrams
SysML Diagram

Package Diagram

Diagram
Modified from UML 2
New diagram type

Activities
• Activity used to specify the flow of inputs/outputs and

control, including sequence and conditions for
coordinating activities
• Secondary constructs show responsibilities for the
activities using swim lanes
• SysML extensions to Activities
– Support for continuous flow modeling
– Alignment of activities with Enhanced Functional Flow Block
Diagram (EFFBD)

Activity Diagram Notation
Activity
act MonitorTraction
WheelRevs Action
Initial Decision
Calculate
Node Wheel
Velocity
[loss of
AngularVelocity of traction]
Calculate
Calculate Modulation
Modulation
Fork Traction
Fr e que nc y Frequency
Speed
[else]
Calculate Car
Control Velocity
Flow
Object
SpeedoInput
Flow
Flow Activity
Final Final
Node Node
Activity
Pin
Parameter
Node
•Join and Merge symbols not included

•Activity Parameter Nodes on frame boundary correspond to activity parameters
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 PreventLockup [Activity Diagram] act PreventLockup [Activity Diagram]
Pins must
have same
characteristics
DetectLossOf
Traction
Loss: Modulate DetectLossOf
TractionLoss:
Modulate (name, type
Traction BrakingForce Traction BrakingForce
Traction
Loss:
etc.)
Pins ObjectNode
Explicit Allocation of Behavior to
Structure Using Swimlanes
act PreventLockup [Activity Diagram]
Activity Diagram DetectLossOf

TractionLoss:
Modulate
Traction BrakingForce
(without Swimlanes)
act PreventLockup [Swimlane Diagram]
«allocate» «allocate»
:TractionDetector :BrakeModulator
Activity Diagram
DetectLossOf Modulate
(with Swimlanes) Traction
TractionLoss:
BrakingForce
allocatedTo
«connector»c1:modulatorInterface

SysML EFFBD Profile
EFFBD - Enhanced Functional Flow Block Diagram
Aligning SysML with Classical Systems Engineering Techniques

Distill Water Activity Diagram
(Continuous Flow Modeling)
Continuous Flow
Interruptible
Region
Representing Distiller Example in SysML

Using Continuous Flow Modeling
Activity Decomposition
act PreventLockup [Activity Diagram]

bdd PreventLockup [Activity Breakdown]
«activity»
PreventLockup
Traction
a1:DetectLossOf Loss: a2:Modulate
a1 a2 Traction Traction
BrakingForce
Loss:
«activity» «activity»
DetectLossOf ModulateBrak
Traction ingForce
Definition Use

Interactions
• Sequence diagrams provide representations of

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

Black Box Interaction (Drive)
sd DriveBlackBox
driver:Driver vehicleInContext: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

by11Supporting
July 2006
Control Logic and Reference Sequences
Copyright © 2006 by Object Management Group. 46
Black Box Sequence (StartVehicle)
References Lifeline
Decomposition
For White Box
Interaction
Simple Black Box Interaction

White Box Sequence (StartVehicle)
Decomposition of Black Box Into White Box Interaction

Trial Result of Vehicle Dynamics
0.5
0.45
0.4
0.35
Accelleration (g)
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

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.

Operational States (Drive)
stm HSUVOperationalStates
Off keyOff/
start[in neutral]/start engine shutOff/stop engine Nominal

states only
Operate
Idle
Transition notation:
trigger[guard]/action
accelerate/
when (speed = 0)
releaseBrake/
Accelerating/
Braking
Cruising
engageBrake/

Use Cases
• Provide means for describing basic functionality in

terms of usages/goals of the system by actors
• Common functionality can be factored out via include
and extend relationships
• Generally elaborated via other behavioral
representations to describe detailed scenarios
• No change to UML

Operational Use Cases

Cross-cutting Constructs
• Allocations
• Requirements
SysML Diagram

Package Diagram

Diagram
Modified from UML 2
New diagram type

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

Different Allocation Representations
(Tabular Representation Not Shown)
Element
Name2
«allocate»
Element
Name1
«allocate»
Element
Name3
Allocate Relationship Explicit Allocation of

Activity to Swim Lane
«block»
BlockName
PartName
allocatedFrom
«elementType»ElementName
Compartment Notation Callout Notation

SysML Allocation of SW to HW
• In UML the deployment diagram is used to deploy artifacts to nodes
• In SysML allocation on ibd and bdd is used to deploy software/data to hardware
ibd [node] SF Residence
«node»
SF Resid ence In stallati on
* 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

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

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

Example of Derive/Satisfy Requirement
Dependencies
Supplier
Client
Client depends on supplier

(i.e., a change in supplier Supplier
results in a change in client)
Client
Arrow Direction Opposite Typical Requirements Flow-Down

Problem and Rationale
Problem and Rationale can be attached to any

Model Element to Capture Issues and Decisions
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

Stereotypes
Defining the Stereotype Applying the Stereotype

Applying a Profile and
Importing a Model Library

Cross Connecting Model Elements
1. Structure 2. Behavior
Anti-LockController satisfies
satisfies act PreventLockup [Swimlane Diagram]
Diagram] «requirement»
«requirement»
Anti-Lock
Anti-Lock «allocate» «allocate»
Performance
Performance act PreventLockup [Activity Diagram]
:TractionDetector :BrakeModulator
d1:TractionDetector
d1:TractionDetector
ate
allocatedFrom
allocatedFrom
c1:modulator «activity»DetectLos
«activity»DetectLos
d1:Traction
c
allo
c1:modulator
Interface OfTraction
Of Traction
Detector
Interface
c1:modulator
interface DetectLossOf Modulate
Modulate
TractionLoss:
m1:BrakeModulator
m1:BrakeModulator
m1:Brake Traction BrakingForce
BrakingForce
allocatedFrom
allocatedFrom Modulator
allocatedFrom
allocatedFrom
«ObjectNode» «activity»Modulate
«activity»Modulate
TractionLoss: BrakingForce
BrakingForce
values
value allocatedTo
«connector»c1:modulatorInterface
DutyCycle: Percentage binding
satisfy par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
req [package] VehicleSpecifications

[Requirements Diagram - Braking Requirements] v.chassis.tire. v.brake.abs.m1. v.brake.rotor.
Friction: DutyCycle: BrakingForce: v.Weight:

Vehicle System Braking Subsystem
Specification Specification tf: tl: bf: c
m:
«requirement» «requirement» :BrakingForce f: :Accelleration

StoppingDistance Anti-LockPerformance Equation Equation
F:
[f = (tf*bf)*(1-tl)] [F = ma]
id=“102” id=”337"
text=”The vehicle shall stop text=”Braking subsystem a:
from 60 mph within 150 ft shall prevent wheel lockup a:
on a clean dry surface.” under all braking conditions.”
v:
VerifiedBy SatisfiedBy :DistanceEquation :VelocityEquation
«interaction»MinimumStopp «block»Anti-LockController [v = dx/dt] v: [a = dv/dt]
ingDistance «deriveReqt»
x:
«deriveReqt»
«deriveReqt» v.Position:
verify
3. Requirements 4. Parametrics
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?
Distiller Types
Batch
Distiller
Continuous
Distiller

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

Distiller Problem – Package Diagram:
Model Structure and Libraries
pkg [model] Distiller [Model Overview]
DistillerRequirements DistillerUseCases
bdd [package] ValueTypes
«valueType»
Real
DistillerBehavior DistillerStructure
«valueType» «valueType» «valueType» «valueType»

temp press massFlowRate dQ/dt
unit = ºC unit = N/m^2 unit = gm/sec unit = cal/sec ValueTypes ItemTypes

dimension = dimension = dimension = dimension =
temperature pressure massFlowRate heatFlowRate
«valueType» «valueType» «valueType»

efficency specificHeat latentHeat
unit = null unit = cal/(gm*ºC) unit = cal/gm

dimension = dimension = dimension =
efficency specificHeat latentHeat

Distiller Example
Requirements Diagram
req [package] DistillerRequirements
Source
«requirement»
OriginalStatement
Id = S0.0
text = 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.
«requirement» «requirement» «requirement»

PurifyWater HeatExchanger WaterProperties
Id = S1.0 Id = S2.0 Id = S5.0
text = The system shall text = Heat dirty water and text = water has properties: density 1
purify dirty water. condense steam are performed by gm/cm3, temp 20 deg C, specific heat
a Counter Flow Heat Exchanger 1cal/gm deg C, heat of vaporization
540 cal/gm.
«requirement»
Boiler
Id = S3.0 «requirement»
WaterInitialTemp
text = Boil dirty water is performed
by a Boiler. Id = S5.1
«deriveReqt» text = water has an
«rationale» «requirement» initial temp 20 deg C
The requirement Drain
for a boiling
function and a Id = S4.0
boiler implies that text = Drain residue is performed by
the water must be a Drain.
purified by
distillation
«requirement»
DistillWater
Id = D1.0
text = The system shall purify water
by boiling it.
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

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)

Control-Driven: Serial Behavior
Batch
Distiller
Distiller Example – Block Definition
Diagram: DistillerBehavior
bdd [package] DistillerBehavior [Distiller Behavior Breakdown]
«activity»
DistillWater
a1 a2
HeatWater BoilWater Need to
Activities consider
(Functions) a3
phases
a4
of H20
CondenseSteam DrainResidue
Control
(not shown
on BDD) Things that flow (ObjectNodes)
Distiller Example – State Machine
Diagram: States of H2O
stm [block] H2O
Gas
Add Latent Heat Remove Latent Heat

of Vaporization of Vaporization
States
Liquid
Add Latent Heat Remove Latent Heat

of Liquification of Liquification
Transitions
Solid

I/O Driven: Continuous Parallel Behavior
act [activity] DistillWater [Parallell Continuous Activities)
loPress:Residue
coldDirty:H2O
[liquid] steam:H20 hiPress:Residue
[gas]
recovered:Heat
a4:DrainResidue
a1:HeatWater a3:CondenseSteam
hotDirty:H2O
[liquid]
a2:BoilWater
pure:H2O
external:Heat [liquid]
Continuous
Distiller
No Control Flow – Simultaneous Behavior

Distiller Example – Activity Diagram
(with Swimlanes): DistillWater
Parts

Diagram: DistillerStructure
Generic Subsystems Usage Names

(Blocks)
Diagram: Heat Exchanger Flow Ports
bdd [package] DistillerStructure [Structural Breakdown]
«block» «block»
Fluid Heat
«block» values values
Distiller temp:ºC dQ/dt:cal/s
press:kg/m^2
Constraints
(on Ports) hx1 drain
bx1
f2Out:Fluid in:Fluid
«block»
HeatExchanger
hIn:Fluid fIn:Fluid «block» «block»
Boiler qIn:Heat Valve out:Fluid
cIn:Fluid constraints
{cIn.temp <= 220}
f1Out:Fluid
{cIn.press <= 150}
{cOut.temp <= 220}
{cOut.press <= 150}
{hIn.temp <= 400} hOut:Fluid
{hIn.temp <= 1000}
cOut:Fluid {hIn.temp <= 400}
{hIn.temp <= 1000}
Flow Ports Generic Things

Generic Subsystems
(typed by things that flow) That Flow
(Blocks)
(Blocks)
Distiller Example – Internal Block
Diagram: Distiller Initial Design
ibd: [block] Distiller [DistillerBlockDiagram - ItemFlows]
m1:H2O m2:H2O s1:Residue s2:Residue
hx1:HeatExchanger bx1:Boiler drain:Valve
m3:H2O
q1:Heat
m4:H2O
Parts Flow Ports Connectors Things That Flow

(Blocks used In Context
in context) (ItemFlows)
Distiller Example –Internal Block
Diagram: Distiller with Allocation
ibd: [block] Distiller [DistillerBlockDiagram - ItemFlows]
allocatedFrom allocatedFrom allocatedFrom allocatedFrom

«objectNode»coldDirty:H2O «objectNode»hotDirty:H2O «objectNode»hiPress:Residue «objectNode»loPress:Residue
m1:H2O m2:H2O s1:Residue s2:Residue
hx1:HeatExchanger bx1:Boiler drain:Valve
allocatedFrom allocatedFrom allocatedFrom

«activity»a1:HeatWater «activity»a2:BoilWater «activity»a4:DrainResidue
«activity»a3:CondenseSteam
m3:H2O
q1:Heat
m4:H2O
allocatedFrom allocatedFrom allocatedFrom
«objectNode»External:Heat «objectNode»steam:H2O «objectNode»Pure:H2O
Allocation Compartment Allocation Callout

Distiller Example – Parametric Diagram:
Heat Balance Equations
par [block] Distiller [Simplified Isobaric Heat Balance Analysis}
Parts or {Qrate=(th-tc)*mRate/sh)}
ItemFlows water_in:H2O
mRate:
temp:ºC sh:
tin: SinglePhaseHeatXFR
Equation
massFlowRate:
gm/sec tout:
r1:
Qrate:
equivalent
hx_water_out:H2O {r1=r2} water_in:H2O
r2: Qrate:
specificHeat:
Value temp:ºC
condensing: lh:
cal/(gm*ºC)
massFlowRate:
Properties gm/sec
SimplePhaseChange
Equation
latentHeat:
cal/gm
mRate:
bx_steam_out:H2O
massFlowRate: Note: Underline =

gm/sec {Qrate=mRate*lh)} these are
invariant
r1:
properties of all
equivalent uses of H2O
{r1=r2} Qrate:
water_out:H2O
r2:
massFlowRate: boiling: lh:
Value
gm/sec
Constraints SimplePhaseChange
Equation Constraint
Bindings mRate:
callouts
heat_in:Heat
dQ/dt>:cal/
sec

Distiller Example – Heat Balance
Results
table IsobaricHeatBalance1 [Results of Isobaric Heat Balance]
Satisfies «requirement»
specific heat cal/gm-°C 1 WaterSpecificHeat
latent heat cal/cm 540 Satisfies «requirement»
WaterHeatOfVaporization
bx_steam_out
hx_water_out
bx_water_in
water_out
water_in
Satisfies «requirement»
WaterInitialTemp
mass flow rate gm/sec 6.75 6.75 1 1 1

temp °C 20 100 100 100 100
dQ/dt cooling water cal/sec 540

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

Updated DistillWater
act [activity] DistillWater [Revised Swimlane Diagram]
«allocate» «allocate» «allocate» «allocate»

drain:Valve loPress:Residue
hx1:HeatExchanger feed:Vave bx1:Boiler
«continuous»
coldDirty:H2O
[liquid] «continuous» «continuous»
recovered:Heat a4:DrainResidue
steam:H2O
[gas] «continuous»
pure:H2O
[liquid]
«streaming» «streaming»
a1:HeatWater a3:CondenseSteam
«streaming» hiPress:Residue
a2:BoilWater
«continuous»
hotDirty:H2O «continuous»
[liquid] hotDirty2:H2O
«continuous»
hotDirty1:H2O [liquid]
[liquid]
«continuous»
external:Heat a5:DivertFeed
ShutDown

Diagram: Updated Distiller

Distiller Example – Use Case and
Sequence Diagrams
seq OperateDistiller [Operational Sequence]
«actor» «block»
:User :Distiller uc DistillerUseCases [Operate Distiller]
TurnOn
Operate
Distiller
Distiller
PowerLampOn
User
OperatingLampOn
loop
alt
LevelHighLampOn
DrainingLampOn
LevelLowLampOn
TurnOff
PowerLampOff
Diagram: Distiller Controller

Distiller Example – State Machine
Diagram: Distiller Controller

Sample - Artisan Tool
OOSEM – ESS Example
System Development Process
System
Modeling
Activities
Component
Modeling
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
11 July 2006 CopyrightCopyright

© Lockheed© 2006 byCorporation
Martin Object Management Group.
2000 – 2003 & INCOSE 2004-2006 94
Systems Modeling Activities - OOSEM
Analyze
Needs
Major SE Development Activities
•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
Common Subactivities
2000 – 2003 & INCOSE 2004-2006 95
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

2000 – 2003 & INCOSE 2004-2006 96
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»

2000 – 2003 & INCOSE 2004-2006 97
Operational View Depiction
bdd [package] Enterprise (As Is)
Central Monitoring Station As-Is
Comm Network
Residence
Dispatcher Intruder
Police

2000 – 2003 & INCOSE 2004-2006 98
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

2000 – 2003 & INCOSE 2004-2006 99
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

2000 – 2003 & INCOSE 2004-2006 100
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

2000 – 2003 & INCOSE 2004-2006 101
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]

2000 – 2003 & INCOSE 2004-2006 102
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

2000 – 2003 & INCOSE 2004-2006 103
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

2000 – 2003 & INCOSE 2004-2006 104
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

2000 – 2003 & INCOSE 2004-2006 105
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
X X
Physical Components
Site RDBMS
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

2000 – 2003 & INCOSE 2004-2006 106
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
: 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
: Site Hard Disk : User Console
allocatedFrom

2000 – 2003 & INCOSE 2004-2006 107
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

2000 – 2003 & INCOSE 2004-2006 108
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

2000 – 2003 & INCOSE 2004-2006 109
OOSEM Browser View
Artisan Studio™ Example

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
Implemented
Methods HP OOSE SADT Other By Tools
Modeling &
IDEF0 SysML UPDM HLA MathML
Simulation
Standards System Modeling Simulation & Analysis
Interchange &
Metamodeling MOF XMI STEP/AP233
Standards
Data
Repository
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

Standards-based Tool Integration
with SysML
Systems Modeling Other SE Engineering

Tool Tools
Model/Data
Interchange
SV4 OV2
AP233/XMI
•
• .....
• ... .. -
• ..... -
-
-
-
OV7 TV2
-
-
-
-
• ..... • -
• ..... -
• ..... -
- -
- -
- -
-
AP233/XMI
-
-
-
-
-
-
-
-
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
- -
-
-
-
-
-
-
-
-
-
-
-

Participating SysML Tool Vendors
• Artisan
• EmbeddedPlus
– 3rd party IBM vendor
• Sparx Systems
• Telelogic (includes I-Logix)
• Vitech

UML Profile for DoDAF/MODAF
(UPDM) Standardization
• Current initiative underway to develop standard

profile for representing DODAF and MODAF products
– Requirements for profile issued Sept 05
– Final submissions expected Dec ‘06
• Multiple vendors and users participating
• Should leverage SysML

Transitioning to SysML
Using Process Improvement
To Transition to SysML

Integrated Tool Environment
Project Management
Engineering Performance Analysis
Specialty Engineering Analysis

SoS / DoDAF / Business Process Modeling
Requirements Management
Product Data Management
Verification & Validation

System Modeling
SysML
CM/DM
Software Modeling Hardware Modeling

UML 2 VHDL, CAD, ..

Summary and Wrap up
Summary
• SysML sponsored by INCOSE/OMG with broad industry and

vendor participation
• 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
• OMG SysML Adopted in May 2006
• Multiple vendor implementations announced
• Standards based modeling approach for SE expected to improve
communications, tool interoperability, and design quality

References
• OMG SysML website

– http://www.omgsysml.org
• UML for Systems Engineering RFP
– OMG doc# ad/03-03-41
• UML 2 Superstructure
– OMG doc# formal/05-07-04
• UML 2 Infrastructure
– OMG doc# ptc/04-10-14

SysML Tutorial Baseline To INCOSE 060524 Low Res

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SysML Tutorial Baseline To INCOSE 060524 Low Res

Uploaded by

Copyright:

Available Formats

OMG Systems Modeling Language

• This material is based on version 1.0 of the SysML

• OMG SysML Website

11 July 2006 Copyright © 2006 by Object Management Group. 2

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

11 July 2006 Copyright © 2006 by Object Management Group. 3

• Motivation & Background (30)

11 July 2006 Copyright © 2006 by Object Management Group. 4

• Analysis & Trade-off

Moving from Document centric to Model centric

Start Shift Accelerate Brake Control Power Vehicle

Integrated System Model Must Address Multiple Aspects of a System

11 July 2006 Copyright © 2006 by Object Management Group. 8

Modeling Needed to Manage System Complexity

11 July 2006 Copyright © 2006 by Object Management Group. 9

DDG-51 AEGIS Destroyer Software Power

Engagement Support Requests

Network Track Data Receive Network Track Data

Track Data Send Track

BMDS Track Data Correlate Tracks BMDS Track Data

Correlation Results Session Activated

corr fail / is new BMDS Track

On entry / receive file data

<LINK rel="stylesheet" href="/

11 July 2006 Copyright © 2006 by Object Management Group. 10

Modeling Needed to Improve Communications

11 July 2006 Copyright © 2006 by Object Management Group. 11

• A graphical modelling language in response to the UML for

• Supports the specification, analysis, design, verification, and

SysML is Critical Enabler for Model Driven SE

11 July 2006 Copyright © 2006 by Object Management Group. 12

• Is a visual modeling language that provides

11 July 2006 Copyright © 2006 by Object Management Group. 13

• UML for Systems Engineering (SE) RFP

11 July 2006 Copyright © 2006 by Object Management Group. 14

• Industry & Government

11 July 2006 Copyright © 2006 by Object Management Group. 15

11 July 2006 Copyright © 2006 by Object Management Group. 17

Behavior Requirement Structure

Same as UML 2 Parametric

New diagram type

11 July 2006 Copyright © 2006 by Object Management Group. 18

req [package] VehicleSpecifications

Vehicle System Braking Subsystem tf: tl: bf: c

Header Completion status:

Behavior Requirement Structure

Same as UML 2 Parametric

New diagram type

11 July 2006 Copyright © 2006 by Object Management Group. 21

• Package diagram is used to organize the model

11 July 2006 Copyright © 2006 by Object Management Group. 22

Behavior Logical Design IPT A

EngrAnalysis Verification IPT C

By Diagram Type By Hierarchy By IPT

11 July 2006 Copyright © 2006 by Object Management Group. 23

11 July 2006 Copyright © 2006 by Object Management Group. 24

• Provides a unifying concept to describe the structure of an

• Multiple compartments can describe the block characteristics

11 July 2006 Copyright © 2006 by Object Management Group. 25

• Property is a structural feature of a block

11 July 2006 Copyright © 2006 by Object Management Group. 26

• Based on UML Class from UML Composite Structure