A Model-Based Approach to Blame-Assignment in Design Eleni Stroulia,Murali Shankar, Ashok K. Goel, College of Computing Georgia Institute of Technology Atlanta, GA 30332-0280
[email protected],
[email protected]
and Louise Penberthy Intelligent Systems Group Human Interface Technology Center NCR Corporation 500 Tech Parkway, NW Atlanta, GA 30313, USA
Abstract We analyze the blame-assignment task in the context of experience-based design and redesign of physical devices. We identify three types of blame-assignment tasks that differ in the types of information they take as input: the design does not achieve a desired behavior of the device, the design results in an undesirable behavior, a specific structural element in the design misbehaves. We then describe a modelbased approach for solving the blame-assignment task. This approach uses structure-behavior-function models that capture a designer’s comprehension of the way a device works in terms of causal explanations of how its structure results in its behaviors. We also address the issue of indexing the models in memory. We discuss how the three types of blame-assignment tasks require different types of indices for accessing the models. Finally we describe the KRITIK2 system that implements and evaluates this model-based approach to blame assignment.
1 Introduction Design is a very common and wide-ranging information-processing task. The general design task takes as input the specification of a set of constraints on the design of an artifact. It has the goal of giving as output the specification of a structure for the artifact that satisfies the given constraints. In this paper we are primarily concerned with conceptual (or preliminary) design of physical devices. A typical design task in the domain of physical devices is to design a device that achieves a given set of behaviors. The conceptual phase of this design task takes as input a specification of the behavioral and structural constraints on a device, and has the goal of giving as output a high-level specification of a structure for the device that can deliver the desired behaviors. Blame (or credit) assignment is a major subtask of the design task. The blame-assignment task occurs, for example, in redesign. Given a device that fails to achieve some desired function, the blame-assignment In the Proceedings of the Second International Conference on AI in Design, J.S. Gero (editor), Pittsburgh, June 22-25, AID’92, pp. 519-537, Kluwer, Dordrecht.
1
subtask of redesign is to identify the structural faults responsible for the device failure. The blame-assignment task also occurs in experience-based (or case-based) design. In experience-based design, new design problems are solved by adapting the solutions to old ones. Modification of the structure of existing designs to meet a new behavioral specification is thus a critical task in experience-based design. Identification of the structural “fault” responsible for the “failure” of the old design to deliver the new behaviors is another instance of blame assignment in design. This paper has three main goals. First, we analyze the blame-assignment task in the context of experiencebased design (and redesign) of physical devices. We identify three types of blame-assignment tasks that differ in the types of information they take as input: the design does not achieve a desired behavior of the device, the design results in an undesirable behavior, or a specific structural element in the design misbehaves. Second, we describe a model-based approach for solving the blame-assignment task. This approach uses structurebehavior-function (SBF) models of physical devices. The models capture a designer’s comprehension of the way devices work in terms of a causal explanation of how their designs result in their behaviors. The models are based on a component-substance-field (CSF) ontology and represented in a behavioral representation language (BRL). This language provides a vocabulary for capturing the causal processes underlying the functioning of devices, including cyclic causal processes and interactions between multiple causal processes. Third, we address the issue of indexing knowledge of causal processes in memory. We discuss how the three types of the blame-assignment task require different types of indices for accessing knowledge of the causal processes. The KRITIK2 system implements and evaluates this model-based approach to blame assignment. In addition to retrieving SBF models and using them for blame assignment, KRITIK2 also repairs designs and revises models. A discussion of design repair and model revision is beyond the scope of this paper and we will not discuss it any further (see Goel 1991a for design repair and Goel 1991b for model revision). Instead, we focus on showing how KRITIK2 validates the model-based approach for two of the three types of blameassignment tasks in three different domains: electrical circuits, heat exchangers, and angular momentum controllers.
2 Types of Blame Assignment Blame assignment is a classical problem in artificial intelligence (Minsky 1963; Samuel 1967). Given a system (e.g., a plan, a program, a problem solver) that fails to deliver the behaviors desired of it, the general blame-assignment task takes as input a specification of the structure of the system, the desired behaviors of the system, and the behaviors delivered by the system. It gives as output a specification of the structural faults responsible for the failure of the system to deliver the desired behaviors. Blame assignment is a very common subtask of the design task. To see how blame assignment occurs in design, suppose that a user supplies a design specification such as: “Design an electrical circuit for a special kind of flashlight that produces light of intensity X , uses batteries of type Y , and does not produce more than Z amount of heat”. 1 Note that the above design specification contains (i) the function desired of the design, viz. “produces light of intensity X ”, (ii) a structural constraint on the design, viz. “use batteries of type Y ”, and (iii) a behavioral constraint on the design, viz. “does not produce more than Z amount of heat”. Now suppose that the designer retrieves from her memory a previously designed circuit that satisfies similar constraints and attempts to adapt the old design to satisfy the new constraints. To decide on modifications 1
In this paper we distinguish between several different types of behaviors of a system. First, we distinguish between two types of behaviors of a system: (i) output behaviors and (ii) the internal causal behaviors that result in the output behaviors. Next, we make a distinction between two types of output behaviors: intended output behaviors, which we call functions, and unintended output behaviors that may arise as side effects. Finally, we make a distinction between two types of unintended output behaviors: undesirable output behaviors and unintended output behaviors about which neither the designer nor the user cares. The blame-assignment task refers to the output behaviors of a system, which include its functions.
2
to the old design, she would need to identify the causes for the old design’s “failure” to satisfy the new constraints. This is an instance of the blame-assignment task. To take the example one step further, suppose that the designer generates an electrical circuit for the new flashlight but an evaluation of the design shows that the bulb in the circuit dies when the switch is pressed. Note that this specification of the design failure refers to a specific structural component “the bulb”. Again, to decide on modifications to the circuit design, she would need to identify the causes for the design’s failure. This too is an instance of the blame-assignment task. We have identified three different blame-assignment tasks that occur in design of physical devices. The three tasks differ in the type of information they take as input: (i) the design does not achieve a desired function of the device, for instance, the retrieved design in the above example may not deliver the function of producing “light of intensity X ”; (ii) the design results in an undesirable behavior, for example, the retrieved design may produce “more than Z amount of heat”; and (iii) a specific structural component in the design misbehaves, for example, the bulb in the circuit dies when the switch is pressed. While the three blameassignment tasks differ in the type of information they take as input, the information they give as output is the same, viz. the structural causes for the design failure. In the first case, the retrieved design may not deliver the function of producing “light of intensity X ” because the battery in the circuit supplies too high an electrical voltage. In the second case; the design may result in the undesirable behavior of producing “more than Z amount of heat”, again because the battery supplies too high an electrical voltage. In the third case, the structural component (bulb) in the design may misbehave (die when the switch is pressed) yet again because the battery supplies too high an electrical voltage. As we discuss below, solving these different types of blame-assignment tasks calls for different types of knowledge.
3 Model-Based Blame-Assignment In principle, a number of methods such as associative reasoning, case-based reasoning and model-based reasoning, are potentially applicable to the blame-assignment task. The choice of a particular method, in general may depend on factors such as the nature of the task (what type of blame-assignment task is it), the nature of the domain (what types of knowledge are available in it), the properties of the method (what types of knowledge and computational resources it requires) and the properties of the desired solution (what measures of correctness and optimality it should satisfies) (Goel and Chandrasekaran 1990). In the KRITIK project we are investigating the use of qualitative structure-behavior-function (SBF) models for solving blame-assignment tasks in the domain of physical devices.2 The content of these models is design-specific (though the underlying ontology and language are design-independent). The SBF model of a device captures a designer’s comprehension of the causal behaviors that explain how the structure of the device produces its output behaviors (including its functions) (Goel 1991a). The hypothesis underlying the use of SBF models is that they are sufficient for solving blame-assignment tasks. The rationale for their use is that SBF models of physical devices are readily available and that model-based reasoning is a robust mechanism. Other methods, such as associative reasoning and case-based reasoning, while applicable, use highly situation-specific knowledge; model-based reasoning makes use of more general knowledge. The SBF model of a design captures only the “declarative” part of the knowledge needed for blame assignment. In addition to these models, KRITIK2 uses abstract plans that capture the “procedural” portion of its blame-assignment knowledge. A blame-assignment plan specifies a specialized search procedure in the form of a sequence of abstract operations (Goel 1991a). When instantiated in the context of a design failure, it searches the SBF model of the design to locate the structural causes of the design failure. These abstract blame-assignment plans are design-independent. 2
“Kritik” is a Sanskrit word that roughly translates to “the designer”.
3
3.1 Accessing Blame-Assignment Knowledge The next issue is how to organize the SBF model of a design, i.e., how to index the causal behaviors that explain how the design structure produces the output behaviors of the design. The other half of this issue is how to organize the plan memory, i.e., how to index the abstract plans that search the SBF models. These issues are important because both the success and the efficiency of the model-based approach to blame-assignment depends on its ability to access the right causal behavior in the SBF model to search and the right plan with which to search the model. KRITIK2 uses multiple indices into the causal behaviors: desired functions, undesirable output behaviors, and structural components. The rationale for using these indices is that they directly correspond to the three types of blame-assignment tasks we described in the previous section: the design does not achieve a desired function of the device; the design results in an undesirable behavior; and a structural component in the design misbehaves. The advantage of this indexing scheme is that it provides rapid access to the causal behavior(s) in the SBF model that is useful for solving a given blame-assignment task. The high-level organization of abstract plans in KRITIK2 is task-specific. That is, the plans are indexed by the type of blame-assignment task to which they are applicable. For example, the plans for searching the SBF model when the design does not achieve a desired function of the device are indexed by the types of functional differences between the desired and the delivered functions (Goel 1991a). The rationale and advantage of this indexing scheme is that it provides rapid access to the abstract plan that is useful for solving a given blame-assignment task.
4 Structure-Behavior-Function Models KRITIK2’s SBF models are based on a component-substance-field ontology. In this section we limit the discussion to components and substances. We discuss fields in a later section. In KRITIK2, each device is described in terms of its function, its structure and its internal causal behaviors that allow its structure to achieve its function. The schema used for the representation of a design is shown in Figure 1(a). Structure KRITIK2 views a physical device as composed of a set of components and substances. The components are connected to one another and the substances flow through the components. Knowledge of the structural components of the device is organized in a structure-substructure hierarchy. Each device can be viewed as a set of connected components, and each component can be viewed as a device that can be further decomposed in terms of its components. The structure schema is shown in Figure 1(b). Function The function of a device is also represented as a schema. In this paper we focus on device functions that can be viewed as transformations from the input state to the output state of the device. The slots and the types of fillers in the schema shown in Figure 1(c). 3 The given state specifies the input state of the device; the makes state specifies the output state of the device. The stimulus slot specifies the interaction of the device with its external environment. The representation of a function of a device also specifies knowledge of the internal causal behavior of the device that results in the function. In Figure 1(c), the causal behavior is specified by the by-behavior slot. Thus, the function schema contains knowledge of both a function and knowledge of the index to the causal behavior that results in the function. The provided slot specifies the conditions under which the behavior achieves the function. Causal Behavior As substances flow through the device components, their properties may change and also the mode of operation of the components may change. The sequence of these substance state and component state 3
In Figure 1, the slots enclosed in
fg are optional and those that are followed by a * can exist zero or more times in the schema 4
design : (function : functional specification causal-model : set of internal causal behaviors structure : partonomic hierarchy of device components history : acquisition history) 1(a) Design Schema structure : (is-a-part-of : structural-part consists-of : set of structural parts affects-transitions : set of transitions where it plays a role affected-by-transitions : set of transitions by which it is affected ) 1(b) Structure Schema functional specification : (makes: final behavioral state given: initial behavioral state by: causal behavioral-state sequence stimulus: input from the external environment provided: secondary function )*
f
g
f
g
1(c) Functional Specification Schema behavioral state : (previous: previous state next: next state enabled-by: preceding state-transition enabling: succeeding state-transition substance-schema: substance description at current state : location (property value)* contained substances description )
f
g
1(d) Behavioral State Schema state-transition : (previous: preceding state next: succeeding state using-function: component’s primitive function in mode structural-relation qualitative-relation * enabling-condition *)
f f f
g g g
1(e) State Transition Schema
Figure 1: Structure-Behavior-Function model changes constitute causal behaviors. Knowledge of causal behaviors is represented as directed acyclic graphs (DAGS). The nodes in this graph represent the behavioral states and the edges represent state transitions. The states (i.e., the nodes) and the state-transitions (i.e., the edges) are themselves represented as schemas. Behavioral State A behavioral state is represented in the form of either a substance schema, a component schema, or a field schema. The substance-schema specifies the location, property, and values of properties of a substance. Substances can be either substances such as water and Nitric Acid or abstract substances such as heat or electricity. A substance in a particular device may also contain other substances, which are also described in the substance-schema shown in Figure 1(d). State Transition A state transition is also represented as a schema. The slots point to both the preceding and succeeding states of the transition. A transition may be caused by primitive types of behavioral interactions between substances and components such as allow and pump (Goel 1991). The slot using-function is a pointer to the specific function of a specific element in the device structure. A state transition may also be annotated by the enabling conditions under which the behavioral interactions result in the transition. One type of enabling condition, denoted by under-condition-transition, may act as an index to another behavior. The
5
state-transition schema is described in Figure 1(e).
5 Blame Assignment in Experienced-Based Design In experienced-based design, given a new problem specification, the design with the closest function to the new desired function Fnew is retrieved from the design memory. The structure of the retrieved design Sold is adapted to transform the function it delivers from Fold to Fnew . Once a new structure Snew is produced, it is tested. If it delivers the desired function, it is stored in the design memory for further reuse. Often, the testing reveals undesirable behaviors. In these cases, redesign is needed.
5.1 Blame Assignment in Design Adaptation The specific task of blame assignment that we address in this section takes as input the specifications of the function Fnew desired of the design and the function Fold delivered by the design, where the desired function Fnew is similar to but different from the delivered Fold . It has the goal of giving as output a specification of the structural element(s) in Sold which is(are) responsible for the failure of the structure Sold to deliver the desired function Fnew . 4 For blame-assignment tasks of this type, KRITIK2 uses the function Fold as an index to the causal behaviors that result in it. An Example : The design of a Nitric Acid cooler Let us consider as an example the task of designing a Nitric Acid cooler (NACnew ) to reduce the temperature of some quantity of Nitric Acid from some initial temperature T 1 to some final temperature T 2new Let us also suppose that the design-retrieval task returns the structure of the design of a Nitric Acid cooler (NACold ) which reduces the temperature of the same quantity of Nitric Acid from temperature T 1 to temperature T 2old , where T 1 ? T 2new >> T 1 ? T 2old . Clearly, the desired function of cooling Nitric Acid from T 1 to T 2new is similar to but different from the delivered function of cooling Nitric Acid from T 1 to T 2old . Informally, the functioning of this device can be described as follows: Hot Nitric Acid is pumped in the device by a pump. Then it flows through a pipe into a heat-exchange chamber. There it goes through another pipe which is enclosed in a container of cold Water. Heat is exchanged between hot Nitric Acid and cold Water, as a result of which the temperature of out-flowing Nitric Acid is lower than that of in-flowing Nitric Acid; the temperature of cold Water increases correspondingly. The cold Water is pumped into the heat-exchange chamber by a water-pump. The temperature of the out-flowing Nitric Acid depends on (i) the temperature of the in-flowing Nitric Acid, (ii) the temperature of the in-flowing Water and (iii) the flow rate of Nitric Acid and the flow rate of Water. The functional specification of the old Nitric Acid cooler is shown in Figure 2(a). The internal causal behavior that achieves the cooling of Nitric Acid is shown in Figure 2(b). For this example, the task of blame assignment takes as input the specification of the structure of NACold , the specifications of the desired function of cooling Nitric Acid from T 1 to T 2new and the delivered function of cooling Nitric Acid from T 1 to T 2old It has the goal of giving as output that structural element Sold that is responsible for the failure of the structure of NACold to cool Nitric Acid from T 1 to T 2new . KRITIK2’s model-based method in this example works as follows: The function Fold of NACold is used as an index to retrieve the causal behavior CoolNitricAcid shown in Figure 2(b). Since the value of the Nitric Acid temperature T 2 needs to be changed, KRITIK2 traces the behavior CoolNitricAcid which explains the Nitric Acid flow through the device, from state4 and backwards. The Nitric Acid temperature is the same in both state4 and state3 but changes in state2. The transition transition2 3 : state2 ! state3 explains the temperature change. The initial Nitric Acid temperature T 1, the quantity of heat exchanged between Nitric Acid and Water Q2 ? Q1, and the Nitric Acid flow rate R, are added to the set of optional changes, since 4
The term “structural element” of a structure of a device entails both the components and the substances constituting the structure of the device.
6
GIVEN: loc:p1 state1
MAKES: loc:p4 state4
prop:temperature
param:T1
J prop:flow param:R JJ sub:heat prop:magnitude prop:temperature param:T2
sub:HNO
JJ prop:flow param:R J sub:heat prop:magnitude sub:HNO3
param:Q1
3
param:Q2
BY-BEHAVIOR : CoolNitricAcid 2(a) Functional Specification of NACold state1 transition1-2
?
state2
loc:p2
prop:temperature param:T1
sub:HNO
JJ prop:flow param:R J sub:heat prop:magnitude 3
param:Q1
USING FUNCTION allow HNO3 of Heat-Exch USING FUNCTION allow heat of Heat-Exch STRUCTURAL RELATION containment of pipe in Heat-Exch UNDER-CONDITION-TRANSITION transition6-7 of Behavior HeatWater transition2-3 QUALITATIVE RELATIONS HNO3 .Temperature.T2 = f(+ HNO3 .Temperature.T1), HNO3 .Temperature.T2 = f(+Heat.Magnitude.(Q2-Q1)), Heat.Magnitude.(Q2-Q1) = f(- HNO3 .Flow-Rate.R), Heat.Magnitude.(Q2-Q1) = f(+ H2 O.Flow-Rate.R)
?state3 loc:p3 ?transition3-4 state4
sub:HNO3
J
prop:temperature
prop:flow
JJ sub:heat
param:T2
param:R
prop:magnitude
param:Q2
2(b) Behavior CoolNitricAcid of NACold
Figure 2: The NACold design they affect the final temperature T 2. Also, because transition2 3 points to transition6 7 of the behavior HeatWater, as necessary for transition2 3 to occur, KRITIK2 also traces behavior HeatWater, from state7 and backwards. The algorithm is described in more detail in Figure 3. The computational advantages of the algorithm arise from three sources. First, since Fold is used as an index into Bold the algorithm quickly localizes the start of search in Bold . Second, it traces only parts of Bold and the behaviors it indexes because the cros-indexing among internal behaviors allows it to focus the search.
5.2 Blame Assignment in Redesign The specific task of blame assignment that we address in this section takes as input (i) the specification of the undesirable behavior Bundesirable that the design exhibits, and (ii) the structural element in which the undesirable behavior is observed. It has the goal of giving as output a specification of that structural element of Snew which is responsible for the side-effect Bundesirable. For blame-assignment tasks of this type KRITIK2 uses structural elements of the device as indices into the causal behaviors in which the elements play a role. An Example : The Hubble Space Telescope
7
BLAMETRACE( Fold , Fnew )
Fnew ? Fold = ( Initial Statenew ? Initial Stateold; Final Statenew ? Final Stateold) old ; P new ), where Smust?change = f(Pi ; Pi:value i:value Pi is the property whose value needs to be changed, new is its value in the desired design Pi:value old is the value in the current design Pi:value old 6= P new , such that Pi:value i:value Bold = function-by-behavior(Fold ) Smust?change = BACKTRACE (behavior-final-state(Bold ), Smust?change )
BACKTRACE (state, Smust?change ) current-state = state LOOP previous-state = state-previous-state (current-state); IF previous-state = NIL, THEN Exit LOOP CASE : (0) IF for every Pi inSoptional?change old in current-state = P old in previous-state Pi:value i:value THEN NIL (1) IF there is a qualitative equation in state-previous-transition(current-state), and property Pi inSmust?change such that Piold = f (c) , where c a component parameter, param, or another substance property, Pl THEN Smust?change =
old ; P new )g Smust?change [ f(Pl ; Pl:value l:value new new ), or where Pl:value = finv (Pi:value Smust?change [ fparamg
(2) IF there is a pointer to a new behavior sequence B’ such that a the transition state-previous-transition(current-state) depends on a transition trans of B’ THEN spawn BACKTRACE (transition-next-state(trans), Smust?change ) END-CASE current-state = previous-state goto LOOP END-LOOP
Figure 3: Algorithm 1 In order to make the present discussion more concrete, let us consider the specific problem of redesigning the reaction wheel assembly (RWA) aboard the Hubble Space Telescope (Keller, Manago, Nayak and Rua 1988). The desired function of RWA is to make the telescope point at a chosen area of the sky. The structure of the RWA consists of a rapidly spinning rotor mounted on a shaft. The rotating shaft is connected to a stator at both ends via assemblies of anti-friction ball bearings. The power that drives the rotor comes from a motor that is remotely controlled from earth. The stator itself is mounted on the walls of the telescope bay. The structure of the RWA, and its hierarchical organization, is shown in Figure 4. The structural schema that KRITIK2 uses to represent of structure of the BearingAssembly is shown in Figure 5. The functioning of RWA is based on the law of conservation of angular momentum. When the telescope is to be oriented towards a specific direction, a signal from the earth is sent to the motor that results in a change in the power supplied by the poweramp to the motor. This causes a change in the motor’s angular momentum which in turn affects the angular momentum and angular velocity of the shaft. Due to the conservation of angular momentum, the angular momentum of the telescope as a whole changes in the opposite direction. 8
RWA
?? PowerAmp
?
@@R BearingAssembly
Motor
?
? BallBearings
Shaft
Figure 4: Part of the Reaction Wheel Assembly (RWA) structure BearingAssembly : is-a-part-of : RWA consists-of : (Shaft, BallBearings) affects-transitions : ((BearingAssembly.Heat-Affects-BearingAssembly.Temperature)) affected-by-transitions : ()
Figure 5: The BearingAssembly Structure Schema When the telescope nears its desired orientation, a change in the angular momentum of the telescope in the opposite direction is achieved in a similar manner, and the telescope angular velocity is reduced to zero. A common problem in the operation of RWA arises due to friction in the bearing assemblies. The load on the bearings due to the rapid spin of the rotor causes deformation of the bearing balls which results in increased frictional forces in the bearing assembly. This causes generation of heat in the bearing assembly. Since the increase in temperature depends on the load on the bearings, a typical redesign solution to this problem is to increase the load capacity of the bearings by increasing the size of the balls. This increased temperature in the bearing assembly is an example of an unintended and undesirable behavior. Figure 6 shows the internal causal behavior of the RWA as represented in KRITIK2. Note that the change in the Shaft.AngularVelocity has both desired and undesired effects. The desired effects are depicted by the empty dashed boxes in the left of the Figure. The side-effect which is of interest for the particular example, is shown by the rest of the dashed boxes in the middle and right of the Figure. Note that each dashed box in Figure 6 represents a state-transition, each vector represents an under-condition-transition between the state-transitions it connects, and the solid boxes represent component-states. The input to the blame-assignment task in the RWA example is an undesirable behavior (high temperature) localized to a specific structural element in RWA (the bearing assembly). The output is the specific structural element(s) in RWA responsible for the high temperature in the bearing assembly. KRITIK2’s algorithm for blame assignment in the context of redesign is shown in Figure 7. This algorithm assumes that there are no loops in the causal dependencies in the model. In the RWA example, the algorithm uses the BearingAssembly (whose specification is shown in Figure 5) as an index into the causal model as indicated in the bottom right of Figure 6. The index points to the behavior in the model in which the temperature of the bearing assembly is affected, namely the BearingAssembly:Heat ? Affects ? BearingAssembly:Temperature. The under-condition-transition pointer in this behavior is traced to the “preceding” behavior Shaft:FrictionalForce ? Affects ? BearingAssembly:Heat. The behaviors in the model are traced backwards until the algorithm reaches the behavior Shaft:AngularV elocity ? Affects ? BearingAssembly:FrictionalForce. The transition in this behavior is annotated with a qualitative relation that specifies that the frictional force is inversely 9
Substance : AngularVelocity Property : Magnitude Param : W
PowerAmp.Power Affects Motor.Torque
?
Motor.Torque Affects Shaft.AngularMomentum
UNDER-CONDITION-TRANSITION Shaft.AngularMomentum Affects Shaft.AngularVelocity QUALITATIVE-RELATION BearingAssembly.FrictionalForce.F = f(+Shaft.AngularVelocity) BearingAssembly.FrictionalForce.F= f(-BearingBalls.Diameter)
?
Shaft.AngularMomentum Affects Shaft.AngularVelocity
?? ? ? ?
...
?
@@ ? Substance : @@ R Property FrictionalForce : Magnitude Shaft.AngularVelocity Affects Param : F BearingAssembly.FrictionalForce ? Shaft.FrictionalForce Affects BearingAssembly.Heat
?
-
BearingAssembly.Heat Affects BearingAssembly.Temperature
R
Component : BearingAssembly Property : Temperature Param : T1 UNDER-CONDITION-TRANSITION Shaft.FrictionalForce Affects BearingAssembly.Heat QUALITATIVE-RELATION BearingAssembly.Temp.T2 = f(+BearingAssembly.Heat.Q)
?
Structure Schema BearingAssembly
?
? ? ?
Component : BearingAssembly Property : Temperature Param : T2
Figure 6: Part of the Internal Causal Behavior of RWA
10
proportional to the diameter of the bearing balls. Since the diameter of the bearing balls is an independent variable in the model (it does not depend upon the preceding behavior) the algorithm concludes that this is a structural element responsible for the undesirable behavior of RWA. The final output of the blame-assignment process is a list of such structural elements. BLAMETRACE(Pointer-to-Structure, Bundesirable ) Starting Points = affected-by-transitions(Pointer-to-Structure) FOR EACH element IN Starting Points Structural Causes = Structural-Elements that affect this transition UnderConditionTransitions = List of FOR EACH element IN Structural Causes affected-by-transitions(element) FOR EACH cause IN Structural Causes IF affected-by-transitions(cause) = THEN PossibleFaults = PossibleFaults cause END-FOR Starting Points = Starting Points UnderConditionTransitions END-FOR
;
[f
g
[
Figure 7: Algorithm 2
5.3 Cycles and Fields The examples described above are limited in two very important ways. First, they are devices whose internal causal behaviors can be represented as DAGs (directed acyclic graphs). Their internal causal behaviors do not contain cyclic behaviors, such as feedback for example. Second, they contain only components and substances, where a substance can flow from one component to another only if the two components are interconnected. They do not contain fields that can influence at a distance.
? ??
SWITCH
# gggggg gggg "!
@ CLAPPER 6 SPACE1 loc8
BATTERY
6 SPACE2
COIL
Figure 8: Electromagnetic Household Buzzer Although the class of physical devices consistent with the two assumptions stated above is quite large, there are many other devices that contain cycles or fields or both. Consider for example the electromagnetic household buzzer, shown in Figure 8. The function of the buzzer is to produce a sound when the switch is closed. Its structure consists of a switch, a battery, a magnetic coil, a clapper, and several wires. Informally, the internal causal behavior of the buzzer that results in its function is the following: When electricity flows 11
through the coil, it creates a magnetic field in the space around it. The clapper is within this space. In resting state, the clapper is stationary and the circuit is closed at point loc8, as shown in Figure 8. When the switch is pressed, the circuit is closed, electricity flows from the battery in the coil, and a magnetic field is created. The magnetic field attracts the clapper towards the coil, and opens the circuit at loc8. The moment the circuit opens, electricity flow stops, thus destroying the magnetic field in the coil, and releasing the clapper to its resting state. When the clapper returns to its resting state, the circuit closes again, and the behavior is repeated. The behavior described above depends critically on the repeated creation and destruction of the magnetic field in the coil. The magnetic field differs from substances such as water in that the field can influence the device components at a distance, as long as they are within the field space. Properties of components that happen to be within the field space might change. A field can be characterized by the location of the field source, the range of its influence, its intensity, and the function that describes how its intensity changes with the distance from the field source. KRITIK2’s representation of a field is shown in Figure 9. field-schema: field-source : a point in the device space field-range : the range within which the field influences intensity : a property of the field influence-function : qualitative relation that describes the intensity change with the distance from the field.
Figure 9: Field Schema
GIVEN : MAKES : sound PROVIDED : switch BY-TEMPORAL-ABSTRACTION :
@
@@
R @
STATE1
STATE2
6
?
STATE4
-
STATE3
Figure 10: The by-temporal-abstraction primitive The function of the device is to produce a continuous sound. This sound is produced as the result of a sequence of events, namely, the clapping of the clapper against the circuit when it returns to its resting position. The device function can be viewed as a temporal abstraction of the repetitive causal behavior. KRITIK2 uses the primitive by-temporal-abstraction to represent this relation between the function and the causal behavior of the device as illustrated in Figure 10. Since the internal causal behavior occurs repeatedly, the pointer from the by-temporal-abstraction slot to the cyclic behavior can point to any of the states as initial state. A simple extension is also necessary to the blame assignment algorithm (i) to start the blame assignment process in the initial state to which by-temporal-abstraction points, and (ii) to terminate the trace of the behavior when it 12
reaches the initial behavior state the second time around.
6 Related Research KRITIK2 evolves from our earlier work on the KRITIK system. The original KRITIK used case-based reasoning for designing physical devices and model-based reasoning for adapting design cases (Goel 1991a, 1991b). KRITIK used structure-behavior-function models based on a component-substance ontology and represented in the behavioral representation language for design modification. Its component-substance ontology was borrowed from Bylander and Chandrasekaran’s (1985) research on the method of consolidation, and its behavioral representation language was based on Sembugamoorthy and Chandrasekaran’s (1986) work on the functional representation scheme. KRITIK2 extends KRITIK’s ontology, model, and language to include fields. KRITIK could handle simple interactions between multiple causal processes; KRITIK2 extends it to accommodate causal side-effects and cyclic processes. The NAC example described here has been adapted from (Goel 1991a) and the RWA example has been adapted from (Goel and Chandrasekaran 1989). Our decomposition of the task of design modification into the subtasks of blame assignment and repair generalizes Goel and Chandrasekaran’s (1989) decomposition of the redesign task into the subtasks of diagnosis and repair. Similarly, our proposal for using device functions, undesirable output behaviors, and structural elements as indices to causal processes generalizes their proposal for using functions and structural components as indices. More importantly, KRITIK2 for the first time integrates these ideas into a broader framework, implements the framework in a computer program, and validates its sufficiency in several domains. KRITIK2 also builds on other work in artificial intelligence on design. Its use of abstract plans, for example, is based on the method of plan selection and instantiation developed by Sacerdoti (1976), Friedland and Iwasaki (1985), and Brown and Chandrasekaran (1989) in their work on design problem solving. However, KRITIK2’s plans differ in their indexing, which is specific to the task of blame assignment, and execution, which results in backward search of the causal behaviors embedded in the SBF models. The idea of using causal models for analyzing designs of physical devices dates at least as far back as Rieger and Grinberg’s (1978) work on commonsense algorithms. They did not, however, relate the causal model of a device with its functions or provide an account of how the causal model can be used for blame assignment. Gero, Lee and Tham (1991) have recently proposed the use of functions as indices to causal models in a manner very similar to the functional representation scheme (Sembugamoorthy and Chandrasekaran 1986) from which KRITIK2’s organizational scheme evolved. Umeda et al. (1990) have integrated the component-substance ontology of consolidation (Bylander and Chandrasekaran 1985) with the functional indexing scheme in a representation that closely resembles the SBF models used by the KRITIK2 system. Neither Gero, Lee and Tham nor Umeda et al. describe how their SBF models can be used in design modification. Stallman and Sussman (1977) introduced dependency-directed backtracking in their work on design modification to decide what component to modify when a design fails to achieve the desired functions. KRITIK2’s SBF models serve a similar purpose: they express the causal dependencies between the device states which enables the designer to trace the structural cause for the device’s failure to achieve a desired function. Steinberg and Mitchell’s (1985) REDESIGN system’s use of the purposes of structural components in a design and KRITIK’s use of functional abstractions of structural components are similar. REDESIGN’s design knowledge, however, is largely associative rather than in the form of SBF models. Murthy and Addanki’s (1987) PROMPT system uses graphs of models to decide on the applicability of modification heuristics. KRITIK2 uses task-specific organizations of general SBF models and blame-assignment plans for design modification. Further, REDESIGN and PROMPT are concerned with design modification in the context of redesign only; KRITIK2 can handle design modification in the context of experience-based design as well as in redesign problem solving. The CADET system, (Navinchandra, Sycara and Narasimhan 1991) 13
uses a functional organization of causal behaviors for design modification in the context of case-based design. Their approach is similar to that of the original KRITIK system. CADET, however, neither uses multiple indices into causal behaviors, nor handles cyclic processes or other complex interactions, nor does it solve different kinds of blame assignment tasks. KRITIK2 does all this and several domains.
6.1 Further Research KRITIK2’s model-based method for blame-assignment raises a number of new issues. Current work on KRITIK2 focuses on representation of and reasoning about (i) interactions among causal behaviors, (ii) cycles including feedback and feedforward, (iii) fields, and (iv) large devices in complex engineering domains.
7 Conclusions Our experiments with KRITIK2 lead us to three main conclusions. First, blame-assignment tasks in design modification can be of three types: (i) the design does not achieve a desired function of the device, (ii) the design exhibits an undesirable behavior, and (iii) a specific structural element in the design misbehaves. Second, each of the three blame-assignment tasks requires different indices into the causal behaviors of the design. In particular, task (i) requires design functions as indices into the causal behaviors that result in the functions, and task (iii) requires structural elements of the design as indices into the causal behaviors in which they play a role. Third, KRITIK2’s model-based method is sufficient for blame-assignment tasks of types (i) and (iii). This model-based method uses structure-behavior-function models. The range of physical devices and causal processes covered by KRITIK2 provides some evidence for the generality of its representations and methods.
Acknowledgements This research has benefited from discussions with several colleagues in the Cognitive Science Program at the Georgia Institute of Technology and at the Laboratory for Artificial Intelligence Research at the Ohio State University. We are especially thankful to Sambasiva Bhatta, B. Chandrasekaran, and S. Prabhakar. We thank Kavi Mahesh and anonymous reviewers for their comments on an earlier draft. This work has been partially supported by a grant from the NCR Corp. and an IBM Fellowship.
References [1] Brown, D. and Chandrasekaran, B.: 1989, Design Problem Solving: Knowledge Structures and Control Strategies, London, UK, Pitman, 1989. [2] Bylander, T. and Chandrasekaran B.: 1985, Understanding Behavior Using Consolidation, Ninth International Joint Conference on Artificial Intelligence, pp. 450-454. [3] Friedland, P. and Iwasaki, Y.: 1985, The Concept and Implementation of Skeletal Plans, Automated Reasoning, 1, pp. 161-208. [4] Gero, J.S., Lee, H.S., and Tham, K.W.: 1991, Behaviour: A Link between Function and Structure in Design, Proceedings IFIP WG5.2 Working Conference on Intelligent CAD, pp. 201-230. [5] Goel, A.: 1991a, A Model-Based Approach to Case Adaptation, Proceedings of the Thirteenth Annual Conference of the Cognitive Science Society, pp. 143-148. [6] Goel, A.: 1991b, Model Revision: A Theory of Incremental Model Learning, Proceedings of the Eighth International Workshop on Machine Learning, pp. 605-609. [7] Goel, A. and Chandrasekaran, B.: 1989, Functional Representation of Designs and Redesign Problem Solving, Proceedings of the Eleventh International Joint Conference on Artificial Intelligence, pp. 1388-1394.
14
[8] Goel, A. and Chandrasekaran, B. : 1990, A Task Structure for Case-Based Design, Proceedings of the 1990 IEEE International Conference on Systems, Man, and Cybernetics, pp. 587-592. [9] Keller, R., Manago, C., Nayak, P., Rua, M.: 1988, Internal Memo, Knowledge Systems Laboratory, Stanford University. [10] Minsky, M.: 1963, Steps Towards Artificial Intelligence, Computers and Thought, Feigenbaum and Feldman (editors), McGraw-Hill, New York. [11] Murthy, S. and Addanki, S.: 1987, PROMPT: An Innovative Design Tool, Proceedings of the Sixth National Conference on Artificial Intelligence, pp. 637:642. [12] Navinchandra, D., Sycara, K. and Narasimhan, S.: 1991, Behavioral Synthesis in CADET, a Case-Based Design Tool, Proceedings of the 7th Conference on Artificial Intelligence Applications, pp. 217-221. [13] Rieger, C. and Grinberg, M.: 1978, A System for Cause-Effect Representation and Simulation for Computer-Aided Design, Artificial Intelligence and Pattern Recognition in Computer-Aided Design, J. Latombe (editor), Amsterdam, Netherlands, North Holland, pp. 299-334. [14] Sacerdoti, E.: 1977, A Structure for Plans and Behavior, Lawrence Erlbaum, Hillsdale, NJ. [15] Samuel, A.: 1967, Some Studies in Machine Learning Using the Game of Checkers - II, IBM Journal, 11(11),601. [16] Sembugamoorthy, V. and Chandrasekaran, B.: 1986, Functional Representation of Devices and Compilation of Diagnostic Problem-Solving Systems, Experience, Memory and Reasoning, J. Kolodner and C. Riesbeck(editors), Lawrence Erlbaum, Hillsdale, NJ, pp. 47-73. [17] Stallman, R. and Sussman, G. : 1977, Forward Reasoning and Dependency-Directed Backtracking in a System for Computer-Aided Circuit Analysis, Artificial Intelligence, 9, pp. 135. [18] Steinberg, L.I. and Mitchell, T.M.: 1985, The REDESIGN System: A Knowledge-based Approach to VLSI CAD, IEEE Design and Test of Computers, 2(1),45. [19] Umeda, Y., Takeda, H., Tomiyama, T., Yoshikawa, H.: 1990, Function, Behaviour, and Structure, Applications of Artificial Intelligence in Engineering, vol 1, Design, Proceedings of the Fifth International Conference, Gero (editor), Springer-Verlag, Berlin, pp. 177-193.
15
