Toward automating recognition of differing problem-solving demands

Int. J. Man-Machine Studies (1988) 29, 599-611

Toward automating recognition of differing problem-solving demands JEFFREY STOUT:~, GILBERT CAPLAIN,t SANDRA MARCUS~ AND JOHN McDERMOTtw

Department of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213, USA

(Based on a paper presented at the Second A A A I Workshop on Knowledge Acquisition for Knowledge-Based Systems, Banff, October 1987)

SALT provides a knowledge acquisition framework for the development of expert systems that use propose-and-revise as their problem-solving method. These systems incrementally construct a tentative design, identify constraints on the design and revise design decisions in response to constraint violations. By having an understanding of the specific problem-solving method used to integrate the knowledge it acquires, it has been previously shown that SALT possesses a number of advantages over less restrictive programming languages. We have applied SALT to a new type of propose-and-revise task, and have identified areas where SALT was too restrictive to adequately permit acquisition of domain knowledge or efficient utilization of that knowledge. Addressing these problems has led to a more "general" SALT and to a better understanding of when it is an appropriate tool.

1. Introduction

SALT ~r is a knowledge acquisition tool designed to assist in building expert systems that assume a propose-and-revise problem-solving strategy. A SALT-genera ted expert system will construct, as opposed to select, a solution (cf. Clancey, 1985). The SALT-assumed method incrementally builds up a description of a proposed design, identifies constraints on parts of the design and modifies the proposal in response to the detection of constraint violations. As with other similarly moti- vated knowledge acquisition tools (Davis & Lenat , 1982; Boose, 1984; Kahn, Nowlan & McDermot t , 1984; van de Brug, Bachart & McDermot t , 1986; Eshelman & McDermot t , 1986), its ability to provide assistance derives f rom the fact that all the systems it builds use the same problem-solving method.

Giving a knowledge acquisition tool an understanding of the knowledge roles in the problem-solving method it presupposes gives it considerable leverage (McDermot t , 1986; Clancey, 1985; Neches, Swartout & Moore , 1985; Swartout, 1983). This understanding results in a narrow, structured language which the domain expert can use to concisely convey knowledge to the tool and which the generated system uses to explain what it knows. I t also helps in defining when that knowledge should be brought to bear in problem-solving, and in determining the adequacy of

t Now at CERMA-ENPC, La Courtine B.P. 105, 93194 Noisy le Grand, France. :~ Now at the Advanced Technology Center, Boeing Computer Services, P.O. Box 24346, M/S 7L-64,

Seattle, WA 98124, USA. w Currently on leave at Digital Equipment Corporation, HL02-3/CO7, 77 Reed Rd, Hudson, MA

01749, USA. ~r kNowledge ACquisition Language.

599 0020-7373/88/100599 + 13503.00/0 ~) 1988 Academic Press Limited

600 J. STOUT ET AL.

the knolwedge base for its intended function. Finally, it determines the domains for which the tool is appropriate. SALT fits all of these descriptions (Marcus, McDermott & Wang, 1985; Marcus & McDermott, 1986), but it was not clear if it was too restrictive, unnecessarily sacrificing some generality.

SALT has been successful in acquiring the knowledge for and in generating VT, an expert elevator configurer (Marcus, Stout & McDermott, 1986), but it was not clear from that work to what degree both presupposing a single problem-solving method and basing that method on only a single domain restricted the scope of SALT's applicability. This paper details the "extension" of SALT to a new domain, that of production scheduling. This extension has led to a SALT which can handle a wider range of constructive tasks (without compromising any of its leverage), and has also helped to better define when SALT and a knowledge domain are appropriate for each other. More importantly, however, we have found that no single propose-and-revise scheme is appropriate for all such tasks. Thus, SALT must be able to determine which scheme is best for a particular domain and act accordingly.

The next section briefly reviews the representation SALT uses and the method it assumes. Section 3 describes the scheduling task and the scheduler that was built using SALT. Section 4 describes the problems encountered in building the scheduler and how SALT had to be changed to address those problems. Section 5 discusses the implications of those changes both for the problem-solving method and the scope of tasks for which SALT is appropriate.

2. SALT's assumptions

A SALT-generated system constructs, rather than selects (cf. Clancey, 1984; Clancey, 1985), solutions using a "purpose-and-revise" method (Marcus & McDermott, 1986). In many domains, it is not possible to construct a solution by a simple sequence of deterministic decisions. In such domains, plausible reasoning combined with the ability to backtrack to revise bad guesses can be an efficient problem-solving strategy (Stefik, Aikins, Balzer, Benoit, Birnbaum, Hayer-Roth & Saccerdoti, 1983). Even least commitment planners such as MOLGEN (Stefik, 1981a, b) sometimes have a need for this kind of reasoning. For example, decisions in the course of constructing a solution are sometimes underconstrained, or must be made based on incomplete information. The method SALT assumes allows for a least commitment construction of a porposed design, but offers the capability of revising decisions when the proposed design does not meet all constraints.

SALT categorizes domain knowledge according to the role it plays in problem- solving. From SALT's perspective, domain-specific knowledge always plays one of three roles:

1. PROPOSE-A-DESIGN-EXTENSION. 2. IDENTITY-A-CONSTRAINT on part of the design. 3. PROPOSE-A-FIX for a constraint violation.

Each "piece" of PROPOSE-A-DESIGN-EXTENSION knowledge specifies a procedure for defining the value of a part of the design description. These procedures may either determine that value with certainty or propose a preferred

DIFFERING PROBLEM-SOLVING DEMANDS 601

choice. (The user need not be aware of the distinction.) Details of the procedures consist largely of constants to be assigned, algebraic formulas for calculations and specifications which are translated into database calls. These procedures are also used to specify I D E N T I F Y - A - C O N S T R A I N T knowledge. Constraints require the additional knowledge of the value it constrains and in how it limits that value (e.g. a minimum or maximum). PROPOSE-A-FIX knowledge identifies a design decision that could be changed in order to remedy a particular constraint violation. This includes the nature of that change and some indication of how costly the change would be.

Classifying knowledge in this way categorizes it according to the effect it has in determ!ning the values of variables that represent the final design description (the desired output of the system). P R O P O S E - A - D E S I G N - E X T E N S I O N proposes a value for a variable, I D E N T I F Y - A - C O N S T R A I N T limits the value of a variable and PROPOSE-A-FIX revises the value of a variable. Organizing the knowledge base in this way still leaves open the question of how these pieces of knowledge fit together to form a sequence of actions that constructs a solution, An outline of how they fit into the method SALT assumes when constructing a system is given below:'~

1. Propose extensions to the design and identify constraints until a constraint violation is detected.

2. Propose possible remedies for the constraint violation. 3. Select the least costly fix not yet at tempted. 4. Tentatively revise the design insofar as to examine the effect on the constraint

violation. 5. If the constraint violation persists, go back to Step 3. 6. Remove portions of the design inconsistent with the revision. 7. Implement the revision and return to Step 1.

Proposed designs are built incrementally in the sense that each step to extend the design uses input or decisions already made. Simultaneously, the system identifies constraints on the design as enough information becomes available to derive their values. The control in this phase is data-driven; whenever all the information required to apply a procedure is available, the procedure is applied. (More than one procedure may be "eligible" at a time, but their relative order is unimportant .) As each procedure is applied, a dependency network is built up that records the specifics of the applied procedure. Constrained values are compared with their constraints as soon as both are proposed. If a constraint violation is detected, the system will use domain-specific proposals (fixes) to determine which decisions may be revised. It also uses domain-specific knowledge about relative cost of revisions plus a measure of likelihood of success in deciding which revision(s) to try. Once a successful fix if found, a truth maintenance system is used to trace through the dependency network and remove any values that may be inconsistent with the change(s) made. The system then re-enters the data-driven phase of extending the proposed design using the new data.

t The SALT-generated problem-solving architecture is quite similar to that of EL (Sussman, t977; Stallman & Sussman, 1977), although it differs somewhat in how the system decides which decisions to revise.

602 J. STOUT ET AL.

3. Building the scheduler

3.1. SELECTING THE FACTORY SCHEDULING DOMAIN

SALT first crystalized during the building of VT, an expert system for configuring elevators (Marcus et al . , 1986). VT takes as input the customer's functional specifications for the elevator, such as the speed at which it must travel, its carrying capacity, and key architectural information about the elevator shaft, such as the wall-to-wall dimensions and locations of sills and rail supports. The task is to select all the necessary pieces of equipment and produce a configuration and layout of parts that meet those specifications, as well as satefy, installation, and maintenance requirements.

Although SALT was successful in building and maintaining VT, a single case gives little indication of a tool's generality or the range of tasks over which it is applicable. It was clear that SALT was good for elevator configuration, but inappropriate for classification tasks such as medical diagnosis. One positive instance (hit) and one far-off negative instance (miss) do little in determining bounds. Given that we wanted not only to gain a better understanding of SALT's limitations, but also to extend SALT so as to transcend those limitations, the ideal task would be one that was a near miss. Such a task would give a good indication of the type of task characteristics responsible for bounding SALT's applicability, and if the miss was "near" enough, a reasonable shot of extending SALT to make it a hit. If, however, SALT could not transcend the limitation, the consolation would be a reasonably well-defined boundary.

The domain of factory scheduling was chosen as a task clearly different from electromechanical system configuration, but not so different as to make SALT hopelessly inappropriate. It appeared to be viable since it seemed that all SALT required of a task was that it could be structured to provide methods for initial values for extending a design, methods for defining boundaries between acceptable and unacceptable solutions, and a way to change values in response to a particular boundary violation that would lead to an acceptable solution.

Given this view of SALT's assumed method, scheduling appeared to be a suitable test-domain, since many scheduling tasks require coming up with an initial schedule, recognizing situations that make the schedule infeasible, and making minimally disruptive changes which make the schedule acceptable once more. To test the suitability, we built a prototype for production scheduling for escalators and elevators. Figure 1 shows the flow of work performed to produce and deliver an order for one product line. Each box represents a department that must do some processing on an order of a given product type. Each department must complete work on an order before it can move on to the next department (indicated by an

FIG. 1. The flow of work performed between the departments for one type of order.


arrow). Departments which are able to process an order in parallel lie on different branches. Associated with each department is a normal "lead" time for a given product type. This represents the amount of time the order would normally remain in a department while work was being done on that job. Not all of the lead time is actual hands-on processing time. For example, in the Mechanical Layout department the engineer might normally review a job as soon as it is assigned, checking for any missing information required from the customer or from other departments simultaneously processing the job, putting out routine requests for information, and then working on other orders while those requests are filled. There is a possibility for "shrink" time, requiring a job to be completed in the minimal amount of hands-on time. "Slack" time, leaving a job in a department longer than necessary, is also used to do things such as smoothing out the load to subsequent departments or avoiding shipping equipment to the field is prepared to install it. The task of the scheduler, then, is to provide start and complete dates for each relevant event in the processing of each order.

3.2. ACQUIRING THE KNOWLEDGE

When giving SALT a piece of domain knowledge, the user must first indicate what role that knowledge will play. Once a role is selected, SALT presents the user with a schema containing slots which the user may fill to complete the specification of that piece of knowledge. The three examples below are representative pieces of scheduler knowledge which fill each of SALT's three knowledge roles. More specifically, they show completed SALT schemas.

In a completed schedule, every order has a specific date associated with when each department begins processing that order. The date a department starts processing an order usually depends on when some other departments are finished processing it. The following is the piece of PROPOSE-A-DESIGN-EXTENSION knowledge that determines the starting date for shipping the order:

1 Name: START-DATE 2 Defined for: DEPT ORDER 3 Precondition: [DEPT= SHIP-MODULE]

AND [PRODUCT-CODE = JB-2] 4 Procedure: CALCULATION 5 Formula: MAX [COMPLETE-DATE@DEPT= MECH-GO

COMPLETE-DATE@DEPT = EE-CI] 6 Justification: FROM JB-2 FLOW CHART IN

PROCEDURES MANUAL

Enter your command [EXIT]:

Thus the starting date will be the larger of the completion dates in the Mechanical G.O. and E . E . C . I . Departments (which is consistent with the flowchart shown previously). Since DEPT and ORDER are defined as indices, SALT knows that there may multiple values for START-DATE, with each one specific to a particular

604 J. STOUT E T AL.

department name and order number. COMPLETE-DATE@DEPT = MECH-GO means the COMPLETE-DATE whose department index is MECH-GO.t

SALT translates the above information into a PROPOSE-A-DESIGN- EXTENSION rule which can be paraphrased as follows:

Given that the scheduled COMPLETE-DATE for an ORDER has been generated for the MECH-GO DEPT, and

Given that the scheduled COMPLETE-DATE for that ORDER has been generated for the EE-CI DEPT,

If there is no value for the STARTING-DATE for that ORDER for the SHIP-MODULE DEPT, and

If the ORDER's PRODUCT-CODE is JB-2, then:

Make the SHIP-MODULE STARTING-DATE for the ORDER the larger of the two COMPLETE-DATES.

Leaves a trace that the ORDER's PRODUCT-CODE and those COMPLETE- DATES contributed to this STARTING-DATE. (This builds the dependency network used by the truth maintenance system.)

Leave a trace describing the inference as given here. (This is used by the explanation facility.)

Thus this procedure captures the domain knowledge, indicated by the flowchart, that processing in the SHIP-MODULE department begins when both the MECHANICAL-GO and EE-CI departments have finished with the order.

As jobs are assinged starting dates for departments, they influence the load that the department will be working under. Since there is a limit on how much work a department can handle, a piece of IDENTIFY-A-CONSTRAINT knowledge is needed to detect when this happens:

1 Constrained value: 2 Constraint type: 3 Constraint name: 4 Defined for: 5 Precondition: 6 Procedure: 7 Formula: 8 Justification:

LOAD MAXIMUM MAXIMUM-LOAD DEPT WEEK DEPT = MECH-GO CALCULATION MANPOWER *2 AVERAGE MECH-GO ENG. CAN PERFORM

2 JOBS/WEEK


Thus the maximum workload for the Mechanical G.O. Department in any given week is equal to the amount of manpower available to the department for that week (which can vary due to vacations, overtime, etc.) multiplied by the number of orders each person can process in a week (here it is two). SALT translates this information into an IDENTIFY-A-CONSTRAINT rule which specifies a procedure for specify-

t Indices are actually doing much more than this. COMPLETE-DATE, as one might suspect, is indexed by ORDER as well. SALT will assume (unless told otherwise) both that all ORDER indices tor any values in the procedure indexed by ORDER must match, and that they determine the value ol the ORDER index of the result.


ing a value for the constraint and provides crucial information about the constraint to the problem-solver, a paraphrase of this rule would be:

Given that there is a specified M A N P O W E R for the M E C H O - G O D E P T for a particular W E E K ,

If that W E E K has no value for M A X I M U M - L O A D for the M E C H - G O DEPT, then:

Make the M A X I M U M - L O A D for the M E C H - G O D E P T for that W E E K the value of the M A N P O W E R times two.

Identify this value as a M A X I M U M constraint on the L O A D for the M E C H - G O D E P T for that WEEK.

Leave a trace that the M A N P O W E R contributed to this M A X I M U M L O A D .

Leave a trace describing the inference as given here.

When the user has idenified a constraint, SALT will expect proposals for remedying violations of that constraint. For example orders often have deadlines for certain activities (e.g. certain pieces of equipment must be delivered to the site by a certain time). Failure to meet a deadline usually results in a penalty. This imposes constraints on when departments must finish processing the order. If these constraints are violated, the schedule must be modified in order to avoid the penalty. One way to do this is to rush the order through a particular department. This is specified to SALT with the following piece of PROPOSE-A-FIX knowledge:

1 Violated constraint: 2 Value to change: 3 Ordering function: 4 Change type: 5 Step type: 6 Preference rating: 7 Preference reason: 8 Justification:

M A X I M U M - C O M P L E T E - D A T E L E A D - T I M E @ D E P T = * MINIMIZE START-TIME D E C R E A S E T O - C U T O F F 2 Rushes processing of order


This fix knowledge instructs SALT to decrease an order 's L E A D - T I M E (the "hands on" time) in a department in the event that a deadline is not met. The "ordering function" specified above indicates that SALT should try to decrease the L EAD-TI ME in a department which handles the order early on. This is done to leave some "play" in the schedule if future events make additional rushes necessary.

This fix, and others for the same constraint violation, are translated into a PROPOSE-A-FIX rule which will suggest potential remedies whenever the associated constraint is violated. The paraphrase of this rule would be:

If there has been a violation of M A X I M U M - C O M P L E T E - D A T E for an O R D E R , then:

Try to D E C R E A S E that O R D E R ' s L E A D - T I M E in any D E P T down to its minimum value (the "shrink" time). In selecting a DEPT, give preference to those with the smallest START-TIME.

606 J. STOUT E T A L .

4. Problems in applying SALT to scheduling Although SALT is now an appropriate tool for the scheduling task, a significant amount of effort was required to make it so. Slight changes in the representation were necessary, as well as variations in how domain kwledge is brought to bear. This section details those changes, and how those changes have helped in understanding both when SALT is appropriate and how it can determine for itself how it can be of the most help.

The first step in enhancing a knowledge acquisition tool to address perceived deficiencies is to identify the necessary enhancements, and determine for each one whether it represents a new general capability or a variation of an existing capability. If it is a variation, the tool mus be able to recognize situations where the variation is appropriate and act accordingly. For SALT, this means recognizing features of the domain which would cause SALT to use an alternate knowledge representation or assume an alternate problem-solving strategy.? Ideally these "switches" would be flipped by the system automatically based on what it currently knows about the nature of the task.

The scheduling task, although a constructive task, did not initially fit well within SALT's propose-and-revise scheme. The main reasons for this were the dynamic nature of fix preferences and the high level of conflict among fixes for different constraints. These are discussed in greater detail below.

VT's fix knowledge is static; the precise value to be fixed is specified during the SALT interview, before the knowledge base is compiled. The relative cost of fixes are based on a static preference function. The following are the possible negative effects that VT's fixes can have on a design, ranked from least to most damaging:

1. Causes no problem. 2. Increases maintenance requirements. 3. Makes installation inconvenient. 4. Changes minor equipment selection. 5. Violates minor equipment constraint. 6. Changes minor contract specifications. 7. Requires special part design. 8. Changes major equipment selection. 9. Changes the building dimensions.

10. Changes major contract specifications. 11. Increases maintenance costs. 12. Compromises system performance. 13. Violates elevator code.

Relative position in this ordering is significant, but absolute position is not. For each fix, the expert indicates a single value to be changed (e.g. the machine model). The expert then associates the change with its effect on the design (e.g. "Changes major equipment selection"). If more than one fix is applicable for a particular constraint violation, VT investigates the lowest ranked (most preferred) fix first.

In the scheduling domain, it is impossible to specify the precise value to be changed during the SALT interview. For example, if a department's maximum load

t Given that these enhancements result from near miss tasks, the result would probably be slight variations in the representation or method, rather than something radically different.


is exceeded for a particular week, one fix is to delay processing on one of the orders which is contributing to that load. The most an expert can tell S A LT is that there is some "set" of possible fix values; for example, the START-TIME for any jobs in the department during the peak load. In that case, the expert must give some criterion for selecting one of the members of the set. In the maximum load example, one might select the job with the lowest priority. Thus where VT uses a static cost function to rank fix preference, the scheduler requires a dynamic ordering function. The scheduler must use a dynamic function because the expert supplying the knowledge to SALT cannot anticipate what jobs will be in the system when a maximum load is exceeded.

This had been integrated into SALT as a new general capability. Since VT's fixes specify only single values, an ordering function need not be given. If the fix value specifies a set, SALT presents the user with an opportunity to enter an ordering function.

The second major difference between the domains is that for the scheduler, virtually every fix has the potential of causing several new constraint violations. VT also has interaction between fixes for different constraints, but in almost every case the fixes for one constraint reinforce those for other constraints. For VT it makes sense to fix constraint violations as soon as they arise using a local, single-constraint- specific strategy. It is best to fix a bad guess before a lot of additional design work is done using that bad proposal. If there is no antagonism among constraints, the additional work won' t help decide how to fix the violation. The success of the fix can be judged by making sure the single constraint is no longer violated. Thus VT can resolve constraint violations as they arise, but his localized strategy would cause the scheduler to deal with minor problems before recognizing a larger problem exists that will make the other fixes moot. The scheduler must therefore delay constraint checking until it knows more about the schedule. In fact, the level of antagonism between fixes for different constraints is so high that a full tentative schedule is necessary before one can decide which violated constraint should be addressed first. This implies that once a violated constraint is selected and a fix proposed, local search is not a reliable predictor of fix success. In order to be assured that a fix does not cause the violation of a more important or more fundamental constraint, lookahead also must be extended to the global level.

This requirement that an entire schedule be built before addressing constraint violations, in addition to the need for global lookahead, was in direct conflict with VT's needs. The difference between the two strategies was not a mat ter of knowledge; it was a difference in how knowledge is brought to bear by the problem-solving method. Our initial solution was to build two separate control shells which make different use of the same SALT-generated rules, thus introducing a variation into SALT.

The new problem-solving method used by the schedular is:

1. Propose extensions to the design and identify constraints unt i l no m o r e can

be done.

2. Check for constraint violations. 3. Select one of the violated constraints and propose possible remedies. 4. Select the least costly fix possible.

608 J. STOUT ET AL.

5. Implement the revision. 6. Remove portions of the design inconsistent with the revision and return to

Step 1.

A more general approach results from recognizing that the fundamental issue is constraint antagonism. Human experts often solve such problems by breaking the large problem into smaller pieces, in an attempt to keep the interactions localized within more tractable subtasks. Thus the real issue here is in delineating areas of antagonism and having a method that delays constraint evaluation until an area is ready to be evaluated. Whereas SALT's original, local search is used to insure (in a narrow, local sense) that a proposed fix for a constraint violation will be successful, in a more general treatment lookahead will need to go far enough to examine the effects on the other constraints within the violated constraint's conflict area.

Taking this view, VT and the scheduler represent the two extremes. In VT, constraint antagonism is very low, thus making it possible to consider almost every constraint individually. [Those which were antagonistic were given special treatment (Marcus, Stout & McDermott, 1987).] Lookahead is limited to examining the effect on the violated constraint. The level of antagonism in the scheduler is so high that there is a single "area of antagonism"--the entire system. To be useful, any lookahead would have to examine the effects of each proposed fix on the entire system.

Given this approach, here is the more general problem-solving method that SALT needs to assume:

1. Propose extensions to the design and identify constraints. When a constraint violation is detected, ignore it until all other constraints in its area of antagonism are identified.

2. Propose possible remedies for all violated constraints in the area. 3. Select the least costly fix not yet attempted in this area. 4. Tentatively revise the design insofar as to examine the effect on all constraints

in the same area. 5. If the constraint violations persist, go back to Step 3. 6. Remove portions of the design inconsistent with the revision. 7. Implement the revision and return to Step 1.

Step 3 is the key to thrash prevention. Originally SALT's concept of "not yet attempted" was "not yet attempted for this particular constraint violation"--the system could not detect when it was thrashing, since it did not have any memory of what it did on previous violations of the same constraint. Now areas of possible thrashing are delineated, and the system keeps track of previous fix attempts at the appropriate level to prevent thrashing.

Thus what at first appears to be a variation in SALT's problem-solving method upon further inspection becomes a generalization of that method. SALT now looks for areas of possible antagonism in the knowledge base and organizes constraint evaluation, fix proposal and lookahead to work within the above method. This works both for the few isolated areas of antagonism in VT and for the system-wide antagonism in the scheduler.


5. Determining when SALT is appropriate

The key to determining the usefulness of a tool like SALT for a particular task is to ask whether its assumed problem-solving method is appropriate. It is therefore important to characterize SALT's assumed method with respect to the types of demands it makes on the knowledge sources of the domain. An initial "broad cut" can be made by the fact that the method constructs, rather than selects, a solution (cf. Clancey, 1984, 1985). A selection method demands that the domain expert be able to pre-enumerate the entire set of possible solutions. For tasks which cannot meet this criterion, construction is the alternative.

It is in these cases where the domain fails the test for supplying a sequence of pre-enumerated decisions that propose-and-revise becomes a candidate. The propose-and-revise strategy makes important demands on the organization of the domain. More specifically, in order for SALT to be an appropriate tool, the domain expert must be able to describe the task by categorizing each piece of the domain knowledge into one of the three roles described previously. Further, the degree to which SALT is easy to use is determined by the degree to which it is natural to think of the task in terms of SALT's roles.

5.1. SALT AND VT

Because VT deals with a large number of potential part combinations and must customize the layout to the space available in individual buildings, it must construct its solution. VT cannot provide a completely predetermined sequence of deicsions; many of the decisions it must make are underconstrained. For example, the width of the elevator car plus the width of the counterweight plus the space between the car and counterweight plus the space between the counterweight and the wall must sum to the wall-to-wall distance in the elevator shaft. The width of the car is selected by the customer, but this input combined with the constraint do not result in an algorithm for determining the other three values. VT must make a reasonable guess at one the values, for changing it if it causes problems later in the design process. VT also has cases of decisions so interdependent that no decision can be made without knowing its own result. For example, the hoist cable quantity and diameter depend on hoist cable quantity and d iamete r - - they must be able to support their own weight, as well as the weight of other parts whose selection is based partly on the hoist cable quantity and diameter. Again, VT must make an estimate, revising it if necessary.

VT's domain experts are able to easily cast their knowledge into the roles that SALT assumes. VT is able to use propose-and-revise for the cases described above. For example, the VT method estimates the lowest possible value for hoist cable quantity and diameter (PROPOSE-A-DESIGN-EXTENSION) , selects other parts using these estimates (also using P R O P O S E - A - D E S I G N - E X T E N S I O N knowledge), then derives from these constraint on the quantity and diameter that m u s t be used to insure safety ( IDENTIFY-A-CONSTRAINT) . If the value of the constraint does not match the initial estimate, quantity and diameter are increased (PROPOSE-A-FIX).

610 J. STOUT ET AL.

5.2. SALT AND THE S C H E D U L E R

The scheduler must construct its solution because at any one time there will be a unique configuration of orders in the system and available resources that will affect the assignment of dates. It is impossible for the scheduler to operate based on a predetermined sequence of decisions, since many of its decisions are underconstrained, and because of changes in the world as new orders are entered and resources shift (due to shortages, sick days, and so forth).

Propose-and-revise is a reasonable candidate to address this problem, and the SALT knowledge roles are appropriate as well. The flow chart shown previously is a high-level view of the procedures used to propose a tentative schedule for an individual order using normal lead times (PROPOSE-A-DESIGN-EXTENSION) . There are several ways than an initial schedule may be unacceptable ( IDENTIFY- A-CONSTRAINT) . For example, contracts may have promised dates for specific events, and departments have a maximum work load. The responses to these situations include rescheduling orders and shifting resources (PROPOSE-A-FIX) .

6. Conclusion

The scheduling task was initially chosen because it was obviously a configuration task that could be performed in a propose-and-revise manner. By changing SALT in response to the needs of the task, we have developed a more general SALT. If any of SALT's leverage as a method-based knowledge acquisition tool was sacrificed in the process, it was leverage of a type yet to be discovered, since VT can not only still be built and maintained using SALT, it can now be done more easily and can be extended to a cover a larger port ion of elevator jobs.

In determining whether SALT and a domain are appropriate for each other, one should not become bogged down in the specifics of the problem-solving strategy. SALT is appropriate for the scheduling task, not because the task has the exact same form as that of VT, but because the knowledge roles are well defined and match those which SALT assumes. If a prospective domain has PROPOSE-A- DESIGN-EXTENSION, IDENTIFY-A-CONS TRA IN T, and PROPOSE-A-FIX knowledge classes (and only those), it should be possible to either use SALT as is, generalize SALT to handle new domain features, or add variations to SALT's knowledge roles and/or problem-solving method to handle the new features. If variations are necessary, then mechanisms must be introduced that can recognize when those variations are appropriate; otherwise, the end result is a set of possible SALTs where the user is left holding the bag as to which one to use.

There is no reason to believe that every a domain having the three SALT knowledge roles is compatible with SALT's propose-and-revise scheme. Such domains could be useful in determining how far SALT's problem-solving method can be generalized. At worst, these domains would be invaluable in bounding the set of problems appropriate for SALT. However, one has yet to be identified.

Finding additional tasks for which a knowledge acquisition tool is appropriate is gratifying, but not very informative. Only by attempting to go beyond a tool's capablities can one determine what those capabilities are. Hopefully as S A LT tries to "acquire" other tasks, it will fail as successfully as it has for scheduling. As these


failures help to extend SALT's capabilities and/or determine hard boundaries on SALT's applicability, a clearer picture should emerge of what it means for a task to be called "propose-and-revise" .

References

BOOSE, J. (1984). Personal construct theory and the transfer of human expertise. In: Proceedings of the Fourth National Conference on Artificial Intelligence, Austin TX.

CLANCEY, W. (1984). Classification problem solving. In: Proceedings of the Fourth National Conference on Artificial Intelligence, Austin TX.

CLANCEY, W. (1985). Heuristic classifiction. Artificial Intelligence, 27, 289-350. DAvis, R. & LENAT, D. (1982). Knowledge-Based Systems in Artificial Intelligence. New

York: McGraw-Hill. ESHELMAN, L. & MCDERMOTt, J. (1986). MOLE: a knowledge acquisition tool that uses its

head. In Proceedings of the 5th National Conference on Artificial Intelligence, pp. 950-955, Philadelphia, PA.

KAHN, G., NOWLAN, S. & MCDERMOTT, J. (1984). A foundation for knowledge acquisition. In: Proceedings of IEEE Workshop on Principles of Knowledge-based Systems, Denver, CO.

MARCUS, S. McDERMOTT, J. & WANG, T. (1985). Knowledge acquisition for constructive systems. In: Proceedings of the International Joint Conference on Artificial Intelligence, pp. 637-639, Los Angeles, CA.

MARCUS, S. & McDERMOTT, (1986). SALT: a knowledge acquisition tool for propose-and- revise systems. Technical Report CMU-CS-86-170, Carnegie-Mellon University, Depart- ment of Computer Science.

MARUCS, S., STOUT, J. & McDERMOTT, J. (1986). VT: an expert elevator configurer that uses knowledge-based backtracking. Technical Report CMU-CS-86-169, Carnegie-Mellon University, Department of Computer Science.

MARCUS, S., STOUT, J. & McDERMOTT, J. (1987). VT: an expert elevator designer that uses knowledge-based backtracking. AI Magazine, Winter.

McDERMOTr, J. (1986). Making expert systems explicity. In Proceedings of the IFIP Congress, Dublin, Ireland.

NECHES, R., SWARTOUT, W. • MOORE, J. (1985). Explainable (and maintainable) expert systems. In: Proceedings of the International Joint Conference on Artificial Intelligence, 382-389, Los Angeles, CA.

STALLMAN, R. M. & SUSSMAN, G. J. (1977). Forward reasoning and dependency-directed backtracking in a system for computer-aided circuit analysis. Artificial Intelligence, 9, 135-196.

STEFIK, M. (1981a). Planning with constraints (MOLGEN: Part 1). Artificial Intelligence, 16, 111-140.

STEFIK, M. (1981b). Planning and meta-planning (MOLGEN: Part 2). Artificial Intelligence, 16, 141-170.

STEFIK, M., AIKINS, J., BALZER, R., BENOIT, J., B1RNBAUM, L., HAYES-ROTH, F. & SACERDOTI, (1983). The architecture of expert systems. In: F. HAYES-ROTH, D. WATERMAN & D. LENAT, Eds, Building Expert Systems, pp. 89-126. Reading, MA: Addison-Wesley.

SUSSMAN, G. J. (1977). Electrical design, a problem for artificial intelligence research. In: Proceedings of the International Joint Confernece on Artificial Intelligence, pp. 894-900, Cambridge.

SWARTOUT, W. XPLAIN: a system for creating and explaining expert consulting systems. Artificial Intelligence, 21, 285-325.

VANDE BRUG, A., BACHANT, J. & McDERMOTt, J. (1986). The taming of R1. IEEE Expert, 1, No. 3.

Toward automating recognition of differing problem-solving demands

Documents

Transcript of Toward automating recognition of differing problem-solving demands