0% found this document useful (0 votes)
61 views49 pages

Modeling Event-Based Behavior With State Machines: Critical Embedded Systems

Modelling

Uploaded by

lucas john
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
61 views49 pages

Modeling Event-Based Behavior With State Machines: Critical Embedded Systems

Modelling

Uploaded by

lucas john
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 49

Modeling Event-Based Behavior with

State Machines

Critical Embedded Systems


Dr. Ákos Horváth and Dr. Balázs Polgár
Prepared by
Budapest University of Technology and Economics
Faculty of Electrical Engineering and Informatics
Dept. of Measurement and Information Systems
© All rights reserved.

This material can only used by participants of the course.

Budapest University of Technology and Economics


Department of Measurement and Information Systems
System Modeling Process

2
What is it about?

Context of the Modeling Aspect


State Machine Diagram

4
Modeling Aspect
What are the states of the selected component?
How it reacts to events (how it changes states)?

5
What are the building blocks?

Modeling Elements & Notation


Atoms of dynamic modeling
 Event:
o Asynchronous occurrence/happening with parameters
e.g. mouse click and its place and which button
o Full-fledged object, instance of the Event class
inheritance: extension of its attributes
o Life-cycle:
• Initialization, notification of target objects
• Event-queues and selection
• Processing
o Reactive objects: react to events

7
Atoms of dynamic modeling II.
 Operation:
o Services provided by the classes (methods)
• client-server relation
• can have return values
o Part of the class definition
o Synchronous or asynchronous communication between
objects
• e.g., method invocation
result = server->operation(p1, p2, ..., pn)
 Signal reception
o Asynchronous communication between objects
8
Atoms of dynamic modeling III.
 State:
o The state of an object
o Defined by:
- value of its attributes (e.g., x<3)
- conditions are met (e.g., operation can be executed)
 Transition:
o Change of state
o Triggered either by the incoming event
or completion
 Action:
o The operations to be executed by the object

9
Dynamic Modeling
with State Machines
State Machines
 Describes the states and state transitions of the system, of a
subsystem, or of one specific object.
o hierarchical and concurrent systems
 States
o Concrete state:
• Combination of possible values of attributes
• Can be infinite
o Abstract states: (like in State Machines)
• Predicates over concrete states
• One abstract state  many concrete states
• Hierarchical states:
– Frequent in embedded apps (e.g. control of car brake)
 Transitions
o Triggering Event
o Guard
o Action

11
State Machine - introduction
 For defining reactive behavior of objects
o Responds to events:
state transitions and actions
o Traditional approach: state machine
 UML State Machine: extension to state machine
o State hierarchy: refinement of states
o Concurrent behavior: parallel threads
o Memory: last active state configuration

12
States I.
 Attributes:
o entry action report_job

o do action entry/init()
do/print()
o exit action exit/reset()

 State refinement
o Simple state
o OR refinement: auxiliary state machine,
only one active state
o AND refinement: concurrent regions (state machines),
all regions are active in parallel

13
Example: State refinement I.

On Off

off

on

out

14
Example: State refinement II.

On Off

off
Standby

on

out in

out Disconnected

OR refinement

15
Example: State refinement III.

On Off
Image Sound
off
Standby

on

out in

out Disconnected

AND refinement

16
Example: State refinement IV.

On Off
Image Sound
off
Show Standby
SoundOn
on

snd mute out in

out Disconnected
coor coor
SoundOff
Coordinates

17
Example: State refinement V.

On Off
Image Sound
off
Show Standby
SoundOn
Clock
on
clk clk
snd mute out in
NoClock
out Disconnected
coor coor
SoundOff
Coordinates

18
State II.
 History state
o Stores the last active state configuration
o Input transition: it sets the object to the saved state
configuration
o Output transition: defines the default state, if there were
no active state since
o Deep history state: saves the complete state hierarchy
(down to the lowest substates)
 Initial state: becomes active when entered to the
region
• One in each OR refinement
• One in each AND region
 Final state: state machine terminates
19
Example: History State

Print_job

Process
Handle
it
Print
Get H
Close
Reply

20
Transition I.
 Defining state changes
 Syntax:
trigger [guard] / action
o trigger: event, triggered operation or time-out
o guard: transition condition
• Logic formula over the attributes of the objects and events
• referring to a state: IS_IN(state) macro
• Without trigger: if becomes true the transition is active
o action: operations  action semantics

21
Transition II.
 Time-out trigger:
o becomes active if the object stays in he source state for the
predefined interval
e.g., tm(50), based on system time
 Complex transitions
o Fork

o Join

o Condition

o (Internal)
• executes without exiting or re-entering the state in which it is defined
 Transitions between different hierarchy levels
22
Transition example
Work
State name
Group1

Phase1 Phase2

Prepare Passed

Act1 Act2 Act3


Missed
Group2 tm(50)

[not_fatal] / recovery()
error [fatal] / report_status()

illegal_activity [fatal] / report_status() Failure

23
(Basic) State Machine elements

 State State name

 (Transition) s1 s2

 History state H H*

 Initial State
 Final State
 Conditional transition
 Synchronization(fork/join)

24
How is the model interpreted?

Semantics of the Model


Semantics: How does it work?
 Basics:
o Hierarchical state machine (state chart)
o Event queue + scheduler
 Semantics defines:
Behavior in case an event occurs
 one step of the state chart
o (concurrent) transitions fire
o State configuration changes
in all region in the active state and also one substate in
the OR refinement (recursively)

26
Semantics of State Transitions
 Separately processed events:
o Scheduler only triggers the next event if the previous
one is completely processed
stable configuration: there is no state change without an event

 Complete processing of events:


o The largest set of possible fireable transitions
(all enabled transition fires, if they are not in conflict)

How does it work?: Steps of the event processing

27
Steps of event processing I.
 Scheduler triggers an event for the State Machine
in a stable state configuration
 Enabled transitions:
o Source state is active
o The event is their trigger
o Guards are evaluated to true
Based on the number of fireable transitions
o Only one: fire!
o None: do nothing
o More than one: select transitions to fire?

28
Example: Conflict
All transitions are triggered by the same e event: Which should fire?

a1 a2
a11 a12 t4 a21
a111 a121

t5
t1 t2 t3
a112 a113 a122 a22

Disabled (cannot fire): t5


Cannot fire together : (t1,t2); (t1,t4); (t2,t4); (t3,t4)

29
Steps of event processing II.
 Selection of fireable transitions:
o Fireable = Enabled + Max, priority
o Conflict: Has the same source state
• Formally: the intersection of their left (exit) states is not
empty
Conflict resolution  priority:
• Defined between two transitions (t1 and t2)
• t1 > t2, if and only if the source state of t1 is a substate within
the state hierarchy of t2 („lower level”)

30
Steps of event processing III.
 Selection of transitions to fire:
o Set of transitions to fire: parallel execution of
concurrent transitions:
• Maximum number of fireable transitions
(= cannot be extended any further)
• There is no conflict between any two transitions
o Selection of this set:
• Random!

31
Conflict resolution

a1 a2
a11 a12 t4 a21
a111 a121

t5
t1 t2 t3
a112 a113 a122 a22

Fireable: (t1,t3) or (t2,t3)

32
Steps of event processing IV.
 Selected transitions fire:
in random order
 Firing one transition:
o Leaving the source states from the bottom to top and
execute all their exit operations
o Execute the action of the transition
o Entering the target states from top to bottom and
execute the entry actions  new state configuration

33
Steps of event processing V.
 Entering a new state configuration:
o Simple target state: part of the state configuration
o Non-concurrent superstate: direct target of one of its
substate or its initial state
o Concurrent target state: all of its regions have to have
an active state either as direct target state or with
initial state
o History state : the last active state configuration
if there is none: the target state of the history state

34
State transition example

S11
S1 S111 S112
S1111 S1112 S1113

S12
S121 S122 S123
S1211 S1212 S1231 S1232

35
State transition example

S11
S1 S111 S112
S1111 S1112 S1113

S12 S1211 - exit action


S121 S122 S123
S1211 S1212 S1231 S1232

36
State transition example

S11
S1 S111 S112
S1111 S1112 S1113

S121 - exit action


S12
S121 S122 S123
S1211 S1212 S1231 S1232

37
State transition example

S11
S1 S111 S112
S1111 S1112 S1113

S12 - exit action


S12
S121 S122 S123
S1211 S1212 S1231 S1232

38
State transition example

S11
S1 S111 S112
S1111 S1112 S1113

Transition action
S12
S121 S122 S123
S1211 S1212 S1231 S1232

39
State transition example

S11
S1 S111 S112
S1111 S1112 S1113

S11 – entry action


S12
S121 S122 S123
S1211 S1212 S1231 S1232

40
State transition example

S11
S1 S111 S112
S1111 S1112 S1113

S111 – entry action


S12
S121 S122 S123
S1211 S1212 S1231 S1232

41
State transition example

S11
S1 S111 S112
S1111 S1112 S1113

S1111 - entry action


S12
S121 S122 S123
S1211 S1212 S1231 S1232

42
Summary
 Effective technique to model certain dynamic
systems

 Hierarchic refinement allows iterative


development

 Already used in many application domain


o Avionics, automotive, control, etc.

43
Complex Example
 Traffic light for an intersection with a prioritized
road
o Off: (blinking yellow)
o On: green for the priority road
o Green, yellow, red etc. Different timerange (timer)
o 3 waiting vehicle on priority road: green light despite
the timer’s ticks
o Automatically take photos of vehicles crossing the
priority road on red light. Manual on/off for this
feature.

44
1. Basic state machines

Red
reset T2
Yellow
reset
Off
T1
do/blink reset
Green

T4

!reset Red
Yellow
reset T3
tm(T4)

45
2. Hierarchy
On
Red
reset T2
Yellow
Off
T1
do/blink
Green

T4

Red
Yellow
!reset
T3

46
3. Concurrent states
On
Red
reset T2
Camera Count
Yellow
Off
T1
do/blink
Green

T4

Red
Yellow
!reset T3

47
4. History States
On
Red
reset T2
Camera Count
H
Yellow
CarGo
Off On
T1
do/blink

ManualOn

ManualOff
Green
Shoot
T4

Red
Yellow Off
!reset T3

48
Complete System
On
reset Red
T2
Camera Count
H
Yellow
CarGo Count0
Off On
T1 car
do/blink

ManualOn

ManualOff
Green Count1
Shoot
car
T4
Count2
Red
Yellow Off car
!reset T3

49

You might also like