- Email: [email protected]
Artificial Intelligence and Expert Systems: Next Generation Tools
Copyright © IFAC Industrial Process Co ntrol Systems, Bruges, Belgium, 1988
ARTIFICIAL INTELLIGENCE AND EXPERT SYSTEMS: NEXT GENERATION TOOLS L. Boullart Automati( CO lltrol LaboratOl)" State L'lIil ·ersity of Cll ellt, C rote.ltefll U'eg .\'oonl 2, B-9i 10 Client, Belgium
ABSTRACT. Recent advances in research in Artificial Intelligence (A.I.) have resulted into noticeable operational applications in the field of expert systems. Although the first successes were mainly in the medical area, also in process control the expectations currently are very high. The tutorial will giv e an introduction to Artificial Intelligenc e in general, and will focus thereafter more onto expert systems. The general structure of such systems will be discussed and a survey of the appropriate languages and tools will be presented. Furthermore, an overview of the topics in process control will demonstrate where A. I. and expert systems could be introduced. Because most to-day operational systems are designed with a rule based methodology, this will be explained more in depth. An easy-to-use rule based system will be described and illustrated with appropriate examples. This will enabl e to explain important characteristics of expert systems. such as reasoning and inference methodologies, selection strategies, and conflict resolution. To conclude with, the operation of such systems will be illustrated in the field of the simulation of continuous dyn~ic systems . Such systems typically demonstrate the new formalism in the description and design of the control strategy when using these techniques.
THE ROOTS Of A.I.
INTROOUCTION Arti ficial Intelligence (A. 1. ) is a relatively young acience, and therefore there is no strict definition. "Intelligence" is commonly considered as the ability to collect knowledge and to reason with this knowledge in order to solve a certain clasa of problems. Artificial Intelligence tries to catch this intelligence in computers.
In the early stage of computing (early 50's), it was completel y unthinkable that computers would ever do something else than computing ballistic curves. The problem undoubtedly lies in the terminology itself, where "computer" is always associated with "counting" and "calculating", although in pr inciple the machines could manage all kinds of symbols. Even John von Neumann has argued in his last publications that computers never would reach any stage of intelligence.
A. I. is often regarded as a collection of techniques to handle knowledge in such a way as to obtain new results and inferences which are not explicitly (" imperativel y") progrBfl'fned. A much broader v iew of A.1. contains also all appl ications which employ A.I.-techniques, whether or not they enable the inference of new knowledge.
The first applications of A.1. existed already in the 50' s and the earl y 60' s especially in the form of chess and checkers programmes. The purpose of the designers thereby was to get an insight in the essential reasoning process of f~ous chess players : there was a general presumption that some kind of general principle lays at the base of each intelligent behavior. To-day specialists have realised that the intelligent behavior of such programs only illustrates a few aspects of the reasoning process: a good chess player is only (no less, but also no more) than a good chess player. This change in attitude was very characteristic, and meant a swap from research in general rea90ning principles to the recognition of more apecific knowledge (facts, experimental knowledge), and its impact in specific domains. This swing in mentality in the scientific research was triggered by experiments in specific projects, which demonstrated that it wss possible to use lsrge amounts of knowledge in an "intelligent" wsy, leading to results which could never hsve been reached by human action slone.
A.1. undoubtedly has a growing impact and currently enjoys an increasing interest from potential (eapecially industrial) users. Computers are performing - all things well considered - rather well, even when processing large amol.Jlts of data (knowledge). On the other hand A.I. is not a magic toolbox to solve all problems, but the advance towarda more complex ones which could not have been readily aolved by "normal" imperative progr!M11ming methods, or only at the expenae of huge efforts, is quite noticeable. Future industrial power will largely be determined by knowledge information proceasing systems: "KIPS". The expected (and necessary) increase of knowledge proceasing power of the coming computer generation ia dr!M11atic : from some tena to hundreds of "LIPS" (Log~cal iQference per second) in today's systems, to 10 - 10 LIPS in the 90's.
APPlICATION AREAS Of A.l. Al though important and extensive spplicstions of A.1. are only expected after 1995, research has already given to-day noticeable results in the form
45
46
L. Boullan
of useful tools and applications. The domain is qui te large, but in the context of this paper, the most important topics are the Expert Systems for process control. An expert system applies A.I.techniques to an amount of knowledge concerning a strictly defined area. This knowledge consists both out of objective facts ( "data base" ) and mechanisms, relations, etc ..•• which govern those facts ("knowledge base" ) . Results from this knowledge information system are obtained by so called inference techniques. Where the original goals of expert systems was to mimic the human expert, this view nowadays is far too strict. a. Operator assistance: The problem tackled here is that operators of complex control systems, such as power plants, are confronted wi th an overwhelming amount of information during alarm situations. flashing lights, buzzers, printers ejecting page long lists of log values, and many other trigger signals have to be assimilated. for example, in a nuclear envirortnent, some 800 alarmmessages can be generated within 2 minutes. furthermore, the connection between separate alarms may be very complex, if at all present. It is impossible to keep a total view of all events and actions that may influence the si tuation at. hand. The human task to perform here is very difficul t. Even people who are trained to do this kind of work make mistakes, purely because of the heavy load with which their decision-making process is faced under the described conditions. Arti ficial intelligence can provide a reasoning support, because it is not influenced by stress. They can follow the same pattern of thought under any condition, and advise humans on which deci sion to focus. b. Process control design in the situation where a process engineer has to set-up a new complex proceas scheme, an expert computer program may engage a conversation wi th him to finalize into a suitable process control strategy. This will have a growing impact in the future because the requirements in to day's control are much higher and much more algorithmic than they used to be. c. Procesa automation: inside the control loop itself, A.I. can have many benefits. In a ateadily increasing complexity of control strategies, there may be a claim for a higher, much more abstract level, where a choice for the optimal control strategy is made relying upon real- time in fo rm ation from the process. Such systema can be rather Simple, but will surely gain onl y benefi ts when research will have delivered much more insight into the symbolic reasonings which form the roots of such stra tegies.
control systems on the right track. If a certain control loop trips, by which we mean that its parameters steadily deviate from their setpoints or from the optimal strategy, thus gradually approaching instability, a skilled operator will limit the effects of such an error on the rest of the process by manually taking over some of the control actions. In doing this the hum9'l operator discriminates between normal and erroneous situations. e. Controller Jacketing: Al though control system theory has recently delivered new methods for optimal and adaptiv e c ontrol, the algorithms used in industrial envirortnents are very stable. PlO controllers are still everywhere in existing industrial process c ontrol systems. 8ut even though these algorithms are well understood, they are never used without a number of surrounding heuristics, such as wind-up protection, smoothers for manual to automatic transition, transient fil t e ring, etc . . These features have littl e to do with control th e ory, but are extremely important in practical controllers. Artificial int e lligence techniques could provide a jacket for control algorithms, allowing for decision support under conditions the controller would judge as abnormal. f.
Measurement technigues in measurement and monitoring situations it is common knowledge that the amount of information flowing through is enormous; until now we have learned to capture the picture of the process by performing classical signal processing techniques. The time has come now to add another level of abstraction in the form of symbolic manipulation ( e.g. pattern mat c hings ) whi c h will undoubtly offer new insights into the real-time capabilities of such systems.
g. Automatic program design and generation: the goal here is, starting from specific knowledge about the appl ication domain ( e.g. a chemical pro c e ss) and its con t r 0 1 mec ha n i sm san d strategies, to automatically generate computer programs for the implementation of a process control program.
DIffERENCES BETWEEN TRADITIONAL AND A.I. COMPUTER TECHNIQUES Although in an A.1. envirortnent a large part of the traditional computer techniques and conventional algorithmic imperative programming styles may be used, in some aspects a significant difference can be observed. In a traditional programming style, the programner wri tes an instruction sequence which follows a clear path from the problem definition towards the solution.
d. Controlling Complex Systems: Large scale systems, such as chemical reactors, trsffic control systems and real-time shop floor planners are very complex. They are not always well understood, and even if they are, the need may be fel t to simpl i fy the model as much as po saibl e. Chang ing system configuration is expensive, msking mistakes is even more expensive.
A.I. on the other hand, deals more with symbols. These symbols represent quantities from the real problem; but, instead of making calculations with the quantities, the symbols are manipulated and the mutual relations between the symbols processed. This manipulation is in fact performed without any explicit knowledge of the contents. The solution of an A. I.-prOblem is first of all a search for a functional solution.
Controll ing com pI ex processes can be difficult for multiple ressons. Process loops msy be tightly coupled, so that eventual control systems must be multidimensional or of a higher order. Parameter values may depend in a nonl inear way upon the current working point of the ayatem. Also, signal s may be subjected to heavy noise which is automatically discarded by human operators, but looks like a transient error to a machine controller. fortunately, human operatora are often experts in keeping the
In A. I. -systems, there is no single way to represent knowledge. Scientific research in this area is still very intensive. Those methods have to store the knowledge information following certain techniques, and have to formulate procedures to deduce ( "infer" ) new useful information. The knowledge contains facts on objects, relations, actions which are possible on those objecta, and also the so-called "meta-knowledge" : i.e. knowledge about knowledge. The meta-knowledge determinates how the knowledge is structured and which
Artificial Intelligence and Expert Systems relations and values are assigned whenever no explicit indication is given at the instancing of the object.
A.I. lANGUAGES Classical programming languages, as they have been used for imperative programming styles are unsuitable when dealing with A.I.-problems. Therefore a number of specialised languages have been designed. Requirements for A.!. -languages are e.g. manipulation of objects (especially lists) , the possibility for general manipulation of a wide area of different data-types, late binding of the exact value and typing of the objects, pattern recognition in structures, interactive operational procedures and interactive methods ("inference") for autana tic deci sion making and deduc tion. Al though, in a first phase, A.!. -languages were derived from enhanced versions of traditional languages ( e.g. SAIL fro .. ALGOL), to-day more general languages are used, of which PROLOG and LISP are the most important. Besides these tools, some manufacturers and / or scientific researchcentres have developed their own "languages" ( e.g. Small talk-BD, OPS-5, .•• ) .
LISP ( "List Processor" ) was developed by John McCarthy (now at Stanford lkliv.) at MIT at the end of the 50 's. Lisp especially deals with symbols in the form of atoms and lists. The basic element of Lisp is an "Atom" ( elementary string ) , and a list constructed fran atans or other lists. The real power of LISP comes when functions are defined. A function can be seen as a strict functional definition (without any procedural action) , and this definition may be recursive. Such own-defined functions are in no way different from the basic LISP functions: after eventual canpilation, they, may reside into a library, and can be regarded as a true extension of the language. Because program structures and data structures are fundamentally identical, LISP allows to manipulate also programs and functions as symbols. Towards the user, LISP appesrs as an interactive language implemented around a highly integrated workstation (mostly single-user). Its interactive character enables quick and easy developments, which can be tested by the fingertips.
47
Prolog, just as Lisp, can manipulate lists in diverse ways. Full symbolic manipulations of both facts and rules themselves are also possible. Besides those, which are shsred with Lisp, Prolog operates inside a specific inference engine, which is purely goal driven: the evaluation of Prologquestioning is done by searching through the database ( Le . all predicates and rules) via a treesearching algorithm in order to satisfy a goal. This goal can be realised in aeveral ways, depending o~ the questioning : - by an affirmation ( "yes" ) or a negstion ( "no" ) ; - by looking for each instance of a variable (X ) which leads towards an affirmation. In the production rule paradigm, this goal sesrching strategy is called backward chaining: in order to verify if a certain goal can be ful filled, all preconditions have to be checked. Prolog herewith offers a simple conflict resolution scheme ( Le. when mor e rules applies) : it tackles the rules one after the other in the order in which they appear in the data base. Ob ject Oriented Progr_inq In object oriented programming, the emphassis is not on procedures, nor on a functional specification, but on the data, called "objects". An important language in the object programming style is Small talk-BD ( Adele Goldberg - XEROX PARC ) . In this language, the abstract data typing is pushed as far as possible by introducing the concept of "class". A class contains the canplete description of a t ype, both to its nature as to the possible operations which csn be carried out. An object ia just an instance of a class. A program proceeds by sending "messages" towards objects . These messages tell the obj ec t whi c h operation to carry out, and not how; this is determinated completely by the object itself and is hidden inside the class. In this way, identical operations on objects of different nature may be carried out in different ways . Ea c h instance of a class delivers an object with an own "private" memory. Modifications of this private memory can only be carried out by the object itself. This mechanism autanatically guarantees that the implementation of an object will not depend on internsl details of other objects, but onl y on the messages to which it has to respond. This method slso guarantees the modularity of the system. EXPERT SYSTEMS
PROLOG ("Programming in logic" ) was developed around 1970 at the Marseilles university by Alain Colmerauer. At the department for A.I. at the Universi ty of Edingburgh, Prolog was elaborated on by implementing it on a Decsystem-10 by e.g. Warren and Hellish. Prolog is based on the so called predicate logic, and can be regarded as a formal implementation into a 1 anguage of this type of logic. The language starts from objects snd the relation between objects; it proceeds then to wards a consultation of this information by questioning. Thua, we can distinguish J phases : - formulating facts: "predicates"; - formulating" rules", to establish the relation between those facts; - formulating queations. The facts, which are things we know about the world we are moving around, are stored in the data base. The rules which govern the world sre atored in the knowledge bsse.
What is understood as an "expert", has been carefully expressed by P. Johnson, in the following text ( fig. 1) : "An expert is a person who, because of train i ng and exper ience, is able to do things the rest of us cannot; experts are not only profic i ent but also !IIlooth and efficient in the actions they take. Experts know a great many things and have tricks and caveats for appl ying wha t they know to problems snd tasks; they are also good at plowing through irrelevant information in order to get a basic issues, and they are good at recognizing problems they face as instances of types with which they are familiar. lklderlying the behavior of experts is the body of operative knowl edg e we have termed ex per ti se. It i a reasonable to suppose, therefore, that experts are the ones to ask when we wish to represent the expertise thst makes their behsv ior possible".
48
L Bo ulla n
KNOWLEDGE REPRESENTATION AND EXTRACTION
An expert system is composed of 3 important elanents : - the knowledge of facts; - the knowledge of relations between the facts; 8 heuristic, efficient method for storage and acquisition of this information ( "inference" ) .
I
InterrogatIOns Case - studies
(S~)! ~
Knowledge Engineer
EXPERT
I
I
0
0
The key issue in A. 1., and especially in ex pert s yst e ms , is the wa'y kn o wledge is stored and ex trac t ed from the knowledge base. This fact is not only r e l a t e d to the applic ation field itself, but also t o t he fea si bilit y of the application . How ni c e a nd intelligent an e xpe rt s ystem may be, if the tim e to infe r the r e qui r ed answer is too long, it is complet e l y usel e s s . This is especially true in pr oce s s c ontr ol envi ro nments where the real-time a spe c t i s a se vere r e quirement. Therefore, kno wl edg e r epr esen t a ti o n and ex t r ac tion mechanisms not o n ly have t o f ulfill the ir task, but they have to do it ver y qui c kly and effi c i e ntly, whi c h is diffi c ul t to a c hie v e b eca us e of the painful limitation s o f to-day's c omputers!
I
j
t
Answers Solutions
~ -i I I
u
Ther e is no gen e ral rul e f o r knowledge respresentati o n and e xtra c tion. However, some general schanes ar e used in to-da y's applic a tions: - fram e and sc r i pts; - san an ti c ne tworks ; - prod uc ti o n rul es .
EXPERT SYSTEM
Fig. 1 : Ex pert System Building. In the 70' s, especially the last item r ece ived a lot of attention in s c ientifi c resear c h. The importance of this el ement i s crucial f o r an y practical use of expert s ystems, as is str e sse d by Hayes-Roth : "The central notion of intelligent problan solving is that a system must c onstruct its solution selectively snd efficiently from a space of alternatives. When resource-limited, the expert needs to search this space sel ectively, with a little unfruitful activity as possible. An expert's knowledge helps to spot useful data early, suggests promising wsys to exploit them, and avoids low-pa yoff efforts by pruning blind alleys as earl y as possible. An expert system achieves high performance by using knowledge to make the best use of its time."
Becau se mo s t su cc esful implementations employ p ro du c t io n r u l es , t he l a tter pa radigm will be ex pl a in e d mo r e i n de tail. Fo r the oth e r methods the read e r i s r e fered to the literatur e .
PRODUCTION RUl£-8ASEO SYSTEMS General Concepts on production rules Produ c ti o n rul e s originat e from the popular I F ••• THE N str uc ture, whi c h is known in traditional proc edur a l languages. "If the o ven temperatur e becomes higher than 250 d e gr e es Ce l c ius then the thermoswitch is d e fec t". "If the o ven t e mperatur e becomes lower than 50 degrees Cel c i us and i f t he I i ght in th e o ven is on then the th e rmoswi t c h is defect". "If th e out s id e t e mpe rature is higher than 28 d eg r ee s Ce lc ius th e n b e er c onsumption will ri se" .
The construction of an expert system is called "knowledge engineering". The "knowledge engineer's" j ob i s toe x t r act the k now 1 ed g e 0 ut 0 f hum an experts : Le. procedures, stra teg y, rules 0 f thunb and to transfer this into a data base. Multidisciplinary tools are used for knowledg e extration (e.g. interview, video-observation, prototyping, ••• ) .
Thi s IF .• • THE N s tructure is based upon first order logi c ( pr edica t e s ) ; Le. IF A THE N B : L e . When A ~ B "modus ponens" not ( 8) ~ not ( A) "modus toll ens" •
When developing and using ex pert s ystems, a nunber of key people are involved . The relations between these people are drawn in the fig. 2, and demonstrate tha t the ex per t sy stem lo o p has important hunan aspects.
I
0
Q I EXP~R'T
Tool Builder
1
Bu ilding
Interview
(~~)
~
I
Exten sive Testin
Us ing
u u EXPERT SYSTEM TOOL
Fig. 2
0
Knowledge Engineer
-
Bu il ding Testing Tun ing
~~I / u
u
I
EXPERT
SYSTEM
The Human Face of the Ex pert Sy stem Loop.
Data + Knowledge Base
Artificial Intelligence and Expert Systems Rules always contain two parts : - a condition-part, sometimes called "left-handside" (LHS) - an action-part, sometimes called "right-handside" (RHS)
49
~ (
R_E_A_L_ _.....
,-I
One must however be careful with the indication "left" and "right", because in some syntaxes (e.g. Prolog) the "left" (condition) is physically written on the righthand side of the rule. A set of rules can be evaluated in either two different ways: from left to right or vice verse. Those two approaches to the solution reflect two di fferent reasonings and classes of probl ems.
, ,-
---------~. ..... ,
( Knowledge \
Base '
(Rules)
As an example, consider e.g. an expert system for medical diagnoses, with the following rules. If symptom (A) and symptom ( B) end symtom ( C) THEN measles. If symptom (A) end symptom (D) Tt£N measles If symptom (A) end symptom (r.) Tt£N flu.
Consult Rules
INFERENCE
Add/Delete Facts
Consult Facts
ENGINE
The two first rules together form an OR-clause (with each rule itself an AND-clause). In the on and
a left-to-right reasoning, the doctor will ask patient about all possible symptons, write them a scoreboard, evaluate all rules in sequence, tr ies to find out the desease.
In a right-to-left approach, the doctor will suppose the patient has measles, scan the knowledge base to find the measles symptons and then diagnoses the patient for a possible match. Those two reasoning processes are called forward-chaining ("left-to-right") : i t is often referred to as "date-driven" or "bottolT>-up"; - backward-chaining ("right-to-left") : this is also called "goal-driven" or "to~down". The different element of a production rule-based expert system are drawn in fig. 3. The knowledge base contains all the rules. The blackboard contains all known facts: Le. the world to which the system applies in a given state at a particular instant of time. As time goes by, both by external events, or by evaluating rules, the contents of this blackboard may change. The interpreter acts on the given rule set and mainly has to match the lefthand sides in order to succeed the goals or sub-goals ( action ) . One must however be aware that there is a fundamentsl difference wi th a classic al procedural language : in a rulebaaed system, many rules ( IF ••. THEN ••• ) will be "open" (i.e. are executable) in parallel and at the eame time. A special isaue therefore is the problem of confl ict resolution : i.e. the strategy to follow when at a given instsnt of time more than one rule "fires". Several schemes are then conceivable : priority, selecting the first (as in Prolog), recercy strategy, importarce, selectivity etc ••• Finally many operational expert systems offer the user some ex tra fac ili ties in the form of the explanation (tracing) of how a specific conclusion has been drawn. This is very importsnt not only in the development phase to evaluate the system, but also in real operation in order to make the user confident about the suggested ac tions.
Proloq
88
/
World
I.
Fig. 3 : Production Rule System. measles:-symptom(A) ,symptom(S) ,symptom(C). measles:-symptom( A) ,symptom ( D). flu:-symptom(A) ,symptom(E) . As Prolog contains in itself also an inference engine, Prolog can be seen as a production rule system. It employs the backward inference procedure. Prolog evaluation is a goal searching procedure, whereb y a goal is asked for and then all necessary conditions ("sub-goals") are searched in order to try to attain the main goal. E.g. the above mentioned eXllllple thermodefect:-temp( oven ,X) ,X(50,ovenlight. is evaluated by asking Prolog ?-thermodefect. Then Prolog will 1) measure the temperature; 2) compare this as "(50" 3) look at the ovenlight. Only is if all sub-goals succeed ( "and" clauae) Prolog will answer" yes" . The action "measure the temperature", which is typical for a real-time system, can be implemented in two ways : - as a rule in the knowledge base, activating some spec ial ( non-Prolog ) routine to actually meaaure the temperature; - as a fact: i.e. the engine will look at the blackboard for something like "temp(oven,40)"; this approach inherently suppose some other mechanism (probably a conventional foreground program in the computer) is present (see also fig. 3) which periodically scans measurements and adapts the facts on the blackboard correspondingly. The latter approach is substantially better, espec iall y from real-time and performMce con&trains, although PC-tools often choose the first.
a Production Rule Systa.
The "translation" of the above eXllllples into Prolog is straightforward Md much conciser : thermodefectl-temp( OVe-l,X) ,X>250. thermodefec t:-temp( oven, X), X(50, ovenlight. raiae_beer:-temp(outside,X),X>2B.
In order to have a full operational system, this is only part of the story. There should indeed by a kind of "sutopilot" : i.e. a progrllll which continuously and automaticslly questions the system for results. Just having a program which cyclically asks all possible questions would be high! y inefficient. Some methodology therefore should be intro-
L. Boullart
50
duced. This could be some feed-forward mechanisn which after changing facts on the scoreboard tr i9gers all involved rules. The read er sho uld al so real ize tha t the &bove exIIIIIple ia rather simple. In practice a questioning involves a complex evaluation procedure of many linked rules/facts. It can be seen as an (inverted) tree traversing process, wi th many backtracking (i.e. on failure of a branch) before a succesful answer eventuall y could be found.
There are many explicit rule-based programming systems canmercially available on the market. They are sometimea called "shells". Mostly they operate in a forward way, but backward evaluation can often be obtained by introducing extra facilities in the language to create goals, subgoals, e.o. A rather aimple, however powerful rule based system, called "CLIPS" developped at the Artificial Intelligence Section of tho! Jomson Space Center, and available on the public domain, will be used in the next examples. It shows a close relationship in structure (although there are slight differences in the evaluation procedure in the conflict set) with the OPS5 expert system language from OCC. In order to set the idea about rule-based shells, the basic elements of CLIPS wil be summarized. a. Dealing with facts. Facts can be entered ("asserted") onto and deleted ("extracted") fran the scoreboard. This can be done either directly (i.e. conversationally from the terminal) or fran within the action part of a rule e.g. (aasert (valve boiler-fuel open)) (extract l) The extract command calls the internal fact number, which can be obtained by displaying all facts at the terminal, or by putting a fact in a reference variable (inside a rule). The system makes a difference between initial facts (Le. those asserted before the program starts operating) and the facts asserted/extracted during progrlllll evaluation.
=>
(extract ?cl ?c2) (assert (temp-alarm on)) (assert (valve boiler-fuel closed)))
Thereby is "test" an internal procedure for logical testing. Al though those example give a clear insight in the principlea of the language, the reader should be aware that the language is much richer in capabilities (e.g. on pattern matching, computing procedures, logical constructs, ••• ). Also facts can be "time-stamped" (i.e. giving a unique identification) which is very important in goal-seeking strategies. Furthermore extensive debug and tracing facilities are available. A real-life problem consists of many such rules which in a consiatant way interact with each other by means of the facts on the scoreboard. As already stressed out, all rules in principle act in a kind of parallellisn. After a canplete rule is executed, the system confronts i tsel f wi th a new si tuation (the scoreboard could have been changed) and makea a "notebook" of all rules which are executable at that particular point in time .. This agenda is called the "conflict set". Then it must proceed by choosing only one out of all possible rules. In CLIPS this is simply done in a flFO-kind of way, but in other similar systems more sophisticated mechanisms exist : e.g. OPS5 tries to catch the importance and the tipecificity of each rule. This evaluation procedure is of the highest importance, and the user should understand the underlying strategy of his rule-based system on-hand very well in order to write efficient and correct "programs". From the operational env ironment point of view, there is a significant difference between PROLOG and a rule based system. Whereas in PROLOG, the user must interactively ask all questions, a rule based system operates wi th a recognize-act cycle. Thereby after placing the initial facts on the scoreboard, the user starts the system, which afterwards runs by itself until it finds itself with an empty notebook. At that time the progrsn is over. A RlLE-BASED SIMlLAT!Jl F!Jl
CONTINUOUS DYNAMIC SYSTEMS b. Dealing with rules. A rule is an independant entity with a name and a body. The body consists of the condition part and the action part. The condi tion part apeci fies a number of facts which ill must be preaent before the action part is engaged. (defrule boiler-control (boiler-tEmp high) (boiler-pression normal)
=>
(assert (valve boiler-fuel closed)) (sssert (temp-alarm on)))
The lsnguage alao recognizes variables, which remain locally within the rule itself. They can be referred to both in the lefthand and righthand side. They can contain different items (atom, facts) and matching should lexicographicslly be exsct. (A variable is preceded by a "7 "-mark .) (defrule boiler-control (boiler-temp 7tl) (boiler-pression 7pl) (test (> 7tl 150)) (test « 7p120) 7cl <- (tEmp-alarm off) 7c2 <- (valve boiler-fuel open)
As an ex ample of an application where A. 1. -tecmiques could open new insights and perspectives, a rule-based simulator for simulating continuous dynsnic systems is discussed. Continuous dynsnic systems are those systems which are mathematically represented as a set of differential equations eventually coupled with algebraic equa tions. Bo th process and control systems can often be represented in such form. Simulating such systems could be done in two ways. The most natural way is to use analog computers, because the y 0 ffer the nec essary speed, inherent parallelism and the independancy from the size of the system. Many years ago, this was the only way to proceed. Although nowadays such canputers are still intensively used in special high demanding environments, in most cases they are replaced by the cheap equivalent of digital computers. Several software packages are available for the user to simulate such ayatEms by digital canputers. The way those packsges proceed to enter the simulation model is twofold. Some packages have an algebraic approach: i.e. the (differential) equations are entered in a procedure resembling conventional Fortran programs. Other packagea have a block oriented procedure: the user has to draw a block diagram of hia system, which thereafter is codad into a program table. The latter method ia often used by process engineera, because they are very fEmiliar with this kind of block diagrams.
Artificial Intelligence and Expert Systems We will deal in this paper witht he second method. It is obvious that in such representation schemes, many levels of abstraction are feasible; this solely depends upon the complexity of the blocks in the simulation model and it can range from a simple adder or integrator up to a full complex controller. This level of abstraction reflects itself in the computer program by the complexity of the corresponding computational routine. The reader will further notice that it also holds true for the rule-based simulator. In fig. 4 a block model is drawn using blocks with the func tion "integrator", "adder", "invertor" and "printer" .
51
The figure 5 shows the initial facts of the dllnped osc illator of figure 4. One clearly distinguishes the following elements : - the type of each block number e.g. (block 2 type integrator) - the connector scheme e .g. (from 1 to 2 3) - the initial values of the state varisbles e.g. (at 0 integrator I output I) - the parllneter values e.g. (integrator 2 par +2) - integratfun control e.g. (step lOO) - output control e.g. (print-interval 5)
------------------------------------; Initial model confi,uT.lion; : Ihis is in flct the datl - base and the scoreboard of the model.
------------------------------------(deHlcU simulation - modcl- waves (block I type intelTaCor) (block 2 type inle,rllor) (block 3 Iype summer - 2)
(block .. type lummer-2) (block' type print) (block 6 type invertor) (from I to 2 3)
fig. 4 : A block model for an oscillator. The equation for this model can easily be derived as follows
y1 = -2z y 1 + 2y
z
Y = 2y 1 Substitution leads us to the differential equation y +
2y
+ By
0
which is a simple damped oscillator system. To formalize this model, each block is given a block number 0 ... 6}, and a connection matrix could be set Lp. In a rule based environment, this system can be simul ated as follows. At esch step in the integration process, the output of each state variable csn uniquely be characterized at the scoreboard as a fact with the following form :
(from 2 10 .. 5) (from 3 10 6) (from 610 I) (It 0 inte,r.lor I output I)
0 intcarltor 2 output 0) (intcaTator I par + 2) (inlClralor 2 plr +2) (summer-2 3 pari I) (summer - 2 4 par2 2) (endtime 4) (I'
(Slep 100) (print-time 0) (print- inlerval $) (plot-time 0) (plol- inlerval $) (plot - scale 80)
(plot-oH ... 40))
Fig. 5
Initial facts for the simulator.
The figure 6 gives as an eXllnple two "computational" rules, one for a state variable (integrator) and one for an algebraic variable (summer). One osverves that for the integrator a new output fact is asserted on the scoreboard, whereas for tha summer the output value is immediately dispatched.
;------- --- ------------- --------; Definition of block - types
(at x block-type y output z) where x y
z
time-value block-number output value (atate variable value)
e.g. (at 5 integrator 2 output 0.03). The rule-based aimulator containa also a so called scheduleI', which - knowing the connection scheme between all blocks - diapatches all outputs to the necessary inputs the moment they are available. At laat, each block ia represented by one rule ..t1ich ia triggered by the matching of facts which represent all necessary inputs at each time frllne. The action pert retracta this input facts from the scoreboard, and aaserts the new output fact (for a state variable) or diapatches immediately values for other block-typea. Remembering the time step in each fact ia strictly neceasary because otherwise the computation at the block-rulea would mix Lp resul ts of different iterations of the feedback scheme. It should be stressed out that in the simulator there is only one rule for each blocktype (even if there are more identical blocks in the model), and that each block itself is a runtime instantiation of the rule.
;--------------------------.----(defrule inlearalor -type ?c I < - (al "li me inte.rator 1numb ?v al) 1c2 < - (11 1ti me inle.rator 1numb output ?valout) (step 1uep) (intearltor ?numb par 1p) (relrlct ?cl 1(2) (bind ?newvII (+ (I (. 1vII ?p) ?uep) ?vllout) (assert (11 - (+ ?Iime I) intearator ?numb output ?newvII)) (auere (displlcb II - (+ ?Iime I) ?newvII (rom inlearator ?null'lb»))
;--- ---_ ._._--------.--- .... - .. _.(defrule summer - 2 -Iype ?c I < - (al ?Iime summer - 2 1numb 1 ?nll) ?c2 < - (11 ?time summer - 2 1numbl ?vaI2) (tu t (. ?numb2 (+ ?numb I I») (summer - 2 1numb I par I ?p I) (summer - 2 ?numb2 parl 1p2) (retract 1c I ?('2) (auert (displlch 11 ?time .(+ (e ?vall 1pl) (. ?va12 ?p2)) (rolD summer - 2 ?numbl»))
;-- .. --._---------- .. -- ... - .. - ... Fig. 6 : The "integrator" end "aummer" computational rules.
52
L. Boullart
To demonstrate tha t output-control is a straightforward matter, the figure 7 gives the corresponding rule. An important observation when looking, at this procedures for driving a simulator is that it is a real implementation of what is know in ccmputer science as a data-flow machine. The system is very characteristic in this perspective because it tackles a very hughe problem in data flow in a elegant way: i.e. the unique identi fication of each iteration in the feedback loop. This problem, which is known as "coloring" in data flow, is solved here by adding a time stamp to each iteration sensitive fact. ; • • - - - - - - - - - - - - ___________ 2_KZ
_______ _
DUlput rules :
outPUI- prinl provides I list If resuhs output - plot provided
I
simple print - plot
with ,cale (plol- scale xx) and of het (plot-offset fYY)
;-----------------------._-----------(defrule outPUI- print (dcrl.re (&alienee 100»
1c I < - (I' ?Iime print ?numb 7val) ?c2 < - (prinl-timc ?time) (print - internl 7inter) (step 'step)
?(2) (bind ?temp (I ?time 71lcp)) (printout 'temp" _. - "7nl ctlf) (Iller. (print-time -(+ ?time 7inter)))) (rCUICI 7c1
Fig. 7 : Rule for output control.
CON:lUSlON By glvlng an overview of the field of A.I. and E.S. this paper clearly shows an important number of tools are available to the user to apply these new techniques. More and more such tools are readily available to-day on all types of ccmputer systems, ranging from small PC's to larger mini's and mainframes. The application of the rule based simulator demonstrates that by implementing a classical problem wi th the new tools, ccmpletely new ideas and insights in the problem can be drawn and interesting perspectives in related research fields open up.
BIBLIOGRAPHY 1. 'Astrom K.J. et a1. "Expert Control", Automatica, 22 (3), (1986). 2. Baldwin J.F. "Support Logic ProgrElllming for Expert Systems", paper presented at BIRA workshop on expert systems, 24 sept. 1985. 3. Boullart L. "Expert Systems", Monogra~ic seriea on Automatic Control 1, Belgisch Insti tuut voor Regeltechniek and Automatisering, Antwerpen (1987) • 4. Boullart L. "Using A. I.-tools for progrElllming Programmable Logic Controllers", Proc. European Simulation Hulticonference, Society for Ccmputer Simulation, Vienna, ( 1987). 5. Boullart L. "Artificial Intelligence &: Expert Systems : new issues in process control", Journal A, £!!. (3), (1987). 6. Boullart L., Delbar P., VandElllme F., Heeffer A. "Expert-Driven industrial process control", Flanders Technology, International Seminar (1987) • 7. Brady H., Gerhsrdt L., Davidson H. ( Eds.) "Robotics and Artificial Intelligence", SpringerVerlag, Berlin (1984). 8. Clocksin W. F., Hell ish C. S. IIp rogramming in Prol2.g", Springer-Verlag, Berlin (1981). 9. Delbar P. "A parallel approach to rule based systems", Eurcmicro (1987). 10. Delbar P. "Technische Toepessingen van Expertsystemen", Het Ingenieursblad, 22. (2), (1987). ll. De Swaan Arons H., Van Li th P. "Expert ~ temen", Academic Service (1984). 12. Efstathiou J. "Introduction to expert systems", Journal A, 27 (2), (1986). 13. EfstathiouJ. "The Chocolate Biscuit factory", Journal A, 27 (2), (1986). 14. Feigenbaum E., McCorduck P. "The fifth generation", Addison-Wesley (1983). 15. Freedman R., Frail R. "~gen : The evaluation of an Expert System for Process Planning", AIMagazine, 2 (5), (1986). 16. Goldberg A., Robson D. "Smalltalk-80", AddisonWesley (1983). 17. Haspel D. "Application of rule-based control in the Cement Industry", paper presented at the BIRA Seminar on Expert Systems and Artificial In tell igence in Industry, (l986). 18. Hayes-Roth B. "A Blackboard Architecture for Control", Artificial Intelligence, 26 (3), 251322 (1985). 19. Steels L. "Programmeren in Lisp", Academic Services (1983). 20. Waterman D. "A guide to expert systems", Addison-Wesley (1985).
ARTIFICIAL INTELLIGENCE AND EXPERT SYSTEMS: NEXT GENERATION TOOLS L. Boullart Automati( CO lltrol LaboratOl)" State L'lIil ·ersity of Cll ellt, C rote.ltefll U'eg .\'oonl 2, B-9i 10 Client, Belgium
ABSTRACT. Recent advances in research in Artificial Intelligence (A.I.) have resulted into noticeable operational applications in the field of expert systems. Although the first successes were mainly in the medical area, also in process control the expectations currently are very high. The tutorial will giv e an introduction to Artificial Intelligenc e in general, and will focus thereafter more onto expert systems. The general structure of such systems will be discussed and a survey of the appropriate languages and tools will be presented. Furthermore, an overview of the topics in process control will demonstrate where A. I. and expert systems could be introduced. Because most to-day operational systems are designed with a rule based methodology, this will be explained more in depth. An easy-to-use rule based system will be described and illustrated with appropriate examples. This will enabl e to explain important characteristics of expert systems. such as reasoning and inference methodologies, selection strategies, and conflict resolution. To conclude with, the operation of such systems will be illustrated in the field of the simulation of continuous dyn~ic systems . Such systems typically demonstrate the new formalism in the description and design of the control strategy when using these techniques.
THE ROOTS Of A.I.
INTROOUCTION Arti ficial Intelligence (A. 1. ) is a relatively young acience, and therefore there is no strict definition. "Intelligence" is commonly considered as the ability to collect knowledge and to reason with this knowledge in order to solve a certain clasa of problems. Artificial Intelligence tries to catch this intelligence in computers.
In the early stage of computing (early 50's), it was completel y unthinkable that computers would ever do something else than computing ballistic curves. The problem undoubtedly lies in the terminology itself, where "computer" is always associated with "counting" and "calculating", although in pr inciple the machines could manage all kinds of symbols. Even John von Neumann has argued in his last publications that computers never would reach any stage of intelligence.
A. I. is often regarded as a collection of techniques to handle knowledge in such a way as to obtain new results and inferences which are not explicitly (" imperativel y") progrBfl'fned. A much broader v iew of A.1. contains also all appl ications which employ A.I.-techniques, whether or not they enable the inference of new knowledge.
The first applications of A.1. existed already in the 50' s and the earl y 60' s especially in the form of chess and checkers programmes. The purpose of the designers thereby was to get an insight in the essential reasoning process of f~ous chess players : there was a general presumption that some kind of general principle lays at the base of each intelligent behavior. To-day specialists have realised that the intelligent behavior of such programs only illustrates a few aspects of the reasoning process: a good chess player is only (no less, but also no more) than a good chess player. This change in attitude was very characteristic, and meant a swap from research in general rea90ning principles to the recognition of more apecific knowledge (facts, experimental knowledge), and its impact in specific domains. This swing in mentality in the scientific research was triggered by experiments in specific projects, which demonstrated that it wss possible to use lsrge amounts of knowledge in an "intelligent" wsy, leading to results which could never hsve been reached by human action slone.
A.1. undoubtedly has a growing impact and currently enjoys an increasing interest from potential (eapecially industrial) users. Computers are performing - all things well considered - rather well, even when processing large amol.Jlts of data (knowledge). On the other hand A.I. is not a magic toolbox to solve all problems, but the advance towarda more complex ones which could not have been readily aolved by "normal" imperative progr!M11ming methods, or only at the expenae of huge efforts, is quite noticeable. Future industrial power will largely be determined by knowledge information proceasing systems: "KIPS". The expected (and necessary) increase of knowledge proceasing power of the coming computer generation ia dr!M11atic : from some tena to hundreds of "LIPS" (Log~cal iQference per second) in today's systems, to 10 - 10 LIPS in the 90's.
APPlICATION AREAS Of A.l. Al though important and extensive spplicstions of A.1. are only expected after 1995, research has already given to-day noticeable results in the form
45
46
L. Boullan
of useful tools and applications. The domain is qui te large, but in the context of this paper, the most important topics are the Expert Systems for process control. An expert system applies A.I.techniques to an amount of knowledge concerning a strictly defined area. This knowledge consists both out of objective facts ( "data base" ) and mechanisms, relations, etc ..•• which govern those facts ("knowledge base" ) . Results from this knowledge information system are obtained by so called inference techniques. Where the original goals of expert systems was to mimic the human expert, this view nowadays is far too strict. a. Operator assistance: The problem tackled here is that operators of complex control systems, such as power plants, are confronted wi th an overwhelming amount of information during alarm situations. flashing lights, buzzers, printers ejecting page long lists of log values, and many other trigger signals have to be assimilated. for example, in a nuclear envirortnent, some 800 alarmmessages can be generated within 2 minutes. furthermore, the connection between separate alarms may be very complex, if at all present. It is impossible to keep a total view of all events and actions that may influence the si tuation at. hand. The human task to perform here is very difficul t. Even people who are trained to do this kind of work make mistakes, purely because of the heavy load with which their decision-making process is faced under the described conditions. Arti ficial intelligence can provide a reasoning support, because it is not influenced by stress. They can follow the same pattern of thought under any condition, and advise humans on which deci sion to focus. b. Process control design in the situation where a process engineer has to set-up a new complex proceas scheme, an expert computer program may engage a conversation wi th him to finalize into a suitable process control strategy. This will have a growing impact in the future because the requirements in to day's control are much higher and much more algorithmic than they used to be. c. Procesa automation: inside the control loop itself, A.I. can have many benefits. In a ateadily increasing complexity of control strategies, there may be a claim for a higher, much more abstract level, where a choice for the optimal control strategy is made relying upon real- time in fo rm ation from the process. Such systema can be rather Simple, but will surely gain onl y benefi ts when research will have delivered much more insight into the symbolic reasonings which form the roots of such stra tegies.
control systems on the right track. If a certain control loop trips, by which we mean that its parameters steadily deviate from their setpoints or from the optimal strategy, thus gradually approaching instability, a skilled operator will limit the effects of such an error on the rest of the process by manually taking over some of the control actions. In doing this the hum9'l operator discriminates between normal and erroneous situations. e. Controller Jacketing: Al though control system theory has recently delivered new methods for optimal and adaptiv e c ontrol, the algorithms used in industrial envirortnents are very stable. PlO controllers are still everywhere in existing industrial process c ontrol systems. 8ut even though these algorithms are well understood, they are never used without a number of surrounding heuristics, such as wind-up protection, smoothers for manual to automatic transition, transient fil t e ring, etc . . These features have littl e to do with control th e ory, but are extremely important in practical controllers. Artificial int e lligence techniques could provide a jacket for control algorithms, allowing for decision support under conditions the controller would judge as abnormal. f.
Measurement technigues in measurement and monitoring situations it is common knowledge that the amount of information flowing through is enormous; until now we have learned to capture the picture of the process by performing classical signal processing techniques. The time has come now to add another level of abstraction in the form of symbolic manipulation ( e.g. pattern mat c hings ) whi c h will undoubtly offer new insights into the real-time capabilities of such systems.
g. Automatic program design and generation: the goal here is, starting from specific knowledge about the appl ication domain ( e.g. a chemical pro c e ss) and its con t r 0 1 mec ha n i sm san d strategies, to automatically generate computer programs for the implementation of a process control program.
DIffERENCES BETWEEN TRADITIONAL AND A.I. COMPUTER TECHNIQUES Although in an A.1. envirortnent a large part of the traditional computer techniques and conventional algorithmic imperative programming styles may be used, in some aspects a significant difference can be observed. In a traditional programming style, the programner wri tes an instruction sequence which follows a clear path from the problem definition towards the solution.
d. Controlling Complex Systems: Large scale systems, such as chemical reactors, trsffic control systems and real-time shop floor planners are very complex. They are not always well understood, and even if they are, the need may be fel t to simpl i fy the model as much as po saibl e. Chang ing system configuration is expensive, msking mistakes is even more expensive.
A.I. on the other hand, deals more with symbols. These symbols represent quantities from the real problem; but, instead of making calculations with the quantities, the symbols are manipulated and the mutual relations between the symbols processed. This manipulation is in fact performed without any explicit knowledge of the contents. The solution of an A. I.-prOblem is first of all a search for a functional solution.
Controll ing com pI ex processes can be difficult for multiple ressons. Process loops msy be tightly coupled, so that eventual control systems must be multidimensional or of a higher order. Parameter values may depend in a nonl inear way upon the current working point of the ayatem. Also, signal s may be subjected to heavy noise which is automatically discarded by human operators, but looks like a transient error to a machine controller. fortunately, human operatora are often experts in keeping the
In A. I. -systems, there is no single way to represent knowledge. Scientific research in this area is still very intensive. Those methods have to store the knowledge information following certain techniques, and have to formulate procedures to deduce ( "infer" ) new useful information. The knowledge contains facts on objects, relations, actions which are possible on those objecta, and also the so-called "meta-knowledge" : i.e. knowledge about knowledge. The meta-knowledge determinates how the knowledge is structured and which
Artificial Intelligence and Expert Systems relations and values are assigned whenever no explicit indication is given at the instancing of the object.
A.I. lANGUAGES Classical programming languages, as they have been used for imperative programming styles are unsuitable when dealing with A.I.-problems. Therefore a number of specialised languages have been designed. Requirements for A.!. -languages are e.g. manipulation of objects (especially lists) , the possibility for general manipulation of a wide area of different data-types, late binding of the exact value and typing of the objects, pattern recognition in structures, interactive operational procedures and interactive methods ("inference") for autana tic deci sion making and deduc tion. Al though, in a first phase, A.!. -languages were derived from enhanced versions of traditional languages ( e.g. SAIL fro .. ALGOL), to-day more general languages are used, of which PROLOG and LISP are the most important. Besides these tools, some manufacturers and / or scientific researchcentres have developed their own "languages" ( e.g. Small talk-BD, OPS-5, .•• ) .
LISP ( "List Processor" ) was developed by John McCarthy (now at Stanford lkliv.) at MIT at the end of the 50 's. Lisp especially deals with symbols in the form of atoms and lists. The basic element of Lisp is an "Atom" ( elementary string ) , and a list constructed fran atans or other lists. The real power of LISP comes when functions are defined. A function can be seen as a strict functional definition (without any procedural action) , and this definition may be recursive. Such own-defined functions are in no way different from the basic LISP functions: after eventual canpilation, they, may reside into a library, and can be regarded as a true extension of the language. Because program structures and data structures are fundamentally identical, LISP allows to manipulate also programs and functions as symbols. Towards the user, LISP appesrs as an interactive language implemented around a highly integrated workstation (mostly single-user). Its interactive character enables quick and easy developments, which can be tested by the fingertips.
47
Prolog, just as Lisp, can manipulate lists in diverse ways. Full symbolic manipulations of both facts and rules themselves are also possible. Besides those, which are shsred with Lisp, Prolog operates inside a specific inference engine, which is purely goal driven: the evaluation of Prologquestioning is done by searching through the database ( Le . all predicates and rules) via a treesearching algorithm in order to satisfy a goal. This goal can be realised in aeveral ways, depending o~ the questioning : - by an affirmation ( "yes" ) or a negstion ( "no" ) ; - by looking for each instance of a variable (X ) which leads towards an affirmation. In the production rule paradigm, this goal sesrching strategy is called backward chaining: in order to verify if a certain goal can be ful filled, all preconditions have to be checked. Prolog herewith offers a simple conflict resolution scheme ( Le. when mor e rules applies) : it tackles the rules one after the other in the order in which they appear in the data base. Ob ject Oriented Progr_inq In object oriented programming, the emphassis is not on procedures, nor on a functional specification, but on the data, called "objects". An important language in the object programming style is Small talk-BD ( Adele Goldberg - XEROX PARC ) . In this language, the abstract data typing is pushed as far as possible by introducing the concept of "class". A class contains the canplete description of a t ype, both to its nature as to the possible operations which csn be carried out. An object ia just an instance of a class. A program proceeds by sending "messages" towards objects . These messages tell the obj ec t whi c h operation to carry out, and not how; this is determinated completely by the object itself and is hidden inside the class. In this way, identical operations on objects of different nature may be carried out in different ways . Ea c h instance of a class delivers an object with an own "private" memory. Modifications of this private memory can only be carried out by the object itself. This mechanism autanatically guarantees that the implementation of an object will not depend on internsl details of other objects, but onl y on the messages to which it has to respond. This method slso guarantees the modularity of the system. EXPERT SYSTEMS
PROLOG ("Programming in logic" ) was developed around 1970 at the Marseilles university by Alain Colmerauer. At the department for A.I. at the Universi ty of Edingburgh, Prolog was elaborated on by implementing it on a Decsystem-10 by e.g. Warren and Hellish. Prolog is based on the so called predicate logic, and can be regarded as a formal implementation into a 1 anguage of this type of logic. The language starts from objects snd the relation between objects; it proceeds then to wards a consultation of this information by questioning. Thua, we can distinguish J phases : - formulating facts: "predicates"; - formulating" rules", to establish the relation between those facts; - formulating queations. The facts, which are things we know about the world we are moving around, are stored in the data base. The rules which govern the world sre atored in the knowledge bsse.
What is understood as an "expert", has been carefully expressed by P. Johnson, in the following text ( fig. 1) : "An expert is a person who, because of train i ng and exper ience, is able to do things the rest of us cannot; experts are not only profic i ent but also !IIlooth and efficient in the actions they take. Experts know a great many things and have tricks and caveats for appl ying wha t they know to problems snd tasks; they are also good at plowing through irrelevant information in order to get a basic issues, and they are good at recognizing problems they face as instances of types with which they are familiar. lklderlying the behavior of experts is the body of operative knowl edg e we have termed ex per ti se. It i a reasonable to suppose, therefore, that experts are the ones to ask when we wish to represent the expertise thst makes their behsv ior possible".
48
L Bo ulla n
KNOWLEDGE REPRESENTATION AND EXTRACTION
An expert system is composed of 3 important elanents : - the knowledge of facts; - the knowledge of relations between the facts; 8 heuristic, efficient method for storage and acquisition of this information ( "inference" ) .
I
InterrogatIOns Case - studies
(S~)! ~
Knowledge Engineer
EXPERT
I
I
0
0
The key issue in A. 1., and especially in ex pert s yst e ms , is the wa'y kn o wledge is stored and ex trac t ed from the knowledge base. This fact is not only r e l a t e d to the applic ation field itself, but also t o t he fea si bilit y of the application . How ni c e a nd intelligent an e xpe rt s ystem may be, if the tim e to infe r the r e qui r ed answer is too long, it is complet e l y usel e s s . This is especially true in pr oce s s c ontr ol envi ro nments where the real-time a spe c t i s a se vere r e quirement. Therefore, kno wl edg e r epr esen t a ti o n and ex t r ac tion mechanisms not o n ly have t o f ulfill the ir task, but they have to do it ver y qui c kly and effi c i e ntly, whi c h is diffi c ul t to a c hie v e b eca us e of the painful limitation s o f to-day's c omputers!
I
j
t
Answers Solutions
~ -i I I
u
Ther e is no gen e ral rul e f o r knowledge respresentati o n and e xtra c tion. However, some general schanes ar e used in to-da y's applic a tions: - fram e and sc r i pts; - san an ti c ne tworks ; - prod uc ti o n rul es .
EXPERT SYSTEM
Fig. 1 : Ex pert System Building. In the 70' s, especially the last item r ece ived a lot of attention in s c ientifi c resear c h. The importance of this el ement i s crucial f o r an y practical use of expert s ystems, as is str e sse d by Hayes-Roth : "The central notion of intelligent problan solving is that a system must c onstruct its solution selectively snd efficiently from a space of alternatives. When resource-limited, the expert needs to search this space sel ectively, with a little unfruitful activity as possible. An expert's knowledge helps to spot useful data early, suggests promising wsys to exploit them, and avoids low-pa yoff efforts by pruning blind alleys as earl y as possible. An expert system achieves high performance by using knowledge to make the best use of its time."
Becau se mo s t su cc esful implementations employ p ro du c t io n r u l es , t he l a tter pa radigm will be ex pl a in e d mo r e i n de tail. Fo r the oth e r methods the read e r i s r e fered to the literatur e .
PRODUCTION RUl£-8ASEO SYSTEMS General Concepts on production rules Produ c ti o n rul e s originat e from the popular I F ••• THE N str uc ture, whi c h is known in traditional proc edur a l languages. "If the o ven temperatur e becomes higher than 250 d e gr e es Ce l c ius then the thermoswitch is d e fec t". "If the o ven t e mperatur e becomes lower than 50 degrees Cel c i us and i f t he I i ght in th e o ven is on then the th e rmoswi t c h is defect". "If th e out s id e t e mpe rature is higher than 28 d eg r ee s Ce lc ius th e n b e er c onsumption will ri se" .
The construction of an expert system is called "knowledge engineering". The "knowledge engineer's" j ob i s toe x t r act the k now 1 ed g e 0 ut 0 f hum an experts : Le. procedures, stra teg y, rules 0 f thunb and to transfer this into a data base. Multidisciplinary tools are used for knowledg e extration (e.g. interview, video-observation, prototyping, ••• ) .
Thi s IF .• • THE N s tructure is based upon first order logi c ( pr edica t e s ) ; Le. IF A THE N B : L e . When A ~ B "modus ponens" not ( 8) ~ not ( A) "modus toll ens" •
When developing and using ex pert s ystems, a nunber of key people are involved . The relations between these people are drawn in the fig. 2, and demonstrate tha t the ex per t sy stem lo o p has important hunan aspects.
I
0
Q I EXP~R'T
Tool Builder
1
Bu ilding
Interview
(~~)
~
I
Exten sive Testin
Us ing
u u EXPERT SYSTEM TOOL
Fig. 2
0
Knowledge Engineer
-
Bu il ding Testing Tun ing
~~I / u
u
I
EXPERT
SYSTEM
The Human Face of the Ex pert Sy stem Loop.
Data + Knowledge Base
Artificial Intelligence and Expert Systems Rules always contain two parts : - a condition-part, sometimes called "left-handside" (LHS) - an action-part, sometimes called "right-handside" (RHS)
49
~ (
R_E_A_L_ _.....
,-I
One must however be careful with the indication "left" and "right", because in some syntaxes (e.g. Prolog) the "left" (condition) is physically written on the righthand side of the rule. A set of rules can be evaluated in either two different ways: from left to right or vice verse. Those two approaches to the solution reflect two di fferent reasonings and classes of probl ems.
, ,-
---------~. ..... ,
( Knowledge \
Base '
(Rules)
As an example, consider e.g. an expert system for medical diagnoses, with the following rules. If symptom (A) and symptom ( B) end symtom ( C) THEN measles. If symptom (A) end symptom (D) Tt£N measles If symptom (A) end symptom (r.) Tt£N flu.
Consult Rules
INFERENCE
Add/Delete Facts
Consult Facts
ENGINE
The two first rules together form an OR-clause (with each rule itself an AND-clause). In the on and
a left-to-right reasoning, the doctor will ask patient about all possible symptons, write them a scoreboard, evaluate all rules in sequence, tr ies to find out the desease.
In a right-to-left approach, the doctor will suppose the patient has measles, scan the knowledge base to find the measles symptons and then diagnoses the patient for a possible match. Those two reasoning processes are called forward-chaining ("left-to-right") : i t is often referred to as "date-driven" or "bottolT>-up"; - backward-chaining ("right-to-left") : this is also called "goal-driven" or "to~down". The different element of a production rule-based expert system are drawn in fig. 3. The knowledge base contains all the rules. The blackboard contains all known facts: Le. the world to which the system applies in a given state at a particular instant of time. As time goes by, both by external events, or by evaluating rules, the contents of this blackboard may change. The interpreter acts on the given rule set and mainly has to match the lefthand sides in order to succeed the goals or sub-goals ( action ) . One must however be aware that there is a fundamentsl difference wi th a classic al procedural language : in a rulebaaed system, many rules ( IF ••. THEN ••• ) will be "open" (i.e. are executable) in parallel and at the eame time. A special isaue therefore is the problem of confl ict resolution : i.e. the strategy to follow when at a given instsnt of time more than one rule "fires". Several schemes are then conceivable : priority, selecting the first (as in Prolog), recercy strategy, importarce, selectivity etc ••• Finally many operational expert systems offer the user some ex tra fac ili ties in the form of the explanation (tracing) of how a specific conclusion has been drawn. This is very importsnt not only in the development phase to evaluate the system, but also in real operation in order to make the user confident about the suggested ac tions.
Proloq
88
/
World
I.
Fig. 3 : Production Rule System. measles:-symptom(A) ,symptom(S) ,symptom(C). measles:-symptom( A) ,symptom ( D). flu:-symptom(A) ,symptom(E) . As Prolog contains in itself also an inference engine, Prolog can be seen as a production rule system. It employs the backward inference procedure. Prolog evaluation is a goal searching procedure, whereb y a goal is asked for and then all necessary conditions ("sub-goals") are searched in order to try to attain the main goal. E.g. the above mentioned eXllllple thermodefect:-temp( oven ,X) ,X(50,ovenlight. is evaluated by asking Prolog ?-thermodefect. Then Prolog will 1) measure the temperature; 2) compare this as "(50" 3) look at the ovenlight. Only is if all sub-goals succeed ( "and" clauae) Prolog will answer" yes" . The action "measure the temperature", which is typical for a real-time system, can be implemented in two ways : - as a rule in the knowledge base, activating some spec ial ( non-Prolog ) routine to actually meaaure the temperature; - as a fact: i.e. the engine will look at the blackboard for something like "temp(oven,40)"; this approach inherently suppose some other mechanism (probably a conventional foreground program in the computer) is present (see also fig. 3) which periodically scans measurements and adapts the facts on the blackboard correspondingly. The latter approach is substantially better, espec iall y from real-time and performMce con&trains, although PC-tools often choose the first.
a Production Rule Systa.
The "translation" of the above eXllllples into Prolog is straightforward Md much conciser : thermodefectl-temp( OVe-l,X) ,X>250. thermodefec t:-temp( oven, X), X(50, ovenlight. raiae_beer:-temp(outside,X),X>2B.
In order to have a full operational system, this is only part of the story. There should indeed by a kind of "sutopilot" : i.e. a progrllll which continuously and automaticslly questions the system for results. Just having a program which cyclically asks all possible questions would be high! y inefficient. Some methodology therefore should be intro-
L. Boullart
50
duced. This could be some feed-forward mechanisn which after changing facts on the scoreboard tr i9gers all involved rules. The read er sho uld al so real ize tha t the &bove exIIIIIple ia rather simple. In practice a questioning involves a complex evaluation procedure of many linked rules/facts. It can be seen as an (inverted) tree traversing process, wi th many backtracking (i.e. on failure of a branch) before a succesful answer eventuall y could be found.
There are many explicit rule-based programming systems canmercially available on the market. They are sometimea called "shells". Mostly they operate in a forward way, but backward evaluation can often be obtained by introducing extra facilities in the language to create goals, subgoals, e.o. A rather aimple, however powerful rule based system, called "CLIPS" developped at the Artificial Intelligence Section of tho! Jomson Space Center, and available on the public domain, will be used in the next examples. It shows a close relationship in structure (although there are slight differences in the evaluation procedure in the conflict set) with the OPS5 expert system language from OCC. In order to set the idea about rule-based shells, the basic elements of CLIPS wil be summarized. a. Dealing with facts. Facts can be entered ("asserted") onto and deleted ("extracted") fran the scoreboard. This can be done either directly (i.e. conversationally from the terminal) or fran within the action part of a rule e.g. (aasert (valve boiler-fuel open)) (extract l) The extract command calls the internal fact number, which can be obtained by displaying all facts at the terminal, or by putting a fact in a reference variable (inside a rule). The system makes a difference between initial facts (Le. those asserted before the program starts operating) and the facts asserted/extracted during progrlllll evaluation.
=>
(extract ?cl ?c2) (assert (temp-alarm on)) (assert (valve boiler-fuel closed)))
Thereby is "test" an internal procedure for logical testing. Al though those example give a clear insight in the principlea of the language, the reader should be aware that the language is much richer in capabilities (e.g. on pattern matching, computing procedures, logical constructs, ••• ). Also facts can be "time-stamped" (i.e. giving a unique identification) which is very important in goal-seeking strategies. Furthermore extensive debug and tracing facilities are available. A real-life problem consists of many such rules which in a consiatant way interact with each other by means of the facts on the scoreboard. As already stressed out, all rules in principle act in a kind of parallellisn. After a canplete rule is executed, the system confronts i tsel f wi th a new si tuation (the scoreboard could have been changed) and makea a "notebook" of all rules which are executable at that particular point in time .. This agenda is called the "conflict set". Then it must proceed by choosing only one out of all possible rules. In CLIPS this is simply done in a flFO-kind of way, but in other similar systems more sophisticated mechanisms exist : e.g. OPS5 tries to catch the importance and the tipecificity of each rule. This evaluation procedure is of the highest importance, and the user should understand the underlying strategy of his rule-based system on-hand very well in order to write efficient and correct "programs". From the operational env ironment point of view, there is a significant difference between PROLOG and a rule based system. Whereas in PROLOG, the user must interactively ask all questions, a rule based system operates wi th a recognize-act cycle. Thereby after placing the initial facts on the scoreboard, the user starts the system, which afterwards runs by itself until it finds itself with an empty notebook. At that time the progrsn is over. A RlLE-BASED SIMlLAT!Jl F!Jl
CONTINUOUS DYNAMIC SYSTEMS b. Dealing with rules. A rule is an independant entity with a name and a body. The body consists of the condition part and the action part. The condi tion part apeci fies a number of facts which ill must be preaent before the action part is engaged. (defrule boiler-control (boiler-tEmp high) (boiler-pression normal)
=>
(assert (valve boiler-fuel closed)) (sssert (temp-alarm on)))
The lsnguage alao recognizes variables, which remain locally within the rule itself. They can be referred to both in the lefthand and righthand side. They can contain different items (atom, facts) and matching should lexicographicslly be exsct. (A variable is preceded by a "7 "-mark .) (defrule boiler-control (boiler-temp 7tl) (boiler-pression 7pl) (test (> 7tl 150)) (test « 7p120) 7cl <- (tEmp-alarm off) 7c2 <- (valve boiler-fuel open)
As an ex ample of an application where A. 1. -tecmiques could open new insights and perspectives, a rule-based simulator for simulating continuous dynsnic systems is discussed. Continuous dynsnic systems are those systems which are mathematically represented as a set of differential equations eventually coupled with algebraic equa tions. Bo th process and control systems can often be represented in such form. Simulating such systems could be done in two ways. The most natural way is to use analog computers, because the y 0 ffer the nec essary speed, inherent parallelism and the independancy from the size of the system. Many years ago, this was the only way to proceed. Although nowadays such canputers are still intensively used in special high demanding environments, in most cases they are replaced by the cheap equivalent of digital computers. Several software packages are available for the user to simulate such ayatEms by digital canputers. The way those packsges proceed to enter the simulation model is twofold. Some packages have an algebraic approach: i.e. the (differential) equations are entered in a procedure resembling conventional Fortran programs. Other packagea have a block oriented procedure: the user has to draw a block diagram of hia system, which thereafter is codad into a program table. The latter method ia often used by process engineera, because they are very fEmiliar with this kind of block diagrams.
Artificial Intelligence and Expert Systems We will deal in this paper witht he second method. It is obvious that in such representation schemes, many levels of abstraction are feasible; this solely depends upon the complexity of the blocks in the simulation model and it can range from a simple adder or integrator up to a full complex controller. This level of abstraction reflects itself in the computer program by the complexity of the corresponding computational routine. The reader will further notice that it also holds true for the rule-based simulator. In fig. 4 a block model is drawn using blocks with the func tion "integrator", "adder", "invertor" and "printer" .
51
The figure 5 shows the initial facts of the dllnped osc illator of figure 4. One clearly distinguishes the following elements : - the type of each block number e.g. (block 2 type integrator) - the connector scheme e .g. (from 1 to 2 3) - the initial values of the state varisbles e.g. (at 0 integrator I output I) - the parllneter values e.g. (integrator 2 par +2) - integratfun control e.g. (step lOO) - output control e.g. (print-interval 5)
------------------------------------; Initial model confi,uT.lion; : Ihis is in flct the datl - base and the scoreboard of the model.
------------------------------------(deHlcU simulation - modcl- waves (block I type intelTaCor) (block 2 type inle,rllor) (block 3 Iype summer - 2)
(block .. type lummer-2) (block' type print) (block 6 type invertor) (from I to 2 3)
fig. 4 : A block model for an oscillator. The equation for this model can easily be derived as follows
y1 = -2z y 1 + 2y
z
Y = 2y 1 Substitution leads us to the differential equation y +
2y
+ By
0
which is a simple damped oscillator system. To formalize this model, each block is given a block number 0 ... 6}, and a connection matrix could be set Lp. In a rule based environment, this system can be simul ated as follows. At esch step in the integration process, the output of each state variable csn uniquely be characterized at the scoreboard as a fact with the following form :
(from 2 10 .. 5) (from 3 10 6) (from 610 I) (It 0 inte,r.lor I output I)
0 intcarltor 2 output 0) (intcaTator I par + 2) (inlClralor 2 plr +2) (summer-2 3 pari I) (summer - 2 4 par2 2) (endtime 4) (I'
(Slep 100) (print-time 0) (print- inlerval $) (plot-time 0) (plol- inlerval $) (plot - scale 80)
(plot-oH ... 40))
Fig. 5
Initial facts for the simulator.
The figure 6 gives as an eXllnple two "computational" rules, one for a state variable (integrator) and one for an algebraic variable (summer). One osverves that for the integrator a new output fact is asserted on the scoreboard, whereas for tha summer the output value is immediately dispatched.
;------- --- ------------- --------; Definition of block - types
(at x block-type y output z) where x y
z
time-value block-number output value (atate variable value)
e.g. (at 5 integrator 2 output 0.03). The rule-based aimulator containa also a so called scheduleI', which - knowing the connection scheme between all blocks - diapatches all outputs to the necessary inputs the moment they are available. At laat, each block ia represented by one rule ..t1ich ia triggered by the matching of facts which represent all necessary inputs at each time frllne. The action pert retracta this input facts from the scoreboard, and aaserts the new output fact (for a state variable) or diapatches immediately values for other block-typea. Remembering the time step in each fact ia strictly neceasary because otherwise the computation at the block-rulea would mix Lp resul ts of different iterations of the feedback scheme. It should be stressed out that in the simulator there is only one rule for each blocktype (even if there are more identical blocks in the model), and that each block itself is a runtime instantiation of the rule.
;--------------------------.----(defrule inlearalor -type ?c I < - (al "li me inte.rator 1numb ?v al) 1c2 < - (11 1ti me inle.rator 1numb output ?valout) (step 1uep) (intearltor ?numb par 1p) (relrlct ?cl 1(2) (bind ?newvII (+ (I (. 1vII ?p) ?uep) ?vllout) (assert (11 - (+ ?Iime I) intearator ?numb output ?newvII)) (auere (displlcb II - (+ ?Iime I) ?newvII (rom inlearator ?null'lb»))
;--- ---_ ._._--------.--- .... - .. _.(defrule summer - 2 -Iype ?c I < - (al ?Iime summer - 2 1numb 1 ?nll) ?c2 < - (11 ?time summer - 2 1numbl ?vaI2) (tu t (. ?numb2 (+ ?numb I I») (summer - 2 1numb I par I ?p I) (summer - 2 ?numb2 parl 1p2) (retract 1c I ?('2) (auert (displlch 11 ?time .(+ (e ?vall 1pl) (. ?va12 ?p2)) (rolD summer - 2 ?numbl»))
;-- .. --._---------- .. -- ... - .. - ... Fig. 6 : The "integrator" end "aummer" computational rules.
52
L. Boullart
To demonstrate tha t output-control is a straightforward matter, the figure 7 gives the corresponding rule. An important observation when looking, at this procedures for driving a simulator is that it is a real implementation of what is know in ccmputer science as a data-flow machine. The system is very characteristic in this perspective because it tackles a very hughe problem in data flow in a elegant way: i.e. the unique identi fication of each iteration in the feedback loop. This problem, which is known as "coloring" in data flow, is solved here by adding a time stamp to each iteration sensitive fact. ; • • - - - - - - - - - - - - ___________ 2_KZ
_______ _
DUlput rules :
outPUI- prinl provides I list If resuhs output - plot provided
I
simple print - plot
with ,cale (plol- scale xx) and of het (plot-offset fYY)
;-----------------------._-----------(defrule outPUI- print (dcrl.re (&alienee 100»
1c I < - (I' ?Iime print ?numb 7val) ?c2 < - (prinl-timc ?time) (print - internl 7inter) (step 'step)
?(2) (bind ?temp (I ?time 71lcp)) (printout 'temp" _. - "7nl ctlf) (Iller. (print-time -(+ ?time 7inter)))) (rCUICI 7c1
Fig. 7 : Rule for output control.
CON:lUSlON By glvlng an overview of the field of A.I. and E.S. this paper clearly shows an important number of tools are available to the user to apply these new techniques. More and more such tools are readily available to-day on all types of ccmputer systems, ranging from small PC's to larger mini's and mainframes. The application of the rule based simulator demonstrates that by implementing a classical problem wi th the new tools, ccmpletely new ideas and insights in the problem can be drawn and interesting perspectives in related research fields open up.
BIBLIOGRAPHY 1. 'Astrom K.J. et a1. "Expert Control", Automatica, 22 (3), (1986). 2. Baldwin J.F. "Support Logic ProgrElllming for Expert Systems", paper presented at BIRA workshop on expert systems, 24 sept. 1985. 3. Boullart L. "Expert Systems", Monogra~ic seriea on Automatic Control 1, Belgisch Insti tuut voor Regeltechniek and Automatisering, Antwerpen (1987) • 4. Boullart L. "Using A. I.-tools for progrElllming Programmable Logic Controllers", Proc. European Simulation Hulticonference, Society for Ccmputer Simulation, Vienna, ( 1987). 5. Boullart L. "Artificial Intelligence &: Expert Systems : new issues in process control", Journal A, £!!. (3), (1987). 6. Boullart L., Delbar P., VandElllme F., Heeffer A. "Expert-Driven industrial process control", Flanders Technology, International Seminar (1987) • 7. Brady H., Gerhsrdt L., Davidson H. ( Eds.) "Robotics and Artificial Intelligence", SpringerVerlag, Berlin (1984). 8. Clocksin W. F., Hell ish C. S. IIp rogramming in Prol2.g", Springer-Verlag, Berlin (1981). 9. Delbar P. "A parallel approach to rule based systems", Eurcmicro (1987). 10. Delbar P. "Technische Toepessingen van Expertsystemen", Het Ingenieursblad, 22. (2), (1987). ll. De Swaan Arons H., Van Li th P. "Expert ~ temen", Academic Service (1984). 12. Efstathiou J. "Introduction to expert systems", Journal A, 27 (2), (1986). 13. EfstathiouJ. "The Chocolate Biscuit factory", Journal A, 27 (2), (1986). 14. Feigenbaum E., McCorduck P. "The fifth generation", Addison-Wesley (1983). 15. Freedman R., Frail R. "~gen : The evaluation of an Expert System for Process Planning", AIMagazine, 2 (5), (1986). 16. Goldberg A., Robson D. "Smalltalk-80", AddisonWesley (1983). 17. Haspel D. "Application of rule-based control in the Cement Industry", paper presented at the BIRA Seminar on Expert Systems and Artificial In tell igence in Industry, (l986). 18. Hayes-Roth B. "A Blackboard Architecture for Control", Artificial Intelligence, 26 (3), 251322 (1985). 19. Steels L. "Programmeren in Lisp", Academic Services (1983). 20. Waterman D. "A guide to expert systems", Addison-Wesley (1985).