This paper extends model-based diagnosis (MBD) \cite{deKleer87,Reiter87} to systems with hidden interaction faults. An interaction fault is present if an interaction among a set of components leads to an observable failure, even though each individual component individually meets the specifications. A naive approach to address interaction faults is to simply account for all possible interaction faults in the system model. However, the naive approach presumes that all possible faults, both component and interaction faults, are known and addressed in the model.

A variety of rule-based, model-based and datadriven techniques have been proposed for detection and isolation of faults in physical systems. However, there have been few efforts to comparatively analyze the performance of these approaches on the same system under identical conditions. One reason for this was the lack of a standard framework to perform this comparison.

This paper extends model-based diagnosis (MBD) (Reiter87,deKleer87) to systems which convert, move and process material. Examples of such systems are printers, refineries and food processing plants. Such plants present two challenges to model-based diagnosis: (1) the plant may process 100s-1000s of items per minute so retaining full details of behavior of all past objects is impractical, and (2) complex multi-way interactions can occur among components operating on the same object. We address the first challenge by synopsizing past behavior in a data structure of fixed size.

Diagnosing multiple-component systems is difficult and computationally expensive, as the number of fault hypotheses grows exponentially with the number of components in the system.

Today’s complex production systems allow to simultaneously build different products following individual production plans. Such plans may fail due to component faults or unforeseen behavior, resulting in flawed products. In this paper, we propose a method to integrate diagnosis with plan assessment to prevent plan failure, and to gain diagnostic information when needed. In our setting, plans are generated from a planner before being executed on the system.