Knowledge and Control

IaM ic

Design Expert System

David C. Brown, \Afrcester Polytechnic InstituteB. Chandrasekaran, Ohio State University

M ost first-generation expert sys-tems have been rule-based with aseparate inference engine. How-

ever, a large unstructured collection ofrules clearly lacks validity as a realisticmodel of design because reducing allknowledge to a single form does notrecognize that there are many differenttypes of knowledge used in any designproblem-solving activity.

Using such a collection of rules alsodoes not recognize that design knowledgeforms into clusters. Nor does it specifywhere or when this knowledge is to be ap-plied, since different clusters ofknowledgemay be applicable at different times.Similarly, using a single, central all-purpose inference engine ignores therichness of design problem-solving. Yetanother problem is the potential for un-focused system behavior because all ruleshave equal status in the system and haveequal potential for use.

Many systems structure rules into sets.However, these sets are based on subtasksrather than on types of knowledge, 1-3 andthe problem solving is still uniform, as thesame inference engine acts on each ruleset. Advocates of such structuring claimthe subtasks can be solved linearly with nobacktracking between tasks and with onlyminimal backtracking within tasks.Such subtask structure tells us more

about the nature ofthe domain than aboutdesign, since it is clear that design deci-sions of any kind can often be wrong and,if so, will lead to attempts to recover fromfailure. The uniform rule representationand the lack of knowledge-dependentstructure does not provide clear predic-tions about an expert's failure-recoverybehavior.

These problems stem mainly from abasic mismatch between the level of thetools available to build systems and thelevel of abstraction of the design task.

0018-9162/86/0700-009201$.O0 © 1986 IEEE92 COMPUTER

Consequently, for more complex forms ofexpert problem solving, there is a need fortools at the task level. Such tools must pro-vide a rich set of design-related task-levelconstructs. They should be helpful in cap-turing more structured forms of knowl-edge, and should help organize bothknowledge and problem-solving behaviorfor more focused problem-solving.

Generic tasks in reasoning. TheLaboratory for AI Research at Ohio Stateis developing a framework in which in-vestigation of generic tasks in knowledge-based reasoning plays a fundamentalrole. 4 Appropriate families of knowledgestructures and control regimes are con-structed for each generic task. From thisperspective, design as a generic task callson and uses distinctly different types ofknowledge and control from, say,diagnosis.

This point of -view naturally leads tofamilies of high-level languages for expertsystem construction. These languages letdomain knowledge be captured muchmore lucidly by using primitives ap-propriate to the task. They also make ap-propriate classes ofcontrol behavior avail-able to the designer. For the designsubclass we call routine design, we havedeveloped DSPL, a task-level language.("DSPL" stands for Design Specialistsand Plans Language.)

Design is a complex activity, one that ar-tificial intelligence has only relatively weaktheories of, especially for more creativedesign activity. In routine design, thestructure of the artifact is fixed and stan-dard methods of designing various partsare known.

However, there is still a complex prob-lem-solving activity: integrating and satis-fying all the constraints of the particulardesign problem. Rough design and back-tracking occur in this design process, butmuch of the problem solving is piecingtogether the design rather than creatingnew methods. In our view, a substantialpart of design activity in industry is of thistype. Thus, our approach could be widelyapplied.We use the domain of mechanical com-

ponents-air cylinders in particular-tomotivate our research.5 The AIR-CYLsystem described later shows how our

routine design problem-solving approachcan be applied.

Other work in design. The nature ofdesign has been discussed considerablyamong artificial intelligence researchers.The circuit design domain is one areawhere somewhat more sophisticated issuesabout the structure of knowledge and con-trol in design have been discussed, buteven there relatively few systems considerdesign problems in ways that are not adhoc. &9

In the mechanical systems domain, thework of Simmons, Dixon, and Cohen10and Mittal, Morjaria, and Dym"I shareour interest in producing a theory ofdesign. The former authors concentrateon a theory of redesign, while the latter in-clude plans and active design knowledge intheir theory, much as we do. Stefik, 12 too,presents an important view ofdesign but isconcerned with less routine design activity.His Constraint Posting mechanism couldbe used in an explanation of how routinedesign knowledge is produced.

However, this design research did notlead to generic languages and architecturesto support design as a problem-solving ac-tivity (which is at least partly our aim). Wehave deliberately sought a level of designwhere the complexity of knowledge andcontrol can be limited, but where morepowerful building blocks than those nowavailable can be provided in return. On theother hand, the complexity of the designproblems solvable by our framework isstill higher than those solved with the rule-based paradigm.

Design components. Design is a highlycreative activity involving diverse prob-lem-solving techniques and many kinds ofknowledge. Clearly, since we don't knowmany of the problem-solving componentsof general design and since we poorlyunderstand the components we do knowabout, a comprehensive detailed model ofdesign is out of reach.However, there is agreement about

many components of design activity.There is an element of refinement:Descriptions get refined into less abstractforms. Plans are used in recognizablesituations. Such plans result fromrepeated use of past planning and valida-tion. Design activity often has a roughdesign phase followed by design proper.

Design organization reflects the struc-ture or functionality of what is beingdesigned. Similarly, the design representa-tion is also structured. During the design,

Jul 1986

various restrictions are checked at ap-propriate points. The initial conditions(requirements) form a starting set ofrestrictions.

Routine designapproach

In routine design, the designer selectsfrom previously known sets of well-understood design alternatives. Thechoices may be simple at each point in thedesign, but overall the task is still too com-plex to be done by merely looking in adesign database because there are toomany possible combinations of initial re-quirements. Simple choices do not implysimple designs or a simple design process.A significant portion of design activity iscomposed of these routine tasks. (Whilewe have concentrated on routine design,we recognize that some design problemsbelong to a different type.)

Architecture. We use the architecture ofa hierarchically organized community ofdesign agents called specialists. Thishierarchy reflects the hierarchical struc-ture of the artifact being designed. Weconsider routine design to be largely a top-down activity. In our architecture, eachspecialist has a repertoire of design plansto accomplish certain design tasks at itslevel of abstraction. The specialists choosefrom plans, make some commitments,and direct specialists at lower abstractionlevels to refine the design. Failures causedifferent kinds of actions, such as choos-ing alternative plans and transferring con-trol to a parent specialist.The upper levels of the hierarchy are

specialists in the more general aspects ofthe component, while the lower levels dealwith more specific subsystems or com-ponents. We use a hierarchy not becausethe design is intrinsically hierarchical butbecause people use hierarchies to managecomplexity. The specialists chosen, theirresponsibilities, and their hierarchicalorganization will reflect the mechanicaldesigner's underlying conceptual structureof the problem domain.

Agents. Several types of agents (activeproblem-solver modules) exist in thehierarchy's decision-making structure.They include specialists, plans, steps,tasks, and constraints.

93

Specialists cooperate to refine the de-sign. Each specialist tries to design a majorsection of the component. To do this, aspecialist uses a collection of plans.A plan is a sequence of calls to special-

ists or tasks, possibly with interspersedconstraints. A plan represents one methodto design the section of the componentrepresented by the specialist. A planspecifies the order of invocation of thevarious agents used by this design method.The most basic design agent is a step.

Each step makes a design decision. Itdecides on a value for some attribute ofthecomponent. The value is stored in a designdatabase. The decision depends on thecurrent state of the design, taking into ac-count any constraints. For example, onestep would decide the material for somesubcomponent, while another would de-cide its length.A series of steps-possibly with inter-

vening constraints-forms a task, whichdesigns a logically, structurally, or func-tionally coherent section of the compo-nent (for example, a seat for a seal, or ahole for a bolt).

Constraints test for particular relation-ships between two or more attributes atparticular design stages. Constraints canoccur nearly anywhere in the hierarchy.For example, a constraint might checkthat a hole for a bolt is not too small to bemachinable in the material used. 13

Problem approach. The top-most spe-cialist is responsible for the whole design.Specialists lower down in the hierarchymake detailed decisions. Each specialistcan make design decisions about the partsand functions in its specialty. The deci-sions are made in the context of previousdesign decisions made by other specialists,as recorded in the database. Specialists candesign their pieces themselves or use theservices of other specialists below them inthe hierarchy.

Specialists in the hierarchy will refinethe design independently, using theirplans. Tasks attached to specialists pro-duce values using groups of steps, whileconstraints check the integrity of the deci-sions made.

Every specialist has some local designknowledge, some of which is expressed asconstraints. The constraints capture themajor things that must be true of aspecialist's design before it can be con-sidered successfully completed. Other

constraints, embedded in the specialist'splans, check the correctness of inter-mediate design decisions and check thecompatibility of subproblem solutions.

Design phases. The design activity fallsinto four phases.

Requirements phase. Initially, re-quirements are collected from the user andare verified both individually and collec-tively. Once the requirements are accept-able, the system attempts a rough design.

Rough design phase. Rough design ispoorly understood-but it serves at leasttwo purposes. First, those values on whichmuch of the rest of the design depends willbe decided and checked. The actual at-tributes decided depend on the componentand the domain, but it is likely that a valuefor higher level attributes, such asmaterial, will be chosen in this phase.

If these attributes can't be achieved,there is little point going on with the rest ofthe design. This also prunes the designsearch space because once the overall char-acteristics ofthe design are established, thenumber of choices about how to proceedwith the rest of the design diminishes.

Second, as any mutually dependent at-tributes can prevent a design from pro-gressing, rough design can, as humandesigners do, pick a value for one of theattributes and use that as if the dependen-cies didn't exist.

Specialists have both design and rough-design plans to select from, depending onthe current phase. Not all specialists willneed both. Some phases could be mixedduring problem-solving, but we havemade the rough phase occur first, fol-lowed by the design phase.

Design phase. Once rough design iscomplete, the design phase can proceed.Design starts with the topmost specialistand works down to the lowest levels of thehierarchy. A specialist begins by receivinga design request from its parent specialist.It refers to the specification database forrelevant specifications and then selects aplan using these data and the current de-sign state. 14The specialist can fill in some of the

design and can call its successors in plan-determined order with requests to refine asubstructure's design. The knowledge in

the specialist assigns priorities to the plansand invokes alternative plans in case a laterspecialist fails. When all of a specialist'splans fail, the specialist tells its parent.

Redesign phase. If any failures occurduring design, a redesign phase begins. Ifaredesign phase succeeds, the design phasecontinues where it left off. The system triesto handle all failures at the point of failurebefore admitting defeat and passing fail-ure information up the hierarchy. A step,for example, may be able to examine thefailure and then produce another value tosatisfy a failing constraint while still re-taining local integrity. This local attentionto failure is an essential element ofthe sys-tem's failure-handling behavior.

Communication. The main means ofcommunication in the system is passing in-formation and control messages betweenspecialists across the connections formingthe hierarchy. This restrains the controlflow, and the system exhibits clear, well-focused problem-solving activity.

Messages can request actions, reportfailures, ask for assistance, and make sug-gestions. This variety of messages is thekey to handling subsystem interactions.One part of the emerging theory of designproblem-solving is the form and contentof these design-oriented messages. Thedesign trace in the sidebar shows some ofthe types of messages used.

Other agents. In addition to the spe-cialists in the hierarchy, the system mayneed other specialists outside the hierar-chy. These are specialists in somewhatmore general activities commonly neededby several specialists in the hierarchy. Forexample, they may be certain kinds ofstress calculation modules or databasefunctions.

In a more general design system, re-quests could be made to other types ofproblem-solvers. 15 A human user couldact as a problem-solver, since requests forhelp will occur at well-defined points in thedesign. The expert system can subsequent-ly check the acceptability of the resultsprovided.

Routine design example

In the company that cooperated withus, an air cylinder (intended for accurate

COMPUTER94

Figure 2. Partial AIR-CYL structure.

and reliable backward and forward move-ment of some component) had to beredesigned for every new customer. Thiswas done to account for the particularspace it had to fit in or the intendedoperating temperatures and pressures.The air cylinder, shown in Figure 1, hasabout 15 parts.The AIR-CYL design problem-solving

system was developed with the task-levelDSPL language, which was in turn devel-oped with the Rutgers ELisp languageon aDECsystem-20. AIR-CYL demonstratedthe viability of our routine design theory.We are now extending the theory and ex-amining the issues that arose while usingthe air cylinder as our test case.

Conceptual structure. Before designingAIR-CYL, we interviewed an air cylinderdesigner, analyzed the design protocols,and obtained a trace of the design processto establish the underlying conceptualstructure in making an air cylinder (seeFigure 2).

For example, the cylinder head wasclearly treated as a separate conceptual en-tity. The spring was an essentially parallelactivity, while the rest of the design wastreated by the designer as the third majoractivity. Because specialists could be fairlyeasily identified and plans for eachspecialist were few and identifiable, de-signing an air cylinder appeared stronglyto be a routine design activity.

Deign agents. In the examples thatfollow, we use a simplified form of theDSPL language. The task-based languageallows expression of design agents, in-cluding specialists, and plans to carry outdesign objectives.

Aplan consists of a set of actions, someof which may be run in parallel. For exam-ple, in Figure 3, we show a plan with a taskcalled Validate and Process Require-ments, a constraint called Head andSpring Compatible?, and a specialistcalled Rest. Together, these form thedesign plan. Some specialists will also haverough design plans.

A task consists of the sequential use ofsteps, each of which obtains required in-formation, makes calculations, and makes

a decision about the value of a singleattribute.

Figure 4 shows a step that decides theseat width for the piston seal. In this step,"Piston Seal Seat Width" is the name of atask, "Seal Seat Width" is the name oftheattribute being decided, "Increase PistonThickness" is what the step will suggest ifit cannot make a decision (redesign is notpossible for this step), "Piston Thickness"is a previously designed attribute, and"Available > Seal Seat Width" is thename of a constraint.

July 1986

Figure 1. An air cylinder.

95

Handling failures

One view of failure handling considersall relevant knowledge to be available atfailure time. Our view is that data and con-

trol knowledge in human problem-solvingis structured and probably incomplete,

thus restricting the kinds of informationavailable for handling failures. The struc-ture of the design problem-solving system(that is, specialists, plans, tasks, and steps)provides the context in which to structurefailure handling.

In our theory, all design agents detecttheir own failure, try to determine what

went wrong, try to fix it locally, do so ifthey can, and report failure only if all at-tempts fail. Agents that have some controlover other agents can use those agentswhen trying to correct the detected prob-lem. By using these ideas, we hope toestablish what is essential for failurehandling in this kind of design activity. 16

This Is a trace;;highly edited fortra0 'is of a sucOof alternative plafdesign.

"* AIR

COMPUTER

:ment

96

Each kind of agent can have differentkinds of reasons for failing. For example,a step finds that a decision violates someconstraint, a task discovers that a step'sfailure can't be handled locally, a plan canfail if it's not applicable to the situation,and a specialist can fail if all of its plansfail.

For every kind of failure, a message giv-ing details is generated and passed back tothe calling agent. The message includes,wherever possible, suggestions about whatmight be done to alleviate the problem.Because there are usually many kinds ofproblems that can occur, an agent will firstlook at the message to decide what went on

below and what to do next. A FailureHandler attached to an agent contains theknowledge to make those decisions.

For some conditions, immediate failurecan be specified, while for others a re-design might be attempted. A redesigner isassociated with an agent. It contains

July 1986 97

knowledge of how to change a design ac- Research issuescording to suggestions.The sidebar presents an edited trace of

the AIR-CYL system in operation. It We feel that while the idea of designshows recovery from constraint failures. It refinement captures the essence of designalso shows a plan failing and a new-and problem-solving-at least in its relativelysuccessful-plan being selected. routine aspects-there are several impor-

tant aspects of problem-solving and theuse of plans that need more research.DSPL is being studied and refined to makeit more powerful, flexible, and easy to use.In addition, we hope to improve the inter-face with the system so others can use it.Eventually we expect to provide a graph-

COMPUTER98

ical interface to show the development ofthe design as it progresses.One possible way to deal with failures is

to try to relax one or more of the re-quirements. Clearly some requirementscan be softer than others-and asking theuser for some relaxation may clear the way

to a successful design. If much effort hasbeen expended on a design by both ma-chine and human, this makes a lot ofsense.

It may be possible for the system itself tochoose the requirements to relax, but a lotof special knowledge would be necessary

to implement this. Even knowing when toask for a relaxation will be difficult. This isa matter for future research.We are quite aware that there are bound

to be other examples of routine designtasks that cannot naturally be broughtunder the plan refinement paradigm. Even

July 1986 99

if it is true that design is a process ofchoosing plans and refining designs, ourability to construct expert systems fordesign is very much a function ofthe typesof design knowledge we can capture andmanipulate.We would like, as a result of our

research, to be able to characterize thekinds of design problems for which ourapproach can create effective expertsystems.

M ^ uch work remains to be done inbuilding expert systems for rou-

MI tine design activity before we

can understand what design is and howbest to build systems to do it. We feel thatthere is great need for tools that expressknowledge at the task level. DSPL is an ex-

ample of such a tool. We feel that our ap-proach of using a hierarchically structuredsystem with plan selection captures theessential qualities of routine design.[E

Acknowledgments

This work was supported at Ohio StateUniversity by Air Force Office of Scien-tific Research Grant 82-0255. We wouldalso like to acknowledge the cooperationoftheAccuRay Corp., Dave Herman, andPete Schmitz.

References1.J. McDermott, "Ri-A Rule-Based

Configurer of Computer Systems,"Artificial Intelligence, Vol. 19, No. 1,Sept. 1982, pp. 39-88.

2. T. Kowalski and D. Thomas, "The VLSIDesign Automation Assistant: PrototypeSystem," Proc. ACM/IEEE 20th De-sign Automation Conf., June 1983, pp.479483.

3. W. Birmingham and D. Siewiorek,"Micon: A Knowledge-Based Single-Board Computer Designer," Proc.ACM/IEEE 21st Design AutomationConf., June 1984, pp. 565-571.

4. B. Chandrasekaran, "Generic Tasks inKnowledge-Based Reasoning: Character-izing and Designing Expert Systems at theRight Level of Abstraction," Proc. IEEE

Int'l Conf. on Al Applications, Dec.1985.

5. D. C. Brown, "Expert Systems for DesignProblem-Solving Using Design Refine-ment with Plan Selection and Redesign,"unpublished PhD dissertation, Computerand Information Science Dept., OhioState University, Columbus, Ohio, Aug.1984.

6. G. Sussman, "Electrical Design-AProblem for AI Research," Proc. Int'lJoint Conf. Al, Aug. 1977, pp. 894-900.

7. D. McDermott, "Circuit Design asProblem-Solving," Al and PatternRecognition in CAD, J.-C. Latombe, ed.,North-Holland, Amsterdam, 1978, pp.227-245.

8. T. Mitchell, L. Steinberg, and J. Shul-man, "A Knowledge-Based Approach toDesign," IEEE Trans. Pattern Analysisand Machine Intelligence, Vol. 7, No. 5,Sept. 1985, pp. 502-510.

9. M. Grinberg, "A Knowledge-BasedDesign System for Digital Electronics,"Proc. AAAIRlrst Ann. Nat'l Conf. Al,Aug. 1980, p. 283.

10. J. Dixon, M. Simmons, and P. Cohen,"An Architecture for Application ofArtificial Intelligence to Design," Proc.ACM/IEEE 21st Design AutomationConf., June 1984, pp. 634-640.

11. S. Mittal, M. Morjaria, and C. Dym,"Pride: An Expert System for the Designof Paper-Handling Systems," Appli-cations of Knowledge-Based Systems toEngineering Analysis and Design, C.Dym, ed., ASME, New York, 1985, pp.99-116.

12. M. Stefik, "Planning with Constraints(Molgen: Part I and Part 2)," ArtificialIntelligence, Vol. 16, No. 2, 1980.

13. D. C. Brown and R. Breau, "Types ofConstraints in Routine Design Problem-Solving," Proc. IEEE First Int'l Conf.Applications of Al to EngineeringProblems, Southampton, England, Apr.1986.

14. D. C. Brown and B. Chandrasekaran,"Plan Selection in Design Problem-Solving," Proc. AISB 85, Conf. of theSociety for the Study of ArtificialIntelligence and the Simulation ofBehavior, Warwick, England, Apr. 1985.

15. B. Chandrasekaran, "Towards a Taxon-omy of Problem-Solving Types," AlMagazine, Vol. 4, No. 1, Winter-Spring1983, pp. 9-17.

16. D. C. Brown, "Failure Handling in aDesign Expert System," in Computer-Aided Design, J. Gero, ed., Butterworth& Co., London, 1985.

David C. Brown is an assistant professor ofcomputer science at Worcester Polytechnic In-stitute in Massachusetts. His research interestsare knowledge-based problem-solving fordesign, languages and systems for design,knowledge acquisition for design and diag-nosis, and intelligent database browsing formanufacturing applications.Brown received his BSc in computer science

from North Staffordshire Polytechnic and anMSc degree in computing from the Universityof Kent at Canterbury. He has an MS degree incomputer and information science and a PhDin artificial intelligence from Ohio StateUniversity.He is a member of the ACM, IEEE Com-

puter Society, and AAAI.

Readers may write to Brown at the AIResearch Group, Computer Science Dept.,Worcester Polytechnic Institute, Worcester,MA 01609.

B. Chandrasekaran has been at Ohio StateUniversity since 1969. He is currently professorof computer and information science. From1967 to 1969 he was a research scientist with thePhilco-Ford Corporation in Blue Bell, Pa.,working on speech- and character-recognitionmachines. His major research activities are cur-rently in knowledge-based reasoning; he directsthe Al group at OSU.

Chandrasekaran received his bachelor of en-gineering degree with honors from Madras Uni-versity in 1963 and his PhD from the Universityof Pennsylvania in 1967. He is associate editorfor AI of IEEE Transactions on Systems, Manand Cybernetics and chairs the society's Tech-nical Committee onAl. Hewas elected aFellowof the IEEE in 1986.

100 COMPUTER