Information Technology Reference
In-Depth Information
5.1 Informal Causality Analysis Examples
It can be easily verified that the trace shown in Table 3 satisfies the GPCA
safety property in Equation (1). Now we show the causality analyses via a series
of examples, based on variants of the trace observed in Table 3.
Example 1 (Faulty tasks, no system failure).
Given a trace as observed in Ta-
ble 3, with Event 12 missing. In this case,
PM
is faulty by not sending the stop
event. However the system property is not violated since the
AC
task detects
an empty reservoir message and alarms and stops the pump motor.
According to Step 1 of the causality analysis framework, there is no need for
subsequent causality analysis.
Example 2 (Single faulty task caused system failure).
Consider a trace where
only Event 1 and Event 2 in Table 3 are observed. In this case, the
PI
task
fails to move the bolus request event from Q1 to Q2, read by the
PM
task.
Subsequently the
PM
task does not perform any actions, since it does not know
thereisabolusrequest.Inthiscasethe
PI
task is faulty while
PM
is not.
Example 3 (Multiple faulty tasks jointly caused system failure).
Consider the
trace in Table 3 with Events 3-5 and Events 10-12 missing. In this case, the
PI
task is faulty by not moving the bolus request message to Q2. The
AC
task is
faulty by not delivering the alarm and stop events. However, replacing neither
the
PI
nor the
AC
task individually could make the system failure disappear.
Both
PI
and
AC
must be replaced with good ones for the system failure to
disappear.
Example 4 (Multiple faulty tasks, but only one caused system failure).
In the
example in Subsection 2.1, a trace with six events
(enq(Q1, bolus)
,
8500),
(deq(Q1, bolus)
,
8502), (enq(Q3, empty)
,
8503), (deq(Q3, empty)
,
8701),
(alarm
,
9760), (stop
,
9760)
{
is shown. In this example, both
PI
and
AC
are
faulty. However
AC
's faulty behavior would not have been triggered in the first
place if
PI
were not faulty, and thus should not be considered as a cause for
system failure. In the meanwhile, although it is the
PM
task's job to send the
start event, it should not be the cause of system failure in this case either since
it is not a faulty task: it does not receive the bolus request message in the first
place, due to
PI
's fault.
}
Example 5 (Multiple faulty tasks, but only one caused system property violation).
Consider the trace in Table 3 with only Events 1-9 observed. In this case, both
the
AC
and the
PM
tasks are faulty by not delivering the corresponding events.
In this case, if the
AC
task were not faulty, the system failure would disappear.
Examples 4 and 5 show the improvement in precision that we have achieved
using causality analysis: not all of the identified faulty tasks are the culprits for
the system failure. By ruling out the tasks which are not culprits, the subsequent
analysis for the system failure can be focused on the identified minimal culprits.
