Information Technology Reference
In-Depth Information
automated debugging is the highlighting of potential fault locations to an en-
gineer to reduce the complexity for a subsequent manual debugging session.
Thus, fixing the faulty behavior remains a manual task to avoid unexpected
changes that may be introduced by methods that perform repairs automati-
cally [4].
Explaining debugging techniques compute traces that are similar to a
failure trace but fulfill the specification to explain the faulty behavior [10].
The difference between the execution of the correct trace and a failure trace
reveals potential fault candidates. Program slicing returns statements on the
path from a (faulty) observation point to the primary inputs. The analysis is
performed statically or dynamically with respect to the actual values of the
failure trace [22,2]. The techniques above do not fully exploit the expected
behavior at the observation points and an over-approximation of fault can-
didates may be returned only.
Model-based diagnosis is more precise by computing fault locations on
an abstract model [13]. Using a solver for
Boolean Satisfiability
(SAT) allows
to handle large problem instances due to the tremendous improvements in
Boolean satisfiability solving [5,12]. SAT-based debugging [17] partially au-
tomates the debugging by finding possible fault locations, i.e., components
that can
fix
the faulty behavior. The usability for complex models was shown
for debugging hardware [17] as well as software [9].
In this work we analyze methods for automated debugging of PLC pro-
grams. Three automated debugging methods are evaluated: (1) static analy-
sis, (2) dynamic analysis, and (3) correction-based debugging.
2
Diagnosis Model
In IEC61131-3 two textual and three graphical programming languages for
PLCs are standardized. In this paper we focus on the assembler-like language
Instruction List
(IL). More specifically,
Statement List
(STL) is the input
language of the PLC considered [16]. STL is similar to IL and is referenced
as IL in the remainder of this paper.
The behavior of an IL program is specified in
M
lines of code that are
sequentially executed in a deterministic order. Each line contains one instruc-
tion, composed of an optional label, an operator and an optional operand of
{
. The control flow is influenced by jump instructions, that
are referencing a label in line
r
,
variable, constant
}
1
≤
r
≤
M
. IL programs may be additionally
divided into sub-programs.
A CDFG is constructed from the IL program to perform automated de-
bugging. Nodes in the CDFG represent data instructions or control predi-
cates, respectively. Data dependency and the control flow are modeled by
edges.
An abstract model or a concrete model of the executing CPU of the
PLC can be used to construct the CDFG. Because a CPU consists of several
registers, stacks as well as accumulators the execution of an IL instruction
