OMG Systems Modeling Language (OMG SysML™) Tutorial

Transcription

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
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
11 July 2006
3
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)
11 July 2006
4
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
11 July 2006
6
System Modeling
Requirements
Start
Engine
Shift
Accelerate
Transmission
Brake
Transaxle
Control
Input
Power
Equations
Vehicle
Dynamics
Mass
Properties
Model
Structural
Model
Safety
Model
Cost
Model
Integrated System Model Must Address Multiple Aspects of a System
11 July 2006
7
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
11 July 2006
8
System-of-Systems
Interactions
Boundaries
Modeling Needed to Manage System Complexity
11 July 2006
9
Modeling at Multiple Levels
of the System
MCE (CRC)
MCE (CRC)
MCE (CRC)
AWACS
LINK 16
LINK 16
AMDPCS
FAAD C3I
LINK 16
LINK 16
Patriot ICC
E-2C
AWACS
F/A-18
RIVET JOINT
MCE
F-15C
ABMOC Subsystem
Operator Interface
Hardware
SIAP
Power Generation
and Distribution
ACDS (CVN)
Voice Comm
Hardware includes
MSE
Power
Operational Models
Power
Data Processing
Terminal
Hardware
DDG-51 AEGIS Destroyer
Power
Power
JTIDS
Terminal
TCIM
Power
Software
CG
EPLRS or SINGARS
Terminal
TAOM
PLGR (GPS)
Force Level
Control System
Voice & TADIL-B Data
Power
Power
Patriot ICC
A2C2 Subsystem
Operator Interface
Power
Hardware
AMDPCS
Power
Power Generation
and Distribution
Voice Comm
Hardware includes
MSE
OP 5.1.1 Comm Op Info
Provide SA/Support
Engagements
CEC Information Exchange Requirements - Classified SECRET when filled in
3
4
5
6
7
Sending Receiving
Information Characterization
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
Provide SA/Support
Engagements
Navigation data to support data
Host
Provide SA/Support
Engagements
Provide SA/Support
Engagements
Provide SA/Support
Engagements
Provide SA/Support
Engagements
Provide SA/Support
Engagements
Provide SA/Support
Engagements
Power
Data Processing
Terminal
Hardware
FAAD C3I
1
EPLRS or SINGARS
Terminal
Power
Rationale/UJTL Number
Event/Action
Provide SA/Support
Engagements
Provide SA/Support
Engagements
Provide SA/Support
Engagements
Power
JTIDS
Terminal
Software
2
TCIM
Power
Force Level
Control System
PLGR
(GPS)
Power
Network Plan
CID Criteria
Network
Network Track Data Receive Network Track Data
Track File
11
Correlate Track
Files
Correlation S/W
Module
Manage BMDS
Track File Data
Network Interface
Module
10
11
Message
Remarks
Error Rate
REF: CEC A-spec
Table 3-3 and
Host reqmts
xx %
xx %
Secret xx secs/xx secs
xx %
Respond w hen
requested
xx %
CEP
Yes
Binary IAW IDD Secret xx secs/xx secs
xx %
REF:CEC SRS and
Host Nav. spec
CEP
Yes
xx %
AEGIS only
Host-CEP CEP-Host
Yes
xx %
CEP
Host
Yes
xx %
CEP
Host
Yes
xx %
REF: CEC A-spec
Table 3-3. SPY
only
xx %
When assigned
or changed
xx %
When assigned
or changed
xx %
REF: CEC A-spec
Table 3-3. SPY
only
Host
CEP
CEP
Sensor cues to support data
CEP
Host
Host
Host
Yes
Yes
Yes
Changes sent
immediately
REF: CEC IDDs for
each host
BMDS Track
Track Management Module
Correlation Module
13
Track Data
Attempt to
Correlate with
BMDS Track
Track Data
Network Track MSG
HIC
Track Mangement S/W Module
9
Latency: SA/Eng
Support
Correlated Track
12
JDN
Network
Interface S/W
Provide SA/Support
Engagements
Engagement Support Requests
to support data fusion and
composite tracking
Track number management to
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
composite tracking
8
Class
BMDS Track Data
Verify CID,
Correlation, and
Assoicated Track
Data
Track File
Request
Possible
BMDS Track
File Matches
Track Data
Send Track
File Data
Correlate Tracks
BMDS Track Data
Session Activated
Update Track
File Data
yes
no
/ initialize
Complete ( Correlation
CreateCorrelation
New
Results
BMDS
Track ) [ set not null ] / Send Results
Idle
Network Track File Received ( File Data ) [ number tracks
> 0 ] / Input Network Track
Correlating TracksMonitor
Correlation
BMDS Track Display
Receiving Network Track File
Data
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 #
BMDS Track Data
Track MSG Data
System Models
Correlation Results
Correlation
Possible
Prepared Track MSG
HIC
Track File Request
Send BMDS
Track Data to
JDN
On entry / receive file data
Do / store track data
On exit / request matching data
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
<TITLE>System Design<TITLE>
<META http-equiv="REFRESH"

<SCRIPT src="/virtual/2000/code
<LINK rel="stylesheet" href="/
<SCRIPT language="javascript"
BMDS Track File Request Sent ( Request
) / Pull BMDS Track Files
Track Mangement Module
1..*
manages
HIC
/current tracks
/associated track data
/CID data
assign CID ()
recommend CID ()
1..* retrieve track file data ()
display track file data ()
JDN
1..*
uses
1..*
communicates with
ABMOC Subsystem
1
0..*
1
1
1
buffer capacity
/msg data
algorithm
/tracks to be correlated
correlation data
decorrelation data
receive msg ()
parse msg ()
route msg data ()
build msg ()
send msg ()
correlate tracks ()
decorrelate tracks ()
retrieve track data ()
send track data ()
receive ()
store ()
update ()
send ()
Data Processing
Terminal
Hardware
<<derived>>
traces to
Primary Key
/associated data
/history Customer_ID [PK1]
Non-Key Attributes
create () Customer_Name
update ()
destroy () Purchase_Contact
retrieve () Customer_Address
PLGR (GPS)
owns
Software License
Primary Key
Serial_Number [PK1]
Non-Key Attributes
Technical_Contact
consists of
Software Release
Primary Key
Version_Number [PK1]
11 July 2006
is a
Status
Primary Key
Status [PK1]
TCIM
Power
Power
Force Level
Control System
Power
is subject to
Client Call
Operator Interface
Primary Key
Power
Hardware
Serial_Number [PK1] [FK]
createsData Processing
Terminal
Hardware
Software
Tech Support System Entry
Primary Key
TSS_Entry_Number [PK1]
Non-Key Attributes
Windows_Version
Power
TSS_Description
Force Level
Control System
Location
Primary Key
Status [PK1] [FK]
Voice Comm
Hardware includes
MSE
Power
EPLRS or SINGARS
Terminal
correlates
<<entity>>
Customer
BMDS Track
Power
Power
JTIDS
Terminal
Software
1
0..*
<<entity>>
Network Track
Power Generation
and Distribution
Power
Correlation Module
<<interface>>
Network Interface Module
0..*
send track data ()
owning element
Received Date-Time
local track number
Operator Interface
Hardware
interface for
<<entity>>
Track File
Track Number
CID
/State Vector
/Date-Time
received from
A2C2 Subsystem
Power
Power Generation
and Distribution
Voice Comm
Hardware includes
MSE
Component Models
Power
JTIDS
Terminal
TCIM
Power
EPLRS or SINGARS
Terminal
Power
PLGR
(GPS)
Power
currently has
10
Stakeholders Involved
in System Acquisition
Developers/
Integrators
Customers
Project
Managers
Vendors
Regulators
Testers
Modeling Needed to Improve Communications
11 July 2006
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 XMI and the evolving
AP233 standard (in-process)
SysML is Critical Enabler for Model Driven SE
11 July 2006
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
11 July 2006
13
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
11 July 2006
14
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
11 July 2006
15
Diagram Overview
Relationship Between SysML and UML
UML 2
SysML
UML
not required
by SysML
(UML UML4SysML)
11 July 2006
UML
reused by
SysML
(UML4SysML)
SysML
extensions
to UML
(SysML
Profile)
17
SysML Diagram Taxonomy
SysML Diagram
Behavior
Diagram
Activity
Diagram
Sequence
Diagram
Requirement
Diagram
State Machine
Diagram
Use Case
Diagram
Structure
Diagram
Block Definition
Diagram
Same as UML 2
Internal Block
Diagram
Package Diagram
Parametric
Diagram
Modified from UML 2
New diagram type
11 July 2006
18
4 Pillars of SysML – ABS Example
1. Structure
bdd [package] VehicleStructure [ABS-Block Definition Diagram]
«block»
Library::
Electronic
Processor
ibd [block] Anti-LockController
[Internal Block Diagram]
m1
d1
«block»
Traction
Detector
definition
«block»
Brake
Modulator
c1:modulator
interface
interaction
stm TireTraction [State Diagram]
m1:Brake
d1:Traction
Modulator
Detector
LossOfTraction
act PreventLockup [Activity
Diagram]
«block»
Library::Elec
tro-Hydraulic
Valve
«block»
Anti-Lock
Controller
2. Behavior
sd ABS_ActivationSequence [Sequence Diagram]
d1:Traction
Detector
detTrkLos()Gripping
Slipping
RegainTraction
TractionLoss:
DetectLossOf
sendSignal()
Traction
modBrkFrc(traction_signal:boolean)
activity/
function
Modulate
BrakingForce
modBrkFrc()
m1:Brake
Modulator
use
state
machine
sendAck()
req [package] VehicleSpecifications
[Requirements Diagram - Braking Requirements]
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
Vehicle System
Specification
Braking Subsystem
Specification
«requirement»
StoppingDistance
«requirement»
Anti-LockPerformance
id=“102”
text=”The vehicle shall stop
from 60 mph within 150 ft
on a clean dry surface.”
id=”337"
text=”Braking subsystem shall
prevent wheel lockup under all
braking conditions.”
tf:
tl:
bf:
:BrakingForce
Equation
[f = (tf*bf)*(1-tl)]
c
f:
:Accelleration
Equation
[F = ma]
F:
a:
a:
:DistanceEquation
[v = dx/dt]
v:
v:
:VelocityEquation
[a = dv/dt]
«deriveReqt»
x:
3. Requirements
11 July 2006
4. Parametrics
19
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:
Completion status:
Reference:
(User-defined fields)
Header
«diagram usage»
diagramKind [modelElementType] modelElementName [diagramName]
Contents
11 July 2006
20
Structural Diagrams
SysML Diagram
Behavior
Diagram
Activity
Diagram
Sequence
Diagram
Requirement
Diagram
State Machine
Diagram
Use Case
Diagram
Structure
Diagram
Block Definition
Diagram
Same as UML 2
Internal Block
Diagram
Package Diagram
Parametric
Diagram
Modified from UML 2
New diagram type
11 July 2006
21
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)
11 July 2006
22
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
Allocated
Design
IPT B
EngrAnalysis
Verification
IPT C
By Hierarchy
By IPT
By Diagram Type
11 July 2006
23
Package Diagram - Views
pkg SampleModel [by level]
• Model is organized in
one hierarchy
• Viewpoints can provide
insight into the model
using another principle
Enterprise
«import»
System
«import»
«view»
EngrAnalysis
«import»
Logical Design
Allocated
Design
«conforms»
«import»
EngrAnalysisViewpoint
«viewpoint»
stakeholders=”…”
purpose=”…”
methods=”…”
– E.g., analysis view
that spans multiple
levels of hierarchy
– Can specify diagram
usages, constraints,
and filtering rules
– Consistent with IEEE
1471 definitions
Verification
11 July 2006
24
Blocks are Basic Structural Elements
•
Provides a unifying concept to describe the structure of an
element or system
–
–
–
–
–
–
•
Hardware
Software
Data
Procedure
Facility
Person
«block»
BrakeModulator
allocatedFrom
«activity»Modulate
BrakingForce
values
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
11 July 2006
25
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
11 July 2006
26
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
11 July 2006
27
Block Definition vs. Usage
Block Definition Diagram
bdd [package] VehicleStructure [ABS-Block Definition Diagram]
«block»
Library::
Electronic
Processor
d1
«block»
Traction
Detector
«block»
Anti-Lock
Controller
m1
«block»
Brake
Modulator
c2:sensor
Interface
s1
«block»
Sensor
c1:modulator
Interface
s1:Sensor
d1:Traction
Detector
m1:Brake
Modulator
Usage
Definition
– Block is a definition/type
– Captures properties, etc.
– Reused in multiple contexts
11 July 2006
Internal Block Diagram
– Part is the usage in a
particular context
– Typed by a block
– Also known as a role
28
Internal Block Diagram (ibd)
Blocks, Parts, Ports, Connectors & Flows
Enclosing
Block
Reference
Property
c2:sensor
Interface
(in, but not of)
c1:modulator
Interface
Connector
s1:Sensor
d1:Traction
Detector
m1:Brake
Modulator
Item Flow
Part
Port
Internal Block Diagram Specifies Interconnection of Parts
11 July 2006
29
Reference Property Explained
S1 is a reference part in ibd
shown in dashed outline box
c2:sensor
Interface
c1:modulator
Interface
s1:Sensor
d1:Traction
Detector
m1:Brake
Modulator
11 July 2006
30
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
11 July 2006
31
Port Notation
provided interface
(provides the operations)
Standard
Port
required interface
(calls the operations)
Flow Port
Flow
Port
item flow
11 July 2006
32
Delegation Through Ports
• Delegation can be used to
preserve encapsulation of
block
• Interactions at outer ports of
Block1 are delegated to ports
of child parts
• Ports must match (same kind,
types, direction etc.)
• (Deep-nested) Connectors can
break encapsulation if required
(e.g. in physical system
modeling)
11 July 2006
ibd [block]Block1[delegation]
Child1:
Child2:
33
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
11 July 2006
34
Defining Vehicle Dynamics
Defining Reusable Equations for Parametrics
11 July 2006
35
Vehicle Dynamics Analysis
v.chassis.tire.
Friction:
v.brake.abs.m1.
DutyCycle:
tf:
tl:
v.brake.rotor.
BrakingForce:
bf:
:BrakingForce
Equation
{f = (tf*bf)*(1-tl)}
v.Weight:
m:
f:
F:
:Accelleration
Equation
{F = m*a}
a:
a:
:DistanceEquation
{v = dx/dt}
v:
v:
:VelocityEquation
{a = dv/dt}
x:
v.Position:
Using the Equations in a Parametric Diagram to
11 July 2006
Copyright © 2006Value
by Object Properties
Management Group.
Constrain
36
Behavioral Diagrams
SysML Diagram
Behavior
Diagram
Activity
Diagram
Sequence
Diagram
Requirement
Diagram
State Machine
Diagram
Use Case
Diagram
Structure
Diagram
Block Definition
Diagram
Same as UML 2
Internal Block
Diagram
Package Diagram
Parametric
Diagram
Modified from UML 2
New diagram type
11 July 2006
37
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)
11 July 2006
38
Activity Diagram Notation
Activity
act MonitorTraction
Action
WheelRevs
Initial
Node
Decision
Calculate
Wheel
Velocity
[loss of
of traction]
AngularVelocity
Fork
Calculate
Traction
Speed
[else]
Calculate
Modulation
Fr e que nc y
Modulation
Frequency
Calculate Car
Velocity
Control
Flow
Object
Flow
SpeedoInput
Activity
Parameter
Node
Pin
Flow
Final
Node
Activity
Final
Node
•Join and Merge symbols not included
•Activity Parameter Nodes on frame boundary correspond to activity parameters
11 July 2006
39
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]
DetectLossOf
Traction
Traction
Loss:
Traction
Loss:
Modulate
BrakingForce
Pins
11 July 2006
DetectLossOf
Traction
TractionLoss:
Modulate
BrakingForce
Pins must
have same
characteristics
(name, type
etc.)
ObjectNode
40
Explicit Allocation of Behavior to
Structure Using Swimlanes
Activity Diagram
(without Swimlanes)
DetectLossOf
Traction
TractionLoss:
Modulate
BrakingForce
act PreventLockup [Swimlane Diagram]
«allocate»
:TractionDetector
Activity Diagram
(with Swimlanes)
DetectLossOf
Traction
«allocate»
:BrakeModulator
TractionLoss:
Modulate
BrakingForce
allocatedTo
«connector»c1:modulatorInterface
11 July 2006
41
SysML EFFBD Profile
EFFBD - Enhanced Functional Flow Block Diagram
Aligning SysML with Classical Systems Engineering Techniques
11 July 2006
42
Distill Water Activity Diagram
(Continuous Flow Modeling)
Continuous Flow
Interruptible
Region
Representing Distiller Example in SysML
Using Continuous Flow Modeling
11 July 2006
43
Activity Decomposition
bdd PreventLockup [Activity Breakdown]
«activity»
PreventLockup
a1
«activity»
DetectLossOf
Traction
a2
Traction
Loss:
a2:Modulate
BrakingForce
«activity»
ModulateBrak
ingForce
Definition
11 July 2006
a1:DetectLossOf
Traction
Traction
Loss:
Use
44
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
11 July 2006
45
Black Box Interaction (Drive)
sd DriveBlackBox
driver:Driver
ref
vehicleInContext:HybridSUV
StartVehicleBlackBox
par
alt controlSpeed
ref
[state = (idle)]
Idle
[state = (accelerating/cruising)]
ref
Accelerate/Cruise
[state = (braking)]
ref
ref
ref
Brake
Steer
Park/ShutdownVehicle
UML 2 Sequence Diagram Scales
July 2006
by11Supporting
Control
Logic and Reference Sequences
46
Black Box Sequence (StartVehicle)
References Lifeline
Decomposition
For White Box
Interaction
Simple Black Box Interaction
11 July 2006
47
White Box Sequence (StartVehicle)
Decomposition of Black Box Into White Box Interaction
11 July 2006
48
Trial Result of Vehicle Dynamics
0.5
0.45
Accelleration (g)
0.4
0.35
0.3
0.25
0.2
0.15
0.1
0.05
0
0
5
10
15
20
15
20
Time (sec)
140
Velocity (mph)
120
Lifeline are
value properties
100
80
60
40
20
0
0
5
10
Time (sec)
1800
1600
Timing Diagram Not
Part of SysML
Distance (ft)
1400
1200
1000
800
600
400
200
0
0
5
10
15
20
Time (sec)
Typical Example of a Timing Diagram
11 July 2006
49
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.
11 July 2006
50
Operational States (Drive)
stm HSUVOperationalStates
keyOff/
Off
start[in neutral]/start engine
shutOff/stop engine
Nominal
states only
Operate
Transition notation:
trigger[guard]/action
Idle
accelerate/
when (speed = 0)
releaseBrake/
Accelerating/
Cruising
Braking
engageBrake/
11 July 2006
51
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
11 July 2006
52
Operational Use Cases
11 July 2006
53
Cross-cutting Constructs
• Allocations
• Requirements
SysML Diagram
Behavior
Diagram
Activity
Diagram
Sequence
Diagram
Requirement
Diagram
State Machine
Diagram
Use Case
Diagram
Structure
Diagram
Block Definition
Diagram
Same as UML 2
Internal Block
Diagram
Package Diagram
Parametric
Diagram
Modified from UML 2
New diagram type
11 July 2006
54
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
11 July 2006
55
Different Allocation Representations
(Tabular Representation Not Shown)
Element
Name2
Element
Name1
«allocate»
«allocate»
Element
Name3
Allocate Relationship
Explicit Allocation of
Activity to Swim Lane
«block»
BlockName
PartName
allocatedFrom
«elementType»ElementName
Compartment Notation
11 July 2006
Callout Notation
56
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
«hardware»
: Optical Sensor
2
*
«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»
: Video Camera
«hardware»
: NW Hub
allocatedFrom
«software» SF Comm I/F
«hardware»
: Alarm
«hardware»
: DSL Modem
«hardware»
: DVD-ROM Drive
2
allocatedFrom
«data» Video File
«hardware»
: Site Hard Disk
«hardware»
: User Console
allocatedFrom
«data» Site Database
11 July 2006
57
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
11 July 2006
58
Requirements Breakdown
req [package] HSUVRequirements [HSUV Specification]
HSUVSpecification
«requirement»
Eco-Friendliness
RefinedBy
«useCase» HSUVUseCases::Accelerate
«requirement»
Performance
«requirement»
Power
«deriveReqt»
«requirement»
Braking
«requirement»
FuelEconomy
«requirement»
Accelleration
«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
11 July 2006
59
Example of Derive/Satisfy Requirement
Dependencies
Supplier
Client
Client depends on supplier
(i.e., a change in supplier
results in a change in client)
Supplier
Client
Arrow Direction Opposite Typical Requirements Flow-Down
11 July 2006
60
Problem and Rationale
Problem and Rationale can be attached to any
Model Element to Capture Issues and Decisions
11 July 2006
61
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
11 July 2006
62
Stereotypes
Defining the Stereotype
11 July 2006
Applying the Stereotype
63
Applying a Profile and
Importing a Model Library
11 July 2006
64
Cross Connecting Model Elements
1. Structure
2. Behavior
act PreventLockup [Swimlane Diagram]
Anti-LockController
Diagram]
satisfies
satisfies
«requirement»
«requirement»
Anti-Lock
Anti-Lock
Performance
Performance
d1:TractionDetector
d1:TractionDetector
«allocate»
act PreventLockup
[Activity Diagram]
:TractionDetector
allocatedFrom
allocatedFrom
«activity»DetectLos
«activity»DetectLos
d1:Traction
OfTraction
Of Traction
Detector
c1:modulator
c1:modulator
Interface
Interface
c1:modulator
interface
m1:BrakeModulator
m1:BrakeModulator
m1:Brake
Modulator
allocatedFrom
allocatedFrom
BrakingForce
BrakingForce
allocatedFrom
allocatedFrom
«ObjectNode»
TractionLoss:
values
DutyCycle: Percentage
c
allo
ate
DetectLossOf
Traction
TractionLoss:
value
binding
satisfy
«allocate»
:BrakeModulator
Modulate
Modulate
BrakingForce
BrakingForce
allocatedTo
«connector»c1:modulatorInterface
req [package] VehicleSpecifications
[Requirements Diagram - Braking Requirements]
v.chassis.tire.
Friction:
v.brake.abs.m1.
DutyCycle:
v.brake.rotor.
BrakingForce:
v.Weight:
Vehicle System
Specification
Braking Subsystem
Specification
tf:
«requirement»
StoppingDistance
«requirement»
Anti-LockPerformance
id=“102”
text=”The vehicle shall stop
from 60 mph within 150 ft
on a clean dry surface.”
id=”337"
text=”Braking subsystem
shall prevent wheel lockup
under all braking conditions.”
SatisfiedBy
VerifiedBy
«block»Anti-LockController
«interaction»MinimumStopp
«deriveReqt»
ingDistance
tl:
bf:
:BrakingForce
Equation
[f = (tf*bf)*(1-tl)]
c
m:
f:
F:
:Accelleration
Equation
[F = ma]
a:
:DistanceEquation
[v = dx/dt]
v:
v:
a:
:VelocityEquation
[a = dv/dt]
x:
«deriveReqt»
«deriveReqt»
3. Requirements
11 July 2006
v.Position:
verify
4. Parametrics
65
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.
Dirty water
@ 20 deg C
Heat Dirty water
To 100 deg C
Dirty water
@ 100 deg C
Steam
Boil Dirty water
Residue
Heat to Dirty
water
Heat to Boil
water
and
Energy to
condense
Pure
water
Condense
steam
and
Drain
Residue
Disposed
residue
What are the real requirements?
How do we design the system?
11 July 2006
68
Distiller Types
Batch
Distiller
Continuous
Distiller
11 July 2006
69
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
11 July 2006
70
Distiller Problem – Package Diagram:
Model Structure and Libraries
pkg [model] Distiller [Model Overview]
DistillerRequirements
DistillerUseCases
bdd [package] ValueTypes
«valueType»
Real
DistillerBehavior
«valueType»
temp
unit = ºC
dimension =
temperature
«valueType»
press
unit = N/m^2
dimension =
pressure
«valueType»
efficency
unit = null
dimension =
efficency
11 July 2006
«valueType»
massFlowRate
unit = gm/sec
dimension =
massFlowRate
«valueType»
specificHeat
unit = cal/(gm*ºC)
dimension =
specificHeat
DistillerStructure
«valueType»
dQ/dt
unit = cal/sec
dimension =
heatFlowRate
ValueTypes
ItemTypes
«valueType»
latentHeat
unit = cal/gm
dimension =
latentHeat
71
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»
PurifyWater
«requirement»
HeatExchanger
Id = S1.0
text = The system shall
purify dirty water.
Id = S2.0
text = Heat dirty water and
condense steam are performed by
a Counter Flow Heat Exchanger
«requirement»
WaterProperties
Id = S5.0
text = water has properties: density 1
gm/cm3, temp 20 deg C, specific heat
1cal/gm deg C, heat of vaporization
540 cal/gm.
«requirement»
Boiler
Id = S3.0
text = Boil dirty water is performed
by a Boiler.
«deriveReqt»
«rationale»
The requirement
for a boiling
function and a
boiler implies that
the water must be
purified by
distillation
«requirement»
Drain
«requirement»
WaterInitialTemp
Id = S5.1
text = water has an
initial temp 20 deg C
Id = S4.0
text = Drain residue is performed by
a Drain.
«requirement»
DistillWater
Id = D1.0
text = The system shall purify water
by boiling it.
11 July 2006
72
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
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
11 July 2006
73
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
@ 100 deg C
Dirty water
@ 20 deg C
Heat Dirty water
To 100 deg C
Steam
Boil Dirty water
Residue
Heat to Dirty
water
Activities (Functions)
11 July 2006
and
Energy to
condense
Pure
water
Condense
steam
and
Drain
Residue
Heat to Boil
water
Disposed
residue
Control (Sequence) Things that flow (ObjectNodes)
74
Control-Driven: Serial Behavior
Batch
Distiller
11 July 2006
75
Distiller Example – Block Definition
Diagram: DistillerBehavior
bdd [package] DistillerBehavior [Distiller Behavior Breakdown]
Activities
(Functions)
a1
a2
«activity»
HeatWater
«activity»
BoilWater
a3
a4
«activity»
CondenseSteam
Control
(not shown
on BDD)
11 July 2006
«activity»
DistillWater
Need to
consider
phases
of H20
«activity»
DrainResidue
Things that flow (ObjectNodes)
76
Distiller Example – State Machine
Diagram: States of H2O
stm [block] H2O
Gas
States
Add Latent Heat
of Vaporization
Remove Latent Heat
of Vaporization
Liquid
Remove Latent Heat
of Liquification
Add Latent Heat
of Liquification
Transitions
Solid
11 July 2006
77
I/O Driven: Continuous Parallel Behavior
act [activity] DistillWater [Parallell Continuous Activities)
loPress:Residue
coldDirty:H2O
[liquid]
steam:H20
[gas]
hiPress:Residue
recovered:Heat
a4:DrainResidue
a1:HeatWater
a3:CondenseSteam
hotDirty:H2O
[liquid]
a2:BoilWater
pure:H2O
[liquid]
external:Heat
Continuous
Distiller
11 July 2006
78
No Control Flow – Simultaneous Behavior
11 July 2006
79
Distiller Example – Activity Diagram
(with Swimlanes): DistillWater
Parts
11 July 2006
80
Diagram: DistillerStructure
Generic Subsystems
(Blocks)
11 July 2006
Usage Names
81
Diagram: Heat Exchanger Flow Ports
bdd [package] DistillerStructure [Structural Breakdown]
«block»
Fluid
«block»
Distiller
Constraints
(on Ports)
hx1
cIn:Fluid
cOut:Fluid
values
temp:ºC
press:kg/m^2
constraints
{cIn.temp <= 220}
{cIn.press <= 150}
{cOut.temp <= 220}
{cOut.press <= 150}
{hIn.temp <= 400}
{hIn.temp <= 1000}
{hIn.temp <= 400}
{hIn.temp <= 1000}
f2Out:Fluid
hIn:Fluid
fIn:Fluid
«block»
Boiler
qIn:Heat
in:Fluid
«block»
Valve
out:Fluid
f1Out:Fluid
hOut:Fluid
Generic Things
Flow Ports
That Flow
(typed by things that flow)
(Blocks)
11 July 2006
values
dQ/dt:cal/s
drain
bx1
«block»
HeatExchanger
«block»
Heat
Generic Subsystems
(Blocks)
82
Distiller Example – Internal Block
Diagram: Distiller Initial Design
ibd: [block] Distiller [DistillerBlockDiagram - ItemFlows]
m1:H2O
m2:H2O
hx1:HeatExchanger
s1:Residue
bx1:Boiler
s2:Residue
drain:Valve
m3:H2O
q1:Heat
m4:H2O
Parts
(Blocks used
in context)
11 July 2006
Flow Ports
Connectors
Things That Flow
In Context
(ItemFlows)
83
Distiller Example –Internal Block
Diagram: Distiller with Allocation
ibd: [block] Distiller [DistillerBlockDiagram - ItemFlows]
allocatedFrom
«objectNode»coldDirty:H2O
allocatedFrom
«objectNode»hotDirty:H2O
m1:H2O
allocatedFrom
«objectNode»hiPress:Residue
m2:H2O
hx1:HeatExchanger
s1:Residue
s2:Residue
bx1:Boiler
allocatedFrom
«activity»a1:HeatWater
«activity»a3:CondenseSteam
allocatedFrom
«objectNode»loPress:Residue
allocatedFrom
«activity»a2:BoilWater
drain:Valve
allocatedFrom
«activity»a4:DrainResidue
m3:H2O
q1:Heat
allocatedFrom
«objectNode»External:Heat
allocatedFrom
«objectNode»steam:H2O
Allocation Compartment
11 July 2006
m4:H2O
allocatedFrom
«objectNode»Pure:H2O
Allocation Callout
84
Distiller Example – Parametric Diagram:
Heat Balance Equations
par [block] Distiller [Simplified Isobaric Heat Balance Analysis}
Parts or
ItemFlows
{Qrate=(th-tc)*mRate/sh)}
water_in:H2O
mRate:
temp:ºC
massFlowRate:
gm/sec
tin:
sh:
tout:
r1:
Qrate:
equivalent
{r1=r2}
hx_water_out:H2O
r2:
Value
Properties
SinglePhaseHeatXFR
Equation
water_in:H2O
Qrate:
temp:ºC
condensing:
SimplePhaseChange
Equation
massFlowRate:
gm/sec
lh:
specificHeat:
cal/(gm*ºC)
latentHeat:
cal/gm
mRate:
bx_steam_out:H2O
massFlowRate:
gm/sec
{Qrate=mRate*lh)}
r1:
water_out:H2O
Value
Bindings
massFlowRate:
gm/sec
equivalent
{r1=r2}
Qrate:
Note: Underline =
these are
invariant
properties of all
uses of H2O
r2:
Constraints
boiling:
SimplePhaseChange
Equation
mRate:
lh:
Constraint
callouts
heat_in:Heat
dQ/dt>:cal/
sec
11 July 2006
85
Distiller Example – Heat Balance
Results
table IsobaricHeatBalance1 [Results of Isobaric Heat Balance]
11 July 2006
water_out
bx_steam_out
bx_water_in
Satisfies «requirement»
WaterSpecificHeat
WaterHeatOfVaporization
hx_water_out
WaterInitialTemp
1
540
water_in
specific heat cal/gm-°C
latent heat cal/cm
mass flow rate gm/sec
temp °C
6.75 6.75
1
1
1
20 100 100 100 100
dQ/dt cooling water cal/sec
dQ/dt steam-condensate cal/sec
condenser efficency
heat deficit
540
540
1
0
dQ/dt condensate-steam cal/sec
boiler efficiency
dQ/dt in boiler cal/sec
540
1
540
Note: Cooling water
needs to have 6x flow
of steam!
Need bypass between
hx_water_out and
bx_water_in!
86
Updated DistillWater
act [activity] DistillWater [Revised Swimlane Diagram]
«allocate»
hx1:HeatExchanger
«continuous»
coldDirty:H2O
[liquid]
«allocate»
feed:Vave
«continuous»
recovered:Heat
«streaming»
a1:HeatWater
«continuous»
steam:H2O
[gas]
«streaming»
a3:CondenseSteam
11 July 2006
loPress:Residue
«continuous»
pure:H2O
[liquid]
«continuous»
hotDirty1:H2O
[liquid]
ShutDown
«allocate»
drain:Valve
a4:DrainResidue
«streaming»
a2:BoilWater
«continuous»
hotDirty:H2O
[liquid]
«continuous»
external:Heat
«allocate»
bx1:Boiler
hiPress:Residue
«continuous»
hotDirty2:H2O
[liquid]
a5:DivertFeed
87
Diagram: Updated Distiller
11 July 2006
88
Distiller Example – Use Case and
Sequence Diagrams
seq OperateDistiller [Operational Sequence]
«actor»
:User
«block»
:Distiller
uc DistillerUseCases [Operate Distiller]
TurnOn
Operate
Distiller
Distiller
PowerLampOn
User
OperatingLampOn
loop
alt
LevelHighLampOn
DrainingLampOn
LevelLowLampOn
TurnOff
11 July 2006
PowerLampOff
89
Diagram: Distiller Controller
11 July 2006
90
Distiller Example – State Machine
Diagram: Distiller Controller
11 July 2006
91
11 July 2006
Sample - Artisan Tool
92
OOSEM – ESS Example
System Development Process
System
Modeling
Activities
Component
Modeling
Activities
Integrated Product
Development (IPD) is
essential to improve
communications
A Recursive V process
that can be applied to
multiple levels of the
system hierarchy
11 July 2006 CopyrightCopyright
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
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
Define
•Req’ts diagram
Logical
Architecture
Optimize &
Evaluate
Alternatives
•Logical architecture
•Engr Analysis Models
•Trade studies
Validate &
Verify
System
•Test cases/procedures
Synthesize
Physical
Architecture
•Node diagram
•HW, SW, Data architecture
Common Subactivities
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
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
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006
96
ESS Requirements Flowdown
req [package] ESS Requirements Flowdown
«trace»
«document»
Market Needs
ESS Enterprise Models
«trace»
«requirement»
ESS System Specification
«satisfy»
«refine»
id# = SS1
«requirement»
IntruderDetection
id# = SS102
txt = System shall
detect intruder entry
and exit ...
satisfiedBy
Entry/Exit Subsystem
verifiedBy
Entry/Exit Detection Test
ESS System Models
«requirement»
R111
«deriveReqt»
id# = SS111
«requirement»
ESS Logical Requirements
«satisfy»
«refine»
ESS Logical Design Models
id# = LR1
«deriveReqt»
«satisfy»
ESS Allocated Design
Models
«requirement»
ESS Allocated Requirements
id# = AR1
«refine»
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
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
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006
98
ESS Enterprise As-Is Model
bdd [package] ESS Enterprise (As Is)
*
Domain
As-Is
*
«enterprise»
Enterprise As-Is
Residence
1
Customer As-Is
Intruder
«system»
Sec Sys
1
«external»
Comm Network
«external»
Emergency Services As-Is
*
Site Installation
As-Is
Central Monitoring
Station As-Is
Dispatcher
Police
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006
99
ESS Operational Enterprise To-Be
Model
bdd [package] ESS Enterprise (To Be)
*
Domain
To-Be
«moe» OperationalAvailability = {>.99}
«moe» MissionResponseTime = {<5 min}
«moe» OperationalCost = {TBD}
«moe» CostEffectiveness
MonitorSite ()
DispatchEmergencyServices ()
ProvideEmergencyResponse ()
Intruder
1..*
«enterprise»
ESS Operational Enterprise
*
1..*
Protected Site
«external»
Emergency Services
*
Assess Report ()
Report Update ()
Dispatch Police ()
Customer
«system»
ESS
«external»
Comm Network
*
*
*
*
«external»
Physical Environment
«external»
Single-family Residence
Responder
«external»
Property
«external»
Multi-family Residence
Dispatcher
«external»
Business
Police
Fire
Paramedic
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006 100
System Use Cases - Operate
uc [package] System Use Cases
Activate/Deactivate
«include»
Operate
«extend»
«include»
Respond
Monitor Site
Respond to
Break-In
Respond to
Fire
Respond to
Medical
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006 101
System Scenario: Activity Diagram
Monitor Site (Break-In)
act Monitor Site (break in)
«actor»
Intruder
«system»
ESS
«external»
Emergency Services
System On
Enter Property
Status Update
System Off
DetectEntry
ValidateEntry
Validated Entry
Conduct Theft
GenerateAlarm
ReportEntry
Exit Property
[Alert]
Assess Report
InternalMonitor
[Alert]
DetectExit
Report Update
ReportExit
Dispatch Police
[Alert]
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006 102
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
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
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»
: Entry Sensor
«logical»
: Entry/Exit Monitor
: Door Input
: SensedExit
: Entry/Exit Alert Status
: Window Input
: Window Input
m+n
«logical»
: Exit Sensor
«logical»
: Event Monitor
: Alert Status
«store»
: Event Log
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006 104
ESS Logical Design (Partial)
ibd [system] ESS
«logical»
: Alarm Generator
: Window Input
«logical»
: Entry Sensor
: AlarmSignal
: SensedEntry
: Door Input
: AlarmCmd
: BIT
«logical»
: Entry/Exit Monitor
: Alert Status
«logical»
: Alarm I/F
: Entry/Exit Alert Status
: Window Input
«logical»
: Exit Sensor
: SensedExit
: Door Input
: BIT
«logical»
: Perimeter Sensor
: BIT
: BIT
«logical»
: Environment Sensor
«logical»
: Event Monitor
«store»
: Event Log
: Alert Status
«logical»
: Emergency Monitor
: EmergencyData
«logical»
: Fault Mgr
«logical»
: Emer Serv I/F
: Emergency
ServicesOut
: Fault
«logical»
: Customer Output Mgr
: FaultReport
«logical»
: Customer I/F
: Lamp
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006 105
ESS Allocation Table (partial)
•
Allocating Logical Components to HW, SW, Data, and Procedures
components
Logical Components
Entry
Sensor
Type
«software»
Perimeter
Exit Sensor Sensor
Entry/Exit
Monitor
Event
Monitor
Site
Comms I/F Event Log
Customer
I/F
Customer
System
Output Mgr Status
X
X
X
Event Mgr
X
X
Physical Components
Site Status Mgr
X
X
X
X
X
Site RDBMS
CMS RDBMS
Video File
CMS Database
Site Database
Optical Sensor
X
X
X
X
User Console
Alarm
X
X
DSL Modem
Video Camera
Alarm I/F
X
User I/F
«hardware»
Alarm
Generator
Device Mgr
SF Comm I/F
«data»
Fault Mgr
X
X
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006 106
ESS Deployment View
ESS
ibd [system] ESS
«node»
: Central Monitoring Station
*
«node»
: MF Residence Installation
*
«node»
: Business Installation
«external»
: Comm
Network
: SF Residence Installation
*
«hardware»
: Optical Sensor
«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
2
«hardware»
: Video Camera
«hardware»
: NW Hub
allocatedFrom
«software» SF Comm I/F
«hardware»
: Help Desk Client
«hardware»
: Phone Lines
«hardware»
: MS LAN
*
«hardware»
: PS Comm
I/F
«hardware»
: DSL Modem
«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
«hardware»
: DB Server
«hardware»
: Alarm
«hardware»
: Video Server
«hardware»
: CM Server
allocatedFrom
«software» CMS RDBMS
«data» CMS Database
allocatedFrom
«software» S/W Distrib Mgr
«software» System CM
«hardware»
: DVD-ROM Drive
2
allocatedFrom
«hardware»
: Site Hard Disk
«hardware»
: User Console
allocatedFrom
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
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
«moe»
OperationalAvailability
CE
MRT
OA
«moe»
CostEffectiveness
OC
«moe»
OperationalCost
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006 108
Entry/Exit Test Case
sd Entry/Exit Detection Test
Description
«testComponent»
:IntruderEmulator
seq
«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
Enter
Door sensor detects entry
: SensedEntry
New alert status sent to central
system
Intruder leaves through lounge
window
Window sensor detects exit
Changed alert status sent to
central system
IntruderEntry :
Alert Status
Exit
: SensedExit
Intruder Exit :
Alert Status
© 2006
byCorporation
Object Management
Group.
© Lockheed
Martin
2000 – 2003
& INCOSE 2004-2006 109
OOSEM Browser View
Artisan Studio™ Example
11 July 2006
110
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
Modeling &
Simulation
Standards
Interchange &
Metamodeling
Standards
EIA 632
FEAF
ISO 15288
DoDAF
HP
IDEF0 SysML
OOSE
IEEE 1220
MODAF
SADT
UPDM
XMI
Zachman FW
Implemented
By Tools
Other
HLA
System Modeling
MOF
CMMI
MathML
Simulation & Analysis
STEP/AP233
Data
Repository
11 July 2006
112
ISO/IEC 15288
System Life Cycle Processes
Enterprise Processes
5.3.2
Enterprise Environment
Management Process
5.3.4
System Life Cycle
Processes Management
5.3.5
Quality
Management Process
5.4.3
Project Assessment
Process
5.4.4
Project Control Process
5.5.3
Reqts Analysis Process
5.5.4
Architectural Design Process
5.5.5
Implementation Process
5.4.6
Risk Management
Process
Agreement Processes
11 July 2006
5.5.2
Stakeholder Reqts
Definition Process
5.4.5
DecisionDecision-Making Process
5.3.6
Resource
Management Process
5.2.3
Supply Process
Technical Processes
5.4.2
Project Planning Process
5.3.3
Investment
Management Process
5.2.2
Acquisition Process
Project Processes
5.4.7
Configuration Management
Process
5.4.8
Information Management
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
113
Standards-based Tool Integration
with SysML
Systems Modeling
Tool
SV4
OV7
• .....
• .....
• .....
•
-
11 July 2006
Model/Data
Interchange
Other SE Engineering
Tools
OV2
TV2
AP233/XMI
..
• ...
..
• ...
• .....
•
-
AP233/XMI
-
-
114
Participating SysML Tool Vendors
• Artisan
• EmbeddedPlus
– 3rd party IBM vendor
• Sparx Systems
• Telelogic (includes I-Logix)
• Vitech
11 July 2006
115
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
11 July 2006
116
Transitioning to SysML
Using Process Improvement
To Transition to SysML
11 July 2006
118
Integrated Tool Environment
11 July 2006
System Modeling
SysML
Software Modeling
UML 2
Hardware Modeling
VHDL, CAD, ..
Specialty Engineering Analysis
SoS / DoDAF / Business Process Modeling
Verification & Validation
Engineering Performance Analysis
Requirements Management
CM/DM
Product Data Management
Project Management
119
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
11 July 2006
121
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
11 July 2006
122

OMG Systems Modeling Language (OMG SysML™) Tutorial

Transcription

Similar documents

McNess Bova Calf Cubes - Furst

Papyrus Datasheet.indd

View Event Flyer - Whiskey Obsession Festival

Distiller Instruction Booklet pdf.pub

Recommended Billing Codes for the Anatomotor Table For Cervical

Krawler T/A KX - Suburban Tire

Charlotte Katzenmoyer Director of Public Works City of Lancaster, PA

Acrobat Distiller 7

The SysML notation