An Explication of Function - Semantic Scholar

An Explication of Function B. Chandrasekaran and John R. Josephson Laboratory for AI Research The Ohio State University 375, Dreese Laboratories 2015 Neil Avenue Columbus, OH 43210

January, 1996 Abstract. For the last several years, mostly motivated by diagnostic and design problem solving, there has been much work on functions of devices. The intuitions about functions that these investigations capture and to some extent formalize are not all the same, and are generally quite restricted in their range of applicability. In this paper, we attempt to provide a foundation for unifying and generalizing many of these intuitions. Objects are embedded in an environment and represented in a view. Objects have properties in causal interaction with environment properties and are characterized by their property relations. Functions are defined in terms of the effects objects have on their environment. This framework is sufficient to unify static and dynamic objects, abstract and physical objects, intended and natural functions, and structural explanation as a species of causal ordering. We believe that with additional domain-specific content theories at different levels of abstraction, this framework can be uniformly applied in different domains. 1. Desiderata for a Framework on Functions The last two decades have seen flowering of work on reasoning about physical systems. Recently, motivated by problems in diagnosis and design, a stream of work has emerged in which the notion of device function has been central. Diagnosis is naturally concerned with malfunctions, and design is, of course, concerned with producing a structure that has a desired function. This stream of work uses many of the ideas that have been developed in qualitative reasoning and qualitative simulation. For example, [1] uses qualitative simulation to verify design functions. The various investigations on device functions have mostly lacked a unified technical vision underlying them. Different intuitions about functions are pursued in different contexts and application domains. It is hard to see how to unify them and build on each other, even though each approach clearly solves some set of problems. What we need is a minimalist effort, something that looks for what is common among all the intuitions about function and seeks to build the smallest ontological framework within which the notion of function can be explicated. Of course, for work in particular domains and applications, additional constructs and content theories will be needed, but, if the effort is successful,

the minimalist commitments can be used by all. This paper is an attempt to provide such an ontology. A framework for functions should, in my opinion, satisfy the following desiderata. • 1. It should apply both to intended functions of human-designed devices, functions or roles in natural systems. Consider: i. the function of a chair is to support comfortable seating ii. the function of the heart is to pump blood iii. the role of the moon in causing tides iv. the role of DNA damage in causing cancer I hold that whether a property is an intended function or an observed role is a stance toward it rather than intrinsic to the property. • 2. It should apply to functions of both static and dynamic objects. Almost all of the work on reasoning about objects and their functions has focused on functions which are defined in terms of state changes of objects, e.g., electronic circuits, buzzers, gears, and so on. However, the notion of function applies just as well to static objects, e.g., support beams, windows. • 3. It should apply to functions of abstract as well as physical objects. Even though most of the work has been done only for physical objects, one can talk of functions of modules in software, and of steps in plans, just as naturally as speaking of functions of physical objects. 2. The Framework 2. 1. Ontology: an object, in an environment, viewed from a perspective The world is composed of objects in causal interaction with each other. The primitive representational notion for us is that of an object in a view in an environment. Representationally, the basic elements are: in Object properties (Generic) environmental properties in potential causal relation with object Property relations An object in the real world has a potentially infinite and open-ended number of properties: science can discover new properties or relationships between existing properties, and one can define new properties from old properties. A view is a specific modeling stance; it selects certain properties of the object for representation. The view also implicitly specifies the classes of external objects an object can be in causal interaction with.

2

E Figure 1. An object O in an environment E. Object properties pi and pj are in causal

p’i

p1

p’j

pi pj

interaction with generic environmental properties p’i and p’j.

pn

O The central idea is illustrated in Figure 1. An object interacts with its environment because some of its properties either affect or are affected by the properties of objects in the environment. When two people are in a room, what one person says affects the mood of the other person. When an electrical wire comes in contact with an electrical terminal of an object in its environment, depending upon which of the voltages is the independent variable, the voltage of one of the terminals causes the voltage of the other terminal to have the same value. The terminals are simply special cases where the property is localized to a physical location, but the most general way of talking about causal interaction between objects is by means of the properties that causally interact. Since we wish to describe the object in some generality, the environment is specified in general terms. That is, the environmental properties that the object can interact with are described as types. Finally, a set of property relations are given that represent the modeler’s causal understanding of the object. The relations state all the causal relations between the properties, both the object’s and environmental ones, believed by the modeler to be relevant. The causal relationships can be in any form: continuous, discrete, qualitative, etc. In order to carry a complete example through the paper, I give below the representations of three objects that will be required for our representation of a heater: an electrical switch, a battery, and a heater-resistor. In the representations below, we will use the font as in reserved terms to denote reserved terms of the framework, and the font as in domain-specific to denote domain-specific terms. (This applies only to text, not to the figures.) Example 1. Electrical Switch

3

user_action' {Push, Pull}

v'1 at location p' 1

v' at 2 location p' 2

switch_state ({Closed,open}) v1 at location p 1

I

v2 at location p 2

Figure 2.. Electrical Switch. v1 and v2 are the voltages of the two terminals p1 and p2, in causal interaction with generic voltages, v1’ and v2’, respectively, of generic electrical terminals p’1 and p’2 in the environment. I is current flow. Switch_state is a binary object property in causal interaction with generic external property, user action, in pressing switch. Dotted lines indicate causal interaction with external properties.

Object: Electrical_Switch Object Properties: v1, v2, type voltage, at locations p1 and p2 I, type current Switch_state({Closed, Open}) Environmental Properties: user_action’({Push, Pull}) v1’, type voltage, of electrical terminal p’1 (the terminal in causal interaction with p1) v2’, type voltage, of electrical terminal p’2 (the terminal in causal interaction with p2) Property_Relations: v1’ = v1, v2’ = v2 user_action(Push) → switch-state(Closed) switch-state(Closed) → (v1 = v2) user_action(Pull) → switch-state(Open) switch-state(Open) → (I = 0) Example 2. Battery Figure 3. Battery v' at 1 location p' 1

v' at 2 location p' 2

v1 and v2 are the voltages of the two terminals p1 and p2, of the battery in causal interaction with generic voltages, v1’ and v2’, at terminals p’1 and p’2, respectively, of the environment. I is current flow.

v2 at location p 2

v1 at location p 1 I

4

Object: Battery Object Properties: v1, v2, type voltage, at locations p1 and p2 I, type current battery voltage, B; internal resistance, b; Environmental Properties: v’1 , type voltage, of terminal p’1 v’2, type voltage, of terminal p’2 Property_Relations: v1’ = v1, v2’ = v2 v1 - v2= B - Ib The property relations simply assert the well-known relation between the voltage difference, current and resistance, and the fact that the voltage of any terminal of an external object connected to the terminal pi of R is the same as vi, i = 1, 2. In this example, the property relations do not specify the causal direction, but in general they include all knowledge of causal relations between properties, in whatever form.

Example 3. Heater-resistor Figure 4. Heater-resistor. v' at 1 location p' 1

T'e

T v1 at location p 1

s

v2 at location p 2

v' at 2 location p' 2

v1 and v2 are voltages at terminal locations p1 and p2, in causal interaction with voltage properties v’1 and v’2 of terminals in the environment. I is current. Ts is surface temperature of resistor in causal interaction with property T’ e, the surface temperature of the fluid layer in physical contact with the surface of the resistor.

I

Object: heater-resistor Object Properties: v1, v2, type voltage, at terminals p1 and p2 respectively I, type current R, resistance; k, conversion constant for transformation from electrical to heat energy of resistor material Ts, temperature of resistor surface Environmental Properties: v1’ , type voltage, in causal interaction with v1 v2’, type voltage, in causal interaction with v2 T’e, type temperature of surface of fluid layer in contact with resistor surface

5

Property_Relations: v1’ = v1, v2’ = v2 I = (v1 - v2)/R Ts = k* (I**2) T’e = Ts 2.1.1. Static versus Dynamic objects. When, in a modeling situation, we wish to focus on changes to the properties that occur as part of the causal phenomenon, those properties are called state variables. Property relations then describe the relations between state variables at a given instant of time as well as between them at different instants of time. Time flow can be continuous, discrete, or as a series of landmark instants. We call objects which have dynamic properties in a view “dynamic objects” for short. Much of the work on representing functions has focused on objects of this sort. There is much confusion between the terms “function” and “behavior” that comes up often in the discussion of dynamic objects. It is worth looking briefly at this term, “behavior.” Behavior. Let {S} be the set of state variables of a dynamic object. Behavior is a term that is used to refer to the values of state variables over time (whatever model of time is chosen). Usage in the literature is not consistent and can refer to one of more of the following: •the value(s) of any state variable(s) of interest at one instant •the value(s) of any state variable(s) of interest over an interval of time •the value(s) of state variable(s) specifically labeled “output” state variables, either at an instant or over an interval of time •the values of all the state variables in the object description, either at an instant or over an interval of time In order to improve clarity, I propose using term “behavior trajectory” when referring to values over an interval of time. Other than this, we will let context and specific qualifications determine our usage of the term “behavior.” Property (and state and behavior) abstractions. One of the common ways in which views of objects are changed is by defining property abstractions. Examples: • In the case of a particular electrical circuit, we may define a new abstraction variable, a, called “amplification factor” as the ratio of two specific voltages, vo and vi. • In the case of another electrical circuit, we may define a configuration of voltages as standing for binary numbers, with specific values of the voltages mapping to 0s and 1s. We might then define new abstractions called addends and sum to refer to values of specific voltage configurations. This is the view change that would occur in going from the electronic circuit level to the arithmetic representation level in an adder. • An example that is especially interesting occurs when a new state variable is created from a behavior trajectory. Let s be a binary state variable. A binary

6

state variable oscillating can be defined based on whether the behavior trajectory of s is of the form {0, 1, 0, -1, 0, ...}, with oscillating being true when the trajectory of s satisfies the form. 2. 2. Composing Objects to Make Composite Objects. How do objects causally interact? When we connect two objects, we are making it possible for selected properties of the two objects to be in causal interaction of the type determined by the type of connection. Thus, from the representational point of view, connecting two objects involves declaring which properties of the two objects are in causal interaction. We can identify types of connections and associate with each type the properties whose causal interactions are enabled. For example, being in physical proximity is one type of connection which enables magnetic and gravitational properties to interact. Being in physical contact is another type which enable properties associated with force, motion, etc. to interact. Details of connection types are not central to our current purposes. Our basic ontology for an object is not one of the object in isolation, but in some environment, in contact with other objects. Given two objects, “connecting” them is configuring the objects such that each becomes part of the other’s environment. They can be conceived as causally connected only if they are compatible. This is illustrated in Figure 5. Notationally, we will specify a connection Ci between objects o1,...on as Ci(o1;..on), where somewhere Ci is described so that the properties in causal contact can be determined.

p’i pi

Figure 5. Composition of two objects. If qi is of the type

q’i

pi’, and pi is of the type qi’, then O1 and O2 have a compatible connection for properties p i and qi.

qi O1 1

O2

Example. Composing two resistors. Consider two resistors R1 and R2, with individual object representations as follows. We will assume that the representations of the individual objects are as in the heater-resistor example, except that we will only focus on electrical properties, with variables R, v 1, v2, I, v’1 and v’2 replaced by Ri, vi1, vi2, v’i1 and v’i2, for i = 1, 2. There are four ways these objects can be connected (within the compatibility requirements), two of them serial and two parallel. Below, we give one instance for each type. • Serial. v12 in causal interaction with v21. This would call for setting v’12 = v21, and v’21 = v12. • Parallel. v11 in causal interaction with v21 and v12 in causal interaction with v22. This would require setting v’11 = v21, v’21 = v11, v’12 = v22, v’22 = v21.

7

2.2.1. Terminals or Ports In engineering, when we assemble components to make devices, the connections are often made at specific locations called “ports” or “terminals.” Specifying ports as part of object description is one way to identify properties that can be put in causal relation with external objects. In principle, an infinite number of voltages can be measured on a resistor, at different points along it. By the same token, in principle, any point in it can be in electrical contact with an external electrical object. But a specific model of a resistor would only focus on the voltages at its two ends, making the ends the only loci of causal interaction with external objects. Thus, identifying terminals is a useful way of specifying an object’s loci of causal interactions. While the use of terminals works well for engineering objects, it is neither necessary nor always appropriate. In modeling human interactions, we might wish to focus on the fact that moods and sayings of one person affect the moods of another. The only model of composition here is for two human beings in physical or communication contact. It would be awkward to identify ports through which moods interact and ports through which sayings and moods interact and so on. The point is that what is fundamentally important for our minimal ontology for causal reasoning is that properties of one object can affect the properties of another object if the objects are in appropriate configurations for this to happen. 2.2.2. Description of Composed Object. A description of a composed object can be generated from the descriptions of individual objects and the connection specifications using some domain knowledge. The details of the composition can be complicated, but our minimalist ontology provides quite a bit of support. Let us consider some aspects of the process using the serial example. In the serial case, we start with 4 intrinsic and 2 external properties for each object. We first generate the property relations of the two objects with appropriate substitutions. Technically, the union of the two sets of property relations, after the substitutions, contains all we know about the composed object’s property relations, so in that sense it is complete, but the union will not be especially useful unless additional inferences are drawn and the relations are simplified. For the serial resistors example, we can quickly make the following inferences: v12 = v21, I1 = I2 = (v11 - v22)/(R1 + R2). Of course, the inference process may come up with other inferences as well, inferences that we may or may not wish to focus on. There is also the issue of the environmental properties for the new object, which is essentially the question: what sorts of causal interactions can the composed object have with the external world? This is partly a matter of domain knowledge. For example, an electrical terminal can accept an arbitrary number of external connections (in principle), but a bit of space, once occupied by another object, is not available for occupation by another object. The knowledge about electrical terminals suggests that the composed object will have three loci of causal interaction with external objects, v11, v22 and the join of v12 and v21.

8

There are two important questions about the process of deriving a simplified and useful set of property relations for the composed object: Can we do this for arbitrary objects, and how complex is the process? In the case of the property relations involving simple resistors, deriving the consequences of serial connection by repeatedly applying the relations to the situation instantiated by the connection is relatively straightforward. This will not in general be the case. Depending on the form of the property relations, deriving the set of property relations may require discovery of new mathematical techniques, and even when techniques are available, the derivation may be arbitrarily complicated, contributing to the concern about incompleteness. 2.2.2.1. Composite object in a new view

After deriving a representation of the composite object, we might wish to re-represent the composite object in a new view, by suppressing some of the component-level properties, introducing new property abstractions, and by restricting our representation of its causal interaction with the external world. In the case of the (serial) example, the modeler might wish to suppress the identity of the individual resistors and make only v 11 and v22 available for external interactions. In this case, the composed object will be represented in a new view, where the object properties are simply {R s, v1, v2, I} and the external properties are simply the two voltages of objects connected to the two terminals of the composed resistor. Generating this sort of reduced representations for certain kinds of composite objects has been discussed in the literature on Consolidation [2]. For another example, consider an electronic Adder circuit. Composing its components, we can generate a description of it in terms of voltages and currents and generate a set of property relations involving both object and external properties. It can also be represented in the Adder view: instead of voltages and currents, new property abstractions of addends and sum and their interrelations would describe the composed object. This would typically be the user view of the Adder object. 2.2.2.1. Structure of a composite object

We can now define a structural description of a composite object as follows. Given an object O in view V, with object properties {pi}, environmental properties {e i}, and property relations f({pi}, {ei}), a structural decomposition of it is given as follows. • A set of component objects {o1, o2,.. oi, ..., on} are identified, where oi is in view Vi and has properties {pij}, {eij} and property relations fi. • A composition relation C(o1,... on) is identified among the component objects o1, .. on, consisting of a set of configuring relations. • Mappings between {pi} and {ei} of O and {pij} and {eij} of the component objects are given. That is, the decomposition identifies the properties mentioned in O’s description in terms of the properties of the components. Example. Composing an electrical heater circuit. Now let us consider the series composition of the electrical switch, the battery and the heater-resistor. We will omit the details of the derivation of the composite representation. We give two representations, one which retains all the properties of the components

9

(except that further external electrical connections are not included), and one in a new view that we call the “user view.” The user view suppresses the electrical properties. Figure 6.. Electrical circuit, with objects electrical_switch, battery and heater-resistor composed in series. The

user_action({push, pull}) p

1 T'e

switch_state({closed,open}) Ts

p 3

p

2

variables have been simplified so we now have three electrical terminals p1, p2 and p3, with voltages v1, v2 and v3 as voltage properties; they are no longer in causal interaction with external electrical terminals. It has a physical terminal in interaction with the environmental property, user_action, and one thermal terminal, with property T s, the surface temperature, in interaction with an external fluid layer with property T’e, its surface temperature.

Composed-Object: Resistor circuit (in a view that retains the components’ properties). Object properties: voltages v1, v2, and v3 at terminals p1, p2 and p3 respectively I, current through the circuit R, B, b, k, Ts (resistance, battery voltage, internal resistance of the battery, conversion constant from electrical to thermal energy, and the surface temperature of the heater-resistor, respectively) Environmental properties: User_action({push, pull}) T’e , temperature of fluid layer in contact with resistor surface Property relations: If User_action(push), then Switch_state(closed) I = B / (R+b), v1 - v2 = R*I, ... Ts = k * (I**2), T’e = Ts If User_action(pull), then Switch_state(open) I=0

10

Figure 7. Heater. This is in

user_action({push, pull})

T'e

switch-state({closed,open})

ooopen)

Ts

a user view that suppresses electrical properties. There are only three object properties, switch-state, heater-rating parameter k’, which is greater than the ambient temperature Ta, and heater-surface temperature. Causal interactions take place through environmental properties, User_action and temperature of fluid layer in contact with heater surface.

Object: Heater (in user view) Object properties: k’, heater temperature rating; switch_state; Ts, heater surface temperature Environmental properties: User_action({push,pull}), T’e Property relations: T’e = Ts If User_action (Push), then switch_state (closed) Ts = k’ (> Ta , ambient temperature) If User_action (Pull), then switch_state (open) Ts = Ta (ambient temperature) 3. Functions Now we are ready to discuss the main point of the paper. The central idea that we will propose is that function of an object is the effect it has on its environment. Thus a functional definition of an object has two parts: 1. Mode of deployment describing the properties of the object and the environment that are in causal interaction. This is typically given by specifying the types of connections between an object and objects in its environment. 2. Functional formulae. Under what conditions on environmental properties, what predicates on the environmental properties become true. We start with an environment, consisting of objects, O1, ...ON, in some relationship. It is not necessary for the objects to be specified in full. Let F be a formula defined over the properties of interest in the environment.

11

Example. Pump: An environment in which properties of interest are the quantities of water, Q1(t) and Q2(t), at instant t, in locations L1 and L2 whose elevations are h1 and h2. Let h2 > h1. Let F be the formula corresponding to Q 1(t0) - Q1(tf) = Q2(tf) - Q2(t0) = K > 0. That is, a positive quantity of water is moved from L1 to L2 from the initial instant to final instant. For simplicity let us call this formula Pump(K, h1, h2). Definition. Function. Let F be a formula defined over properties of interest in an environment. Let us consider the environment plus an object D. If D (by virtue of certain of its properties) causes F to be true in the environment, we say that D performs, has or achieves the function (or role) F. Remarks. Note that while F is described as a function of object D, both causes and effects in the specification of F are defined exclusively in terms of properties outside of D. The function of an object is not the effect it has on itself, but the effect it has on its environment. In the Pump example, the formula Pump(K, h1, h2) describes an effect on the environment. If an object is introduced such that it causes the formula to be true, we will say that the object plays the role of Pump or has the function Pump. Many different objects can achieve this function in many different ways. The above sense of function applies for both intended functions and natural functions. For example, if we have a goal of making the formula Pump(K, h1, h2) true, and we design a device which, when embedded in the environment, causes the formula to be true, then we say that the device has the intended function Pump. On the other hand, applying the definition, we can also say that the heart has the function Pump. The definition of function is neutral with respect to whether the cause-effect description is intended or observed. 3.1. Functions of static and dynamic objects The definition of function as given is applicable both to static objects and dynamic objects. In the case of static objects, the object which has function F causes F to be true of the environment when it is appropriately embedded in E. The flower-arrangement, when placed in the room, causes the predicate Pleasant to be true of the room. The chair, when it is in a certain relation to the person sitting in it, causes the sitter’s bottom to be supported comfortably. In the case of dynamic objects, describing the role or the function of an object would typically require giving a sequence of partial states of the environment. Let us take some examples: Example. ATM machine The Automated Teller Machine is an example that has been much used in the objectoriented design community. The functional description here is: Customer-Withdraw-cash($K): . {Customer-cash (x), balance-in-customer-account (y), y > K, → Customer_cash(x + K), balance-in-customer-account (y - K)} The intended interpretation is that the antecedent is true at t 0 and the consequent at tf.

12

Example: The Thermostat in a home-heating system (room_temp < Tset → furnace (on)) or (room_temp >=Tset → furnace (off)) Note that, in all these examples, both the cause and the effect in the functional definition are external to the object. It so happens that in the examples, no mention is made of any aspect of the structure of the object, such as “If User_action(Push) at location switchbutton,...” While User_action(Push) is an entirely environmental property, and as such satisfies the requirements to participate in the function definition, this can only be meaningfully in interaction with a specific location of the object, switch-button. Not mentioning any structural feature of the functional object is often a feature of functional definition for the design task. 3.2. Function in the Design Task Let E be an environment and let F be a predicate defined for E. Let a cognitive agent have a goal to have F be true in E. This sets up a design task: to specify an object D, and a composition specification to embed D in E, such that when D is so embedded, F is caused to be true. Remarks: 1. Traditional definitions of the design task focus on the need to specify the object, i.e., provide a list components from some component library and a way of composing them. The definition above additionally requires that a way of composing D with, or embedding D in, E be specified as well. This is a consequence of the fact F is defined without any commitment to properties of structure of D. Thus the design task is not complete until the designer includes a mode of deployment of D, i.e., how it is to be connected to the environment. 2. The function definition may not make any reference to the structure of the object that has the function. It is left to the mode of deployment to make the needed references to the structure of the object. Consider the example of the buzzer. Typically, in the literature, the function is stated as “when the switch is pressed, a sound is made.” “Pressing the switch” makes reference to a part of the structure of the device. The Buzzer function itself might be given to the designer simply as no sound in the environment → sound in the environment The definition just given for the design task makes the reasons for this clearer. It is useful to think of the definition of the function of buzzing as potentially existing independent of, and prior to, the design of the buzzer. The function definition cannot include a reference to the structure of something that may not yet have been designed. Also, by isolating the function definition from any reference to the structure, we are making it possible for the designer to come up with very different objects to achieve the function. Perhaps one design would achieve the function when it is twisted, another when it is blown on, and so on. By the same token, the task of the designer is not simply to describe the artifact to be built, but also to specify how it is to be deployed in the environment.

13

3.3. Example. Functions of the components and device for the Heater object. We refer the reader to the Figures 2, 3, 4 and 7, and the object descriptions that follow them. For each of the objects, selected functions are given below. Each function has a mode of deployment and the functional formula specification, and is named for later reference. Electrical switch Functions: close_connection(p’1, p’2), open_connection(p’1, p’2) Mode of Deployment: p1, p2 in causal interaction with external electric terminals p’ 1, p’2 switch_state button in causal interaction with user_action Functional Formulae: close_connection(p’1, p’2): user_action is Push → (v’1 = v’2) open_connection(p’1, p’2): user_action is Pull → (I = 0) Battery Function: Apply_voltage(B) across p’1 and p’2 Mode of Deployment: p1, p2 in causal interaction with external electric terminals p’ 1, p’2 Functional Formulae: v’1 - v’2 = B Heater-resistor Function: Heat_Surface_in_contact(T’e > T’e0) Mode of Deployment: p1, p2 connected to external electrical terminals p’ 1, p’2 with voltage difference v’ resistor surface in contact with fluid surface, temperature T’ e Functional Formulae: When v’ = 0, T’e = T’e0 When v’ = va > 0, T’e = k * (va/R)**2 > T’e0 Heater (User View) Function: Heat_surface_ in_contact(k’) Mode of deployment: switch_state button in causal interaction with user_action resistor surface in causal interaction with fluid surface, temperature T’ e Functional Formulae: If User_action(Pull), T’e = T’e0 If User_action(Push), T’e = k’ > T’e0 3.4. Causal Explanation of How a Function is Achieved An important requirement for a functional framework to be used is that it should support reasoning about the relation between the properties of an object and its components. This is essential for both diagnostic and design purposes.

14

The stream of work on functions called Functional Representation (FR) Language (summarized in [3]) focuses on the relationship between the function of a device and its structure. In particular, it proposes a representation called a causal process description (CPD) to explain how the device achieves the function. In the CPD, the causal transitions are associated with formally interpretable explanatory annotations. The annotation that links the device level to the component level is one that explains a transition by appealing to some function of a component. This way of explaining has intuitive appeal. However, in the FR work, function is defined as a sort of abstraction of an object’s own behavior. Thus, in its definition of function, it does not make the distinction between the object and the environment that we make here. It would be useful to show that the intuition of explaining a device level function in terms of component functions can be supported when we adopt the definition of function proposed here. Further, the form of explanation provided by FR, the causal process description, can be seen to be only one kind of explanation, one that fits well with commonsense explanations. It is not immediately obvious how this form of explanation relates to the more formal explanations that are used in the hard sciences. In this section, we briefly show how the formal scientific explanation is a special case of a more general type of explanation, and we do this in the context of the new definition of function in the paper. 3.4.1. Forms of Explanation Given an object and some property that is observed, several forms of causal explanation of the property are possible and have been considered. 1. The simplest type of explanation is the set of property relations associated with the object. They constitute the understanding of the modeler about the causal relations between the object and environmental variables. The pendulum equation that relates the length and the period is likely to constitute the set of property relations in a physicist’s model of a pendulum. In the hard sciences, property relations in models of objects consist of mathematical relations between the relevant variables. The equations themselves are often acausal, as in F = ma. However, once we know which of the variables is independent in a given situation, the equations then can be viewed as showing how the dependent variables are causally determined. 2. For more complex, multivariable situations, additional insights about the causal relations can be provided by causal ordering [4] [5]). Here, the causal antecedents of the property of interest are ordered in a partial order. Causal ordering explicitly indicates which properties depend on which others. A causal ordering explanation of some property p8 of an object might look as follows, where the arrow in “a → b” is to be interpreted as “b causally depends on a”: {p2, p3} → p5 {p1, p3} → p4 {p4, p5} → p7 {p4, p5, p7} → p8.

15

Additionally, we can associate with the arrows the specific functional form of the dependency. Using this information, as we traverse the arrows, we can update the values of the dependent variables. 3. A specific type of causal ordering is structural explanation. Here the goal is to explain a property of an object in terms of the properties of its components and the way the components are put together. Using our framework, structural explanation can be described as the following series of steps. • O is first described as a composition of component objects, say, {o1, .. on}. (Many such decompositions may be possible. Each decomposition is a basis for one structural explanation.) In many cases, the views in which O and the components are represented would be different. In the Adder example, O’s properties are abstractions of the properties of the component objects. Thus describing O as a composition includes not only identifying the components and describing which properties of the objects are in causal interactions, but also providing the mappings between the properties of O in its view and the properties of the components in their views. [1] • Now a specific type of causal ordering is constructed. In this causal ordering, the causal antecedents of each object-level property of interest are identified recursively ending with (or rather causally beginning with) component-level properties. We will now consider structural explanations for the function of the Heater. 3.4.2. Structural Explanation as Causal Ordering for the Heater Device The function of the Heater from the user view, as described in Section 3.3 , is that, as the user pushes the button, the temperature of the fluid surrounding the heating surface will increase. (The user needs to have some additional model of the surrounding object, the fluid, to get an idea of how the fluid as a whole will heat up. Also, clearly, even the model of the heater as given is obviously too simple, but these details are not important right now.) A straightforward causal ordering of all the properties involved, derived from representations of the various objects given earlier, can be given as in Figure 8.

16

user_action (Push)

switch_state (Closed)

Figure 8. Structural explanation as causal ordering. Component properties

p ,, p 3 1 connected volt. applied bet p , ,p 1 2

B,b

I>0

voltage available be t. p , ,p 3 2

T

T

s

are ordered in terms of causal dependency, from user_action to the temperature of the surrounding fluid. The arrows can be annotated by the name of the component, so that the causal dependency can be checked or indicated by the Property Relations in the component model.

e

Note that all the properties that play roles in the property of interest, the value of T e, are in the causal dependency diagram (and, even though this is not an example of it, the properties that do not play a role will not be in the diagram, simplifying any simulation). The explanation is structural, since many of the causal dependency steps are explained by appeal to the Property Relations of the appropriate component. A causal process description in the FR framework is a special case of a causal ordering diagram. Some of the details in the diagram in Figure 8 can be skipped by directly appealing to the function of the components involved. (The functions of the components, of course, can be explained either by appeal to the Property Relations of the corresponding component, or by an additional level of structural explanation of the component.) For the Heater example, Figure 9 illustrates the structural explanation diagram that would correspond to the CPD in the FR framework.

user_action (Push)

p ,, p 3 1 connected

By-Fun ction Close-connection of switch

By-Fun ction Apply_Volta ge of battery

volt. a pplie d bet p , ,p 1 2

T

e

By-Fun ction Heat_Surface_in_contact of heater -resistor

Figure 9. Causal process description as causal ordering for the Heater example. Each transition in this example is explained by appeal to a function of a component.

Since the function of an object is precisely defined in terms of functional formulae as effects on objects surrounding it, the annotation is really a pointer to information that can be used for computation, or for inference. Even though the example discussed does not involve functions in which a sequence of state changes are involved, in principle, the idea of structural explanations by causal

17

ordering, where causal dependencies are explained by appeal to component Property Relations or functions, applies just as well to dynamic devices. The structural explanation in Figure 9 satisfies the intuitions that underlie the CPD in the FR work, but has the additional virtues that (i) it can be seen as a special case of other types of causal explanation and (ii) it uses what we should regard as a simpler and cleaner notion of function. 4. Related Work and Discussion There has been an explosion of work on functions in recent years, so we will only discuss, and that briefly, work directly relevant to the issues central to the current paper. A susbtantial body of work can be thought of as content-theory that can fit comfortably with the notions developed here. A set of basic roles in mechanical interactions is provided in [6] and, in a somewhat different subdomain, in Goel [19], roles that components of loops play in algorithms are given in [7], roles that seem to be common to different domains sharing the ontology of flows is given in [8] et al.. The focus on functional roles common to flow systems is shared by [9] and [10]. There has been a substantial body of work in visual understanding (see, e.g., [11]) wherein recognitional algorithms use a functional rather than a structural definition of objects to be recognized. Thus a recognizer for chair would see if the object can in fact support the sitting of a person rather than look for specific subparts. In the pioneering work on function in diagnosis [12], the function was closely tied to the object. The work in the FR tradition (summarized in [3]) and on CFRL [1, 13] [14] treats function as an abstraction of the behavior of a device, as does [15]. This is entirely adequate for many purposes, but the separation of function from the object’s properties will help those investigations to reach wider applicability. Recently, [16] and [17] share some essential intuitions with the present paper in that they make an effort to separate the behavior of an object from its function as the role played in the achievement of a designer’s goal. The present paper proposes what appears to be the simplest ontology in which this notion can be explicated, and also makes various kinds of unifications, such as between static and dynamic objects and between intended functions and functions observed in natural systems. Research on function types of [18] is orthogonal to the work here, and can be restated to be consistent with the definition of function proposed here. Locating the function in the effects on the environment, rather than in the object, clarifies the notion of multiple realizability of functions, as we discussed in the section on the design task. When the function is defined without any reference to the structure of an object, different realizations of the function become possible. This multiple realizability also gives criteria by which one could decide at what level of organization the effects of an object should be described. For example, we describe the role of the thermostat as “When the room temperature is below T set, the furnace is on.” Note that both predicates were of objects in the environment. However, an effect of the thermostat so configured is also eventually to make a person in the room warm. Does this

18

mean that it is equally plausible to attribute to the thermostat the function, “make a person warm”? Suppose that “make a person warm” can be multiply realized, for example, one, by covering the person with a woolen blanket and two, by using a thermostat-controlled furnace. The thermostat’s effect is actually on the furnace and the thermostat-furnace configuration as a whole has the effect of keeping the person warm. Thus, in the given modeling context, the thermostat’s function is best stated as its role in linking the temperature of the room to the start of the furnace. Acknowledgments We thank Susan Josephson for a number of discussions on the topic of this paper. References [1] Y. Iwasaki and B. Chandrasekaran, “Design Verification Through Function- and BehaviorOriented Representation: Bridging the gap between function and behavior,” in Artificial Intelligence in Design '92, J. S. Gero, Ed.: Kluwer Academic Publishers, 1992, pp. 597-616. [2] T. Bylander, “A Critique of Qualitative Simulation From a Consolidation Viewpoint,” IEEE Trans. Systems, Man and Cybernetics, vol. 18, pp. 252-263, 1988. [3] B. Chandrasekaran, “Functional representation and causal processes,” in Advances in Computers, vol. 38, M. C. Yovits, Ed.: Academic Press, 1994, pp. 73-143. [4] Y. Iwasaki, and H. A. Simon, “Causality in device behavior,” Artificial Intelligence, vol. 29, 1986. [5] H. A. Simon, “Causal ordering and identifiability,” in Studies in Econometric Methods, T. Koopman and W. Hood, Eds. New York: John Wiley and Sons, 1953. [6] J. Hodges, “Naive mechanics: A computational model od device use and function in design improvisation,” IEEE Expert, vol. 7, pp. 14-27, 1992. [7] D. Allemang, “Using Functional Models in Automatic Debugging,” in IEEE Expert, vol. 6, 1991, pp. 13-18. [8] L. Chittaro, C. Tasso, and E. Toppano, “Putting functional knowledge on firmer ground,” International Journal of Applied Artificial Intelligence, vol. 8, pp. 239-258, 1994. [9] M. Lind, “Modeling goals and functions of complex industrial plants,” Applied Artificial Intelligence, vol. 8, pp. 259-283, 1994. [10] A. N. Kumar, and S. J. Upadhyaya, “Function-based discrimination using model-based diagnosis,” International Journal of Applied Artificial Intelligence, vol. 9, pp. 65-80, 1995. [11] L. Stark, and K. W. Boyer, “Achieving generalized object recognition through reasoning about association of function to structure,” IEEE Trans. Pattern Analysis and Machine Intelligence, vol. 13, pp. 1097-1104, 1991. [12] R. Davis, “Diagnostic Reasoning Based on Structure and Function,” Artificial Intelligence, vol. 24, pp. 7-84, 1984. [13] Y. Iwasaki, R. Fikes, M. Vescovi, and B. Chandrasekaran, “How Things Are Intended to Work: Capturing functional knowledge in device design,” in Proceedings of the 13th International Joint Conference on Artificial Intelligence. Mountain View, CA: Morgan Kaufmann, 1993, pp. 1516-1522. [14] M. Vescovi, Y. Iwasaki, R. Fikes, and B. Chandrasekaran, “CFRL: A Language for Specifying the Causal Functionality of Engineered Devices,” in Eleventh National Conference on AI: AAAI Press/MIT Press, 1993, pp. 626-633. [15] Y. Umeda, H. Takeda, T. Tomiyama, and H. Yoshikawa, “Function, behavior and structure,” in AI in Engineering: Computational Mechanics Publications and Springer Verlag, 1990, pp. 177-193. [16] M. Sasajima, Y. Kitamura, M. Ikeda, and R. Mizoguchi, “FBRL: A function and behavior representation language,” in International Joint Conf on Artificial Intelligence, vol. 2. Montreal: IJCAI, Inc. and Morgan Kaufmann, 1995, pp. 1830-1836. [17] J. E. Larsson, “Diagnosis based on explicit means-end models,” Artificial Intelligence, 1995.

19

[18] A. Keuneke, “Device Representation: The significance of functional knowledge,” in IEEE Expert, vol. 6, 1991, pp. 22-25. [19] A. K. Goel, “Integration of cased-based reasoning and model-based reasoning for adaptive design problem solving, Ph. D. thesis, Ohio State University, 1989.

20