The Unknown Mode

Back to Main Page

The Problem

A Livingstone model requires the modeler to enumerate the "modes" of each component in the model. Not only nominal (that is, normal or intended) modes but also failure modes must be modeled. To model a mode involves modeling the way the component enters and exits that mode.

It is possible -- in fact, probably inevitable -- for a model to be incomplete in that either it does not enumerate every possible failure mode, or it does not enumerate every possible transition into a modeled failure mode. Furthermore, it is possible that Livingstone not receive all Commands given to the device being modeled, so it loses track of the device's mode.

If this is the case, Livingstone may be unable to add assumptions to make the model consistent. This leads to Livingstone being unable to find any Candidates.

The Solution

Livingstone modelers have addressed this problem by adding to each multi-mode component a catch-all failure mode that, by convention, is called the "unknown" mode (though it doesn't have to be named that). A device that has only one mode (perforce a nominal mode) does not need to have an unknown failure mode.

For the catch-all "unknown" failure mode, there must be

• a clauseless transition into the catch-all "unknown" failure mode from any other mode, and
• a clauseless transition from the catch-all "unknown" failure mode to itself.

• any transitions out of the "unknown" failure mode, or
• any clauses that assert anything about the "unknown" failure mode.

The Ambiguity of Unknown

Having a component mode named unknown conflicts with the allowable Livingstone variable value of unknown. This is because the unknown value means that Livingstone could not determine which multi-mode proposition was true. To disambiguate this situation, the catch-all failure mode should be named something other than unknown, say unknownFault.

An Example

As an example, consider a device named "Thingamajig". Its nominal and identified failure modes are "modeA", "modeB" and "modeC".

Add the Catch-All Unknown Failure Mode

To the enumerated nominal and failure modes, add the catch-all "unknown" failure mode, here arbitrarily named "unknownFault":

    <ci:attributetype name="thingamajig.ModeType"
        members="modeA modeB modeC unknownFault"/>
    

Add the Transition into The Catch-All Unknown Failure Mode

There must be a transition into the catch-all "unknown" failure mode from any mode. To keep from inferring that this transition took place unless you have no alternative, keep the probability low. The keyword "unknownFailureRank" signifies the lowest probability, exp(-10).

    <ci:transition to="unknownFault" probability="unknownFailureRank" from="*" 
        name="intoTheUnknown"/>
    

Add the Transition to Remain in The Catch-All Unknown Failure Mode

There must be a transition from the catch-all "unknown" failure mode into itself. This Transition must have a Clause with an empty set of Terms.

    <ci:transition to="unknownFault" from="unknownFault">
      <ci:clause/>
    </ci:transition>
    

The Model Elements that Are Not There

Make sure there is no other Transition in which the catch-all "unknown" failure mode participates, and there is no Clause that asserts anything about the catch-all "unknown" failure mode. Thus the name of the catch-all "unknown" failure mode (in this example, "unknownFault") must appear exactly 4 times:

• Once in the attribute type for the modes
• Once in the transition into the catch-all "unknown" failure mode
• Twice in the transition to remain in the catch-all "unknown" failure mode

Side Effects

Adding transitions to "unknown" failure modes will increase the number of Candidate diagnoses that the Tracker finds. At best this is clutter; at worst, when only a small number of Candidates are allowed, these "unknown" Candidates displace more meaningful ones. The best policy is to give transitions to "unknown" failure modes very low probabilities. This way, the more meaningful Candidates, if any, will be returned first. The symbol "unknownFailureRank" was designed for this purpose.

Software Support

Currently, nothing in Livingstone or Skunkworks requires that components with multiple modes include a catch-all "unknown" failure mode. The Livingstone XMPL reader or the JMPL compiler could be modified to check for the existence of such a mode and possibly to insert such a mode when it is found to be absent.

In Stanley, beginning with release 2.7.1, when the user creates a new component, a catch-all "unknown" failure mode is automatically added with a name of unknownFault. Stanley will not allow the user to name a new mode (ok or fault) unknown.

References

The IJCAI paper on the Sherlock system mentions unknown failure modes.

Johan de Kleer and Brian C. Williams. 1989. Diagnosis with Behavioral Modes, In Proceedings of the International Joint Conference on Artificial Intelligence, Detroit, MI, pp. 1324-1330; also in Readings in Model-based Diagnosis, Hamscher et al. eds., Morgan Kaufman, 1992, pp. 124-130.

Back to Main Page