comparison of state machines in uml2 and modelica 3 · comparison of state machines in uml2 and...

Comparison of State Machines

in UML2 and Modelica 3.3

A Modeler Perspective

Wladimir Schamai, Philipp Helle (Airbus Group Innovations, Hamburg, Germany)

MODPROD, February 2014

Table of Contents

- Introduction

- Basic execution semantics and event processing (reactive/run-to-completion vs. clocked behavior)

- Event Processing

- Conflicting transitions

- Modelica 3.3 state machine: In-State Actions

- UML2 state machine: Compound transitions

- UML2 state machine: Inter-level transitions (transitions that cross state hierarchy borders)

Introduction

- In the 1980s David Harel invented Statecharts

- Statechart = FSMs + depth + orthogonally

- Harel, David. "Statecharts: A visual formalism for complex systems." Science of computer programming 8, no.

3 (1987): 231-274.

- Since 1990s: Statecharts are supported by the object-oriented modeling tool Rhapsody (IBM Rational)

- Ca. since 2000: OMG Unified Modelica Language (UML) 1.3 includes state machines that are based on David

Harel’s statecharts

- 2013: Modelica state machines are introduced in Modelica 3.3

- “The semantics of the state machines is inspired by mode automata and is basically the one from Lucid

Synchrone 3.0”

- “Modelica state machines have a similar modeling power as Statecharts (Harel 1987) …”

- 2013: Dymola (Dassault Systèmes) supports Modelica 3.3 state machines

UML2 state machines and Modelica 3.3 state machines are similar but… very different!

Introduction: UML2 (Rhapsody) State Machine Example

04 February 2014

Comparison of State Machines in UML2 and Modelica 3.3

4

printingLayout1

printingLayout2

inQueue

waitToPrint

evAbort

evAbort

[qEnabled == true][else]

[qEmpty == true][qEmpty == true]

[qEmpty == true]

initializePrinting

[else]

evReady

[selectedLayout == 1] [else]

waitForJob

evNewPrint

evFinished

evFinished

State:

(optional) entry/exit actions,

in-state reactions

Transition:

(optional) trigger

+ (optional) guard Boolean expression

+ (optional) transition effect

Pseudo states:

e.g., “condition”,

“junction”

Initial Transition

Trigger event

Introduction: Modelica 3.3 State Machine Example

04 February 2014


5

State:

(optional) in-state equations

Transition:

guard (Boolean expression)

Initial Transition

Basic Execution Semantics

UML2 (tool: Rhapsody, IBM Rational)

- Reactive state machines

- State machine is evaluated when an event is

dispatched to it

- Event processing

- Events are queued and dispatched to the state

machine one after another (FIFO); No

simultaneous events are possible

- Run-to-completion: after an event is dispatched all

active (null) transitions are executed until the state

machine is in stable state configuration

04 February 2014


6

Modelica 3.3 (tool: Dymola, DS)

- Clocked state machines

- State machine is evaluated at clock tick (i.e., no

evaluation between ticks)

- Event processing

- State machine can only react to events at clock

ticks; Simultaneous events are processed

simultaneously

- All transition guards are evaluated once at a

clock tick

Reactive (+ Run-To-Completion) vs.

Clocked Behavior

04 February 2014


7

UML2 (Rhapsody): Run-to-Completion Semantics

- Run-to-completion semantics: after an event is dispatched all active transitions are executed until the state


05 February 2014


8

state_0

state_1 state_2ev1[x>0]

[y>0]

x = 1; y = 2;

state_0

state_1 state_2ev1[x>0]

[y>0]

UML2 (Rhapsody): Run-to-Completion Semantics

- Run-to-completion semantics: after an event is dispatched all active transitions are executed until the state


- Deadlocks (infinite looping) are possible

05 February 2014


9

x = 1; y = 2;

state_0

state_1 state_2[x>0]

[y>0]

Modelica 3.3: Clocked Execution Semantics for State Machines

- All transition guards are evaluated once at a clock tick

- No infinite looping

04 February 2014


10

Modelica 3.3: Clocked Execution and Events Between Clock Ticks

• State machine clock period needs to be selected

carefully in order to ensure sensing of continuous

variables required for the state machine evaluation

04 February 2014


11

Event Processing

04 February 2014


12

February 4, 2014


13

UML2 (Rhapsody): Concurrent Events

• Processing of events is typically implemented in UML2 tools using event queues

• Events are queued and dispatched to state machine one after another (FIFO)

• This may lead to a misleading interpretation of the state machine diagram

state_0

state_1_l

Reactions

GEN(ev1());

state_2_l

ev1

state_3_l

ev2

state_1_r

Reactions

GEN(ev2());

state_2_r

ev1

state_3_r

ev2

state_0

state_1_l

Reactions

GEN(ev1());

state_2_l

ev1

state_3_l

ev2

state_1_r

Reactions

GEN(ev2());

state_2_r

ev1

state_3_r

ev2

February 4, 2014


14

UML2 (Rhapsody): Concurrent Events

• Changing the generation order of events in orthogonal regions leads to different behavior

state_0

state_1_l

Reactions

GEN(ev2());

state_2_l

ev1

state_3_l

ev2

state_1_r

Reactions

GEN(ev1());

state_2_r

ev1

state_3_r

ev2

state_0

state_1_l

Reactions

GEN(ev2());

state_2_l

ev1

state_3_l

ev2

state_1_r

Reactions

GEN(ev1());

state_2_r

ev1

state_3_r

ev2

- Simultaneous events are not queued, they are

processed simultaneously

Modelica 3.3: Concurrent Events

04 February 2014


15

Conflicting Transitions

04 February 2014


16

UML2 (Rhapsody): Handling Conflicting Transitions at the Same State

Hierarchy Level

- UML2 does not specify how to resolve conflicting transitions at the same state hierarchy level

- In Rhapsody, in case of conflicting transitions, transitions are taken in order of drawing

04 February 2014


17

state_0

state_1[x > 0]

state_2

[y > 0]

state_0

state_1[x > 0]

state_2

[y > 0]

x = 1, y = 1

Modelica 3.3: Handling Conflicting Transitions

- In Modelica state machines every outgoing transition from one state

has a priority which is evaluated in case of conflict to determine

which of the outgoing transitions should be taken

04 February 2014


18

Transition priority

UML2 (Rhapsody): Handling Conflicting Transitions at Different State

Hierarchy Level

• UML2 does specify how to resolve conflicting transitions at different state hierarchy levels:

• Priority schema: Lower-level transitions have higher priority than higher-level transitions

04 February 2014


19

state_0

state_2 state_3ev1 state_1

ev1

state_0

state_2 state_3ev1 state_1

ev1

Modelica 3.3: Handling Conflicting Transitions at Different State

Hierarchy Level

• Modelica priority schema is different to UML2:

• Priority schema: Higher-level transitions have higher priority than lower-level transitions

04 February 2014


20

Modelica In-State Actions

04 February 2014


21

Modelica 3.3: In-state Actions (Equations)

- In Modelica in-state actions are executed at each clock tick if the state is active

- Not supported in UML2 (except workarounds, e.g., self transitions with timeouts)

04 February 2014


22

UML2 Compound Transitions

04 February 2014


23

February 4, 2014


24

UML2 Compound Transitions (Not supported in Modelica 3.3)

UML (IBM Rhapsody)

printingLayout1

printingLayout2

inQueue

waitToPrint

evAbort

evAbort

[qEnabled == true][else]

[qEmpty == true][qEmpty == true]

[qEmpty == true]

initializePrinting

[else]

evReady

[selectedLayout == 1] [else]

waitForJob

evNewPrint

evFinished

evFinished

Modelica (Dymola) Pseudo state

“condition”

UML2 Inter-Level Transitions

04 February 2014


25

February 5, 2014


26

UML2 Inter-Level Transitions (Not supported in Modelica 3.3)

off

on

operating

position_modes

stow_mode

fixed_forward_mode

evFixed_forward_cmd

rate_modes

manual_rate_mode

evManual_rate_cmd

auto_rate_mode

evAuto_rate_cmdevManual_rate_cmd

evStow_cmd

standby

evFixed_forward_cmd

evStandby_cmd

maintenance

interactive_BITE

evIBITE_cmd

evIBITE_finished

calibrationevCalibration_cmd

evCalibration_finished

evTurn_on

evTurn_off

Electro-optical/infrared sensor on TALARION UAV.

Conclusion

- UML2 state machine reactive behavior may lead to deadlocks (infinite looping)

- No issue in Modelica clocked state machine

- In Modelica clocked state machines events between clock ticks are not sensed

- No issue in UML2 state machine because it reacts to every received event

- UML2 queuing of events may lead to unpredictable behavior of the state machine

- No issue in Modelica - events are processed as they appear

- UML2 does not provide any means to resolve state-outgoing transition conflicts

- In Modelica explicit transition priorities are used to resolve transition conflicts

- Modelica in-state actions are executed at each clock tick if the state is active

- Not supported in UML2 (except with workarounds, e.g., self transitions)

- UML2 compound transitions provide better readability of complex guards

- Not supported in Modelica

- UML2 inter-level transitions make state machine diagrams concise

- Not supported in Modelica

04 February 2014


27

Thank you for your attention!

[email protected]

[email protected]

04 February 2014 28

mailto:[email protected]

mailto:[email protected]

comparison of state machines in uml2 and modelica 3 · comparison of state machines in uml2 and...

Documents