Matthew Hause Building Bridges between Systems and Software with SysML and UML

Building Bridges Between Systems
and Software with SysML and UML
Matthew Hause
PTC GTM Solutions Specialist, Fellow
March 17, 2015

2Copyright © 2015 PTC All Rights Reserved
Agenda
•  The Problem
•  Engineering Domains
•  Analysing the problem with SysML
•  Allocating to software
•  The Importance of Process
•  Conclusion

3
Systems Engineering as an Innovation Enabler
PTC proprietary and confidential
Systems
Engineering
A multi-disciplinary
engineering approach
that ensures
successful system
specification, design,
validation, and
verification of
complex products.

4
Author
1..*
1..*
Response
Repository
cap_Baseline_Project( )
cap_Control_Access( )
Item
>
Status
ConceptualBarrier
Some
communication is
blocked.
Other information
is distorted.
The Miscommunication Problem
SE SWE
HWE

5
The Systems/Software Problem
• DoD buys systems but software is both a critical enabler and a
prominent source of risk (both product and process)
• Systems engineering practices contribute to software risks if
they:
– Prematurely over-constrain software engineering choices
– Inadequately communicate information, including unknowns and uncertainties, needed
for effective software engineering
– Fail to adequately represent and analyze the implications of software design choices in
system-level trade studies
• Attempting to fix software engineering problems without
rethinking the role of systems engineering may limit any
potential for improvement
Copyright © 2015 PTC All Rights Reserved
From Reconsidering the Role of Systems Engineering in DoD Software Problems
© 2004 by Carnegie Mellon University Grady Campbell (ghc@sei.cmu.edu)

6
The Systems Engineering Process
• The systems engineering process is comprised of the
following seven tasks:
– State the problem
– Investigate alternatives
– Model the system
– Integrate
– Launch the system
– Assess performance
– Re-evaluate.
The Systems Engineering Process (Bahill, Gissing, 1998)

7
OOSEM System Development Process
Procedures
Manage
System
Development
Define System
Reqt's &
Design
Integrate
& Test
System
System
Stakeholder
Reqts
System arch
Allocated reqt's
Data
Hardware
Software
Develop
System
Element
System
Element
Plan
Status
Technical data
Test procedures
OOSEM
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

8
Typical Systems Req’ts & Design Activities & Models - OOSEM
Synthesize
Allocated
Architecture
Define
System
Requirements
Define
Logical
Architecture
Optimize &
Evaluate
Alternatives
Validate &
Verify
System
Analyze
Needs
Major SE Development Activities
Common Subactivities
• Parametric Diag
• Trade study
• Test system
• Test cases
• Causal analysis
• Mission use cases/scenarios
• Enterprise model
• System use cases/scenarios
• Elaborated context
• Logical decomposition
• Logical scenarios
• Logical subsystems
• Node diagram
• HW, SW, Data arch
• System deployment
Manage
Requirements • Reqt’s
Diagram
& tables

9
SE Interface with Hardware/ Software Development
SE Interface
Inputs to SW/HW (Partial List)
• Allocated requirements
• Design constraints
• System architecture
• System scenarios
Outputs to Systems (Partial List)
• Requirements compliance
• SW/HW Design
• Verification results
• Risks and issues
SE Interface
HW/SW Level:
Manage
Development
Integrate and
Test
Implement
Design
HW/SW
Req’ts &
Design

10
The Complete Solution
• Typically a Complete Solution requires an integration of more
than one engineering domain.
– Therefore many disciplines will be involved.
• “Trade-Off Analysis” typically trades-off the relative merits of
competing domains (initially). e.g.:
•  Hardware vs. Software
•  Mechanical vs. Electro-Mechanical.
• Then trades-off the relative merits of competing solutions
within a domain e.g.:
•  Ada vs. Java (Software Solution Space)
•  Fluid or Gas hydraulics (Chemical Solution Space)

11
Model-Based Systems Engineering

12
•  MBSE is a model-based approach to Systems Engineering, typically
applying the SysML modeling language to deal with system complexity
and enabling unambiguous communication amongst interested parties
What is Model Based System Engineering?
System Models
Software
Mechanical
Electrical
Analysis
Manufacturing
Marketing
Management
System
System Context Model
Use Cases Model
Functional Model
Structural Model
Requirements
© 2015 PTC
Service
(Device, Cloud,
Mobile)

13
The Four Pillars of SysML (ABS Example)
13
ibd [Block] Anti-Lock Controller1
«Block»
Anti-Lock Controller
«BlockProperty»
d1 : Traction Detector
«BlockProperty»
m1 : Brake Modulator
«BlockProperty»
d1 : Traction Detector
«BlockProperty»
m1 : Brake Modulator
c1:modulator interface
use
interaction
par [constraint] StraightLineVehicleDynamics [Parametric Diagram]
: AccelerationEquation
F c
a
: BrakingForceEquation
tf
tl
bf
f
: DistanceEquation
vx
: VelocityEquation
a
v
{f = (tf*bf)*(1-tl)} {F = ma}
{v = dx/dt} {a = dv/dt}
1. Structure
4. Parametrics
2. Behavior
Vehicle System
Specification
Braking Subsystem
Specification
«requirement»
id#
102
txt
The vehicle shall stop from
60 mph within 150ft on a
clean dry surface.
Stopping Distance
«requirement»
id#
337
txt
The Braking subsystem shall
prevent wheel lockup under
all braking conditions.
Anti-Lock Performance
req [Package] Vehicle Specifications [Braking]
«deriveReqt»
3. Requirements
bdd [Package] Vehicle [ABS]
«Block»
Library::
Electronic
Processor
«Block»
Anti-Lock
Controller
«Block»
Library::
Electro-Hydraulic
Valve
«Block»
Traction
Detector
«Block»
Brake
Modulator
d1 m1
definition
Gripping Slipping
LossOfTraction/
RegainTraction/
stm Tire [Traction]
state machine
Detect Loss Of
Traction
TractionLoss Modulate
Braking Force
act PreventLockup
activity/
function

14
Cross Connecting Model Elements
14
ibd [block] Anti-LockController
[Internal Block Diagram]
d1:Traction
Detector
m1:Brake
Modulator
c1:modulator
interface
allocatedFrom
«activity»DetectLos
OfTraction
d1:TractionDetector
allocatedFrom
«activity»Modulate
BrakingForce
m1:BrakeModulator
allocatedFrom
«ObjectNode»
TractionLoss:
c1:modulator
Interface
act PreventLockup [Activity Diagram]
DetectLossOf
Traction
Modulate
BrakingForce
TractionLoss:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:Accelleration
Equation
[F = ma]
:VelocityEquation
[a = dv/dt]
:DistanceEquation
[v = dx/dt]
:BrakingForce
Equation
[f = (tf*bf)*(1-tl)]
tf: bf:tl:
f:
F:
c
a:
a:
v:
v:
x:
1. Structure 2. Behavior
3. Requirements 4. Parametrics
act PreventLockup [Swimlane Diagram]
«allocate»
:TractionDetector
«allocate»
:BrakeModulator
allocatedTo
«connector»c1:modulatorInterface
DetectLossOf
Traction
Modulate
BrakingForce
TractionLoss:
req [package] VehicleSpecifications
[Requirements Diagram - Braking Requirements]
Braking Subsystem
Specification
Vehicle System
Specification
id=“102”
text=”The vehicle shall stop
from 60 mph within 150 ft
on a clean dry surface.”
«requirement»
StoppingDistance
id=”337"
text=”Braking subsystem
shall prevent wheel lockup
under all braking conditions.”
«requirement»
Anti-LockPerformance
«deriveReqt»
allocatedFrom
OfTraction
d1:TractionDetector
allocatedFrom
BrakingForce
m1:BrakeModulator
allocatedFrom
«ObjectNode»
TractionLoss:
c1:modulator
Interface
satisfies
«requirement»
Anti-Lock
Performance
Braking Subsystem
Specification
Vehicle System
Specification
id=“102”
«requirement»
StoppingDistance
SatisfiedBy
«block»Anti-LockController
id=”337"
«requirement»
«deriveReqt»
allocatedFrom
Of Traction
d1:TractionDetector
values
DutyCycle: Percentage
allocatedFrom
BrakingForce
m1:BrakeModulator
allocatedFrom
«ObjectNode»
TractionLoss:
c1:modulator
Interface
satisfies
«requirement»
Anti-Lock
Performance
:Accelleration
Equation
[F = ma]
:VelocityEquation
[a = dv/dt]
:DistanceEquation
[v = dx/dt]
:BrakingForce
Equation
[f = (tf*bf)*(1-tl)]
tf: bf:tl:
f:
F:
m:
a:
a:
v:
v:
x:
v.Position:
v.Weight:
v.chassis.tire.
Friction:
v.brake.abs.m1.
DutyCycle:
v.brake.rotor.
BrakingForce:
:Accelleration
Equation
[F = ma]
:VelocityEquation
[a = dv/dt]
:DistanceEquation
[v = dx/dt]
:BrakingForce
Equation
[f = (tf*bf)*(1-tl)]
tf: bf:tl:
f:
F:
m:
a:
a:
v:
v:
x:
v.Position:
v.Weight:
v.chassis.tire.
Friction:
v.brake.abs.m1.
DutyCycle:
v.brake.rotor.
BrakingForce:
Braking Subsystem
Specification
Vehicle System
Specification
VerifiedBy
«interaction»MinimumStopp
ingDistance
id=“102”
«requirement»
StoppingDistance
SatisfiedBy
«block»Anti-LockController
id=”337"
«requirement»
«deriveReqt»
satisfy
verify
value
binding
allocate

SysML Requirements Traceability
Activities
«activity»
Decrement Speed
«activity»
Increment Speed
Cruise Control System
Maintain
Speed
«requirement»
txt
When cruise control is engaged, the driver must be able to
increment the desired speed in increments of 1 MPH.
REQ_CCS_04a
«requirement»
txt
When cruise control is engaged, the driver must be able to
decrement the desired speed in increments of 1 MPH.
REQ_CCS_04b
«requirement»
txt
When cruise control is active, the driver must be able to increment or
decrement the desired speed (in increments of 1 MPH). The driver
must also have the ability to change the gear selection whilst cruise
control is active.
REQ_CCS_04
«requirement»
txt
The CCS must allow a driver to enable the vehicle to maintain a
desired speed.
satisfiedBy
Maintain Speed (in changeSpeed : Integer, in EMUMessage : EMU
OP Message = every 10ms, out ThrottleMessage : EMU Analog IP
Message)
REQ_CCS_01
«requirement»
txt
The CCS must allow cruise control to be engaged and disengaged. When
engaged the cruise control system is available to accept driver instructions (such
as 'set' and 'disengage'). When disengaged, the cruise control system will not
respond to any driver inputs (except 'engage').
REQ_CCS_02
verifiedBy
«State Diagram» [Block] Cruise Control System
verifiedBy
«State Diagram» [Block] Cruise Control System
DecBttnDecBttn
IncBttnIncBttn
incSpeedincSpeed
req [Package] Cruise Control System [Reqts - with Links]
«deriveReqt»
«satisfy»
«satisfy»
«satisfy»
«allocate»
«allocate»
«allocate»
«refine»

Requirements Traceability Relationships
Traceability
relationships
stored in the
model

17
Requirements Traceability Report

18
Requirements Traceability from Other Diagrams
Traceability callouts can be added from model elements
wherever they appear in other diagrams in the model

19
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 actions to structure via swim lanes (i.e.,
activity partitions)
• Both graphical and tabular representations are specified

20
Behavioral Allocation – Actions to Parts
using Activity Diagram Swimlanes
Parts
Actions

Structural Allocation – Abstract to Concrete
later
refinement
early
abstraction
ibd [block] Vehicle [CC System IO - Logical]
Vehicle
CC Sys : Cruise Control System
BrakeSys : Brake SubsystemPowSys : Power Subsystem
ElecSys : Electrical Subsystem
Driver
Driver
setThrottle : EMU Analog IP Message
EMUdata : EMU OP Message
brakeEngaged : Digital Signal
power : Electrical Power reqdSpeed : Speed errorId : Char
ButtonPresses : Digital Signal
allocatedTo
«FlowPort» BrakeIF
«FlowPort» CCIF
«Connector» CCIF - BrakeIF
allocatedTo
«FlowPort» BrakeIF
«FlowPort» CCIF
«Connector» CCIF - BrakeIF
allocatedTo
«ItemFlow» High
«ItemFlow» Low
allocatedTo
«ItemFlow» High
«ItemFlow» Low
ibd [Block] Vehicle [CC System IO - Physical]
Vehicle
BrakeSys : Brake Subsystem
CCIF : 0-12V
CC Sys : Cruise Control System
PSIF : ~EMU IO BrakeIF : 0-12V
ESIF
PowSys : Power Subsystem
CCIF : EMU IO
ElecSys : Electrical Subsystem
CCIF Driver
Driver
: 12V DC
EMU OP Msg : EMU OP Frame
EMU IP Msg : EMU IP Frame
EMU error : CAN Error Frame
CC error : CAN Error Frame
High Low

SysML Allocations Traceability Table/Matrix

23
The Software Engineering Process

24
UML: System Definition
Use Case View and Relationships
24
ACME RADAR
: Signal Processing : RADAR Controller
: Array Antenna
: Receiver
: Transmitter
: Antenna Controller
: Power Supply
: Tx Rx Duplex
: Array Orientation
: Mechanical Orientation
: Elevation Actuator
: Azimuthal Actuator
: Electronic Orientation
: User Displays
: Display : Keypad
: Array Antenna
: Receiver
: Transmitter
: Power Supply
: Tx Rx Duplex
: Array Orientation
: Electronic Orientation: Receiver
: Transmitter
: Power Supply
: Tx Rx Duplex
: Power Supply
: Tx Rx Duplex
: Array Orientation
: User Displays
: Display : Keypad: Display : Keypad
Operator
Requirements
Pilot
Stores
Navigation Data
Deploys
Weapon
Performs
Sorte
Use Case Model
The Software
:The SoftwarePilot Data Entry Panel
Pilot Presses Key
Key Press
Software Determines new Mode
Key Press( KEY ID )
if NAV Key then
Enter Navigation Mode
Set Mode( NAV )
elsif Weapons Key then
case Selected Store is
when Loft Bombs => Set Mode( LOFT )
when Retard Bombs => Set Mode( RETARD )
when Guns => Set Mode( GUN )
when Rockets => Set Mode( ROCKET )
end case
end if
Set Mode( NAV )
end case
end case
The Software
Pilot Presses Key
Key Press
Key Press( KEY ID )
if NAV Key then
Set Mode( NAV )
end case
end if
Set Mode( NAV )
end case
end case
The Software
Pilot Presses Key
Key Press
Key Press( KEY ID )
if NAV Key then
Set Mode( NAV )
end case
end if
Set Mode( NAV )
end case
end case
Scenario Model
Starting Up System
Fail Safe
Shutting Down System
Compressor Off
Compressor On
State4
Compressor Off
Compressor On
after( 40s )/
system start/Start Up Plant
power down/
system stop/Shutdown Plant
alarm/Handle Alarm
after( 180s )/
Maintain Gas Pressurealarm/Handle Alarm
power up/
[LPT and LOP alarms ringing]/
[els e]/
[els e]/
250 bar/
Stop Compressor
150 bar/
Start Compressor
[LOP alarm
ringing]/
Interaction Overview
(Modes) Diagram
Test
Scripts
Operational
Parameters Performance
Loader Speed
Belt Speed
Containers Scan
Success
Defective
Containers Accuracy
Constraints
Bombadier
Select Target Destination
Authority
Bombadier
Select Weapon Type
Navigator
«Equivalent»
Select Target Destination
Authority
Bombadier
Select Weapon Type
Navigator
Pilot
Communicator
Strike Authorised
Navigate to Target
Communicator
Strike Authorised
Navigate to Target
Commander
Strike Authority
«Secondary Actor»
Strike Authority
Activity Diagram
Composite Structure
Diagram
(Context)

25
UML: System Design
Class View and Relationships
::Person
Name
Age
Assign
Un-Assign
::Company
Name
::Contract
Start Date
Salary
Grade
Change Grade
::Work Instruction
Description
Start Date
Duration
Performance Rating
Agree Performance Rating
::Revenue Item
Cost
::Product ::Service
::Development Plan
Mean Performance
Training Needs
Current Skills
::Contractual Constraint
Description
Update
::Term ::Condition
11..* Works For
Employee Employer
1..*
1
Manages
Manager
Worker
1..*
1
Markets
Manufacturer
1..*1 Describes Work On
*
0..1
1
1
*
1
Updates
Supervisor
*1
1..*
1
Updates
1..*
1
Purchases
Customer
Item Type {Exclusive}Item Type {Exclusive}
Constraint Type {Inclusive}Constraint Type {Inclusive}
Class Model
The Software
Pilot Presses Key
Key Press
Key Press( KEY ID )
if NAV Key then
Set Mode( NAV )
end case
end if
Set Mode( NAV )
end case
end case
The Software
Pilot Presses Key
Key Press
Key Press( KEY ID )
if NAV Key then
Set Mode( NAV )
end case
end if
Set Mode( NAV )
end case
end case
The Software
Pilot Presses Key
Key Press
Key Press( KEY ID )
if NAV Key then
Set Mode( NAV )
end case
end if
Set Mode( NAV )
end case
end case
Scenario Model
Source
Files
running down
Entry/monitor.inhibit(LOP);
timer.set(40);
motor.stop;
valve[inlet].close;
valve[outlet].close;
valve[by-pass].open; ...
stopped
waiting for oil pressure to build
Entry/monitor.inhibit(LOP);
valve[vent].close;
timer.set(30);
timer.set(40);
motor.start; ...
waiting for gas pressure to build
operating
timeup/
monitor.enable(LOP)
start compressor/
after( 40s )/
valve[vent].open;...
after( 10s )/
valve[by-pass].close;
valve[inlet].open;
valve[outlet].open; ...
stop compressor/
«Destroy»/
stop compressor/
timer.cancel(30);
timer.cancel(40);
stop compressor/
timer.cancel(40);
«Create»/
[!monitor.check(LOP)]/
monitor.activate(LOP)
[monitor.check(LOP)]/
Dynamic Model
ACME RADAR
: Array Antenna
: Receiver
: Transmitter
: Power Supply
: Tx Rx Duplex
: Array Orientation
: User Displays
: Display : Keypad
: Array Antenna
: Receiver
: Transmitter
: Power Supply
: Tx Rx Duplex
: Array Orientation
: Electronic Orientation: Receiver
: Transmitter
: Power Supply
: Tx Rx Duplex
: Power Supply
: Tx Rx Duplex
: Array Orientation
: User Displays
: Display : Keypad: Display : Keypad
Operator
Composite Structure
Diagram
Requirements

26
SysML Blocks and Mapping
•  Blocks can represent any level of the system hierarchy including the top-
level system, a subsystem, or logical or physical component of a system or
environment, as well as software entities.
– A block can represent a well defined area of functionality or structure in the system.
– Blocks modeling software can map to UML entities
– Mapping will not be one to one, because the levels of abstraction will be different
– Functional, data, and structural software elements in the SysML model will not be the same as in
a UML model.
•  The job of the systems engineer is to define the requirements of the
software.
•  The job of the software engineer is to define a well-architected software
solution.
•  Consequently, refactoring will need to take place.
•  However, as SysML is based on UML, we will at least be mapping between
similar paradigms.

Block Structure
bdd [Package] CC System Software
«Block»
«Block»
«boundary»
allocatedFrom
Decrement ()
Disengage ()
Display Speed ()
EMU Message ()
Engage ()
Engage Brake ()
Increment ()
Resume ()
Set Speed ()
Shift ()
Suspend ()
allocatedTo
CC Motherboard
External Interface
Interface
«Block»
«control»
allocatedFrom
Error
Maintain Speed
Operate Cruise Control
Power Off
Power On
Calculate Throttle Position
allocatedTo
CC Motherboard
Control
Control
«Block»
«entity»
allocatedFrom
Log Error ()
Load Acceleration Profile ()
allocatedTo
CC Motherboard
Persistence Support
Persistence
11
CCIF
1
1 CCCtrl
1
1
Perst

28
Software Mapping
•  Block structure reconfigured to separation of concerns
•  Blocks allocated to hardware components and processors
•  Blocks allocated to software components
Control
«control»
cThrottle Controller
Alg_Derivative
Alg_Integral
Alg_Proportional
ThrottlePosition
SpeedValue
NormalisedSpeedValue
SetSpeedValue ()
Reset ()
SetNormalisedSpeedValue ()
BrakeEngaged ()
GearShift ()
Suspend ()
Resume ()
cSpeedMonitor
CalibrationFactor
RawSpeed
SetRawSpeed ()
CalcNormalisedSpeed ()
External Interface
«boundary»
eBrakePedalMonitor
«boundary»
eCruiseControlPanel
SpeedSetPoint
Switch_Pressed ()
Set_Speed ()
«boundary»
eEMUIF
ThrottlePosition
Set_Throttle ()
«boundary»
eTransmissionMonitor
Persistence Support
pAccelerationProfile pCalibration Manager
WheelCircumference
1
1
Calibrates
1 1
Provides Speed
1
1
Stops Cruise Control
1
1
Driver Input
1
1
Profiles
1
1
Sets Throttle Position
1
1
Provides Readings
bdd [Package] CC System Software
«Block»
«Block»
«boundary»
allocatedFrom
Decrement ()
Disengage ()
Display Speed ()
EMU Message ()
Engage ()
Engage Brake ()
Increment ()
Resume ()
Set Speed ()
Shift ()
Suspend ()
allocatedTo
CC Motherboard
External Interface
Interface
«Block»
«control»
allocatedFrom
Error
Maintain Speed
Operate Cruise Control
Power Off
Power On
Calculate Throttle Position
allocatedTo
CC Motherboard
Control
Control
«Block»
«entity»
allocatedFrom
Log Error ()
Load Acceleration Profile ()
allocatedTo
CC Motherboard
Persistence Support
Persistence
11
CCIF
1
1 CCCtrl
1
1
Perst
«part»
CCUnit : Cruise Control Unit
«part»
«multidropBus»
CANbus : CAN
«part»
«board»
CCUio : CC IO Card
CCDispIF
BrakeIF : Digital
CANIF
EngDisIF
SetIF
SusResIF
TransmIF : Analogue
EMUIF : RS232IncIF
DecIF
«part»
«board»
CCUmb : CC
Motherboard
CANIF
«part»
«multidropBus»
CANbus : CAN
«part»
«board»
CCUio : CC IO Card
CCDispIF
BrakeIF : Digital
CANIF
EngDisIF
SetIF
SusResIF
TransmIF : Analogue
EMUIF : RS232IncIF
DecIF
CCDispIF
BrakeIF : Digital
CANIF
EngDisIF
SetIF
SusResIF
TransmIF : Analogue
EMUIF : RS232IncIF
DecIF
«part»
«board»
CCUmb : CC
Motherboard
CANIFCANIF
: EMU Message
: AnalogueMessage
Gear : Analogue
«ItemFlow»

29
Software Model Allocation
Control
«control»
Alg_Derivative
Alg_Integral
Alg_Proportional
ThrottlePosition
SpeedValue
NormalisedSpeedValue
SetSpeedValue ()
Reset ()
SetNormalisedSpeedValue ()
BrakeEngaged ()
GearShift ()
Suspend ()
Resume ()
cSpeedMonitor
CalibrationFactor
RawSpeed
SetRawSpeed ()
CalcNormalisedSpeed ()
External Interface
«boundary»
eBrakePedalMonitor
«boundary»
eCruiseControlPanel
SpeedSetPoint
Switch_Pressed ()
Set_Speed ()
«boundary»
eEMUIF
ThrottlePosition
Set_Throttle ()
«boundary»
eTransmissionMonitor
Persistence Support
pAccelerationProfile pCalibration Manager
WheelCircumference
1
1
Stops Cruise Control
1
1
Driver Input
1
1
Profiles
1
1
Sets Throttle Position
1
1
Provides Readings
1
1
Calibrates
1 1
Provides Speed
allocatedFrom
«Block» Control
allocatedFrom
«Block» Interface
allocatedFrom
«Block» Persistence

30
State Machines
•  Overall System state machine on left defines requirements
•  Throttle controller implements in software
stm [Block] Cruise Control System
Fault
do : Log Error
do : Disengage
Operating
do : Maintain Speed
Decrement Reqd Speed/Decrement Speed
Increment Reqd Speed/Increment Speed
Accelerate Vehicle
Set Speed/
Accelerating
do : Resume
Suspended
do : Suspend
Engaged
Idle
Power On
Engage/
Do Initialisation tests
CCerror/...
Disengage/
Resume[(Set Speed <> 0)&
(Brake Not Engaged)]/
[Set Speed Reached]/
Set Speed/
Suspend/
[test fail]/
[els e]/
Power Off/
Power On/
Accelerate
Maintain Target Speed
SetSpeedValue/
Active
Initialize
Disengage
when( On Switch )/
when( Complete )/
SetSpeedValue/
when( Speed Reached )/
when( Accelerate Button )/
BrakeEngaged/
when( Off Switch )/
when( Off Switch )/
Suspend/
Resum e/

Data Modeling
•  SysML is used to specify data modeling requirements
•  UML is used to model data model implementation in software

Central Monitoring Station As-Is
Police
Residence
Dispatcher Intruder
Comm Network
bdd [package] Enterprise (As Is)
Alarm System Context

34
Alarm System Breakdown

35
Logical Functions of Alarm System

36
BDD of Hardware

37
SysML Allocation of SW to HW
n  In UML the
deployment
diagram is used
to deploy
artifacts to
nodes
n  In SysML
allocation on
ibd and bdd is
used to deploy
software/data
to hardware

38
SysML Level –
System Level
SysML/UML
Level –
Component
Level
(for each
Component)
SysML Level –
Subsystem
Level
(for each
Subsystem)
SysML to UML Allocation

40
Problem Statement
•  1. General Background
– The city of Autoville has just elected a new city council with a mandate to reduce traffic on the
highways and thoroughfares. After receiving a grant of $200M from the federal government, they
have decided to acquire a traffic management system to help them identify areas and times of
high traffic density so they can take measures to alleviate the effects of it. The city of Autoville has
100 miles of highway with 10 interchanges and 300 miles of thoroughfares with 100 major
intersections.

41
Requirements
•  The requirements specified by the management are:
– - The system shall identify traffic levels on all highways and thoroughfares.
– - The system shall provide traffic data for intervals not greater than 1 mile for highways and ¼
mile for thoroughfares.
– - The system shall provide traffic data that is no more than 5 minutes old.
– - The system shall record traffic data for 30 days.
– - The system shall provide a 24-hour centralized control room capable of being manned by no
more than 2 persons at any time.
– - The system shall provide live video surveillance of major highways to a centralized control room.
– - The system shall automatically report major traffic-causing incidents to the control room within
10 minutes.

42
Requirements
•  The requirements specified by the management are:
– - The system shall estimate total delay time per accident.
– - The system shall record length of backup per accident.
– - The system shall estimate time to clear accident and resume normal flow.
– - The system shall provide user-defined reports to support future highway and thoroughfare
planning and construction.
– - The system shall have an operational life of not less than 10 years.
– - The development cost of the system shall not exceed $100M.
– - The operations and maintenance cost of the system shall not exceed $10M per year.
– - The system shall be operational by Dec 30th, 2012.

43
OV-1 Operational Concept with Graphics

44
CV-2 Capability Taxonomy with Implementing Resources
CV-2 [Architectural Description] Capabilities [CV-2 Resources]
«Capability»
«block»
realizingResource
«Software» Traffic Flow Calculation SW
Calculate Traffic Levels
«Capability»
«block»
Communication
«Capability»
«block»
realizingResource
«Software» Emergency Services SW
«Software» Traffic Control SW
Coordination
«Capability»
«block»
realizingResource
«Software» Emergency Services SW
«Software» Traffic Event SW
Respond to Traffic Event
«Capability»
«block»
realizingResource
«Software» Traffic Signal SW
«System» Control Center
«System» Control Room
«System» Traffic Display Board
«Software» Traffic Control SW
Traffic Control
«Capability»
«block»
realizingResource
«Software» Traffic Data Archive SW
Provide Traffic History
«Capability»
«block»
realizingResource
«Software» Traffic Prediction SW
Traffic Prediction
«Capability»
«block»
realizingResource
«Software» Traffic Report Generation SW
Traffic Reporting
«Capability»
«block»
realizingResource
«Materiel» Video
«Materiel» User Interface
«Software» Video Processing SW
«Software» Sensor Processing SW
«Software» Traffic Display SW
«Materiel» Traffic Sensor
Traffic Surveillance
Traffic Context

45
SV-1 Traffic Management Systems
SV-1/SvcV-1 [System] Traffic Context [SV-1]
«System»
«block»
Traffic Context
«SystemRole»
CC : Control Center
«SystemRole»
CR : Control Room
«SystemRole»
CS : Control System
«SystemRole»
UI1 : User Interface
«SystemRole»
«SystemRole»
CRO1 : Control Room Operator
«SystemRole»
«SystemRole»
WS : Weather Services
«SystemRole»
ES : Emergency Services
«SystemRole»
CP : City Planning
«SystemRole»
1..*
MM : Mass Media
«SystemRole»
IN : Internet
«SystemRole»
1..*
Veh : Vehicle
«SystemRole»
100
VID : Video
«SystemRole»
1000
TS : Traffic Sensor
«SystemRole»
1..*
TMS : Traffic Display Board
«SystemRole»
1..*
EV : Event Venue
«SystemRole»
1..*
TS : Traffic Signal
«SystemRole»
RM : Road Maintenance
WS->CS:WR : Weather Report
CS->CP:TPR : Traffic Planning Report
CS->ES:SR : Service RequestES->CS:SS : Service Status
CS->UI:TF : Traffic Flow
CS->UI:SS : Service Status
CS->UI:VD : Video Data
CS->UI:RT : Road Topology
CS->UI:TR : Traffic Report
CS->UI:ES : Event Schedule
CS->MM:TR : Traffic Report
CS->IN:TR : Traffic Report
RM->CS:SS : Service Status
TS->CS:SD : Sensor Data
VID->CS:VD : Video Data
CS->TMS:TSM : Traffic Status Message
EV->CS:ES : Event Schedule
CS->TS:TSS : Traffic Signal Schedule
CS->RM:SR : Service Request

46
SV-1 Control Room Detail
SV-1/SvcV-1 [System] Control Room [Sv-1]
«System»
«block»
Control Room
«SystemRole»
«SystemRole»
«SystemRole»
CS : Control System
«SystemRole»
«SystemRole»
UI1->CR01:SS : Service Status
UI1->CR01:Vd : Video Data
UI1->CR01:TF : Traffic Flow
CR01->UI1:SR : Service Request
UI2->CR02:TR : Traffic Report
CR02->UI2:TRR : Traffic Report Request
UI2->CR02:ES : Event Schedule
UI2->CR02:RT : Road Topology
CS->UI:ES : Event Schedule
CS->UI:RT : Road Topology
CS->UI:TR : Traffic Report
UI2->CS:TRR : Traffic Report Request
CS->UI:SS : Service Status
CS->UI:TF : Traffic Flow
CS->UI:VD : Video Data
UI1->CS:SR : Service Request

47
SV-2 Software Interfaces and Interactions
SV-2/SvcV-2 [System] Control System [SV-2]
«System»
«block»
Control System
«SystemRole»
TPSW : Traffic Prediction SW
SP
WP
CS
«SystemRole»
TFCSW : Traffic Flow Calculation SW
SP
VP
TRG
TE
«SystemRole»
VPSW : Video Processing SW
TFC
CS
WebP
«SystemRole»
SPSW : Sensor Processing SW
TFC
TP
«SystemRole»
TRGSW : Traffic Report Generation SW
TFC
Web
DB
TC
TDA
«SystemRole»
TDSW : Traffic Display SW
«SystemRole»
ESSW : Emergency Services SW
CS
TC
«SystemRole»
WPSW : Weather Processing SW
TP
CS
«SystemRole»
WebPSW : Web Presence SW
TRGVP
CS
«SystemRole»
TSSW : Traffic Signal SW
TC
CS
«SystemRole»
DBSW : Display Board SW
TRG
CS
VP : Video Data
TP : Sensor Data
ES
WP : Weather Report
«SystemRole»
TCSW : Traffic Control SW
TRG
ES
TS
TE
DB
«SystemRole»
TDA : Traffic Data Archive SW
RG
«SystemRole»
TESW : Traffic Event SW
TE
TC
Web
TS
SP->TFC:SD : Sensor Data
SP->TP:SD : Sensor Data
VP->TFC:VD : Video DataCS->VP:VD : Video Data
FC->TRG:TF : Traffic Flow
TRG->Web:TR : Traffic Report
VP->Web:VD : Video Data
TRG->DB:TR : Traffic Report
WP->TP:WR : Weather Report
CS->TP:SD : Sensor Data
ES->CS:SR : Service Request
CS->ES:SS : Service Status
CS->WP:WR : Weather Report
TRG->TC:TR : Traffic Report
TC->TS:TSS : Traffic Signal Schedule
DB->CS : Traffic Status Message
Web->CS:TR : Traffic Report
TFC->TE:TF : Traffic Flow
TE->TC:AER : Accident Event Report
TS->CS:TSS : Traffic Signal Schedule
TRG->TDA:TR : Traffic Report
[Architectural Description] Resources [SV-3]
[System] Control Room [SV-6]
[Architectural Description] System Activities [SV-4]

48
The Importance of Process
• Building a system without a model is
like building a house without
architectural diagrams
• The process describes what to do
when and with what.
– Lay the foundation
– Add the exterior structures
– Add the plumbing and electrical wiring
– Etc.

49
So, will it work?
•  So, will software engineers look at all this as systems engineers meddling
in their area and telling them how to design software? Given the level of
internal competition and conflict, I have found on some projects, it is a
question worth asking. A well defined process can help. It should instruct
the systems engineers how to describe the software functional
requirements and constraints, and (when specified by the requirements)
the architecture without straying into software design. Most importantly, it
will tell them when to stop.

50
Conclusion
• UML 2 has increased the usability of UML for Systems and
Software Engineers
• SysML has improved this with the:
– Activity Diagram extensions
– Block Diagrams
– Parametric Diagram
– Requirements Diagram
– Cross cutting principals
• A well-defined process is essential for a successful project
• To be successful, Systems Engineers must communicate and
disseminate concepts, requirements, standards, etc.

51
Questions and Answers
DescriptionDescription You
:Attendee
Me
:Speaker
loop1
You
:Attendee
Me
:Speaker
loop1 while open questions exist
Question1.1
end loop
while open questions exist
Question1.1
Question
Answer1.1.1
Question
Answer1.1.1
AnswerAnswer
end loop
{Speech Time}{Speech Time}

For more insights take a look at our
Systems Engineering Resource Center
www.ptc.com/topics/systems-engineering52

Matthew Hause Building Bridges between Systems and Software with SysML and UML

Matthew Hause Building Bridges between Systems and Software with SysML and UML

More Related Content

What's hot (16)

Viewers also liked (13)

Similar to Matthew Hause Building Bridges between Systems and Software with SysML and UML (20)

Recently uploaded (20)

Matthew Hause Building Bridges between Systems and Software with SysML and UML