We have to propose a method with definitions for each of the six components.
The goal that guides the choice for the * Cover*
and * NotContra* components is
* explanation-notion(standard)*, since the system contains knowledge that
standard entailment is most frequently used in diagnostic methods
(as opposed to the use
of non-standard variatons of entailment proposed in [ten Teije & van Harmelen, 1996a]). As a
result, we choose for both explanation relations (* Cover* and *
NotContra*) the
classical entailment relations ( and
respectively). The
other four components are chosen blindly.

In * Table 7* the definitions
of the components are briefly
described. In [ten Teije & van Harmelen,
1994] the definitions of some of these components
are given more formally.

**Figure 7:** The components of the proposed method.

The dynamic goals now become all the goals that have not already been
statically determined. In this case the only dynamic goal is
* max-number-diagnoses(2)*.

** Knowledge-verification**

One of the usual constraints on diagnostic methods is to demand that the
* Cover* component is at least as strong as the * NotContra*
component.
After all, if an observable is entailed by a consistent theory, then that
observable is also consistent with this theory.

The method described by term (3) does not
violate this
constraint. However, there is another assumption conflict, because *
#-min*
assumes that every cause has equal likelyhood. This means that the
knowledge-verification step has failed, and therefore a new propose step is
started.

** Propose**

We now propose another method. Because this step is still guided by
the same static
goal as before (* explanation-notion(standard)*), the method still
contains
as * Cover* definition and as * NotContra* definition.
The other components are again chosen blindly.
The propose method is now:

** Knowledge-verification**

As in `` knowledge-verification'' there
is no violation of
the constraint concering the * Cover* and * NotContra* components.
The other assumption-confllict also disappears because
does not assume equal likelyhood of causes. As a result,
in this case assumptions conflicts no longer occur.

** Simulation-Verify**

In this step the system performs diagnosis using the valid method of term (4). Based on the computed diagnoses it tests the dynamic goals.

Using the method of the term (4)
results in the following
and .
The vocabulary defined by * initial-fault-nodes* contains
all the initial nodes of Figure 6 that correspond
to fault-modes, plus
all the assumption-symbols .
Performing diagnosis results in ``no diagnosis'', which becomes
the verification result.

** Critique**

The reason for not finding any diagnoses is that there is
no explanation for * lights(yes)*: only incompleteness
assumptions ('s) and faults are part of
the vocabulary
(* initial-fault-nodes*), and a fault cannot explain the correct behaviour
of * lights(yes)* when we use
and for
* Cover* and * NotContra* respectively. This step determines that
a
possible suitable repair action is adapting the * Obs-mapping*.
This is so because a different * Obs-mapping* might require only
incorrect behaviour to be explained (as apposed to all behaviour, including
correct behaviour, as is the case withe the current definition, namely
* Obs-mapping=abd-mapping*).

** Modify**

The modify step must now repair the component specified by the critique step.
The repair action is determined by first generating a set of variants of the
* Obs-mapping*, and then applying two filters on this generated set of
* Obs-mapping* definitions.

** generate**: generate variants of
the * Obs-mapping* component.

We require that any solution of the method using the original *
Obs-mapping* is
also a solution for the adapted method with the new * Obs-mapping* (after
all,
we want to increase the set of solutions). This relation is expressed in the
predicate * subset-Es(Old,New)*. It denotes that the explanations
generated
by a method with * Obs-mapping*-component * Old* are also generated
by a method
with * Obs-mapping*-component * New*, provided all the other
components remain
the same. In this generation step we generate those * Obs-mapping*
definitions which satisfy * subset-Es(abd-mapping,New)*:

For our problem, the system generates the following set based on its
factual knowledge of * subset-Es*:

The complete definitions of these * Obs-mapping* components are in
[ten Teije & van Harmelen, 1994], but
in sloppy notation these definitions are
given in table 8.

**Figure 8:** denotes
the possible observable values, and * OBS* denotes the
currently given observations

The generated set of * Obs-mapping* definitions is now:

* {cbd-mapping,nor-abnorm-mapping,polarity-mapping}*

because * subset-Es(abd-mapping,New)* holds for these elements.

** :** of all the possible candidate repairs, we prefer
the variants that are the ``closest'' to the original * Obs-mapping*
component:

We define ``closest'' as those * Obs-mapping* definitions whose set
is (1) in any case no superset of the original set (since we do not
want to explain more observable values strongly) and (2) is not a subset of
another possible set (since we want to
delete as few observable
values as possible).

The predicate
* closest-Obs-mapping* is therefore defined as follows, whereby
denotes that the * Obs-mapping*
* X* gives an
set that
is a subset of the set computed by the
* Obs-mapping* * Y*.

We filter the set based on the following factual knowledge of :

This factual knowledge, just as the knowledge in (5),
is stored as given facts in our system. However, given sufficiently
powerful theorem-proving techniques, it would be possible for the system
to automatically derive these facts from the definitions in table
8.
From these definitions, it follows that * closest-Obs-mapping* holds for
the
* Obs-mapping* definitions * polarity-mapping* and *
abnormality-mapping*. The
FilteredSet is therefore:

** :** We now filter those variants which result in the
same solutions as the original method in the current case. In this filter the
system executes a part of the diagnosis, namely the * Obs-mapping*
definition.
The results of the possible * Obs-mapping* definitions have to be computed
and
compared with the outputs of the original * Obs-mapping*. Those which
give the
same and will be deleted from the set. In contrast
with , this filter is specific for the
current problem on hand,
whereas the was independent of the
problem.

Applying the * Obs-mapping* definitions from (6)
to * OBS={light(yes),engine-starting(no)}* gives the following
values for and :

We see that the * Obs-mapping* with value
* polarity-mapping* gives the same sets as the original *
Obs-mapping*
(which had value * abd-mapping*). The * Obs-mapping*
with value * abnormality-mapping* gives other
sets. This results in a FilteredSet where the only * Obs-mapping* is
* abnormality-mapping*.

The modify therefore results in the method:

The originally proposed method of term (4)
could not handle
observed behaviour that was correct behaviour. The above critique-&-modify
step tried to recover from this shortcoming by adapting the * Obs-mapping*
component, resulting in the method from term (11). The next
step is to verify the adapted method.

** Knowledge-verification**

The knowledge verification still succeeds, since the * Cover*-,
* NotContra*- and * Selection*-components and the assumptions have
not changed.
(see `` Knowledge-verification'')

** Simulation-verification**

Again we perform diagnosis, but now using the modified method of term (11). Performing diagnosis results in the following diagnoses:

Unfortunately, the test whether the dynamic goal
* max-number-diagnoses(2)* is satisfied fails. This means we have to
perform
another critique step.

** Critique**

In the verification step the problem of too many solutions was recognized. A
repair action for this problem is a modification of the * Selection*
component.
If the new * Selection* component is a stronger filter, then less
diagnoses will
be left. The system uses the knowledge that constructing the conjunction of
the current * Selection*-component with an additional selection criterion
will
have this effect.

** Modify**

The repair action of configuring the new * Selection* criterion is
executed in
this step. In our case the * Vocabulary* (* initial-fault-nodes*)
contains
faults and incompleteness-assumptions.
We can therefore eomply a selection-criterial that prefers explanations which
are subset-minimal in the incompleteness assumptions
(). The proposed * Selection*
criterion then becomes
`` ** and** ''.

The adapted method is:

The proposed method from (11) resulted in too many diagnoses. The above critique and modify steps tried to recover from ``too many diagnosis'' and have modified the method. This modified method now has to be verified.

** Knowledge-verification**

The knowledge verification still satisfies, as before ( also does not violate the unequal-likelyhood assumption).

** Simulation-verification**

Again we perform diagnosis using the modified method of term (9). Performing diagnosis results in the following diagnosis:

Checking this against the dynamic goal shows that we have now also
satisfied * max-number-diagnoses(2)*.

We have now (finally!) solved the original diagnostic problem
specified in (2).
The method of term (9)
has explained the observations
* {engine-starting(no),lights(yes)}* under the assumption
``the causes are different in likelyhood'' for the desired goals
``use a standard notion of explanation''
and ``at most two alternative diagnoses are allowed''.
The sole computed diagnosis is (14).

During this diagnostic problem solving process the configuration system has had
to recover from the initial inability to deal with correct behaviour (by
modifing the * Obs-mapping* component) and it had to recover from ``too
many
solutions'' caused by too weak a selection filter (by modifying the *
Selection*
component).

Fri Oct 4 13:40:35 MET DST 1996