STATE MACHINE

DESIGN AND
IMPLEMENTATION

Jan 2011
Coding Standard – State Machine Implemented
as Structured Text Inside Function Block
This describes a coding standard for design and implementation of PLC
functionality from design of the state machine through to deployment by
using an example of development of an MCC starter function block
programmed in Schneider Electric Unity Pro Software.
 State Machine Design and Implementation in IEC 61131 Languages

1. REFERENCES

Defining State Machines/Modelling

 ISA-88/IEC 61512-1
Unity Pro Language Guide

 Unity Pro Program Languages and Structure Reference Manual (35006144.07 07/2008)

2. INTRODUCTION

Traditionally PLC control logic has been implemented as ladder logic, for a number of reasons

 Memory efficiency

 Extension of physical relay control logic into software

 Perceived simplicity

 Only programming language offered by the vendor

 Familiarity due to legacy

Some negatives associated with ladder logic are

 Unstructured “free form” – very easy to write badly structured code (especially spaghetti code)

 Even well structured code can be difficult for a third party to understand/troubleshoot

 Poor encapsulation of functionality – possible “side effects”

 Poor encapsulation of variables – possible “side effects”

Some two decades ago the IEC defined a standard for PLC languages, yet it has only been in the last 5
years or so the products offered by the vendors have matured and many clients acceptance of the new
languages has occurred.

IEC 61131-3 is the international standard for programmable controller programming languages. As such,
it specifies the syntax, semantics and display for the following suite of PLC programming languages:

 Ladder diagram (LD)

Page 1
 State Machine Design and Implementation in IEC 61131 Languages

 Sequential Function Charts (SFC)

 Function Block Diagram (FBD)

 Structured Text (ST)

 Instruction List (IL)

The different languages have different strengths and weaknesses for different applications. Also the
standard allows for use of arrays and user defined data structures, encapsulating data use and making
object orientated software design and implementation easily achievable.

An added benefit of user defined data structures and function blocks that can instanced from a prototype
is that a change made to the definition will propagate through all the instances when the program is
recompiled.

This document outlines the use of user defined function blocks with internal logic in the form of structured
text, starting from the design requirements and functionality through to implementation.

A specific example implemented in Schneider Unity Pro programming software will be used to illustrate
the concepts.

With all factors taken into account it is thought this approach yields optimum results for use in automation
control schemes in the following contexts:

 Unambiguous and exhaustive definition of functionality

 Object orientation

 Encapsulation of object functionality and transitions of object states (see more later)

 Ease of implementation – design is up front before coding commences

 Ease of trouble shooting – relevant “snippet” of code is easily found for any mis-operation

3. State Machine Definition of Functionality

Traditionally implementation of from requirements to code has been done by the PLC programmer
converting an English narrative to control code by mentally designing functionality and code
implementation in one pass.

This creates multiple problems

 Interpretation of English language to code differs from person to person

 English language descriptions are rarely exhaustive or unambiguous

 Often requires keeping multiple ideas in the head at one time – the average person can only
manage 3-5 concurrent ideas at once in their mind.

Page 2
 State Machine Design and Implementation in IEC 61131 Languages

An example follows of where English descriptions of requirements can fail, in this case due to differing
understanding of context:

A wife asks her husband, a software engineer, "Could you please go shopping for me and buy
one carton of milk, and if they have eggs, get 6!"

A short time later the husband comes back with 6 cartons of milk.

The wife asks him, "Why the hell did you buy 6 cartons of milk?" He replied, "They had eggs."

4. DEFINING FUNCTIONALITY WITH A STATE MACHINE

4.1.1. Step 1 – Identify the Machines (Objects)
The first step is to identify the breakup of the system into machines. A machine is a functional object with a
number of mutually exclusive states. A state is a property of the machine.

An example of a simple machine might be a solenoid controlled valve with feedback limits. The states
could be:

 Opened – valve is in the opened position, confirmed by limit

 Closed – valve is in the closed position, confirmed by limit

 Travelling to Opened – valve is moving to the open position but not arrived at limit yet

 Travelling to Closed – valve is moving to the closed position but not arrived at limit yet

 Fail to Open – Open limit was not reached in required time

 Fail to Close – Closed limit was not reached in required time

 Fault – Both opened and closed limits on simultaneously

If desired the states could be reduced to:

 Opened – valve is in the opened position, confirmed by limit

 Closed – valve is in the closed position, confirmed by limit

 Travelling – valve is moving

 Fault – Failed to travel to required state or both opened and closed limits on simultaneously

The states needed are determined by a range of factors

Page 3
 State Machine Design and Implementation in IEC 61131 Languages

 Need of the operator/maintainer/other machines (eg for interlocks) to know or record various
conditions
 Availability of information (Inputs) as to the status of the equipment, eg some valves may only
have a closed or opened limit.

Beware of creating too many states as the possible transitions form one state to another increase at a
ratio of number of states squared. This is called the state explosion.
The skill that must be learned is the appropriate granularity to break the system down to, and
appropriate states for each machine.
The number of states can be reduced by grouping a number of them together as per the previous
example of the valve. Avoid unnecessary states, the can always be added in later.

In our specific example we are building a function block to control a standard MCC DOL starter. For this
implementation the states are

 READY – The drive is ready to attempt to start if requested

 STARTING – The drive is starting, but not yet returned the running feedback
 RUNNING – The drive is running
 STOPPING – The drive is stopping but has not yet removed the running feedback
 FAIL TO START – The drive tried to start but running feedback not received in required time
 FAIL TO STOP – The drive tried to stop but the running feedback was not removed in time
 NOT READY – The drive would not start if requested because – in this case interlocked or the
starter is not ready due to isolation or lack of control power (This is dependent on the drive
schematic as it relates to functionality of the wiring of the starter)
 FAULT – The starter has a fault – in this case a thermal overload, but conditions depend on how
the MCC starter is designed.

4.1.2. Step 2 – Create the Blank State Table

(Refer to example below)

Now create a matrix with a list of all the possible states entered twice – once down the left hand side and
secondly in the same order across the top. The left hand side is the “from” state and the top line the “to”
state for how the machine will transition from state to state.

This is the state transition table and the intersection of the states at each “cell” of the matrix is where we
will enter the conditions to make that transition.

It is convenient to create a alpha numeric cross reference with numbers down the left side and letters
across the top so code comments can refer to the state transition cell.

Start by populating each cell with an “X” which means no transition allowed.

Page 4
 State Machine Design and Implementation in IEC 61131 Languages

4.1.3. Step 3 – Populate the State Table with Desired Transitions

For each desired transition, put the conditions for that transition in the state table cell.

e.g. in cell B1 we wish to allow the machine to go from READY to STARTING when the start pushbutton is
pressed and the stop button is not pressed.

Then in cell C2 we wish to transition from STARTING to RUNNING when the running feedback (contactor
closed) input is asserted.

If the running signal was not received in time we wish to transition from STARTING to FAIL TO START in cell
E2.

By progressively working through the desired transitions the table below is arrived at.

At this time it is prudent to identify all the necessary inputs are available to drive the required transitions.

4.1.4. Step 3 – Identify Which States Drive Which Outputs

In this example we only have one output to drive, which the RUN output. We wish the RUN output to be
asserted when the STARTER machine is in the states STARTING or RUNNING.

4.1.5. Step 4 – Identify Any Transitions With Associated Functionality

There are no transitions (as opposed to states) which have functionality in this example, but an example
where this might occur is in the case of a MODE machine with states LOCAL and REMOTE, where you might
like to initiate a stop command to the machine on a transition from REMOTE to LOCAL, but not vice versa.

Page 5
 STATE TO A B C D E F G

STATE FROM READY STARTING RUNNING STOPPING FAIL TO START FAIL TO STOP NOT READY

MCC_READY=false
START=true and 
1 READY X and X X X X INTERLOCK=true 
STOP=false and 
MCC_TOL=true

MCC_READY=false
and 
2 STARTING X X MCC_RUNNING=true STOP=true START_TIMER>START_TIME X INTERLOCK=true 
and 
MCC_TOL=true

MCC_READY=false
STOP=true and 
3 RUNNING X X X or X X INTERLOCK=true 
MCC_RUNNING=false and 
MCC_TOL=true

MCC_READY=false
and 
4 STOPPING MCC_RUNNING=false X X X X STOP_TIMER>1 second INTERLOCK=true 
and 
MCC_TOL=true

5 FAIL TO START RESET=true X X X X X X

6 FAIL TO STOP RESET=true X X X X X X

MCC_READY=true
and 
7 NOT READY INTERLOCK=false  X X X X X X
and 
MCC_TOL=false
5. Function Block
An example of the STARTER function block instanced as HPU_01B is shown below
 State Machine Design and Implementation in IEC 61131 Languages

6. Function Block Variables and Pin Assignments

The definition of the pin assignments (<inputs> and <outputs>) is shown below. These names correspond to
the names inside the funciton block adjacent to the pins.

Internal variables are defined in <private>.

The second column is the pin position on the block.

The third column is the type of variable.

Page 1
 State Machine Design and Implementation in IEC 61131 Languages

7. Defining Tag Named Constants For State Values

In order to allow english like strucured text to be written inside the function block and to have uniform state
values across the program, a set of constants are defined to hold the the state values.

First a data structure is defined with all the possible states to be used for the program or a subset of the
program. In this expample we define one list of states to cover all state machines used within the PLC
program

This data structure is then instanced, in thas as variable “C” and values assigned to the states.

This variable C is then passed into the function block as type “Constants” to allow use of the variable
“C.NOT_READY” instead of a literal integer “1”.

Page 2
 State Machine Design and Implementation in IEC 61131 Languages

This is both more meaningful and referenced back to a common definition that allows change for the whole
program to be enacted at a single point if needed.
The values assigned to the states in the instance can be any integers provided they are unique. e.g. each
value only is used once. If by some chance the same value is assigned to two different states, the state
machine/code will probably behave with a seemingly bizarre and unexpected functionality, even though the
structured text code would read as if it were well formed.

Page 3
 State Machine Design and Implementation in IEC 61131 Languages

8. Logic Internal To The Function Block

The following shows the structured text inside the function block which solves the state machine logic.

Each if statement corresponds to a cell in the transition table, as indicated in the comments.

Note the use of the “C.Xxxxxxx” variables which makes the code readable.

Also note the assignment of text to a string (“State_Text”) which is output on a function block pin. This allows
the programmer to see what state the machine is currently in without having to decode the integer value by
referring back to the C instance of the Constants data structure.

(************************************************************)

(* Process Drive Control *)

(* B1 - Ready to Starting *)
If ((State=C.Ready) and (START=true) and (STOP=false)) then
new_state:=C.STARTING;
State_Text:='STARTING';
end_if;

(* C2 - Starting to Running *)
If (State=C.Starting) and (MCC_RUNNING=true) then
new_state:=C.RUNNING;
State_Text:='RUNNING';
end_if;

(* D2 - Starting to Stopping *)
If (State=C.Starting) and (STOP=true) then
new_state:=C.STOPPING;
State_Text:='STOPPING';
end_if;

(* E2 - Starting to Fail_To_Start *)
START_TIMER (IN:=(State=C.Starting), PT:=START_TIME, Q=>Q1, ET=>ST1) ;
if ((State=C.Starting) and (Q1=true)) then
new_state:=C.FAIL_TO_START;
State_Text:='FAIL TO START';
end_if;

(* D3 - Running to Stopping *)
If (State=C.Running) and (STOP=true or MCC_Running=False) then
new_state:=C.STOPPING;
State_Text:='STOPPING';
end_if;

(* A4 - Stopping to Ready *)
If (State=C.Stopping) and (MCC_RUNNING=false) then
new_state:=C.READY;
State_Text:='READY';
end_if;

Page 4
 State Machine Design and Implementation in IEC 61131 Languages

(* F4 - Stopping to Fail_To_Stop *)
STOP_TIMER (IN:=(State=C.Stopping), PT:=TIME#1s0ms, Q=>Q2, ET=>ST2) ;
if (State=C.Stopping) and (Q2=true) then
new_state:=C.FAIL_TO_STOP;
State_Text:='FAIL_TO_STOP';
end_if;

(* A5, A6 - XXX to READY (RESET) *)

If (
(State=C.FAIL_TO_START) or
(State=C.FAIL_TO_STOP)
)
then
if (RESET=true) then
new_state:=C.READY;
State_Text:='READY';
end_if;
end_if;

(* A7 - NOT_READY to READY*)
If (State=C.NOT_READY) then
if ((MCC_READY=true) and (INTERLOCK=false) and (MCC_TOL=false)) then
new_state:=C.READY;
State_Text:='READY';
end_if;
end_if;

(* G1,2,3,4 - XXX to NOT_READY *)

If (
(State=C.READY) or
(State=C.STARTING) or
(State=C.RUNNING) or
(State=C.STOPPING)
)
then
if ((MCC_READY=false) or (MCC_TOL=true) or (INTERLOCK=true)) then
new_state:=C.NOT_READY;
State_Text:='NOT_READY';
end_if;
end_if;

(* transfer working state *)

state:=new_state;

(* Set output pins *)

READY:=(State=C.READY);
STARTING:=(State=C.STARTING);
RUNNING:=(State=C.RUNNING);
STOPPING:=(State=C.STOPPING);
FAIL_TO_START:=(State=C.FAIL_TO_START);
FAIL_TO_STOP:=(State=C.FAIL_TO_STOP);
NOT_READY:=(State=C.NOT_READY);

(* Go to FAULT condition *)
FAULT:=(MCC_TOL);

Page 5
 State Machine Design and Implementation in IEC 61131 Languages

(* START OUTPUT *)
RUN:=((State=C.STARTING) or (State=C.RUNNING));

Page 6
 State Machine Design and Implementation in IEC 61131 Languages

9. Functionality Driven by Transitions

In the case where it is desired to detect a transition in to or from a particular state, instead of identifying all
transition IF..THEN statements which lead to that transition it is possible to compare the “state” and
“new_state” before they are equalized at the end of the state machine solver.
e.g.

If (new_state<> state) then

If (new_state=C.FAULT) then
(*DO SOMETHING UPON ENTRY INTO THE FAULT STATE*)
End_if;
End_if;

10. Debugging Tips

At times a state may only live for one or a few scans of the PLC and be hard to detect by eye. In this case it
can be useful to create a debugging block which connects to the “state_text” output of the block and shows
the state history for the last 8 (say) states on 8 output pins, effectively giving a state history. The transitions
can also be time stamped or scan number stamped to give a better idea of what is going on.

11. Deployment of the STARTER block

Two examples of deployment have been shown below
1) Simple use with DOL starter. Note this MCC starter did not have READY or MCC_FAULT inputs so these
are set with a static TRUE.
2) Use of two STARTER blocks to implement a reversing starter, where each block’s object could be
considered to be the contactor – one for forward and one for reverse. This is an alternative to
defining a single state machine with reversing functionality.
Why would you do this? A number of reasons could occur:
a) If you only had one reversing starter in the program, it is possibly easier and less to manage to
just re-use the DOL starter in this manner as it decreases complexity over designing and
debugging a reversing starter.
b) In the case where the reversing starter has separate overloads for forward and reverse and you
may still wish to allow running in one direction when the other is faulted – this arrangement
decouples the forward and reverse state machines. This is an example where the starter schematic
arrangement influences the state machine design and implementation.

Page 7
Simple DOL Starter
 State Machine Design and Implementation in IEC 61131 Languages

Example of Using Starter Block For Reversing Starter

Page 1