View
599
Download
5
Tags:
Embed Size (px)
Citation preview
Building Bridges Between Systems and Software with SysML and UML
Matthew Hause PTC GTM Solutions Specialist, Fellow
March 17, 2015
2 Copyright © 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 Copyright © 2015 PTC All Rights Reserved
4
Author 1..* 1..*
Response
Repository cap_Baseline_Project( ) cap_Control_Access( )
Item > Status
Con
cept
ual B
arrie
r 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 ([email protected])
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.
Copyright © 2015 PTC All Rights Reserved
The Systems Engineering Process (Bahill, Gissing, 1998)
7
OOSEM System Development Process
Procedures
ManageSystem
Development
Define SystemReqt's &Design
Integrate& TestSystem
System
StakeholderReqts
System archAllocated reqt's
DataHardware
SoftwareDevelopSystemElement
SystemElement
Plan
StatusTechnical 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)
Copyright © 2015 PTC All Rights Reserved
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)
Copyright © 2015 PTC All Rights Reserved
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]
: AccelerationEquationF c
a
: BrakingForceEquationtf
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 SystemSpecification
Braking SubsystemSpecification
«requirement»
id#102
txtThe vehicle shall stop from60 mph within 150ft on aclean dry surface.
Stopping Distance
«requirement»
id#337
txtThe Braking subsystem shallprevent wheel lockup underall braking conditions.
Anti-Lock Performance
req [Package] Vehicle Specifications [Braking]
«deriveReqt»
3. Requirements
bdd [Package] Vehicle [ABS]
«Block»Library::ElectronicProcessor
«Block»Anti-LockController
«Block»Library::
Electro-HydraulicValve
«Block»TractionDetector
«Block»Brake
Modulator
d1 m1
definition
Gripping Slipping
LossOfTrac tion/
RegainTraction/
stm Tire [Traction]state machine
Detect Loss Of Traction
TractionLoss Modulate Braking Force
act PreventLockup
activity/ function
14
Cross Connecting Model Elements
Copyright © 2015 PTC All Rights Reserved
14
ibd [block] Anti-LockController [Internal Block Diagram]
d1:Traction Detector
m1:Brake Modulator
c1:modulator interface
ibd [block] Anti-LockController [Internal Block Diagram]
allocatedFrom«activity»DetectLosOfTraction
d1:TractionDetector
allocatedFrom «activity»Modulate BrakingForce
m1:BrakeModulator
allocatedFrom«ObjectNode»TractionLoss:
c1:modulatorInterface
act PreventLockup [Activity Diagram]
DetectLossOf Traction
Modulate BrakingForceTractionLoss:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[F = ma]
:VelocityEquation[a = dv/dt]
:DistanceEquation[v = dx/dt]
:BrakingForceEquation
[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 BrakingForceTractionLoss:
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»
ibd [block] Anti-LockController [Internal Block Diagram]
allocatedFrom«activity»DetectLosOfTraction
d1:TractionDetector
allocatedFrom «activity»Modulate BrakingForce
m1:BrakeModulator
allocatedFrom«ObjectNode»TractionLoss:
c1:modulatorInterface
satisfies«requirement»Anti-LockPerformance
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
SatisfiedBy«block»Anti-LockController
id=”337"text=”Braking subsystem shall prevent wheel lockup under all braking conditions.”
«requirement»Anti-LockPerformance
«deriveReqt»
ibd [block] Anti-LockController [Internal Block Diagram]
allocatedFrom«activity»DetectLosOf Traction
d1:TractionDetector
valuesDutyCycle: Percentage
allocatedFrom «activity»Modulate BrakingForce
m1:BrakeModulator
allocatedFrom«ObjectNode»TractionLoss:
c1:modulatorInterface
satisfies«requirement»Anti-LockPerformance
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[F = ma]
:VelocityEquation[a = dv/dt]
:DistanceEquation[v = dx/dt]
:BrakingForceEquation
[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:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[F = ma]
:VelocityEquation[a = dv/dt]
:DistanceEquation[v = dx/dt]
:BrakingForceEquation
[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:
req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements]
Braking Subsystem Specification
Vehicle System Specification
VerifiedBy«interaction»MinimumStoppingDistance
id=“102”text=”The vehicle shall stop from 60 mph within 150 ft on a clean dry surface.”
«requirement»StoppingDistance
SatisfiedBy«block»Anti-LockController
id=”337"text=”Braking subsystem shall prevent wheel lockup under all braking conditions.”
«requirement»Anti-LockPerformance
«deriveReqt»
satisfy
verify
value binding
allocate
15 Copyright © 2015 PTC All Rights Reserved
SysML Requirements Traceability
Activities
«activity»Decrement Speed
«activity»Increment Speed
Cruise Control System
MaintainSpeed
«requirement»
txtWhen cruise control is engaged, the driver must be able toincrement the desired speed in increments of 1 MPH.
REQ_CCS_04a
«requirement»
txtWhen cruise control is engaged, the driver must be able todecrement the desired speed in increments of 1 MPH.
REQ_CCS_04b
«requirement»
txtWhen cruise control is active, the driver must be able to increment ordecrement the desired speed (in increments of 1 MPH). The drivermust also have the ability to change the gear selection whilst cruisecontrol is active.
REQ_CCS_04
«requirement»
txtThe CCS must allow a driver to enable the vehicle to maintain adesired speed.
satisfiedByMaintain Speed (in changeSpeed : Integer, in EMUMessage : EMUOP Message = every 10ms, out ThrottleMessage : EMU Analog IPMessage)
REQ_CCS_01
«requirement»
txtThe CCS must allow cruise control to be engaged and disengaged. Whenengaged the cruise control system is available to accept driver instructions (suchas 'set' and 'disengage'). When disengaged, the cruise control system will notrespond 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»
16 Copyright © 2015 PTC All Rights Reserved
Requirements Traceability Relationships
Traceability relationships stored in the model
18
Requirements Traceability from Other Diagrams
Copyright © 2015 PTC All Rights Reserved
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
Copyright © 2015 PTC All Rights Reserved
20
Behavioral Allocation – Actions to Parts using Activity Diagram Swimlanes
Copyright © 2015 PTC All Rights Reserved
Parts
Actions
21 Copyright © 2015 PTC All Rights Reserved
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 SubsystemCCIF 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
24
UML: System Definition Use Case View and Relationships
Copyright © 2015 PTC All Rights Reserved
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
: 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: Receiver
: Transmitter
: Antenna Controller
: Power Supply
: Tx Rx Duplex
: Power Supply
: Tx Rx Duplex
: Array Orientation
: Mechanical Orientation
: Elevation Actuator
: Azimuthal Actuator
: Mechanical Orientation
: Elevation Actuator
: Azimuthal Actuator
: Elevation Actuator
: Azimuthal Actuator
: Electronic Orientation
: User Displays
: Display : Keypad: Display : Keypad
Operator
Requirements
Pilot
StoresNavigation Data
DeploysWeapon
PerformsSorte
Use Case Model
The Software:The SoftwarePilot Data Entry Panel
Pilot Presses Key Key PressSoftware Determines new Mode Key Press( KEY ID )if NAV Key then
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end caseend if
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
when Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
The Software:The SoftwarePilot Data Entry Panel
Pilot Presses Key Key PressSoftware Determines new Mode Key Press( KEY ID )if NAV Key then
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end caseend if
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
when Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
The Software:The SoftwarePilot Data Entry Panel
Pilot Presses Key Key PressSoftware Determines new Mode Key Press( KEY ID )if NAV Key then
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end caseend if
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
when Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
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]/
[e ls e]/
[e ls e]/
250 bar/Stop Compressor
150 bar/Start Compressor
[LOP alarm ringing]/
Interaction Overview (Modes) Diagram
Test Scripts
OperationalParameters Performance
Loader Speed
Belt Speed
Containers ScanSuccess
DefectiveContainers 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
Copyright © 2015 PTC All Rights Reserved
::Person
NameAgeAssignUn-Assign
::Company
Name
::Contract
Start DateSalaryGradeChange Grade
::Work Instruction
DescriptionStart DateDurationPerformance RatingAgree Performance Rating
::Revenue Item
Cost
::Product ::Service
::Development Plan
Mean PerformanceTraining NeedsCurrent Skills
::Contractual Constraint
DescriptionUpdate
::Term ::Condition
11..* Works ForEmployee Employer
1..*1
Manages
Manager
Worker
1..*
1
Markets
Manufacturer
1..*1 Describes Work On
*
0..11
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:The SoftwarePilot Data Entry Panel
Pilot Presses Key Key PressSoftware Determines new Mode Key Press( KEY ID )if NAV Key then
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end caseend if
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
when Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
The Software:The SoftwarePilot Data Entry Panel
Pilot Presses Key Key PressSoftware Determines new Mode Key Press( KEY ID )if NAV Key then
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end caseend if
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
when Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
The Software:The SoftwarePilot Data Entry Panel
Pilot Presses Key Key PressSoftware Determines new Mode Key Press( KEY ID )if NAV Key then
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end caseend if
Enter Navigation ModeSet Mode( NAV )elsif Weapons Key then
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
case Selected Store iswhen Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
end case
when Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )
Scenario Model
Source Files
running downEntry/monitor.inhibit(LOP);timer.set(40);motor.stop;valve[inlet].close;valve[outlet].close;valve[by-pass].open; ...
stopped
waiting for oil pressure to buildEntry/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
: 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
: 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: Receiver
: Transmitter
: Antenna Controller
: Power Supply
: Tx Rx Duplex
: Power Supply
: Tx Rx Duplex
: Array Orientation
: Mechanical Orientation
: Elevation Actuator
: Azimuthal Actuator
: Mechanical Orientation
: Elevation Actuator
: Azimuthal Actuator
: Elevation Actuator
: Azimuthal Actuator
: Electronic 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.
Copyright © 2015 PTC All Rights Reserved
27 Copyright © 2015 PTC All Rights Reserved
Block Structure
bdd [Package] CC System Software
«Block»Cruise Control System
«Block»«boundary»
allocatedFromDecrement ()Disengage ()Display Speed ()EMU Message ()Engage ()Engage Brake ()Increment ()Resume ()Set Speed ()Shift ()Suspend ()
allocatedToCC MotherboardExternal Interface
Interface
«Block»«control»
allocatedFromErrorMaintain SpeedOperate Cruise ControlPower OffPower OnCalculate Throttle Position
allocatedToCC MotherboardControl
Control
«Block»«entity»
allocatedFromLog Error ()Load Acceleration Profile ()
allocatedToCC MotherboardPersistence Support
Persistence
11CCIF
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
Copyright © 2015 PTC All Rights Reserved
Control
«control»cThrottle Controller
Alg_DerivativeAlg_IntegralAlg_ProportionalThrottlePositionSpeedValueNormalisedSpeedValueSetSpeedValue ()Reset ()SetNormalisedSpeedValue ()BrakeEngaged ()GearShift ()Suspend ()Resume ()
cSpeedMonitor
CalibrationFactorRawSpeedSetRawSpeed ()CalcNormalisedSpeed ()
External Interface
«boundary»eBrakePedalMonitor
«boundary»eCruiseControlPanel
SpeedSetPointSwitch_Pressed ()Set_Speed ()
«boundary»eEMUIF
ThrottlePositionSet_Throttle ()
«boundary»eTransmissionMonitor
Persistence Support
pAccelerationProfile pCalibration Manager
WheelCircumference
1
1
Calibrates
1 1Provides Speed
1
1
Stops Cruise Control1
1
Driver Input
1
1
Profiles
1
1
Sets Throttle Position
1
1
Provides Readings
bdd [Package] CC System Software
«Block»Cruise Control System
«Block»«boundary»
allocatedFromDecrement ()Disengage ()Display Speed ()EMU Message ()Engage ()Engage Brake ()Increment ()Resume ()Set Speed ()Shift ()Suspend ()
allocatedToCC MotherboardExternal Interface
Interface
«Block»«control»
allocatedFromErrorMaintain SpeedOperate Cruise ControlPower OffPower OnCalculate Throttle Position
allocatedToCC MotherboardControl
Control
«Block»«entity»
allocatedFromLog Error ()Load Acceleration Profile ()
allocatedToCC MotherboardPersistence Support
Persistence
11CCIF
1
1 CCCtrl
1
1
Perst
«part»CCUnit : Cruise Control Unit
«part»«multidropBus»CANbus : CAN
«part»«board»
CCUio : CC IO Card
CCDispIF
BrakeIF : Digital
CANIFEngDisIF
SetIF
SusResIFTransmIF : Analogue
EMUIF : RS232IncIF
DecIF
«part»«board»
CCUmb : CCMotherboard
CANIF
«part»«multidropBus»CANbus : CAN
«part»«board»
CCUio : CC IO Card
CCDispIF
BrakeIF : Digital
CANIFEngDisIF
SetIF
SusResIFTransmIF : Analogue
EMUIF : RS232IncIF
DecIF
CCDispIF
BrakeIF : Digital
CANIFEngDisIF
SetIF
SusResIFTransmIF : Analogue
EMUIF : RS232IncIF
DecIF
«part»«board»
CCUmb : CCMotherboard
CANIFCANIF
: EMU Message
: AnalogueMessage
Gear : Analogue«ItemFlow»
29
Software Model Allocation
Copyright © 2015 PTC All Rights Reserved
Control
«control»cThrottle Controller
Alg_DerivativeAlg_IntegralAlg_ProportionalThrottlePositionSpeedValueNormalisedSpeedValueSetSpeedValue ()Reset ()SetNormalisedSpeedValue ()BrakeEngaged ()GearShift ()Suspend ()Resume ()
cSpeedMonitor
CalibrationFactorRawSpeedSetRawSpeed ()CalcNormalisedSpeed ()
External Interface
«boundary»eBrakePedalMonitor
«boundary»eCruiseControlPanel
SpeedSetPointSwitch_Pressed ()Set_Speed ()
«boundary»eEMUIF
ThrottlePositionSet_Throttle ()
«boundary»eTransmissionMonitor
Persistence Support
pAccelerationProfile pCalibration Manager
WheelCircumference
1
1
Stops Cruise Control1
1
Driver Input
1
1
Profiles
1
1
Sets Throttle Position
1
1
Provides Readings
1
1
Calibrates
1 1Provides 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
Copyright © 2015 PTC All Rights Reserved
stm [Block] Cruise Control System
Faultdo : Log Errordo : Disengage
Operatingdo : Maintain SpeedDecrement Reqd Speed/Decrement SpeedIncrement Reqd Speed/Increment SpeedAccelerate VehicleSet Speed/
Acceleratingdo : Resume
Suspendeddo : Suspend
Engaged
Idle
Power On
Cruise Control System
Engage/Do Initialisation tests
CCerror/.. .
Disengage/
Resume[(Set Speed <> 0)&(Brake Not Engaged)]/
[Set Speed Reached]/
S et S peed/
S uspend/[tes t fa il] /
[e ls e ] /
P ower O ff/
P ower On/
Accelerate
Maintain Target SpeedSetSpeedValue/
Active
Initialize
Disengage
cThrottle Controller
when( On Switch )/
when( Complete )/
SetSpeedValue/
when( Speed Reached )/
when( Accelerate Button )/
B rakeEngaged/
when( Off Switch )/
when( Off Switch )/
S uspend/
Res um e/
31 Copyright © 2015 PTC All Rights Reserved
Data Modeling
• SysML is used to specify data modeling requirements • UML is used to model data model implementation in software
33 Copyright © 2015 PTC All Rights Reserved
Central Monitoring Station As-Is
Police
Residence
Dispatcher Intruder
Comm Network
bdd [package] Enterprise (As Is)
Alarm System Context
37
SysML Allocation of SW to HW
Copyright © 2015 PTC All Rights Reserved
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.
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»UI2 : User Interface
«SystemRole»CRO1 : Control Room Operator
«SystemRole»CRO2 : Control Room Operator
«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 ScheduleCS->RM:SR : Service Request
46
SV-1 Control Room Detail
SV-1/SvcV-1 [System] Control Room [Sv-1]
«System»«block»
Control Room
«SystemRole»CRO1 : Control Room Operator
«SystemRole»CRO2 : Control Room Operator
«SystemRole»CS : Control System
«SystemRole»UI1 : User Interface
«SystemRole»UI2 : User Interface
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
TRGTE
«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
TPCS
«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
Copyright © 2015 PTC All Rights Reserved
• 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.
Copyright © 2015 PTC All Rights Reserved
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.
Copyright © 2015 PTC All Rights Reserved
51
Questions and Answers
DescriptionDescription You:Attendee
Me:Speaker
loop1
You:Attendee
Me:Speaker
loop1 while open questions existQuestion1.1
end loop
while open questions existQuestion1.1 Question
Answer1.1.1Question
Answer1.1.1 AnswerAnswerend loop
{Speech Time}{Speech Time}
For more insights take a look at our Systems Engineering Resource Center
www.ptc.com/topics/systems-engineering 52