Static Analysis of Sequential Function Charts using
Abstract Interpretation
Hendrik Simon, Stefan Kowalewski
Embedded Software Laboratory, RWTH Aachen University, Aachen, Germany
Email: lastname@embedded.rwth-aachen.de
Abstract—In this work we present an abstract interpretation
based static value set analysis method tailored for Sequential
Function Charts (SFCs). Translation based approaches that
transform SFCs into different presentations - and thus loosing
the structure - have shown to be imprecise for this language.
Our approach thus keeps the SFC structure and additionally
provides value sets as entry-and exit information for each set of
possibly active steps in the SFC. Further, analysis information
for actions connected to the steps is provided, to allow for
in-depth debugging. Beside value set information, our analysis
does structural checks and, hence, is able to generate warnings
for erroneous SFC behaviour, as specified in the IEC-61131-3
standard. As some semantic aspects for SFCs are left open in
the standard specification, our analysis adopts the CODESYS
semantics.
I. Introduction
A. Approach
Sequential Function Chart (SFC) is one of the graphical
programming languages for Programmable Logic Controllers
(PLCs) and is defined in the IEC-61131-3 standard. Since
PLCs are often used in industrial, safety-critical environments,
the software running on them has high quality requirements
regarding correctness and safety. Although thorough testing is
mandatory, only an under-approximation of the real program
behavior can usually be tested. On the other hand, over-
approximating methods like static analysis can yield clues,
which code fragments to test or which instructions are safe.
Static analysis is a well understood method to check for
software failures and detect implementation flaws. Analysis
results can directly point out errors, or greatly support engineers
in the process of debugging.
A common method for static analysis is to translate PLC
programs into a more generalized representation, to make
general analyses possible. While working well on textual
languages [1], the loss of crucial structural elements renders
this approach infeasible for languages as SFC. The loss of
structure leads to a broader over-approximation during analysis,
resulting in less useful warnings.
Besides static information about the code, in the domain of
SFCs one is also interested in properties of the code’s structure.
The IEC-61131-3 [2] defines several SFC behaviors that are
undesirable, and thus should be tackled by a static analysis as
well.
B. Contribution and Outline
The contribution of this work is twofold. First, we developed
a structure-preserving static analysis for SFCs, in order to
generate precise results and provide information about possibly
c 2016 IEEE
978-1-5090-1314-2/16/$31.00
regarding deterministic behavior [10], our analysis adheres to
Authorized licensed use limited to: Universidad de los Andes. Downloaded on June 10,2020 at 21:32:49 UTC from IEEE Xplore. Restrictions apply.
undesired SFC behavior. To this end, we will utilize a reacha-
bility graph model that we enrich with value set information
before and after each state in the graph. We utilize abstract
interpretation [3] for an efficient calculation of value sets of the
program’s variables. Rather than translating the whole program
into one big control flow graph (CFG), we generate separate
CFGs for each action and are thus able to additionally provide
analysis results for the source code inside actions in the SFC.
Second, through the noted enhancements, we want to broaden
the range of languages in which static analysis can be effectively
used for PLCs in practice.
II. Related Work
Static analysis has been successfully applied to the field
of PLCs, with Arcade.PLC [1] being a tool developed at our
department chair. Besides, static analyzers exist in commercial
tools as well, e.g. in CODESYS, implementing rather syntactic
and only few semantic checks. While handling textual languages
well, several limitations were found in Arcade.PLC regarding
SFCs.
SFCs have been introduced in 1993 in the first version of
the IEC-61131-3 standard [2]. The language design is based on
the GRAFCET specification developed in 1988 [4]. The IEC-
61131-3 norm defines different types of erroneous SFC behavior,
for which analyses were provided in [5]. These analyses are,
however, not complete, which gives rise for new algorithms.
One early approach was done in [6], utilizing a subclass of
petri nets. Their algorithm is, however, restricted to detecting the
unsafe and unreachable behavior. Another petri net related work
was presented in [7], lifting the petri net semantics to so called
sensor-based stage petri nets, adapting the reactive behavior of
PLCs. A similar approach translating SFCs to timed petri nets
was developed in [8]. Both approaches are restricted to petri-net
analyses and can thus only retrieve structural information as in
[6].
Arcade.PLC [1] on the other hand offers a translation of
SFC’s into an intermediate representation that is analyzed using
abstract interpretation [9]. During the translation, however, struc-
tural information is lost, which implies two major drawbacks.
First, the loss of structural information makes it impossible
to detect erroneous behavior as specified in the IEC-61131-3
standard. Second, the analysis results themselves get less precise
due to the loss of structural information. Hence, our approach
aims at both, providing precise information about variable
values and allowing for structural checks. This is achieved
by creating a reachability graph of the SFC on the fly, while
providing sound pre-and post information for each reachable
state. Since the IEC-61131-3 definition is rather ambiguous
 NOERROR R ring_bell 1:
2:
procedure SFC_StaticAnalysis
pre, post : SFC_States → (VAR → P (VAL))
3: pre ({initstate}) ← ι
4: W C {initstate}
5: while W not empty do
errorOccured 6: C ← W.poll
7: pre (C) ← SetCallParameters (pre (C))
ERROR S ring_bell 8: for each predeccessor P of C do
9: Q ← getActions (P, C)
10: result ← executeActions (Q, pre (C))
11: post (C) ← post (C) ∪ result
fixed AND NOT errorOccured 12: for each successor S of C do
13: T ← applyTransition (post (C))
14: pre (S ) = pre (S ) ∪ T
15: W C S , if post (C) changed
Fig. 1. A simple SFC consisting of the two steps ERROR and NOERROR
Fig. 2. High-level description of our static analysis
with associated actions as well as two transitions with guards.
active or will be active in the next cycle, respectively. Further,
a variable step.T denotes for each step, how long it is currently
the CODESYS semantics.
active, or was active the last time. Beside the action qualifiers
III. Preliminaries defined in the IEC-61131-3, we adopt the following three
Sequential Function Chart (SFC) is a graphical language for CODESYS qualifiers:
programming PLCs and is especially designed for structuring • Execute while active
sequential or parallel programs. SFCs are represented by a • Execute on activation
graph structure comprising steps and transitions, similar to a • Execute on deactivation
petri net. Steps in an SFC represent states of a program that
trigger certain behavior in a customizable way. Transitions on Being a convenient addition to the existing ones, these qualifiers
the other hand represent state changes that may occur when allow multiple executions of one action in a single cycle, which
certain conditions hold. An example SFC with inputs fixed, is not possible with the definitions from IEC 61131-3. We will
errorOccurred and output ring_bell is depicted in figure 1. further refer to actions related to a CODESYS qualifier as CS
This program controls an alarm bell, which should ring if an actions.
error occurs and turn the bell of as soon as the responsible The execution of CS actions complies to a total order of all
problem is fixed. Steps with their corresponding actions are steps (top to bottom, left to right), resulting in a deterministic
denoted as labeled boxes, the initial step being distinguished program behavior, which is indispensable for our analysis. All
by its double-lined border. Transitions are represented as small other actions are executed in lexicographical order. A complete
bars, their guard being located right of the bar. Each action cycle with all features names so far is structured as follows:
is typically enriched by a qualifier, specifying how this action 1) Execute CS on deactivation actions
is triggered. In figure 1 e. g. the action ring_bell is attached 2) Execute CS on activation actions
to two different steps with qualifiers R, S (reset, set). Although 3) Execute CS while active actions
the transitions in the example have only one source-and one 4) Copy value of step._X to step.X
target step, transitions may have multiple of those. 5) Execute IEC 61131-3 actions
The general execution of an SFC is structured as follows. In 6) Fire transitions
each cycle of the PLC, all states that are active are processed, Note that also step 6 follows the total order mentioned above,
starting with the initial step being the only active step. Whenever resulting in a deterministic behavior in case of multiple firing
a guard can be evaluated to true and all source steps are active, transitions. In order to finally decide, whether an action
all target steps are set to active, while the source steps are given its qualifier is executed, each step is connected to an
deactivated. In this case, we say that the according transition Action_Control function block, adhering to the with final scan
fires. semantics defined in the IEC-61131-3 [2] to be consistent
The high-level structure and execution being outlined, we with CODESYS. In this setup, the step.X variable of each
will now focus on details and design decisions we made for step is connected to the input of the Action_Control block
our analysis. Since several aspects concerning deterministic corresponding to the specified qualifier. Based on this input
behavior are left open by the IEC-61131-3 standard, we choose the action is executed if the Output A of the Action_Control
to adhere to the CODESYS specific implementation. Two block holds the value true.
examples are the non-specified order of firing transitions or
executed actions. With CODESYS being a well established IDE, IV. Direct Static Analysis
we therefore comply with their design decisions concerning In this section, we will present and discuss the direct static
these SFC behaviors and will introduce the necessary details analysis algorithm in detail and start with a brief explanation of
in the following. some of our design choices. Although our presentation in this
First of all, the program is equipped with variables step.X section focuses on a value set analysis, the shown algorithm is
and step._X for each step, representing that a step is currently a general framework and can be used for different analyses with

Authorized licensed use limited to: Universidad de los Andes. Downloaded on June 10,2020 at 21:32:49 UTC from IEEE Xplore. Restrictions apply.
 1: procedure getActions(predecessors P, currentState C)
2: Q←∅
3: for each p ∈ P \ C do
4: QC CS exit action of p
5: for each c ∈ C \ P do
6: QC CS entry action of c
7: QC special action for copying step active variables
8: for each c ∈ C do
9: QC CS active action of c
10: for each action a do
11: execute ACTION_CONTROL block A of a
12: for each A with false ∈ A.Q and true ∈ A.A do
13: QC corresponding action a
14: for each A with true ∈ A.Q and true ∈ A.A do
15: QC corresponding action a
return Q
Fig. 3. The getActions procedure used during analysis
different domains. Our goal is to directly model the transition
structure of the SFC, which means that our analysis will work
on a corresponding state graph. However, since we can be in
several steps at a time, we will model the SFC via a reachability
graph on the power set of all steps.
A. Main algorithm
Let S denote the set of states in the reachability graph.
Analysis information is stored for each state s ∈ S as pre-and
post-information, representing variable values before and after
the steps in s being active, respectively. Information retrieved
by the analysis is of the form s → (VAR → P (VAL)), with
VAR denoting the set of all variables and P (VAL) denoting the
abstract domain for the values – a simple set in our example.
The main procedure of the static analysis is illustrated
in figure 2 and represents a standard worklist algorithm,
propagating analysis information through the reachability graph
until a fixpoint is found, i. e. until variable values do not
change anymore upon further iterations. The reachability graph
is created on-the-fly, as some states might be unreachable,
depending on the calculated value sets. We use the symbols
"←" as an assignment to a value and "C" as an append operation
to a list. First of all, the initial information ι containing
initial variable values is assigned to pre ({initstate}), while
{initstate} itself is appended to the worklist W. In each worklist
iteration, the current state C is processed. As a transition in
the state graph represents one cycle of the PLC, input values
have to be set as a first step. This is done by applying the
function SetCallParameters to the information at pre (C). This
function either sets inputs to specific values, assuming that
the call context for the analyzed SFC is known, or assigns
a suitable top element > to all inputs. Note that since we
access pre ({initstate}) this way in the first iteration, we have to
introduce an artificial empty predecessor of {initstate}. Further,
note that a state may be its own predecessor, representing the
case that no transition can fire.
The remainder of the algorithm represents the actual
transformation of pre (C) into post (C). First, all actions that
might have been executed on the transition from a predecessor
P to C are collected using the getActions function (Fig. 3),
which will be explained shortly. Secondly, all gathered actions
are applied to pre (C) in order (figure 4). Finally, the results
Authorized licensed use limited to: Universidad de los Andes. Downloaded on June 10,2020 at 21:32:49 UTC from IEEE Xplore. Restrictions apply.
1: procedure executeActions(Q, I)
2: S ←I
3: while Q not empty do
4: a ← Q.poll
5: if a definitely executed then
6: S ← a(S )
7: else
8: S ← S ∪ a(S )
return S
Fig. 4. The executeActions procedure used during analysis
are merged into post (C).
After the application of actions, it merely remains to
determine, which transitions may fire next, i. e. determining
the successors of C that have to be added to the worklist. This
is done in lines 12 – 15. First, the transition guard is applied
to a temporary copy of post (C), restricting values of variables
occurring in the guard accordingly. This information is then
merged with pre (S ). A successor S is then only added to the
worklist, if post (C) changed. As stated before, a state might
be its own successor, if all outgoing transitions can possibly
not fire, which would result in a self-loop in the graph. Thus,
if there is one transition that definitely fires, no self-loop is
generated instead. We will now briefly discuss the functions
getActions and executeActions.
The getActions function(Fig. 3) determines, which actions
have to be executed when traversing from predecessor P to the
current state C and stores those actions in an ordered list Q. The
order corresponds to the one discussed in section III. CS entry-
and exit actions are inserted first, followed by a special action
that copies the step active variables. This special action updates
the active steps and allows us to choose the correct CS active
actions afterwards. For all non-CS actions, the corresponding
Action_Control is executed. Corresponding actions for each
Action_Control block where the Q output can be false and A
can be true are added to Q first, representing the final scan
semantics. After that, actions for blocks with Q and A both
possibly true are added to Q.
The executeActions function takes an ordered list of actions
Q and analysis information I. Each action is then applied
in order. Due to the over-approximation of the analysis, we
have to distinguish between cases where an action is definitely
executed, and cases where an action may be executed. If an
action is definitely executed, we can directly apply the action
to the analysis information. On the other hand, if an action
may be executed, the application of it to the information has
to be merged into the current information S in order to keep
the analysis sound.
The application of an action a to analysis information S ,
denoted by a(S )(e.g. line 6) invokes abstract interpretation of
a in the style of Arcade.PLC [9]. This implies a construction
of a control flow graph for the action itself, through which the
information is propagated.
B. Properties of the algorithm
The presented technique is able to statically compute pre-
and post information for each state of an SFC, i.e. a set of
currently active states, in a sound fashion. That implies a
construction of the reachability graph, which itself might be
valuable information in the process of debugging. Due to the
abstract interpretation done during application of an action

Fig. 5. The reachability graph resulting from the static analysis on our
example SFC.
State errorOccurred fixed ring_bell
pre ({NOERROR}) {true, false} {true, false} {true, false}
post ({NOERROR}) {true, false} {true, false} {true, false}
pre ({ERROR}) {true, false} {true, false} {true, false}
post ({ERROR}) {true, false} {true, false} {true}
TABLE I. Analysis results for the example SFC.
to analysis information, the algorithm additionally generates
warnings for the code inside the actions. Thus, our technique
provides valuable information on action level, as well as SFC-
structure level.
Warnings specified by the IEC-61131-3 can directly be
deduced from the analysis results, too. A state graph containing
a state without outgoing transitions indicates that the SFC is
"unreachable". If a transition activates an already active step,
we can mark the SFC as "unsafe". This property is, however,
not directly provided by the structure of the graph, but deduced
from the value set results. Finally, during the construction of
the reachability graph we can check for multiple time-related
qualifiers connected to the same active action. According to
the IEC-61131-3, we also provide a warning in this case.
V. Evaluation
In this chapter, we will briefly evaluate the presented
approach on our example in Fig. 1. The reachability graph
generated by our analysis is depicted in figure 5 and the analysis
results are listed in table I. Note that due to errorOccured
and fixed being inputs and thus nondeterministic, they are
always assigned the > value of the domain – {true, false}
in our case. Although the results represent a rather broad over-
approximation, we can conclude that the ring_bell variable
can only be true after the ERROR action was performed,
which is the expected behavior. Due to the with final scan
semantics, however, we can not detect that the same variable
has to be always false after executing NOERROR, since
in a final scan, the action in the ERROR step is executed,
forcing the analysis to over-approximate. Analyses on further
examples indeed have shown that the with final scan semantics
leads to a necessarily broader over-approximation in most
cases. Note that the use of CS qualifiers can often alleviate
this problem, since execution then does not depend on an
ACTION_CONTROL block anymore, avoiding the final scan.
Using CS entry qualifiers for the actions in our example e. g.
yields the more precise result, stating that ring_bell is always
false at post (NOERROR).
The calculated value sets are still more precise than the
results obtained by translating the SFC to the intermediate
representation of Arcade.PLC and performing the analysis on
the resulting control flow graph. We thus conclude that the
preservation of the SFC-structure in our approach positively
influences the overall analysis precision. Finally, the use of CS
Authorized licensed use limited to: Universidad de los Andes. Downloaded on June 10,2020 at 21:32:49 UTC from IEEE Xplore. Restrictions apply.
qualifiers – if applicable – can support the analysis to provide
better results to the user.
VI. Conclusion
In this work we have presented a possible framework for
abstract interpretation of SFCs. Our approach can generate
warnings according to the IEC-61131-3 standard and generate
possible variable values before and after a reachable set of
steps. Further, our analysis also provides value set information
inside actions. The retrieved analysis results are more precise
compared to a non-structure-preserving approach. To the best
of our knowledge, the presented approach is the first to capture
structural and value-set information in a single analysis. In
follow-up research, we want to evaluate the usefulness of the
presented technique on industry size code examples. To this
end, replacing the in-built CODESYS semantics with a more
general one [10], would allow for a broader range of available
programs.
There are several possible improvements that we leave for
future work. The current implementation uses widening to speed
up termination of the abstract interpretation. However, there is
yet to find a suitable narrowing algorithm in order to utilize loop
invariants, yielding more precise results. Information retrieved
from other analyses, e.g. a live variable analysis, can further
reduce the runtime of the algorithm, as stated in [9]. These
analyses, however, have to be adapted to our reachability graph
model first. As a future application, it would be interesting to
integrate our approach into an existing IDE, in order to allow
for easy access and usage of the analysis during development.
References
[1] S. Biallas, J. Brauer, and S. Kowalewski, “Arcade.PLC: A Verification
Platform for Programmable Logic Controllers,” in Proceedings of
the 27th IEEE/ACM International Conference on Automated Software
Engineering (ASE), 2012, pp. 338–341.
[2] International Electrotechnical Commission, IEC 61131-3: Programmable
Controllers — Part 3: Programming Languages. Geneva, Switzerland:
International Electrotechnical Commission, 2003.
[3] P. Cousot and R. Cousot, “Abstract interpretation: A unified lattice
model for static analysis of programs by construction or approximation
of fixpoints,” in Conference Record of the Fourth Annual ACM SIGPLAN-
SIGACT Symposium on Principles of Programming Languages. ACM,
1977, pp. 238–252.
[4] International Electrotechnical Commission, IEC 60848: GRAFCET spec-
ification language for sequential function charts. Geneva, Switzerland:
International Electrotechnical Commission, 1988.
[5] ——, IEC 61131-8: Programmable Controllers — Part 8: Guidelines for
the application and implementation of programming languages. Geneva,
Switzerland: International Electrotechnical Commission, 2003.
[6] A. Karatkevich, M. Adamski, and M. Wegrzyn, “Rapid correctness
analysis for sequential function chart,” in Proceedings of the 45th
International Scientific Colloquium, IWK, 2000.
[7] S. Peng and M. Zhou, “Design and analysis of sequential function charts
using sensor-based stage petri nets,” in Systems, Man and Cybernetics,
2003. IEEE International Conference on, vol. 5, 2003, pp. 4748–4753
vol.5.
[8] N. Wightkin, U. Buy, and H. Darabi, “Formal modelling of sequential
function charts with time petri nets,” IEEE Trans. Contr. Sys. Techn.,
vol. 19, pp. 455–464, 2011.
[9] S. Biallas, S. Kowalewski, S. Stattelmann, and B. Schlich, “Efficient
handling of states in abstract interpretation of industrial programmable
logic controller code,” in Proceedings of the 12th International Workshop
on Discrete Event Systems. Cachan, France: IFAC, 2014, pp. 400–405.
[10] N. Bauer, R. Huuck, B. Lukoschus, and S. Engell, A Unifying Semantics
for Sequential Function Charts. Berlin, Heidelberg: Springer Berlin
Heidelberg, 2004, pp. 400–418.