Claremont CollegesScholarship @ Claremont

All HMC Faculty Publications and Research HMC Faculty Scholarship

1-1-1987

Issues in the Design and Implementation of ExpertSystemsClive L. DymHarvey Mudd College

This Article is brought to you for free and open access by the HMC Faculty Scholarship at Scholarship @ Claremont. It has been accepted for inclusionin All HMC Faculty Publications and Research by an authorized administrator of Scholarship @ Claremont. For more information, please contactscholarship@cuc.claremont.edu.

Recommended CitationC. L. Dym, “Issues in the Design and Implementation of Expert Systems,” Artificial Intelligence for Engineering Design, Analysis andManufacturing, 1 (1), 37-46, December 1987. DOI: 10.1017/S0890060400000135

Articial Intelligence for Engineering,Design, Analysis and Manufacturinghttp://journals.cambridge.org/AIE

Additional services for Articial Intelligence forEngineering, Design, Analysis and Manufacturing:

Email alerts: Click hereSubscriptions: Click hereCommercial reprints: Click hereTerms of use : Click here

Issues in the design and implementation of expertsystems

Clive L. Dym

Articial Intelligence for Engineering, Design, Analysis and Manufacturing / Volume 1 / Issue 01 / February1987, pp 37 - 46DOI: 10.1017/S0890060400000135, Published online: 27 February 2009

Link to this article: http://journals.cambridge.org/abstract_S0890060400000135

How to cite this article:Clive L. Dym (1987). Issues in the design and implementation of expert systems. ArticialIntelligence for Engineering, Design, Analysis and Manufacturing, 1, pp 37-46 doi:10.1017/S0890060400000135

Request Permissions : Click here

Downloaded from http://journals.cambridge.org/AIE, IP address: 134.173.130.137 on 31 Jan 2014

(Al EDAM) (1987) 1(1), 37-46

ISSUES IN THE DESIGN AND IMPLEMENTATIONOF EXPERT SYSTEMS1

CLIVE L. DYM

Department of Civil Engineering, University of Massachusetts at Amherst, Amherst, MA 01003, U.S.A.

This article discusses the issues that arise in the design and implementation of expert systems. These issues include: taskselection; the stages of development of expert system projects; knowledge acquisition; languages and tools; development andrun-time environments; and organizational and institutional issues. The article closes with some speculation about the futuredevelopment of expert systems.

1. Introduction

This article is concerned with the process of buildingan expert system and, as such, its focus is on thequestions of how such a system is implemented orbuilt. For the purpose of this discussion, an expert (orknowledge-based) system is one that uses knowledgecaptured from experts to solve problems or do tasksthat involve reasoning. Such systems differ fromconventional algorithmic programs in that theyincorporate heuristics and other rule-oriented reason-ing aids, and their architectures typically represent aseparation of the control of the program from theknowledge of the domain (Dym 1985a). The tenor ofthe discussion is discursive and tutorial, and pointersto some of the salient literature are given. Among theissues addressed that arise from implementation of asystem are the following:

What tasks are suitable for encapsulation within anexpert system? What are the stages of development ofan expert system?

How is knowledge acquired? Can more than oneexpert be used? How are the experts interrogated?How is conflict (among several experts) resolved?

What are the technical issues? What are theappropriate languages and tools for developing aserious system? What are the appropriate languagesand tools for running or delivering a rapid andefficient system? How do tools and languages relate tohardware?

Received 3 February 1987.

' T o appear in revised form as Chapter 3 of M. L. Maher (Ed.),Expert Systems for Civil Engineering: Technology and Applications,New York; American Society of Civil Engineers, 1987.

0890-0604/87/010037+ 10$02.00/0

What are the issues for the organizations thatundertake the building of expert systems? Are expertsystems expensive? How is access to the expertsguaranteed? How important is the commitment ofmanagement? What are the advantages (i.e. com-munity memory, standardization, training and educ-tion) to management?

The article concludes with some speculation on futureissues in the building of expert systems, especiallythose that appear to be affected by the advent ofparallel architectures. The most intriguing prospecthere is the possibility of successful interaction ofmultiple expert systems acting concurrently.

Finally, it is again noted that the treatment of theseissues is discursive and somewhat idiosyncratic,heavily conditioned by the author's own experience inthis field (Dixon and Dym, 1986, Dym, 1985a, 1985ft,1987, Mittal and Dym, 1985, Mittal et al., 1986,Morjaria et al., 1985).

2. Task selection and the stages of development

Careful selection of the task to be encapsulated in anexpert system is essential for the success of the systemdevelopment project. Several criteria for choosingprojects and tasks have been enumerated (Bobrow etal., 1986, Dym, 1985a, Prerau, 1985) and will besummarized here. It will subsequently be seen that thewinnowing of a list of candidate projects according tothese criteria is the first stage ('identification') in thedevelopment of an expert system.

The task to be modelled in an expert system mustbe clearly defined, rich in reasoning, and one that isperformed by an expert reasonably often and within a

37(O 1987 Academic Press Limited

38 C. L. Dym

reasonable period of time. The task itself should befairly narrow and domain-intensive. It ought not todepend on a lot of general and commonsenseknowledge about the world, and the number ofrelevant concepts should be bounded and not undulylarge. If it is not rich in reasoning, and if morespecifically the task is capable of algorithmic solution,it is not appropriate for expert system encapsulation.

What is a reasonable length for the time it takes todo a task that will be captured in an expert system?The conventional wisdom has it that the time shouldbe measured in hours, rather than in weeks ormonths. It appears, however, that this is too simple ananswer. In fact, there are some tasks that take weeksor months that require a lot of repetitive and tediouswork that can be successfully modelled in an expertsystem (Dym et al., 1987). The real issue is theunderlying complexity of the task and the degree towhich it involves much creative thought. If a taskrequires days or weeks of original and creativethought by an expert, then it is more than likely notsuitable for encapsulation.

There should be available a substantial library ofcase studies or test cases. This library is useful in theknowledge acquisition process (see Section 3), fortesting implementations of the system, and forconfirming that the criteria for task performance timeand frequency have indeed been met. Test cases arenot readily produced if the task is performed onlysporadically, and a lack of repeatability or taskconsistency is also signalled by a paucity of casestudies. The examination of a set of cases also helpsensure that more of the knowledge is exposed, fordifferent examples expose new heuristics that were so'completely obvious' in—or not relevant to—the casesalready examined.

The task must have clear—and typically economic—value to the organization sponsoring the developmentof an expert system because, as will be seen in greaterdetail below, the building of an expert system isexpensive and time consuming. Thus, the expertsystem must be capable of producing substantialbenefit for the sponsor to justify the committment ofsufficient resources to insure a successful outcome. Aparticularly interesting example of this is theR1/XC0N system developed by the Digital Equip-ment Corporation (DEC) which will be discussed insomewhat greater detail in Section 5 (McDermott,1981).

The selection of a task for coding in an expertsystem is the first step in building an expert system,and in fact it may be viewed as the beginning of thefirst of the five stages of system building (Buchanan eial., 1983). These stages can be characterized as

follows: identification, in which the important stages ofthe problem are characterized and goals are set for theentire project; conceptualization, during which the keyattributes of the task and its domain are made explicitand some thought is given to issues of knowledgerepresentation; formalization, at which time a formalmodel of the task, its attributes and their relationshipsare represented in a particular scheme (or set ofschemes); implementation, during which time therepresentation scheme is programmed using whatevertool (programming language, shell, etc.) has beenchosen for the project; and testing, in which theprototype system just implemented is exercisedagainst some of the case studies from the previouslyassembled library of solutions. After the testingphase, or rather, within the testing phase, feedbackloops are implemented which will lead to furtherrefinement of the prototype or even a complete

reformulation.This conceptual model of how knowledge is

acquired, represented and coded hides to a largeextent the institutional and personal aspects ofcapturing knowledge, as well as aspects of implement-ing a system that will be used by its intended audienceand appreciated by its sponsors. This model also hidesthe role that experts play in the design andimplementation of an expert system, and howimportant it is to maintain their enthusiasticparticipation throughout the life of the project. Someof these aspects are addressed in greater detail below,especially in Sections 3 and 5.

3. Knowledge acquisition

This section is devoted to a discussion of howknowledge is acquired from the expert(s), an essentialstep if there is to be an expert system! This part of thesystem-building task transcends the first three stages(identification, conceptualization and formalization) inthe paradigm outlined in the previous section. Thepresent discussion begins by focussing on what isrequired in the way of knowledge. There then followsa model of how the knowledge is obtained from theexperts themselves. Note that there will be continuedreference to multiple experts, reflecting in part theauthor's strong bias that several experts ought to beconsulted in the process of building an expert system(Mittal and Dym, 1985). In addition, it should be keptin mind that other sources of expertise can beexploited, including analysis programs, books, re-search papers, reference manuals, etc.

Knowledge acquisition begins with choosing and/ordefining the task that will be encapsulated within the

Implementing expert systems 39

expert system. The choice, as noted earlier, dependson several critical factors, including the time taken toperform the task, its value, the availability of experts,the reasoning involved, and so on. This phase of theproject also marks the formal entry of the knowledgeengineer, i.e. the expert in AI and/or computerscience who will lead the knowledge acquisition andimplementation phases of the expert system develop-ment. (The knowledge engineers are distinct from thedomain experts, commonly referred to simply as theexperts, whose knowledge and expertise about thedomain is being put into the expert system.) As theknowledge engineers being to familiarize themselveswith the task at hand, they will begin to develop adomain vocabulary. That is, they will begin to acquireand use the words, phrases, formulas, etc., whichcomprise the natural language in which the task isdescribed. This is an important step in understandingthe domain and (later) in communicating with theexperts.

With the vocabulary in hand, the knowledgeengineer begins to sort out how the task is performedby developing a model of the reasoning involved andhow it is applied. This is an intellectural exercise thatmay be represented by a flow chart or by steps in aprotocol or so on; it is not (yet) a computer programor even a formal representation. It is, rather, a paperexercise in which the task is outlined and modelled sothat it can be evaluated for encapsulation. Of course,the process of laying out the task often provides theinitial ideas about the subsequent representation ofthe task, but that is a later step, one taken (typically)by the knowledge engineers acting separately from thedomain experts. But, in terms of the domainknowledge itself, the end of the acquisition process ismarked by the completion of a document, flow chart,etc., that traces the task in its natural language andmakes explicit what knowledge is used, where, when,and how a conclusion is reached.

The process of acquiring knowledge is an interactiveone representing a complex dialogue between thedomain experts and the knowledge engineers. Manyquestions arise in such a process, including: Howmany experts are needed? Is one expert enough? Howare experts to be identified? How does one verify anexpert's expertise? Can a domain expert also behis/her own knowledge engineer? How are expertsinterviewed? How are case studies used in theprocess? Are there ways to resolve conflicts amongexperts?

There is not sufficient space here to answer all these(and related) questions. Rather, the approach takenwill be to set forth the strategy taken in the PRIDEproject (Mittal et ai, 1986), detailing along the way

the rationales and strengths of this particular strategy(Mittal and Dym, 1985). The story picks up after anagreement-in-principle had been reached between theproject sponsors (Xerox's Reprographics BusinessGroup in Webster, NY) and the knowledge engineers(both located at the Xerox Palo Alto ResearchCenter) to build an expert system to aid in thesubsystem design of paper copiers. This particularexpert system would be built as a demonstration thatthe technology could be used successfully in anengineering environment in order to carry out betterengineering designs.

There were two designers within the sponsoringorganization who would work closely with theknowledge engineers on this project. Through them,and following the preliminary selection of a task forencapsulation, in accord with the criteria set out in theprevious section, the knowledge engineers for thePRIDE project arranged a set of interviews with apanel of experts who worked within the sponsoringorganization. The initial motivation for this first set ofinterviews was to confirm that there was a discrete,repeatable, capturable task that might be worthencoding. This was accomplished by keeping the twodesigners as resident experts on the knowledgeengineers' side of the table, while individuallyinterviewing more than half a dozen other designerswho performed the task. The resident experts posedthe design problem to each of the other experts inturn, acting as interlocutors and framing the problemexactly as it would be handed to designers in practice,with the experts then working out the design solutionat a blackboard.

This process produced some immediate dividends.It became clear that all the experts followed a verysimilar strategy for carrying out the design in terms ofhow they decomposed the problem into subproblems,worked on the subproblems, and then related thepartial designs to each other. While decomposition isnot a new technique for solving complex problems, itwas interesting and reassuring to see the similarities inthe subproblems chosen and in the strategies forsolving each subproblem. Thus, the task chosenseemed to exhibit some regularity that each expertwas trained to exploit. Further, it also became clearthat there were interesting individual nuances thatemerged in each design, reflecting the varyingbackgrounds of the individual designers, so that thefinal assemblage of knowledge might benefit frombringing together these separate strands of expertise.

A very important point needs mentioning here. Thedesign problem was posed to the experts in standardform, together with the instruction that they proceedas they would normally to achieve a successful design.

40 C. L. Dym

Thus, they were asked to do the design; they were notasked to describe how they did it. This is importantbecause experts typically cannot give reliable accountsof their expertise and how it is exercised. To extractknowledge, it must be exercised on problems.

Again, the present forum does not allow a completediscussion of all facets of knowledge acquisition. Thesalient points of the experience described here arethat: more than one expert can be used to reinforcethe understanding of a repeatable and capturabletask; that individual expertise can be captured in sucha way as to augment the knowledge of all the users ofan expert system [see the discussion of communitymemory in (Dym, 1985a) and (Mittal and Dym,1985)]; and that experts should be asked to performtheir task, rather than describe it.

It is also worth adding that the library of casestudies emerges as an important part of the acquisitionprocess, especially where more than one expert isinvolved. With more experts participating, there willgenerally be more case studies available and thusthere are more opportunities to test cases that are newto particular experts. This facilitates the exploration oftask regularity and the emergence of subtle featuresand points that are not well understood, and it helpshighlight areas of conflict. Again, further details aregiven elsewhere (Mittal and Dym, 1985).

4. Development and run-time programmingenvironments

Al LANGUAGES AND ENVIRONMENTS

Implementation is the next stage in the develop-ment of an expert system, where programming of thetask is undertaken within a chosen representationscheme. Applications projects in AI are usuallyimplemented in a high-level programming languagewhich can be considered to fall within one of threegroupings (Hayes-Roth et al., 1983): general purposeprogramming languages; general purpose repre-sentation languages; and domain-independent expertsystem frameworks. Some very brief descriptions andexamples follow; comprehensive reference lists arenot included here as they are available elsewhere(Harmon and King, 1985, Hayes-Roth et al., 1983,Maher et al., 1984, Mullarkey, 1987, Rehak andFenves, 1985, Waterman, 1985).

The general purpose programming languages used inAI are, typically, LISP and its dialects, especially inthe U.S., and PROLOG, largely in Japan andEurope. LISP is an acronym for the list processinglanguage developed by John McCarthy in the 1950s,

whereas PROLOG is based on the predicate calculusand was developed in Europe in the 1970s. Thesehigh-level languages are quite often exercised inexploratory programming environments that en-courage experimentation with large chunks ofknowledge, abstraction, symbolic manipulation, andtentative modifications. Some of the advantages ofthese environments are outlined by Sheil (1983).

LISP has been the major force behind virtually allthe major AI innovations and the impetus for thearchitectural design of symbolic processors.PROLOG, while popular in Europe, has not beenaccepted by the majority of AI researchers. PROLOGdoes express knowledge in logical form, but it has asingle type of control structure that many believe is acritical weakness.

There are many dialects of LISP, and names such asInterlisp-D, Zeta LISP and MACLISP will beencountered in the literature. However, CommonLISP has become the standard dialect because theDOD funding agencies, and DARPA in particular,have led the push toward a standardization ofprogramming languages.

It is worth repeating that the reason that these LISPenvironments are so important is that they provide apowerful set of software tools that tremendouslyenhance programmer productivity (Sheil, 1983).These development tools include code and memorymanagement, editing and debugging, and the abilityto handle (and abstract from) large chunks ofknowledge.

There are also software systems that facilitate thetask of building large expert systems by providing theprogrammer with a high-level framework, as well asediting and debugging tools. These systems, orenvironments, are built on top of LISP environments,and include general purpose representation languageenvironments and expert system frameworks.

General purpose representation languages areprogramming languages designed specifically forknowledge engineering. They are not tied to anyparticular control or inference strategy, but theyfacilitate the implementation of a range of problemsalong the classification-formulation continuum. Suchlanguages include SRL, RRL, KEE, OPS5, ROSIE,ART, LOOPS and AGE.

Domain-independent expert system frameworks,usually referred to as 'shells', provide an inferencemechanism, which can then be applied by the additionof domain-specific knowledge. These systems oftenprovide modules for knowledge acquisition and forexplanation. They often have their roots in specificexpert system projects, from which they thus derivetheir control strategies. Examples of these expert

Implementing expert systems 41

system shells include EMYCIN (which was used in theSACON experiment), KAS, HEARSAY-III,EXPERT, and KMS/KES.

Paranthetically, it is worth noting that the term'shell' is sometimes used to include general purposerepresentation languages (e.g. KEE, LOOPS) as wellas expert system frameworks such as EMYCIN andEXPERT. However, it is well to remember that thegeneral purpose language environments offer greaterflexibility because, as noted, they are not tied to aparticular control or inference strategy. The word'shell' should be used to describe an expert systemframework within which a committment has beenmade to a particular inference strategy. It follows, ofcourse, that use of a particular shell requires a goodmatch between the shell's control and representationstrategies and the task to be captured.

CONSIDERATIONS IN CHOOSING ADEVELOPMENT ENVIRONMENT

Since the goal of an expert system project is thedesign of a prototype system that demonstrates thefeasibility of capturing some task in an expert system,the implementation phase should in general beperformed in an environment that allows a spectrumof representation and control schemes to be invokedand played with. Thus, from this point of view, onewould tend to downplay issues of efficiency and easeof interfacing to any related analysis, modeling orsimulation programs that might form part of thedomain knowledge. However, there are still manythings to think about in choosing the rightenvironment (consisting of hardware, basic program-ming language, and shell or tool) for developing anexpert system and, subsequently, for using it in arun-time environment. Some of the issues areexplicated in this and the next sections.

For example, an expert system shell that embodiesthe fewest a priori constraints in building anapplication system on top of a core representation isprobably most desirable. That is, it is best to operateon a principle of least committment to a singlerepresentation scheme or a single control approachuntil there is complete understanding of the issues ofrepresentation and inference. However, this is not auniversally applicable principle because it assumesthat each expert system project is a research project.In those instances where the representation andcontrol issues are well understood from thebeginning, then a more restrictive tool can be mucheasier to use. If the paradigms match, then a lot of thework that needs to be done is already incorporatedinto the tool.

Among completely general environments andrepresentation languages, several choices are available[see (Harmon and King, 1985) for a relativelycomplete listing], although cost and hardwareconsiderations may limit the use of such general tools.Intellicorp's KEE is similar to Xerox's LOOPS: bothallow integration of frame and rule representations,coupled to several different control structures,together with features of procedural and access-oriented (also known as incorporating 'active values'or 'demons') programming. KnowledgeCraft, de-veloped by the Carnegie Group, could be a goodchoice for some exploration and applications since itembodies frames, backward-chaining and forward-chaining, and also has hooks for system development.

Such general tools are run on LISP machines,sometimes (still) in different dialects, and sometimesthe same product runs in different dialects on differentmachines. The preferred choice of LISP dialect isfairly clear, however, especially in light of theCommon LISP standard. Thus, one would ordinarilyselect a different dialect of LISP only if the availableimplementation of Common LISP is inefficient. Ofcourse this can be dealt with when moving to therun-time environment. Another reason for choosingan alternative dialect is that the software desired maynot exist in Common LISP, or the machine availablemay not have an implementation of CommonLISP—although this is not likely to happen in thefuture given the acceptance of the Common LISPstandard.

The quality of the Common LISP implementation isan additional consideration in the joint decision ofCommon LISP and hardware processor. There areseveral metrics by which one might evaluatecompeting implementations, including memory re-quirements, the compactness of the code, its virtualmemory requirements (locality), variable lookup andbinding, data structure manipulation, type computa-tions, arithmetic operations, and so on. Benchmarksfor common LISP implementations have beenproposed (Gabriel, 1985), but experience has notshown great uniformity or consistency in theapplication of these benchmarks to different CommonLISP implementations when running on differentplatforms.

CONSIDERATIONS IN CHOOSING A RUN-TIMEENVIRONMENT

Run-time considerations are quite different fromthose outlined above and must perforce be addressedin detail after substantial progress has been made on

42 C. L. Dym

the shape of the prototype expert system, its couplingto and dependence on the development environment,and on the kinds of hardware and software that mightbe part of the delivered expert system. For example,the expert system might be designed as a pre- orpost-processor to a numerical package, or it might beintended to work in a CAD system in a designenvironment. Thus, the particular nature of theintended run-time environment will influence stronglythe way that the expert system is delivered.

However, some of the issues can be addressed hereand, to give the discussion some concreteness, it willbe cast into the context of considering an expertsystem as an intelligent pre- and post-processor foranalysis packages based on the finite element method(FEM). The ideas stem from the early stages of acollaborative research effort on the feasibility of suchan application (Dym and Fenves, 1986, Fenves, 1985).The most important issue in tying an expert system toan FEM package concerns the means by which expertsystem modules can be incorporated into present (andfuture) FEM products that are (will be) commerciallyavailable.

Most FEM codes are programmed in FORTRAN,while the expert system modules will be developed inan AI programming environment or within an expertsystem shell. One way to interface the two would bethrough file transfers. This would be a very weakcoupling that would inhibit information transferbetween the two systems.

Another possibility for developing efficient inter-faces is the use of a common operating system (e.g.UNIX) and its attributes (e.g. UNIX 'pipes').However, given that many FEM codes are run inVAX environments, with their VMS operatingsystems, it is not clear how a match of operatingsystems would be made, especially since UNIX is usedoften in AI/LISP machines.

It would be much more desirable to have both theFEM code and the expert system modules written inthe same language. This would allow tighter couplingbetween the two, and would also make it easier forvendors to develop and support their products.However, in the short run this seems unlikely as itwould not be cost-effective to rewrite the expertsystem modules in FORTRAN. It also seems unlikelythat the FEM codes will be recast in LISP. Onemiddle ground that appears viable is the recoding ofFEM codes into C. This might be possible becausethere appear to be under development somecross-compilers that would allow LISP programs to becompiled into C or into 68000 assembly code. Avariation on this option is the coding of the expertsystem into C as well, an idea which has receivedsome attention in the literature and the commercial

world of tool developers. However, as will be notedbelow, the advent of new chips and the inherentadvantages of LISP (in terms of memory manage-ment, programming environments, etc.) still leaveLISP as the language of choice for expert systemdevelopment and application (Barber, 1987).

There are two extremely important computationalissues that must be addressed in this phase of theproject: speed and memory. The issues arise becauseCommon LISP is a very large language that is alsomemory intensive. It is also computationally intensiveand runs relatively slowly (several times slower thanC, for example). Thus, the following questions arise:Is the CPU fast enough to run LISP at a practicalspeed? Also, is there enough addressable memory tohandle both LISP and the application? (On its own,LISP requires 2.5 to 3 MB. A more typical minimummemory requirement is 4MB, with 8MB usuallybeing specified for more serious applications.)

Further, in terms of memory, it is of criticalimportance that the run-time environment containsufficient primary memory to avoid unnecessary pagefaults and thrashing. It was noted earlier that 8megabytes of memory would usually be needed in adevelopment machine. This requirement may bereduced as more compact versions of LISP aredeveloped, but it must be understood that these morecompact versions do not exist yet, nor is it clear whenthey will exist, if at all, nor how effective they will be.

In terms of the FEM application being discussedhere, the issues appear as follows: Assuming that anFEM analysis assistant can be successfully built infunctionally-specific modules, can one or more of themodules be run in real-time, while the user waits, orwill they be run off-line in batch mode, or evenovernight? The answer to this question will clearlyaffect the nature of the user interaction and themanner in which the design process takes place.However, an answer to this question will not beavailable until after at least one module is developed,and even then there will be variations in the size andcomplexity of future modules.

In planning both the development and the run-timephases of a project such as that envisioned here,some things can be done to make the expert systemmore efficient. The first is that the LISP programshould be compiled, although a LISP interpreter willstill be required. Second, one can structure therule-sets so that the user can control the order ofapplication of the rules, thus avoiding unnecessarypattern-matching. Third,' applying the notion of'meta-level' control, one can partition the rules toensure that only the immediately relevant rules arefired in any given computation.

Lastly, one can look for hardware that makes use of

Implementing expert systems 43

the newer and faster LISP chips that are underdevelopment. Such chips are 36 bit chips, rather than32, and they facilitate the tagged-memory architectureof LISP code by allowing type-checking, branchingand stacking to be done concurrently in micro-code.These chips are expensive, but they are some five toten times faster than current LISP chips and areexpected to be available in the next year or two. Inaddition, with the advent of new processors such asthe Intel 80286 and 80386, which are 16 and 32 bitchips, respectively, there is sufficient execution speed(1-2 mips for the 80286 and 3-4 mips for the 80386)and memory (up to 16MB physical and 4 gigabytesvirtual for the 80286 and 4 gigabytes physical and 64terabytes virtual for the 80386) to support substantialexpert system development and application (Barber,1987).

It might be noted that, the above specificsnotwithstanding, the world of machines, speed andmemory is in a state of very rapid flux. Thus, the bestadvice may be to proceed only after absorbing themost recent information and anticipating that thingswill change rapidly in the future. Thus, to the extentone can favor open architectures and upwardcompatibility, in the most general terms, the better offone is likely to be.

5. Institutional issues

Institutional, or organizational aspects of expertsystem building are not only important in their ownright, because of the commitment of resourcesrequired for the building of a worthwhile and robustsystem. They are also important because organiza-tional issues interact strongly with some of thetechnical issues, often to the point where they cannotbe considered as independent of each other. The keyinstitutional issue, of course, is the allocation ofresources, both to the system building project as awhole and among the various phases as the projectproceeds. The impact of resource decisions will be felton the choice and characterization of the task to bemodelled, on the choice of the developmentenvironment, on the knowledge acquisition process,and on the delivery platform. By way of spotlightingthe interaction of technical and institutional issues, itis worth looking at some examples of expert systemprojects that are considered as success stories.

The Dipmeter Advisor is an expert system designedto aid in the geological analysis of subsurfaceformations by examining and interpreting magneticdata taken from boring logs (Smith, 1984). Boring-loganalysts look at output from strip-chart recorders asthey try to interpret the geological data, and the

Dipmeter Advisor maintains this ability, incorporatingalso various kinds of summary data and the ability toscroll smoothly and quickly among various strips ofdata. This required a large investment in the userinterface for this expert system. In fact, thedistribution of lines of code in the Dipmeter Advisoris as follows:

inference engineknowledge basefeature detectionuser interfacesupport environment

8%,22%,13%,42%,15%.

Note that 42% of the code is taken up by the userinterface, while the amount devoted to the obviousexpert system components, the knowledge base andthe inference engine, is only 30% of DipmeterAdvisor's code. This emphasis on the user inter-face is not usual in expert system design. In thePRIDE system, for example, about 40% of thecode is dedicated to the user interface (Mittal et ai,1986).

This is an interesting example of how technical andinstitutional implementation issues interact becauseit speaks directly to the issue of how resources areallocated as an expert system is being built. It isimportant to recognize that the software created (andthe delivery platform used) must create an environ-ment consistent with how the expert exercises hisexpertise. Thus the knowledge engineers must putforward an interface that can and will be used by theexperts and other potential users. Again, in thePRIDE system, the starting point in the designprocess captured there is an interface that allows thedesigner/user to 'sketch' a path for a paper handlingsubsystem in a way that is very close in feeling to howit would have previously been done on a drawingboard (Mittal et ai, 1986, Morjaria et ai, 1985).

Dipmeter Advisor is also an interesting examplebecause of the time taken for its development andevolution. It began as a research project in 1978, andthe first prototype was completed in 1980. Theprototype, containing 245 K bytes of DEC 2020 LISPcode and another 450 K bytes of VAX FORTRANcode, was too slow. The second implementation wascompleted in 1983, running on a Xerox workstationwith 650 K bytes of Interlisp-D code. The 1983implementation was considered sufficiently fast androbust for testing (Smith, 1984).

Another well-known expert system also started as aresearch project in 1978 (McDermott, 1981). TheRl/XCON system began at Carnegie-Mellon Univer-sity in that year, with the first prototype being

44 C. L. Dym

delivered to DEC in 1980. However, it was not putinto regular use there until 1982, and even now itrequires a very large support and maintenance staff.(Some fifty people work on this and related projects atDEC.) However, it does successfully configure 97% ofall VAX orders, and thus its economic return is quitesubstantial.

Both Dipmeter Advisor and Rl/XCON are oftencited to make the point that building a large androbust expert system is a long and expensive process.Both of these projects required years of research andexperimentation before they were adopted for regularuse. However, both of these systems were started longbefore the availability and understanding of the kindsof tools that are now taken for granted. It is not thatbuilding large, 'industrial-strength' expert systems hasbecome cheap, but the process is not as expensive oras time consuming as the Dipmeter Advisor andRl/XCON projects would indicate. Both the PRIDEsystem and the LSC Advisor were brought to workingprototype stage within 12-18 months, and theresource consumption of both these design systemprojects was far less than the other projects just cited(Dym et al., 1987, Mittal et al., 1986).

One of the less obvious costs in building suchsystems is that of the experts' time. Clearly, while theexperts are involved in a system building project theywill be doing less of what they would otherwise bedoing in their various organizations. Further, withoutthe expert's active, enthusiastic and continuinginteraction with the knowledge engineers and othersystem builders, the knowledge cannot be successfullyexplicated and captured in the system. Thus, majorcommitments must be made by the experts and bytheir organizations. Without such commitments,which obviously can be very expensive, serious systembuilding endeavors should not be undertaken.

Another aspect of expert system building thatrequires major institutional commitments is the life ofthe system after its development. An expert systemis—or at least should be—a dynamic system thatneeds active maintenance and updating. New casesand situations provide further experience that can beadded to the knowledge base, as can refinements ofthe user interface and other features of the system.(Recall that one of the real advantages of theseparation of knowledge and control in expert systemprogramming is that it facilitates the addition of'chunks' of knowledge (Dixon and Dym, 1986, Dym,1985a). This requires a commitment by managementto maintain and support the system, which reallymeans that the system should provide a continuingbenefit sufficient to justify to its sponsoring organiza-tion this continuing expense.

6. Speculations on future system implementations

This section is devoted to a somewhat specializeddiscussion of future expert system possibilities. Themotivation comes from extrapolation from a currentresearch project (Dym et al., 1987), taking accountalso of current research in distributed processing atthe University of Massachusetts (Durfee et al., 1985).

The current project involves the development of anexpert system to do architectural code checking (Dymet al., 1987). It is clear from architectural andengineering practice that building and other structuraldesigns often need to meet more than one set of coderequirements. Indeed, the interaction of multipleconstraints sets in a design project is only one exampleof how expertise in engineering projects may bedistributed, making the interaction of multiple sourcesof knowledge a serious engineering issue. Otherexamples include the interaction of subsystemdesigners as an overall system design is assembled(out of the various subsystems), the interaction ofmultiple experts in achieving a diagnosis or indeveloping an analysis strategy for a complexproblem, and the formulation of a coherent set ofplans for a project from the individual plans of severalinvolved parties.

It might be noted that the distribution of expertsystems and their interaction is not a dream for thedistant future. It is already clear that some of thebenefits of building (single) expert systems derivefrom the ability to use them at a variety of sites- Suchuse facilitates standardization of techniques, methodsand requirements among geographically dispersedparts of an organization. It also allows localizedexpertise to be distributed for training purposes, andit allows the development of a community memory foran institution (Dym, 1985a, Mittal and Dym, 1986).The point is that the benefits of distributing a singleexpert system are so clear and obvious that theperceived possibilities of concurrent expert systemswill surely drive innovation in this area, especiallywith the increasingly rapid development of parallelprocessor hardware.

The study of the representation of and solutions tothese kinds of problems comprises that branch ofartificial intelligence usually called 'distributed AI'.And perhaps the major issue is that of couplingbetween the knowledge sources or expert systems.The ideal scenario, of course, is that of tight coupling,where operating systems and memory are shared, andthere are no synchronization problems. This is anideal, however, that cannot typically be met in acomplex engineering environment in which there isalready established a web of computers, peripherals,

Implementing expert systems 45

and the software and other hardware necessary toachieve the objectives of a particular organization.

As noted above, a more typical environment inwhich expert systems will interact is one wherein theyare loosely coupled. This denotes the situationwherein each system could have its own data inputand will communicate with other expert systems overa low-bandwidth channel. Clearly, in order to thinkabout the interactions of concurrently executingexpert systems, it has to be accepted that theindividual systems should not be designed as isolated,closed expert systems. Rather, the individual expertsystems must be open and capable of a high degree ofinteraction. Some of the research questions to befaced in the development of complexes of expertsystems are as follows:

(1) How does an expert system solve subproblemsthat interact?(2) How is parallel processing done over a set ofexpert systems?(3) What is the appropriate representation schemefor the highly abstract and processed data that willbe shared by the cooperating systems?(4) What is the control mechanism that governs theset of cooperating systems, and how does it interactwith the individual control systems of eachknowledge-based system?These are only some of the research questions to be

addressed for an understanding of how cooperatingknowledge sources can be used to perform betterengineering. The kind of architecture typicallyproposed for an ensemble of cooperating systems iscalled the blackboard (Nii, 1986a, 1986ft), and aspecific example of such an architecture is the GenericBlackboard (GBB) architecture developed at theUniversity of Massachusetts (Corkill et ai, 1986). Butthe main point is that, new as they are, expert systemsare rapidly evolving, and as they do so they arebecoming more open and thus more widely applicableto important engineering applications.

7. Conclusions

This article has been devoted to a discussion of theimplementation of an expert system, that is, of how tomake it happen. In the process many important issueshave been raised, some technical, some institutional,some interactive between these two dimensions. It isprobably useful to close this discussion with somewarnings or maxims about expert system develop-ment, as well as with a listing of some of theadvantages to an organization that sponsors thedevelopment of an expert system.

As maxims, it is worth remembering that:* Expert systems cannot do the impossible, e.g.,

cure cancer.* Expert systems cannot do the extraordinary, e.g.,

make money on the stock market.* Knowledge is expensive.* It takes time to build a serious, robust expert

system.* A single knowledge representation scheme is

often inadequate.* Much more is known about developing diagnostic

and interpretive expert systems than aboutplanning and design systems.

Then why invest in an expert system? Because:* Expert systems do not get tired. They can

perform routine tasks with high reliability andconsistency.

* The knowledge acquisition process deepens andsharpens the experts' own understanding.

* Expert systems allow the experts to concentrateon rarer, more interesting tasks.

* Expert systems can be used to train neophytes.* Expert systems provide a community memory for

sharing and propagating knowledge.* Expert systems, with networking, permit the

widespread standardization of techniques, meth-ods, requirements, etc.

Acknowledgements

The author is grateful for helpful comments fromseveral collaborators: S. Gonick of AmerinexArtificial Intelligence, Inc., and D. D. Corkill, R. P.Henchey and E. A. Delis of the University ofMassachusetts. E. M. Riseman of the University ofMassachusetts provided useful comments on an earlyversion of Section 4 of this paper.

References

Barber, G. R 1987 LISP vs. C for implementing expert systems,Al Expert 2(1), 28-31.

Bobrow, D. G., Mittal, S. and Stefik, M. J. 1986. Expert systems:Perils and promise. Communications of the ACM 29(9), 880-894.

Buchanan, B. G. et al. 1983. Constructing an expert system. In:Hayes-Roth, F., Waterman, D. A, and Lenat, D. B., Eds,Building Expert Systems, Reading, MA: Addison-Wesley.

Corkill, D. D., Gallagher, K. O. and Murray, K. E. 1986. GBB: Ageneric blackboard development system. In: Proceedings of theFifth National Conference on Artificial Intelligence, Vol. II,Philadelphia, PA, pp. 1008-1014.

Dixon, J. R. and Dym, C. L. 1986. Artificial intelligence andgeometric reasoning in manufacturing technology, AppliedMechanics Reviews 39(9), 1325-1330.

46 C. L. Dym

Durfee, E. H., Lesser, V. R and Corkill, D. D. 1985. CoherentCooperation Among Communicating Problem Solvers, TechnicalReport 85-15.Amherst, MA: Department of Computer andInformation Science, University of Massachusetts.

Dym, C. L. 1985a. Expert systems: New tools for computer-aidedengineering, Engineering with Computers 1(1), 9-25.

Dym, C. L. (Ed.) 19856. Applications of Knowledge-Based Systemsto Engineering Analysis and Design New York: AmericanSociety of Mechanical Engineers.

Dym, C. L. and Fenves, S. J. 1986. Feasibility study of aknowledge-based expert system finite element modeling andanalysis assistant (FEMAA), a joint research project at theUniversity of Massachusetts and Carnegie-Mellon Universitysponsored by the U.S. Air Force Office of Scientific Research,1986-1987.

Dym, C. L., Delis, E. A. and Henchey, R. P. 1987. Representationand control issues in automated architectural code checking,manuscript in preparation

Fenves, S. J. 1985. A framework for a knowledge-based finiteelement analysis assistant. In: C. L. Dym (Ed) , Applications ofKnowledge-Based Systems to Engineering Analysis and Design,New York: American Society of Mechanical Engineers.

Gabriel, R. P. 1985. Performance and Evaluation of Lisp Systems,MIT Press, Cambridge, MA, 1985.

Harmon, P. and King, D. 1985. Expert Systems, New York: JohnWiley.

Hayes-Roth, F., Waterman, D. A. and Lenat, D. B. 1983. (Eds).Building Expert Systems, Reading, MA: Addison-Wesley.

Maher, M. L., Sriram, D. and Fenves, S. J. 1984. Tools andTechniques for Knowledge-Based Expert Systems for EngineeringDesign, Technical Report DRC-12-22-84. Pittsburgh, PA: DesignResearch Center, Carnegie-Mellon University.

McDermott, J. 1981. Rl : The formative years, Al Magazine 2(2),

21-29.Mittal, S. and Dym, C. L., 1985. Knowledge acquisition from

multiple experts, Al Magazine 6(2), 32-36.Mittal, S., Dym, C. L. and Morjaria, M. 1986. PRIDE: An expert

system for the design of paper handling system, Computer 19(7),102-114.

Morjaria, M., Mittal, S. and Dym, C. L. 1985. Interactive graphicsin expert systems for engineering applications. In: Proceedings ofthe 1985 International Computers in Engineering Conference andExhibit. Boston, MA, pp. 235-241.

Mullarkey, P. W. 1987. Languages and tools for building expertsystems. In: Maher, M. L., Ed., Expert Systems for CivilEngineering: Technology and Applications, New York: AmericanSociety of Civil Engineers.

Nii, H. P. 1986a. Blackboard systems: The blackboard model ofproblem solving and the evolution of blackboard architectures,Al Magazine 7(2), 38-53.

Nii, H. P. 19866. Blackboard systems; Blackboard applicationsystems, blackboard systems from a knowledge engineeringperspective, Al Magazine 7(3), 82-106.

Prerau, D. S. 1985. Selection of an appropriate domain, AlMagazine 6(2), 26-30.

Rehak, D. R. and Fenves, S. J. 1985. Expert systems in civilengineering, construction and construction robotics, 1984 AnnualResearch Review, Pittsburgh, PA: Robotics Institute, Carnegie-Mellon University.

Sheil, B. 1983. Power tools for programmers, Datamation 29(2),131-144.

Smith, R. 1984. On the development of commercial expert systems,Al Magazine 5(3), 21-34.

Waterman, D. A. 1985. A guide to expert systems, Reading, MA:Addison-Wesley.

Clive L Dym is Professor of Civil Engineering and Adjunct Professor of Computer andInformation Sciences at the University of Massachusetts, Amherst, where he has also beenHead of the Department of Civil Engineering (1977-1985). He was a Senior Scientist atBolt Beranek and Newman in Cambridge MA (1974-1977), and served on the faculties ofSUNY Buffalo (1966-1969) and Carnegie-Mellon University (1970)-1974). He has heldvisiting appointments at the Technion-Israel Institute of Technology (1971), the Institutefor Sound and Vibration Research at the University of Southampton (1973), and Stanfordand the Xerox Palo Alto Research Center (1983-84). Dr. Dym completed undergraduatework at the Cooper Union (1962), received an MS from the Polytechnic Institute ofBrooklyn (1964) and a PhD from Stanford University (1967). Dr Dym has done researchon a variety of problems in applied mechanics and acoustics. Recently his researchactivities have focused on the development of expert (knowledge-based) systems forengineering analysis and design. Dr Dym's research results have been published in some60 journal articles and in seven books. He was the recipient of the 1980 Walter L HuberResearch Prize of the ASCE and the Western Electric Fund Award of the New EnglandSection of the ASEE (1983). He is on the Editorial Board of the Journal of Sound andVibration, has been an Associate Editor of the Journal of the Acoustical Society ofAmerica, and is founding Editor of the new journal, Artificial Intelligence for EngineeringDesign, Analysis and Manufacturing, published by Academic Press.