Information Technology Reference
In-Depth Information
level. An (un)marked code block means that none/all instructions within the
code block have been marked as fault candidate by the debugging algorithm.
None of the debugging algorithms return a subset of the instructions within
a code block only.
The application of static analysis on the example is not very ecient.
That is, any path from the primary inputs ends at the observation point
ByteV alue
. All nodes are required for the computation of
ByteV alue
and
no node is prunable. As shown in Table 1, all diagnoses return all instructions
in the IL program as fault candidates.
Dynamic diagnosis is more accurate. The usage of the input stimuli in-
creases the accuracy and some code blocks are pruned (see Table 1). Each test
case activates different paths and the final diagnosis depends on the consid-
ered test cases. The final diagnosis with respect to a single fault assumption
for test case 1 and test case 3 returns code block (2), (3), and (4). The con-
sideration of all four test cases further prunes code blocks and returns code
block
as potential fault candidates only.
However, the cardinality of the fault is typically not known in advance and
using all test cases is often not feasible for models with a large number of
inputs. Additionally, any fix at
(2)
(the fault site) and code block
(4)
(4)
cannot fix the faulty behavior. The fault
candidates in code block
have not been proved to fix the faulty behavior.
The final diagnosis without any assumption on the fault cardinality returns
all code blocks as potential fault candidates and does not help for debugging.
Correction-based debugging is more accurate in comparison to the first
two analyses. Only fault candidates that fix the faulty behavior are returned.
Code block
(4)
is accurately determined to be not a fault candidate. The
results for each failure trace are more accurate and the final diagnosis with
respect to all test cases returns the block with the original fault site only. The
fault candidates are automatically of minimal cardinality and no assumption
on the cardinality of the fault has to be made.
(4)
4.2
Industrial Software
The debugging algorithms are further evaluated on six industrial programs
from the railway interlocking domain. The models have different complexity
and use Boolean operations (e.g. logical AND and OR), arithmetic operations
(e.g. 16-bit addition), and control flow statements (e.g. conditional jumps).
The number of instructions in the models are ranging from
22
833
to
and
23
10
31
themodelshaveupto
primary inputs,
primary outputs, and
state
variables.
A faulty implementation has been created by injecting a single fault man-
ually in the IL model, e.g. replacing an operator
A
with an
AN
. The failure
traces are obtained by applying SAT-based equivalence checking to a high
level specification (see [18]). In all cases, the diagnosis is performed with re-
spect to a single fault assumption and a randomly generated single failure
trace. Components on instructions level are considered.
