EFSM Code Generation v4 1x2
EFSM Code Generation v4 1x2
Insup Lee
Department of Computer and Information Science
University of Pennsylvania
Outline
A Keyboard Example
Formal Definitions
Variants
EFSM: A Keyboard Example
initial self
transition transition trigger action list
final
state variable
CAPS_LOCK CAPS_LOCK
variable
EFSM: Definitions
An EFSM consists of
o Extended States, Guards, Events, Actions, and Transitions.
A state is a situation or condition of a system
during which
o some (usually implicit) invariant holds,
o the system performs some activity, or
o the system waits for some external event.
An extended state is a state with “memory”
o E.g., using 100,000 states to count 100,000 key strokes;
or, using one extended state with a variable “count”.
Keystrokes=2
Keystrokes=1
No concept of variable „keystrokes‟, using One state and one variable to
different states to represent them. represent all.
Spring '10 CIS 541 8
EFSM: Definitions
Guards are
o boolean conditions on extended state variables which
enables or disables certain operations (e.g., change of
states).
o evaluated dynamically based on the extended state
variable values.
o immediate consequence of using extended state variables.
An event
o is an occurrence in time and space that has significance to
the system.
o may also be parametric which conveys quantitative info.
Spring '10 CIS 541 9
EFSM: Definitions
Actions
o are performed when an event instance is dispatched.
o include
changing a variable;
performing I/O;
invoking a function;
generating another event instance; or
changing to another state (state transition).
Transitions
o can be triggered by events.
o can also have a guard.
Input/output Variables
o can serve as enhanced messages in communicating EFSMs
Communicating EFSMs
o input/output events are properly defined to convey info
o EFSMs communicate by sending and receiving events via channels
Timed Automata
o “clock” variables are added, increasing automatically as
clock ticks (discrete) or
time elapses (continuous)
Hierarchical EFSMs
o inside a state, the system behavior is also like an EFSM
Three methods
o init() – take a top-level initial transition
o dispatch() – dispatch an event to the state machine
o tran() – take an arbitrary state transition
Each coding scheme virtually implements these
To use an EFSM in the main logic of the code
o create an EFSM instance
o invoke init() once
o call dispatch()
repetitively in a loop
or sporadically based on detected events
o dispatch() will then call the corresponding trans() function
code
SLASH SLASH
star CHAR,
SLASH
slash
CHAR
STAR
STAR
STAR
comment
CHAR,
SLASH
Two alternatives
o Switch with events first and then states
o Use one switch that combines both.
class CParser1 {
private:
State myState; // the scalar state-variable
long myCommentCtr; // comment character counter
state machine interface
/* ... */ // other CParser1 attributes
public:
void init() { myCommentCtr = 0; tran(CODE); } // default transiton
void dispatch(unsigned const sig);
void tran(State target) { myState = target; }
long getCommentCtr() const { return myCommentCtr; }
};
Signals
CHAR_SIG STAR_SIG SLASH_SIG
code doNothing(),
States
slash
slash doNothing(), a2(), doNothing(),
code comment code
comment a1(), doNothing(), a1(),
comment star comment
star a2(), a1(), a2(),
comment star code
State Table
Advantages
o Direct mapping from a tabular representation of an EFSM
o Fast event dispatching
o Code reuse of the “generic event dispatching process”
Disadvantages
Signals
o Table maybe large
CHAR_SIG STAR_SIG SLASH_SIG
and wasteful
code doNothing(),
States
slash
slash doNothing(), a2(), doNothing(),
code comment code
comment a1(), doNothing(), a1(),
comment star comment
star a2(), a1(), a2(),
comment star code
{{&StateTable::doNothing, CODE },
{static_cast<StateTable::Action>(&CParser2::a2), COMMENT },
{&StateTable::doNothing, CODE }},
{{static_cast<StateTable::Action>(&CParser2::a1), COMMENT },
{&StateTable::doNothing,STAR },
{static_cast<StateTable::Action>(&CParser2::a1), COMMENT }},
{{static_cast<StateTable::Action>(&CParser2::a2), COMMENT },
{static_cast<StateTable::Action>(&CParser2::a1), STAR },
{static_cast<StateTable::Action>(&CParser2::a2), CODE }}
};
(2)
(3)
(3) The parser has exactly one object for each concrete
state class (e.g., myCodeState, mySlashState, etc.)…
Spring '10 CIS 541 32
(4)
(5)
(6)
};
CodeState CParser3::myCodeState;
SlashState CParser3::mySlashState;
CommentState CParser3::myCommentState;
StarState CParser3::myStarState;
Advantages
o It localizes state specific behavior in separate (sub)classes.
o Efficient state transition – reassigning a pointer.
o Fast event dispatching – using C++ mechanism for function look up.
o Parameterized events made easy – passing function parameters.
o No need for enumeration of states or events beforehand.
Disadvantages
o Adding states requires creating subclasses.
o Adding new events requires adding handlers to state interface.
o In some situations where C++ or Java is not supported (e.g., some
embedded systems), mockups of OO design maybe an overkill.
Approach I
o Each EFSM is implemented inside one thread.
o Threads run simultaneously, scheduled in round-robin.
o EFSMs share variables in the process.
Advantage
o Straightforward transformation from model.
o EFSM communication easily implemented with thread messages.
Disadvantage
o In some situations, no ready thread support in specific platform.
o Related analysis (progressiveness if semaphores are used, timing
properties, etc) may be difficult.
Multiple-threaded Implementation
Approach II
o Event detectors are implemented in threads.
o Transition actions are implemented in functions.
o Location information is stored with a variable.
o When event detector threads detects, calls corresponding functions
and switching locations.
Advantage
o Easy adaption to model changes.
Disadvantage
o In some situations, no ready thread support in specific platform.
o Code may be unstructured/unreadable.
Introduction
The EFSM Language
Checking for Non-determinism and Totality
Translations to Other Languages
Test Generation from EFSMs
Script Generation
Code Generation
Simulation
Introduction to EFSM Toolset
Example
SYSTEM LampSystem:
Channel: press, sync, B;
EFSM Lamp {
States: off, low, bright;
InitialState: off;
LocalVars:
bint[0..5] y =0,
boolean x = false;
Transition: From off to low when true==true do press ? x , y =0;
Transition: From low to off when y>=5 do press ? x;
Transition: From low to bright when y<5 do press ? x;
Transition: From bright to off when true==true do press ? x;
}
EFSM User {
States: idle;
InitialState: idle;
LocalVars:
boolean x = false;
Transition: From idle to idle when true==true do press ! x;
}
Definitions
o An EFSM is non-determinism if there exists some state
with two or more outgoing transitions which maybe
enabled at the same time.
o An EFSM is total (or complete) if at any state S, there is at
least one outgoing edge enabled.
Checking Non-determinism and Totality
o The EFSM Toolset utilizes the satisfiability checker zChaff
systematically transform logic formula over guards to DIMACS
(zChaff accepted format)
feed into zChaff and interpret the result
Test Generation
o create a set of traces through the EFSM
o for testing an implementation of the system
o coverage criteria
state coverage – go through each state at least once
transition coverage – ensures that every transition is take once
definition-use coverage – makes a trace from every definition of a
variable to each of its subsequent uses
Output of Test Generation
o a sequence of assignments of variable values
o necessary to lead the EFSM to take particular paths
Script Generation
o takes a set of traces (from test generation)
o makes a set of scripts
o which can be run on an implementation
Approach
Code Generation
while (transition_taken) {
transition_taken=0;
if ((currentState==1)&&(current < getNumBots())) {
PRE_TRANSITION_HOOK;
current=current+1;
currentState=2;
transition_taken=1;
//printf("rolling:From:incrementTo:check
//Guard:current <=numBotsAction:current=current+1\n");
POST_TRANSITION_HOOK;
}
....
if ((currentState==2)&&(getSwitch()==1)) {
PRE_TRANSITION_HOOK;
setAllAngles(1);
currentState=1;
transition_taken=1;
//printf("rolling:From:checkTo:increment
//Guard:switchValue==trueAction:setAngles=true \n");
POST_TRANSITION_HOOK;
}
}
import jcsp.lang.*;
public class gaitThread implements CSProcess {
private final String name="gaitThread"; ....
public gaitThread() {}
public void run() {
final Skip skip= new Skip(); ....
while ( true ) {
switch (alt.priSelect()) {
case 0:
if ((currentState.equals("footArming")) & (TwoSecondDelay == true )) {
currentState="spineArming";
System.out.println("gait: From: footArming
To:spineArming
Guard:TwoSecondDelay== true
Action:spine=-20");
}
if ((currentState.equals("spineArming")) & (TwoSecondDelay == true)) {
....
} ....
....
}
}
}
Spring
} '10 CIS 541 57
Simulation with the EFSM Toolset
References