From: AAAI Technical Report FS-92-03. Copyright © 1992, AAAI (www.aaai.org). All rights reserved.
Consistency.based
Diagnosis
and Design
Peter Struss
University of Technology, Orleansstr. 34, W-8000Munich, Germany
e-mail: struss@informatik.tu-muenchen.de, ph." (..49) 89 48095 123
Our research background lies in qualitative, non"diagnosis
of (preliminary)
designs".
Thisidea
monotonic, and model-based reasoning with a focus
intriguing,
butit is worthwhile
exploring
howfarit
on the application to diagnosis of technical systems.
carries.
In particular,
we have been following
the
First,
onlyearlier
stages
ofthedesign
process
maybe
consistency-based
approach which considers
supported
by applying
consistency-based
diagnosis,
diagnosis as the task of finding an assignment of
guaranteeing
that it is possible
to satisfythe
modes(correct or faulty), MA,to a set of components specification:
which is consistent with the system description, SD,
SD U SPECSU IMPLis consistent.
and the observations of the actual system behavior,
Ultimately, the design has to derive the
specification.
This corresponds
to applying
the
OBS:
criterion
ofabductive
diagnosis:
SD U OBSU MAconsistent.
As a special line of research, we have developed a
SD U IMPL t- SPECS
theory and methods for using multiple models of
Thesecond
issueconcerns
thenature
of thebehavior
components in consistency-based diagnosis. This
modeassigned.
In contrast
to diagnosis,
theydo not
does not only include models at different levels of
capturethe potentialfault behaviorsof the
abstraction, but also approximate models, or, more components
(unless
simulating
theeffects
offailures
generally, models based on simplifying assumptions
is partof thedesign
task),
butdifferent
choices
for
that mayhave to be retracted ([Struss 92]).
implementing a component. Consistency-based
Our interest is to explore possible links to the task of
techniques can identify sets of choices that are
designing artifacts in at least two ways.
conflicting with the specification and, thus, indicate
One issue in diagnosis, in particular whencombined candidates for changes in the design.
with the repair task, is representing and exploiting
This reveals the third, and most serious feature of
teleology. So far, the model used for diagnosis
the approach: it restricts
the possible design
describes the (physical) behavior of a device, but not
variations to choosing different realizations of
components in a fixed structure. What appeared to
the purpose this behavior implements. Although
theimportance
of teleological
reasoning
hasbeen be a plausible assumptionin the context of diagnosis,
recognized
early,thereis littleto graspat the namely minimality, locality and independence of
present
time.Representing
thepurpose
of a system violations of the original model, establishes stronger
andhowit is supposed
to achieved
thispurpose
is limitations for design. The diagnostic approach
obviously
central
to thedesign
process.
Diagnosis seems to be applicable to routine design where the
and repair would benefit from models and
general structure is given, but the right types of
information
emergingfrom designsystems.From components and/or their parameters have to be
chosen. Even in this case, however, changes maybe
current CAD systems, however, at most the
structural
description
maybe extracted,
butnot non-local, since the choice of the particular
behavioral
models,
leavealonea representation
of componentmay have an impact on others.
the purpose.
Special design tasks the diagnostic techniques might
be ready to support, are design for diagnosibility and
Our approach to diagnosis suggests a way to build
sensor
placement
as faras givenstructures
areto be
knowledge-based design systems. We regarded
analyzed.
Fortaskscloserto innovative’
design,
diagnosis as a process of finding a model of the
artifact in its current state that is consistent with the
wherethe structure
is to be found(i.e.in our
behavior we observed. A formulation of the design
approach
SD issubject
tobelief
revision),
theydo not
problemis to find a modelof an artifact that entails
suffice.
the behavior we would like to observe, i.e. its
specification. Hence, a possible approach would be
[Struss 92a] Struss, P. What’s in SD? Towards a
to replace
the observations,
OBS, by the
Theory of Modeling for Diagnosis. In: Hamscher, W.,
specifications,
SPECS, and the mode assignments,
de Kleer, J., and Console, L. (eds.), Readings
MA,by different possible implementations, IMPL. Model-based Diagnosis, Morgan Kaufmann, San
Then, we could organize the design process as
Mate), 1992.
146