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

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

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.


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)


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]

: 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


14

ibd [block] Anti-LockController [Internal Block Diagram]

d1:Traction Detector

m1:Brake Modulator

c1:modulator interface


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»


allocatedFrom«activity»DetectLosOfTraction

d1:TractionDetector


m1:BrakeModulator



satisfies«requirement»Anti-LockPerformance






SatisfiedBy«block»Anti-LockController



«deriveReqt»


allocatedFrom«activity»DetectLosOf Traction

d1:TractionDetector

valuesDutyCycle: Percentage


m1:BrakeModulator



satisfies«requirement»Anti-LockPerformance






[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:






[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:




VerifiedBy«interaction»MinimumStoppingDistance



SatisfiedBy«block»Anti-LockController



«deriveReqt»

satisfy

verify

value binding

allocate


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»


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


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

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



end case


end case

when Loft Bombs => Set Mode( LOFT )when Retard Bombs => Set Mode( RETARD )when Guns => Set Mode( GUN )when Rockets => Set Mode( ROCKET )





end caseend if



end case


end case






end caseend if



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]/

[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


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





end caseend if



end case


end case






end caseend if



end case


end case






end caseend if



end case


end case


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


: 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»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


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


EMUIF : RS232IncIF

DecIF

CCDispIF

BrakeIF : Digital

CANIFEngDisIF

SetIF


EMUIF : RS232IncIF

DecIF

«part»«board»

CCUmb : CCMotherboard

CANIFCANIF

: EMU Message

: AnalogueMessage

Gear : Analogue«ItemFlow»

29

Software Model Allocation


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


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/


Data Modeling

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

32

Alarm System Example


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

39

Traffic Management Example

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


Communication


realizingResource«Software» Emergency Services SW«Software» Traffic Control SW

Coordination


realizingResource«Software» Emergency Services SW«Software» Traffic Event SW

Respond to Traffic Event


realizingResource«Software» Traffic Signal SW«System» Control Center«System» Control Room«System» Traffic Display Board«Software» Traffic Control SW

Traffic Control


realizingResource«Software» Traffic Data Archive SW

Provide Traffic History


realizingResource«Software» Traffic Prediction SW

Traffic Prediction


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»CRO1 : 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»CS : Control System



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


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

matthew hause building bridges between systems and software with sysml and uml

Engineering

role of systems engineering

system requirements

software engineering

software engineering

system hierarchy

confidential systems

problem engineering

software risks