OMG Systems Modeling Language (OMG SysML) Tutorial 19 June 2008 revb

Sanford Friedenthal Alan Moore Rick Steiner

Copyright 2006-2008 by Object Management Group. Published and used by INCOSE and affiliated societies with permission.

(emails included in references at end)

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.

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.

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.

Motivation & Background

SE Practices for Describing Systems

Past
Specifications Interface requirements System design Analysis & Trade-off Test plans

Future

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 Input

Power Equations

Vehicle Dynamics

Engine

Transmission

Transaxle

Mass Properties Model Structural Model Safety Model Cost 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)

AWACS

MCE (CRC)

LINK 16 AMDPCS LINK 16

FAAD C3I LINK 16 LINK 16 Patriot ICC

E-2C AWACS F/A-18

RIVET JOINT
MCE

F-15C

ABMOC Subsystem

SIAP
CG TAOM

Operator Interface Hardware

ACDS (CVN)

Power Power Generation and Distribution Power JTIDS Terminal

Voice Comm Hardware includes MSE

Power Power TCIM

Data Processing Terminal Hardware

Operational Models
2 Event/Action Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements Provide SA/Support Engagements CEC Information Exchange Requirements - Classified SECRET when filled in 3 4 5 6 7 Sending Receiving Critical Format Node Node Radar measurements to support data fusion composite Host CEP Yes Binary IAW IDD tracking IFF measurements to support data fusion and composite Host CEP Yes Binary IAW IDD tracking IFF interrogation requests to support data fusion and Host CEP Yes Binary IAW IDD composite tracking ID Changes to support data Host CEP Yes Binary IAW IDD fusion and composite tracking Information Characterization Navigation data to support data Host fusion and composite tracking Engagement Support Requests to support data fusion and composite tracking Track number management to support data fusion and composite tracking Composite Track State Update to support data fusion and composite tracking Associated Measurement Reports to support data fusion and composite tracking IFF Assignments to support data fusion and composite tracking ID recommendations to support data fusion and composite tracking CEP Yes 8 Class 9 Latency: SA/Eng Support 10 11 Message Remarks Error Rate REF: CEC A-spec Table 3-3 and Host reqmts

DDG-51 AEGIS Destroyer

Software EPLRS or SINGARS Terminal PLGR (GPS) Power Voice & TADIL-B Data

Power Force Level Control System

Patriot ICC

Power A2C2 Subsystem Operator Interface Power Hardware Power Generation and Distribution Power Voice & TADIL-B Data JTIDS Terminal Power
OP 5.1.1 Comm Op Info

Power

Voice Comm Hardware includes MSE

1 Rationale/UJTL Number

FAAD C3I AMDPCS

Data Processing Terminal Hardware Software

TCIM

Secret xx secs/xx secs

xx %

OP 5.1.1 Comm Op Info

Secret xx secs/xx secs

xx % Respond w hen requested

Power Force Level Control System Power

EPLRS or SINGARS Terminal

OP 5.1.1 Comm Op Info

Secret xx secs/xx secs Secret xx secs/xx secs

xx % xx %

Power PLGR (GPS)

OP 5.1.1 Comm Op Info

OP 5.1.1 Comm Op Info

Binary IAW IDD Secret xx secs/xx secs

xx %

REF:CEC SRS and Host Nav. spec

OP 5.1.1 Comm Op Info

Host

CEP

Yes

Binary IAW IDD Secret xx secs/xx secs

xx %

AEGIS only Changes sent immediately REF: CEC IDDs for each host REF: CEC A-spec Table 3-3. SPY only When assigned or changed When assigned or changed REF: CEC A-spec Table 3-3. SPY only

OP 5.1.1 Comm Op Info

Host-CEP CEP-Host

Yes

Binary IAW IDD Secret xx secs/xx secs

xx %

OP 5.1.1 Comm Op Info

CEP

Host

Yes

Binary IAW IDD Secret xx secs/xx secs

xx %

OP 5.1.1 Comm Op Info

CEP

Host

Yes

Binary IAW IDD Secret xx secs/xx secs

xx %

OP 5.1.1 Comm Op Info

CEP

Host

Yes

Binary IAW IDD Secret xx secs/xx secs

xx %

Network Plan CID Criteria Network Network Track Data Receive Network Track Data Track File 11 Correlate Track Files 12 JDN Correlation S/W Module Network Interface S/W
Network Interface Module

OP 5.1.1 Comm Op Info

CEP

Host

Yes

Binary IAW IDD Secret xx secs/xx secs

xx %

OP 5.1.1 Comm Op Info

Sensor cues to support data CEP fusion and composite tracking

Host

Yes

Binary IAW IDD Secret xx secs/xx secs

xx %

Correlated Track

Manage BMDS Track File Data

Track Management Module

BMDS Track
Correlation Module Track File HIC

13
Attempt to Correlate with BMDS Track Track Data Request Possible BMDS Track File Matches

Track Data Network Track MSG

Track File Request

Track Data

Track Mangement S/W Module

HIC

Send Track File Data

System Models
Session Activated / initialize Idle Network Track File Received ( File Data ) [ number tracks > 0 ] / Input Network Track

BMDS Track Data

Correlate Tracks

BMDS Track Data

Correlation Results Verify CID, Correlation, and Assoicated Track Data Correlation Possible yes no CreateCorrelation Complete ( Correlation New Results BMDS Track ) [ set not null ] / Send Results Update Track File Data

BMDS Track Display

Correlating TracksMonitor Correlation

Process On entry / match state vectors Do / corr state vectors Do / corr LPE Do / corr PIP Do / corr RCS Do / corr CID On exit / corr BMDS Track #

Receiving Network Track File Data On entry / receive file data Do / store track data On exit / request matching data

BMDS Track Data Track MSG Data Send BMDS Track Data to JDN

Prepared Track MSG

corr fail / is new BMDS Track corr success / is corr BMDS Track

BMDS Track File Data Received ( File Data ) / Correlate Tracks Receiving BMDS Track File Data On entry / receive file data Do / store track data

BMDS Track File Request Sent ( Request ) / Pull BMDS Track Files

<TITLE>System Design<TITLE> <META http-equiv="REFRESH" <!--CSSDATA:966533483--> <SCRIPT src="/virtual/2000/code <LINK rel="stylesheet" href="/ <SCRIPT language="javascript"

Track Mangement Module HIC manages 1..* /current tracks /associated track data /CID data uses JDN assign CID () recommend CID () 1..* retrieve track file data () display track file data () communicates with 1 0..* 1 <<entity>> Track File Track Number CID /State Vector /Date-Time received from send track data () receive msg () parse msg () route msg data () build msg () send msg () 1 interface for 1 Correlation Module algorithm /tracks to be correlated correlation data decorrelation data correlate tracks () decorrelate tracks () retrieve track data () send track data () 1..*

1..*

ABMOC Subsystem Operator Interface Hardware Power Data Processing Terminal Hardware Power JTIDS Terminal Power TCIM Power Power Generation and Distribution Voice Comm Hardware includes MSE

<<interface>> Network Interface Module 0..* buffer capacity /msg data

Software EPLRS or SINGARS Terminal PLGR (GPS) Power Voice & TADIL-B Data

Power Force Level Control System

0..* correlates <<entity>> Network Track owning element Received Date-Time local track number receive () store () update () send () <<derived>> traces to <<entity>> Customer BMDS Track

Primary Key /associated data /history Customer_ID [PK1] Non-Key Attributes create () Customer_Name update () destroy () Purchase_Contact retrieve () Customer_Address

owns

Software License Primary Key Serial_Number [PK1] Non-Key Attributes Technical_Contact

Power
is subject to Client Call Operator Interface Primary Key Power Hardware Serial_Number [PK1] [FK]

A2C2 Subsystem Power Generation and Distribution Power Voice & TADIL-B Data JTIDS Terminal

Power

Voice Comm Hardware includes MSE

Component Models

consists of

createsData Processing

Terminal Hardware Software Tech Support System Entry Primary Key TSS_Entry_Number [PK1] Non-Key Attributes Windows_Version Power TSS_Description

TCIM Power

Software Release Primary Key Version_Number [PK1]

EPLRS or SINGARS Terminal Power PLGR (GPS)

Force Level Control System Power

Location Primary Key Status [PK1] [FK]

is a

Status Primary Key Status [PK1]

currently has

4/15/2008

Copyright 2006-2008 by Object Management Group.

10

Stakeholders Involved in System Acquisition

Customers Project Managers Developers/ Integrators

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
UML reused by SysML (UML4SysML) SysML extensions to UML (SysML Profile)

UML not required by SysML (UML UML4SysML)

4/15/2008

Copyright 2006-2008 by Object Management Group.

SysML Extensions -Blocks -Item flows -Value properties -Allocations -Requirements -Parametrics -Continuous flows -
16

SysML Diagram Taxonomy

SysML Diagram

Behavior Diagram

Requirement Diagram

Structure Diagram

Activity Diagram

Sequence Diagram

State Machine Diagram

Use Case Diagram

Block Definition Diagram

Internal Block Diagram

Package Diagram

Same as UML 2 Modified from UML 2 New diagram type

Parametric Diagram

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
interaction state machine
Slipping

stm TireTraction [State Diagram] m1:Brake d1:Traction Modulator Detector LossOfTraction

detTrkLos()Gripping

sendSignal()

RegainTraction

activity/ function
modBrkFrc()

modBrkFrc(traction_signal:boolean)

definition

use
sendAck()

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

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

Header
diagram usage diagramKind [modelElementType] modelElementName [diagramName]

Version: Description: Completion status: Reference: (User-defined fields)

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

Structural Diagrams
SysML Diagram

Behavior Diagram

Requirement Diagram

Structure Diagram

Activity Diagram

Sequence Diagram

State Machine Diagram

Use Case Diagram

Block Definition Diagram

Internal Block Diagram

Package Diagram

Same as UML 2 Modified from UML 2 New diagram type

Parametric Diagram

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 kine (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]

Use Cases

Enterprise

Architecture Team

Requirements

System

Requirements Team

Behavior

Logical Design

IPT A

Structure

Physical Design

IPT B

EngrAnalysis

Verification

IPT C

By Diagram Type
4/15/2008

By Hierarchy

By IPT
22

Copyright 2006-2008 by Object Management Group.

Package Diagram - Views

pkg SampleModel[by level]

Enterprise import view EngrAnalysis

Viewpoint represents the stakeholder perspective View conforms to a particular viewpoint

Imports model elements from multiple packages Can represent a model query based on query criteria

System

import

import Logical Design import conforms

EngrAnalysisViewpoint Physical Design viewpoint stakeholders= purpose= constructionRules= concerns= languages=

View and Viewpoint consistent with IEEE 1471 definitions

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
System Hardware Software Data Procedure Facility Person

block BrakeModulator allocatedFrom activityModulate BrakingForce values DutyCycle: Percentage

Compartment Label

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
Copyright 2006-2008 by Object Management Group. 24

4/15/2008

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
Block is a definition/type Captures properties, etc. Reused in multiple contexts

Usage
Part is the usage of a block in the context of a composing block Also known as a role
27

4/15/2008

Copyright 2006-2008 by Object Management Group.

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 Port
part1: part2:

required interface (calls the operations) Flow Port Flow Port

part1: part2:

item flow

4/15/2008

Copyright 2006-2008 by Object Management Group.

31

Delegation Through Ports

Delegation can be used to preserve encapsulation of block (black box vs white box) Interactions at outer ports of Block1 are delegated to ports 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 ibd [block]Block1[delegation]

Child1:

Child2:

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 Copyright 2006-2008 by Object Management Group. Constrain Value Properties

35

Behavioral Diagrams
SysML Diagram

Behavior Diagram

Requirement Diagram

Structure Diagram

Activity Diagram

Sequence Diagram

State Machine Diagram

Use Case Diagram

Block Definition Diagram

Internal Block Diagram

Package Diagram

Same as UML 2 Modified from UML 2 New diagram type

Parametric Diagram

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

Activity Diagram

Output Input
in1

Action
in1 out1 a1 out1 in2 [x>0] [x<=0] a2 out1

Input

in1 a3 out1 a4

in1

out1

Output

in1 a5

out1 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

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
<<optional>> input1 action1 <<optional>> output1

input2

action2

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 Note: The summary is an approximation of the semantics. 0 ..* optional item inputs & outputs 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
<<optional>> input1 action1 <<optional>> output1

input2

action2

output2

Call Operation Action (can call leaf level function)

Call Behavior Action

Accept Event Action (Event Data Pin often elided)

4/15/2008

Send Signal Action (Pins often elided)

43

Copyright 2006-2008 by Object Management Group.

Activity Diagram Example With Streaming Inputs and Outputs

act Activity
Start

Activity4 out1 optional <<optional>> input1 {stream} in2 in1 {stream}

output3

[x>1] [else] Activity 1 optional out1 {stream} [y>0] optional in1 {stream} Activity 2 out1 {stream} optional in1 {stream} Activity 3 <<optional>> output1 {stream}

input2

[else]

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)

Actions are enabled by default when activity is enabled Continuous flow means Time between tokens approaches zero Continuous Flow

Accept Event Action Will Terminate Execution

Interruptible 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 Brake Pressure :Braking

continuous Braking Pressure 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 ]

a1 : Detect Loss of Traction

p1 : TractLoss of1 p2 : TractLoss

a2 : Modulate Braking Force

a1 : Detect Loss of Traction

tl : TractLoss

a2 : Modulate Braking Force

Pins must have same characteristics (name, type etc.)

Pins
4/15/2008

ObjectNode
47

Copyright 2006-2008 by Object Management Group.

Explicit Allocation of Behavior to Structure Using Swimlanes

act [Activity] Prevent Lockup [ Actions ]

Activity Diagram (without Swimlanes)

a1 : Detect Loss of Traction

p1 : TractLoss of1 p2 : TractLoss

a2 : Modulate Braking Force

act [Activity] Prevent Lockup [ Swimlanes ]

<<allocate>> d1 : Traction Detector

<<allocate>> m1 : Brake Modulator

Activity Diagram (with Swimlanes)

a1 : Detect Loss of Traction

p1 : TractLoss of1 p2 : TractLoss

a2 : Modulate 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 << activity> > De tect Los s of Tra ction p1 <<block >> Tra ctLoss p2

a2 << activity> > Modulate Braki ng For ce

a1 : Detect Loss of Traction

p1 : TractLoss of1 p2 : TractLoss

a2 : Modulate Braking Force

Definition
4/15/2008

Use
49

Copyright 2006-2008 by Object Management Group.

SysML EFFBD Profile EFFBD - Enhanced Functional Flow Block Diagram

effbd act 2.4 Function in Multi-exit Construct {cc#1} Item 1 2.2 Multi-exit Function optional {cc#2} [ before third time ] Item 2 External Input 2.1 Serial Function optional 2.5 Function in an Iterate [ after third time ] External Output

Item 3

optional 2.6 Output Function

2.3 Function in Concurrency Item 4

optional

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 ref Idle [state = (accelerating/cruising)] ref Accelerate/Cruise [state = (idle)]

[state = (braking)] ref Brake

ref

Steer

ref

Park/ShutdownVehicle

UML 2 Sequence Diagram Scales 4/15/2008 by SupportingCopyright 2006-2008 by Object Management Group. Control Logic and Reference Sequences

52

Black Box Sequence (StartVehicle)

sd StartVehicleBlackBox driver:Driver vehicle:HybridSUV 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 1: StartVehicle epc:ElectricalPowerController

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
4/15/2008 Provided by Michael Chonoles 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] Satisfies requirement cceleration A
0.5 0.45 0.4 Accelleration (g) 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0 0 140 120 100 80 60 40 20 0 0 1800 1600 1400 Distance (ft) 1200 1000 800 600 400 200 0 0 5 10 Time (sec) 15 20 5 10 Time (sec) 15 20 5 10 Time (sec) 15 20

diagramDescription version=0.1" description=Constant 100 wheel horsepower, 4000 lb vehicle weight, simple drag" reference=Equations of Motion completeness=assumes perfect tire traction

Lifeline are value properties

Velocity (mph)

Timing Diagram Not Part of SysML

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

Idle accelerate/ when (speed = 0) releaseBrake/ Accelerating/ Cruising engageBrake/

Transition notation: trigger[guard]/action

Braking

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

Drive_The_Vehi cle Driver

include

Accelerate

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 Diagram

Requirement Diagram

Structure Diagram

Activity Diagram

Sequence Diagram

State Machine Diagram

Use Case Diagram

Block Definition Diagram

Internal Block Diagram

Package Diagram

Same as UML 2 Modified from UML 2 New diagram type

Parametric Diagram

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)

Element Name2 Element Name1 allocate allocate Element Name3

allocate part name : Element Name action name : Activity Name

Allocate Relationship

Explicit Allocation of Action to Part Property

block Block Name

block Block Name

part name
allocatedFrom

allocatedFrom elementTypeElement Name

part name

elementTypeElementName

Compartment Notation
4/15/2008

Callout Notation
64

Read as follows: part name has constraints that are allocated to/from an <<element type>> Element Name

Copyright 2006-2008 by Object Management Group.

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

hardware : Optical Sensor

* hardware : Video Camera

2 hardware : Alarm

hardware : Site Processor allocatedFrom software Device Mgr software Event Mgr software Site Config Mgr software Site RDBMS software Site Status Mgr software User I/F software User Valid Mgr

hardware : NW Hub allocatedFrom software SF Comm I/F

hardware : DSL Modem

hardware : DVD-ROM Drive allocatedFrom data Video File hardware : User Console

hardware : 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 Eco-Friendliness

requirement Performance requirement Power

deriveReqt

requirement Braking

requirement FuelEconomy

requirement Acceleration

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

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 OffRoadCapability requirement Acceleration requirement CargoCapacity

Supplier
deriveReqt deriveReqt deriveReqt

Client

Client depends on supplier (i.e., a change in supplier results in a change in client)

requirement Power

Supplier

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

requirement Loss of Fluid

block Brake System satisfy

requirement Reservoir

m:MasterCylinder satisfy

rationale The best-practice solution consists in assigning one reservoir per brakeline. See "automotive_d32_hdb.doc"

problem The master cylinder in previous version leaked.

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
stereotype ConfigurationItem
author: String version: String lastChanged: Date

author=John Doe version=1.2" lastChanged=Dec12, 2005

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

import

HSUVModel

4/15/2008

Copyright 2006-2008 by Object Management Group.

72

Cross Connecting Model Elements

1. Structure 2. Behavior

c allo

ate

value binding

satisfy

Verify
4/15/2008 3. Copyright Requirements 2006-2008 by Object ManagementParametrics 4. 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.
Dirty water @ 100 deg C Energy to condense Condense steam Boil Dirty water and Drain Residue Disposed residue and Pure water

A crude behavior diagram is shown.

Dirty water @ 20 deg C Steam

Heat Dirty water To 100 deg C

Residue Heat to Dirty water Heat to Boil 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
Copyright 2006-2008 by Object Management Group. 78

4/15/2008

Distiller Problem Package Diagram: Model Structure and Libraries

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 S0.0 S1.0 S2.0 S3.0 S4.0 S5.0 S5.1

name OriginalStatement PurifyWater HeatExchanger Boiler Drain WaterProperties WaterInitialTemp

text Describe a system for purifying dirty water. The system shall purify dirty water. Heat dirty water and condense steam are performed by a Boil dirty water is performed by a Boiler. Drain residue is performed by a Drain. water has properties: density 1 gm/cm3, temp 20 deg C, water has an initial temp 20 deg C

table [requirement] PurifyWater[Requirements Tree]

id

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

name

relation

id

name

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.

Dirty water @ 20 deg C

Dirty water @ 100 deg C

Steam

Energy to condense Condense steam

Pure water

Heat Dirty water To 100 deg C

Boil Dirty water

and Drain Residue

and

Residue Heat to Dirty water Heat to Boil water

Disposed residue

Actions (Functions)
4/15/2008

Control (Sequence) Things that flow (ObjectNodes)

82

Copyright 2006-2008 by Object Management Group.

Distiller Example Activity Diagram: Control-Driven: Serial Behavior

effbd act [activity] DistillWater [Simple Starting Point)

recovered:Heat coldDirty:H2O [liquid]

steam:H2O [gas] hotDirty:H2O [liquid] a3:CondenseSteam

pure:H2O [liquid]

a1:HeatWater

a2:BoilWater a4:DrainResidue

external:Heat predischarge :Residue

discharge :Residue

Continuous Distiller Here

Batch Distiller
83

4/15/2008

Copyright 2006-2008 by Object Management Group.

Distiller Example Block Definition Diagram: DistillerBehavior

Activities (Functions) Control (not shown 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

Batch Distiller Here

Continuous Distiller
Copyright 2006-2008 by Object Management Group. 86

4/15/2008

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

4/15/2008

Allocated ibd

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 bdd Initial Distiller Structure [ distiller breakdown (ports) ] <<block>> Distiller

condenser <<block>> Heat Exchanger constraints {h out.temp<=120, c in.temp<=60, h in.temp<=120, c out.temp<=90}

evaporator <<block>> Boiler top : Fluid bottom : Heat in : Fluid

drain <<block>> Valve out : Fluid

c in : Fluid c out : Fluid

h in : Fluid

middle : Fluid

h out : Fluid bottom : Fluid

Constraints (on Ports)

Flow 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

ibd

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

Swimlane Diagram

Exercise for student: Is allocation complete? Where is objectFlowof8?

Copyright 2006-2008 by Object Management Group. 92

4/15/2008

Parametric Diagram: Heat Balance

4/15/2008

Copyright 2006-2008 by Object Management Group.

93

Distiller Example Heat Balance Results

table IsobaricHeatBalance [Results of Isobaric Heat Balance 1 ]

main2 : H2O frm condenser

specific heat cal/gm-C latent heat cal/cm

Satisfies requirement WaterSpecificHeat Satisfies requirement WaterHeatOfVaporization Satisfies requirement WaterInitialTemp

1 540

main1 : H2O

main2 : H2O into evap

main3 : H2O

main4 : H2O

mass flow rate gm/sec temp C dQ/dt cooling water cal/sec dQ/dt steam-condensate cal/sec condenser efficency heat deficit dQ/dt condensate-steam cal/sec boiler efficiency dQ/dt in boiler cal/sec

6.8 6.8 1 1 1 20 100 100 100 100 540 540 1 0 540 1 540
Note: Cooling water needs to have 6.75x flow of steam! Need bypass between hx_water_out and bx_water_in!

1. Set these (steady state) 2. Solve for these

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

ibd

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 ] Distiller 1: Turn On 2: Power Lamp On 3: Operating Lamp On loop [while state=Operating] alt [level=high] 4: High Level Lamp On Operator Operate Distiller : Operator <<block>> : Distiller

[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 ] ibd diverter assembly splitter : Tee Fitting m2.2 : H2O

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

condenser : Heat Exchanger

evaporator : Boiler p in : Elec Power

drain : Valve

c : Boiler Signals main3 : H2O

v : V Ctrl htr pwr : Elec Power

blr ctl : Blr Sig feed ctl : V Ctrl main4 : H2O blr status : Blr Sig pwr in : Elec Power distiller pwr : Elec Power v2 : V Ctrl user : Control Panel pwr : Elec Power b : Boiler Signals bp : Elec Power v1 : V Ctrl drain ctl : V Ctrl

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 do /Power Light Off [bx level low]

Filling do /open feed : Valve

Operating do /bx heater on [bx1 level low] Level Low do /open feed : Valve [bx1 level high] Level High do /open drain : Valve Draining do /open drain : Valve [bx1 temp = 30]

[NOT bx1 level low] Warming Up do /bx1 heater on

Level OK do /shut all Valves

[NOT bx1 level low]

[NOT bx1 level high]

Cooling Off entry / bx1 heater OFF 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 Reqts
Manage System Development Status Technical data Plan

Define System Reqt's & Design

Test procedures System arch Allocated reqt's Procedures Data Hardware Software

Integrate & Test System

System

System Modeling Activities

Verified System Component

Component Modeling Activities

Develop System Components

Integrated Product Development (IPD) is essential to improve communications

4/15/2008

A Recursive V process that can be applied to multiple levels of the system hierarchy

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 101 Copyright Lockheed Martin Corporation 2000 2003Group.

System Modeling Activities OOSEM

Integrating MBSE into the SE Process
Analyze Needs

Mission use cases/scenarios Enterprise model Define

System Requirements

Requirements Traceability is Managed Through the Entire MBSE Process

System use cases/scenarios Elaborated context Define Reqts diagram

Optimize & Evaluate Alternatives

Logical Architecture

Logical architecture
Synthesize Physical Architecture

Engr Analysis Models Trade studies

Validate & Verify System

Test cases/procedures

Node diagram HW, SW, Data architecture

4/15/2008

Copyright Lockheed Martin Corporation 2000 2003Group. Copyright 2006-2008 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 2006-2008 by Object Management & INCOSE 2004-2006 103 Copyright Lockheed Martin Corporation 2000 2003Group.

ESS Requirements Flowdown

req [package] ESS Requirements Flowdown document Market Needs trace ESS Enterprise Models

trace requirement ESS System Specification id# = SS1 satisfy refine ESS System Models

requirement IntruderDetection id# = SS102 txt = System shall detect intruder entry and exit ...

requirement R111 deriveReqt id# = SS111 satisfy

satisfiedBy Entry/Exit Subsystem verifiedBy Entry/Exit Detection Test

requirement ESS Logical Requirements id# = LR1

ESS Logical Design Models refine

satisfy deriveReqt requirement ESS Allocated Requirements id# = AR1 refine ESS Allocated Design Models

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 104 Copyright Lockheed Martin Corporation 2000 2003Group.

Operational View Depiction

bdd [package] Enterprise (As Is)

Central Monitoring Station As-Is

Comm Network Residence

Dispatcher Police

Intruder

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 105 Copyright Lockheed Martin Corporation 2000 2003Group.

ESS Enterprise As-Is Model

bdd [package] ESS Enterprise (As Is) Domain As-Is

* Residence 1

enterprise Enterprise As-Is

Customer As-Is

Intruder

system Sec Sys

external Comm Network

external Emergency Services As-Is

* Central Monitoring Station As-Is Dispatcher Police

Site Installation As-Is

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 106 Copyright Lockheed Martin Corporation 2000 2003Group.

ESS Operational Enterprise To-Be Model

bdd [package] ESS Enterprise (To Be) * Domain To-Be * enterprise ESS Operational Enterprise moe OperationalAvailability = {>.99} moe MissionResponseTime = {<5 min} moe OperationalCost = {TBD} moe CostEffectiveness MonitorSite () DispatchEmergencyServices () ProvideEmergencyResponse ()

Intruder 1..*

1..* Protected Site

external Emergency Services * Assess Report () Report Update () Dispatch Police ()

Customer

system ESS

external Comm Network

* *

* * external Physical Environment external Property Dispatcher

Responder

external Single-family Residence

external Multi-family Residence

external Business Police Fire Paramedic

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 107 Copyright Lockheed Martin Corporation 2000 2003Group.

System Use Cases - Operate

uc [package] System Use Cases

Activate/Deactivate include Operate

include

extend Respond

Monitor Site

Respond to Break-In

Respond to Fire

Respond to Medical

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 108 Copyright Lockheed Martin Corporation 2000 2003Group.

System Scenario: Activity Diagram Monitor Site (Break-In)

act Monitor Site (break in)
actor Intruder system ESS
System On

external Emergency Services

Enter Property

Status Update

System Off

DetectEntry

ValidateEntry
Validated Entry

Conduct Theft
[Alert]

GenerateAlarm Exit Property

ReportEntry Assess Report

InternalMonitor
[Alert]

DetectExit Report Update ReportExit

[Alert]

Dispatch Police

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 109 Copyright Lockheed Martin Corporation 2000 2003Group.

ESS Elaborated Context Diagram

ibd [domain] Domain-To-Be : EmergencyServicesIn external : Emergency Services : EmergencyServicesOut

system : ESS

perf Power = {<100 watts} perf Reliability phys SiteInstallDwg store EventLog store SystemState : CustomerIn : CustomerOut DetectEntry () DetectExit () : Customer 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 2006-2008 by Object Management & INCOSE 2004-2006 110 Copyright Lockheed Martin Corporation 2000 2003Group.

ESS Logical Decomposition (Partial)

bdd [package] ESS Logical Decomposition system ESS * logical Entry Sensor logical Exit Sensor logical Perimeter Sensor logical Environment Sensor logical Customer Output Mgr logical Customer Input Mgr logical Entry/Exit Monitor logical Emergency Monitor logical Event Monitor logical Sensor logical I/O Item Manager

* *

logical Emer Serv I/F logical Customer I/F logical Alarm Generator logical Alarm I/F logical Fault Mgr logical User Validation Mgr logical Sys Config Mgr logical External I/F Manager

logical Support Service Manager

4/15/2008

Copyright 2006-2008 by Object Management Group.

111

Detect Entry Subsystem Scenario

act detectEntry subsystem entry/exit subsystem logical Entry/Exit Monitor

logical Entry Sensor continuous Door Input continuous Window Input

logical Event Monitor

Alert Status di : Door Input status Record Event log : Event

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

[Else] store Event Log

4/15/2008

Copyright 2006-2008 by Object Management Group.

112

Elaborating Logical Component

logical
Entry Sensor Sense State Change()

logical
Entry/Exit Monitor Detect event()

logical
Event Monitor 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 logical : Entry Sensor : Door Input : SensedExit : Window Input m+n : Window Input logical : Exit Sensor logical : Event Monitor : Alert Status store : Event Log : Entry/Exit Alert Status m+n : SensedEntry

logical : Entry/Exit Monitor

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 114 Copyright Lockheed Martin Corporation 2000 2003Group.

ESS Logical Design (Partial)

ibd [system] ESS
logical : Alarm Generator : SensedEntry : AlarmCmd : BIT logical : Entry/Exit Monitor : AlarmSignal

: Window Input logical : Entry Sensor : Door Input

: Alert Status

logical : Alarm I/F

: Window Input logical : Exit Sensor : Door Input : SensedExit

: Entry/Exit Alert Status logical : Event Monitor store : Event Log : Alert Status

logical : Emergency Monitor

: BIT

: EmergencyData

logical : Perimeter Sensor

: BIT

logical : Fault Mgr

logical : Emer Serv I/F

: Emergency ServicesOut

: BIT

: Fault

logical : Environment Sensor

logical : Customer Output Mgr

: FaultReport

logical : Customer I/F

: Lamp

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 115 Copyright Lockheed Martin Corporation 2000 2003Group.

ESS Allocation Table (partial)

Allocating Logical Components to HW, SW, Data, and Procedures components

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

X X X X X X X X X X X X X X X X X
Copyright 2006-2008 by Object Management & INCOSE 2004-2006 116 Copyright Lockheed Martin Corporation 2000 2003Group.

Physical Components

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

4/15/2008

ESS Deployment View

ESS

ibd [system] ESS * node : MF Residence Installation hardware : Phone Lines * node : Business Installation external : Comm Network * hardware : PS Comm I/F hardware : MS LAN node : Central Monitoring Station hardware : Help Desk Client

hardware : Application Server allocatedFrom internal actor software MS Comm I/F software MS Event Monitor : Help Desk Operator software PS Report Mgr software PS Request Mgr software Site Interface Mgr

: SF Residence Installation

* hardware : Optical Sensor

2 hardware : Video Camera

hardware : DSL Modem

hardware : Site Processor allocatedFrom software Device Mgr software Event Mgr software Site Config Mgr software Site RDBMS software Site Status Mgr software User I/F software User Valid Mgr

hardware : NW Hub allocatedFrom software SF Comm I/F

hardware : DB Server hardware : Alarm allocatedFrom software CMS RDBMS data CMS Database

hardware : Video Server

hardware : CM Server allocatedFrom software S/W Distrib Mgr software System CM

hardware : DVD-ROM Drive allocatedFrom data Site Database hardware : Site Hard Disk allocatedFrom data Site Database hardware : User Console

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 117 Copyright Lockheed Martin Corporation 2000 2003Group.

ESS Parametric Diagram To Support Trade-off Analysis

par [block] EnterpriseEffectivenessModel moe MissionResponseTime

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

of1 : ObjectiveFunction moe OperationalAvailability MRT OA OC moe OperationalCost CE moe CostEffectiveness

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 118 Copyright Lockheed Martin Corporation 2000 2003Group.

Entry/Exit Test Case

sd Entry/Exit Detection Test Description testComponent :IntruderEmulator sut hardware Door[1] /:Optical Sensor sut hardware Window[4] /:Optical Sensor sut hardware :Site Processor sut hardware :DSL Modem

seq Intruder enters through front door Door sensor detects entry New alert status sent to central system Intruder leaves through lounge window Window sensor detects exit Changed alert status sent to central system

seq Enter : SensedEntry IntruderEntry : Alert Status Exit : SensedExit Intruder Exit : Alert Status

4/15/2008

Copyright 2006-2008 by Object Management & INCOSE 2004-2006 119 Copyright Lockheed Martin Corporation 2000 2003Group.

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 Architecture Frameworks Modeling Methods

EIA 632

ISO 15288

IEEE 1220

CMMI

FEAF

DoDAF

MODAF

Zachman FW

HP

OOSE

SADT

Other

Modeling & Simulation Standards Interchange & Metamodeling Standards

IDEF0 SysML

MARTE

HLA

MathML

System Modeling

Simulation & Analysis

MOF

XMI

STEP/AP233

4/15/2008

Copyright 2006-2008 by Object Management Group.

122

ISO/IEC 15288 System Life Cycle Processes

Enterprise Processes
5.3.2 Enterprise Environment Management Process 5.3.3 Investment Management Process 5.3.4 System Life Cycle Processes Management 5.3.5 Quality Management Process 5.3.6 Resource Management Process

Project Processes
5.4.2 Project Planning Process 5.4.3 Project Assessment Process 5.4.4 Project Control Process

Technical Processes
5.5.2 Stakeholder Reqts Definition Process 5.5.3 Reqts Analysis Process 5.5.4 Architectural Design Process 5.5.5 Implementation Process 5.5.6 Integration Process 5.5.7 Verification Process 5.5.8 Transition Process 5.5.9 Validation Process 5.5.10 Operation Process 5.5.11 Maintenance Process 5.5.12 Disposal Process

5.4.5 Decision-Making Process Decision5.4.6 Risk Management Process 5.4.7 Configuration Management Process 5.4.8 Information Management Process

Agreement Processes
5.2.2 Acquisition Process 5.2.3 Supply Process

4/15/2008

Copyright 2006-2008 by Object Management Group.

123

Standards-based Tool Integration with SysML

Systems Modeling Tool
OV2

Model/Data Interchange
AP233/XMI AP233/XMI

Other Engineering Tools

SV4

..... ..... .....

OV7
..... ..... ..... -

TV2

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

Requirements Management

CM/DM Product Data Management

Simulation & Visualization

SoS/ DoDAF / Business Process Modeling Verification & Validation

System Modeling SysML

Software Modeling UML 2.0

Hardware Modeling VHDL, CAD, ..

4/15/2008

Copyright 2006-2008 by Object Management Group.

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

A Practical Guide to SysML (Morgan Kaufmann) by Friedenthal, Moore, Steiner UML for Systems Engineering RFP
OMG doc# ad/03-03-41 OMG doc# formal/2007-11-02 OMG doc# formal/2007-11-04

UML 2 Superstructure v2.1.2 UML 2 Infrastructure v2.1.2

PAPERS Integrating Models and Simulations of Continous Dynamics into SysML

Thomas Johnson, Christiaan Paredis, Roger Burkhart, Jan 2008 RS Peak, RM Burkhart, SA Friedenthal, MW Wilson, M Bajaj, I Kim RS Peak, RM Burkhart, SA Friedenthal, MW Wilson, M Bajaj, I Kim Bock. C., vol. 9 no.2, pp. 160-186, Journal of International Council of Systems Engineering, 2006. Matthew Hause, Alan Moore, June ' 2006. Laurent Balmelli, Oct ' 2006. L. Balmelli, D. Brown, M. Cantor, M. Mott, July ' 2006.

Simulation-Based Design Using SysML - Part 1: A Parametrics Primer

Simulation-Based Design Using SysML - Part 2: Celebrating Diversity by Example SysML and UML 2.0 Support for Activity Modeling, The Systems Modeling Language, An Overview of the Systems Modellng Language for Products and Systems Development, Model-driven systems development,

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