Component-ontological representation of function for reasoning about devices

PII: S 0 9 5 4 - 1 8 1 0 ( 9 7 ) 1 0 0 1 2 - 7

Artificial Intelligence in Engineering 12 (1998) 399–415 q 1998 Elsevier Science Limited All rights reserved. Printed in Great Britain 0954-1810/98/$19.00

Component-ontological representation of function for reasoning about devices Amruth N. Kumar a,* & Shambhu J. Upadhyaya b a Computer Science, Ramapo College of New Jersey, Mahwah, NJ 07430, USA Department of Electrical Engineering, University at Buffalo, Buffalo, NY 14260, USA

b

We propose principles behind component-ontological representation of function. In this representation, the function of a component is expressed in terms of its ports. The representation has many advantages: (i) The function of a component can be represented in isolation of its environment. Therefore, libraries of function models can be built. These models are re-usable. (ii) The function model of a complex device can be built by composing the function models of its components. This helps preserve the fidelity of representation. Further, this process can be automated. (iii) The representation is linear in space complexity: the function model of an atomic component is linear in the number of its ports, and that of a composite device is in most cases linear in the number of its components. We propose Classes as a component-ontological representation of function. We illustrate Classes by using it to model parts of a printer buffer, which has the complexity of a microcomputer. We also demonstrate how class models may be used for model-based diagnosis. q 1998 Elsevier Science Limited. All rights reserved. Key words: reasoning about function, model-based reasoning, fault diagnosis, representation.

(Consistent with its use in Computer Science,1 we use the word ‘ontology’ to mean the study of the primitives in terms of which we view an object/world. We use the term ‘ontological representation’ to emphasize the difference in the ontologies used.) The resulting representation is re-usable and composable. It is linear in space complexity and its construction can be automated. Therefore, it exhibits the traits of a ‘good’ representation, and compares favorably with many existing representations of function.2–9 Further, we present Classes as a component-ontological representation of function. As part of Classes, we propose function primitives for components as well as subsystems. Finally, we illustrate class representation using the case study of a printer buffer. The paper is organized as follows: In Section 2, we present the principles behind component-ontological representation of function. Based on these principles, we propose Classes as a representation of function in Section 3. In Section 4, we illustrate representation in Classes with the case study of a printer buffer. In Section 5, we illustrate the utility of class representation for modelbased diagnosis. We briefly review other approaches for representing function in Section 6 and summarize the paper in Section 7.

1 INTRODUCTION In model-based reasoning, the quality of reasoning is significantly affected by the quality of the models used. Therefore, building a ‘good’ model is important. A ‘good’ model must have sufficient depth of information to facilitate reasoning. In addition, the following characteristics for the model are preferred: •

•

The model should be re-usable. This will enable developers to use the same model in various contexts, and for various reasoning tasks. One implication of re-usability is that models can be stored in an on-line library. The model should be inexpensive. One mechanism to hold down the cost is to build the model of a complex device by composing the models of its components. We will refer to this as composability of a model. It is even better if this construction can be automated.

In this paper, we propose component ontology as the basis for representing function for model-based reasoning.

*Author to whom correspondence should be addressed. 399

A. N. Kumar et al.

400 2 COMPONENT ONTOLOGY PRINCIPLES

For clarity, we begin with definitions of function and behavior. The behavior of a device is a quantitative relationship between its inputs and outputs. It is normally expressed in terms of the ports of the device. The behavior of a component is independent of the device (i.e. context) in which it is embedded. The function of a device is a description of what the device does in its environment, either as intended by its designer or as interpreted by its user. Therefore, the function of a component is dependent on the device (i.e. context) in which it is embedded. Function has been traditionally expressed in terms of context. Function relates the behavior of a device to its purpose, i.e. its utility in a socio-cultural context. The proposals of this paper are twofold: •

•

Function is an abstraction of behavior. Therefore, we propose to model function as a qualitative relationship between the input and output ports of a device. Due to context-dependent nature of function, function models are often tailored to the context of application, and are hence not re-usable. We propose to build a context-independent model of function in spite of its context-dependence. Such a model consists of the most specialized expression of function of a component. It can be used in any context without loss of correctness of reasoning.

unit may be characterized as: convey ¹ electricity ∧ redirect ¹ spark(to a cylinder): Note that each new predicate adds to the complexity of a function. The following discussion is independent of the granularity of the incremental behavior that may be chosen for representation of function. It is also independent of the choice of such incremental behaviors. Definition 1. A function f 2 is defined to be specialized with respect to f1 ¼ P1 ∧ … ∧ Pn (where P i are predicates), if f2 ¼ f1 ∧ Pn þ 1 ∧ … ∧ Pn þ m for m . 0. f 1 is in turn generalized with respect to f 2. f 1 subsumes f 2. E.g. a variable resistor is more specialized than a fixed resistor. 2.2 Dual modeling of function Components are designed to be modular. Each component is provided with a set of ports through which it interacts with its environment: • •

A component is designed to process the signals at its ports. Therefore, it has specific functions with respect to its ports. The ports are designed to deliver specific signals to a component from its environment. Therefore, they have specific functions with respect to the component.

Therefore, we propose to model the function of a component in terms of:

These two proposals constitute the principles of component-ontological representation of function. We will illustrate how such a representation may be used for modelbased diagnosis. However, diagnostic reasoning is not the focus of this paper—we have discussed it in detail elsewhere.10 In the following discussion, for generality, we use the term ‘environment’ in lieu of ‘context’, and it may be understood to mean ‘the embedding device’ for components in a device.

In Fig. 1 the function model of C 1 will include not only the function of component C 1 with respect to its ports i 11, i 12 and o 11, but also the functions of ports i 11, i 12 and o 11 with respect to C 1. We refer to this as the dual nature of function representation.

2.1 Generalization/specialization

2.3 Function of a component

Function is an abstraction of behavior. Function may be expressed as a conjunction of predicates, each of which qualitatively describes incremental behavior of a device, e.g. the function of a distributor in an automobile ignition

Observation 1. A component designed to carry out a function f can also carry out functions which are more generalized than f, but not functions which are more specialized than f.

• •

the function of the component with respect to its ports, and the function of its ports with respect to the component.

Fig. 1. Defining the functions of components and subsystems.

Component-ontological representation of function Explanation: Let a component C be designed to carry out a function f ¼ P1 ∧ P2 ∧ … ∧ Pn where P i are predicates. Case 1: In a specific environment, say another function f1 ¼ P1 ∧ P2 ∧ … ∧ Pn ¹ 1 is to be met, where f 1 is generalized with respect to f (by definition). By disabling the incremental behavior P n, the component C may be configured to meet the requirement of the environment. Case 2: In a specific environment, say another function f2 ¼ P1 ∧ P2 ∧ … ∧ Pn þ 1 is to be met, where f 2 is specialized with respect to f (by definition). Usually, owing to economy of design, the component C cannot be used to meet the function f 2 unless additional hardware is incorporated into it to implement P nþ1. Usually, the function for which a component is designed ends up being the most specialized function that the component can carry out. The function for which a component is designed is the function of the component with respect to its own ports. All the other functions which the component fulfills in specific environments may be expressed as generalizations of this function. Therefore: Observation 2. The function of a component in an environment can be expressed as a generalization of the function of the component with respect to its ports. So, assume that we can ignore the function of a component in its current environment, and instead, model its function with respect to its own ports. The advantage of such a model is that only one function model suffices for a component, and this model can be re-used in any environment. Such a model is acceptable if and only if correctness of reasoning with the model can be guaranteed. We will analyze this claim in a later section. Assuming for the moment that correctness of reasoning can indeed be guaranteed, we generalize our discussion so far as follows: Principle 1. The function of a component in any environment can be expressed in terms of its own ports. e.g. the function of a switch in a table lamp is to turn the lamp on/off. In terms of its ports, the function of a switch is to control what flows through its ports. Therefore, the function of a switch in a table lamp may be said to be that of control. Two alternative arguments for the above principle are: •

•

A component is connected to its environment through its ports. Its function with respect to its environment is realized through these ports. Therefore, the function of a component with respect to its environment may be rewritten in terms of the function of the isolated component with respect to its own ports. Function is an abstraction of behavior. It is convenient to express function in terms of behavior because computational techniques can be applied to behavior on account of its quantitative nature. Since behavior of a component is specified with respect to its ports, function may also be specified with respect to its ports.

401

Whereas the behavior of a component is represented as a quantitative relationship between the values at its ports, as per principle 1, the function of a component is represented as a qualitative relationship between the component and its ports. For instance, in Fig. 1, the function of C 1 with respect to the embedding device D 1 is expressed in terms of its ports i 11, i 12 and o 11 as shown by the solid arrows. 2.4 Function of a subsystem For proper functioning, a component needs specific inputs at its ports. These inputs, and by association, their corresponding ports, play specific functional roles with respect to the component. The functions of the ports with respect to the component are an integral part of the function model of the component. Function is also associated with subsystems in a device. The term subsystem is used to refer to a modular sub-assembly of causally connected components in a device. (Subsystems are later referred to as signal-lines in the paper.) A subsystem may be structurally encapsulated to form a component. Therefore, from principle 1, the function of a subsystem may be defined in terms of its ports. However, subsystems are not standardized and may vary from one context to another. Therefore, we recast the functions of subsystems in terms of the function(s) of the port(s) of the component(s) to which they are connected. Note that almost every port of every component in a device has a subsystem connected to it. Observation 3. When the output of a component C 1 is connected to the input of another component C 2, the range of behavior (set of possible output values) of C 1 must be a subset of the domain of behavior (set of allowable input values) of C 2 for the composition of C 1 and C 2 to work correctly. Explanation: In Fig. 2, for proper operation, C 2 must be able to accept and process any and all the outputs generated by C 1. In other words, the non-shaded portion of the effective range of behavior b(C 1) must be empty. (Note that the effective range of behavior of a device is the range through which the device is configured to behave in a specific environment. It is a subset of the device’s actual range, e.g. when a transistor is used as an amplifier, it is operated only in its

Fig. 2. Subsumption in the direction of causality.

A. N. Kumar et al.

402

linear range, which is its effective range.) Therefore: Range(b(C1 )) # Domain(b(C2 )) Therefore, in order to quantify the causal effect of C 1 on C 2, it is sufficient to consider the domain of C 2. Now, if C 1 is a boundary component in a subsystem S, the function of subsystem S is subsumed by the function of port i of C 2. The function of port i with respect to the component C 2 is an abstraction of the relationship between the input received at port i and the behavior of C 2. Hence, the following principle: Principle 2. The function of a subsystem in a device can be expressed as the function(s) of the port(s) of the component(s) to which it is connected. Referring back to Fig. 1, the function of the subsystem S 1 consisting of the components C 1 and C 2 may be specified as the function of port i 32 (of C 3) with respect to C 3. 2.5 Component-ontological representation The function of a component is dependent on its environment. However, it follows from principles 1 and 2 that the function of a component can be modeled as a combination of: (1) the function of the component with respect to its own ports; (2) the functions of ports of the component, with respect to the component: this recasts the functions of subsystems connected to those ports. Since the function of a component can be modeled in terms of the component itself, this model can be specified in isolation of the environment of the component. Therefore, it can be compiled into a library. It need not be built dynamically, on demand, but instead, may be retrieved from the library and re-used as necessary. The model can also be reused in other dissimilar environments if we can guarantee that it will not affect the correctness of reasoning—a task we will take up later in the paper. Since function is represented in terms of ports of a component (as opposed to states or processes in it), principles 1 and 2 form the basis of component-ontological representation. Whereas function models of atomic components may be retrieved from a library, the function model of a composite device can be built by composing the function models of its components, as follows: •

•

First, subsystems in the device are identified. Each subsystem’s functions are determined as the functions of the ports of the components to which the subsystem is connected. Within each subsystem, the function of each component is determined as the function of the component with respect to its own ports through which it is connected to the subsystem.

The italics above refer to the two parts of the component-

ontological function models of the composed components. The above steps may be recursively applied at all the levels of structural hierarchy in a device. This ability to compose the function models of components is an advantage inherent to component-ontological representation. Composability also implies that the representation task can be automated.11 2.6 Device-independence of model-based reasoning We now argue that composability of models is not only desirable but also required in model-based reasoning. One claimed advantage of model-based reasoning over rule-based reasoning is that it is domain- and device-independent, and hence, general. The basis for this claim does not lie in the reasoning techniques because reasoning techniques used in both model-based reasoning (constraint suspension, dependency tracing, etc.) and rule-based reasoning (deduction, forward/backward chaining) are domain-independent. The claim cannot be explained based on the representation of knowledge either: diagnostic rules used in rulebased systems are device-specific, but so are device models used in model-based systems. The distinguishing factor is the nature of the knowledge used: device knowledge, and hence, the models used in model-based systems are composable in nature, i.e. the model of a device can be built by composing the models of its components. But, diagnostic knowledge used in rule-based systems, i.e. associations between symptoms and faults are not composable, i.e. diagnostic rules cannot be derived for a device by composing the rules of its components. In a model-based system, component models are stored in a library. When a new composite device is considered, its model is built by composing the models of its components retrieved from the library. On the other hand, when a new composite device is considered in a rule-based system, the rules pertinent to the device must first be collected. These rules cannot be composed from the rules of the components of the composite device. Therein lies the generality of model-based systems vis-a`-vis rule based systems. Observation 4. Model-based reasoning is domain and device-independent compared to rule-based reasoning only insofar as the device knowledge, i.e. the model it uses is composable in nature. Since composability is one of the primary advantages of model-based systems over rule-based systems, a representation may be considered to be adequate for modelbased reasoning only if it is composable. Hence, the principle: Principle 3. Representation of function must be composable to ensure domain and device-independence of modelbased reasoning systems. Component-ontological representation is composable. Therefore, it is adequate for model-based reasoning.

Component-ontological representation of function 2.7 Accounting for context sensitivity of function By nature, function is context-sensitive. Therefore, the function model of a component can be expected to defy re-use except in the context for which it was built. However, we had earlier proposed to build a re-usable function model of a component by representing its most specialized function, which is its function with respect to its own ports. We had argued that any function a component can assume in a particular context is a generalization of the function of the component with respect to its own ports. Now, we need to prove that even when the function assigned to a component’s model is more specialized than the current function of the component in its environment, the correctness of reasoning is ensured. Explanation: Let the current function of a component C in a device in which it is embedded be: f1 ¼ P1 ∧ P2 ∧ …Pn where P i are predicates which qualitatively describe incremental behaviors of the component. Let the function represented in the component’s model be f 2. If f 2 is more specialized than f 1, by definition 1, it includes at least one additional conjunctive predicate P nþ1: f2 ¼ f1 ∧ P n þ 1 Failure of any of the predicates P1 , …, Pn þ 1 results in a symptom. Therefore, function f 2 fails whenever f 1 fails. But, the reverse is not true. It follows that, during diagnosis, component C is suspected in a larger number of cases (symptoms) if f 2 is assigned to it than if f 1 is assigned to it, and these cases include all the cases of f 1. In other words, if f 2 is the function assigned to a component and it is more specialized than the actual function f 1 of the component in its current context, the component will never be hypothesized to be fault-free when it is faulty (cases P1 , …, Pn ), but it may be hypothesized to be faulty when it is fault-free (case P nþ1). This ensures the correctness of diagnostic reasoning, although the reasoning is inefficient because component C is suspected even in cases (P nþ1 above) which are not warranted by its actual function f 1. As an illustration, consider an electric switch. Its function may be written as: f2 ¼ convey¹electricity ∧ enable¹regulation(on=off): In a table lamp, the switch may be rigged to be constantly on. Its function is then: f1 ¼ convey¹electricity: If f 2 is used as the function model of the switch, when diagnosing the table lamp, the switch will be suspected when any of the following symptoms is observed: • • •

no electricity flows through the lamp; the lamp cannot be turned on; the lamp cannot be turned off.

On the other hand, if f 1 is used as the function model of

403

the switch, the switch will not be suspected in the last case above. We have the following propositions so far: •

• •

the correctness of reasoning is ensured even if the function model assigned to a component is more specialized than the actual function of the component in its current context; the most specialized function of a component is its function with respect to its own ports, i.e. its designed function; the functions a component can carry out in various contexts are all generalizations of the function of the component with respect to its own ports.

It follows that: Principle 4. If a single function model must be re-used in various contexts for a component, the correctness of reasoning can be ensured in all the contexts by modeling the function of the component with respect to its own ports. The applications of function have been categorized into three groups: discriminatory, motivational and explanatory.12 Although our discussion so far has been specific to diagnosis which is a discriminatory application, principle 4 applies to motivational and explanatory applications as well. We will consider design, which is a motivational application, and consider two cases in it. Once again, let f 1 and f 2 be two functions that a component can assume, f 2 being a specialization of f 1. •

•

Case 1: If f 1 is the model used and f 2 the desired function in a context, the component will be considered inadequate for the context since its model does not account for P n þ1. Case 2: If f 2 is the model used and f 1 the desired function in a context, the component may be used in the context after being configured to serve f 1 by disabling P nþ1. However, this design is not optimal, since the component has more functionality than is required for the context.

Therefore, if the most specialized function is modeled for a component, it can be guaranteed that during design, the component will not be eliminated from consideration in the contexts where it can be used. We can similarly argue the correctness of reasoning in explanatory applications of function (such as explanation generation) as well. In summary, if the model of a component represents the function of the component with respect to its own ports: (1) the correctness of reasoning is ensured in any context; (2) the same model can be re-used in different contexts despite the context-sensitive nature of function; (3) hence, the model can be compiled into on-line device libraries and re-used: it need not be built anew for each new context. This saves a considerable amount of time and effort during device representation.

A. N. Kumar et al.

404

This is the basis as well as the merit of component-ontological representation of function. Note that the component-ontological function model of a device is built in terms of the ports of the device and is determined from its design. It is not subjective: the model will not differ from one modeler to another. Hence, the competency of component-ontological representation can be evaluated more easily than that of state-based representations where the choice of states is left to the discretion of the modeling engineer.

3 CLASSES

We propose Classes as a computational model for function based on the component ontology principles discussed in the previous section. In Classes, we propose primitives called functors for the representation of: • •

the functions of components with respect to their ports; the functions of ports with respect to their component. These are also the functions of subsystems (called signal-lines) in the device.

In order to make Classes domain-independent, we use flow ontology: •

•

•

(1) Producer: produces the signal S. Its function is fp (x) ¼ S where either x ¼ B , i.e. input is non-existent, or the element of x is different from that of S, e.g. solar cells produce electrical signal from solar energy input. (2) Consumer: consumes the signal S. Its function is ft (S) ¼ y where either y ¼ B , i.e. the device has no output corresponding to the input signal S, or the element of y is different from that of S. In the latter case, the consumer transduces between the two elements, e.g. speakers consume electrical signal to produce sound. (3) Control: modifies the signal S. Its function is fc (S, C) ¼ S9 where the modification of S to S9 is dependent on an optional input C. If C exists, the component is a consumer with respect to it, e.g. a transistor amplifies an electrical signal. (4) Address: chooses among several signal-lines Y i for an input signal S or among several input signals S i for a signal-line Y. The chosen signal is conveyed unmodified. Address component’s function may be written as either of

Causal interactions in a device are expressed in terms of effort for and flow of energy, matter and information.13 For instance, flows of gasoline, air and electricity interact in automobile engines. Gasoline, air and electricity are flows of energy/ matter in distinct forms. Each such distinct form of flow is termed an element. A signal is defined as a causal flow of energy, matter or information in a device. By definition, a signal is restricted to only one element in a device. Several signals may co-exist in a device. A signal-line is defined as the sequence of components from the origin to the use of a signal in a device. For instance, a signal-line for information flow in a publishing company is the sequence of components: author, editor, typesetter, proofreader and printer. Every component in a signal-line causally contributes to its signal. Signal-lines in a device represent subsystems in it. A component may belong to different signal-lines with respect to its different ports.

3.1 Device/component functors The functor of a component is defined with respect to its ports. Definition 2. The functor of a device/component with respect to a signal S at its port is defined as follows (see Fig. 3):

Fig. 3. Functors of components and signal-lines.

Component-ontological representation of function the following (or a combination of both): fa (S, A) ¼ S ¼ Yi fa (Si , A) ¼ Y ¼ Si where Y is a signal at the output, and the value of i is determined by the address input A. Input A is optional. If it exists, the component is a consumer with respect to it, e.g. the distributor in an automobile ignition unit selects one of many cylinders to deliver sparks. (5) Data: transports the signal S unmodified. Its function is fd (S) ¼ S e.g. the fuel pipe in an automobile transports fuel. (6) Store: behaves as a repository for the signal S. Its function is fs (Sto ) ¼ Sto þ t for some time instant t o and elapsed time t $ 0. It may also have an optional input which controls the storage of signal S. This input, if it exists, enables the component to write and/or read the signal, e.g. memory chips are store components. It is not necessary that all the above functors occur in every signal-line. However, every component in a signalline must be classifiable as at least one of the above functors. A component may be a different functor with respect to its different ports, as seen in the definitions of address and control functors. A component may also be a combination of functors with respect to a single port. For instance, memory chips are a combination of store and address functors. 3.2 Functors of signal-lines The functor of a signal-line is defined as the function of the port(s) of the component(s) to which it is connected. Definition 3. The functor of a signal-line connected to an input of a device/component D is defined with respect to D. Let x be an input, y an output and b the behavior of device D (see Fig. 3). (1) Power signal-line p is the input necessary to realize the behavior b of the device. If p ¼ 0, b is not realized and y cannot be observed, e.g. the power cord of an electrical device is part of its power signal-line. (2) Clock signal-line t is the input used by D to delay, time or synchronize its output y. The behavior of D may be expressed as: b ¼ b9(t), i.e. b is some function of the temporal input t, e.g. the timer in a toaster is part of its clock signal-line. (3) Control signal-line c provides control input to a control component, i.e. D obtains its output y by modifying its input x according to the input c. In other words, y ¼ b(x,c), e.g. the idle speed screw in an automobile carburetor is part of a control signal-line connected to its throttle.

405

(4) Address signal-line a provides address input to an address component, i.e. D selects its output y from among its several inputs x i or channels its input x to one of its several outputs y i based on the input a. In other words, b(x i,a) ¼ y ¼ xi or bðx; aÞ ¼ x ¼ yi , where the value of i is dependent on a, e.g. in an automobile distributor, the electronics which controls the firing sequence constitutes an address signal-line. (5) Data signal-line d is the input that D was designed to process (to control, address, store, etc.), i.e. d ¼ x itself. y is the corresponding data output of D, e.g. fuel–air mixture is one of the data signal-lines connected to an automobile engine. A signal-line may serve different functors with respect to different components. For instance, a signal-line may provide data input to a device D1 and control input to another device D2. A device consumes all of its inputs except data. The only input corresponding to which a device has an output is data. Data input is the signal that is modified by a control component, redirected by an address component, and transported to the corresponding data output (unmodified) by a store/data component. The proposed function primitives are typical of component-ontological representation (irrespective of the domain), but are not claimed to be comprehensive. Our objective is to demonstrate the merit of component-ontological representation using Classes, rather than to promote any particular choice of function primitives. Other suitable primitives may be included in our computational model and used for function-based reasoning. One excellent source of function primitives is Living Systems by J. G. Miller.14 Among the primitives proposed by the author for processing matter and energy are: distributor, converter, producer, storage, reproducer, boundary, ingestor, extruder, motor and supporter. While choosing primitives for an application, it is important to ensure that they are adequate for the representation of all the devices in the domain. Further, they must be sufficiently dissimilar to support function-based reasoning. We illustrate Classes by using it to model a printer buffer in Section 4 and by using it to diagnose the printer buffer in Section 5. 3.3 Complexity of class representation The function model of a component consists of: • •

a functor label for the component with respect to each of its ports; a functor label for each port with respect to the component.

Hence, if a component D has m input and n output ports, the function model of the component consists of 2(m þ n) functor labels. The space complexity of the function model is O(m þ n), i.e. linear in the number of ports. This complexity applies to all atomic components as well as components at the floor level of representation11 in a device.

A. N. Kumar et al.

406

If a composite device D9 has m9 inputs, n9 outputs and p components in it, we estimate an upper bound on the number of signal-lines in it as: z þ kp where • •

z is the number of data signal-lines connected to its inputs and outputs; k is the maximum number of signal-lines other than data (e.g. power, clock) that may be connected to (the ports of) each component in the device. The value of k is determined by the number of functors defined for signal-lines in Classes, and is a constant. k ¼ 4 for the set of functors we have proposed in this paper.

The value of z depends on the topology of the device: •

If the device has neither fan-ins nor fan-outs, in the worst case, a signal-line is connected to each input and output port of the device. Hence, z ¼ m9 þ n9. • If the device has only non-reconvergent fan-ins and fan-outs, no two signal-lines originate as well as terminate at the same ports. In the worst case, there is one data signal-line between every possible pair of input and output ports. Hence, z ¼ m9n9. • If the device has reconvergent fan-outs, z may be exponential in p. Assume the device has a topology which can be partitioned such that components in each partition get their inputs from components in earlier partitions, and provide inputs to components in later partitions. Components in the earliest partition get their inputs from the inputs of the device and components in the last partition generate the outputs of the device. We can impose such a linear order among components and their partitions because of subsumption in the direction of causality as argued in Section 2, and encapsulation of feedback loops. In order to calculate the number of reconvergent fan-out signal-lines possible in a device, we choose all possible sequences of components, such that exactly one component is selected from each partition. If there are l partitions in a device, in the worst case, the number of data p signal-lines in it is z ¼ ðd :eÞl , i.e. z is exponential in p. l Hence, in most cases, the relationship between the number of signal-lines in a composite device and the number of

components in it is linear. Therefore, the space complexity of its function model is also linear. This compares favorably with the space complexity of state-based representations, which is exponential because of the exponential number of states in a device. Elsewhere, it has been shown that the time required to build the model of a complex device from those of its components is also linear in the number of components in the device.15 Moreover, this process can be automated, which helps preserve the fidelity of representation. 4 ILLUSTRATION: THE PRINTER BUFFER The Heathkit printer buffer receives files from a computer, stores the files if necessary, and prints them when the printer is free. It has serial and parallel input and output ports, and can be interfaced between two computers and two printers simultaneously (see block diagram in Fig. 4). It has the complexity of a microcomputer, and includes a Central Processing Unit (CPU), Random Access Memory (RAM), Read-Only Memory (ROM) and a Light Emitting Diode (LED) display. In the following sections, we describe the class models of a select few units in the printer buffer. The Configuration Switches Unit and the Display Unit were chosen for their relative simplicity, and the Parallel Input Unit and the RAM Refresh Unit were chosen for their complexity. We then list the lessons we learned from modeling the entire printer buffer. We illustrate diagnosis using the class model of the Display Unit of the printer buffer. 4.1 The configuration switches unit The Configuration Switches Unit enables the user to set communication parameters. It consists of Tri-state Buffers, a 3-to-8 line Decoder/Demultiplexer, switches and a CPU. The class model of the Configuration Switches Unit is shown in Fig. 5. The user can manually configure the switches to set communication parameters such as baud rate, word length, parity status (on/off), parity (odd/even), number of stop bits, and handshaking and its polarity. An open switch outputs 1 and a closed switch outputs 0. CPU reads the settings of these switches through three Tri-state Buffers as follows: it outputs address A0-A2 which is used by Decoder to select a particular Buffer. When the selected Buffer also receives a

Fig. 4. Block diagram of the Printer Buffer.

Component-ontological representation of function low RD signal from CPU, it loads the settings of the 8 switches connected to its input, i.e. one byte of data on to the data bus D0-D7 for CPU to read. The signal-lines in the class model of the Configuration Switches Unit shown in Fig. 5 are: • • •

• •

CPU is the producer of signal I=OE consumed by Decoder. This is a control signal-line with respect to Decoder. CPU produces signal A7 which is consumed by Decoder. This is also a control signal-line with respect to Decoder. Signal A0-A2 is produced by CPU. Decoder is an address component with respect to this signal. Buffers are consumers of this signal in the form of their I=O input. The signal-line CPU–Decoder–Buffer is a control signal-line with respect to the buffers. RD signal produced by CPU is consumed by the buffers. This is also a control signal-line with respect to the buffers. Supply Voltage is the producer of a signal which is controlled by manual switches Switch10-17, Switch20-27 and Switch30-37. Buffers act as control/store components of the signal and CPU consumes it through data bus D0-D7. The resulting signal-line Supply Voltage–Switch–Buffer–CPU is a data signal-line with respect to CPU.

407

This signal-line actually refers to three different signallines passing through Switch10-17, Switch20-27 and Switch30-37. In this discussion, for simplicity, we have dropped the device suffixes to obtain one name that stands for all the three signal-lines. Technically, this signal-line is a control signal-line with respect to CPU because CPU decides which software routines to use for communication, based on this signal. However, since we are not modeling the software of the printer buffer, we ignore this subtlety. 4.2 The parallel input unit The Parallel Input Unit receives files from the computer in parallel. It consists of CPU, Schmitt Trigger Inverter, Resistor Pack (RP), D Flip-Flops, OR gate, Monostable Multivibrator and Decoder. It receives data through inputs D0-D7 and uses Strobe, BUSY and ACK signals for handshaking. The class model of the Parallel Input Unit is shown in Fig. 6. When a computer wants to send data to the printer buffer in parallel, it checks the BUSY and ACK signals issued by the Parallel Input Unit. If BUSY signal is high, the computer waits. Otherwise, if ACK signal is low, the computer sends one byte of data in parallel on inputs D0-D7 and pulses the Strobe line low. This Strobe line in inverted form is used by D Flip-Flop2 (D FF2) to latch the data present on inputs

Fig. 5. Class model of the Configuration Switches Unit.

408

A. N. Kumar et al.

D0-D7. The same inverted Strobe is used by D Flip-Flop1 (D FF1) to issue a high BUSY signal. CPU reads the data stored in D Flip–Flop2 by selecting it with a low OE input. The low OE is generated as a conjunction of a low RD signal issued by CPU and a low I=O4 signal generated by Decoder as described before in the Configuration Switches Unit. CPU transfers the data from D FlipFlop2 over the data bus D0-D7 to its RAM Unit. After the transfer, it unselects D Flip-Flop2 by raising its OE input to 1. This rising signal triggers Monostable Multivibrator into issuing a low pulse of fixed duration. This is the low ACK pulse which signals that the Parallel Input Unit is ready to accept a new byte of data. This signal is used by D FlipFlop1 to reset BUSY signal to 0. The class model of the Parallel Input Unit shown in Fig. 6 consists of the following signal-lines: • Resistor pack (RP) is a data component with respect to input signal D0-D7. This signal is stored by D Flip-Flop2 (D FF2) and consumed by CPU. The resulting signal-line RP–D Flip-Flop2–CPU is a data signal-line with respect to CPU. • Strobe input is controlled by Schmitt Trigger Inverter which eliminates noise. It is consumed by D Flip-Flop1 and D Flip-Flop2. It is a clock signalline with respect to the D Flip-Flops. • RD signal is produced by CPU and consumed by OR gate. It is a control signal-line with respect to OR gate. • The signal-lines necessary to generate I=O4 signal have been described as part of the Configuration Switches Unit in Section 4.1. Decoder is an address component with respect to this signal. OR gate controls the signal and D Flip-Flop2 consumes it. The

•

•

•

•

•

resulting signal-line CPU–Decoder–OR–D FlipFlop2 is a control signal-line with respect to D Flip-Flop2. It enables D Flip-Flop2 to output on to the data bus D0-D7 the data it has latched (but does not affect the latching itself). The output of OR gate is also consumed by Monostable Multivibrator. The resulting signal-line CPU–Decoder–OR–Monostable is a control signal-line with respect to Monostable Multivibrator. ACK signal is produced/controlled by Monostable Multivibrator and output by the Parallel Input Unit. Monostable Multivibrator controls production of the signal based on its inputs B, A and CLR. ACK signal is also consumed by D Flip-Flop1 and is a control signal-line with respect to it. A and CLR inputs are consumed by Monostable Multivibrator. They are control signal-lines with respect to it. Note that, the resistor and capacitor which fix the duration of ACK pulse have been structurally encapsulated16 into Monostable Multivibrator in this model. BUSY signal is produced through Supply Voltage (5 V) connected to D input of D Flip-Flop1. It is stored/controlled by D Flip-Flop1 and is output by the Parallel Input Unit. D Flip-Flop1 uses CLR and PR inputs to control BUSY signal and is a consumer of these two signals. In addition, the Parallel Input Unit has three Jumpers connected to ‘Paper Empty’, ‘Printer Selected’ and ‘Error’ output signals. The Jumpers are manually switched address components which connect either 5 V or Ground to these output signals. They have not been shown in the figure.

Fig. 6. Class model of the Parallel Input Unit.

Component-ontological representation of function 4.3 The RAM dynamic refresh unit The RAM Unit stores the files sent by the computer(s) until they can be printed on the printer(s). The printer buffer comes with two options: either 8 RAM chips are interleaved to provide 64 Kbytes or 16 RAM chips are interleaved to provide 512 Kbytes of memory. Multiplexers are used to address the chips properly in either case. In the following discussion, the printer buffer is assumed to have 512 Kbytes of RAM. For simplicity, the RAM Unit is split into two parts: the Address Decode Unit and the Dynamic Refresh Unit. The Address Decode Unit accesses individual locations in RAM. The Dynamic Refresh Unit periodically rewrites the contents of RAM chips. Rewriting is necessary to prevent the dynamic RAM chips from gradually losing their contents owing to leakage. The Dynamic Refresh Unit consists of RAM chips, D

409

Flip-Flops, Schmitt Trigger Inverters, 3-input NAND gates and CPU. Schmitt1, Schmitt2, D Flip-Flop1 (D FF1) and NAND1 refresh the lower 8 RAM chips RAM1, …, RAM8, and are described here. The class model of the Dynamic Refresh Unit is shown in Fig. 7. The lower 8 RAM chips are refreshed when their CAS input is low. Whenever E signal generated by CPU is low, outputs of D Flip-Flops, and hence, CAS inputs of the RAM chips are set to 1, thereby disabling RAM refresh. CAS signal is set to 0 only when all of the following occur: ROM Decoder output is 1; REFRESH output of CPU is 1; Address bit A18 produced by CPU is 1; E signal produced by CPU is 1; and D signal produced by CPU makes a transition from 1 to 0. When all these signals are present, NAND1 outputs 0, which is input to D Flip-Flop1. D Flip-Flop1 sets its output connected to CAS inputs of RAM chips to 0, thereby enabling RAM refresh. Following are the signal-lines in the class model of the

Fig. 7. Class model of the RAM Dynamic Refresh Unit.

A. N. Kumar et al.

410

4.4 The Display Unit

Dynamic Refresh Unit (see Fig. 7): • •

•

•

•

•

Signal E produced by CPU is consumed by D FlipFlops. This is a control signal-line with respect to the D Flip-Flops. CPU produces signal D which is controlled by Schmitt1 Inverter. D Flip-Flops are consumers of this signal. The resulting signal-line CPU– Schmitt1–D Flip-Flop is a clock signal-line with respect to the D Flip-Flops. CPU produces signal A18 which is controlled by Schmitt2 Inverter and consumed by NAND1. The signal-line CPU–Schmitt2–NAND1 is a control signal-line with respect to NAND1. Output of the ROM Decoder is consumed by NAND1 gate. The resulting signal-line CPU– ROM Decoder–NAND1 (not shown in the figure) is a control signal-line with respect to NAND1. CPU produces REFRESH signal, which is controlled by NAND1. NAND1 controls the signal based on its inputs from ROM Decoder and Schmitt2 Inverter. D Flip-Flop1 is a store/control of this signal. The lower 8 RAM chips are consumers of the signal in the form of their CAS input. The resulting signal-line CPU–NAND1–D FlipFlop1–RAM is a control signal-line with respect to the RAM chips because it controls the refreshing of their contents. Without it, the RAM chips would lose all their contents. CLR inputs of the D Flip-Flops are control signals consumed by the D Flip-Flops.

The Display Unit consists of three LEDs and a Swap Diode. Each LED in turn consists of a 7-segment display and a decimal point (DP). The amount of memory available in the printer buffer is displayed on the LEDs. Swap Diode lights up when serial and parallel ports are crossed by pressing the ‘swap panel button’. CPU loads the information that must be displayed on each LED in its corresponding Buffer. The contents of each Buffer (say, Buffer1) drive the corresponding LED (LED1). In order to change the contents of Buffer1, and thereby, the display of LED1 and/or Swap-Diode: • • • •

Following are the signal-lines in the class model of the Display Unit (see Fig. 8, where, for clarity, only one set of Buffer, RP and LED are shown): •

Additional signal-lines necessary to refresh the higher eight RAM chips RAM9, …, RAM16 are: • •

CPU produces signal A18 which is consumed by NAND2. This input is a control signal-line with respect to NAND2. Again, CPU–NAND2–D Flip-Flop2–RAM signalline is a control signal-line with respect to the higher 8 RAM chips.

CPU selects Decoder through A7 and a low I=OEnable(I=OE), and issues the address appropriate for Buffer1 on A0-A2; Decoder decodes A0-A2 to issue a low I=O1, which in turn selects Buffer1; CPU puts the new information to be displayed on D0-D7 and forces Buffer1 to store it by issuing a low WR signal; Buffer1 drives LED1 through Resistor Pack RP1 to display the new information.

•

CPU produces D0-D7, which is stored/controlled by the buffers, transported by RPs and consumed by LEDs and Swap-Diode. Each Buffer controls D0D7 based on WR signal from CPU. CPU–Buffer1– RP1–LED1 is a data signal-line with respect to LED1. Other such signal-lines are CPU–Buffer2– RP2–LED1 with respect to input DP of LED1, CPU–Buffer1–RP1–Swap Diode, CPU–Buffer2– RP2–LED2, CPU–Buffer3–RP3–LED2 and CPU–Buffer3–RP3–LED3. CPU is the producer of WR signal consumed by the buffers. This is a control signal-line with respect to the buffers.

Fig. 8. Partial Class model of the Display Unit.

Component-ontological representation of function • •

CPU is the producer of I=OE and A7 signals which are consumed by Decoder. These are control signallines with respect to Decoder. CPU is the producer of A0-A2 signal, Decoder is an address component with respect to it, and Buffers are consumers of the signal in the form of their I=O input. The signal-line CPU–Decoder–Buffer is an address signal-line with respect to the buffers.

necessary first to develop their semantics, which can then be used during reasoning, e.g. all the signal-lines that have now been classified as control and provide SEL inputs to components (e.g. to Decoder in the Configuration Switches Unit) may be re-classified as switch signal-lines. •

4.5 Modeling observations We have modeled an automobile carburetor and an electrical doorbell in addition to the printer buffer using Classes. Whereas the printer buffer was meant to test the scalability of Classes, the carburetor was used to test how well Classes could be used for transdomain devices, i.e. devices with multiple elements. Following are some of our observations/experience using Classes to model these devices: •

•

Most of the signal-lines were found to be short, comprised of not more than 4–5 components, excluding data components. Several signal-lines were trivial, involving only a producer and a consumer, such as I=OE signal in the Configuration Switches Unit (Fig. 5). Many control components were found to have more than one control input, e.g. Monostable Multivibrator in the Parallel Input Unit (Fig. 6) and NAND1 gate in the RAM Dynamic Refresh Unit (Fig. 7). Several store components were found to have inputs which controlled their read/retrieve and write/save operations, e.g. D Flip-Flop2 in the Parallel Input Unit (Fig. 6). Some components belonged to more than one functor with respect to a single port, e.g. in the Parallel Input Unit, Monostable Multivibrator is a producer/control with respect to its ACK output and D Flip-Flop1 is a control/store with respect to its BUSY output. It was found too restrictive to classify all the components/signal-lines which modify inputs to generate outputs as control components/signal-lines. For instance, we modeled both PR and CLR inputs of D Flip-Flop as control signal-lines (e.g. Parallel Input Unit, Fig. 6). However, it is desirable to discriminate between these two inputs: PR sets the output of a D Flip-Flop to 1, whereas CLR resets it to 0.

Some specializations of control functor which may also be used in Classes are: • • • • •

Attenuator: reduces the magnitude of its input signal. Amplifier: increases the magnitude of its input signal. Switch: transports or inhibits its input signal depending on its control signal. Modulator: encodes a carrier signal with information. Demodulator: decodes information from a modulated carrier signal.

In order to include these functors in Classes, it is

411

An advantage of component-ontological representation is that the function model of a device can be built from the function models of its components. On top of such a model, it was found helpful to use overlays of component functions based on behaviors of aggregates of components in a given device.

For instance, in the Display Unit of the printer buffer (Figure 8) the ensemble of the three buffers and Decoder acts as an address component overlay, although the buffers themselves are only control/store components: Decoder selects one among the three buffers to store input from CPU. Modeling this address overlay aids in diagnosing the Display Unit. Similarly, the aggregate of three buffers and Decoder in the Configuration Switches Unit (Fig. 5) may be modeled as an address component overlay. Since these overlays are dependent on the functions carried out not by individual components but rather by aggregations of components in a device, they must be hand-coded, and cannot be compiled into component libraries. •

It was found that domain expertise is necessary to build the function model of a device when the Class models of its components are ambiguous. For instance, a three-input NAND gate can be a control component with respect to any one of its inputs, the other two being its control inputs. Therefore, in the RAM Dynamic Refresh Unit (Fig. 7) domain expertise was required to determine that NAND1 is a control component with respect to REFRESH signal, and not its inputs from ROM Decoder or Schmitt2.

5 MODEL-BASED DIAGNOSIS Function in the form of Classes may be used for diagnostic reasoning in either of the following approaches: •

•

in the classical approach involving constraint suspension/propagation and backtracing, it may be used to discriminate among the generated candidates. In this approach, function facilitates generation of explanation during diagnosis10; in consistency-based approach,17 it may be used to partition components18 based on their likelihood of failure.10

In the rest of this section, we will briefly describe the first approach. A more detailed discussion of diagnosis using Classes and its merits is provided elsewhere.10 During representation in Classes, functor labels are

A. N. Kumar et al.

412

affixed to components and their ports. During diagnosis, function in the form of these labels is used to discriminate among suspects. The basis of this discrimination is abduction. Functor labels may be used to discriminate among suspects in several ways, two of which are:15 •

•

functors are associated with typical symptoms or abstractions of symptoms in a domain. When diagnosing a device in the domain, its components with functor labels corresponding to the observed symptom(s) are suspected first. depending on the nature of device failures in a domain, functors are ordered by their likelihood of giving rise to failures in devices in the domain.

In the following discussion, we use the latter approach to diagnose electrical devices. •

•

Based on the reliability rule that ‘the greater the specialization of a component, the greater its complexity, and hence, the greater the chances that it will break down’, the (partial) order among functors of components is producer and consumer, control, address and store, and data. Based on the reliability rule that ‘the more specialized the functor of a signal-line, the fewer the components in it; the more the components in a signalline, the greater the chances of a fault lying in it’, the (partial) order among functors of signal-lines is data, control and address, and power and clock.

Note that we use our function models as supplements (and not alternatives) to the traditionally used structure and behavior models of a device. The function-based reasoning algorithm to diagnose a device with a single fault is given below: Algorithm 1. Given the Class model of a device D, and a symptom S at its output O, diagnosis proceeds as follows: (1) All the signal-lines that end in output O are listed. Let the list be SL. (2) The signal-lines in SL are ordered by the order of their functors. Let the ordered candidate-list of signal-lines be SR ¼ (S1 , …, Sm ). (3) The following steps are applied to the first signalline S 1 [ SR. If S 1 is found to be fault-free, the algorithm backtracks to consider S 2 [ SR, and so on. If necessary, the algorithm backtracks until all the signal-lines in SR have been considered. (3a) Let the set of components in the signal-line under consideration be CL. (3b) The components in CL are ordered by the order of their functors. Let the ordered candidate-list of components be CR ¼ (C1 , …, Cq ). Candidates in CR may now be validated using function simulation3,6,19 to eliminate candidates that cannot explain the symptom. (3c) The following steps are applied to the first component C 1 [ CR. If C 1 is found to be fault-free, the algorithm backtracks to consider component C 2 [ CR, and so on. If necessary, the algorithm backtracks until all the components in CR have been considered.

(3.c.i) Peripheral diagnosis: All the signal-lines other than S 1 which are connected to the inputs of C 1 are checked. Let AL be the set of these signal-lines. The algorithm is recursively applied from Step 2 onwards to AL sans all the signal-lines that have already been considered by the algorithm. Note that, whereas AL is the set of signal-lines connected to a device at its own level of structural hierarchy, SL is the set of signal-lines within a device at a lower level of structural hierarchy. (3.c.ii) Component diagnosis: If the component C 1 is not atomic or it is not at the desired granularity of diagnosis, it is checked for fault recursively at a lower level of structural hierarchy. First, the symptom S9 at the output O9 of the component C 1 which can explain the symptom S at the output O of the device D is computed by constraint suspension.20 Next, the diagnosis algorithm is recursively called, with substitutions S9 for S, O9 for O, and C 1 for D. If C1 is atomic, i.e. it cannot be decomposed into subcomponents, or it is at the desired granularity of diagnosis, the user is prompted for measurements across C 1 in order to test whether it is faulty. The algorithm is scalable to large and complex devices as long as they are represented hierarchically. 5.1 Diagnosing the printer buffer display We illustrate our diagnosis algorithm using the Display Unit of the printer buffer modeled in Section 4.4. The symptom we consider is that the LEDs display an available memory of 338K instead of 333K. The symptom is observed in the 7-segment section of LED1. The algorithm considers the only signal-line connected to the symptom, i.e. CPU–Buffer1–RP1–LED1. It orders the components in the signal-line by the order of their functors. Therefore, the ordered candidate list is: { LED1, CPU, Buffer 1, RP1 }. Since LED1 is a consumer, it is at the top of the list. Since it is an atomic component, measurements are initiated across it by the algorithm. Suppose measurements indicate that LED1 is not faulty. The algorithm backtracks to consider the producer component, i.e. CPU. When CPU is found to be fault-free, the algorithm performs peripheral diagnosis, i.e. it attempts to diagnose the other signal-lines connected to CPU. It suggests that the clock input to CPU may be faulty because it cannot be eliminated on the basis that it is also connected to other, working components. On the other hand, it exonerates the power signal-line through candidate validation by constraint suspension because the power signal-line is also connected to the buffers and Decoder. The next component to be considered in the signal-line is the store, i.e. Buffer1. Since Buffer1 is an atomic component, the algorithm initiates measurements across it. When measurements indicate that Buffer1 is not faulty, the algorithm performs peripheral diagnosis on it. Three signal-lines are connected to Buffer1, i.e. the control signal-line CPU– Buffer1, the address signal-line CPU–Decoder–Buffer1 and

Component-ontological representation of function the power signal-line. The algorithm generates a candidate list of these signal-lines ordered by the order of their functors. The algorithm considers the control signal-line first in this list, although perfunctorily since CPU has already been eliminated. It considers the address signalline next, in which it suspects Decoder first. Measurements across Decoder indicate that it is indeed faulty: it failed to select Buffer1; Buffer1 did not register the new input (the unit 3 of 333K) from CPU; and Buffer1’s random contents were displayed on the 7-segment section of LED1. Note that the algorithm is exhaustive—eventually, it considers all the components in a device which are causally connected to the symptom. It considers suspects for measurement in the order of their functional relevance (as specified by functors) to the symptom. Finally, it ‘traverses’ a device along the interconnected signal-lines identified in the device. Therefore, the order in which it considers suspects for measurement can be explained on the basis of causality in the device. 5.2 System implementation The diagnostic system is implemented in Common Lisp. Components and devices are represented as s-expressions in LISP. The structure and function of devices are modeled using slot-filler representation.21 Generic properties of a device are stored separately from specific properties. For instance, the library file for AND gates stores generic properties such as the behavior of AND gates, number of ports, etc. The specific file of an AND gate stores such details as the instance of the chip in which it is housed. Simulation and inference behaviors of devices20 are represented procedurally using LISP functions rather than declaratively as in DART22 and GDE.23 Provision is made to store three values for every port of every component: expected value obtained by simulation, validation value obtained by constraint suspension20 and measured value obtained from the user. During diagnosis, values measured at the input and output ports of a device are obtained from the user. Measured values of input ports are also assigned to be their expected values. The device is simulated using expected values of inputs, and expected values are calculated for all the components and output ports of the device. Measured values of output ports are also assigned to be their validation values. Constraint suspension is performed using these validation values. Proceeding from the outputs to the inputs of the device, validation values are calculated for the ports of all the components in the device. These values indicate how each component could malfunction to generate the symptoms of the device. Components with conflicting validation values are marked for elimination from the candidate list. Finally, functionbased diagnosis is performed as described in the algorithm above.

413

6 BACKGROUND In this section, we briefly review other approaches for function representation. Existing representations of function may be classified as associative, state-based and flowbased. In associative representations, the model of a device is not defined with respect to it or its environment but rather associated with it.2–4 Associative representations are not composable, i.e. the function model of a device cannot be composed from the function models of its components. This is a drawback for model-based reasoning. In state-based representations, function is expressed as an abstraction of behavior states in a device.6–8 An advantage of this approach is that the resolution of representation can be changed to suit the current needs by changing the choice of states. However, if the chosen states are too fine grained, the representation becomes intractable because of the potentially exponential number of possible states. If the chosen states are too coarse, the representation becomes brittle and ineffective during reasoning. The choice of states is often subjective and varies from one modeler to another. Therefore, evaluating the competence as well as limits of competence of state-based representations is difficult. TED7 is a state-based language to represent function for design and diagnosis. Functional Reasoning (FR)24 and Functional Modeling (FM)25 are also state-based representations, wherein, the model of a device consists of its structure and a list of its functions. Each listed function is described in terms of the pre-conditions, postconditions and the behavior used to implement the function. These state-based representations have been adapted by several other researchers.26–28 Causal Functional Representation Language (CFRL)8 is one such extension with rules for clear interpretation of function in terms of behavior. In flow-based representations, function is expressed in terms of flow and effort.13 Our representation is flowbased. Other flow-based representations include FDef29 (which is itself based on earlier work on multiple modeling19,30,31) and MFM.32 The function model used in FDef9,29 consists of functional roles and processes. Functional roles are function primitives such as capacitor, inductor, resistor and ideal conduit. Functional processes include charging, discharging, transportation and transducing. It is not clear whether this representation is composable, because process-ontology is not always modular. This limits the re-usability of the model. In Multilevel Flow Modeling,32,33 function primitives are defined for flows of energy, mass and information. The primitives proposed for mass and energy flows are source, sink, storage, transport, barrier and balance. These primitives are defined in terms of the states in a device in addition to the values at its ports. A set of goals is identified for each device. The function model of a device is associated with its goals by means-end relations called achieve and conditions, which are traversed during reasoning.

A. N. Kumar et al.

414 7 LIMITATIONS AND CONTRIBUTIONS

Classes is a representation of function designed for diagnosis. It is at a coarser level of granularity than state-based representations, and does not support simulation. The effectiveness of applying Classes to diagnose a device depends on the variety and dissimilarity of the functors of its components and signal-lines. Classes may be ineffective for devices in which most of the components have similar functions, e.g. combinational circuits such as the ripple carry adder, where every component is either a data or a store. The diagnosis algorithm will not be able to discriminate between two components with the same functor. In contrast, Classes is very effective for diagnosing devices such as the printer buffer, where a great variety of functors occur. For instance, almost every possible functor occurs in the function model of the Display Unit (Fig. 8). Therefore, Classes can be effectively used to order its components during diagnosis. The above problem observed in some combinational devices may be addressed by defining more specialized functors. However, no matter which functors are chosen, one can always come up with a device, such that most of its components belong to a small subset of the chosen functors. This implies that in such pathological cases, functors may have to be selected depending on not only the domain but also the device at hand. This compromises the utility of Classes as a device-independent computational model for function. Following is a summary of our contributions in this paper: 1. We proposed component ontology as the basis for efficient representation of function for use in model-based diagnosis. We proposed the principles behind componentontological representation. 2. We proposed Classes as a computational model for function based on component ontology. It includes function primitives called functors for components as well as subsystems (signal-lines). By defining functors for components in terms of signal-lines and vice versa, Classes enables systematic traversal of devices during both representation and reasoning. 3. Component-ontological/Class representation has several merits: • •

•

The function of a device can be modeled independent of its environment. Therefore, it can be compiled into on-line libraries, and is re-usable. The representation is composable, i.e. the function model of a complex device can be constructed by composing the function models of its components. Therefore, it is adequate for model-based reasoning, where composability is required of the representation. Composing the function model of a device from the function models of its components helps preserve the fidelity of representation. The representation is in most cases linear in complexity and hence, efficient:

The space complexity of representation of an atomic component is linear in the number of its ports. The space complexity of representation of a composite device is linear in the number of its components. The function model of a complex device can be composed from those of its components in linear time.15 •

The availability of a library of function models of atomic components, and their re-usability and composability result in considerable savings of time and effort during device representation.

4. We have demonstrated the utility of Classes for modelbased diagnosis by using functors to order suspects. The advantage of using function instead of the traditionally used fault probabilities23 for ordering suspects is that function is readily available from the design of a device and can be used to diagnose even novel devices whose fault probabilities are not easily available.10

REFERENCES 1. Bobrow, D. Qualitative reasoning about physical systems— an introduction. Artificial Intelligence, 1984, 24(1-3), 1–5. 2. Milne, R., Diagnosing faults through responsibility. In Proceedings of the Annual Conference of the ACM, New York, 1985, pp. 88–91. 3. Fink, P. and Lusth, J. Expert systems and diagnostic expertise in the mechanical and electrical domains. IEEE Transactions on Systems Man and Cybernetics, 1987, 17(3), 340–349. 4. Steels, L., Diagnosis with a function-fault model. In Causal AI Models, ed. W. Horn. Hemisphere Publishing Corp., New York, 1989, pp. 129–54. 5. Abu-Hanna, A., Benjamins, R. and Jansweijer, W. Device understanding and modeling for diagnosis. IEEE Expert, 1991, 6(2), 26–32. 6. Sticklen, J. & Chandrasekaran, B., Integrating classificationbased compiled level reasoning with function-based deep level reasoning. In Causal AI Models, ed. W. Horn. Hemisphere Publishing Corp., New York, 1989, pp. 191–220. 7. Franke, D. Deriving and using descriptions of purpose. IEEE Expert, 1991, 6(2), 41–47. 8. Iwasaki, Y., Vescovi, M., Fikes, R. and Chandrasekaran, B. A causal functional representation language with behaviorbased semantics. International Journal of Applied Artificial Intelligence, 1995, 9(1), 5–31. 9. Chittaro, L., Tasso, C. and Toppano, E. Putting functional knowledge on firmer ground. International Journal of Applied Artificial Intelligence, 1994, 8(2), 239–258. 10. Kumar, A.N. and Upadhyaya, S.J. Function based discrimination during model based diagnosis. International Journal of Applied Artificial Intelligence, 1995, 9(1), 65–80. 11. Kumar, A. N. and Upadhyaya, S. J., Automating representation. In Working Notes of the AAAI-90 Workshop on Model Based Reasoning, Menlo Park, CA, 1990, pp. 124–30. 12. Kumar, A.N. Function based reasoning. The Knowledge Engineering Review, 1994, 9(3), 301–304. 13. Paynter, H., Analysis and Design of Engineering Systems. MIT Press, Cambridge, 1961. 14. Miller, J., Living Systems. McGraw-Hill, New York, 1978. 15. Kumar, A. N., Component ontological representation of function for candidate discrimination in model based diagnosis. Technical Report 94-32, State University of New York at Buffalo, 1994. 16. Hamscher, W. C., Model-based troubleshooting of digital

Component-ontological representation of function

17. 18. 19.

20. 21. 22. 23. 24.

25.

systems. Technical Report 1074, MIT Artificial Intelligence Laboratory, 1988. deKleer, J. & Williams, B. C., Diagnosis with behavioral modes. In Proceedings of Eleventh International Joint Conference on Artificial Intelligence, 1989, pp. 1324–30. deKleer, J. Using crude probability estimates to guide diagnosis. Artificial Intelligence, 1990, 45, 381–392. Brajnik, G., Chittaro, L., Tasso, C. & Toppano, E., Epistemology, organization and use of functional knowledge for reasoning about physical systems. In Working Notes of Tenth International Workshop on Expert Systems and Their Applications, held in conjunction with Second Generation Expert Systems Conference, Avignon, France, 1990, pp. 53–66. Davis, R. Diagnostic reasoning based on structure and behavior. Artificial Intelligence, 1984, 24, 347–410. Minsky, M. L., A framework for representing knowledge. In The Psychology of Computer Vision, ed. P. H. Winston. McGraw Hill, New York, 1975, pp. 211–77. Genesereth, M.R. The use of design descriptions in automated diagnosis. Artificial Intelligence, 1984, 24, 411–436. deKleer, J. and Williams, B.C. Diagnosing multiple faults. Artificial Intelligence, 1987, 32, 97–130. Sembugamoorthy, V. & Chandrasekaran, B., Functional representation of devices and compilation of diagnostic problem-Solving Systems. In Experience, Memory and Reasoning, ed. J. Kolodner & C. Reibeck. Lawrence Erlbaum & Associates, Mahwah, NJ, 1986, pp. 47–73. Hawkins, R., McDowell, J.K., Sticklen, J., Hill, T. and Boyer, R. Function-based modeling and troubleshooting. International Journal of Applied Artificial Intelligence, 1994, 8(2), 285–302.

415

26. Allemang, D. & Chandrasekaran, B., Functional representation and program debugging. In Proceedings of the Sixth Knowledge Based Software Engineering Conference, IEEE, Los Alamitos, CA, 1991, pp. 136–43. 27. Keuneke, A. Device representation: The significance of functional knowledge. IEEE Expert, 1991, 6(2), 22–25. 28. Hunt, J. and Price, C. Multiple-model diagnosis of electromechanical subsystems. Journal of Systems Engineering, 1992, 00, 74–89. 29. Chittaro, L. & Ranon, R., Augmenting the diagnostic power of flow-based approaches to functional reasoning. In Proceedings of AAAI-96: 13th Conference of the American Association for Artificial Intelligence, AAAI, Menlo Park, CA, 1996, pp. 1010–15. 30. Chittaro, L., Guida, G., Tasso, C. and Toppano, E. Functional and teleological knowledge in the multi-modeling approach for reasoning about physical systems: a case study in diagnosis. IEEE Transactions on Systems, Man and Cybernetics, 1993, 23(6), 1718–1751. 31. Chittaro, L., Constantini, C., Guida, G., Tasso, C. & Toppano, E., Diagnosis based on cooperation of multiple knowledge sources. In Working Notes of AVIGNON ’89: Ninth International Workshop on Expert Systems and Their Application: Specialized Conference on Second Generation Expert Systems, 1989, pp. 19–33. 32. Lind. M., Larsen, M. N. & Osman, A., Applications of multilevel flow modeling. In Proceedings of ANP International Conference on Design and Safety of Advanced Nuclear Power Plants, 1992. 33. Larsson, J. E., Reasoning with explicit means-end models. In Working Notes of the AAAI-93 Workshop on Reasoning About Function, 1993, pp. 73–7.