II. FSM - University of Oulu · FSM (Finite State Machines), EFSM (Extended FSM), CFSM...

521265A Telecommunication Software Ch2 – FSM521265A Telecommunication Software Ch2 – FSM

II. FSM

Dept. Electrical & Information Engineering, Computer Engineering Lab 2-1 Dr. Junzhao SunDept. Electrical & Information Engineering, Computer Engineering Lab 2-1 Dr. Junzhao Sun


Outline

FSM based protocol specification & verificationFSM, FSM minimization, EFSM, CFSMP t l ifi ti d i h bilit l iProtocol verification, design errors, reachability analysis

Protocol synthesis



Outline


Protocol synthesis



Protocol SpecificationInformal methods, such as Message Sequence Chart (MSC)Formal methods

State Transition ModelsState Transition ModelsFSM (Finite State Machines), EFSM (Extended FSM), CFSM (Communicating FSM)LTS (Labeled Transition Systems), IOA (Input-Output Automata), Petri Nets,

Programming Languages ModelsAbstract ProgramsCCS (Calculus of Communicating systems), CSP (Communicating Sequential Processes)Temporal logic

Hybrid Models


Language StandardsSDL (FSM + extensions)Estelle (EFSM + extended Pascal)LOTOS (CCS)


Finite State Machines (FSMs)

Finite state machines consist of:StatesInput Events (or Signals or Messages)Input Events (or Signals, or Messages)Transition FunctionsOutput Events

inputevents outputs

transitionfunction

INPUTEVENTS OUTPUTS

TransitionF ti


currentstate

nextstate

state

function

STATE

NEXTSTATE

CURRENTSTATE

Function


FSM – Statesinput

events outputstransitionfunction

Current State State which determines the current behavior of the machine

Next State

currentstate

nextstate

state


State which machine will have after processing an input event. Next State can be the same as current state

Start State State in which machine will be when created (power on)

End StateState in which no transition rule is executable


inputevents outputstransition

function

FSM – Transitions

currentstate

nextstate

state

Triggered by input events the FSM moves from one state to other based on the Transition Function


based on the Transition FunctionTransition Function produces the Output and Next State depending on Current State and Input EventWhile in particular state FSM is not active, it is waiting for an input to perform next activity


Typical FSM – Vending Machine

Inputs: coin, button (,hit)Outputs: lamp, espresso, idleStates: 1(wait for coin), 2(wait for button)



FSM – Formal Definition

A general FSM is 6-tuple: A = (S, X, Y, DA, h, s0), whereS – Finite set of statesX Fi it t f i tX – Finite set of inputsY – Finite set of outputsDA ⊆ S × X – Specification domain, subseth : DA 2S×Y – Behavior function, powersets0 ∈S – Initial state

Normally called initialized nondeterministic Mealy machineS t f fi l t t F l b d fi d


Set of final state, F, can also be definedToo general, will be restricted

Nondeterministic to deterministicBehavior function to transition function + output function


Categories of Finite State Machines

Nondeterministic finite state machine (NFSM)A finite state machine whose behavior function maps inputs symbols and states to a (possibly empty) set of next statesstates to a (possibly empty) set of next statesThe behavior function may also map the null symbol (no input symbol needed) and states to next states

Deterministic finite state machine (DFSM)A finite state machine with at most one transition for each symbol and stateBehavior function h is replaced by transition δ and output λ functions


Behavior function h is replaced by transition δ and output λ functions



Complete FSM (CFSM)Completely specified finite state machineS ifi ti d i i th h lSpecification domain is on the whole spaceDA = S × X

Partial FSM (PFSM)Partially specified finite state machineSpecification domain is part of the whole spaceDA ⊂ S × X

I l t ti ll d l d b CFSM hil


Implementations are usually modeled by CFSM, while specifications could be CFSM or PFSM (i.e., partial view on the system)



The Mealy machine has both transition function and output function defined

A fi it t t hi hi h d t t f h t itiA finite state machine which produces an output for each transitionThe machine is the most general case because the output function is determined by both the events (X) and the set of states (S)So, input/outputs are attached to the transitionsThis is the normal case under study

The Moore machine is a special case of Mealy machine


The Moore machine is a special case of Mealy machine A finite state machine that produces an output for each stateThe output function is determined only by the set of states, SThus, states/outputs are attached to the states instead of the transitions


FSM – Formal Definition Generally Used

ClassificationComplete FSM, CFSM

Deterministic CDFSMDeterministic, CDFSMNon-deterministic, CNFSM

Partial FSM, PFSMDeterministic, PDFSMNon-deterministic FSM, PNFSM

A Mealy CDFSM is 6-tuple: FSM = (S, X, Y, δ, λ, s0), whereS – Finite set of statesX – Finite set of inputs


X – Finite set of inputsY – Finite set of outputsδ : S × X S – Transition functionλ : S × X Y – Output functions0 ∈S – Initial state


State Transition Diagrams

Used to visually represent an FSMEmphasis is on identifying states and possible transitionsCircles represent StatesArrows represent Transitions

ei are inputs, xi are outputs, Slash (“/”) : Input/OutputS1

e1/x1 e2/x4

e2/x3

Directed graph G=(V, E) representing FSM MSet of vertices V = {v1, v2, …, vn} represents the set


S2

e1/x2

of states S in MDirected edge (vi, vj)∈E represent a transition from state si to state sj in MAn edge in G is represented by a triple (vi, vj; L),L=ak/ol is the input/output operation corresponding to the transition from si to sj in M


FSM Tables

inputevents

outputscurrentstate

nextstate

S1 x1S2e1All inputs, states, state transitions

d t t f FSM b

Each row of the table is one unique combination of Input Events and Current State

S1

S2

S1

S2

x1

x2

x3

x4

S2e1

e1

e2

e2

S2

S1

S1

and outputs of a FSM can be listed in a Table format


For complete definition of FSM all Event/State combinations shall be providedTable is another way to represent an FSM with an emphasis on exploring all Event/State combinations


FSM Table – Compact Form

S1 S2

X1 X2

stateevent

Here in the top row of the Table has a list of all States while first column has a list of all Input Event

X1,S2

X3,S1

X2,S2e1

e2 X4,S1


column has a list of all Input Event.Table Field on the intersection represents the transition function for the State, Event combinationEach field contains list of outputs and next state


hEvents such as “switch on” and “switch off” may cause the machine to change state, as in the state diagram below for a light with a rocker switch.

s itch off/

Rocker Switch Example

off

on

switch on/make click sound

switch on/stay quiet

switch off/make click sound

switch off/stay quiet

inputevents

outputscurrentstate

nextstate

on

off

on

off

-

click

click

-

onSwitch on

Switch on

Switch off

Switch off

on

off

off

On Off

-

click,off

click,onSwitch on

Switch off -

stateevent


hSome events don’t cause a state transition at all, as in attempting to turn on a light that is already on.

hBehaviour of the system in each state has to be defined: State ON - light is emitted out of bulb, State OFF - no light emitted.


FSM Example – Telephone

What are possible statesWhat are possible events Create FSM TableCreate State Transition Diagram

When we model an object we consider behavior which is of interest for us


interest for us. In this case we will consider ability of phone to be used to dial another subscriber, to be used to pass voice between subscribers, and to be able to receive incoming calls


Telephone States

Following States can be identifiedIDLE no calls in progress handset is on-hookDIALING h d t i ff h k b t ll i t iDIALING handset is off-hook, but call is not in progressRINGING handset is on-hook, incoming call alertPATH ACTIVE handset in off-hook and call is in progress

Relevant events are:off-hook User takes handset off-hook

h k U l h d t h k


on-hook User places handset on-hookdial digit User dials digitcall alert Exchange alerts phone - incoming call


IDLE DIALING RINGING PATH ACTIVE

Telephone – FSM Table

On-hook -

IDLE

-

IDLE

Off-hook Send Dial Tone,

DIALING

-

PATH ACTIVE

-

DIALING Dial-digit(Note 1)

- PATH

-

-

Note 1: if last digit in phone number is dialed lower option shall be


PATH ACTIVE

Call-Alert Ring Phone,

RINGING

/

/

/

selected

“/“ Unexpected event, “-” No State Change


Telephone – State Transition Diagram

Off-HookStop Ringing

PATHACTIVE

RINGING

Dial DigitOn-Hook This is

Startingstate

Call AlertStart Ringing


IDLE

DIALINGOff-Hook

Dialing Tone

Dial DigitOn-Hook


Timers & FSMs

Sometimes there is a need to perform some actions after some period of time. For that purpose timers are usedTimers can be started specifying amount of time before time-out will happenWhen time-out occurs the timer event will be sent to the FSM. Name of event is typically same as name of timerTimers can be stopped, so timer event is not generated



Telephone FSM Table with Timers

IDLE DIALING RINGING PATH ACTIVE

On-hook -

IDLE

/

IDLE

Off-hook Send Dial Tone,

DIALING

-

Stop T1 PATH

ACTIVE

-

DIALING Dial-digit(Note 1)

-

PATH ACTIVE

-

-

Note 1: if last digit in phone number is dialed lower option shall be


Call-Alert Start T1=20secRINGING

/

/

/

T1 /

/

IDLE

/

selected


Telephone STD with Timers

Off-HookStop Ringing

Starting/Stopping of the Timersis not visible on STD.

PATHACTIVE

RINGING

Dial DigitOn-Hook

Call AlertStart RingingT1


IDLE

DIALINGOff-Hook

Dialing Tone

Dial DigitOn-Hook

This is Starting

state


FSM Minimization

Acceptable input sequence α=x1x2…xk∈ X* for state si∈S, if ∃ k states si1si2…sik∈S and an output sequence γ=y1y2…yk∈ Y* such thatth i f t iti / / /there is a sequence of transitions si-x1/y1->si1-x2/y2->si2…->sik-1-xk/yk->sik

X* denotes the set of all the acceptable input sequences for state si

States si and sj (subscript i, j) are equivalent if Xi*=Xj*, andif ∀α ∈ Xi* : λ(si, α) = λ(sj, α) Equivalent states are not distinguishable

FSM is reduced (minimal) if it has no equivalent states


Two FSMs are equivalent if their initial states are equivalentGenerate the same output sequence when offered the same input oneEquivalent reduced FSM are isomorphic


FSM Minimization Algorithm

1. Look at each pair of states (s1, s2) in the FSM 2. If s1 produces different outputs from s2 for any input, mark them

non-equivalent 3. For each state pair (s1, s2) not yet marked, for each input i, find

state pair (δ (s1, i), δ (s2, i)) 4. If (δ(s1, i), δ(s2, i)) are marked non-equivalent for any i, mark (s1,

s2) non-equivalent 5. Iterate until no more marking is possible


g p6. Unmarked state pairs are equivalent, simplify FSM accordingly


FSM Minimization With Implication Table

1. Construct implication chart1 square for each combination of 2 states

2. If outputs of states different, mark the square with “X” States cannot be equivalent

3. Otherwise, fill square with next state pairs for all input combinations

4. Systematically advance through squares for each next state pair in square, check that square for “X”


if “X”-ed, this square “X”-edI.e., if next states not equivalent, then these states not equivalent

5. Iterate until no changes6. Remaining unmarked squares represent equivalent states


FSM Minimization Example

Problem: build a sequence-detecting FSMDetects the 3-bit sequence 010 or 110M hi t ft h 3 bitMachine reset after each 3-bit sequence1 input, 1 output — output 1 only after sequence detectedMealy machine state diagram

S0

S2S1


S2

S6S5S4S3

S1


Empty Implication Table



Initial Implication Table



Result Implication Table



Extended Finite State Machines - EFSM

For more complex problems, number of states can increase to be unmanageable - this is called State ExplosionNumber of states can be reduced by introducing local variables

They reduce number of states by hiding less important information

Global state of an EFSM is dependant on the explicit state and current value of its variablesGenerally the information which doesn’t have strong impact on behavior shall be represented as a variable


EFSM introduce notions of Tasks that values of variables are assigned, arithmetic & logical operatorsDecisions where action (output, new state) depends on the variable value

Starting and stopping of timers also represents a task in EFSM


Extended FSMs Table

State tables for EFSM processes should include a separate tasks column, as outputs column is used explicitly for , p p ymessages that shall be sent

inputevents

outputscurrentstate

nextstate

S1 x1S2e1

tasks

t1

S1 S2

t1, X1, X2,1

stateevent


S2S1S2

x2--

x4,x2

e1e2e2

S2S1S1

--t3t4

, ,S2

t3,S1

,S2e1

e2 t4,X4,X2,S1


EFSM Example (1/3)

Communication protocol may rely on message acknowledge mechanism to indicate successful transmission of the message

Transmitter Receiver

msg

msg Ack

msgUser A

User Bmsg


msg_Ack


EFSM Example (2/3)

If message is not acknowledged it is re-transmitted


MsgmsgUser A

Msg

Messagelost


Msg_AckUser B

msgg

1 sec timer expired


EFSM Example (3/3)

If second re-transmission is not acknowledged an error is indicated to user


MsgmsgUser A

1 sec timer expired

Messagelost

Msg Messagelost

error Ind


1 sec timer expired

error_Ind


EFSM - States, Events

Consider Transmitter - what states can be identifiedIDLE no acknowledge pending, ready to send next messageW4 ACK iti f k l d f tW4_ACK waiting for acknowledge of next message

What Input Events can be identifiedmsg From userMsg_Ack From Receiver

Wh t O t t E t b id tifi d


What Output Events can be identifiedMsg to Receivererror_Ind to User


EFSM State Table

IDLE

W4 ACKState IDLE W4_ACK

msg

Start T1=1s Msg,

W4_ACK

Return to queue

Msg_Ack

/

Stop T1, IDLE

Event

variable I as a counter


Start T1=1s, I++, Msg,

-

T1

/

error_Ind, IDLE

I==1is true


Equivalent FSM State Table

IDLE W4 ACK W4 ACK1State

IDLE W4_ACK W4_ACK1

msgStart T1=1s

Msg,W4_ACK

Return to queue Return to queue

Msg_Ack /Stop T1,

IDLEStop T1,

IDLE

Event


T1 /Start T1=1s,

Msg,W4_ACK1

error_Ind,IDLE


Another EFSM Example (1/2)

Define a finite state automaton, the input set of which is X = {a, b}and which accepts such a language, in which the sequence of five b symbols is followed by one a symbol and each a symbol isb symbols is followed by one a symbol and each a symbol is followed by at least one b symbolSolution in form of FSM

S6 is error state, others are acceptable final states



Another EFSM Example (2/2)

EFSM solution: variable B_CNT (b counter)Operations on variables e.g. <, ++, =, ==



Modelling of Complex Systems

So far we have only considered a single FSM. Typical telecomm system is too complex to be represented with a single FSM. As usually when dealing with complexity we should split a complexusually when dealing with complexity we should split a complex problem into a number of smaller componentsIn this case we will have number of concurrent FSMs communicating with each other. Communicating FSM can be

In a single process (task, thread of control)In separate concurrent processes on same microprocessorO t i i ti t h th


On separate microprocessors communicating to each otherDepending on how FSMs are co-located, different methods of communications are possible

The two communication mechanisms for concurrent processes can be categorised into Message Passing and Shared Data


Communication Mechanisms for Concurrent Systems

Message passing involves sending and receiving messages through a channelthrough a channel

Shared

Process ProcessReceive

Send ChannelIn the Shared Memory approach memory is common to both processes, and they can read and write to the memory


Process Process

SharedMemoryWrite Read

The two are equivalent. We will only consider message passing as more general


Asynchronous & Synchronous Communications

Two approaches to implement message passingSynchronous Communication

The processes involved in communication are required to participate at theThe processes involved in communication are required to participate at the point of communication simultaneouslyIf Process A attempts to send a message and Process B is not ready to receive it, Process A must wait until Process B is ready

Asynchronous Communication The processes involved in communication are not required to participate at the point of communication simultaneouslyIf Process A attempts to send a message and Process B is not ready to

i it P A d it


receive it, Process A sends it anywayIf Process B is ready to receive a message but A hasn't sent it, B must waitAsynchronous communication requires use of buffers to store messages

The protocol specification methods studied in this course will be mostly based upon Asynchronous Communication


Asynchronous Communication using FIFOs

In most communicating systems, a FIFO (First In First Out) discipline is enforced on sending and receiving messagesDuring a send event the message is appended to the end of the queue while a receive event removes a message from the frontIt is possible to modify the communications channel to provide additional communication constructs such as priority signalsTo absorb any delay variation in the communications channel, FIFOs are usually used at the interfaces


Process Process

FIFO CHANNEL

FIFO CHANNEL SendReceive

ReceiveSend


Communicating FSMs Model

Protocol is described as a set of Communicating FSMs (CFSMs) Each CFSM represents a component (or process) of the network

I OSI t t l tit d iIn OSI term, a protocol entity, e.g. sender, receiverEach process can be defined by a set of states

The process waits in a state for an event to occurMessages are received as events by the receiving FSMWhen this input event occurs, it transfers to another state, and in doing so can send out messages and performs other tasks

Each CFSM is represented by a directed labeled graph where


Nodes represent states (conditions) of the processEdges represent transitions (events) of the process

This model is the model used by the ITU Specification and Description Language (SDL)


Communicating FSMs Model

Each protocol “entity” (e.g., sender, receiver) and “channel” connecting them have states

Protocol entity: states typically correspond to times when entity waiting for some eventsChannel: state indicates contents of channel

For each state: zero or more transitions out of state (to a new state) when event occurs

Protocol entity: typically when msg received or timeout


y yp y gChannel: msg sent into channel, received from channel


TransitionsTransitions are triggered by actions

Internal the process (e.g. the sending of a message) or External stimuli (e g the reception of a message)External stimuli (e.g. the reception of a message)

The sending message transition is labeled as -Msg Where Msg is the type of messages being sent

The receiving message transition is labeled as +Msg Where Msg is the head message on the incoming FIFO queue of the CFSM


ProcessA

ProcessB

ProcessC Network

of CFSMs


CFSM Operating Semantic (1/2)Channels that connect CFSM's are assumed to be FIFO queuesStarting at the initial node, a CFSM traverses the nodes and transitionstransitionsNodes (states)

Initial node – starting state of a CFSMFinal node – no transitionReceiving node – all outgoing transitions are receiving transitions. If no message or incorrect msg in the channel, the node will be blockedSending node all outgoing transitions are sending transitions They are


Sending node – all outgoing transitions are sending transitions. They are not blockedMix node -- has both receiving and sending transition


CFSM Operating Semantic (2/2)Transitions

When a machine traverses a sending transition, it sends/appends a message with the same label to its outgoing channelmessage with the same label to its outgoing channelA machine at a node cannot traverse its receiving transition unless there is a message matched with the same label on the head of its incoming channelWhen a machine traverses a receiving transition, it removes the matched head message of its incoming channelAmong several possible transitions, a machine traverses one non-deterministically


deterministically


Communicating FSMs - Example

S11 S21FSM1 FSM2

Y

S12

Receive(Y)/Send(R)

Receive(X)/Send(P)

S22

Receive(R)/Send(X)

Receive(P)/Send(Y)

Y FSM1 FSM2


RY

P

X

Y

After receiving event Y FSMs will continue to oscillate indefinitely between their two states


Networks of CFSMsExample 1: Simple request-response protocol

Example 2: What happens if we change the initial node of a CFSM



Networks of CFSMsExample 3: An aggressive protocol with a self-sending loop

Example 4: A sliding window protocol with a window size of 2



CFSM Modeling ExercisesHow to specify the channel behavior as a CFSM which

Loses every other packet, Loses packets sometimesLoses packets sometimes, Loses and corrupts the packet sometimes?

How to extend the model to specify CFSMs with the multiple channels?


channels?


Pros and Cons of the CFSM modelThe overall state of the system can be described by a vector of all the states of the individual processes. Then the overall system state itself becomes a finite state machine, and thus its behaviour ,becomes more deterministicCFSM deals only with the state-transition aspect of protocols, It does not address the data aspect of protocols, e.g., message content or formatIt can not handle protocols where state variables have a wide range of values. Extended FSM were proposed but EFSM becomes difficult to analyze


becomes difficult to analyzeCFSM is an abstract model

The non-determinism in the execution of transitions of a mix node may result in different implementationYou can always expand the specification, e.g., replacing node 1 with a subgraph


Protocol Specification & FSMsMany formal protocol methods are based upon FSMThe ITU Specification and Description Language (SDL) is one such formal specification methodsuch formal specification method

Most protocols defined by ITU after the advent of SDL are described using SDLPrior to the introduction of SDL protocols were described using a variety of different methods including natural language

Even with the advent of formal specification languages there still exist ambiguities and incompleteness in the protocol specifications that must be resolved in the software design


specifications that must be resolved in the software designEven formally specified protocols may not have been validated sufficiently

The standards don’t include machine dependent details (like create application process) leaving the software designer to fill the gaps in


FSMs - Summary

Discrete event processes and finite state machines are key concepts in modelling the dynamic real-time behaviour of telecommunications softwaretelecommunications softwareFSM consist of States (Initial, Current and New), Input Events, Output Events, TransitionsIn case when “state explosion” is an issue extended FSM (EFSM) may be used so some states are replaced by local variablesComplex Telecommunication Systems can be modelled as


number of communicating FSMs


Correctness Properties of the ProtocolsCommunication software design errors:

Semantic error which causes the provision of incorrect service to the system users that affect the safety of the system.Syntactic errors which ultimately causes the protocol to deadlock, and therefore affects the liveness propriety of the system

1. Freedom from deadlocks2. Freedom from unspecified receptions3. Liveness4 B d d

Dynamic

Logical correctness (properties 1-4)


4. Boundedness5. Freedom from dynamical blockage6. Completeness7. Self-synchronization

1, 2, 3, 4SYNTACTIC

5, 6, 7SEMANTIC

Static


Protocol Design Errors – Deadlock

DeadlockBoth machines are at receiving states and channels are empty. The network can not progress furthernetwork can not progress furtherReceiving state is a state where all its outgoing transition are all receiving transition. It can not move without msg in its incoming channel

S+a

1+a2+a

FIFO queries are empty

C1

+A2

1-R +R-A

2

1


Discriminates against LivelockA system is in the livelock (dynamic deadlock) if the processes are exchanging messages that are not useful for providing the service and so not making "effective progress".

+a t

C2Sender Receiver


Protocol Design Errors – Unspecified Reception

Unspecified receptionThere exist a message in the queue, there exist a reception transition but the message in the queue is different from the message expected by thethe message in the queue is different from the message expected by the reception transition. The network can not progress further.E.g. there is msg B in C2 but sender does not have a receiving transition with msg B.

+a

b1 C11 1


S+a1

+a2

+at

{a1, …, at}∩{b1, …, br}= ∅

b2

brC2

+A

Sender2

-R +R-A

Receiver2B


Non-executable States and Transitions

E.g. State 3 of Receiver will never be executed or become the current state. It is called non-executable state.Transitions (2 3 +B) and (3 1 C) will never be executedTransitions (2,3,+B) and (3,1,-C) will never be executed. They are called non-executable transitions.

C11 1

-C


C2

+A

Sender2

-R +R-A

Receiver2B 3+B


Other Protocol Design Errors

Instability or state ambiguityIf an initial state of one protocol entity may coexist with different states of other cooperating entities (with empty channels)other cooperating entities (with empty channels)The result of such an error is the potential loss of synchronization between the cooperating entities

Unboundedness or overflowIf a protocol state can be reached such that the channel linking any pair of communicating protocol entities contains a number of messages exceeding


g p g gthe predefined capacity for that channel


Protocol Verification: Global State In CFSMs

A global state of a system, is a pair of <S,C>, where S=(s1,s2,…sn), si – current states of processes Pi,C ( ij f ll I#j d i j ) t t t f th h l ij li ki thC=(cij, for all I#j, and i,j≤n) – current contents of the channels cij linking the processes Pi and PjA global state is a snapshot of the overall system state

The initial (final) global state composition is a pair <S,C> in which Each si of S is the initial (final) states in its respective processes PiAll channels are empty, i.e. cij = ∅

The next global state is obtained as: <S C>=><S’ C’> if there


The next global state is obtained as: <S,C>=><S’,C’>, if there exit a transition that can be executed. Two cases are possible: 1. There exist a transition for a process where the message x can be sent,2. There exist a reception transition of a message x for a process and a

message x is in the input queue of a process


Protocol Verification Using Reachability Analysis

Reachability Analysis is a global state exploration process that Starts from the initial global state, and

i l l ll ibl t iti th t l d t l b l t trecursively explores all possible transitions that lead to new global statesThe result is a reachability graph, which captures all possible states

A global state <S,C> is said to be reachable from the initial global state <S0,C0>, denoted <S0,C0> =>*<S,C>, IFF:

There exists an execution path consisting of the interleaving of message receptions and transmissions that takes the system of communicating


receptions and transmissions that takes the system of communicating processes from the the initial global state <S0,C0> to <S,C>


Reachability Graph (Tree)

Reachability Graph (Tree)Nodes represents regular global statesDirected arc connecting two nodes or states <S1 C1> and <S2 C2>Directed arc, connecting two nodes or states <S1,C1> and <S2,C2>,corresponds to a transition in one of the communicating processesRoot of the Tree corresponds to the initial state <S0,C0>A path in the Tree corresponds to an execution sequence of the interleaved receptions and transmissions, and it represents the reachability of the last state in the path from the initial state of the path

The expansion of the tree from a particular node stops if one of the following conditions is satisfied:


g1. the node already exist in the tree2. the node correspond to a deadlock state3. an unspecified reception error is detected at the node4. the node corresponds to a final state


Reachability Analysis ProcessStarting from initial global state, where channels are empty and machines at their initial statesExplore all possible reachable state by firing all the possibleExplore all possible reachable state by firing all the possible transitions (and generating global states) from any given reachable stateAll deadlock and unspecified reception errors will be captured and marked as individual global stateBy examining the number of messages in the channels we can d i th b ff i f th t l


design the buffer size for the protocolCan detect non-executable states and transitions by marking those states that are touched and transitions that are fired during the reachability analysis


Reachability Analysis Example 1

CFSMsC1

1 1

11E

E

gs0

Global state/reachable state

C2

-R+A

Sender2

1+R-A

Receiver2

1-B

21R

E

-R

21B

Egs2

-B

UnspecifiedReception,Receiver donot know

22E

E

+R

gs1

gs3


Sender’sState

Channel C1’s content

Channel C2’s content

Receiver’sState

gsn –Global State ID

not know how to receive B

E: channel empty

2

21E

A

-A

+A

gs4

Reachability Graph






a) Perform the reachability analysis on the Network (M, N)b) What sizes of buffers are needed for the two FIFO channels?c) Are there non-executable states or transitions?

1

M

R+A A

1

N

R+A A


2 3

-R+A+R -A

2 3

-R+A+R -A


Reachability Analysis Example 3 – Solution

One unspecified reception (see gs4)

1 EE 1

GS 0

GS 2M:-R N:-R

gs4)Both channels need buffer size of 2 (see gs8 and gs9)No non-executable states and transitionsSince both machines send same types of msgs. We use “Machine:” to specify which

2 RE 1

GS 11 ER 2

GS 2

2 EE 3

GS 3

N:+R

2 RR 2

GS 43 EE 2

GS 5

N:-R M:-R M:+R

2 EGS 6

1 AGS 7

N:-A

M:+A

M:-Aunspecifiedreception


Machine: to specify which machine fires the transition

2 EA 1

1 AE 2

2 EAR 2

GS 8

N:-R

M:+A

2 ARE 2

GS 9

M:-R N:+A

N:+A

Figure 1. Reachability graph.



Perform the reachability analysis on the Network (P1, P2)Find deadlock, unspecified reception global states in the protocol Are there non-executable transitions and nodes in the CFSMsHow many buffers are required in each of the two channel?



[State of P1, C21, C12, State of P2]

Reachability Analysis Example 4 – Solution

No deadlock or[S0, E, E, S0]

[S1, E, 1, S0]

[S1, E, E, S1]

[S1, 2, E, S0] [S1, 3, E, S2]

No deadlock or unspecified receptionNon-executable

P1: S2, (S1, S2, +5), (S2, S1, -4)P2: S3, (S2, S3, +4), (S3, S1, -5)


[S1, 2, E, S0] [S1, 3, E, S2]

[S1, E, E, S2][S1, 3 6, E, S0]

[S1, 6, E, S0]

BufferC21: 2C12: 1


Reachability Analysis ExercisesGiven the following network of two communicating finite state machines,a) Perform the reachability analysis on the Network (M, N). b) What sizes of buffers are needed for the two FIFO channels? c) Are there non-executable states or transitions?


What are the channel buffer sizes needed for the following two machines?


Pros and Cons of Reachability AnalysisAdvantages:

Easily automatedMany logical errors can be detected by only examining individual globalMany logical errors can be detected by only examining individual global states in the reachability graph

Disadvantages: State space explosion problemDoes not work on unbounded protocolsMany relationships among the protocol state variables, expressing the


Many relationships among the protocol state variables, expressing the desirable logical correctness properties of the protocol are not apparent from simply traversing the reachability graph


Methods Other Than Full State Space Search

Full search is simplest but for small class of protocolsControlled partial search tries to optimize the quality of analysis

Depth-bounds, place a bound on the length of the execution sequencesScatter searches, executions are selected that lead closer to potential deadlock statesGuided searches, a dynamically evaluated cost function as state selection criterion Probabilistic searches, successor states are explored in decreasing order of their probability of occurrence


p yPartial orders, based on the definition of a heuristic for fair or maximum progress state exploration

Random simulation is for systems of even complexity Explore the state space with a random simulation or “random walk”


Outline


Protocol synthesis



Protocol Synthesis – Services vs. Protocols

ServicesAt high level of abstraction, a communication system can be viewed as a service provider which offers some specified communication services to aservice provider which offers some specified communication services to a number of service user who access the system through many geographically distributed service access points (SAPs)Service specification describes the distributed functions provided by the system to its service users

ProtocolsAt a lower level of abstraction, the communication system can be seen to


consist of a number of cooperating protocol entities (PEs) which exchange protocol messages (PDUs, over FIFO reliable communication medium) that are not observable to the users at the SAPProtocol specification describes the behavior of the PEs, each servicing a particular SAP


Protocol Synthesis – the Problem

Protocol synthesis is the problem as “the design of the (N)-protocol specification starting from both (N)- and (N-1)-service specifications ”specifications.”

“synthesis” is also known as derivation, transformation, construction, decomposition, refinement, etc.

U1 U2 Un

SAP1 SAP1 SAP1

U1 U2 Un

SAP1 SAP2 SAPn


SAP1 SAP1 SAP1 SAP1 SAP2 SAPn

PE1

FIFO Reliable Comm Medium

Communication Service PEnPEnSynthesis


Protocol Synthesis Methods

General features to characterize synthesis methodsStarting point of the method: requirements/protocol/service specificationM d li f li PN LOTOS (E i ) FSMModeling formalism: PNs, LOTOS (Expression), FSMConstraints on communication model: synchronous/asynchronous, number of entities, ordering, degree of reliability, etc.Mode of interaction with the designer: automatically or interactivelyProtocol properties guaranteed: liveness (non-deadlock), safety (bounded)Specific protocol functions: error recovery, throughput, testability

Service oriented methods


Service oriented methodsModeling formalism could be FSM based or LOTOS based

Non-service oriented methodsBasically FSM basedCan be automatic generation or interactive construction


An Example

behavior architecture

architecture with protocol entities:

Service A

A b, caa

1

2

b

cservice access pointsat two different sites:

S1, S2

ba

b, ca

E1 E2


A

b, ca

S1 S2

Deriving a protocol specification from a given service specification

Question: What should be the behavior of E1 and E2 ?


Solution for the example

a(1) ; b(2) becomes in E1: a(1) ; send(2, x), in E2: receive(1,x); b(2)

S i A Protocol

a

1

1’

E1

1

2

E2

2

Receive(2,y)

Receive(1,x)

2’b

Send(1,y)

Service A Protocol

a

1

2

b

behavior


cSend(2,x)

A

b, ca

S1 S2

cb, ca

E1 E2


References

G.J. Holzmann, Design and validation of computer protocols, Chapter 8-11, Prentice-Hall, 1991, ISBN 0-13-539925-4, spinroot com/spin/Doc/Book91 htmlspinroot.com/spin/Doc/Book91.html A. Petrenko, Introduction to the theory of experiments on finite state machines, lecture notes, 2003, www.bretagne.ens-cachan.fr/DIT/People/Claude.Jard/ sem_13_05_2003_petrenko_trans.pdf Igor Potapov , Protocol engineering, lecture notes, 2004, www.csc.liv.ac.uk/~igor/COMP201/G V B h d R G t h i D i i t l ifi ti


G.V. Bochmann and R. Gotzhein, Deriving protocol specifications from service specifications, ACM Trans. on Computer Systems, vol. 8, no. 4, 1990: 255-283R.L. Probert and K. Saleh, Synthesis of communication protocols: survey and assessment, IEEE Trans. Computers, vol. 40, no. 4, 1991: 468-476

II. FSM - University of Oulu · FSM (Finite State Machines), EFSM (Extended FSM), CFSM...

Documents

Transcript of II. FSM - University of Oulu · FSM (Finite State Machines), EFSM (Extended FSM), CFSM...