Guest Editor'sIntroduction

Se June HongIBM I J. Watson Research Center

JExpert (or knowledge-based) systems

represent a relatively new program-ming approach and methodology,

one that evolved and is still evolving as an

important subarea of artificial intelligenceresearch.The main difference between expert sys-

tems and conventional programs lies notin the delivery of expertise, for many con-ventional programs can perform "expert"tasks. Rather, it lies in the way the pro-grammer makes use ofthe different degreeof separation between the dynamics ofwhen to do what to perform a task on theone hand, and the "static" (that is, non-procedural) application-domain knowl-edge on the other hand.

In early programs, data and code were

often intermixed. Modern-day programs

generally have clearer separation betweendata and program constructs. The expert-systems approach permits even greaterseparation by providing nonproceduralconstructs on a still higher level. Such

separation usually allows more flexibilityin generating and maintaining the pro-gram, as well as greater ease of under-standing, at the cost of run-time overheadnecessitated by the underlying mech-

anisms that support it. This kind of trade-off is well demonstrated by comparinglogic simulation programs: compiledsimulation versus table-driven simulation.For many applications, especially those

we usually think of as belonging to somedomain of expertise, it is usually impossi-ble to define the total flow ofactions takenby a human problem-solver. Expertise is,however, often describable in bits andpieces, each relating some small situationcontext and the actions appropriate for thesituation. Expert systems provide a

mechanism (often referred to as an in-

ference engine) to thread these piecestogether dynamically at run-time so as tosuccessfully complete a task. Conven-tional programming basically allows two

simple options:

0018-9162/86/0700-0012SO1.00 0 1986 IEEE

J

I

12 COMPUTER

* test and branch, or* do the next action in the list.

While these two are sufficient for any pro-gramming task, programmers suffer ifthey must write programs at this levelwhen the domain involves expertise that isnot thus resolvable.

Characteristics of anexpertAn expert not only possesses a store of

definitional (or declarative) knowledge ofa domain, but also can quickly apply theknowledge to a given task. Therefore, toemulate the problem-solving skills of anexpert, it is not sufficient to encode thedeclarative knowledge separate from theprocedural component of the expertise,leaving the latter to proceed in the fixedway provided by an inference engine. Agood example of this is a chess programwritten in a few pages of Prolog, completewith a goal to checkmate. With only thedepth-first backtracking mechanism ofProlog, it would take eons to generate themoves for a winning play-hardly an ex-pert player's behavior. Procedural knowl-edge in the expert-systems context ad-dresses issues at a much higher level (thatof determining the relevancy of actionsand subgoals) than the notion of instruc-tion flow found in conventional programs.

Three things are essential to being an ex-pert. First, an expert has knowledge of theconcepts relevant to the domain, its tax-onomy, and interrelationships amongthem; if necessary, the expert can solvenovel problems by reasoning from the do-main principles. Second, an expert has awealth of situation-specific, ready-madeanswers or partial answers that shortcutthe problem-solving process. Third, an ex-pert has the ability to recognize oppor-tunities for using such shortcuts, and in-vokes the right "situation-action pair" sothat focused progress is made toward com-pleting the given task.

The state of the art

-Declarative knowledge. There is areasonably useful array of schemes torepresent this first kind of knowledge,although most of them can describe onlysimple relationships among concepts.

Theorem-proving techniques can be usedfor reasoning from the domain principles,ifno surface heuristics are available. How-ever, theorem-proving is inherently expen-sive computationally, and the burden is onthe programmers to fmd as many short-cut rules as possible to minimize "deepreasoning." Most of the current genera-tion of expert systems relies solely on thesituation-action paradigm and gives up inthose cases where only deep reasoning canprovide the solution. Providing special-purpose reasoners, and representationsfor efficient deep-reasoning capabilities inspecific domains, is an active area of AIresearch.

Ready-made knowledge. Handling thesecond type of knowledge is the forte ofstate-of-the-art expert systems. Thesituation-action knowledge is imple-mented as demons, as actions to be takenon an if-needed basis within a frame, and,most commonly, as explicit rules. The ini-tial success of expert systems was largelydue to their ability to capture this kind ofknowledge and make inferences with it.Still, there is much progress to be made inimproving the expressivity of the rule lan-guage. Inference engines that invoke theserules in sequence are currently rather in-flexible, regardless of whether the se-quencing is basically goal driven or datadriven. Rules usually describe appropriateactions in a given situation, but whetherdoing the consequent action now is rele-vant to the task at hand is often notknown. Most ofthe current-generation in-ference engines, both goal driven and datadriven, provide depth-first invocation ofrules, with some limited variations.

Meta-knowledge. The third kind ofknowledge is perhaps the hardest to elicitfrom an expert-even when the program-mer is the expert. Imagine rules as seg-ments of a flowchart that is cut up intopairs consisting of a "test" diamondfollowed by a "procedure" box. Withoutknowing which segment should followanother segment, it would take an enor-mous amount of trial and error for some-one to perform the program tasks man-ually-if they could be performed at all.Exaggerated though the analogy may be,essentially this difficulty is reflected in theinference mechanisms that are in usetoday. Meta-rules (the use of tags or flags

An expert not onlypossesses a store ofdefinitionalknowledge of adomain, but also canquickly apply theknowledge to a giventask.

attached to data) and explicit control lan-guages are attempts to harness this thirdkind of knowledge; that is, the knowledgeofwhen to invoke what at various levels ofdetail. Much ofthis procedural knowledge(or meta-knowledge), which producesfocused progress in task performance,may becommon to all problem-solving ac-tivities, while some must be domain spe-cific. Either way, the means of capturing itrepresents perhaps the weakest part of ex-pert systems today. Consequently, this isan active Al research area. The problem isaccentuated in engineering applicationsthat have many alternative methods andhigh demand for procedural efficiency.

The field today

Expert systems expand the use of com-puters to many applications for which theyweren't being used at all or were beingused unsuccessfully within conventionalprogramming practices. Many successfulexpert-systems applications are beginningto appear in medicine, business, finance,and engineering. Also, many tools forbuilding expert systems, in the form ofshells and programming environments, arebeginning to be commercially available.'

There have been high expectations and acorresponding flurry of activities in thisarea. This brought on some myths and in-flated expectations about the state of theart and the limits of expert systems. Readyavailability of expertise, the need for intel-ligent programmers, user-friendly inter-faces, the sound practice of softwareengineering principles, and convenient de-velopment environments are no less im-portant to expert-systems applicationsthan to traditional programs. Automaticacquisition and compilation of knowledge

13July1986

Automatic acquisitionand compilation ofknowledge is still agoal of Al for which

research is justbeginning to yieldsome very limited

results.

is still a goal of Al for which research isjust beginning to yield some very limitedresults. Performance and verification con-cerns are perhaps more serious for expertsystems than for conventional programs.Yet, it is clear that more applications are,indeed, enabled by this addition to soft-ware technology. The articles in this issuerepresent some of these engineering appli-cations and some efforts at advancing thestate of the art so that more engineeringapplications will be made possible.

In this issue

The purpose of this special issue is notto give a survey or a tutorial on expert sys-tems, but rather to share examples of engi-neering applications that depict the advan-tages, the current limitations, and thekinds of tasks being addressed. Engineer-ing applications may not be genericallydifferent from the applications of expertsystems in other areas, but the articles herepresent samples of what is stressed in engi-neering applications. For an introductoryreading in expert systems, articles that ap-peared earlier in Computer2-4 wouldmake a good start.The articles selected for this issue were

chosen for the maturity ofthe applicationsthey describe, their appropriateness (in ad-dressing some of the technical issues of ex-pert systems), and because as a group theypresent a balanced variety of applicationsand R&D activities. Many of these articlesalso demonstrate the need to integrate theknowledge-based part of the system withexisting software and databases.The first paper, by William Faught,

discusses four different applications builton KEE. (KEE is a multi-paradigm pro-

gramming environment that featuresframe-based knowledge representation. 5)It emphasizes the importance of clear, visi-ble models and advocates building a fullsystem by starting out with a bag of toolsor an intelligent workbench.The next paper, by Giorgio Bruno, An-

tonio Elia, and Pietro Laface, describesproduction scheduling for flexiblemanufacturing systems, for which there isno known algorithmic solution. Theauthors make use of an intelligent,discrete-event simulation that is writtenpartly in OPS5 rules and partly in Fortrancode. (OPS5 is a popular data-driven in-ference engine. 6) Although they note theflexibility and ability to incrementally de-velop the system that this approach makespossible, they report on the difficulty ofmaintaining data integrity between thetwo types of programs.Gary Stroebel, Randy D. Baxter, and

Michael J. Denney present a planning,design, and evaluation system for config-uration of the IBM System/38 computer.This application makes use of many ex-isting programs in the course of perform-ing a variety of tasks in an interactive ses-sion. Performance modeling is in APL;workload analysis, user-interaction han-dling, and the configuration generator arein Pascal. An evaluation function has beenimplemented in three different versions:Lisp, OPS5, and ESE. (ESE uses the goal-driven inference in a manner similar to itsuse in Emycin, with an additional mech-anism to specify certain controls.7) Theglobal control and communication amongthese different modules is patterned afterthe blackboard model. The authorsobserve that it was convenient to use shellsbut add that they found them to be moreawkward at times than straight Lisp, acasein point revealing the limited expressivityof knowledge representation in the currentstate of the art.The blackboard architecture is intended

for capturing and utilizing the controlknowledge. 8 While this mechanism in itsfull generality allows flexible and explicitrepresentation of high-level proceduralknowledge, the overhead makes it imprac-tical for performance-oriented applica-tions. Many systems implement a simpleform of such a mechanism.

Sarosh N. Talukdar, Eleri Cardozo, andLuiz V. Leao also make use of a simplifiedblackboard model to coordinate several

different specialist modules in their sys-tem, Toast. The domain deals with moni-toring and controlling utility power sys-tems as an aid to human operators. Thesystem has two parts: an off-line consulta-tion part that has been implemented, and areal-time, on-line control part that has yetto be implemented. OPS5 has beenadapted to run concurrently within theirdistributed problem-solving environment,called Cops.

Frank Pipitone reports on an expertdiagnostic system for electronic circuits.The system has information on failureprobability, a list of tests, and a list ofcosts. The system finds the "best nexttest" to apply, and upon receipt ofthe out-come, updates the "current resolution"listing. This system is unique in that ex-plicit probability calculation is directlyused with inferences made from compo-nent-wise behavioral rules and a com-ponent connectivity description. This sys-tem is written in Franz Lisp.

P. A. Subrahmanyam's Synapse systemwill be a large, complex system when com-pleted. Intended for designing VLSI chipsfrom specification to physical layout, thesystem is designed to deal with multilevel,multiperspective descriptions of the chipdesign in progress. Maintaining an alge-braic model of the intended VLSI func-tion, the system makes a series of refine-ment transformations on the model by useof production rules. This system also in-terfaces to many existing programs and tospecial-purpose hardware. The theorem-proving part is written in Pascal, themanipulation of algebraic models is doneby Macsyma, algorithmic CAD work isdone by a VLSI workstation, and the rule-based expertise is implemented with theKEE system.The next two articles describe mechan-

ical-design systems. David C. Brown andB. Chandrasekaran discuss a languagedesigned to capture the task-level knowl-edge used in creating routine designs."Routine design" refers to those designproblems in which the intended function iswell understood and the basic configura-tion of the design is known. (Nevertheless,the designer has to make design choicesbased on complex requirements, and thenrefine and specialize the chosen configura-tion.) This article represents a research ef-fort to provide knowledge representationclosely matching a particular kind of ex-

COMPUTER14

pertise, in this case that of routinemechanical design.

Sanjay Mittal, Clive L. Dym, andMahesh Morjaria, on the other hand, at-tack nonroutine design-for paper-trans-port systems. Their article identifies, interms of generate-test-analyze-modifycycles, necessary concepts for searchingthrough a large design space. Their use ofmultiple specialists to handle designsubgoals is similar to Brown and Chan-drasekaran's. Their system already con-tains over 1000 objects implemented inLoops. (Loops is a multiparadigm pro-gramming environment that featuresobject-oriented style. 9) The authors alsodetail the experience in knowledge acquisi-tion that they gained, which resulted in a100-page document ofpaper-handling sys-tem expertise.The last paper is by Yi-Tzuu Chien and

Jay Liebowitz, who present a variety ofdefense-oriented application areas, alongwith system-level requirements. Theauthors point out a list of advances yet tobe made before such expert systems can bepractically implemented. These require-ments and areas of necessary further pro-gress are not unique to defense applica-tions, nor to engineering applications. M

Acknowledgments

I would like to thank Mike Mulder, theeditor-in-chief of Computer, and thedesignated member of his editorial board,the willing and able Ralph Preiss, whoread all the manuscripts and with whom Iconsulted during the preparation of thisspecial issue. I thank all the reviewers fortheir thoughtful reviews and all theauthors who submitted their work for con-sideration in this issue. Eric Mays and JimGriesmer helped me in selecting thereviewers and provided me with a numberof helpful suggestions for this introduc-tion. Last but not least, I would'like toacknowledge the able secretarial helpgiven me throughout the process byEvelyn Zoernack.

References1. Donald A. Waterman, A Guide to Expert

Systems, Addison-Wesley, Reading,Mass., 1985.

2. Dana S. Nau, "Expert Computer Sys-tems," Computer, Feb. 1983, pp. 63-85.

3. Computer, special issue on knowledgerepresentation, Oct. 1983.

4. E Hayes-Roth, "Knowledge-Based Ex-pert Systems: A Tutorial," Computer,Sept. 1984, pp. 11-28.

5. R. Fikes and T. Kehler, "The Role ofFrame-Based Representation and Rea-soning," CACM, Sept. 1985, pp.904-920.

6. L. Brownston et al., ProgrammingExpertSystems in OPS5, Addison-Wesley,Reading, Mass., 1985.

7. P. Hirsch et al., "Interfaces for Knowl-edge Base Builder's Control Knowledgeand Application-Specific Procedures,"IBM J. R&D, Vol. 30, No. 1, Jan. 1986,pp. 29-38.

8. B. Hayes-Roth, "A Blackboard Architec-ture for Control," Artificial Intelligence,Vol. 26, No. 3, July 1985, pp. 251-321.

9. Mark Stefik et al., "Knowledge Program-ming in LOOPS: Report on An Exper-imental Course," Al Magazine, Vol. 4,No. 3, Fall 1983, pp. 3-13.

Se June Hong received his BSc degree in elec-tronic engineering from Seoul National Univer-sity in 1965, and his MS and PhD degrees inelectrical engineering from the University ofIllinois in 1967 and 1969, respectively. He thenjoined IBM Poughkeepsie Laboratory, work-ing in the areas of fault-tolerant computing anddesign automation. He joined IBM Thomas J.Watson Research Center at Yorktown Heights,New York in 1978. He is currently a seniormanager in the Computing Technology Dept.,responsible for projects in computer algebra,natural language, education, and knowledge-based programming.

During the academic year 1974-75, Hong wasa visiting associate professor at the Universityof Illinois, Urbana. He was a visiting professorat the Korea Advanced Institute of Science andTechnology (KAIST) for the month of October1980.

He received an honorable mention award forOutstanding Young Electrical Engineer in 1975and three outstanding innovations awards fromIBM. He served as a Computer SocietyDistinguished Visitor, 1972-74; the guest editorof the special issue on reliable and fault-tolerantcomputing of IEEE Transactions on Com-puters, which appeared in July 1982; and as amember of the Ad Hoc Visiting Team for theIEEE Engineering Accreditation Board,1979-84. He is currently a member of theEdison Medal Awards committee.Hong is a fellow of IEEE and a member of

ACM, MAA, ACL, AAAI, KSEA, and SigmaXi.

Readers may write to Se June Hong aboutthis special issue at IBM T. J. Watson ResearchCenter (31-206), PO Box 218, YorktownHeights, NY 10598.

7;

36 papers organized into 13 sessions. This con-ference was concerned with both principles andpragmatics, with the major theme being "the use

of ER concept in knowledge representation."350 pp.

Order #645Proceedings-The 4th IntemationalConference on Entity-Relationship

ApproachNonmembers-S45.00Members-S22.50

Handling Charges Extra

Order from IEEE Computer SocietyOrder Dept.

PO Box 80452, Worldway Postal CenterLos Angeles, CA 90080 USA

'1 _ (714) 821-8380 /

July 1986

- -

15