An expert system for formulating lubricating oils

K. Lunn, I. G. Archibald, J. J. Redfearn, A. Robinson, A. Bamigboye, M. D. Cope

and B. T. Hird

Shell Research Ltd, Thornton Research Centre, PO Box 1, Chester CH1 3SH, UK

The formulation of lubricants for automotive engines involves the highest levels of human
decision-making. A project investigating the application of AI techniques to support this activity
has proved to be a challenging exercise. The aim is not to replace formulators, but to automate
only those aspects of their activity where it is reasonably practicable to do so. The basic approach
taken is to view formulation as a hierarchical planning activity, with deep knowledge represented
using a causal model. Formulation decisions are made by rule-bases which mix heuristic
knowledge and causal reasoning, together with the facility for formulators to enter their own
decisions. Decisions are represented as constraints and alternative decision paths are maintained.
Representation of knowledge in a manner accessible to the end users is a key issue, with substantial
amounts of the construction and maintenance of the knowledge base handled by the formulators
themselves. Problems in the interpretation of statements about such a complex domain have
been highlighted. The formulation system integrates with existing information technology,
especially databases. Whilst complete automatic formulation is viewed as technically feasible,
the support of formulators in more routine matters is seen as the only practicable means of
applying AI technology to lubricant formulation.
Key Words: formulation, design, planning, causal reasoning, knowledge acquisition,
constraint-based reasoning, least-commitment.

1. I N T R O D U C T I O N range of potential additives. Additives are used to

A project to investigate the application of AI to the
formulation of lubricating oils for automotive car engines
began in 1985. Initially this was part of an Alvey project
involving Schering Agrochemicals Limited and Logica
UK Limited. The wider Alvey project had the more
general aim of investigating the application of AI to the
formulation process; this meant identifying, where
possible, common themes among a broad class of
formulation activities. The Alvey project concluded
mid-1987, producing a publicly available report 1 5 and
a number of prototypes; confidentiality considerations
have prevented public demonstration of many of these
prototypes, but a demonstrator containing no com-
mercially sensitive data does exist.
This paper presents a Shell Research Limited
perspective on the Alvey project, and reports on
continued work in this area. The chief conclusion of the
Alvey project was that applying current AI techniques
to formulation is feasible and that systems which
formulate adequately can be constructed. Practical
implementation of an operational system involves far
more than technical feasibility, and we have since tried
to identify and solve many of the potential problems.
The formulation of lubricants for automotive engines
involves the highest levels of human decision-making. A
modern lubricating oil consists of a base oil (or mixture
of such) and a number of additives chosen from a wide
Paper accepted October 1990. Discussion closes September 1991.
© Shell Research Limited
Reproduced by Computational Mechanics Publications with their kind
permission.
improve the lubricant by reducing wear or deposition or
other forms of deterioration of an engine. Additives may
have side-effects, or may interact, in a beneficial or
deleterious manner. Inside an engine, the physical and
chemical processes which influence the performance and
degradation of a lubricant are only partially understood.
Changes in engine design, materials used, environmental
restrictions and general expectations mean that require-
ments change continually. A formulator must make
decisions based on incomplete information, unreliable
information, and an incomplete understanding of many
of the processes involved. A formulator is continually
learning and re-learning his craft.
Tackling such a demanding task as the application of
AI to this process is justified by the insight gained into
both AI and lubricating oil formulation. Formulation of
lubricating oils is costly in terms of human resource, and
in terms of materials expenditure on testing. This means
that anything which might reduce costs is worthy of
exploration. Further, for large volume products, small
reductions in lubricant costs can result in large scale
savings. A secondary justification is the development of
useful spin-offs, both for the formulation department and
in other AI projects.
The key issue in determining the likely success of an
operational system, given the premise that a working
system can be produced, is the ease with which it can be
maintained. At this point we seem likely to encounter a
common problem of combinatorial complexity which
limits the rate at which a system can be updated. This
problem exists in X C O N 6, a system which produces
computer system configurations from a statement of
customer requirements, and requires a large team of

© 1991 Computational Mechanics Publications

74 Artificial Intelligence in Engineering, 1991, Vol 6, No 2
 An expert system f or formulating lubricating oils: K. Lunn et al.
full-time maintenance staff. The configuration problem
addressed by XCON is comparable in complexity with
the formulation of lubricating oils, involving many
hundreds of components which can be mixed in many
ways, but the criteria for success in X C O N are much
simpler. To be successful, a lubricating oil formulation
must be tested by placing samples in a number of engines,
running those engines under controlled conditions and
dismantling them to determine the effect on components
such as wear and deposition. Repeatability on such tests
is often poor, and they are expensive and time-
consuming. Additives interact, either enhancing or
inhibiting each other, and additives have unwanted
side-effects which must be controlled.
It has become clear that with current state-of-the-art
techniques an operational system could only succeed if
it could be maintained principally by the users of the
system. The intervention of a knowledge engineer would
lead to delays in modification, which would mean that
the system was always out of step with the level of general
knowledge in the formulation department. Hence, the
later stages of our work has involved the construction of
tools which should ease the modification of the system.
In the long term, we see the capacity to learn as an
integral part of such a system, but current induction
techniques are inappropriate, and other techniques are
too immature.
The rest of this paper outlines the key aspects of the
Shell Research Limited contribution to the Alvey project
and the ensuing work. The post-Alvey work concentrated
principally on adapting the concepts developed under
the Alvey project, and providing high quality interfaces.
We begin by looking at the analysis and representation,
then examine the m o s t ~ c e n t implementation. We shall
conclude with some of-;the lessons learnt and possible
future directions.
2. ANALYSIS AND R E P R E S E N T A T I O N
Considerable effort was expended in the acquisition of
formulation knowledge and much heartache was spent
on finding suitable representations. The following
description is inevitably a distillation of the lengthy
process undergone. A fuller description is given in the
Alvey public report 1 5. Some aspects of the original Alvey
project have diminished as we move toward practical
implementations, and this is reflected below.
The core knowledge representation involves a causal
network and a hierarchical task breakdown. Tasks are
implemented as rule bases, and the order of evaluation
can change dynamically. Decisions are made by posting
constraints, which need to be resolved. When alternative
decisions are possible, it is important to be able to explore
the consequences of any alternative. Finally, incor-
poration of a database of analytical and experimental
data is required, to provide technical data on additives
and provide experimental evidence to support form-
ulation decisions.
Initially there was some hope of formalizing the whole
process. There exist a few statistically derived mathe-
matical models for performance prediction of lubricant
additives. However, their validity depends on reasonable
quantities of experimental data, and by the time sufficient
data is avaiable, market requirements have often
changed. Modelling an engine, including wear and
deposition processes, is technically very difficult, given
Artificial Intelligence in Engineering, 1991, Vol 6, No 2
the limited knowledge of the processes involved and
frequent changes in engine technology. A causal network
appears to be the most acceptable model available, given
the lack of any existing formal model of the process
involved.
2.1. Knowledge elicitation
There are no textbooks on formulating lubricating oils.
Learning the basic skills involves an apprenticeship which
can expand over many years. A great deal of factual
information exists, stored in manuals and computer
databases, but the process of formulating a lubricating
oil is not written down. At the beginning of the project
there were few publications on knowledge acquisition;
techniques such as those suggested by Breuker and
Weilinga 7 were incorporated as the project progressed.
To identify the formulation process, about fifty
interviews averaging about one hour took place over
18 months. The early interviews were somewhat confused
and their chief value seems to have been in allowing the
interviewees to develop suitable techniques. Later
interviews were better directed and proved very effective.
Interviews were recorded and transcribed. The
transcriptions were then condensed into short English
summaries (no formal intermediate representation was
used) before encoding in prototypes. Transcribing a one
hour interview takes almost a day of a skilled typist's
time, and analysing the interview can take a knowledge
engineer up to two days. Analysis of the interview requires
an understanding of the intent of the interview; for a
third party, reading the transcriptions is difficult.
However, transcripts have proved very valuable for new
members of the research team, and for established
members when revisiting the project. The cost of
transcription has been justified and, where appropriate,
we are using the same procedure with other projects.
Adequate alternatives to interviews could not be
identified. Acting as an observer proved inappropriate -
the formulation activity could take place over several
weeks, involving discussions with colleagues and private
meditation both inside and outside the normal working
hours and working environment. For the same reasons,
asking a formulator to write down what he did was
infeasible. Some consideration was given to video
recording of interviews, but this seemed even more
off-putting than audio recording an interview, with little
extra information provided. Thus, whilst an interview
was an artificial environment in which to formulate, it
was the most practicable means of covering the greatest
amount of ground without encroaching too heavily on
a formulator's time.
Early interviews were loosely structured, on a theme
which could be described as 'tell me all about
formulating'. Three or four 'knowledge engineers' would
be present with one or two formulators, putting the
formulators on the defensive. Too often a formulator was
asked to relate his activity to a particular method or way
of describing it, rather than 'telling it like it is'. Broad
ranging interviews such as these are useful initially as a
way of familiarizing the knowledge engineers with the
domain, but they need to be handled with care - they
are not the way to elicit the detailed knowledge of the
domain expert(s).
The early interviews led to an awareness that the
interviewer's interpretation of an expert's statement
influences what the expert will say. It is necessary to
75
An expert system for formulating lubricating oils: K. Lunn et al.
prevent the interviewer over-constraining the expert's
description. If the interviewer proffers a model of what
the expert does, the expert may agree with that model
because it is a good analogy even though there are major
mismatches with his own reasoning. It is impossible to
remove this problem, and therefore it is important to be
aware of it and avoid the pitfalls. The dialogue between
interviewer and expert needs to be managed, and
inevitably that responsibility falls on the interviewer.
It was soon recognized that the best way of proceeding
was with one interviewer and one expert. Interviews need
to be planned and to have clear goals. Two types ot
interview developed. The first type was to obtain
declarative knowledge about the chemical and physical
properties of lubricating oil additives and engines. The
second was to obtain procedural knowledge about how
a formulator undertakes his job.
The 'declarative knowledge' interviews proceeded
along the lines of 'tell me all about additive X'.
Information was sought on its main functions, its
side-effects, the additives it worked well with, those it
worked badly with, when it was a good choice, when a
bad choice. Similarly, interviews investigated all aspects
of a particular engine test measurement such as wear on
cams, seeking information on which additives improved
it and which additives made it worse. Much of the
information was interpreted by the construction of a
causal network (see later). These interviews were also
used to construct rules about which additives are useful
in which situations, and which interactions to avoid or
promote.
The objective of such interviews was to identify a
'structure' to the declarative aspects of lubricating oil
formulation. It was clear early on that the interviewing
activity would be too time-consuming to allow
maintenance of an operational system. How additives
influence tests is often weakly understood since tests
change sufficiently often to prevent collection of adequate
statistical data. New additives are developed with
improved functionality but unknown side effects and
interactions. To succeed with an operational system, it
will be necessary to construct updating facilities which
allow the system to keep pace with changes in the real
world, and with a formulators perception and under-
standing of that world.
The 'procedural knowledge' interviews proceeded
along the lines of 'please formulate for this specification'.
Specifications were obtained either from previous
examples, or were made up by one formulator for another
to tackle. Occasionally a formulator was asked to resolve
the same problem twice with a suitable intervening
period, which often resulted in a different solution; on
close examination this was usually the result of changes
in understanding or newly acquired knowledge, but
sometimes indicated that some decisions could be
arbitrary. The interviews aimed to come up with a
formulation in one to two hours of activity. Throughout
the interview, the knowledge engineer would encourage
the formulator to explain his reasoning.
A serious concern is that any structure imposed upon
the system will be inconsistent with the expert's activity.
For example, a formulator works with a rough plan (or
list of things to do), but the way he acts on that plan is
not clear. A computer specialist is inclined to force-fit
the formulators activity into an existing computational
model, and the formulator is apt to agree with that model
76 Artificial Intelligence in Engineering, 1991, Vol 6, No 2
as a reasonable explanation of his own thought processes.
We have become increasingly aware that verbal responses
to questions such as 'Why did you do that?' are more
often than not post-rationalizations and justifications
rather than an accurate explanation of the decision-
making process. For example 'Why did you add X?' often
elicits the response 'Because it is good for Y', when it
turns out that X is almost always used and is now used
habitually. Similarly a question such as 'What decision
do you make next?', elicits a response which implies that
decision-making is a step-wise activity.
Many arguments have arisen over how a formulator
carries out his job. There are often major discrepancies
between what a person does and what a person says he
does. The major lesson here is that we cannot be certain
of accurately simulating an expert's reasoning. At best,
we can build something which is behaviourally
equivalent.
2.2. Causal reasoning
Much of a formulator's justification of his decisions is
along the lines of 'X is good for Y' or 'X is good for Y
which in turn is good for Z'. There are three major classes
of object in the lubricating oil domain - namely additives,
processes and measurements. Additives are used to
modify performance, and it is the set of additives and
their quantities which define a formulation. Processes
cover oxidation of the oil, particle formulation, and many
other activities or events in an engine. Measurements are
hard evidence of the effect of a formulation, such as how
much did a cam wear.
Causal reasoning 8-1° is a powerful technique in a
well-bounded domain, such as circuit diagnosis. In the
lubricant formulation domain~the connectivity of the
network is high, and the qua'fitification of causation
difficult or impossible. In the Alvey project, to represent
causation, links were prioritized and ad hoc means were
used to chain across from additive to measurement.
Recent experience with an editor which allows a
formulator to draw a network and modify priorities
indicates that reasonable suggestions can be made using
a causal network; at the very least the causal network
should prove to be a useful decision support tool.
The network was constructed with 'isa' and 'class'
hierarchies and inheritance. Thus, if class X influences
class Y and x belongs to X, y belongs to Y and no direct
link between x and y is recorded, a causal link is inherited.
This permits economical inclusion of additives where a
precise understanding of the behaviour has not yet been
acquired.
Within the Alvey prototypes, the causal network is
used as a default when a suitable rule does not exist for
selecting an additive. It gives prioritized lists of additives
to consider and additives to avoid in order to improve
a measurement. Alternatively, it can give prioritized lists
of measurements which are improved or degraded by an
additive. There was an intention to use the network for
justification of decisions (rule based or otherwise), but
this was not explored. Recent prototypes have used the
causal network as a critiquing tool, comparing two
formulations in terms of their broad effects; for example
it is possible to indicate that one formulation is better
than another in preventing wear, but worse at preventing
deposition.
Recent prototypes have used a numeric tag to a causal
link. Tags are integers in the range - 5 to + 5. An ad
 An expert system f or formulating lubricating oils: K. Lunn et al.
hoc but very effective means of inferring causation across
intermediate nodes has been implemented. If X causes Y
degree N, and Y causes Z degree M, then X causes Z
degree M , N / 5 . For example if additive-X causes
oxidation with degree 3 (intuitively interpreted as a
moderate positive influence), and oxidation causes wear
with degree 4 (intuitively interpreted as a strong positive
influence), then in the absence of any other link between
additive-X and wear, the system would calculate that
additive-X causes wear with degree 2.4 (interpreted as a
moderately positive influence).
There was no theoretical justification to the combina-
tion rule presented above. It was a simple attempt to
improve the prioritization mechanism of the Alvey
prototype which adopted a number of ad hoc procedures
for reasoning across links. We now recognize the need
to elaborate this mechanism, where the 'degree' measure
is some function of the quantity of the causer. For
example, doubling the quantity of an additive does not
double its effect on an engine test measurement. Further
research is required on this. Nonetheless, the simple
mechanism described above has proved more than
adequate for identifying broad trends and discriminating
between strong and weak influences.
Joint causation has also been modelled, so that X1,
X2 . . . . . Xn can together cause Y. This allows modelling
of complementary additives where one additive enhances
the effectiveness of another, or alternatively it can model
conflicting additives where one additive inhibits or reacts
with another additive. Chaining across intermediate
nodes is a simple extension of the above. If X1, X2 cause
Y with degree M, and Y causes Z with degree N, then
X1, X2 cause Z with degree M , N / 5 . If X causes Y1
degree M, and Y1, Y2 cause Z with degree N, then X,
Y2 cause Z with degree M* N/5.
Despite the weakness of causation as a quantifiable
reasoning technique in this domain, it has proved
valuable as an analysis tool and for inference.
Formulators have found this to be a very clear
representation of their domain, and it is encouraging that
they are now making firm proposals on how the causal
network should be altered to more adequately fit their
understanding of the domain. There is significant
potential for this as a decision support tool beyond its
role in an expert system. Further research is underway
on the inference techniques applicable to such networks,
including the capture and reasoning over multiple
opinions, and reasoning based on some value associated
with a cause, such as the quantity of an additive.
2.3 Planning
A formulator has a well-defined set of decisions to
make, such as choosing a dispersant or a detergent. The
consensus of the Alvey project was that planning was
hierarchical and one step at a time. The ordering of plan
steps was taken to be problem-dependent, and the
schedule was modifiable at run-time. A task which started
but which could not complete was able to suspend itself
and reschedule after a later step had run. A task, on the
whole, either broke down into smaller tasks or
transformed the formulation by either selecting a
component, quantifying a component, or posting a
weaker form of constraint. Plan steps were implemented
as rules.
The key problem was task-interaction. Choosing a
Artificial Intelligence & Engineering, 1991, Vol 6, No 2
component, for example, might restrict the choice of other
components because of unfavourable reactions. The 'least
commitment' method of M O L G E N (Stefik TM) was
seen initially to be the best fit to our understanding of a
formulator's reasoning, recording decisions as con-
straints which may involve disjunctions. A simple
example would be the recording of an additive selection as
'additive-X or additive-Y', instead of making a firm
choice. Later decisions may extend the constraint, say
by making another additive selection which is dependent
on the earlier additive selection, resulting in a new
constraint of 'additive-V and additive-X or additive-W
and additive-Y'. In this way, multiple alternative solution
paths could be avoided.
Implementation of 'least commitment' proved prob-
lematic. Constraint resolution can require substantial
knowledge, is often only a way of postponing a difficult
decision, and can result in redundant knowledge
representation or poor partitioning of a solution.
Moreover, complex constraints are not easily understood
by the user. On the whole, the Alvey project tried to
avoid backtracking because of the potential combinatorial
explosion.
Clues to why a formulator does not have these
problems come from re-investigation of the interviews.
To begin with, the dialogue is full of asides about
implications for other decisions. Whilst he is concen-
trating on one activity, a picture is being built of other
activities. In an interview, a formulator is artificially
constrained, and adapts his explanations to questions
such as 'What do you do first?'. In practice he may
consciously visit and revisit a decision a number of times
before settling on a solution. Furthermore, a formulator
solves a problem over an extended period, not in one or
two intense sessions; a number of times a formulator
would ring up the day after an interview and start by
saying 'I've been thinking about that and ...'. Least
commitment is the best fit we found to this form of
reasoning, but the implementable representations do not
seem able to handle subtle nuances.
Another clue is to be found in recent publications on
design 13 which suggest that good designers work by
adapting and combining previous examples (or some
weak representations of such). This interpretation fits the
interviews, though it was not explicit from the interviews.
Subsequent work has substantiated this.
After the Alvey project, least-commitment was
abandoned as a reasoning strategy, and multiple decision
paths were permitted, with backtracking allowed either
automatically or under the direction of the user. Despite
initial fears of a combinatorial explosion, the later shift
of emphasis towards a user-guided system acting
principally in a decision-support role has meant that the
backtracking approach has been very effective.
Despite these problems, as part of the Alvey project,
a prototype was constructed which formulated with
tolerable accuracy based on a limited set of candidate
additives and target measurements. The Alvey prototype
was tested by comparing results with those recommended
by a formulator. Discrepancies between a formulator's
solution and the system's solution were usually the result
of changes in the formulator's understanding in the
period between knowledge elicitation and completion of
the prototype. The formulator was happy with the way
in which the system went about making decisions, and
was able to relate new knowledge to the individual
77
 An expert system f or formulating lubricating oils: K. Lunn et al.
decisions made by the system. No formulation generated
by the system was tested in an engine.
The subsequent prototypes have placed more emphasis
on the user directing the solution, and exploring the
potential solution space. The system provides an overall
framework with a plan of tasks to undertake. The user
can either let the system follow its plan automatically,
or he can guide the system through a restricted set of
options to progress a formulation, or both. Multiple
paths are permitted - how this operates is described in
a later example. The system is now viewed as an
environment in which the formulator makes his own
decisions, mixed with system decisions where appro-
priate. The system also offers critiquing of decisions, such
as comparison of two formulations using the causal
network. Validation of this is underway, and there is
every indication that this way of using a system is the
preferred solution.
The Alvey project demonstrated that at a behavioural
level on a bounded problem, hierarchical step-by-step
reasoning does work. However, the time taken to
construct a system can result in a system which is out of
date by the time it is installed. An environment which is
directed by the user, where the user can enter his own
decisions and modify some aspects of the knowledge base,
is considered more appropriate and more acceptable for
this type of domain.
2.4. Constraint based reasonin9
A formulator, whilst making a decision, does not
appear to make a hard and fast choice at once. He may
decide on a list of suitable additives, and return to that
list for further refinement. He may decide not to use more
than a certain quantity of an additive to limit a side-effect,
and return to make the choice on quantity later. To cope
with this, a formulation is constructed as a set of
constraints. A choice of one component may impose
constraints on the choice or quantity of other
components.
The system must reason with constraints. For example
there may be a constraint that the dispersant is to be
chosen from the set [a, b, c, d]. Later it may be decided to
constrain the dispersant choice to be from the set I-c, d, e].
The system must resolve these constraints to restrict the
dispersant choice to be from the set [c, d]. Similarly range
constraints on numbers must be handled, for example
1 . 2 < x < 3 . 4 and 2 . 3 < x < 4 . 7 must be resolved to
2.3<x<3.4.
Constraint-based reasoning was seen as one way of
controlling combinatorial explosion, and removing the
need to backtrack. Unfortunately, resolving conflicting
constraints can require a great deal of knowledge about
the origins of the constraints. One approach taken was
to have a weaker form of constraint, called a preference,
which could be overridden. Another approach was to
construct a knowledge-based constraint manager which
would referee conflicting constraints. The recent,
preferred solution is to allow backtracking, with
over-constrained decision paths being blocked. This
seems to be a more readily comprehensible option for
the users.
2.5.Alternative world reasonin9
To support hypothetical reasoning, the luboil
prototype supported alternate world views. A world
consists of a partial (or complete) formulation together
78 Artificial Intelligence in Engineering, 1991, Vol 6, No 2
fmm~a~
+
sir~le_fo~Aulat~
zmc 2~nc ~lnc
t detergent detergent dctcrgent dct~cm d ~ t ~ t
;;
d~p~'=~L,~td~l~'~nt ~
+ ; + + d~p~s~t dL~'~m~t ~ a n t
Fig. 1. A typicalformulation tree. Nodes represent tasks,
such as 'choose zinc additive'. Tasks are defined by rules.
Multiple alternative rules for the same task 9enerate
alternative paths. The decisions resultin9 in a formulation
(or partial formulation) are defined by a single path from
root to leaf (or node)
with the plan of tasks necessary to complete the
formulation. A plan step creates a new world or set of
worlds from a formulation. A plan step involves a state
transition in either the formulation or the plan (or both).
Thus if a candidate set of three additives could be used,
the system would generate three worlds with each of the
three possible choices, and explore the three alternatives
in turn. The resulting tree is displayed in the prototype
and the user can interrupt the process, directing search
along alternative paths, or intervening with a decision of
his own and exploring the consequences. An example of
such a tree is displayed in Fig. 1.
The presentation of what is effectively a decision tree
is important to our aim of providing a decision-support
environment. Such a display is quite acceptable to the
formulators. Each node of the tree represents a decision
made (or to be made). Multiple alternate decisions might
be made. A decision might b e taken based on the system's
knowledge base or a decision may be made by the user.
The route through to a formulation might involve a
mixture of system and user decisions.
The benefits for a formulator are potentially many. To
begin with, it is possible to record the decision process
and return to it. The structure imposed in effect
implements a methodology for formulating, giving
guidance to novice formulators and allowing standard-
ized communication of the decision process to other
formulators. By mixing system decisions and his own
decisions, the user can supplement areas of his own or
the systems weakness. Call out facilities exist to consult
the causal network or to edit the rules in the system or
to other support systems such as technical databases.
Even without the system making any decisions, there will
be benefits in using such a system as a means of recording
a particular activity.
2.6. Databases
Formulators make use of a substantial database of
previous formulations. This database contains inform-
ation on composition (i.e., what additives) and
performance (i.e., what engine test results). Substantial
use is made of this database to corroborate decisions
made and to develop statistical models of additive
behaviour. It was surprising to find that much of the
formulators use of the information was derived from
 An expert system f or formulating lubricating oils: K. Lunn et al.
standard reports rather than from interactive queries.
Initial assumptions that this was technical conservatism
proved wrong. Two prototypes were constructed which
extracted information from the database. The first
prototype looked for a formulation which achieved
specified performance measures (expressed as ranges).
The second prototype retrieved formulations which fitted
a chemical profile. Both required very complex queries
which took considerable time and effort to construct,
and long query times on the database.
This taught us that a naive interface to the existing
database would be of limited value. A formulator can
work faster with a highlighter pen on a listing than with
a sophisticated query interface. Formulators extract far
more data than is necessary, and refine it off-line. An
expert system would need to simulate this off-line activity.
The other lesson is that fully normalized databases,
whilst removing update and other integrity problems,
can seriously impede performance and reduce the clarity
of the database structure for the end user. Introducing
redundant representations can overcome the perform-
ance penalties and improve clarity.
Standard query languages do not easily support the
browsing of data. For scientific applications, it is
common to want to find a set of entities which meet a
complex set of criteria. Each criterion may well result in
a join in a relational database. A formulator works
iteratively, finding a superset of the entities required
based on strong selection criteria. He then repeatedly
sifts out unwanted entities, or adds in entities which were
unwittingly sifted out. The sifting process may be driven
by constraints on data or sometimes the formulators
knowledge of the type of entity. During the filtering
process the formulator wants to examine information
about an entity, which in turn may require joins in a
relational database. Attempting to translate such a
process into a SQL query is non-trivial and likely to
result in very long retrieval times. Moreover, the query
would not be generic. We suspect that such processing
of data is quite common in other areas, such as market
analysis and trading, and that much of the processing of
data is off-line. We have attempted to tackle these
problems, firstly with a query language (TREQL 14'15)
which does automatic navigation and provides a
user-oriented image of the database. Secondly, we are
investigating windowing mechanisms which allow the
user iteratively to construct sets of entities and tag those
entities with attributes.
3. I M P L E M E N T A T I O N
During the Alvey project a good deal of prototyping
activity took place. Detailed discussion of this is available
in the Alvey public report l-s. The implementation
described below outlines the work within Shell Research
since the Alvey project ended, and differs in a number
of respects. The aim was to re-implement in an
operationally acceptable environment the key concepts
of the original work. Inevitably, some aspects have
changed. The emphasis has been on explicating the
reasoning process, making it accessible and modifiable
by the formulators themselves.
3.1. Software and hardware
The Alvey consortium used Symbolics computers,
LISP and Knowledge Craft for much of the prototyping.
Artificial Intelligence in Engineering, 1991, Vol 6, No 2
Shell Research Ltd considered Knowledge Craft to be a
useful prototyping tool, particularly the frame-based
representation language CRL, but that operational
constraints would rule it out as a development tool.
Prolog was used extensively as a language for accessing
and manipulating databases, both on an IBM 4341
(Rapport) and on a Symbolics (compiled Prolog
database).
Recently, the key aspects of the work have been
re-implemented and extended on a network of SUN/3
workstations using Quintus Prolog and the interfacing
tool Prowindows. A suitable object-oriented extension to
Prolog would be a benefit, but lack of one has not proved
a great handicap - Prowindows is sufficiently close to an
object-oriented system for the purposes of handling the
user-interface. Settling on a single language has greatly
improved compatibility between components. Oracle has
been chosen as the new database implementation system
on a DEC Vax and this will facilitate remote access to
techical databases.
3.2. Encoding of rules
The Alvey prototypes encoded rules in LISP. The Shell
Research prototype required the rules to be edited as
LISP and compiled into the environment. More recently,
the Prolog implementation has defined a simple language
outlined briefly below.
The rules are written according to the syntax:
TASK: : C O M M A N D , C O M M A N D . . . . . C O M M A N D .
To run a task, the commands are evaluated in turn.
Commands may fail, and backtracking to find an
alternative solution to an earlier command is permitted.
A task may have multiple rules, and each rule will be
evaluated in an alternative world. Variables are recorded
as either formulation or specification values, which may
change during execution. The value of a variable may be
a symbol, a number, a list or a range.
Typical commands include the following:
run A - schedule task A for running.
run A a f t e r B - schedule task A to run after B.
run A b e f o r e B - schedule task A to run before task B.
menu(A1, A2, .... An) - define a pop up menu with
options A1 to An which are task names.
On user selection of Ai, place Ai on the
plan, and continue executing the plan.
if X t h e n Y - if X evaluates to true carry out Y.
if X then Y else Z if X evaluates to true carry out Y
otherwise carry out Z.
either A or B - run alternate worlds from here on, one
with the results of evaluating A, one with
the results of evaluating B.
A < B proceed if the current range for A includes values
less than B, and modify the range of A to
exclude values B or above.
A = B - proceed if the current range of A includes B, and
set A to B precisely.
A in [ B 1 , . . . , Bn] - proceed if the current value of A
includes at least one of B1 to Bn, and set A
to be the appropriate subset.
X = goodfor(A) - set X to the list of items which 'isa' X,
and are good for A on the causal net,
ordering the list in decreasing causal
strength.
79
An expert system for formulatin9 lubricatin9 oils." K. Lunn et al.
The range manipulation is quite effective and was
motivated by statements such as 'use at least X % of
detergent Y', and 'never use more than Z % of detergent
X'. A formulation may be produced which gives range
values rather than fixed values. Similarly, lists are useful
to implement statements such as 'detergent X or detergent
Y could be used here'; alternate world reasoning could
be used to examine the alternative possibilities, but later
statements may reduce a list - in this way some of the
combinatorial explosion is reduced.
3.3. The inference engine in action
A simple knowledge base might be:
formulate ::menu (simple_formulate,
complex_formulate).
simple_formulate ::run specify,
run zinc,
run detergent,
run dispersant,
run test.
specify::camwear = < 9.
zinc::camwear = < 8.5,
zinc_additive = super_zinc,
detergent_additive in
[expensive_detergent 1,
usual_detergent2].
zinc::8.5 < camwear < 9.5,
zinc_additive = usual_zinc.
zinc::camwear > = 9.5, zinc_additive = cheap_zinc.
detergent ::detergent_additive in
[cheap_detergentl, cheap_detergent2].
detergent ::detergent_additive in
[usual_detergentl, usual_detergent2].
detergent ::detergent_additive in
[expensive_detergent 1,
expensive_detergent2],
dispersant_additive = expensive_dispersant.
dispersant ::dispersant_additive = goodfor (camwear).
test ::stop.
Fig. 2. The initial screen presented to the user. The top left is the unexplored formulation tree. The top right
presents the icons representin# the options available
80 Artificial Intelligence in Engineering, 1991, Vol 6, No 2
The system initially offers the user a screen as shown
in Fig. 2. The user can choose which of a number of
windows to display by selecting from a pop up menu
attached to the windows icon (Fig. 3). The formulation
tree starts off with the single node 'formulate'. Attached
to this node is a pop-up menu which allows the user to
enact the 'simpledbrmulate' or ' c o m p l e x J o r m u l a t e '
task. Let us assume that the 'simpled'ormulate' option
is chosen. The following tasks would execute in turn
formulate - Offers a menu of two options to the user.
s i m p l e _ f o r m u l a t e - Puts the tasks 'specify', 'zinc',
'detergent', 'dispersant' and 'test' onto the plan, in
that order.
specify - Posts the constraint that 'camwear' must be
less than or equal to 9. Any task which attempts to
violate this constraint will fail.
zinc - There are three rules here, so the formulation tree
branches correspondingly (Fig. 4). The first rule
corresponds to the rightmost node displayed, and is
the first to be executed.
zinc (rule 1) - The first rule further constrains 'camwear'
to be less than or equal to 8.5, which does not conflict
with the earlier constraint placed by the task 'specify'.
The zinc additive is chosen to be 'super~zinc', and
the detergent additive is chosen to be one of
'expensive_detergentl' or 'usual_detergent2'.
Fig. 3. The window icon. A pop up menu permits the user
to open or close a variety of windows which show different
aspects of the progress of the formulation
 An expert system for formulatin 9 lubricating oils: K. Lunn et al.

LF - ARTIIqCIAL LUBRICANT FORMULK1OI detergent - There are three rules here, so the formulation
formulate tree branches correspondingly (Fig. 5). The first rule
corresponds to the rightmost node displayed, and is
the first to be executed.

detergent (rule 1) - This tries to constrain detergent_

additive to be one of 'cheap_detergentl' or
'cheap_detergent2'. The zinc rule (1) had earlier
constrained this to be one of 'expensive_detergentl'
or 'usual_detergent2'. Hence this task fails. The
~c ~c ~c system now backtracks to an earlier node, in this
case the second detergent task.

detergent (rule 2) - This tries to constrain detergent_

Fig. 4. A formulation tree, showing the branching caused additive to be one of 'usual_detergentl' or
by three alternative zinc rules 'usual detergent2'. The zinc rule (1) had earlier
constrained this to be one of 'expensive_detergentl'
or 'usual detergent2'. Thus detergent_additive is
given the value 'usual_detergent2'.
formulate
dispersant - This rule calls out to the causal network,
asking for a list of the dispersants which are good
for 'camwear'. There are three dispersants recom-
mended, so the formulation tree branches.

test - At this point, the formulation has completed. A

rule base might be constructed to take in the results
of engine tests, and to modify the formulation based
mc ~c ~c
on those results, and subsequent tests scheduled. In
our simple example, however, the system simply
stops. The final screen is described in Fig. 6. The
formulation is displayed in one window, the
detergent detergent detergent completed plan to this decision in another.

At this point, the user may continue exploring the

Fig. 5. A formulation tree showing the branching caused formulation space by popping up a menu on any node
by three alternative detergent rules where the plan still has outstanding tasks, and choosing

~c ~c ~c

detergent detergent detergent

dispersant dispersam disperumt stop

test

Fig. 6. The screen on completion of a formulation path. Two windows are displayed, showing the formulation and the
plan followed to achieve this formulation

Artificial Intelligence in Engineering, 1991, Vol 6, No 2 $1

An expert system f or formulating lubricating oils." K. Lunn et al.

the 'run task from here' option. A more extensively
explored formulation space is described by the
formulation tree in Fig. 7.
The causal network is illustrated in Fig. 8. Suggestions
for dispersant_additives which are good for camwear will
be usual dispersant, cheap dispersant and expensive_
dispersant in that order of preference.
The network editor is called by activating a pop-up
menu on the edit icon on the inference engine display.
Similarly, the rules can be edited via a text editor called
from the main screen. Various windows can be opened
and closed to display status information such as the rule
fired at a node, the plan of tasks to carry out at a node,
the formulation, and various rule traces. The status at a
particular node is found by pointing at the node and
pressing a mouse button.
The nodes on the tree are active, and a pop-up menu
allows inspection of the node, or the undoing of that

.4-- ~ ~ ~

detergent detergent detergent

S
detergent

dis rsant dispcrsant dispcrsant dispcrsantdis dispersant dispcrsant dis~rsant disp¢rsant dispersant

¢ ¢ ¢
test test test test test test test test test test test test

Fig. 7. The screen with a more fully explored formulation tree

[ ; A l i , % A I . N I - I WOI~,K I-I)1 l(J

tire j

~ g-'-ccc~-3 U---rrcr--3 ~'----c~--3 ~ ~ ~ ~

Fl|Qrlaee; Current v|evn~ne: 4:ilS:iBgpe, ~tl nes ds y 61~h Junef 1990

Fig. 8. A sample causal network as displayed by the causal network editor

82 Artificial Intelligence in Engineering, 1991, Vol 6, No 2

 An expert system forformulatin9 lubricatin9 oils: K. Lunn et al.

node and its descendants. For example, the user might
wish to edit the rule base and redo a line of reasoning.
The tree can be larger than the screen and scrolled around
(as in Fig. 7).
The user can amend the formulation state at a node,
and then see the consequences. For example, the user
may want to see the consequences of choosing a different
dispersant, or a different level of dispersant. In this way,
it is possible to mix system and user decisions.
3.4. The causal network editor
An important goal of the later work has been to provide
adequate means of presenting and editing the knowledge
base. One such tool is the causal network editor (Fig.
8). This gives a clear visual presentation of the causal
network, and provides easy to use editing operations.
It takes less than thirty minutes for a novice to become
proficient in its use.
New objects are created by selecting an option from
a pop-up menu obtained by pressing a mouse button
when the cursor is on the background. Names are typed
directly into a box by highlighting the box with a
mouse-click. Objects can be arranged in hierarchies. For
example, to add a new child, the user clicks on the top-left
icon, clicks on the parent, and a new box appears ready
for the name of the object to be typed in. Not all of the
network can be displayed at once, and so there are
options to display selected items. For example, to display
an existing child, the user clicks on the icon second from
top left, then on the parent, and the child appears
underneath if there are multiple children a menu of
them is offered. Different views of the network are
allowed, displaying different subsets of the network.
Views are switched via a pop-up menu. Objects can
disown (if it is a parent) or adopt other displayed objects.
Objects can have multiple parents.
Causal links are created by clicking on a link icon
('add new causer' or 'add new causes'), then clicking on
the two items to link. The link value can be set to an
integer in the range - 5 to + 5 by activating a pop-up
menu in the link bubble using a mouse button. Multiple
causers are allowed, and this is done by clicking on the
'new causers' icon, clicking on the object caused, then
clicking on the objects which together cause it.
Items can be displayed either from a pop-up menu of
root parents or from a dictionary of all objects via a
pop-up menu on the background. Objects can also be
displayed as children (as described above) of a displayed
object, as parents of a displayed object, as a causer of a
displayed object, or as a causee of a displayed object. If
the display is too crowded, objects can be removed from
the display (but not the network) by clicking on the 'hide'
icon (cover) and clicking on the object to hide, or by
dragging the object behind the curtain 'hide' icon.
Similarly objects can be deleted by clicking on the 'erase'
icon and clicking on the object to be deleted from the
network, or by dragging the object to be deleted into the
'bin' icon.
It is possible to chain through the network obtaining
a list of all objects which cause (directly or indirectly) a
particular object. An example is given in Fig. 9. A
particular causal link can be explained by clicking on the
line in the causers table. Similarly a list of all objects
caused can be obtained, together with an explanation of
the causal links used to establish a level of causality (see
Fig. 10).

c0.4,[a2])
cO,[m])
c(3.6,[ai])
c(3,[n])
c(l.2,[b]) (isa(al,a), eauses(a,n,+2)), causes(n,x2,+3)
(isa(al,a), causes(a,m,+3)), (isa(x2,x), causes(m,x,+4))

1%- C0
Fig. 9. A sample causal network as displayed by the causal network editor. The list of all causes of x2 has been requested,
together with an explanation of why aI causes x2

Artificial Intelligence in Engineering, 1991, Vol 6, No 2 83

An expert system f or formulating lubricating oils." K. Lunn et al.
c0.6,with[],x2)
cO,with([]),m)
c(2,with(I]),n)
c(1.2,with([]),y)
c(1.2,with([]),xl)
(isa(al,a), causes(a,n,+2)), causes(n,x2,+3)
(isa(al,a), causes(a,m,+3)), (isa(x2,x), causes(m,x,+4))
Fig. 10. A sample causal network as displayed by the causal network editor. The list of all effects of al has been
requested, together with an explanation of why al causes x2
The network is represented by a set of Prolog tables
which can be stored out on disc. To prevent disasters,
each edit operation is journalled on disc until the network
is saved. If the editor is exited without saving, the editor
restarts by applying the journal to the original file.
The effort expended in constructing the editor has been
more than justified by the fact that the end users can
now reliably update the causal network. Despite the
complexity and high level of functionality, the editor is
extremely easy to use, and simple to learn how to operate.
The editor has succeeded in making the underlying
knowledge base tangible and comprehensible. A similar
approach to the editing of rules is being investigated,
though the task there is much more complicated.
However, changes in the causal network are anticipated
to be much more frequent than changes in the rule base.
4. F U R T H E R W O R K A N D C O N C L U S I O N S
4.1. Development
It is clear that, at a behavioural level, we can reproduce
a formulator's decisions at a given time. In domains
where the understanding of the technology is evolving
slowly, it would be feasible to construct a usable
operational system with restrictive modification of the
knowledge base using specialist computing/AI staff. In
domains such as the formulation of lubricating oils,
successful operational use across the whole range of
formulation activities would depend on rapid and
continued development/maintenance of the knowledge
base, which must involve a substantial commitment from
the formulation department staff.
Our only role-model for an operational system of
comparable complexity is DEC's XCON. This project
84 Artificial Intelligence in Engineering, 1991, Vol 6, No 2
requires a large team of programmers and several million
dollars a year investment. In DEC's business, the return
on investment is significant since it improves product
quality, reduces overall staff requirements and improves
delivery. If the DEC experience were to be repeated for
the formulation of lubricating oils, the programming
team would have to be comparable in size to the current
number of formulators. The potential return on
investment would not compare with that of DEC, where
hundreds of configuration engineers could be replaced
(or have a large part of their workload replaced) by a
computer system. XCON essentially makes a large
number of small decisions based on complete and
deterministic knowledge. Lubricating oil formulators
make a small number of large decisions based on
incomplete and non-deterministic knowledge.
We must conclude, therefore, that replacement of
formulators by computer systems is, apart from the
technical limitations of AI, not a cost-effective option.
We must therefore look to AI as a means of enhancing
a formulator's work. Significant achievements have been
made in developing prototypes which could complement
a formulator's decision making. In particular the decision
support/documentation features of the inference engine,
the causal network and the database interfaces are of
great potential value in assisting a formulator.
4.2. Limitations of AI
The key limitations of AI for a domain such as the
formulation of lubricating oils are an inability to learn
and an inability to make decisions on incomplete or
uncertain information. The key skills of a formulator are
the ability to keep pace with changes in the field and to
make necessary decisions without the luxury of complete
 A n e x p e r t s y s t e m f o r f o r m u l a t i n g lubricating oils: K. L u n n et al.
experimentation, unlimited time and unlimited money.
Current AI techniques for learning are, by h u m a n
standards, naive. Rule induction techniques rely on large
numbers of simple examples to construct a decision tree;
conflicting examples are not handled particularly well.
Neutral networks offer more promise, but still appear to
be limited in their scope.
Much contemporary research in AI concentrates on
the removal of inconsistent knowledge and the attempt
to ensure completeness of the knowledge base. For
creative, evolving domains this is counter to require-
ments. Research is continuing on reasoning with
incomplete and inconsistent information, but one should
not expect short-term operational implementations.
4.3. Conclusions
Current AI techniques are far from capable of
reproducing the activities of a lubricant formulator. The
Alvey project established convincingly that a system can
be constructed which corresponds behaviourally to a
formulator at a given time. However, a formulator's
behaviour adapts to meet changes in requirements and
changes in understanding. In the broad spectrum of
lubricant formulation that rate of change is high. If one
considers the adaptation to that change a key activity of
a formulator (one must), we conclude that AI is
incapable, at present, of adequately encompassing the
whole of a formulator's activity.
We must therefore consider whether the lubricant
formulation department could maintain and extend a
knowledge based system to keep pace with changes in
requirements and understanding. F r o m our own
experiences and considering the experience of X C O N ,
we must conclude that the cost of managing such change
is high and comparable to the current cost of employing
formulators.
The key facilitator for providing wide-scale automated
decision making in such a domain must lie in the ability
to construct systems which learn, and which develop and
adapt their learning strategies. Rule induction techniques
rely on numerous examples and cannot readily cope with
inconsistencies and incomplete information. Adapting
neural network learning techniques to causal networks
looks interesting but is, as yet, unexplored.
Current AI techniques are capable of application in
areas where formulation knowledge does not change
rapidly. A significant number of such areas exist within
the lubricant formulation department, and automating
these should have significant value. Any reduction in the
number of engine tests required to achieve a formulation,
and/or any reduction in treat rates which result in a lower
cost product, are worth having. Quantitative benefits in
a field of this kind will be hard, if not impossible, to
assess. Measures of success must inevitably come from
the formulators judgement of the value of the system.
On a broad scale, it is infeasible to automate all
lubricant formulation decisions, but a computer system
should prove useful in documenting the decision making
procedure of a formulator (even if that documentation
is not an accurate reflection of the creative process), and
assist the formulator in routine decisions and cal-
culations. At the very least it should provide a
methodological framework, and an environment for
novice formulators to explore the domain without too
great a dependence on skilled formulators.
The research has led to the development of useful tools
Artificial Intelligence in Engineerino, 1991, Vol 6, N o 2
and techniques which should have significant operational
value. These techniques include the causal network and
database interfaces. Improvements in data handling,
using AI techniques where appropriate, should provide
significant benefits in the future.
The overall project has led us to a major strategic
conclusion about the future of AI as an aid in high-level
activities. Rather than look for replacements for experts,
we should be looking towards the development of tools
to enhance the effectiveness of the experts we have, by
reducing their training time, by handling more routine
decisions, and by encapsulating/transmitting expertise.
Such tools may not accurately simulate the behaviour of
an expert, but extend the expert's efficiency and
effectiveness.
ACKNOWLEDGEMENTS
The early part of this research was undertaken as part
of the Alvey programme which added an important
breadth to the project. We thank the Alvey Directorate
and our consortium partners Logica U K Ltd, and
Schering Agrochemicals Ltd for their contribution. The
formulation department, especially John Lillywhite,
David Colbourne, Richard Egan and Eddie Wilkinson,
are thanked for their enthusiasm, patience and input to
the project. Thanks also to Steven Death, and many other
individuals who have contributed considerably.
REFERENCES
1 Robinson, A. (Ed.) PFES Project Report to the Alvey
Directorate: Volume 1 - The PFES Project, 1987, available from
A. Robinson, Shell Research Ltd, Thornton Research Centre,
Chester CH1 3SH, UK
2 Robinson, A. (Ed.) PFES Project Report to the Alvey
Directorate: Volume 2 Description of Applications, 1987,
available from A. Robinson, Shell Research Ltd, Thornton
Research Centre, Chester CH1 3SH, UK
3 Robinson, A. (Ed.) PFES Project Report to the Alvey
Directorate: Volume 3 - The Formulation Kernel, 1987, available
from A. Robinson, Shell Research Ltd, Thornton Research
Centre, Chester CH1 3SH, UK
4 Robinson, A. (Ed.) PFES Project Report to the Alvey
Directorate: Volume 4 - The Public Demonstrator, 1987,
available from A. Robinson, Shell Research Ltd, Thornton
Research Centre, Chester CH1 3SH, UK
5 Robinson, A. (Ed.) PFES Project Report to the Alvey
Directorate: Volume 5 - Recommended Applications Method-
ology, 1987, available from A. Robinson, Shell Research Ltd,
Thornton Research Centre, Chester CH1 3SH, UK
6 Winston,P. H. and Prendergast, K. A. (Eds) The AI Business,
The MIT Press, 1984
7 Breuker, J. and Weilinga, R. Model-Driven Knowledge
Acquisition Interpretation Models, Esprit Project 1098, 1986
8 De Kleer, J. and Brown, J. S. A. Qualitative physics based on
confluences, Artificial Intelligence, 1984, 24(1-3)
9 Forbus,K. D. Qualitative process theory, Artificial Intelligence,
1984, 24(1-3)
10 Kuipers,B. Commonsensereasoning about causality, Artificial
Intelligence, 1984, 24(1-3)
11 Stefik,M. Planning with constraints (MOLGEN: Part 1),
Artificial Intelligence, 1981, 16(2)
12 Stefik,M. Planning and recta-planning (MOLGEN: Part 2),
Artificial Intelligence, 1981, 16(2)
13 Gero, J. S. (Ed.) Artificial Intelligence in Engineering,
Proceedings of the 1988 Conference, Computational Mechanics
Publications
14 Lunn,K. and Archibald, I. G. TREQL (Thornton Research Easy
Query Language) An Intelligent Front End to a Relational
Database, in Prolog and Databases, Gray, P. M. D. and Lucas,
R. J. (Eds), Ellis Horwood, 1989
15 Gray, P. M. D., Archibald, I. G.and Lunn, K. Interfacing a
knowledge base to a large database, The Knowledge Engineering
Review, 1989, 4(1)
85