MACE: A system for the construction of functional models using case-based reasoning

Expert SystemsWith Applications,Vol. 9, No. 3, pp. 347-360, 1995 Copyright0 1995 Elsevier Science Ltd Printedin the USA. All rightsreserved @x57-4174/95$9.50 + .I0

Pergamon

0957-4174(95)00009-7

MACE: A System for the Construction of Functional Models using Case-Based Reasoning JOHN Department of Computer

HUNT

Studies, University of Wales, Aberystwyth,

Dyfed, SY23 3DB. UK

Abstract-A great deal of research has been carried out into what has been called Model-Based Reasoning (MBR). These are systems in which a model is used as the basis of the problem-solving process. However, a major bottleneck in the construction of any MBR system is the acquisition of the model. This is often a time-consuming and error-prone process. In addition, it often requires expert knowledge of the model@ technique being applied as well as an understanding of how the model will be used. In this paper a system called MACE is presented that automatically constructs a functional model from a library of partial models. This system exploits Case-Based Reasoning (CBR) technology to perform this construction. The paper introduces both the concepts behind functional model and CBR before going on to describe the components of the MACE system. It then illustrates, by example, how MACE constructs a functional model from the case data base.

1. INTRODUCTION

understanding of how the actual system works (and often of how the model will be analysed and what use will be made of it). If these models could be automatically synthesized and then presented to an experienced engineer for final analysis and minor modification, a great deal of time and effort could be saved. It would also make model-based reasoning a far more attractive proposition to those who consider the model acquisition phase too “expensive.” Of course, constructing a model from scratch would be a very difficult task; we therefore propose to construct new models from existing models. To do this we exploit ideas from case-based reasoning for design in a system called MACE. The intuition behind the approach adopted in this paper is that many people will refer back to models that they (or colleagues) have constructed in the past and may well perform a manual cut and paste to construct the new model. They will then analyse the patchwork of model fragments to form the new model. The system described in this paper attempts to mimic that process--MACE is a system that (semi-)automatically constructs a new model from existing models. The remainder of this paper is structured in the following manner: Section 2 introduces the concepts behind functional modelling and Section 3 describes case-based reasoning. Section 4 discusses the structure of the case data base used in the MACE system and Section 5 considers the MACE system itself and its constituent parts. Section 6 describes how MACE constructs a new model and Section 7 discusses how MACE: relates to previously published work.

MODEL-BASED REASONING (MBR) has been proposed as a robust technology for building knowledge-based systems (Price & Lee, 1988). These systems rely on a model of a system or artifact as the basis of the reasoning process. These models often use knowledge of the structure of the artifact and how the components of that artifact behave; the operation of the whole artifact is synthesized from this information (Weld & de Kleer, 1990). One type of model is proving to be particularly useful; this type of model represents the functionality of the system explicitly (i.e., what it is for) rather than knowledge of how the system works. These models are termed functional models (Sticklen, 1991; Hunt, 1992). In this paper we have chosen to focus on functional models, rather than structural models. This is due to their inherent ability to hierarchically organize the complexity apparent within complex systems. This has lead them to be successfully applied in applications such as diagnosis (Pegah, Sticklen, & Bond, 1993), design (Goel, 1989), and failure mode effects analysis (Pugh, Hunt, & Price, 1994). However, a major bottleneck for all MBR systems is the construction of the models. This is a time-consuming and error-prone process. It also requires a detailed

Request for reprints should be sent to John Hunt, Department of Computer Studies. University of Wales, Aberystwyth, Dyfed, SY23 3DB. UK. E-mail: [email protected].

347

J. Hunt

348

FIGURE 1. The structure of a functional model with structural augmentations.

2. FUNCTIONAL

MODELLING

Functional modelling provides a way of describing the functionality of a system in terms of the functionality of its subsystems. In the functional modelling system described below (as in other systems) a method for dynamically determining the consequences of a given situation on the operation of the model is available. The functional description used in this paper is that developed at the University of Wales, Aberystwyth, and described in Hunt (1992) and Hunt and Price (1993), called RAPHAEL. A model of a device built using this approach consists of a “core” representation, which represents the “functional” devices in a system. Associated with these devices are “functions,” which express the behaviour of the system when these functions are active. It is also possible to describe the events that can occur. These are external influences on a device such as a switch being set, etc. In the case of the functional models represented using Hunt (1992) and Hunt and Price (1993), it is possible to augment them with structure definitions that describe the electrical circuit associated with a functional device. Figure 1 illustrates the structure of one of these functional models. Figure 1 illustrates the top level of a windscreen wash system. This model possesses two events, “switch on windscreen wash” and “switch off windscreen wash.” It also possesses a function “wash action.” This is the main function of the windscreen wash device. This function also refers to two further functions: “turn on windscreen wash” and “pump water,” which are actually defined in subdevices of the windscreen wash device. Finally, the model also contains a circuit description for the windscreen wash system. Figure 2 illustrates the definition of the wash_action function for the windscreen_wash_system. The language of the functional model allows the definition of functional state variables, the range of values they can take, electrical structures, and the functions themselves. The

functional state variables describe the functional state of the system. This state is determined by synthesizing the whole system state from the results produced by analysing the executable functions. Each variable used to describe the functional state of the system must take some meaningful range of values, for example, true or false. Other value ranges can be defined by the user. For example, on or offmay be more meaningful than true or false when describing the state of a switch. Thus, a new state space, switch-states, can be defined using on and off. As illustrated in Figure 2, a device function is indicated by the dejine_function keyword. A set of preconditions on the function determine when it will execute. A postcondition statement is used to specify the result of the function completing execution successfully. An of statement is used to indicate the device associated with the function that precedes it. If the function is defined within the current object the of and the device name are not required. An electricalStateof statement is used to determine the electrical state of an actual component. During the analysis of a system, if an electricalStateof statement is encountered, then the circuit associated with the specified component is analysed to determine the operation state of the component. The syntax used to describe the circuits is that required by the qualitative circuit analyser of Lee and Ormsby of the University of Wales, Aberystwyth (Lee & Ormsby, 1992). Indeed, in Hunt (1992) and in Pugh et al. (1994) this analyser is used in conjunction with the functional model analyser. [See Figure 7 for examples of the use of the electricalStateOf statement.] 3. CASE-BASED

DESIGN

Case-based reasoning (CBR) is a technology that is proving extremely successful in a wide range of application areas (Kolodner, 1993). A good introductory

349

MACE System for Model Construction

Wtndscreen_wash

detine_function wash-action preconditions [windscreen_wash_switch_state of windscreen_wash= on] turn_on_windscreen_wash if (water-pump-state

of windscreen_wash_circuit -> water-pump-state

= ACI?VE) then

pump-water of hydmuiic_system -> water-pumped if (water-pumped = true) then true -> windscreen_wash_done endif endif postcondition windscreen_wash_done

FIGURE 2. The wash-action function definition.

definition of CBR is that a case-based system is one that “solves new problems by adapting solutions that were used to solve old problems” (Reisbeck & &hank, 1989). This means that in case-based design essentially a store of successful designs, part designs, or design plans is assumed to exist and the design task is now to retrieve existing designs, adupf the design(s) to the current requirements, and to store the new design back into the data base of existing designs. This process continues until a solution is found. The solution can then be saved into the case data base for future use. 3.1. Case-Based

Reasoning

Figure 3 illustrates the basic structure of many CBR systems. The first step in many CBR systems is to analyse the inputs to the system in order to determine the important features to use in selecting past cases from the case data base. These features are then used in the retrieval step along with the initial inputs. The retrieval step uses this information to obtain a list of past cases that match the current situation. From this list the best case can be selected. In many cases it is necessary to adapt this case to match the current situation. Once the case has been adapted, it must be evaluated to determine whether it does provide a solution to the current problem. If the case is accepted, then it is presented as the solution to the problem and stored in the case data base for future use. If some aspect of the current problem is not solved by the case, then the case must be repaired such that it will solve the problem. This is done by first identifying why the case failed to solve the problem (e.g., some constraint on the problem was not met) and then using this information to guide the repair process.

3.2. Case-Based

Reasoning

for Design

The use of CBR techniques for design has been growing during the last few years. CBR has been applied to a number of design applications (Navinchandra, Sycara, & Narasimhan, 1991; Goel, 1989; Goel & Chandrasekaran, 1992; Pu, 1993; Pearce et al., 1992). Hua and Faltings (1993) provide a number of justifications why CBD is desirable, including: A CBD system does not require a complete domain model, but can produce complete and complex designs even with a small knowledge base. However, as Hua and Faltings point out, a great deal of information is still required. Designs start from complete cases, implicitly achieving trade-offs among several functions and avoiding the problem of multicriteria optimization. Using the complete design reduces the complexity and thus can make the problem solving more efficient. Using cases as the source of knowledge allows learning by storing new cases. In addition, the design case acts as the glue that holds the design together. This is important for designs that cannot be easily decomposed.

4. THE MACE CASE DATA BASE As the basis of a CBD system is the case data base, it is important to consider what the cases should represent. As has already been said, a case can be a complete design, a design plan, a partial design, and even undesirable designs. An important issue for CBD is the fact that cases for design tasks tend to be larger than cases in planning or diagnosis; it is therefore often the case that a design

J. Hunt

structures in each case to improve the efficiency of the various search operations. Figure 4 illustrates two cases from the case data base that currently holds 20 cases. These cases represent partial models for the windscreen-wash and petrol_ pump devices. Note that the windscreen-wash case in the case data base does not possess a circuit description nor does it possess any event definitions (unlike that illustrated in Figure 1). This has been done to illustrate MACE’s construction process in Section 6. Each case data base (the system is not tied to a single case data base) is stored as a flat ASCII file, MACE first reads all the cases into internal memory as a list of lists. It then processes each sublist in turn, converting it into an instance of class case. It then adds each instance to a list of all cases. This list of case instances is ordered on the deviceName of the case. This can be useful during some search operations. FIGURE 3. An example CBR system structure.

may be broken down into partial designs, lesson-bearing chunks, or prototype designs. This has an impact on the way in which the designs are retrieved and adapted. For MACE the cases will hold partial models. The partial models represented by each case refer to specific device-function combinations. Although the functions may reference subfunctions, these subfunctions are not maintained within the same case; instead they will form cases in their own right. This also means that although the final models are hierarchical, the cases represent nonhierarchical partial models. Some cases may also contain a structural description of the device. Each case possesses seven attributes: deviceName, functionNames, structureNames, statevariables, functionDefinitions, eventDefinitions, and structureDefinitions. Apart from the device name, each of these is an ordered set. Each actual case is an instance of a case class. This class defines methods that add to, remove from, and search each of the case fields. We have duplicated the names of the functions, events, and

deviceName: functionNames: eventNames: stnxtureNames:

‘windscreen_wash’

wash-action

SYSTEM

STRUCTURE

Figure 4 illustrates the structure of the MACE system. The system is comprised of five main modules that interact, as indicated by the arrows in Figure 5. These are: the retrieval module, the adaptation module, the repair module, the evaluation module, and the update module. The adaptation module and the retrieval module work closely together as it is the retrieval module that retrieves the partial models, which are manipulated by the adaptation module. MACE has been implemented in just over 2500 lines of POP11 code (Barrett, Ramsey & Sloman, 1985) using the Flavours object-oriented language extension in the POPLOG environment. Coordinating the execution of the five main modules is the MACE scheduler. This module processes a goal list, which indicates what subproblems need to be addressed. Depending on the goal, the scheduler selects one of the modules and sends it a message indicating the goal to be performed. In turn, the modules place goals onto the goal list as and when they occur during their

deviceName:

‘petrol_pump’

functionNames:

activate_petrol_pump deactivate_petrol_pump

n

eventNames:

cl windscreen_wash_done

statevariables: functionDefinitions:

5. MACE

[wash-action

eventDefinitions:

u

stxuctureDefinitions:

0

...I

structureNames: SateVariables: funcdonDetinitions:

LJ [I petrol-pumped [activategetrolqump [deactivate_petrol_pump

eventDefiitions:

FIGURE 4. Two example cases.

...I ...

351

MACE System for Model Consrruction

3K

System

Case

Database

FIGURE 5. The

structure of the MACE system.

processing of existing goals. MACE starts its problemsolving process when it places a top level goal on the goal list with the inputs provided by the user. It finishes problem solving when no goals remain on the goal list. As can be seen from Figure 5, there are four knowledge bases. These are: Adaptation procedures. These guide the adaptation process. Generalization/specialization hierarchy. (The GS Hierarchy).’ this represents knowledge about the relationships between various types of components and devices. Domain knowledge base. This represents domainspecific knowledge, such as whether petrol should be filtered or not. Specialized repair plans. These capture domain-specific operations for repairing adaptations or model combinations introduced by the adaptation module.

retrieved based on their device name. The retrieval module can also search through the list of cases currently being modified. These methods mirror those that search the case data base. The matching and ranking system used remains the same whatever the retrieval method selected. That is, we match each case against the current “search” specification and rank them accordingly. This nearest-neighbour function makes extensive use of GS hierarchy. This hierarchy represents the relationships between different types of component/device. For example, the hierarchy represents the fact that a switch is a type of device, that it conducts electricity, and that it changes state. Using the GS hierarchy any type of switch can be abstracted to a device, an electrical conduit, or a state changer, etc. The same is true for functions and for the concepts used for state variables.

5.2. Case Adaptation 5.1. Case Retrieval If designs are maintained in a single case, then case retrieval can concentrate on retrieving the past design that most closely matches the existing situation (see KRITIK in Goel, 1989). However, if designs are divided up amongst a number of cases (as they are in MACE), then the retrieval system must be capable of retrieving partial solutions that are indexed independently. The retrieval module in MACE has a number of retrieval methods available to it; the actual method is selected based upon the information requirements of the adaptation module. The methods available include retrieveByFunction, retrieveByPrecondition, retrieveByComponent, and retrieveByEvent. Note that there is no retrieveByDevice method as at present cases are never

’In fact, the generalization/specialization hierarchy semantic network as there are many links between hierarchy other than “inheritance” links.

is more like a nodes in the

Case adaptation is one of the most difficult tasks in a CBR system. In design systems it is additionally complex as it may first be necessary to “reconstruct” the design from partial designs or design prototypes. In many CBR systems the adaptation process is performed using sets of heuristic rules, although a number of systems employ a coreasoner such as a constraint satisfaction system to handle the adaptation (Hua & Faltings, 1993; Maher & Zhang, 1991; Hinrichs, 1992). For MACE, case adaptation can involve combining partial models together, model parameterization, or model generalization. The adaptation module uses “Adaptation Procedures” that describe how a partial model can be modified. For example, Figure 6, illustrates three adaptation procedures from the 11 that have been defined. The other adaptation procedures include adaptDeviceDefinition, adaptStructureDejinition. adaptStateVariable, adaptEventBody, and adaptstatement. Figure 6 also illustrates an important feature of adaptation

J. Hunt

352

adaptFunctionReferences for function in functionDefinitions do if statement references an unknown function then reuieveByFunction from the case database order retrieved cases select best case

FIGURE 6. Example adaptation procedures.

procedures; they are hierarchical. This means that more complex procedures can be built up from simpler ones. The first adaptation procedure in Figure 6 describes the method for adapting a function to match its new context. This involves first changing all the references to the original device to the current device. This also extends to state variable names. Figure 7 illustrates the result of doing this to the function illustrated in Figure 2. AdaptPreconditions then defines how definitions for unknown state variables (used in precondition statements) may be found. Note the reference to adapting the new state variable definition to match its context. This is actually a trigger to the overall MACE controller to record the need to process this definition. The result of this is that a goal is added to the MACE goal list for future processing. The adaptFunctionReferences adaptation procedure processes a function definition, statement by statement, searching for references to functions that are currently undefined (by undefined we mean “are not defined in any case that has already been obtained”). If this is the case, then the adaptation module is directed to request that the retrieval module retrieve a case for this function. Again, the adaptation module sends a goal to the MACE goal list requesting that the function retrieved is adapted to match its context. In MACE we use the generalization specialization hierachy to identify legal abstractions and replacements in the models. For example, if the model that has been retrieved references the functions associated with a petrol pump and we require a water pump, the hierarchy can be used to perform a set of transformations that will change the model from describing petrol to one describing water (see the next section). This may also involve the domain knowledge base that contains information on domain entities. This information includes knowledge of their corrosive nature, constraints on their use, etc. For example, petrol requires metal pipe work whereas water

can use plastic pipes, etc. Some of this information may not be directly used within the functional model, but is noted as a comment on the model for the engineer’s benefit. It should be noted that MACE’s adaptation procedures often rely on extensive searching of the existing case data base for partial models with appropriate state variable definitions and structure definitions as well as the knowledge contained within its knowledge bases. Other cases are required when a partial model that has already been retrieved references undefined functions, variables, or circuit structures (because it is now out of the context in which it was originally defined). To integrate these definitions into the model being constructed, the generalization specialization hierarchy is again used.

5.3. Case Repair Once the cases have been retrieved or constructed they will often require “repair” to match the new situation. This can be a difficult problem because although techniques such as generalization are powerful design tools, care must be taken not to introduce inadmissable generalizations, etc. If such generalizations are introduced then they will need to be handled by the repair module. The reader is directed to Hua and Faltings (1993), who consider such issues in some depth and propose some solutions. MACE possesses specialized repair plans for situations that are particularly hard to resolve. These include large-scale changes of functionality (such as changing a function describing a four-position switch to a toggle switch) and modifications to state space definitions. The existing repair plans include performDomainRepair, which uses the domain knowledge base to check if any items of information associated with the new concept introduced are missing or are erroneously

353

MACE System for Model Construction present. This repair plan is used by MACE to remove references to “unleaded” and “filtered’ from the activate_water_pump function in the next section. These concepts were in the function definition when it referred to pumping petrol rather than water. 5.4. Case Evaluation We believe that the adaptation stage should act as a human assistant. That is, the adapted model should be presented to the human expert. It is then the human’s responsibility to make the final decision on whether the model meets the specified requirements and if so whether it can be added to the case data base. MACE is therefore acting as an engineer’s assistant and is not intended to replace the engineer. However, an evaluation phase can help the engineer in his task, for example, by analysing the model to ensure that its behaviour meets the engineer’s requirements. This could be done by linking MACE to a functional modelling system and a qualitative circuit simulator. At present this has not been done, but it is a technical rather than a research issue. Currently the evaluation module only presents the model that has been constructed to a user who examines it and makes any necessary changes (this is where the modelling systems could be used). Once the user is happy with the model it can be saved back into the case data base. Note that this may happen at a much later date and may be constrained by organizational restrictions (e.g., only a supervisor may be allowed to update the case data base in an attempt to ensure that only acceptable models are added to the case data base). 5.5. Case Update The update module decomposes a newly constructed model into its constituent parts and saves them as separate cases in the data base. That is, each functional device is saved into the data base as a separate partial model. The assumption used here is that the whole model will be saved elsewhere with the actual modelling system being used. Thus, MACE is only used if no existing model matches the required model. 6. CONSTRUCTING

A NEW MODEL

This section describes how MACE constructs a new functional model using only the information in the partial models in the case data base and the information provided by a user. The actual output produced by MACE during a run, on which this section is based, is presented in Appendix A. The first step is for the user to supply information about his requirements. In Appendix A the user has indicated that he wants a wash function and that it is to be associated with the headlamps device. It is worth noting two points here: firstly, the user does not have to supply an exact specification. Obviously, the

more specific the input the more constrained will be MACE’s task. This will mean that MACE has less flexibility about what it can and cannot do. The second point to note is that very little information is actually required by the MACE system. This is because the partial models retrieved provide further information, which over time extends and constrains the specification of the final model. Therefore, the user of the system is not required to have a detailed knowledge of either the contents of the case data base or of what the final model should look like. 6.1. Retrieving

the First Case

Once the specification has been provided by the user, MACE can direct the retrieval module to find functions (using the retrieveByFunction method) that closely match the overall function wash. Any functions that are retrieved are ranked using the nearest-neighbour formula and the closest match is selected. In Appendix A the case selected is the windscreen_wash case containing the wash_action function, This partial model is then passed to the adaptation module. This module compares the partial model with the initial requirements. If there is a conflict it attempts to invoke an appropriate adaptation procedure. In this case it selects the AdaptDeviceDefinition and then the AdaptFunctionBody procedures. The AdaptDeviceDefinition procedure uses the GS hierarchy to determine how it can change the windscreen-wash definition. The only commonality it can find is that both windscreen_wash and headlamps are devices. It therefore decides that it can exchange them at the device level. Thus, all references to windscreen_ wash are altered to headlamps. Next the wash-action function is analysed by the AdaptFunctionBody procedure. This adaptation procedure immediately calls the adaptFunctionContents procedure. This adaptation procedure finds that the device name now conflicts with some of the terms used in the function body. It therefore replaces all references to windscreen-wash with headlamps. For example, it alters the function turn_on_windscreen_wash of windscreen_wash_circuit to turn-on-headlamps of headlamps-circuit (note that both of these modifications will have implications for the steps performed by MACE in the future). Figure 7 illustrates the current state of the partial model at this point (which is just before the second invocation of the retrieval module in Appendix A). 6.2. Processing

the Preconditions

in Wash-Action

The next adaptation procedure selected is the AdaptPreconditions procedure (illustrated in Figure 6). This procedure searches all the known functions (in this case it finds just the wash-action function) for any unknown preconditions. In wash-action it finds the [headlamps-

354

J. Hunt

define_function wash-action

postcondition water_squirted_at_windscreen

FIGURE 7. The first transformations of a partial model.

switch-state of headlamps = on] precondition. The adaptation module now directs the retrieval module to search for a definition for this switch state. The retrieval module, in turn, searches the case data base for a case that defines a switch state variable for this precondition.* In the example illustrated in Appendix A, MACE finds the steering_column_switches case. This case is a close match in that it defines a number of switch states; however it is not an exact match as it does not define a headlamps-switch-state. The retrieval module therefore passes the case over to the adaptation module for it to process. The adaptation module uses the AdaptStateVariable procedure and the GS hierarchy to modify the steering_ column_switches such that the indicators-switch-state definition is modified to provide a state definition for the headlamps-switch-state. The module then uses the AdaptEvent procedures to modifying the events referring to the indicator-switch-state so that they refer to the headlamps-switch-state. 6.3. Processing

the Functions

Referenced

by

Wash-Action MACE now returns to the processing of the wash-action function. The next adaptation procedure selected is the AdaptFunctionReferences. This procedure processes each of the known functions searching for any undefined functions. In the wash-action function there are two: turn_on_headlamps and pump-water. The adaptation module therefore requests that retrieval module to search by function for cases that provide these functions. The two closest matches are the petrol-pump case and the ’In this situation MACE will search the case data base for devices that define a switch_state. Notice that the search process has generalized the search by looking for a switch state. This is because the GS hierarchy represents concepts associated with switches. This means that there is a greater chance of identifying a potentially interesting (and possibly more useful) device than if the search was limited to a hradlamps_swirch_stare.

windscreen_wash_circuit. The adaptation module processes the petrol-pump case first. As before, it applies the adaptation procedures to water-pump to change its name from petrol-pump using the GS hierarchy. It then applies the AdaptFunctionBody and the procedures it applies. However, the adaptation procedure fails to find a function definition that is close enough to the pump-water function. This means that it cannot adapt a function definition to match this function. The adaptation module therefore stops processing this function. Next the adaptation module processes the turn-on_ windscreen-wash function of the windscreen-washcircuit. This results in the device name changing to wash and the function definition being modified to describe the operation of the turn_on_headlamps function (note the device referenced in association with turn-on-headlamps changed from headlamps-circuit to wash). The remaining steps performed by the adaptation module ensure that all the functions referenced in the wash device are available. For example, the turn-on-headlamps of the wash function references the activate-water-pump and deactivate-water-pump functions of the water-pump device that was retrieved in an attempt to find a function definition for pump-water. The adaptation module therefore applies the AdaptFunctionBody procedure to this case. The result of this process on the activate-petrol-pump function is illustrated in Figure 8.

6.4. Processing

the Activate-Petrol-Pump

Function

The activate-petrol-pump function is slightly complicated as the adaptation procedure must use its domain knowledge to determine whether the references to unleaded and filtered are required. This is done using the performDomainRepair repair plan. The original and final functions are illustrated in Figure 8. MACE first searches its domain knowledge base to identify a common point of reference for water and petrol. In this case it finds that

355

MACE System for Model Construction

preconditions [ignition-switch-state if (elecoicalStateOf@etrolqump)

= on] = ACTMZ

if (unleaded) and (filtered) then true -> petrol-pumped

preconditions [ignition-switch -state= on] if (electicalStateOf(water_pump) = ACTIVE) if tIue and true then true 4 water-pumped

FIGURE8. Function transformations.

they are both fluids. It can now compare and contrast the fluid properties of both water and petrol. It finds that the concept water does not include the need to be unleaded nor does it indicate that it must be clean (hence, there is no need to filter it). This means that MACE can simplify the function definition. The newly defined activate_water_pump function definition possesses a precondition [ignition_switch_ state = on]; the adaptation module therefore applies the AdaptPreconditions procedure. This procedure directs the retrieval module to search for a case defining this state variable. On this occasion, the retrieval module first checks the known cases (i.e., those currently forming part of the model being constructed). In the steering_ column_switches partial model it finds a definition for the ignition_switch_state; therefore, there is no need to search any further. Next, the AdaptFunctionReferences adaptation procedure is considered; however, it is not applied as the function does not reference any other functions.

6.5. Processing a Structure

Definition

As the activate_water_pump function makes reference to the electricalStructureof a component (i.e., the water_ invokes adaptation module the the pump), AdaptStructureReferences procedure. This procedure requests that the retrieval module search the case data base for structure definitions. The retrieval module therefore searches the case data base for cases containing references to pumps (this is a generalization introduced via the GS hierarchy). In Appendix A MACE finds a circuit structure that describes an air-pump. This circuit is essentially correct except that the pump involved is an air-pump. However, if the system examines its GS hierarchy it will find that an air-pump and a water_ pump are both examples of a pump and so it can change the components (note because we are dealing with qualitative models we do not need to concern ourselves with issues relating to current and resistance, etc.). The adaptation module then performs the same set of operations on the deactivate_petrol_pump function definition.

6.6. Repairing

the Models

At this point the adaptation module has completed its task. The five partial models that have been processed are held in a list that is passed onto the repair module. The five partial models are headlamps, steering_column_ switches, wash, water-pump, and water-pump-circuit. The repair module then uses a very simple repair plan to group all these devices together into a new higher-level device that is labeled NewDevicel. The result is the structure illustrated in Figure 9. The NewDevice model has five subdevices and no functions, events, or state variables. Its whole functionality is defined by the functionality of its subdevices. It is left up to the user to give this device a more meaningful name. For example, NewDevice might be relabelled headlamp_wash_systern. Figure 9 also illustrates the events, functions, and state variables now defined by each subdevice. The repair plan used by the repair module is very simplistic. It does not assume anything about the actual relationships between the functions within the constructed model. These relationships are illustrated in Figure 10. This figure shows the hierarchical nature of the model that was constructed. It could be argued that the structure of the devices should match the hierarchical structure of the functions. However, it was felt that a system that generated a complex hierarchical device structure might be more difficult to understand and therefore more difficult for a user to modify. The simple structure generated is clear and allows the user to modify it if he wishes.

6.7. Case Evaluation

and Update

Finally, the NewDevicef model is saved to a file in a plan ASCII format. This file can now be edited by a user in exactly the same way as if the user had written it himself. This is an important point, as the model generated by MACE is expected to be a starting point for the user, rather than a complete solution in its own right. This is indeed illustrated by the dangling reference to the pump_ water function. Although the system successfully found a case that closely matched this function and that provided the activute_water_pump and deactivate-

J. Hunt

356

headlamps

states

Q :nition_switch_state tdicators-switch-state

steering_coh.unn_switches state P”Pntf

wash

watergump

switch_on_ignition switch_off_ignition switch_on_headlamps switch_off_headlamps

states

functions

StZiteS

fimrtinnn

FIGURE 9. The structure of the model constructed.

water-pump functions, it failed to find a function that was close enough to pump-water that it could adapt. It is therefore up to the user to define this function.

7. RELATED

WORK

KRITIKuses a MBR system to guide its adaptation process (Goel, 1989). That is, KRITIK analyses the retrieved case to determine if it can provide the required functionality. The functional model used by KRITIK represents the functionality of a system, the behaviour of

the functions, and the structural elements associated with the behaviours. KRITIK uses this to determine if any part of the case fails to provide the required functionality. If it does, it uses the function’s behaviour to identify the structural faults that could have caused the failure. It then uses heuristic knowledge in the form of modification plans to repair the case. KRITIK differs from the work presented in this paper in two fundamental ways. Firstly, is it attempting to generate a design for an artifact, whereas we are attempting to construct a “executable” functional model.

activate water

FIGURE 10. The hierarchical structure of the function.

357

MACE System for Model Construction Secondly, KRITIK retrieves a single model that is then modified to match the current problem. In contrast, we retrieve partial models that are modified and integrated with other partial models. KRITIK is similar to our system in that a large domain knowledge base is used to determine legal adaptations. Another similarity is that both KRITIK and MACE make use of functional models. However, KRITIK uses modification plans that are associated with the kinds of differences that are between artifacts (e.g., the differences there are between substances held by artifacts etc.). We avoid the need for these specific plans by having generalization specialization hierarchies and the use of partial models. This means that our adaptation procedures are described in generic terms and not hard code knowledge about any system, component, or substance. It is possible that we have been able to do this due to the domain we have been working in, namely automotive electromechanical systems, where as KRITIK has been used to design devices that must be able to hold hazardous substances. Another CBD system that processes models is CADET (Navinchandra et al., 1991). This system specialized in designing hydromechanical systems. The case data base holds a set of previous designs that realize subfunctions of the desired artifact. Three types of synthesis methods are used to generate the descriptions: rule-based, case-based, and search-based. Potential design are evaluated by the evaluation module, which has access to a qualitative simulation system and a constraint checking system. Like KRITIK, it possesses plans for how to repair models; however, it also possesses a large knowledge base of domain laws that it uses to direct the adaptation phase. CADET differs from the work in this paper as it does not attempt to combine partial models together nor does it handle functional models. This is important as the qualitative models it constructs are made up of “qualitative” differential equations at a single level, which describe constraints on the behaviour of an artifact. This means that a constraint satisfaction process is much more applicable than in our case; it also means that the models are less hierarchical (at least at present) and there is therefore less benefit to be accrued from the integration of partial models. However, CADET is able to introduce new system variables and modify the qualitative differential equations using its domain laws. This is very powerful and currently beyond the scope of the work described above.

8. TESTING

AND EVALUATION

The MACE case data base was first seeded with a variety of partial models. These partial models were selected as being representative of the problem domain. The seed cases included the definition of a petrol pump, the top level function of a windscreen wash system, an air pump

circuit description, the list of steering column switches, a wash function, as well as partial models of the central locking system, the ABS system, and the traction control unit. The MACE system, seeded with these cases, was then tested on a number of problems. These included the headlamp wash system described in this paper, an electric window control mechanism, and a cruise system. Unsurprisingly, MACE could construct reasonable solutions to both the headlamps wash system and the window control mechanism. However, an incomplete model of the cruise control system was all that MACE was capable of producing. This was mainly due to the lack of suitable partial models in the case data base. This is not surprising as the cruise control system includes a CPU that possesses a memory function, as well as a complex control/feedback loop. However, what MACE did do was to bring together those elements of existing partial models that were relevant/useful to the engineer. This meant that rather than starting from a blank piece of paper, the engineer could have information about the steering column switches, etc., that were available. Another test that was carried out was to seed MACE with the required solution (in the form of a set of partial models added to the existing case data base) and see if it was capable of reconstructing that model. Interestingly, although MACE retrieved most of the elements of the desired model in some situations, it obtained an alternative partial model. On examination it was revealed that the partial model retrieved was functionally the same as the actual partial model (although with different variable names, etc.) and that this selected partial model had been found first in the case data base.

9. DISCUSSION MACE has the potential to be a very useful and powerful tool; however, it possesses a number of important limitations. Firstly, a lot of how MACE performs its adaptation relies on string pattern matching and string manipulation. At present, this part of the system is not very sophisticated. For example, given a system called windscreen_wash, which is being modified to headlamps-wash, it will successfully change the state variable windscreen_wash_done to headlamps_wash_ done. However, at present it would fail on changing washed-windscreen to washed_headlamps. MACE also relies on the quality of the extensive domain knowledge (in the form of the GS hierarchy and the domain knowledge base). Thus, like a number of other design-oriented CBR systems, it requires a large amount of knowledge before it can be generally useful. This knowledge may not be trivial to obtain and represent. Of course, MACE also relies on the presence in the case data base of appropriate partial models. When no such model is available, MACE cannot provide further

358

J. Hunt

support-it relies on the human user to provide any unresolved functions, etc. This is possible in the simple headlamps model; however it may be significantly harder with larger models and will probably relate to the users’ knowledge and experience with both the modelling approach and the output produced by MACE.

10.FUTURE

WORK

There are a number of areas of future work planned. The first, and most obvious extension, is to interface MACE with a modelling system that can animate the models generated. This would help not only the engineer in determining whether the constructed model meets their requirements, but also in ascertaining which parts of the model are undefined. The RAPHAEL modelling system (Hunt, 1992; Hunt & Price, 1993) is the most obvious choice. This is because both MACE and RAPHAEL are implemented in POP11 within the POPLOG environment and can thus be easily and simply linked together and because the models generated by MACE are similar to those processed by RAPHAEL. At present the ASCII file produced by MACE does not include many of the RAPHAEL syntax words. However, this is a technical rather than research issue. Another future extension that would be very useful to an engineer would be to make the models produced by MACE displayable by GRAF (Graphical RAPHAEL) (Pugh et al., 1994). GRAF is a front-end to RAPHAEL which graphically displays functional models. However, GRAF has led to some modifications in the way in which the models are defined that are not currently compatible with MACE and the version of RAPHAEL used to develop MACE. A more significant problem is that GRAF can only display models that have been developed using GRAF. This is because it holds the models in its own representation, which includes graphical layout information. This internal model is then translated into a RAPHAEL model for simulation purposes. Another extension that is being considered will result in the extension of the library of repair plans. This requires further experience with MACE and a variety of applications to determine which repair plans are required. We are also considering what direction to take with the GS hierarchy. It has proved satisfactory for the range of problems we have considered to date. However, as we have extended the GS hierarchy it has become more difficult to maintain and keep consistent. One possibility is to abandon the use of the GS hierarchy all together and use some form of knowledge based system or intelligent data base system. Finally, we are considering issues associated with the actual use that could be made of MACE by engineers. One of the issues that engineers have reasied is that inexperienced personnel should not be allowed to update the cases in the case data base. This implies different levels of authority for different tasks. Another issue that

engineers have highlighted is the current user interface which must be improved if MACE is to be used by the average engineer. The improved interface could provide a variety of functions including a case data base browse mode, a select (an existing partial model) mode, as well as the existing model construction mode. The first two modes could be as useful to an engineer as the construction of a new model. This is because MACE will develop over time to become a repository of knowledge about the types of system that the engineer works with.

11.CONCLUSIONS This paper illustrates that an approach such as that used in MACE can be extremely useful in the deployment of practical model-based reasoning systems. Many organisations are prevented from considering the application of MBR due to the heavy investment required in model construction. MACE provides a practical way to reuse existing models as well as providing the intitial adaptation and reconstruction of a potentially useful model.

REFERENCES Barren, R., Ramsey, A.. & Sloman, A. (1985). POPlI:

A practical language for artificial intelligence, Chichester: Ellis Horwood. Gael, A. (1989). Integration of case-based reasoning and model-based reasoning for adaptive design problem solving, Ph.D. Department of Computer and Information Science, The Ohio State University. Gael, A., & Chandrasekaran, B. (1992). Case-based design: A task analysis. em AI approaches to engineering design, Vol2: Innovative design, C. Tong and D. Sriram (Eds.). New York: Academic Press. Hinrichs, T. R. (1992). Problem solving in open worlds: A case study in design. Northvale, NJ: Erlbaum. Hua, K., & Faltings, B. (1993). Exploring case-based building design-CADRE, AI-EDAM, 7(2) 135-143. Hunt, J. E. (1992). Integrating multiple domain models using a functional representation. Applications of artificial intelligence in engineering VII, Proceedings of the 7th International Conference in Engineering, pp. 1185-1208. Hunt, .I. E., & Price, C. J. (1993). Integrating functional models and structural domain models for diagnostic applications, In J-M. David, J-P. Krivine, & R. Simmon (Eds.), Second generation expert systems (pp. 135-164), New York: Springer. Kolodner, J. L. (1993). Case-based reasoning, San Mateo, CA: Morgan Kaufmann. Lee, M. H., & Ormsby, A. R. T. (1992). A Qualitative Circuit Simulator. Proceedings Second Annual Conference on Al Simulation and Planning in High Autonomy Systems; “Integrating Qualitative and Quantitative Knowledge for Complex Systems and Simulation Models,” IEEE Computer Society Press, pp. 248-252. Maher, M. L., & Zhang, D. M. (1991). CADSYN: Using case and decomposition knowledge for design synthesis. In J. S. Gero (Ed.), AI in Design 1991, Oxford: Butterworth-Heineman. Navinchandra, D., Sycara, K. P., & Narasimhan, S. (1991). A transformational approach to case-based synthesis. ALEDAM. S(1). 31-45. Pearce, M., Gael, A., Kolodner. J., Zimring, C., Sentosa, L., & Billington, R. (1992). Case-based design support: A case study in architectural design. IEEE Expert, 7(5), 14-20. Pegah, M., Sticklen, J., & Bond, W. (1993). Functional representation and reasoning about the F/A- I8 aircraft fuel system. IEEE Expert, S(2), 65-7 1. Price, C. J., & Lee, M. H. (1988). Applications of deep knowledge.

MACE

System

359

for Model Construction

Artijicial Intelligence in Engineering, 3( 1). Pu, F’.(Guest Editor). (1993). Special issue on case-based reasoning in

Adaptation

design. AI-EDAM. 7(2). Pugh, D. R., Hunt, J. E. & Price, C. J. (1994). Augmenting Raphael with hehaviour charts (Tech. Rep.). Centre for Intelligent Systems, University of Wales, Aberystwyth, Dyfed, SY23 3DB, United Kingdom. Presented at the AAAI’94 Workshop on Representing and Reasoning with Device Function. Riesbeck, C. K., & Schank. R. C. (1989). Inside case-hosed reasoning. Hillsdale, NJ: Lawrence Erlbaum Associates. Sticklen, J. (Guest Editor) (1991). Functional reasoning: Organizing complexity. Special Issue IEEE Expert, (6)2. Weld, D. S., & de Kleer, J. (Eds). (1990). Readings in qualitative reasoning about physical systems. San Mateo, CA: Morgan Kaufmann.

Selecting AdaptDeviceDefinition Adapting steering_column_switches Selecting AdaptStateVariables changing indicators,_switch_state range switch-states default off to headlamps-switch-state range switch-states default off Selecting AdaptEventBody Selecting AdaptEventContents Adapting events referenced by state variable adapting: [switch__on_indicators on- > indicators_ switch-state] to: [switch_on_headlamps on- > headlamps-switchstate] adapting: [switch_off_indicators off- > headlamps_ switch-state] Selecting AdaptFunctionReferences Processing [pump-water tum_on_headlamps]

APPENDIX A: AN EXAMPLE

OUTPUT

Please specify any main functions you require (return to end) : > wash Please specify any known functional device (return to end) : > headlamps :>

Module

Retrieval Module Selecting retrieveByFunction The cases retrieved by function from the database are: petrol-pump windscreen_wash_circuit

Retrieval Module Selecting retrieveByFunction The cases retrieved by function from the data base are: windscreen-wash windscreen_wash_circuit Selecting windscreen-wash as the closest match

Adaptation

Module

Selecting AdaptDeviceDefinition Adapting windscreen-wash to headlamps Selecting AdaptFunctionBody Processing functions for headlamps Selecting AdaptFunctionContents Adapting the wash-action function changing preconditions [windscreen_wash_switch_state of windscreen-wash = on] to preconditions [headlamps-switch-state of headlamps = on] changing tum_on_windscreen_wash of windscreen_ wash-circuit> water-pump-state to tum_on_headlamps of headlamps-circuit> water_ pump-state changing true- > windscreen-wash-done to true- > headlamps-done changing postcondition windscreen_wash_done to postcondition headlamps-done Selecting AdaptPreconditons Processing preconditions for headlamps processing condition preconditions [headlamps-switchstate of headlamps = on]

Adaptation

Module

For function pump-water Selecting AdaptDeviceDefinition Adapting petrol-pump to water-pump Selecting AdaptFunctionBody Processing functions for water-pump Failed to find a funcrion to adapt for pump-water

Adaptation

Module

Selecting AdaptDeviceDefinition Adapting windscreen_wash_system to wash Adapting tum_on_windscreen_wash to turn-on_ headlamps Selecting AdaptFunctionBody Selecting AdaptFunctionReferences Processing [activate-water-pump deactivate_water_pump]

Retrieval Module Selecting retrieveByFunction The known cases selected by function are: water-pump

Adaptation

module

Processing functions for water-pump Selecting AdaptFunctionContents Adapting the activate_petrol_pump function changing if (electricalStateOf(petrol_pump) = ACTIVE) then to if (electricalStateOf(water_pump) = ACTIVE) then

Retrieval Module

Calling Repair Module

Selecting retrieveByCondition The cases retrieved by condition from the data base are: steering_column_switches

Selecting performDomainRepair changing if (unleaded = true) and (filtered = true) then to if true and true then

J. Hunt

360

Returning

states [[ignition_switch_state

to Adaption Module

changing true- > petrol-pumped to true - > water-pumped changing deactivate-petrol-pump changing if (electricalStateOf(petrol_pump) = INACTIVE) then to if (electricalStateOf(water_pump) = INACTIVE) then changing false- > petrol-pumped to false- > water-pumped Selecting AdaptPreconditions Processing preconditions for water-pump processing condition preconditions [ignition-switchstate = on]

Retrieval

Module

Selecting retrieveByCondition The known cases selected by condition: steering_column_ switches

Adaptation

Module

Selecting AdaptStructureReferences Processing structure definition for water-pump

Retrieval

Module

Selecting retrieveByComponent The cases retrieved by component

Adaptation

are: air-pump-circuit

Repair Module Selecting performDeviceRepair creating NewDevice for subdevices

B: THE CONSTRUCTED

MODEL

device NewDevice sub&vices [headlamps steering_column_switch water_ pump wash water_pump_circuit] device headlamps states [[headlamps-donerange Boolean default false]]

functions[ [define-function wash-action preconditions [headlamps_switch_state of headlamps = on] tum_on_headlamps of wash- > water-pump-state if (water-pump-state = ACTIVE) then pump-water of water-pump> water-pumped if (water-pumped = true) then true- > headlamps-done endif endif postcondition headlamps_done]] device steering_column_switches

range switch-states range switch-states

default default

offl events

[

[define-events switch_on_ignitionon- > ignition_ switch-state] [define-events switch_off_ignition; off- > ignition_ switch-state] [define-event switch_on_headlamps; on- > headlamps_ switch-state] [define-event switch_off_headlamps; off- > headlamps_switch_state]] device wash states [[water-pump-state range system-states default INACTIVE]] functions

[

[define-function tum_on_headlamps if (headlamps_switch_state of steering_column_ switches = ON) then activate-water-pump of water-pump> water_ pump-state elseif ((headlamps_switch_state of steering_ column_switches = off) then deactivate-water-pump of water_ pump- > water-pump-state endif postcondition water_pump_state]] device water-pump states [[water-pumped range Boolean default false]] functions

Module

Selecting AdaptDeviceDefinition changing air-pump-circuit to water-pump-circuit Selecting AdaptStructureReferences changing all structure references to air-pump to be water-pump

APPENDIX

offl [headlamps_switch_state

[

[define-function activate-water-pump preconditions [ignition_switch_state = on] if (electricalStateOf(water_pump) = ACTIVE) then if true and true then true- > water-pumped endif endif] [define-function deactivate-water-pump preconditions [ignition_switch_state = on] if (electricalStateOf(water_pump) = INACTIVE) then false- > water-pumped endif]] device water-pump-circuit structures

[[

[chassis :name ground] [battery :name positive_ terminal] [wire :name wire11 [wire :name wire21 [fuse :name fuse] [switch :name switch :state closed] [wire :name wire31 [wire :name wire41 [resistor :name cpu :resistance load] [wire :name wire51 [connector :name relay] [wire :name wire61 [resistor :name water-pump :resistance load] [wire :name wire71 [arc wire1 ground] [arc positive-terminal wire21 [arc wire3 switch] [arc wire2 switch] [arc wire3 fuse] [arc cpu wire51 [arc fuse wire41 [arc wire1 CPU] [arc wire4 relay] [arc wire5 relay] [arc relay wire61 [arc wire6 water-pump] [arc water_ pump wire71 [arc wire7 ground]]]