Technical University of Munich, Department
of Computer Science
Model-based Diagnosis for Industrial Applications
Technical University of Munich
Dept. of Computer Science
Orleansstr. 34 D-81667 München,
OCC'M Software GmbH
Powerful Systems for Automated Diagnosis - Urgently Needed
The task of diagnosing technical systems becomes increasingly
challenging. Their complexity is growing rapidly, and so is the complexity
of the task to identify and remove the causes of malfunctions. This holds
for all types of systems, production plants, communication networks, transportation
systems, but also for consumer products. At the same time, the potential
impact of malfunctions grows considerably in terms of costs entailed, threats
to human health, and destruction of the environment. In many cases, the
capabilities of human operators, users of such systems, maintenance staff
etc. do not catch up with this development. Modern ships perfectly illustrate
these three aspects: complex systems with tremendous effects in case of
an accident are operated by a dramatically reduced crew with limited technical
skills. As a result, powerful systems that are able to support or automatically
perform the diagnostic process are urgently needed.
The Hardware Basis Is Available
For many, if not most, devices that pose serious diagnosis
problems, the computing power is already available or will be in the near
future. PCs are or can be used within repair shops. Moreover, many devices
carry their own processors, usually for control purposes. This is not only
true for large systems, such as ships or production lines, but also for
small devices and consumer products like photocopiers, cars or cameras.
Shrinking in terms or size and price and expansion in terms of memory and
speed allows to equip a broad range of technical systems with a hardware
basis for diagnosis software to run on-board. Advances in networks and
telecommunication open another possibility: solutions can be found even
though the subject of the trouble may be quite distant for the available
diagnosis knowledge: the mechanic in the workshop can be connected to a
diagnosis server via internet, or a car can transmit data to a service
center and receive instructions. So, everything is prepared for the exploitation
of advanced computer systems for on-board, off-board and remote diagnosis,
What is Missing: the Advanced Diagnosis Software
Of course, there already exist on-board diagnostics, for
instance, on control units of various car subsystems, but they deliver
a symptom rather than a diagnosis; fault localization and identification
starts with the symptom. Also, there are systems available for certain
devices, again, such as cars, that guide a technician in diagnosis based
on predefined decision trees. But all existing solutions fail to meet the
challenge we discussed above. They are hand crafted software programs (or
decision trees) targeted to very special types of devices or even individual
ones. There are no diagnostics for the diesel injection system, but for
EDC7.11 for an Audi type X, Variant Y, year 1996, etc. Producing the variants
of diagnosis systems for all variants of the devices under consideration
is a costly process, often not feasible because of the sheer number of
variants, and too costly in cases where it might be feasible in principle.
As a result, a fundamental, inevitable requirement for almost all industrial
a solution to the variant problem. Approaches to diagnosis
that require the input of a set of pre-defined associations between symptoms
(or, more generally, observations) and potential faults do not provide
a solution, because such associations have to be established for each variant.
Decision tree-based systems as well as rule-based diagnosis belong to this
class. At a technical level, what is needed to solve the problem, is a
methodology that allows to automate the derivation
of links between symptoms (observations) and faults. With the perspective
of diagnosis tasks as sketched above, the scope is not only expanded in
terms of types of devices and their variants, but also with respect to
the scenarios in which diagnosis is performed. In particular on-board diagnosis
robust and flexible solutions that cover a broad
range of external conditions, symptoms and faults some of which may
be difficult or impossible to anticipate (e.g. multiple faults). Again,
approaches assuming the existence of symptom-fault associations
based on human experience fail to address this issue: their coverage is
limited to exploiting known symptoms of known faults in well-experienced
devices (in order to know the associations).
The Essence of Model-based Diagnosis
The technology at model-based systems addresses these issues
and provides the solid foundation for the future generation of automated
diagnosis systems. What enables humans to effectively and efficiently solve
diagnosis problems even when they have to deal with new devices and unanticipated
symptoms and, hence, cannot simply draw upon previous cases and experience?
It is their capability to apply general, principled knowledge, namely knowledge
Based on this knowledge, the diagnosis process is guided
by reasoning about how to collect more information about the device (e.g.
by probing, testing and direct inspection) in order to discriminate among
competing diagnosis hypotheses. Model-based diagnosis systems work exactly
the same way: They do not require a pre-specified set of symptom-fault
associations, which will always be incomplete, limited, and expensive to
maintain. Instead, they are based on an explicit representation of the
principled knowledge that allows to derive such associations automatically.
The crucial modules of a model-based diagnosis system are
the (intended) behavior of the constituents of the
device (e.g. the components of a circuit) and
the structure of the device, i.e. how the constituents
are connected for interaction.
The library captures the knowledge specific for a
particular application domain, say mechatronic car subsystem or
electrical circuits; its model fragments can be re-used for the class of
devices in this domain. The structure description is the (only)
device-specific element. It allows to automatically generate a device
behavior model using elements form the library (see Fig. 1). This is, besides
the observations, the input to the diagnosis algorithm which is
general and domain-independent and, hence, can be reused across
several application domains.
Fig. 1: Generation of Diagnostic Systems
a library of component behavior models, capturing
the intended, correct behavior and possibly the behavior under relevant
a description of the device structure in terms of
components represented in the library and their interconnections.
an algorithm for generating diagnostic hypotheses
from a comparison of the model with observations of the actual behavior.
In a nutshell, a diagnosis system of this type works as
These key principles are fairly basic and straightforward.
Nevertheless, they provide the foundation for diagnostic systems that are
truly revolutionary in two respects.
Observations of the actual behavior are entered.
The device model (of the circuit behavior) computes
conclusions about system parameters and variables (observed and
If a contradiction is detected (i.e. conflicting conclusions
/ observations for a parameter or variable) the set of component modules
involved in it indicates which components possibly deviate form their intended
behavior. This can be determined by the diagnosis system because the device
model has a structure that reflects the device constituents that may incorporate
Diagnosis hypotheses are generated, i.e. sets of faulty
components that account for all detected contradiction (fault localization).
Suggestions for useful probes and tests are generated.
This is possible because the behavior model reveals where the diagnosis
hypotheses entail distinctive features of behavior. This function can be
used to reduce the costs in cases whose observations are expensive and
to act as a filter when the amount of information is overwhelming (see
e.g. [Beschta et al. 92])
In case models of faulty components behavior are provided
, the same approach (checking consistency of a model with the observations)
can be used to discard particular faults and to conclude correctness of
certain components if the set of modeled faults is considered complete.
A Revolution in the Technology of Diagnosis
From the description given, one can see that model-based
diagnosis overcomes serious limitations of previous approaches.
The diagnosis procedure guarantees completeness of the results
with respect to the phenomena captured by the models, the faults modeled,
if any, and the observations provided. This means that model-based diagnosis
provides the foundation for future diagnosis systems that can take on the
challenges we discussed in the beginning. An implication of this approach
that is equally important concerns the way diagnosis software is produced.
Diagnosing new devices becomes possible without available
experience with them. This holds because and as long as they are assembled
form components whose behavior models are contained in the model library.
Unanticipated faults and, in particular, multiple
faults can be dealt with. This is based on the fact that the basic algorithm
requires only the specification of models of correct behavior and, hence,
makes no assumption about particular faults.
New symptoms can be exploited, since any observation
that manifests a deviation from normal behavior, even if encountered never
before, will be detected as a contradiction and, hence, contribute to the
generation of diagnosis hypotheses.
A Revolution in the Software Process of Constructing
As we pointed our earlier, the only device-specific element
is captured by the representation of the device structure. Often, it will
be possible to import it from CAD systems. From this information and the
elements of the domain-specific model library, a device behavior model
can be derived automatically. The general diagnosis algorithm operating
on this device model forms a diagnosis system tailored to the particular
device which means it is constructed without having to write a single line
Since the diagnosis framework can be bought from the shelf,
the entire work of programming and knowledge-base construction is in the
establishment and maintenance of the model library. This is essential for
solving the variant problem discussed above and, hence, for turning
a desirable goal into a feasible one from a practical and economic point
of view. Even if the actual runtime system is not a model-based one for
some reason, model-based diagnosis provides useful tools for supporting
programming of diagnostics, for instance for validation or as a starting
point for the programmer who might want to violate the completeness of
the model-based results in a controlled way. Also, the model-based technology
can be used to generate the input to traditional types of diagnosis tools,
e.g. by generating decision trees.
Diagnosis systems can be generated automatically
rather than having to be programmed (see Fig. 1).
Another important advantage is that the generation of
diagnostics requires only a "blueprint" of the device as opposed to a physical
prototype and, hence, can be done concurrently with the design process.
The Current State of the Technology
After about 20 years of research, a number of prototypes
that reflect practical applications have been constructed in the past few
years, including examples from devices like digital and analogue circuits,
power networks, photo copiers, helicopters, and coolant systems of power
plants. Moreover, recently, emerging industrial applications become
visible, mainly a demonstrators. The Tiger project (ESPRIT, see [Milne
et al. 94]) included diagnosis of a gas turbine fuel system. Model-based
diagnosis of car subsystems (both on-board and off-board) is a target of
two projects: "Vehicle Model-based Diagnosis" (VMBD, a BRITE-EURAM project,
and INDIA (a project funded by the German government, see http://lki-www.informatik.uni-hamburg.de/~india/welcome.html).
NASA will equip the "New Millennium" space crafts with model-based systems
as basis for increased autonomy through self-diagnosis and self-reconfiguration.
The first commercial tools are now available, such as
rodon (R.O.S.E. Informatik GmbH) and RAZ'R (OCC'M Software GmbH, see http://www.occm.de).
It has to be mentioned that the scope of current successful applications
and tools is still restricted. Industrial processes (as opposed to devices
with a clear component structure), systems containing embedded software,
and occurrence of structural faults may pose problems for which research
is continuing and no general of-the-shelf solution may be available. Also,
providing the necessary model library is obviously a crucial and potentially
extensive task. Even in cases where mathematical models are used in the
engineering disciplines they may require re-structuring and transformation
to be of utility for model-based diagnosis. Systems supporting or automating
this model acquisition process are still limited. All this means that availability
of expertise in the field of model-based systems is still important both
for selecting applications that are tractable for the state of the art
and for designing the solutions. MONET ("Model-based systems and qualitative
reasoning", a network of excellency in the ESPRIT program, see http://MONET.aber.ac.uk/
) is dedicated to the promotion of technology transfer in this area. In
summary, industrial exploitation of model-based diagnosis technology is
in its starting phase, and companies that appreciate the tremendous impact
of the technology and invest in its exploitation will have a significant
advantage over their competitors.
It is fairly obvious that the model-based technology is relevant
nor only to diagnosis. In fact, much of the knowledge captured by a domain
model library is not specific to the task of diagnosis. Knowledge about
the behavior of components is equally fundamental to other tasks, such
as design, repair, or re-configuration of a device. Failure modes and
effects analysis (FMEA) is a task which can be supported by systems
that automatically analyze the impact of component failures based on a
behavior model (see e.g. [Struss/Malik/Sachenbacher 96]). The same models
might be used for test generation, design for diagnosability, and
training purposes. The model library can be considered as a repository
of corporate technological knowledge. Based on an explicit and coherent
representation, this knowledge can be shared across different phases of
the life cycle of a product, either by humans or by automated model-based
problem solvers (see Fig. 2).
Fig. 2: The Corporate Technological Knowledge
The impact of fully exploiting this technology will be
extremely important to
Thus, model-based systems will be a major contribution to
improve the mastering of the product life cycle.
improving and speeding up communication and knowledge
sharing between different work processes and the people involved,
making corporate knowledge accessible independently of
persons, time, and location.
al. 93] Beschta, A., Dressler, O., Freitag H., Montag, M., Struss,
P.: A model-based approach to fault localization in power transmission
networks. In: Intelligent Systems Engineering, Vol. 2, No. 1 , pp. 3-14,
[Milne et al. 94] Milne, R., et al.: TIGER: Realtime Situation
Assessment of Dynamic Systems. In: Intelligent Systems Engineering, Vol.
3, No. 3 , pp. 103-124, 1994.
96] Struss, P., Malik, A., Sachenbacher, M.: Qualitative Modeling is
the Key to Automated Diagnosis. 13th World Congress of IFAC, San Francisco,
CA, USA, Pergamon, 1996.
96] Dressler, O., Struss, P.: The Consistency-based Approach to Automated
Diagnosis of Devices. In: Brewka, G. (ed.), Principles of Knowledge Representation,
CSLI Publications, Stanford, ISBN 1-57586-057-0, pp. 267-311, 1996.
92] Hamscher, W., Console, L., de Kleer, J. (eds.): Readings in Model-based
Diagnosis, Morgan Kaufman Publishers, Mountain View, 1992.
[Struss 97] Struss
P. Model-based and qualitative reasoning: An introduction. In: Annals of
Mathematics and Artificial Intelligence 19 (1997) III-IV, Baltzer Science
Publishers, pp. 355 - 381, 1997.
If you have comments or suggestions, email me at firstname.lastname@example.org
created: Jakob Mauss, November 28, 1997, last updated: Jakob
Mauss, December 4, 1998