Extended finite-state machines (EFSMs)...Extended ﬁnite state machines: Formal speciﬁcation An...

Extended finite-state machines (EFSMs)

Dr. C. Constantinides

Department of Computer Science and Software EngineeringConcordia University Montreal, Canada

January 10, 2017

1 / 92

Extended finite state machines: Formal specification

An extended finite state machine (EFSM) is defined as follows:

(Q,Σ1,Σ2, q0,V ,Λ)

where

1. Q is a finite, non-empty set of states. A state can be atomic (or simple)or composite (see later).

2. Σ1 is a finite, non-empty set of events.

3. Σ2 is a finite set of actions.

4. q0 ∈ Q is the initial state (or start state). Further, every compositestate has its own initial state.

5. V is the set of state variables. Every state variable v ∈ V is a globalvariable and can be accessed at every state q ∈ Q.

6. Λ is a finite set of transitions.

2 / 92

Extended finite state machines: Formal specification /cont.

◮ A transition λ ∈ Λ is qe [g] / a−−−−−→ q′,

whereq, q′ ∈ Q,e ∈ Σ1,g is a condition called a guard, anda ∈ Σ2 is an action.

◮ A variable affected in the transition is denoted as x ′ in state q′.

◮ A transition is a relationship between two states: It indicates that whenan event occurs (perhaps under a transition guard), the entity changesfrom the prior (source) state to the subsequent (target) state.

◮ Additionally, upon a state transition an action (also: activity, or effect)may execute. All parts of a transition label are optional.

3 / 92

Extended finite state machines: State diagrams

◮ An EFSM can be illustrated by a directed graph, where the nodesrepresent the states and where the edges represent the transitions.

◮ The underlying behavior is modeled as a traversal of this graph.

◮ In software development, an EFSM can be deployed to model an objectat a high level of abstraction such as the entire system, or a use case, orat a low level of abstraction, such as a software object.

4 / 92

States, events and transitions

◮ The simplest EFSM is one that contains only states, events andtransitions.

5 / 92

Example: Gate - Description

◮ Consider a gate at the entrance of some facility which can be eitheropen or closed.

◮ Upon a car approaching the gate, a sensor would produce a signal, liftgate, to command the gate to open.

◮ Upon leaving the gate, another sensor would produce a signal, lowergate, to command the gate to close.

6 / 92

Example: Gate - Formal specification

◮ We can model this system with the tuple S = (Q,Σ1,Σ2, q0,V ,Λ),whereQ = {open, closed}Σ1 = {lift gate, lower gate}Σ2 = {}q0 : closedV = {}Λ: Transition specifications1. → closed2. closed

lift gate−−−−−→ open

3. openlower gate−−−−−−−→ closed

◮ Note that empty sets such as Σ2 and V can be omitted.

7 / 92

Example: Gate - State diagram

closed open

lower gate

lift gate

gate

8 / 92

Example: Gate - State diagram /cont.

◮ Note that in this simple example, Σ2 and V are both empty sets.

◮ In the future, empty sets will be omitted from the specification.

◮ The EFSM of the gate system is modeled as a state diagram wherestates are represented as rectangles with rounded corners.

◮ The little black circle represents a pseudostate that automatically causesa transition to the initial state closed.

9 / 92

Event types

◮ There are four types of events that can trigger a transition:

◮ Call event: An external request to invoke an operation.

◮ Change event: A transition is triggered when its value becomes true.

◮ Signal event: Is triggered by an internal or external clock. A time eventmakes use of the keyword at.

◮ Time event: When the source state has been active over the specifiedlength of time, the guard (if present) is evaluated and a transition occursif the guard is true. If no guard is present, then a transition occurs. Atime event makes use of the keyword after.

10 / 92

Orthogonal states

◮ A state can include independent (or parallel) regions.

◮ Such a state is called orthogonal.

11 / 92

Example: Heater system - Top-level state diagram

off on

heater

12 / 92

Example: Heater system - State diagram of orthogonalstate on

on

low high

warm hot

13 / 92

Orthogonal states /cont.

◮ The state can be present in a number of substates, e.g. low, warm, orlow, hot, etc.

14 / 92

Introducing guards

◮ Guards provide conditions under which transitions can take place.

◮ Guards are evaluated by the system.

15 / 92

Introducing actions

◮ Transitions can be associated with actions.

◮ Such actions can be denoted by a slash after the event, or within arectangle.

◮ Actions are performed by the system.

16 / 92

Example: Bounded buffer - Description

◮ Consider a bounded buffer of capacity greater than one.

◮ The buffer has three states: it can be empty, it can be partially full, or itcan be full.

◮ One may place an item in the buffer provided it is not full.

◮ One may also retrieve an item from the buffer provided it is not empty.

◮ We will use the events put and get to correspond to their respectiveoperations.

17 / 92

Example: Bounded buffer - Formal specification

◮ The EFSM is the tuple S = (Q,Σ1,Σ2, q0,V ,Λ), whereQ = {empty , partial , full}Σ1 = {put, get}Σ2 = {size ++, size −−}q0 : emptyV : size : N0; capacity : N is a constant.Λ: Transition specifications1. → empty

2. emptyput / size++−−−−−−−−→ partial

3. partialput [size < capacity - 1] / size++−−−−−−−−−−−−−−−−−−−−→ partial

4. partialput [size = capacity - 1] / size++−−−−−−−−−−−−−−−−−−−−→ full

5. partialget [size > 1] / size–−−−−−−−−−−−−−→ partial

6. partialget [size = 1] / size–−−−−−−−−−−−−−→ empty

7. fullget / size–−−−−−−−→ partial

18 / 92

Example: Bounded buffer - State diagram

empty

partial

put / size++

full

put [size = capacity 1] / size++ get / size--

get [size = 1] / size--

put [size < capacity 1] / size++ get [size > 1] / size--

bounded buffer

19 / 92

Example: Metro passageway - Description

◮ Consider a metro passageway.

◮ The passageway has only two states: It can be locked, or it can beunlocked.

◮ When the passageway is locked, a person can enter a (valid) ticket.

◮ This will cause the passageway to perform a transition to the unlockedstate while at the same time performing two actions: 1) it will unlock thegate and 2) it will beep to indicate that the person may pass through.

◮ Once a person passes through the gate, a sensor or some physical devicewill cause the passageway to perform a transition back to the lockedstate while at the same time performing a lock action.

◮ We will use the events request entry and pass to correspond to theirrespective operations.

20 / 92

Example: Metro passageway - Formal specification

◮ The EFSM of the metro passageway is the tupleS = (Q,Σ1,Σ2, q0,V ,Λ), whereQ = {locked , unlocked}Σ1 = {request entry , pass}Σ2 = {lock , unlock , beep}q0 : lockedV : ticket = {valid , invalid}Λ: Transition specifications1. → locked

2. lockedrequest entry [ticket is valid] / (unlock ; beep)−−−−−−−−−−−−−−−−−−−−−−−−−−−→ unlocked

3. unlockedpass / lock−−−−−−−→ locked

21 / 92

Example: Metro passageway - State diagram

◮ Recall that a transition λ ∈ Λ is

qe [g] / a−−−−−→ q′

where q, q′ ∈ Q, e ∈ Σ1, g is a condition called a guard and a ∈ Σ2 isan action.

◮ If the label on a transition is e/a, then g is assumed to be true and thetransition occurs whenever e occurs.

◮ If the label on a transition is [g ]/a, then the transition occurs wheneverg holds at the source state q.

◮ If the label of a transition is e, then the transition occurs whenever anevent e occurs at the source state q.

22 / 92

Example: Metro passageway - State diagram /cont.

locked unlocked

pass / lock

request entry [ticket is valid] / (unlock ; beep)

metro passageway

23 / 92

Hierarchically nested states

◮ Modern (UML-based) EFSMs have introduced the notion ofhierarchically nested states.

◮ This means that a state can itself be modeled as an EFSM and containits own states called substates (or nested states).

◮ States that contain other states are called composite states (as opposedto simple states).

◮ We can thus refer to the relation of a superstate and substate.

◮ A substate is called direct substate (as opposed to transitively nestedsubstate) when it is not contained by any other state.

◮ Substates inherit the transitions of their superstate.

◮ If a system is in a substate, it is also (implicitly) in the superstate.

24 / 92

Example: Safe - Description

◮ Consider a (simple) safe. The safe can be open or closed.

◮ While being closed, the safe can be unlocked, or it can be locked.

◮ When the safe is unlocked and provided the door is closed, a person mayenter a valid code causing the safe to lock.

◮ Upon locking, the safe produces a beep sound.

◮ When the safe is locked, a person may enter a valid code, causing thesafe to unlock.

25 / 92

Example: Safe - Formal specification

◮ We can model this safe with the the tuple S = (Q,Σ1, q0,V ,Λ), whereQ = {open, closed}Σ1 = {open door , close door}q0 : openV : door = {locked , unlocked}Λ: Transition specifications1. → open

2. openclose door−−−−−−−→ closed

3. closedopen door [unlocked]−−−−−−−−−−−−−→ open

26 / 92

Example: Safe - Formal specification /cont.

◮ As closed is a composite state, it is defined as the tupleS = (Q,Σ1,Σ2, q0,V ,Λ), whereQ = {locked , unlocked}Σ1 = {lock , unlock}Σ2 = {lock , unlock , beep}q0 : unlockedV : code = {valid , invalid}Λ: Transition specifications1. → unlocked

2. unlockedlock [code is valid] / (lock ; beep)−−−−−−−−−−−−−−−−−−−−−→ locked

3. lockedunlock [code is valid] / unlock−−−−−−−−−−−−−−−−−−→ unlocked

27 / 92

Example: Safe - State diagram

locked

lock [code is valid] / (lock; beep)

unlock [code is valid] / unlock

open

close door

open door [unlocked]

safe closed

unlocked

28 / 92

Example: Safe - State diagram /cont.

◮ We note that as state closed is itself modeled as an EFSM, it containsits own states (including its own starting state).

◮ States unlocked and locked are direct substates of closed.

29 / 92

Example: Alarm - Description

◮ Consider an alarm system that detects movement or smoke.

◮ The system has only two states: It can be idle, or it can be active.

◮ While idle, a person can activate it by entering a valid code.

◮ This will cause the alarm system to perform a transition to the activestate while at the same time execute two actions: 1) activation, and 2) abeep to indicate activation.

30 / 92

Example: Alarm - Description /cont.

◮ Within the active state, the system can be modeled by two substates: itcan be monitoring, or it can be on.

◮ While monitoring, if the system’s sensors indicate a movement or smoke,the system will perform a transition to the on state, while at the sametime performing two actions: 1) turning on and 2) generating a sound.

31 / 92

Example: Alarm - Formal specification

◮ The EFSM is the tuple S = (Q,Σ1,Σ2, q0,V ,Λ), whereQ = {idle, active}Σ1 = {enable, disable}Σ2 = {activate, deactivate, beep}q0 : idleV : code = {valid , invalid}Λ: Transition specifications1. → idle

2. idleenable [code is valid] / (activate ; beep)−−−−−−−−−−−−−−−−−−−−−−−−→ active

3. activedisable [code is valid] / (deactivate ; beep)−−−−−−−−−−−−−−−−−−−−−−−−−→ idle

32 / 92

Example: Alarm - Formal specification /cont.

◮ As active is a composite state, it is defined as the tupleS = (Q,Σ1,Σ2, q0,V ,Λ), whereQ = {monitoring , on}Σ1 = {movement, smoke}Σ2 = {turn on,make sound}q0 : monitoringΛ: Transition specifications1. → monitoring

2. monitoring(movement or smoke) / (turn on ; make sound)−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ on

33 / 92

Example: Alarm - State diagram

idle

enable [code is valid] / (activate ; beep)

disable [code is valid] / (deactivate ; beep)

monitoring

on

active

(movement or smoke) / ( turn on ; make sound)

alarm

34 / 92

Example: Alarm - State diagram /cont.

◮ Note that while at either monitoring or on states, if the alarm isdisabled, it will go to the idle state, as substates inherit the transitionsof its superstate active.

◮ Inheritance of transitions simplifies both the EFSM as well as the statediagram: Without modeling active as a composite state, we would haveto include a transition from monitoring to idle, and from on and idle.

35 / 92

Example: Home garage - Description

◮ Consider a system that controls the door to a home garage which canhold one vehicle: The system can be in states idle, opening or closing.

◮ Initially the system is at idle state.

◮ If a vehicle arrives and provided the code sent from the vehicle’s remotecontrol is valid, then the system performs a transition to the openingstate and switches on an outside light.

36 / 92

Example: Home garage - Description /cont.

◮ State opening is a compound state and its initial state is ascending.

◮ After 10 seconds the system performs a transition to state open.

◮ Having reached state open marks the completion of the execution of allactivities inside this compound state and the system would now performa transition to state closing after 20 seconds.

37 / 92

Example: Home garage - Description /cont.

◮ Within state closing, the system starts at state descending and it wouldperform a transition to state closed after 10 seconds and switch on aninside light.

◮ From here, the system would move to state idle after 30 seconds.However, if while at closing state the system detects a movement(perhaps a child has approached the descending gate), then the systemhalts the closing door, produces an alarming sound and performs atransition to state opening.

38 / 92

Example: Home garage - Formal specification

◮ The EFSM is the tuple S = (Q,Σ1,Σ2, q0,V ,Λ), whereQ = {idle, opening , closing}Σ1 = {vehicle arrives,movement, after(20s), after(30s)}Σ2 = {switch on outside light, halt door ,make sound}q0 : idleV : code = {valid , invalid}Λ: Transition specifications1. → idle

2. idlevehicle arrives [code is valid] / switch on outside light−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ opening

3. openingafter(20s)−−−−−−→ closing

4. closingmovement / (halt door ; make sound)−−−−−−−−−−−−−−−−−−−−−−−→ opening

5. closingafter(30s)−−−−−−→ idle

39 / 92

Example: Home garage - Formal specification /cont.

◮ The EFSM of the opening state is the tuple S = (Q,Σ1, q0,Λ), whereQ = {ascending , open}Σ1 = {after(10s)}q0 : ascendingΛ: Transition specifications1. → ascending

2. ascendingafter(10s)−−−−−−→ open

40 / 92

Example: Home garage - Formal specification /cont.

◮ The EFSM of the closing state is the tuple S = (Q,Σ1,Σ2, q0,Λ), whereQ = {descending , closed}Σ1 = {after(10s)}Σ2 = {switch on inside light}q0 : descendingΛ: Transition specifications1. → descending

2. descendingafter(10s) / switch on inside light−−−−−−−−−−−−−−−−−−−−→ closed

41 / 92

Example: Home garage - State diagram

idle

descending

closed

after (10 s) /

switch on inside light

movement /

halt door; make sound

vehicle arrives [code is valid] /

switch on outside light

opening closing

ascending

open

after (20 s)

after (10 s)

garage door

after (30 s)

42 / 92

Example: Road-rail intersection - Description

◮ Consider a system that controls the intersection between a road and arail track.

◮ A gate that cuts off the road can be open or closed. Initially the gate isin open state while initially there is a constant green light unless apedestrian who wishes to cross the street presses some button in whichcase the system will go through a yellow, red and red yellow lights with atime period of 5 seconds between yellow and red and 20 secondsbetween red and red yellow.

◮ The system goes from red yellow back to green in 5 seconds.

◮ When it lights red, the system turns on a Walk light signal and when itlights red yellow, the system turns on a Do Not Walk light signal.

43 / 92

Example: Road-rail intersection - Description /cont.

◮ When a train arrives, the system performs a transition to a closed statewhile making a sound, turning on a red light, flashing some warninglights and descending the gate.

◮ When a train has passed by, the system performs a transition back toopen and ascends the gate.

44 / 92

Example: Road-rail intersection - Formal specification

◮ The EFSM is the tuple S = (Q,Σ1,Σ2, q0,Λ), whereQ = {open, closed}Σ1 = {train arrives, train passes by}Σ2 ={make sound , turn on red , flash warning lights, descend gate, ascend gate}q0 : openΛ: Transition specifications1. → open

2. opentrain arrives / (make sound ; turn on red; flash warning lights ; descent gate)−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→

closed

3. closedtrain passes by / ascend gate−−−−−−−−−−−−−−−−−→ open

45 / 92

Example: Road-rail intersection - Formal specification/cont.

◮ As open is a composite state, it is defined as the tupleS = (Q,Σ1,Σ2, q0,Λ), whereQ = {green, yellow , red , red yellow}Σ1 = {button pressed , after(5s), after(20s)}Σ2 = {turn on Walk , turn on Do Not Walk}q0 : greenΛ: Transition specifications1. → green

2. greenbutton pressed−−−−−−−−−→ yellow

3. yellowafter(5s) / turn on Walk−−−−−−−−−−−−−−−→ red

4. redafter(20s) / turn on Do Not Walk−−−−−−−−−−−−−−−−−−−−→ red yellow

5. red yellowafter(5s)−−−−−−→ green

46 / 92

Example: Road-rail intersection - State diagram

closed

green

red

open

train passes by / ascend gate

after (5s) /

turn on Walk

button pressed

yellow red yellow

after (20s) / turn on Do Not Walk

train arrives / make sound;

turn on red;

flash warning lights;

descend gate

intersection

after (5s)

47 / 92

A fax machine: Top-level state diagram

��

��

��

��

��

48 / 92

A fax machine: State diagram of active state

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

��

��

��

��

��

��

49 / 92

Pseudostates

◮ A pseudostate is used to combine and direct transitions.

◮ Initial: It marks the starting point of a region that leads to the region’sdefault state. When more than one transition originates from the initialstate, the starting state is determined by the evaluation of the guardcondition of each transition.

◮ Join: Receives two or more incoming transitions that meet to form oneoutgoing transition. Each incoming transition to the join pseudostatemust originate from a different region of an orthogonal state.

◮ Fork: Receives one incoming transition that splits into two or moreoutgoing transitions. Each outgoing transition from the fork pseudostatemust target a state in a different region of an orthogonal state.

50 / 92

Pseudostates /cont.

◮ Junction: Used to chain together multiple transitions. A single junctioncan have one or more incoming, and one or more outgoing transitions.

◮ Choice: Receives a single incoming transition and outputs twotransitions each with a guard condition, one of which is true.

◮ Terminate: Identifies the end of the execution of a state machine.

◮ Additionaly, a special state called the final state indicates that theenclosing region is completed. Note that the final state is not considereda pseudostate.

51 / 92

Example: Vehicle passageway - Description

◮ In this example we illustrate nested states, event types, and pseudostates.

◮ Consider a vehicle passageway where an automatic light system has todetect passing vehicles and turn itself on to guide them through.

◮ The system can be in idle state and would automatically activate at18:00, thus performnig a transition to active state.

◮ The system automatically turns idle at 06:00.

52 / 92

Example: Vehicle passageway - Description /cont.

◮ Within the active state, if it detects a vehicle arriving, it will deploy asensor to calculate the number of vehicles.

◮ If it is three or less the system will turn on the light for a short period oftime (10 s), thus performing a transition to the light short state.

◮ In the other case, i.e. there are more than three vehicles, the system willturn on the lights for a longer period of time (30s), thus performing atransition to the light long state.

◮ While idle, the system can be shut off with the event disable.

53 / 92

Example: Vehicle passageway - Formal specification

◮ The EFSM is the tuple S = (Q,Σ1, q0,Λ), whereQ = {idle, exit, active}Σ1 = {at(06 : 00), at(18 : 00), disable}q0 : idleΛ: Transition specifications1. → idle

2. idleat(18:00)−−−−−−→ active

3. activeat(06:00)−−−−−−→ idle

4. idledisable−−−−→ exit

54 / 92

Example: Vehicle passageway - Top-level state diagram

idle active

at 18:00

at 06:00

disable

vehicle passageway

55 / 92

Example: Vehicle passageway - Formal specification /cont.

◮ As active is a composite state, it is defined as the tupleS = (Q,Σ1,Σ2, q0,V ,Λ), whereQ = {off , light short, light long}Σ1 = {vehicle arrives, after(10s), after(30s)}Σ2 = {turn lights on, turn lights off }q0 : offV : numOfVehicles : NΛ: Transition specifications

1. offvehicle arrives [numOfVehicles <= 3] / turn lights on−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ light short

2. offvehicle arrives [numOfVehicles > 3] / turn lights on−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ light long

3. light shortafter(10s) / turn lights off−−−−−−−−−−−−−−−−→ off

4. light longafter(30s) / turn lights off−−−−−−−−−−−−−−−−→ off

56 / 92

Example: Vehicle passageway - State diagram of activestate

off

light short

active

light long

c := numOfVehicles

[c > 3] / turn lights on

[c <= 3] / turn lights on

vehicle arrives

after (10s)

after (30s)

/ turn lights off

57 / 92

Example: Vehicle passageway - State diagram /cont.

◮ We mentioned earlier that substates inherit the transitions of theirsuperstate.

◮ In this example, off, light long and light short are all substates of activeand inherit its transitions.

◮ For example, while traversing through the states off, light long and lightshort, once event at(06:00) occurs, the system performs a transition toidle.

58 / 92

Example: Temperature control - Description

◮ Consider a temperature control system that can be in states idle or on.

◮ Initially the system is idle. After 20 minutes the system checks the roomtemperature and if it is 18 degrees or above it goes back to being idle,only to repeat this cycle again after 20 minutes.

◮ If the temperature falls below 18 degrees, the system becomes on(subsequently performing certain functions, see next) and it will repeatthis cycle of checking the room temperature every 20 minutes.

59 / 92

Example: Temperature control - Description /cont.

◮ The physical part of the system is made up of a water tank thatdistributes hot water through a network of pipes inside a room.

◮ While on, the system goes initially to a warming up state whereby itstarts heating the water inside the tank.

◮ Once the temperature of the water reaches 50 degrees then the systemmoves to a stable state and starts releasing water to the pipe network.

◮ After 15 minutes the system will check the temparature of the water. Ifit is 40 degrees or above it will go back to stable state, otherwise it willgo to warmingUp state.

60 / 92

Example: Temperature control - Description /cont.

◮ While on, the system can receive event disable, in which case it canimmediately go to idle state.

◮ The system can only be shut off while in idle state by receiving a shutoff event.

61 / 92

Example: Temperature control - Formal specification

◮ The EFSM is the tuple S = (Q,Σ1, q0,V ,Λ), whereQ = {on, idle, exit}Σ1 = {after(20min), disable, shut off }q0 : idleV : roomTemperature: R.Λ: Transition specifications1. → idle

2. idle[roomTemperature ≥ 18] after(20 min)−−−−−−−−−−−−−−−−−−−−−−−→ idle

3. idle[roomTemperature < 18] after(20 min)−−−−−−−−−−−−−−−−−−−−−−−→ on

4. idleshut off−−−−−→ exit

5. on[roomTemperature ≥ 18] after(20 min)−−−−−−−−−−−−−−−−−−−−−−−→ idle

6. on[roomTemperature < 18] after(20 min)−−−−−−−−−−−−−−−−−−−−−−−→ on

7. ondisable−−−−→ idle

62 / 92

Example: Temperature control - Top-level state diagram

idle

on

rt :=

roomTemperature

after (20 min) [rt 18]

[rt < 18]

disable

shut off

after (20 min)

temperature monitoring

63 / 92

Example: Temperature control - Formal specification/cont.

◮ As on is a composite state, it is defined as the tupleS = (Q,Σ1,Σ2, q0,V ,Λ), whereQ = {warming up, stable}Σ1 = {after(15min)}Σ2 = {release water}q0 : warming upV : waterTemperature: R.Λ: Transition specifications1. → warming up

2. warming up[waterTemperature < 50]−−−−−−−−−−−−−−−→ warming up

3. warming up[waterTemperature ≥ 50] / release water−−−−−−−−−−−−−−−−−−−−−−−−→ stable

4. stable[waterTemperature ≥ 40] after(15 m)−−−−−−−−−−−−−−−−−−−−−−−→ stable

5. stable[waterTemperature < 40] after(15 m)−−−−−−−−−−−−−−−−−−−−−−→ warming up

64 / 92

Example: Temperature control - State diagram of on state

stable

on

warming up wt := waterTemperature

[wt 40] [wt < 40]

wt :=

waterTemperature

[wt 50] / release water

after (15 min)

[wt < 50]

65 / 92

Example: Airconditioning system - Description

◮ The system under discussion is one that provides air conditioning to aroom.

◮ The system can be in an idle state, in a monitoring state, or in an activestate.

◮ Additionally, while idle the system can receive a message to shut off inwhich case it completely shuts off. We assume that a desiredtemperature has been set by the user.

◮ While idle, the system will read the current room temperature at 20:00and it will either remain idle if the reading is at the desired temperature,or become active if the current room temperature differs from thedesired temperature.

◮ As it becomes active the system will beep as well as it will set on anindicator light.

◮ While active, the system is disabled either by receiving an appropriatemessage or automatically at 08:00 thus becoming idle; at the same timeit sets off the indicator light.

66 / 92

Example: Airconditioning system - Description

◮ While active the system starts from a state we will call coordinatingwhich acts as the initial state and transitions the system to an increasingor to a decreasing temperature state based on the current roomtemperature.

◮ While at either increasing or decreasing state, the system will eventuallymove to a stable state once the temperature reaches the desired level.

◮ While stable, the system will read the room temperature every 20minutes and again moving to the coordinating state in order to decidewhether to move to increasing, to decreasing, or back to stable.

67 / 92

Example: Airconditioning system - Formal specification/cont.

◮ The EFSM of the overall system is the tuple S = (Q,Σ1,Σ2, q0,V ,Λ),whereQ = {idle,monitoring , active, exit}Σ1 = {at(20 : 00), at(08 : 00), after(20 min), disable, shut off }Σ2 = {beep, set indicator light on, set indicator light off }q0 : idleV : currentTemperature, desiredTemperature : R.

68 / 92


Λ: Transition specifications1. → idle

2. idleat(20:00) [currentTemperature 6= desiredTemperature] / (beep ; set indicator light on)−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→

active

3. idleafter(20 min) [currentTemperature = desiredTemperature]−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ monitoring

4. monitoringafter(20 min) [currentTemperature 6= desiredTemperature] / (beep ; set indicator light on)−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ active

69 / 92


5. monitoringafter(20 min) [currentTemperature = desiredTemperature]−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ monitoring

6. monitoringat(08:00) or disable−−−−−−−−−−−−→ idle

7. idleshut off−−−−−→ exit

8. activeat(08:00) or disable / set indicator light off−−−−−−−−−−−−−−−−−−−−−−−−−−→ idle

70 / 92

Example: Airconditioning system - Top-level state diagram

idle

active ct := currentTemperature

at (20:00)

[ct desiredTemperature] / beep; set indicator light on

at (08:00) or disable / set indicator light off

shut off

air conditioning

monitoring

after (20 minutes)

[ct = desiredTemperature]

at (08:00) or disable

71 / 92


◮ The EFSM of the active state is the tuple S = (Q,Σ1, q0,Λ), whereQ = {coordinating , increasing , decreasing , stable}Σ1 = {after(20min)}q0 : coordinatingΛ: Transition specifications1. → coordinating

2. coordinating[currentTemperature = desiredTemperature]−−−−−−−−−−−−−−−−−−−−−−−−−−−→ stable

3. coordinating[currentTemperature < desiredTemperature]−−−−−−−−−−−−−−−−−−−−−−−−−−−→ increasing

4. coordinating[currentTemperature > desiredTemperature]−−−−−−−−−−−−−−−−−−−−−−−−−−−→ decreasing

5. increasing[currentTemperature = desiredTemperature]−−−−−−−−−−−−−−−−−−−−−−−−−−−→ stable

6. decreasing[currentTemperature = desiredTemperature]−−−−−−−−−−−−−−−−−−−−−−−−−−−→ stable

7. stableafter(20min)−−−−−−−−→ coordinating

72 / 92

Example: Airconditioning system - State diagram of activestate

decreasing

active

increasing

[ct > desiredTemperature] [ct < desiredTemperature]

after (20 min)

stable


coordinating

ct := currentTemperature

73 / 92

Deep and shallow history pseudostates

◮ Shallow history causes the last active substate of a region to be stored.

◮ When traversing into the region, the last active substate will beautomatically activated as if it were the initial state.

◮ On the other hand, a deep history would maintain a memory of innerregions of the substate.

74 / 92

Heater system with deep history

◮ In this example, we are extending the heater system to maintain a deephistory.

◮ If we left the system at high, warm, then the next time the system isactivated it will immediately jump to this pair of states.

75 / 92

Heater system with deep history

on

low high

warm hot

H*

76 / 92

Temporal logic specifications and EFSMs: A traffic lightsystem

◮ We will deploy temporal logic specifications to extended finite statemachines and their state diagram counterparts to express certaintemporal properties of the system.

green yellow

red red-yellow

traffic light system

after(30s)

after(3s)

after(30s)

after(2s)

◮ It is always the case that when the light is green implies that theimmediately next light is yellow.�(green → © yellow).

77 / 92

Temporal logic specifications and EFSMs: A traffic lightsystem /cont.

◮ It is always the case that when the light is green implies that eventuallythe light will again become green.�(green → ♦ green).

green yellow

red red-yellow

traffic light system

after(30s)

after(3s)

after(30s)

after(2s)

78 / 92

Temporal logic specifications and EFSMs: A vehiclepassageway system◮ We use some simplifications on terminology, e.g. unless explicitly stated

in the specification, we will use light to denote either of the two states.

idle active

at 18:00

at 06:00

disable

vehicle passageway

79 / 92

Temporal logic specifications and EFSMs: A vehiclepassageway system /cont.

off

light short

active

light long

c := numOfVehicles

[c > 3] / turn lights on

[c <= 3] / turn lights on

vehicle arrives

after (10s)

after (30s)

/ turn lights off

80 / 92


◮ It is always the case that the system eventually becomes active unless itis disabled.�(idle → ♦ active) W disabled .

◮ It is always the case that when a vehicle arrives, a light will turn on inthe next moment in time.�(vehicle arrives → © light).

◮ It is always the case that a long light remains on until 30 seconds elapse.�(light long U time elapsed).

81 / 92


◮ It is always the case that a light eventually is switched off.�(light → ♦ off ).

◮ It is always the case that between the hours 06:00 and 18:00 (notinclusive), if a vehicle arrives no light will be turned on in the nextmoment in time.�((06 : 00 < time < 18 : 00) ∧ vehicle arrives) → ¬© light).

82 / 92

Example: Airconditioning system - Top-level state diagram

idle

active ct := currentTemperature

at (20:00)

[ct desiredTemperature] / beep; set indicator light on

at (08:00) or disable / set indicator light off

shut off

air conditioning

monitoring

after (20 minutes)


at (08:00) or disable

83 / 92

Example: Airconditioning system - State diagram of activestate

decreasing

active

increasing

[ct > desiredTemperature] [ct < desiredTemperature]

after (20 min)

stable


coordinating

ct := currentTemperature

84 / 92

Temporal logic specifications and EFSMs: Anairconditioning system

◮ The system can never be in state idle between 20:00 and 08:00.� ((20:00 < time < 08:00) → ¬ idle)

◮ It is always the case that when the system is in state coordinatingimplies that eventually the system will be at state idle.� (coordinating → ♦ idle)

85 / 92


◮ It is always the case that when the system is in state monitoring and thetemperature is not at the desired level, it implies that the immediatelynext state is at active unless the system goes back to state idle.� ((monitoring ∧ room temperature 6= desired temperature) → ©(active W idle))

86 / 92


◮ It is always the case that when the system is in state idle implies that iteventually goes to state monitoring or active, unless it is shut off.� (idle → ♦ ((monitoring ∨ active) W shut off)))

◮ It is always the case that when the system is in state idle implies thatthe immediately next state will be monitoring, or active, or exit.� (idle → © (monitoring ⊕ active ⊕ exit))

87 / 92

Temporal logic specifications and EFSMs: Anairconditioning system /cont.

◮ It is always the case that the system is in state active until 08:00 or itremains active until it is disabled.(active) U (time becomes 08:00 ⊕ system disabled)

◮ The system has remained active since the indicator light has been on.(active) S (indicator light on)

88 / 92


◮ The system is in state active until it goes to state idle.active U idle

◮ The system is expected to be in state idle infinitely often.�♦ idle

89 / 92


◮ � (¬idle ∧ (time < 20:00) ∧ (time > 08:00))

◮ ”It is always the case that the state is not idle as well as the time isbetween 08:00 and 20:00.”

◮ Is this true?

90 / 92


◮ ¬� (idle between 20:00 and 08:00)

◮ ”It is not the case that the formula is always true.”

◮ This can imply that it can sometimes be false.

91 / 92


◮ (20:00 < time < 08:00) → � (¬ idle)

◮ ”When the time is between 20:00 and 08:00 the system will become(and subsequently remain) non-idle.”

92 / 92

Extended finite-state machines (EFSMs)...Extended ﬁnite state machines: Formal speciﬁcation An...

Documents

Transcript of Extended finite-state machines (EFSMs)...Extended ﬁnite state machines: Formal speciﬁcation An...