Stateow
What is Stateow Examples Extended uses Semantics and problems
What is Stateow?
A state machine design tool integrated within Simulink: Stateow produces Simulink blocks, fed with Simulink inputs and producing Simulink outputs, a Stateow block can execute Simulink blocks as actions,
provides a seamless integration of state machines into a block diagram formalism.
What is Stateow made of?
Stateow integrates three basic components: 1. hierarchical and parallel state machines borrowed from Statecharts,
2. control ow diagrams allowing to design complex transitions between Stateow states,
3. truth tables allowing to design complex actions.
Stateow Features
Several features are worth to be noticed: Stateow encompasses both Mealy and Moore machines: actions associated with both states and transitions, entry actions performed when entering a state, during actions, performed when remaining in the state, exit actions, performed when leaving the state, condition actions, performed before leaving the source state, transition actions, performed after leaving the source state but before entering the destination state.
More Stateow Features
large variety of means for describing actions: event broadcasting, Stateow scripts (assignments, etc.), truth tables, Simulink block execution, Matlab functions.
Example: The Once Subsystem in Stateow
Design an automaton with one boolean input and one boolean output such that the output is initially false becomes true as soon as the input becomes true stays true for ever as soon as it has become true once
2
1 0 1 2
1 0 1 0 5 10 15 20
Time offset: 0
Solution
2 1 0 1 2 1 0 1 0 5 10 15 20
Time offset: 0
edgeauto/autoedge
[x==0]/{y=0} false [x==1]/{y=1} true
[x==1]/{y=1}
Checking the Solution
Shows how Stateow integrates with Simulink
Pulse Generator
Scope autoedge
Checking the Solution
Shows how Stateow integrates with Simulink
2 1 0 1 2 1 0
x y
1
Scope
10
15
20
Pulse Generator
autoedge
Time offset: 0
Example:Monitoring Properties
Design a property observer that monitors the property: a signal doesnt change its value in two consecutive samples Typical bevaviour:
2 1 0 1 2 1
0 1 0 2 4 6 8 10
Time offset: 0
Monitoring Properties: Solution
2
1 0 1 2 1
0 1 0 2 4 6 8 10
Time offset: 0
monitorauto/monitor
[x==0]/{y=0} onetrue [x==1] moretrue
[x==1]/{y=1} [x==0] [x==1]
failed
[x==0]/{y=1}
onefalse [x==0]
morefalse
[x==1]/{y=0}
Checking the Solution
Shows how Stateow integrates with Simulink
Repeating Sequence Stair
Scope monitor
Checking the Solution
Shows how Stateow integrates with Simulink
2 1 0 1 2 1
x y
0
Scope1
Repeating Sequence Stair
10
monitor
Time offset: 0
More Examples
A very popular usage: Mode Automata A Stateow chart is used to trigger several controller modes A cooperative way of designing complex systems: teams begin to agree on shared variable names, then each team can independently design and validate its own mode.
The Up team builds the up mode . . .
f()
fcn_call
FunctionCall Generator
A Data Store Memory
function()
double
In1
Out1
double
Constant
up
Scope
f() function A A
double
Data Store Read
double
Data Store Write
1 Out1
up.mdl
1 In1
double
. . . , tries it and saves it
40
20
10
15
20
25
30
Time offset: 0
function() In1 Out1
updown.mdl
up
The Down team builds the down mode . . .
f()
fcn_call
FunctionCall Generator
A Data Store Memory
function()
double
In1
Out1
double
Constant
down
Scope
f() function A A
double
Data Store Read
double
Data Store Write
1 Out1
down.mdl
1 In1
double
. . . , tries it and saves it
0 20 40
10
15
20
25
30
Time offset: 0
function() In1 Out1 In1
function() Out1
updown.mdl
up
down
The Simulink library looks like a Java static class
The UpDown team combines the two models. . .
f()
fcn_call
FunctionCall Generator
function()
double
In1
Out1
double
Constant
up_down
Scope
f() function
A Data Store Memory
1 z Unit Delay
upev downev
mode_control
function() In1 Out1
up 1 In1
In1
Switch
function() Out1
1 Out1
up down.mdl
down
. . . through the activation automaton. . .
up entry: upev during: upev
[y<=5]/s=1
[y>=5]/s=0
down entry: downev during: downev
. . . and tries it
10
15
20
25
30
Time offset: 0
It works. . .
Interest and Drawbacks
Interest : Modular approach No redesign No complex wiring Drawbacks Unsafe features when activations are not exclusive
Semantics
Simple Stateow has a clear semantics. Semantic problems appear with parallel states : parallel simultaneous activities which interact and communicate. Several solutions: non determinism: seldom used because determinism is appealing, unique logical solution: (for instance Signal), unique constructive solution: (Esterel, SyncCharts), restriction to one-way interaction: interactions statically ordered ensuring uniqueness (Lustre/Scade, Simulink?), micro-step semantics: (StateCharts, Stateow)
Stateow Solution
Micro-step semantics: an interpretation algorithm based on several orderings (priorities) describes uniquely in which order actions take place. raises problems of cyclic behaviours which dont terminate. (What about Statecharts?)
The Interpretation Algorithm
Starts each time an input event (coming from the Simulink world or from the same Stateow: recursive behaviour ) arrives. 1. search for active states, 2. search for valid transitions, 3. valid transition execution, 4. during action execution.
Search for Active States
performed: hierarchically, from top to bottom; sequentially for parallel states: graphical two dimension priority: states are searched from top to bottom and from left to right!
Search for Active States
performed: hierarchically, from top to bottom;
back
sequentially for parallel states: graphical two dimension priority: states are searched from top to bottom and from left to right! This is an unsafe feature: rst, small variations in the drawing can result in different behaviours, parallelism is misleading (actually sequentiality). verify that the Stateow behaviour is independent of the ordering of parallel states.
Search for Valid Transitions
transitions are searched based on several criteria, this is considered harmful even in the Stateow documentation:
Do not design your Stateow diagram based on the expected execution order of transitions. verify that there is at most one valid initial segment at a time outgoing an active state.
Transitions
A transition can be a complex ow graph made of segments joining connective junctions. Each segment can bear a complex label made of:
event [condition]{condition action}/transition action
in which each eld is optional.
Valid Transitions
Segments outgoing from a connective junctions are searched for validity according to several criteria, among which clock-wise, starting from a twelveo clock position. Cyclic ow diagrams are allowed leading to for and while diagrams (not available in Scade).
Valid Transitions
Segments outgoing from a connective junctions are searched for validity according to several criteria, among which clock-wise, starting from a twelveo clock position. Cyclic ow diagrams are allowed leading to for and while diagrams (not available in Scade). Cyclic diagrams can raise non-termination. Testing for validity of a transition implies executing condition actions found along the transition path (complex side effects).
Labelled Default Transitions
Default transitions (transitions that are executed when entering a super-state) raise a specic problem, indicated in the following warning quoted from Stateow documentation: When labelling default transitions, take care to ensure that there is always at least one valid default transition. Otherwise, a Stateow chart can transition into an inconsistent state. verify that there is always a valid default transition
Executing a valid transition
Once a valid transition has been found, the algorithm is quite simple: 1. execute the exit action of the source state, 2. set the source state to inactive, 3. execute the transition actions of the transition path, 4. set the destination state to active, 5. execute the entry action of the destination state.
Executing a valid transition
Yet, the behaviour can be very complex and lead to non termination because, when an event is broadcast, the interpretation algorithm stops and is stacked and a new intepretation algorithm starts dealing with this event and runs up to completion. Broadcasting an event in the action language is most useful as a means of synchronisation among AND (parallel) states. Recursive event broadcasts can lead to denition of cyclic behaviour. Cyclic behaviour can be detected only during simulation. Thus possible cyclic behaviours should be detected at translation time.
When there is not Valid Transition
When an active state has no valid output transition, its during action is performed and the state remains active.
Safety Checking
The majors points to check for safety: 1. check that the order into which parallel states are considered is irrelevant, 2. check that outgoing transitions from a state are exclusive, 3. check that when entering a super-state, there is always a valid default transition, 4. check the twelve oclock rule, 5. check the cyclic behaviour of connective junctions, 6. check the recursive behaviour due to event broadcasting. In all these aspects, guidelines are needed
