m9 "WWW”!NIWUIMHII'INHUHUHHWHIHIHI

301409 6519

This is to certify that the

dissertation entitled

STANDARD PART LIBRARIES .FROM ‘A
FUNCTIONAL PERSPECTIVE

presented by

Mahmoud Pegah

has been accepted towards fulfillment
, of the requirements for

PhD degree in Computer Science

 

/-;

Major professor

MSUi: an Affirmative Action /Equal Opportunity Institution 0-12771

 

 

LIBRARY
' Michigan State
- Universlty

 

 

 

PLACE II RETURN BOX to remove“. chockomfrom yuncord.
TO AVOID FINES Mum on or More data duo.

0415,9515 DATE DUE DATE DUE

    

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MSU IoAn mm Mai/Equal Opponmlty lnothIon
Wm:

STANDARD PART LIBRARIES FROM A FUNCTIONAL
PERSPECTIVE

By

Mahmoud Pegah

A DISSERTATION

Submitted to
Michigan State University
in partial fulfillment of the requirements
for the degree of

DOCTOR OF PHILOSOPHY

Department of Computer Science

1995

ABSTRACT

STANDARD PART LIBRARIES FROM A
FUNCTIONAL PERSPECTIVE

By
Mahmoud Pegah

This thesis focuses on modeling physical systems. Specifically, it is about enhancing a
human’s ability to select standard-part models for specific tasks. In this thesis we define the
word “model” as any representation system whose behavior is analogous to the behavior of
some other object or system. Furthermore, we define “modeling” as the activity of creating
a representation of an artifact that captures behavioral features significant to the modeling

agent

Modeling complex physical systems is a difficult, error-prone, time consuming activity
and requires skilled and experienced practitioners. Constructing an adequate model is a
necessary step towards effectively reasoning about physical systems and in most cases the
user construct the device model. Although, complete automation of practical physical sys-
tem modeling is still beyond current technology, supplying a repository of standard parts
could alleviate some of modeling difficulties. As a basis for addressing modeling difficul-
ties, we focus on modeling a large-scale, complex system from a realistic domain using the
Functional Modeling (FM) approach, as well as enhancing a modeler’s ability to select

adequate models from a standard part library.

We first examine the feasibility of Functional Modeling for reverse engineering of phys-
ical systems for the purpose of consequence finding. We then investigate the scalability of

Functional Modeling in a realistic, heterogenous domain drawn from the aerospace indus-

try. The term “scalability” is used to signify the ability of FM to scale to larger sized sys-
tems and to model a system in a profoundly different domain than the previously

investigated domains.

We investigate the issues of component connectivity and substance flow. We construct a
representational framework to incorporate the connectivity enhancement to the current the-
ory of the Functional Modeling. We define a standard part as an abstraction of a known,
off-the-shelf artifact, suitable for instantiation and cast the problem of selecting standard
parts as a representation search problem. Furthermore, we develop a computationally trac-
table algorithm and represent a framework to automate the modeler’s ability to select stan-

dard parts for a specific task.

Finally, we show that Functional Modeling supports the reuse and sharing of existing
designs through the standard part library facility. Reusing standard parts reduces the devel-
opment time cycle of the product since the component does not have to be redesigned from
scratch. Furthermore, reusing components which have been shown to function correctly in
the past will help industries meet their goals of improved quality, consistency, testability,

manufacturability and maintainability of the product.

© Copyright by MAHMOUD PEGAH 1995
All Rights Reserved

Dedicated To: Kris T. Schroeder

ACKNOWLEDGEMENTS

First and foremost, my thanks are due to Almighty Allah for His unending blessings and
kindness which made the completion of this thesis possible.

I would also like to express my appreciation to my thesis advisor Dr. Jon Sticklen for his
hard work and dedication to his students. His continuous dedication to his students was a
great inspiration for me to complete this thesis. I deeply admire his dedication to his stu-

dents and the department.

Next, I would like to give my heartfelt thanks to the members of my PhD. guidance
committee for their support and guidance throughout my Ph.D. program. I would particu-
larly like to express my sincere appreciation to Dr. Carl V. Page for his insightful com-
ments. It was an honor for me to have Dr. Page on my Ph.D. committee. Without his
support, it would not have been feasible for me to pursue this and other graduate studies in
the U.S.A. Also thanks are due to Dr. William Bond for his continued interest in the FIA-
18 fuel system project, to Dr. Steve Harsh for his input, and especially to Dr. William

Punch III for his guidance and encouragement.

In addition, I would like to express my gratitude to Dr. James McDowell and Robert
Hawkins for fruitful discussions and their comments in the early stages of this thesis. I am

very grateful for the help I received from them.

Many people made me feel at home when I returned to the ISL to complete this manu-
script. In particular, I wish to thank my good friends Dr. Ahmed Kamel for his encourage-

ment, beautiful stories, and lively discussions, Eman El-Sheikh for her kindness which

vi

made the ISL a delightful place to work and her attention and laughs at my not so funny

jokes, and Chris Penney for providing the most wonderful technical support one could

expect.

I would like to extend my deepest appreciation to my dear friends and colleagues Dr.
Stanley Walljasper and Dr. Philip East from the Computer Science Department of the Uni-
versity of Northern Iowa for their moral support and encouragement. I acknowledge the
support I received from Provost Nancy Marlin, Dean Gerald Intemann, and Dr. Kevin
O’Kane of the University of Northern Iowa. I look forward to returning to UNI and resum-

ing my duties in the Computer Science Department.

Finally, I wish to express my sincere appreciation and heart felt love and gratitude to my
parents for their tremendous support and sacrifice along the way. I am thankful for my wife,
who has given me an abundance of love, encouragement and support throughout our lives
together. I would like to dedicate this thesis to her as a token of my appreciation and love

for all she has done for me.

This research was supported in part by Independent Research and Development funds
from McDonnell Douglas Corporation. The broad research to extend and apply functional
reasoning techniques in the ISL is also supported by ARPA (ARPA/MADE #8673) and the
National Science Foundation Center for High-Speed, Low-Cost Polymer Composite Pro-
cessing at Michigan State University. Equipment used in the ISL has been generously sup-

plied by Apple Computer.

vii

TABLE OF CONTENTS

 

 

LIST OF TABLES ................................................................................... xiii
LIST OF FIGURES .................................................................................. xiv
Chapter 1: Introduction ............................................................................. 1
1.1 Motivation for Model-Based Reasoning .................................................................. 2
1.2 Deep-Knowledge Approaches ................................................................................. 4
1.2.1 Causal Nets .................................................................................................... 4
1.2.2 Qualitative Device Models .................................................................................................. 5
1.3 The Modeling Task .................................................................................................. 7
1.3.1 Quantitative and Qualitative Models ................................................................................... 9
1.3.2 Why Do We Need Modeling? ............................................................................................ 10
1.3.3 Qualitative Reasoning ........................................................................................................ 11
1.3.4 Model-Based Reasoning .................................................................................................... 12
1.3.5 Why Functional Modeling? - ................................................. 12
1.4 Challenges of Pushing Functional Modeling Forward .......................................... 14
1.5 Motivation For Selecting Real World Problems .................................................... 16
1.6 Goals Of This Thesis .............................................................................................. 16
1.7 Readers’ Guide ....................................................................................................... 18
Chapter 2: Related Work ......................................................................... 20
2.1 Related Work in Functional Approach. .................................................................. 21
2.2 An Epistemic View of Ports... ................................................................................ 25

viii

 

 

 

 

2.3 Related Work in Automated Modeling .................................................................. 27
2.3.1 Compositional Modeling -- . .- - - .. ................................... 28
2.3.2 Graphs of Models ................................................................. 33
2.3.3 Modeling With Context Dependent Behaviors .................................................................. 40
2.4 Other Related Work ............................................................................................... 45
2.5 Discussion .............................................................................................................. 47
2.6 Summary ................................................................................................................ 49
Chapter 3: F/A-18 Fuel System Domain ................................................. 53
3.1 Domain Motivation ................................................................................................ 53
3.2 Domain Characteristics .......................................................................................... 55
3.3 Description of the Fuel System Domain ................................................................ 56
3.4 Statistical Data ....................................................................................................... 60
3.5 Major Subsystems .................................................................................................. 62
3.5.1 Engine Fuel Supply System ............................................................................................... 62
3.5.2 External Fuel System ......................................................................................................... 63
3.5.3 Fuel Dump System ............................................................................................................. 63
3.5.4 Fuel Pressurization and Vent System ................................................................................. 63
3.5.5 Fuel Quantity Gauging System .......................................................................................... 63
3.5.6 Fuel Quantity Low Level Warning System ........................................................................ 63
3.5.7 Fuel Storage System -- ........................................................................ 63
3.5.8 Hot Fuel Recirculation System .......................................................................................... 64
3.5.9 In-flight Refueling System ................................................................................................. 64
3.5.10 Internal Fuel Transfer System ............................................................................................ 64
3.5.11 Motive Flow System .......................................................................................................... 65
3.5.12 Refuel/Defuel System ........................................................................................................ 65
3.6 . Conclusion ............................................................................................................. 65
Chapter 4: Functional Modeling ............................................................. 67
4.1 Introduction to Functional Modeling ..................................................................... 67

ix

 

 

 

 

4.2 Components of Functional Modeling .................................................................... 69
4.2.1 Structural Description of the Device ........ - ............ 70
4.2.2 Functional Description of the Device ................................................................................ 70
4.2.3 Taxonomy of Function Types ............................................................................................ 72
4.2.4 Behavioral Description of the Device ................................................................................ 74
4.2.5 Link Annotations ............................................................................... 75
4.2.6 Behavior Graph Semantics. - .......................................... 76
4.2.7 Summary of Components of Functional Modeling ........................................................... 78
4.3 Functional Representation Example ...................................................................... 79
4.4 Reasoning ............................................................................................................... 83
4.5 Conclusion ............................................................................................................. 85
Chapter 5: FIA-18 Fuel System Model .................................................... 87
5.1 Functional Representation of the PIA-18 Fuel System .......................................... 88
5.1.1 Representing a Vertical Slice of the Engine Fuel Supply System ..................................... 89
5.2 Functional Representation of the Fuselage Transfer Control System .................... 98
5.2.1 Representation of the Fuselage Transfer Control System ................................................ 100
5.2.2 Behavior Representation of the Fuel System ................................................................... 100
5.2.3 Reasoning About The Fuselage Transfer Control System ............................................... 104
5.3 Synopsis of Findings ............................................................................................ 108
5.3.1 Modeling Via Reverse-Engineering ................................................................................. 109
5.3.2 Scalability - -- ........................................................................... 109
5.3.3 Extensions ........................................................................................................................ 1 10
5.4 Conclusion ........................................................................................................... 111
Chapter 6: Connectivity and Flow ........................................................ 113
6.1 Motivations for Connectivity ............................................................................... 114
6.2 A New Relationship Between Components ......................................................... 117
6.3 Connectivity Definition ........................................................................................ 118
6.3.1 Example of Connectivity Representation ........................................................................ 119

X

 

 

 

 

 

 

 

 

6.4 The Connectivity Relation ................................................................................... 121
6.4.1 Observations about the Connectivity Relation. .- 123
6.5 Example: Pressure-Balance—Shower—Valve for Household Shower Faucets ....... 124
6.5.1 Overview - - ..................................................................................................... 124
6.5.2 Operation ................................................................................. 125
6.5.3 Component Decomposition of the Shower Valve ............................................................ 129
6.5.4 Conceptual Diagram of the Pressure-Balance-Shower—Valve ......................................... 129
6.5.5 Functionality of the Pressure-Balance-Shower—Valve ..................................................... 132
6.5.6 The Functionality of the Pressure Equalizer Unit ............................................................ 135
6.5.7 High-level View of the Pressure-Equalizer-Unit ............................................................. 136
6.5.8 The Functionality of the Pressure Equalizer Unit’s Subcomponents ............................... 141
6.5.9 Summary- ....... - . ........................................................................................ 143
6.6 Conclusion ........................................................................................................... 175
Chapter 7: Standard Part Library ........................................................ 176
7.1 Standard Part Library Motivations ....................................................................... 177
7.2 Conceptual Design Phase of the Engineering Design Process ............................ 180
7.2.1 Addressing the Challenges of Conceptual Design ........................................................... 182
7.3 Standard Parts Library ......................................................................................... 186
7.3.1 Library Construction ........................................................................................................ 188
7.3.2 Library components structure. ......................................................................................... 189
7.3.3 Standard Part Library Organization. ................................................................................ 190
7.3.4 Modeling Ontology ................................................................................... 193
7.3.5 Standard Part Selection Modes ........................................................................................ 194
7.3.6 Definitions .- . - ....................................................................... 194
7.4 Model Selection Procedure .................................................................................. 196
7.4.1 Discussion -- - ............................................................. 200
7.4.2 Model Selection Algorithm ....................................... 202
7.5 Complexity Analysis of the Model Selection Algorithm ..................................... 204
7.6 Engine Fuel Supply System Example .................................................................. 208

 

 

 

7.6.1 Glossary of Key Terms .................................................................................................... 208
7.6.2 Component Description ................................................................................................... 209
7.6.3 System Operation. . ........................................................................ 212
7.6.4 Engine Fuel Supply System Library of Standard Parts. .................................................. 212
7.7 Structural Description of Stande Parts: ............................................................ 215
7.7.1 Fuel System Ontology ...................................................................................................... 217
7.8 Example ............................................................................................................... 218
7.9 Potential Payoffs of a Standard Part Library ....................................................... 222
7.10 Conclusion ........................................................................................................... 237
Chapter 8: Conclusion ............................................................................ 238
8.1 Summary .............................................................................................................. 238
8.2 Contributions of this Research ............................................................................. 243
8.3 Future Work ......................................................................................................... 245
8.3.1 Graphical Model Editor ................................................................................................... 245
8.3.2 Generating Reliability Causal Chain ........................................................ - ...... 246
8.3.3 Integrating FM with Energy-Based Modeling ................................................................. 247
8.3.4 Enhancing Model Selection Procedure - - - - .............................. 249
8.3.5 Representation of Functions That Arise From Geometric Descriptions. ......................... 250
8.4 Final Note ............................................................................................................. 250
BIBLIOGRAPHY .................................................................................... 252

xii

LIST OF TABLES

TABLE 1. Landscape of automated modeling of physical systems. .......................... 52
TABLE 2. Mapping from Formal to Actual Parameters .......................................... 222

xiii

Figure 1-1:
Figure 2-1:
Figure 2-2:
Figure 2-3:
Figure 2-4:
Figure 2-5:
Figure 2-6:
Figure 2-7:

Figure 2-8:
Figure 3-1:
Figure 3-2:
Figure 3-3:
Figure 4-1:
Figure 4-2:
Figure 4-3:
Figure 4-4:
Figure 4.5:
Figure 4-6:
Figure 5-1:
Fighte 5-2:

LIST OF FIGURES

Modeling Task ................................................................................................ 8
Simulation in Functional Modeling .............................................................. 22
Simulation in Functional Modeling .............................................................. 23
Information Processing Task for Compositional Modeling ......................... 31
The graph of models for a domain ............................................................... 34
Partial graph of models for a gear transmission (Addanki, et al., 1991) ...... 36
An Influence Net in Solid Dynamics (Addanki, et al., 1991) ...................... 39
A schematic for a temperature gauge (N ayak et al., 1992). ......................... 43
The possible models of a wire (Nayak et al., 1992). ................................... 43
High Level Schematic of F-18 (model A and C) Fuel System .................... 58
Components of the PIA-18 Fuel System ...................................................... 59
F/A-18 Hornets with one and two external fuel tanks. ................................ 61
Behavior Graph Semantics .......................................................................... 77
Solenoid Valve, Energized Closed Position ................................................. 80
Solenoid Valve, Energized Opened Position ................................................ 81
Description of the Solenoid Valve ................................................................ 82
Function Open of Solenoid Valve ................................................................ 82

The implementing behavior for the Open Function of the Solenoid Valve..83
Components of the F/A-18 Fuel System ...................................................... 89

Device decomposition of Engine Fuel System ............................................ 91

xiv

Figure 5-3:

Device-Function-Behavior representation of the Engine Fuel

Supply System .............................................................................................. 92
Figure 5-4: Supply-fuel-to-right-engine-from—left-crossfeed-manifold Behavior .......... 93
Figure 5-5: Device-Function—Behavior representation of the Right Engine

Fuel Shutoff Valve ........................................................................................ 96
Figure 5-6: Closing-1eft-engine-fuel-shutoff-valve Behavior ......................................... 97
Figure 5-7: Component decomposition of the Internal Fuel Transfer System. ............... 99
Figure 5-8: Device-Function-Behavior for a portion of the fuel system ...................... 100
Figure 5-9: A high-level function .................................................................................. 100
Figure 5-10: A behavior: to-Tank 3 ................................................................................. 101
Figure 5-11: A behavior: control motive flow pressure to Tank 3 transfer

shutoff valve. .............................................................................................. 102
Figure 5-12: Coarse grain view of a Particularized State Diagram (PSD) ................... ~ 106
Figure 5-13: The Particularized State Diagram (PSD) after one round of expansion ..... 106
Figure 5-14: The most detailed view of the Particularized State Diagram (PSD). ......... 107
Figure 6-1: Example of connections and ports. ............................................................ 120
Figure 6-2: Photo of the Pressure-Balance-Shower-Valve ............................................ 126
Figure 6-3: Component Connection Diagram for the Pressure-Balance-

Shower-Valve ............................................................................................. 127
Figure 6-4: Cross-section of three-position, four-way valve ........................................ 128
Figure 6-5: Component Decomposition for the Pressure-Balance-Shower-Valve ........ 130
Figure 6-6: Conceptual Diagram of Pressure-Balance-Shower-Valve .......................... 131
Figure 6-7: Device-Function-Behavior of the Pressure-Balance-Shower—Valve. ......... 133
Figure 6-8: Implementation of: equalizing-hot-and-cold-water—output-

pressure-in-the-compartments .................................................................... 134
Figure 6-9: Conceptual Diagram of Pressure Equalizer Unit ....................................... 138
Figure 6-10: Device-Function-Behavior of Pressure-Equalizer-Unit ............................. 139

XV

Figure 6—11:

Figure 6-12:
Figure 6—13:
Figure 6-14:
Figure 6-15:
Figure 6-16:
Figure 6-17:
Figure 6-18:
Figure 6—19:
Figure 6-20:
Figure 6-21:
Figure 6-22:
Figure 6-23:
Figure 6-24:
Figure 6-25:
Figure 6-26:
Figure 6-27:
Figure 6-28:
Figure 6-29:
Figure 6-30:
Figure 6-31:
Figure 6-32:
Figure 6-33:
Figure 6-34:

Implementation of: seeking-equilibrium—between-hot-and—

cold-water-pressure .................................................................................... 140
Device-Function-Behavior of Cylinder ...................................................... 145
Implementation of: transferring-water-at-cold-water-side ......................... 146
Implementation of: transferring-water—at-hot-water-side ........................... 147
Implementation of: greater-fluid-energy-at-hot-water-side ........................ 148
Implementation of: greater-fluid-energy-at-cold-water-side ...................... 149
Device-Function-Behavior of Spool .......................................................... 150
Implementation of: mechanical-energy-at-hot—water-side-of-spool ........... 151
Implementation of: mechanica1-energy-at-cold-water-side-of-spool ......... 152
Device-Function-Behavior of Hot-Water-Compartrnent—One .................... 153
Implementation of: controlling-hot-water-inlet .......................................... 154
Device-Function-Behavior of Cold-Water-Compartment-One .................. 155
Implementation of: controlling-cold-water-inlet ........................................ 156
Device-Function-Behavior of Cylinder ...................................................... 157
Implementation of: transferring-hot-water ................................................. 158
Device-Function-Behavior of Cylinder ...................................................... 159
Implementation of: transferring-cold-water ............................................... 160
Device-Function-Behavior of Hot-Water-Compartments .......................... 161
Implementation of: directing-hot-water-through-equalizer-unit ................ 162
Device-Function-Behavior of Cold-Water-Compartments ........................ 163
Implementation of: directing-cold-water-through-equalizer-unit .............. 164
Device-Function-Behavior of Check-Valve-A (Hot Water Side) ............... 165
Implementation of: enabling-flow-in-flow-direction ................................. 166
Implementation of: disabling-flow-in-opposite-direction .......................... 167

xvi

Figure 6—35:
Figure 6-36:
Figure 6-37:
Figure 6-38:
Figure 6-39:
Figure 6-40:
Figure 6-41:

Figure 7-1:
Figure 7-2:
Figure 7-3:
Figure 7-4:
Figure 7-5:
Figure 7-6:
Figure 7-7:
Figure 7-8:
Figure 7-9:

Figure 7-10:
Figure 7-11:
Figure 7-12:
Figure 7-13:
Figure 7-14:
Figure 7-15:

Figure 7-16:
Figure 7-17:

Device-Function—Behavior of Check-Valve-B (Cold Water Side) ............. 168
Implementation of: enabling-flow-in-flow-direction ................................. 169
Implementation of: disabling-flow-in-opposite-direction .......................... 170
Device-Function-Behavior of the Flow-Control-Unit ................................ 171
Implementation of: controlling-hot-and-cold—water-output-pressure ........ 172
Device-Function-Behavior of Mixing-Unit ............................................... 173
Implementation of: combining-hot—and-cold—water ................................... 174
Conceptual Design Phase ........................................................................... 181
The Typical Design Practice ...................................................................... 185
Standard Part Library Hierarchy for the F/A- l 8 Aircraft ........................... 192
Standard Part Selection Process ................................................................. 201
Engine Fuel Supply System ....................................................................... 211
Decomposition diagram for the Engine Fuel Supply System. ................... 214
Representation of the device Pipe .............................................................. 224
Representation of T-Connector ................................................................... 225
Implementation of: merge-fluid of: T-Connector ....................................... 226
Representation of the device Shutoff-Valve ............................................... 227
Implementation of: disabling-fuel-flow of Shutoff-Valve .......................... 228
Representation of the device Turbine-Pump .............................................. 229
Representation of the device Motive-Flow-Boost-Pump ........................... 230
Representation of the device Manifold ...................................................... 231
Implementation of: connecting-multiple-ports-redundant-mode

of Manifold ................................................................................................. 232
Representation of the device Pressure-Switch ........................................... 233
Implementation of: responding-to-pressure-drop of Pressure-Switch ....... 234

xvii

Figure 7—18: Representation of the device Transducer ................................................... 235

Figure 7-19: Representation of the device Transducer ................................................... 236

xviii

Chapter 1

Introduction

This thesis focuses on modeling physical systems]. Specifically, it is about enhancing a
human’s ability to select standard-part models for specific tasks. The word “model” is a
heavily overworked term. For our purposes here, “model” is defined as any representation
system whose behavior is analogous to the behavior of some other object or system.
Furthermore, we define “modeling” as the activity of creating a representation of an artifact
that captures behavioral features significant to the modeling agent. We emphasize that there

is no one model best suited or correct for all tasks.

The modeling process in this thesis is qualitative. The qualitative modeling paradigm
makes no attempt to determine precise numerical values for modeling parameters, i.e., the
model does not represent the exact behavior of the modeled object. Instead, the model
provides qualitative approximations of the object’s behavior. We elaborate on qualitative

modeling in the following section.

 

1. Physical systems include any natural or man-made systems operating under the laws of physics (Iwasaki,
1989).

2
1.1 Motivation for Model-Based Reasoning

One of the most viable products of Artificial Intelligence (AI) research was the
development of landmark computer programs such as MYCIN (Shortliffe, 1976) and
DENDRAL (Feigenbaum, Buchanan, & Lederberg, 1971). It was during the birth of these
programs that the terms “expert system” and “knowledge engineering” were coined to
describe these systems and how they were constructed. These programs demonstrated high
levels of competency, comparable to experts in their respective domains. Their
performance was a direct result of specialized knowledge that they could apply to the
problem at hand. However, they did not posses the type of general problem solving
knowledge possessed by human problem solvers.

The inference methods of the early expert systems were based on shallow knowledge,
such as empirical associations between antecedents and consequences. Although they
performed at high levels of competency in tasks with narrow scope, there were inherent

limitations to their approaches which lead to the recognition of the following problems:

1. The expertise of these systems was limited by the thin slices of knowledge
they used for problem solving. They did not possess knowledge outside this
narrow scope. Consequently, the performance of these systems degraded
sharply when the problem at hand differed only slightly from the original
problem area for which they were designed. Worse, at times they produced

erroneous results by failing to recognize the limits of their own knowledge.

2. The inability to transfer knowledge from one problem solving task to
another made it difficult to store and reuse the knowledge. Early expert
system’s knowledge was encoded as empirical associations that were
specific to the particular type of task they were designed to perform. Thus,
their knowledge was not easy to store and reuse with other tasks, even in the

same domain. For instance, consider a rule that stated, “If there is no spark

3
at the coil wire, then there is a problem in the primary ignition system.” This

rule was useful in diagnosing ignition system malfunctions, but it could not
be used for designing a better ignition system, even though the domain was
the same for both tasks.

3. The early expert system’s knowledge was drawn from different sources,
including behavioral knowledge, structural knowledge, laws of nature,
empirical or statistical knowledge about faults and so on (Kuipers, 1989).
These different types of knowledge were compiled into a single knowledge
representation, regardless of the type of knowledge stored. These expert
systems relied on this one knowledge representation, making no distinction

between knowledge from different sources.

4. Early expert systems often broke down when their initial problem solving
domains were expanded. To expand the problem domain, the knowledge
engineer was forced to expand the knowledge-base. However, integrating
new knowledge into an existing knowledge-base was often a tedious and
error-prone task. The problems that often arose were due to the interaction
among the rules. As the knowledge-base became larger, these interactions
could not be anticipated in advance. Therefore, there was a call for
organization and modularization of the knowledge to make additions and

modifications feasible.

In summary, first generation expert systems failed because their narrow range of
expertise lead to their inability to attack problems outside this range. Simply said, “they

had no common sense” (Top & Akkermans, 1991).

To overcome these limitations, AI researchers proposed new methods which use more
detailed knowledge, called “model-based” or “deep” knowledge (Patil, Szolovits, &
Schwartz, 1981; Pople, 1982). Deep knowledge models are based on general knowledge

4
about the domains. More specifically, the general knowledge includes basic knowledge

about the physical structure of the artifact, functions of the individual components of the
artifact, and the interaction of the components of the artifact. Deep-level knowledge can be
constructed by studying the internal mechanisms of a system and trying to discover the
underlying domain principles. This deep-level knowledge permits the explanation of the
behavior of a device under a wide variety of conditions, including those not anticipated in
advance. Thus, the models have a larger range of applicability than the empirical

associations that were used in early expert systems.

1.2 Deep-Knowledge Approaches

Since the early 1980’s, AI researchers have used the following general approaches to

represent and reason with deep-level knowledge.

1.2.1 Causal Nets

In the causal net approach, the deep knowledge is represented as a network of causal
relations between the variables describing the system. This network is called a causal net.
Each node in a causal net embodies information about the system. Further, each directed
link between two nodes represents the “flow of causality” in the sense that the
antecedent(s) of one node “causes” the node in question. Thus, an effect could be the result
of one or more causes, and a cause could result in one or more effects. Two early Artificial
Intelligence in Medicine (AIM) projects, CADUCEUS (Pople, 1982) and ABEL (Patil, et
al., 1981), employed causal nets to represent medical knowledge. Pople developed an
extensive causal net for use in the CADUCEUS project and Patil constructed a causal net
for the ABEL project.

In the causal net approach, there is no explicit criteria for the levels of abstraction that

should be used for variables and for organizing the causal net (Sticklen & Chandrasekaran,

5
1989). Furthermore, it is the responsibility of the modeler to make such decisions as part of

the modeling process. These decisions are deemed to be domain specific. The Functional
Approach, which we explain later, addresses these issues by providing explicit criteria for
the levels of abstraction for variables and for the organization of the causal knowledge

(Sticklen, Chandrasekaran, & Bond, 1989).

1.2.2 Qualitative Device Models

A second stream of major contributions to the development of deep-knowledge models
may be distinguished as Qualitative Device Models. The four basic approaches to deep-
knowledge about physical systems are:

0 The device-centered approach of deKleer and Brown (deKleer & Brown,

1984).
o The process-centered approach of Forbus (Forbus, 1984).
o The constraint-centered approach of Kuipers (Kuipers, 1986).

o The function-centered approach of Chandrasekaran and his colleagues

(Sembugamoorthy & Chandrasekaran, 1986).

1.2.2.1 The Device-Centered Approach

According to the device—centered approach, the behavior of a physical device can be
inferred from its structure (deKleer & Brown, 1984). Here, devices are modeled as having
components connected via simple interactions, resembling the constitutive relations of
system dynamics. The relations are called confluences and are the qualitative counterparts
of differential equations in quantitative models of devices. The variables are defined in a
qualitative space such as [neg, zero, pos]. The possible behaviors of the system as a whole

are determined by applying generate and test, as well as constraint-satisfaction techniques.

1.2.2.2 The Process-Centered Approach

As opposed to the device-centered approach, Forbus (Forbus, 1984) does not consider
structural components as the ontological primitives of a qualitative physics, he instead
considers physical mechanisms that cause state changes in the device. Here, physical
phenomena are modeled as a set of objects, their relationships, and processes. Objects have
states, and variables are used to represent their states. The notion of a process plays the
central role in this approach. Processes act through time to change the state of the system.
Forbus believes that all changes to the world are caused by processes. He also believes that
the process view is best here, because it explicitly specifies cause and effect relationships,
it is decomposable and it is easily expandable. However, Forbus recognizes that
Qualitative Process Theory is not enough to model all physical phenomena in the world;

some quantitative knowledge is needed.

1.2.2.3 The Constraint-Centered Approach

The goal of the constraint—centered approach is to clarify and formalize the qualitative
mathematics behind constraint equations. This approach starts directly from the system’s
differential equations (DES), and then by using qualitative calculus, generates a
corresponding qualitative system (i.e., qualitative constraints) in terms of qualitative
differential equations (QDE’s). In this approach, Kuipers argues that many behaviors
which satisfy the DES will satisfy the qualitative constraints. The work horse of this
approach is a simulation framework called QSIM. In QSIM, quantities are defined in terms
of a linearly ordered set, called the quantity space of landmarks. Landmarks are qualitative
values at distinguished points that separate physically different regions of the quantity
space. A typical example of a quantity space with landmark values is [-, 0, +]. Qualitative
simulation generates a tree of all possible qualitative states for a given system structure
reachable from the initial state. Although QSIM has become widespread among

researchers in qualitative reasoning, it suffers from a fundamental problem. The problem is

7
that it generates behaviors which do not satisfy the DES (i.e., impossible behaviors in

addition to the correct solution are generated) which makes QSIM inefficient.

1.2.2.4 The Functional Approach

Unlike the previous three approaches, the Functional Approach (Sembugamoorthy &
Chandrasekaran, 1986; Sticklen, 1987) starts with the known functionality of a component
and its subcomponents, then models the behavior of the whole device. At the core of the
Functional Approach is the Functional Representation (FR), consisting of three major

components:
1. A structural description of the device.
2. A functional description of the device.

3. A behavioral description of the device which implements the abstractly

stated functions.

In Chapter 4, we describe the representation and reasoning process of the Functional

Approach in greater detail.

1.3 The Modeling Task

A typical modeling task is viewed as a five stage process as shown in Figure 1-1.

 

 

System decomposition into subsystems

l

Behavioral description of subsystems
Behavioral interaction between subsystems

l

Subsystems model combination to
obtain a complete system model

1

Model validation

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1-1: Modeling Task

The rationale behind the first step is to reduce the complexity of the overall task, and to
obtain tractable subtasks. It is very important to decompose the system into subsystems
which can be reused in other situations. In some domains, such as the domain of engineered
artifacts, subsystems correspond to physical components. For example, when modeling
electrical circuits, the components can be switches, capacitors and transistors. In other
domains, such as the domain of human physiology, subsystems may correspond to abstract
components. For example, in (Sticklen, et al., 1989), Sticklen et a1. model the human
complement system, a physiological system that does not correspond to any physical

component of the human anatomy.

9
The behavioral descriptions for components are typically obtained from mathematical

relations. These relations are augmented by constitutive principles, such as Hooke’s Law
for physical systems. The relations are then expressed as sets of Ordinary Differential
Equations (ODE’s) or Partial Differential Equations (PDE’s). A key problem of expressing
the behavior of the system as a set of ODE’s or PDE’s is the amount of information and
detail required to describe each subsystem. In many cases, it is useful to give
approximations of the subsystem’s behaviors, (e.g., in terms of aggregate models or
qualitative descriptions.) In Section 1.3.5, we present an overview of how the Functional

Modeling approach seeks to overcome the above difficulties.

After completion of steps 1 through 3, the model’s components are assembled into a
complete model. This is one of the most tedious and error-prone stages of the modeling
process. After step 4 has been completed, the complete model must be validated. During
the validation stage, the integrity of the model is scrutinized to ensure it produces the

expected results given the input stimuli.

1.3.1 Quantitative and Qualitative Models

A quantitative model is defined as a triple (E, R, 0), where E is a set of algebraic or
differential relations, R is the set of real numbers, and 0 is a set of operators on R. The
behavioral description of the desired component is obtained from the set of algebraic or
differential relations. By providing precise values for the input parameters, a unique and

precise set of output parameters can be derived or computed.

A qualitative model, on the other hand, is defined as a triple (Q E, Q R, Q 0) where Q; is
a set of qualitative relations, QR is a set of qualitative values called the qualitative space,
such as [-, 0, +], and Q0 is a set of qualitative operators. Qualitative models represent
qualitative relations between qualitative parameters. A qualitative model is often based on

an abstraction of an analytical model.

10
1.3.2 Why Do We Need Modeling?
In real world problem solving, modeling plays a central role. It is one of the first and most
important steps in the analysis, design and evaluation of physical systems. Modeling is a
challenging task, and considerable time and effort are usually spent before a model of
suitable form and detail is found. Modeling is important because of its role in supporting

all of the following tasks.

1. Device/System Understanding: Engineers and other scientists continually
try to model devices, seeking a deeper understanding of their behavior. A
qualitative model of a device/system can, by itself, provide insight into the

device, and can guide the search for other interesting phenomena.

2. Consequence Finding: The model of a system can be used to predict the
behavior of the system in response to a particular set of boundary
conditions. This can be useful in investigating the results of subjecting a

system to adverse or abnormal conditions, particularly in support of design.

3. Model-based Diagnosis: Diagnosing the “broken” system has been the
focus of much attention since the early era of AI research. Model-based
reasoning is attractive because it captures the intentions of the design
engineer. By comparing the behavior generated by a model of the properly
functioning system to the behavior generated by the actual device, points of
failure in the system can be located. This greatly facilitates the
troubleshooting process because the model shows how the device was

intended to work.

4. Design: In the design task, the designer is given a description of the desired
behavior of a component. The objective is to determine how to achieve the

desired behavior by:

1 1
a. selecting a preexisting component or

b. selecting a set of components, along with their interconnections.

Modeling is needed, not only to validate the final design, but to also under-

stand the behavior of the components during the selection process.

5. Control: The primary objective of a control problem is to construct rules for
controlling dynamic systems. Formal control theory procedures require that
an analytical model of the system be constructed. Then, the model is used to
derive a control strategy (i.e., the control rules). The analytical model is
typically a mathematical model describing the behavior of the system
through equations — usually differential equations. In most cases, the
analytical model is difficult to construct and solve. Therefore, deriving the
control strategy can be a tedious task. This is especially true when the model
is a nonlinear model. To alleviate some of these difficulties, qualitative
models are being used to synthesize the control rules for dynamic systems

control (Bratko, 1994).

In this section, we have enumerated a small set of tasks in which modeling may play an
important role. Although the thrust of our work is concerned with modeling for the purpose
of consequence finding and to support design, there are numerous other domains/

application areas in which modeling is important.

1.3.3 Qualitative Reasoning

Research in deep reasoning approaches emphasize qualitative reasoning (i.e. reasoning
about functions of a system without precise numerical models or data). The primary
motivation for qualitative reasoning is based on research in engineering problem solving.
Engineers seek techniques for automating design, manufacturing and other important

engineering tasks. Capturing the skills of an engineer is a necessary step towards

12
automating engineering practices for a variety of important tasks. While traditional tools,

such as SPICE ('Duinenga, 1988; Vlademirescu, 1994), MACSYMA (Rand, 1984), or
MATLAB (Mathworks, 1992) play an important role, identification of the significant
features of a system and evaluation of their interaction are the most crucial parts of

engineering problem solving.

1.3.4 Model-Based Reasoning

The main focus of model-based reasoning is on using a model (in the sense defined above)
to solve problems. In Al, the term “model-based reasoning” is used to represent a problem
solving methodology that uses some explicit or internal representation of a system, called
the model, along with a separate inference mechanism which uses the model to produce
conclusions. The term “model-base reasoning” is also used to distinguish deep knowledge
from empirical or shallow knowledge. None of these terms have been clearly defined in Al
literature. Iwasaki and Low argue that “deep” and “shallow” are vague terms about a
system’s knowledge because the scale along which we can measure the depth of

knowledge is often not presented explicitly (Iwasaki & Chee, 1991).

1.3.5 Why Functional Modeling?

Functional reasoning about a device is a conceptual abstraction of “how” the device works.

This abstraction is based on
0 “what the device is”,
a “what the device is capable of doing”, and
0 “how the device does it”.

We represent “what the device is” as a collection of subdevices related by a

“ComponentOf” relationship. “What the device is capable of doing” is represented by the

13
functions of that device. Finally, “how the device does it” is represented by the behaviors

that accomplish these functions.

Representing a device as a collection of subdevices is advantageous when dealing with
large systems. It is typically easier to analyze and understand the subdevices of a complex
system, rather than tackling the entire device initially. It is then possible to gain an
understanding of the overall device by observing the cooperative actions of its subdevices.
In the Functional Approach framework, the above ideas of device decomposition are
recursively applied at many levels. The inverse concept, functional composition, is applied
to build larger devices from simple components. This is also useful when building a large
model as a composition of available submodels (e.g., building a model from a library of

standard part models).

Along with decomposition and composition, there are two other concepts that are
inherent in the Functional Approach. These are abstraction and modularization.
Abstraction is focusing on important features, while discarding unimportant details. By
modularization, we mean the act of decomposition, usually aimed at reusability. During
device decomposition, we can decompose the device into modules that can be represented

by parts available in a standard part library.

The descriptive power of the Functional Representation provides a natural modularity in
understanding devices. We can replace a subdevice of the overall device with another,
totally different subdevice with the same functions, without any disturbance in the
functioning of the overall device. Furthermore, the Functional Approach delivers a natural
“layering of understanding” from the most abstract levels of the device description to the

most detailed.

In the work presented in this thesis, we are interested in modeling large, complex, real-
world systems in a user-friendly way. Moreover, we want to reuse device models whenever

possible. Therefore, it is important to use a modeling framework that supports device

l4
decomposition, device composition, abstraction and modularization. We have selected the

Functional Modeling framework.

1.4 Challenges of Pushing Functional Modeling Forward

Although there is considerable representation and explanation power in the current
Functional Modeling (FM) framework, we are still faced with several basic challenges in
moving FM to the next stage of development. Capturing the design specification, utilizing
the standard parts library, addressing model reusability and tackling connectivity and flow

are among the most pressing challenges for our purposes.

When constructing functional models of designed artifacts, we need to capture a broad
range of information which is often left implicit. To construct a robust1 model, we need to
understand both the final design of the designed artifact and much of the rationale2 for
choices made during the design of the device. The Functional Approach cannot completely
represent a designer’s rationale. However, the Functional Approach is a good framework
for capturing the intent of the designer during the design process. Consider the result of a
designer documenting the design process by building a functional model of the designed
artifact. In the functional model, the designer must represent the intended functions of the
device, along with a causal story of how the device achieves its functions. Therefore, the
designer’s intent will be captured in the functional model. By then analyzing the functional
model, we understand the functionality the designer was seeking from the component and
how he/she expected the component to behave. Thus, to better understand the decisions a
designer makes during the process, we must capture the intended functionality of the

subcomponents he/she designs.

 

1. By robust, we mean a model that describes the causal relationships between states of the system that can
be used to compute results, such as explanations of the device’s behavior.

2. Design rationale is the explicit record of the design activity and the reasons for choices made during the
design stage of the device (Chandrasekaran, Goel, & Iwasaki, 1993).

15
We need to understand and capture the causality in devices deep enough to allow us to

represent and reason about “how the device works”. Furthermore, it would be helpful to
have a system that understands the domain to some degree. For instance, it would be
valuable to have a system that “understands” what it means to label an object in a CAD
block diagram as a “turbine-pump” or “valve”. The word “understand” means having the
system build an association between the term “turbine-pump” and the appropriate
knowledge about “turbine-pump”, which includes its behavior, structural requirements,

BIC .

One of the most tedious and error-prone parts of modeling an artifact is the need to copy
the same type of component into a model several times. This is especially noticeable in the
domain of engineered artifacts and can be a hinderance to efficient representation. Simply
stated, in an engineered artifact, many device subcomponents will be repeated. The fuel
system project, described in Chapter 3, is a clear example of this observation. In the FIA-
18 fuel system, we modeled recurrences of valve and pumps numerous times. Augmenting
the Functional Approach with a library of standard parts would alleviate some of the
difficulties encountered when repeatedly copying the same type of component into a
functional model.

Currently, the Functional Approach does not explicitly address device connectivity (i.e.
how the device’s components are connected). In the early stages of the development of the
Functional Approach, the ideas of connectivity were represented (Sembugamoorthy &
Chandrasekaran, 1986), but to date, connectivity and flow still remain a barrier to moving
the Functional Approach forward. Engineering systems, especially hydraulic oriented
systems such as the F/A-18 fuel system, are constructed by assembling a large number of
interconnected components. Representing the fuel system as a set of interconnected
components with fluid flowing between them seems the most intuitive approach. However,

the current representation does not provide primitives for representing connectivity and

16
flow. Furthermore, the connectivity should be represented explicitly in the model.

Arguments for this assertion are addressed in Chapter 6 of this thesis.

1.5 Motivation For Selecting Real World Problems

In the Intelligent Systems Laboratory (ISL) at Michigan State University, real-world
problems are our testbeds. We believe that our tools and methodologies (including the
Functional Modeling framework) need to be exercised and expanded by applying them to
real-world devices and phenomena. In our work, we tackle multifaceted, real-world
problems, rather than pedagogically “clean” domains. In the past, research in the ISL has
tackled diverse real—world domains, including ecological-systems, agriculture, biology,
physics, automotive electronics, space station FREEDOM, and composite material design

and fabrication].

The driving force behind the selection of such diverse domains is to study the key
problems of knowledge representation and inference. For instance, in this thesis we target
the F/A-18 fuel system because it is a complex, heterogenous, real-world engineered
artifact. Furthermore, since the original design documentation of the F/A-18 fuel system is
not available to us, we “reverse engineer” the functions of the fuel system’s components.
Tackling real-world problems has yielded several valuable lessons and has helped us

improve our tools and problem solving framework.

1.6 Goals Of This Thesis

As we stated earlier, this thesis focuses on modeling a large-scale, complex system from a

realistic domain using the Functional Modeling (FM) approach, as well as enhancing a

 

1. Manuscripts describing these domains are available from the Intelligent Systems Lab at Michigan State
University.

l7
modeler’s ability to select adequate models from a standard part library. In this thesis, we

address the following goals:

1. To examine the feasibility of Functional Modeling for reverse engineering
of physical systems. We borrow the term “reverse engineering” from
hardware development, where it is typically applied to the process of
discovering how other people’s systems work. By using the existing FM
approach, we represent a realistic domain in aerospace for consequence

finding.

2. To investigate the scalability of Functional Modeling in a realistic,
heterogenous domain drawn from the aerospace industry. The sense that we
use the term scalability is two fold. First, we mean the ability of FM to scale
to larger sized systems. Second, we mean FM’s ability to model a system in
a profoundly different domain than the previously investigated domains.
Our selected domain, the fuel system, consists of tasks, pumps, switches,
valves, etc. This mixed environment is very significant in terms of a
functional slice of the entire aircraft. Further, diagnosing the fuel system is

a tedious and time consuming task and is hard to deal with currently.

3. To incorporate connectivity and flow into the current Functional Approach
framework. Currently, the Functional Approach does not address the issue
of component connectivity and substance flow. An important goal of this
research is aimed at providing a connectivity enhancement to the current

theory of the Functional Modeling.

4. To construct a library of standard parts to automate a modeler’s ability to
select standard parts for specific tasks. We cast the problem of selecting
standard parts as a representation search problem. To do this, we answer the

following four questions:

1 8
a. What is a standard part model, and what is the library of standard

parts?
b. What are the possible uses of a standard part library?

0. How do we search the library of standard parts for a desired stan-

dard part model?

(1. How do we incorporate a standard part model in the model of a

whole system?

1.7 Readers’ Guide

The rest of this thesis presents the details of our solution to the problems we outlined in
Section 1.4. Chapter 2 is a review of the current research in model-based reasoning and the
model selection problem. Chapter 3 briefly describes the domain of the F/A-18 fuel system
which serves as the test bed for our investigation in this thesis. In this chapter, we briefly
describe the importance of the F/A-18 aircraft to the United States Armed Forces, and
detail components of the aircraft’s fuel system. Furthermore, this chapter provides insight

into the modeling of a complex, heterogenous system.

Chapter 4 presents the Functional Approach in a semiformal fashion. Our presentation
is compact and geared towards future work in forrnalizing the Functional Approach. This
chapter is central to the understanding of this thesis. As a follow up to Chapter 3 and
Chapter 4, we present the results of our implementation of the F/A-18 fuel system in
Chapter 5. We present the component decomposition of the fuel system and then describe
our functional representation of a small portion of the Engine Fuel Supply System and the
Internal Fuel Transfer System. In representing these two systems, we focus heavily on the
representation of behavior. Reasoning about the Internal Fuel Transfer System and a

synopsis of our findings conclude Chapter 5.

19
Chapter 6 contains our proposed connectivity extension to Functional Modeling. This

chapter starts with the issue of connectivity and describes our proposal. We illustrate our
connectivity representation by modeling a real world device — a household shower faucet

valve.

Chapter 7 presents the importance of a standard part library in modeling engineered
devices. We briefly review the state of the current intelligent CAD systems and describe
possible uses of a standard part library in the conceptual design phase of the design
process. We then present a simple and novel algorithm for standard part selection. We close
this chapter with a complexity analysis of the algorithm and an application of the model

selection algorithm in modeling a small portion of the engine fuel supply system.

Chapter 8 concludes our work in this thesis. Chapter 8 begins with a summary of our
work in this thesis. Contributions of our research and a road map to future work concludes

the final chapter of this thesis.

Chapter 2
Related Work

Although we believe we are the first to propose a standard part library extension to
Functional Modeling, a large body of recent work in Artificial Intelligence has investigated
various methods of model formulation and selection. In this chapter, we present a brief
review of the Functional Approach literature and automated modeling techniques that are
closest to our work in terms of goals and approach. We begin this chapter with an overview
of the related activities in Functional Reasoning. We then discuss work related to our
extension of the Functional Approach framework. As part of our presentation, we include
an epistemic view of the concept of ports. However, the center of our attention in this
chapter is on the related work in automated modeling techniques in the domain of physical
systems. Our review includes a literature review of automated modeling of physical
systems in the domain of Bond Graphs. Integrating model-based approaches with energy-
based modeling approaches, such as Bond Graphs, has recently gained considerable
attention. We believe that integrating the Functional Approach with the Bond Graph
methodology is a promising endeavour and is one of our main focuses in the continuation

of our work.

20

21
2.1 Related Work in Functional Approach

The framework of the Functional Approach has been utilized for a variety of problem
solving tasks in diverse domains including diagnostic reasoning (Chandrasekaran, Smith,
& Sticklen, 1989; Sticklen & Chandrasekaran, 1989; Sticklen, Goel, Chandrasekaran, &
Bond, 1989b; Sticklen & Tufankji, 1992), design problem solving (Chandrasekaran, Goel,
& Iwasaki, 1993; Goel & Chandrasekaran, 1989; Goel, 1989; Iwasaki & Chandrasekaran,
1992; Stroulia & Goel, 1992), representation of scientific theories (Darden, 1990),
representing problem solvers as devices (Josephson, 1993; Stroulia, 1992; Weintraub,
1991) and representing programs as devices (Allemang, 1990). There is also a great deal of
other work in Al and related areas motivated by the Functional Approach that is aimed at
understanding the relation between the functions and structures of devices. A special issue
of Applied Artificial Intelligence has been dedicated to Functional Reasoning
(Applications of Artificial Intelligence 1993, January 27, 1993) and a historical perspective
of FR can be found in (Chandrasekaran, 1994). Since the main thrust of this thesis is not
solely Functional Reasoning, but rather our extensions to the theory, we choose not to
review the whole of FR related work. We instead review a sampling of the work which has

been most influential in leading to our work.

We begin with the work that is the foundation for the research presented in this thesis. In
the Intelligent Systems Laboratory at Michigan State University, the primary emphasis has
been focused on developing simulation techniques using the functional representation of
devices (Sticklen, Chandrasekaran, & Bond, 1989a). The approach that combines the
functional representation with a reasoning strategy of consequence finding has been called

“Functional Modeling” (FM). We present a detailed review of FM in Chapter 4.

In Functional Modeling, the simulation procedure produces a series of state changes
starting from the “initial state” (i.e., the state that satisfies the given initial conditions of the

device’s function). Figure 2—1 depicts the simulation procedure’s output. The simulation

22
output in Figure 2-1 indicates that given the initial state 81, after the simulation of behavior

B of Component C, the resulting state is 82. After a series of similar state changes, the state
SM is reached. After state SM is reached, the next state that is reached is Sn which is the

“final state” of the device D.

 

Behavior:

/ Initial State —> 81

i <— By Behavior B
32 of Component C

 

Device D i
Functlon F S4

Sn-l
4—— By World Knowledge

 

K Final State ——> Sn

 

 

 

Figure 2-1: Simulation in Functional Modeling

Sun and Sticklen have extended Functional Modeling to deal with situations in which
only a portion of the functionality of a device is understood (Sun & Sticklen, 1990). To
fulfill this goal, they proposed to derive the unknown causal behaviors from other
simulation methods, such as the QSIM approach of Kuipers (Kuipers, 1990). Their
extension provides a simulation framework for constructing representations of behavior

segments that are not represented in FM and thus cannot be activated during simulation.

23
Instead the absent behavior segments are derived during simulation from the cooperating

method. For instance, suppose behavior B of Component C in Figure 2—1 is not available
as a functional representation. If the behavior of Component C can be derived by QSIM,

then the resulting simulation can be performed as in Figure 2-1.

 

 

Behavior:
W Initial State ——> Si
j 4— By Behavior B
82 of Component C
33
Device D 3* QSIM
F ti F 4
unc on Simulate behavior B
. of Component C
Sn-1
I 4— By World Knowledge
Final State —> Sn

 

K

 

 

 

Figure 2-2: Simulation in Functional Modeling.

One of the successful applications of FR is in design problem solving. According to
Chandrasekaran, the early discussion of the role of Functional Reasoning in design sprung
from the work of Freeman and Newell (Freeman & Newell, 1971). Recently, a number of
researchers have also focused their attention of the role of Functional Reasoning in design.
In (Goel & Chandrasekaran, 1989; Goel, 1992), Goel and Chandrasekaran use FR to attack

a number of design subtasks. One such subtask is the redesign task. The goal of the

24
redesign task is to modify an existing design to satisfy slightly different functional

constraints than those imposed by the original design criteria. In many cases, the redesign
task can be accomplished by a relatively small set of modifications to the original design of
the artifact. Goel built a system called Kritik that performed a form of case-based design in
the engineering domain (Goel, 1989). Kritik’s processing involved searching a set of cases
for a design that closely matches the current case, and then used model-based reasoning

techniques to modifying the design as needed.

The use of Functional Reasoning in design verification is one of the recent additions to
the role of FR in applications (Iwasaki & Chandrasekaran, 1992). The design verification
task is best described by the following scenario. Suppose a designer has completed a new
design. The designer has reason to believe that the design will perform as expected and
fulfill its intended function. In other words, the designer has a causal story of the way in
which the designed artifact will behave. The behavior of the device, described in the CPD
(Causal Process Description), can be verified by simulation. The device’s behavior based
on the component description is also simulated and compared to the component level
descriptions in the CPD. In this way, a system trajectory generated by a qualitative!
numerical simulation can be compared to the behavior generated by the functional
representation (Iwasaki & Chandrasekaran, 1992; Vescovi, Iwasaki, Fikes, &

Chandrasekaran, 1993).

In (Allemang, 1990), Allemang employs Functional Reasoning to tackle the problem of
understanding how computer programs work and how the program can be debugged. The
intuitions leading to Allemang’s work stem from the common ground between physical
devices and computer programs. First, computer programs can be decomposed onto
components just as physical devices. The second intuition is that the computer program
achieves its functions by utilizing the functions of its components. The third intuition

behind Allemang’s work is that the manner in which a program’s components achieve their

25
function is irrelevant to understanding the role of the overall program. Therefore, a

subcomponent of a program can be replaced by another component, provided the
replacement supplies the same functionality. Based on these intuitions, Allemang
constructs a framework in which FR is used to represent the expected structures, behavior,
and functions of a program and its components. The goal of his framework is to determine

whether a computer program achieves it intended function.

2.2 An Epistemic View of Ports

One of the guiding intuitions behind the theory of Functional Reasoning is that a device
may be composed of other devices. Furthermore, a device achieves its functionality by
utilizing the services provided by its subdevices. The subdevices are interconnected in
some fashion and their functions result in a series of state changes whose final state
corresponds to the function of the main device. The points of interconnection of the
subdevices are considered input and output ports which are the focus of our discussion in

this section.

The roots of our inspiration for our definition of ports lies in the definition provided by
Paynter (Paynter, 1992). Paynter himself was inspired by Harold Wheeler who proposed

the term ‘port’ in 1949. Paynter quotes Wheeler as follows:

“It has been customary to designate each entrance or exit of a net-
work as a pair of terminals, based on the circuit concept of wires and
conduction. The result was cumbersome terms such as ‘four-termi-
nal networks’. The ultimate confusion was caused by the term ‘two-
terminal pair’ with the unobvious meaning of a network with two
pairs of terminals. Furthermore, the terminal-pair concept becomes
artificial in the case of electromagnetic fields transmitting power
within boundaries, through holes, and from one region to another in
space.

After considering many alternatives, the writer has adopted the term
‘portal’ or simply ‘port’ as the general designation of an entrance or
exit of a network. A self-impedance becomes a ‘one-port’. The usual

26

transducer becomes a ‘two-port’ with one ‘in-port’ and one ‘out-
port’. The general network is designated a ‘multi-port’. This plan
has received a favorable reaction from the several engineers to
whom it has been presented, and is first put to use in this mono-
graph” pg. 7 (Paynter, 1992).

In the Model-Based Reasoning community, many researchers have been using the
concept of ports or terminals to represent device structure. The researchers provide
orthogonal definitions of ports. They all agree that ports are connecting points for the
devices. For instance, in (Chandrasekaran, et al., 1993), Chandrasekaran and Goel included
ports as part of device structure representation. According to the authors, “components
have ports, at which they join other components in certain relations” page 50 of
(Chandrasekaran, et al., 1993). Karnopp defines ports as places at which subsystems can be
interconnected (Karnopp & Rosenberg, 1990). Furthermore, power can flow between
subsystems through the ports. Doebelin defines: ports as two locations at which two devices
exchange energy (Doebelin, 1980). Mittal uses the idea of a ‘port’ as an abstraction for
locations of component connections (Mittal & Frayman, 1989). In (Pugh, Hunt, & Price,
1994), Pugh and Price suggest that “a port provides a link to another type of model, for
example a structural model. It is within the port that facilities are provided for specifying
how the state information of the functional model should be translated into the language of
the associated structural model and vice versa.” The commonality between all these

definitions is that a port is a point of connections between two subsystems.

We, like others, view ports as connecting mechanisms. In this view, ports simply provide
the means of connecting two devices together. In addition to this commonly accepted view
of ports, we allow ports to be virtual connections between components. In this view, input
ports are the locations where specific stimuli are delivered into the device to invoke the
functions of the device. Output ports, on the other hand, are the locations where the device
delivers its functions. For example, consider a cylinder whose function is to convert fluid

energy into mechanical energy. The port which provides the terminus of a passage for the

27
fluid energy is not a physical connection, but instead a virtual connection where the fluid

energy stimulates the function of the cylinder. We view the interaction point of the fluid
energy as a virtual port. Therefore, we define a port as a point of interaction between a

component and its local environment.
We represent ports as pairs:
(N, 4)) where:

0 N is the number of ports.

0 q) is an array of size N containing pairs of the form:

(1", P”) where:

0 l‘ is the type of substance.
0 P" is the port number.

This representation is a novel extension to the notion of ports which other researchers
in the Functional Reasoning community have represented. It is novel because it provides
the terminology required to explicitly represent connectivity in Functional Reasoning.
Furthermore, since ports are typed by their physical-structures (i.e., type of substance
flow), it prevents connectivity between two incompatible ports. This provides a further
consistency-checking ability for the Functional Representation. In our representation, ports
are used as a binding interface, like formal parameters to functions in a programming

language. Furthermore, we define the functions of a component with respect to its ports.

2.3 Related Work in Automated Modeling

The foundations for automated modeling were laid by the work of early researchers in the
area of model formulation. The origins of work in model formulation and the importance
of adequate model selection for efficient problem solving can be found in (Amarel, 1968).
In the medial domain, Patil et a1. show how multiple models of a patient can lead to a causal

understanding of a patient’s illness (Patil, Szolovits, & Schwartz, 1981). Sussman and

28
Steel discuss the use of multiple views, called slices, of an electronic circuit in synthesizing

electronic systems (Sussman & Steele Jr., 1980). There has also been important work
aimed at building kinematic models of systems (Faltings, 1990; Gelsey, 1990; Joskowicz
& Sacks, 1986). Recently, a considerable amount of work has focused on fields related to
model formulation. Rather than review the large body of literature related to model
formulation, we instead focus on a subset of the literature which is related to automated

model selection from a repository of possible models in the domain of physical systems.

2.3.1 Compositional Modeling

In (Falkenhainer & Forbus, 1991), Falkenhainer and Forbus describe compositional
modeling, an approach for automatically constructing a model that is adequate for
answering a particular query. Modeling knowledge is captured in a library called the
domain theory, which consists of a set of model fragments. Each model fragment
represents some atomic aspect of a physical object or physical phenomena. The model
composition task begins with a description of the artifact called a scenario description and
a query about its behavior (typically asking how, or whether one quantity affects another).
An appropriate model of the device is constructed by composing model fragments from the

domain theory.
They formally define the model composition task as follows:
Given:

0 A scenario description S. The scenario description specifies the physical
structure of the system to be modeled. It may also include a set of facts

about the behavior of the system.

0 A domain theory Th, consisting of model fragments ""1"”an and usage
constraints which state the conditions under which each fragment can be

selected.

29
o A query Q about the scenario’s behavior. The query is expressed as a list of

key terms to be explained. The purpose of modeling is to explain how and
why the key terms change over item. Simply stated, the objective is to craft

a causal account of the behavior of the key terms over time.
Produce:

- Scenario model M such that M is coherent].

2.3.1.1 Model Representation

There are two types of information in a domain theory: model fragments and meta-level
usage constraints. A set of model fragments describe the behavior of an artifact. Meta-level
usage constraints describe relevant information about the model fragments and their
underlying assumptions and approximations. The objective of model composition is to
compose a model of a given scenario from the repository of available model fragments

while satisfying the meta-level usage constraints.
Falkenhainer and Forbus formally define a model fragment m to be a quadruple
(I, A, 0, R), where

o I is a set of conditions describing the basic physical properties required for

the model fragment to be applicable.

0 A is a (possibly empty) set of assumptions. These assumptions determine

the relevance of the model fragment to a query.

0 0 is a (possibly empty) set of operating conditions. The operating
conditions delimit the behavioral scope of the model. For instance,

operating conditions may include assertions about the relations between the

 

l. A model is coherent if it satisfies both physical and usage constraints defined in the domain theory.

30
state variables in the model fragment and constants defined in the domain

theory.

0 R is the set of behavioral constraints. The behavioral constraints are
imposed by the model fragments which participate in the construction of the
scenario model. The behavioral constraints are either qualitatively or
quantitatively represented by the state variables and their derivatives using

mathematical relations.

2.3.1.2 Organization

A model fragment’s preconditions is the set I of applicability conditions under which the
model can participate in modeling part of the scenario’s physics. A set of relevance and
mutual exclusivity constraints control the way model fragments can be chosen to model the
given scenario. Falkenhainer and Forbus formulate the model selection problem as a

dynamic constraint satisfaction problem.

Falkenhainer and Forbus define an assumption class as an ordered set of mutually
exclusive assumptions. These ordered sets represent natural groupings of the modeling
assumptions. An example of an assumption class is the different ways in which fluids can
be modeled. A fluid can be modeled as having zero viscosity, a standard newtonian
viscosity, or a non-newtonian viscosity. In the framework of compositional modeling,
assumption classes are declared using (defAssumtionClass c(a1, ...,an)) where c is an
atomic sentence which names the assumption class and (a1, ...,an) is a set of modeling
assumptions. After declaration, if c holds, then the assumption class is said to be active.
The active assumption classes play a key role in the model composition process. The final
scenario model must contain exactly one assumption from each active assumption class.

The set of inactive assumption classes is not considered during the model composition

process.

3 1
2.3.1.3 Model Composition

The information processing task of the model composition task is shown in Figure 2-3:

 

 

 

 

 

 

 

     
 

 

 

 

 

 

 

 

A Scenario
Description S
Domain Theory Th C itional
(Consists of a set of model —> "sigh Scenario Model M
fragments and usage constraints) 3
A Query Q about
the Scenario’s Behavior

 

 

 

 

 

Figure 2-3: Information Processing Task for Compositional Modeling

The model composition algorithm is a four step procedure.

1. Scenario Expansion

In this step, all applicable model fragments are identified and the quantified
domain theory is converted into an equivalent propositional theory that is
specific to the scenario S. As a result, a data dependency graph is produced
for the applicable domain theory. Each node of this graph corresponds to

each model term that could appear in the query.

2. Query Analysis

 

3.

4.

32
From the context of the query, a set of key terms representing objects, quan-

tities, and relations of interest are identified. These key terms are then used
to identify a minimal set of model fragments needed to address the query.
The output scenario model must include one model fragment from the iden-

tified set of model fragments.
Candidate Completion

The set of model fragments computed in the previous step includes every
object that must be included in the final model. This set of model fragments
must then be simplified by simplifying assumption. Some choices of simpli-
fying assumptions may result in new choices of model fragments. For
example, modeling the difference in water pressure between the boiler and
the condenser of a thermal power plant requires modeling decisions about
the fluid path between them, flow through the paths and whether to model
the fluid as a compressible or incompressible substance. Recall that assump-
tion classes provide alternative modeling assumptions. Furthermore, a
model fragment from each active assumption class must be included in the
scenario model. Hence the problem solver extends every partial collection
of model fragments to include one assumption from each active assumption
class. This procedure is called the candidate completion process. The result
of this step is a set of complete candidate modeling environments represent-

ing coherent scenario models.

Candidate Evaluation and Selection

At this stage, each candidate model is evaluated and the “best” one is
selected. The best model is determined by applying an evaluation metric to

each candidate model from the previous step.

33
5. Model Validation

As a result of incomplete information, the model composition procedure
may not select valid assumptions for the scenario model. A scenario model
is validated by checking whether the behavior predicted by the model vio-
lates any of the assumptions. Simulation, both qualitative and quantitative,
is used to validate a scenario model. Qualitative simulations are carried out
by utilizing QPE, an envisioner of QP theory. A fourth order Runge—Kutta

integration algorithm is utilized to perform quantitative simulation.

In summary, Forbus and Falkenhainer construct models by selecting appr0priate model
fragments. To select model fragments, they utilize a set of constraints. These constraints
are similar to the structural constraints we use in our standard part selection procedure. In
addition to these constraints, they also rely on assumptions in the modeling process. They
attempt to produce a model which is used to explain how the key terms of the query change

over time.

2.3.2 Graphs of Models

Another influential work which is closely tied to the work in this thesis is the Graph of
Models work of Addanki et a1. (Addanki, Cremonini, & Penberthy, 1991). The graphs of
models begins with a fixed set of models. Each model is represented as a node in a directed
graph. Each node contains reformulated knowledge from an applied physics domain. Each
edge specifies the effect of changing the assumptions of the “source” model to the
assumptions of the “destination” model. Figure 2-4 shows a graph of models for a
hypothetical domain. In this example, the domain knowledge is codified in a graph

consisting of four different nodes.

0 Model 1: A simple model that neglects a great number of constraints.

34
0 Model 2: A more realistic model which accounts for some of the neglected

constraints of Model 1.

0 Model 3: Another model which accounts for a larger number of neglected

constraints.

0 Model 4: A complex model with more realistic assumptions which is the

closest model to the real artifact being modeled.

 

 

Domain

Change Assumptions Model 3 Change Assumptions

/ Domain
Domain Model 2
Model 4

Domain
Model 1

Initial Assumptions

 

 

 

 

 

 

Change Assumptions

 

Domain Know - n ge

 

 

Figure 2-4: The graph of models for a domain

As shown in Figure 2-4, problem solving analysis starts in the simplest model, Domain
Model 1 (i.e., the model that neglects the greatest number of constraints). Initially, the
model may be considered an acceptable approximation of the real—world artifact. However,
if the current model is inadequate, the model is changed automatically by changing the

assumptions made in the model. As shown in Figure 2-4, by changing the assumptions,

35
Domain Model 1 is changed to the more realistic domain model. This process is carried out

automatically until an adequate domain model is found.

Let us consider a realistic example based on the example shown in (Addanki, et al.,
1991) from the domain of kinematics. Figure 2-5 shows a partial graph of models for a gear
transmission. There are four domain models in Figure 2-5. We make the following
assumptions for these domain models (in the figure the assumptions are shown inside the

rounded boxes):

0 Domain Model 1: This model neglects friction and assumes that energy is
conserved, objects are rigid, and all masses are uniformly distributed. This
is the simplest gear transmission model. The behavior represented by this

model is a rough estimate of the actual behavior of the gear transmission.

0 Domain Model 2: Domain Model 2 neglects friction and assumes that all
masses are uniformly distributed and all objects are rigid. However, Domain

Model 2 does account for energy losses.

0 Domain Model 3: This model accounts for friction and energy losses, but
still assumes that all masses are uniformly distributed and all bodies are

rigid.

- Domain Model 4: The final model is the most realistic model of the domain
models. It accounts for friction and energy losses and assumes non-
uniformly distributed masses. However, the model still assumes that all

bodies are rigid.

36

 

 

 

 

 

 

 

 

 

 

 

 

 

Model 1 Model 3
Edge 2
NF, R, EC, UN] F. R. UN
Edge 3
Edge 1

Model 2 Model 4
NF. R. UN \ F, R, DI
R: Rigid Body EC: Energy Conserved
UN: Uniform Mass DI: Distributed Mass
NF: No Friction F: Coulomb Friction

 

 

 

Figure 2-5: Partial graph of models for a gear transmission (Addanki, etal., 1991)

In this example, problem solving analysis begins in Domain Model 1. Domain Model 1
presents a predicted behavior. The predicted behavior of this model is compared to
measurements taken in the real world. The comparison indicates that a rotational
acceleration for one of the gears is larger than the real-world value measured. Therefore,
Domain Model 1 is not a realistic approximation of the real-world. Since the measured
value and the value predicted by the model do not match (i.e., there is a conflict between
the model and the real-world behavior), a reasoning process is invoked that searches the

graph for a more realistic domain model. The reasoning process is performed as follows:

0 The conflict is represented as delta vectors. A delta vector is an ordered pair
where the first element is the name of the parameter in conflict and the
second element is a qualitative vector that represents the change required to

resolve the conflict. When there is more than one parameter in conflict, the

37
delta vectors of all conflicting parameters are added to a list called the base

delta list.

In the example, the delta vector for the parameter in conflict (i.e., rotational
acceleration (a)) is represented as (on, -) which signifies that a decrease in

rotational acceleration will resolve the conflict.

0 The system then examines all intermediate parameters used in deriving the
parameter in conflict. In the example, Domain Model 1 invokes an equation
a = ‘t/ I to compute rotational acceleration]. The base delta list is then
extended to include all intermediate parameters. The result is the list
{(a, -), (1:, -), (I, +)} . The new list is called the extended-delta-list. The
extended-delta—list represents the changes in the conflicting parameters that
have to be achieved by changing the assumptions. A set of rules called

parameter change rules predict the consequences of assumption changes.

0 Next, the system uses the parameter change rules to set up a directed search.
The system discovers that by accounting for friction between gear teeth, a
force is introduced that opposes motion and causes a reduction in the net-
torque transmitted from one gear to another. The decrease in net-torque
results in a decrease in acceleration. Thus, the assumption change from the
no-friction assumption to the Coulomb-friction assumption satisfies (1, -)
and (0t, -). Note that not all the goals in the extended-delta-list need to be
satisfied. The assumption transition causes the system to switch to a new

model and recompute its results.

We now describe how the graphs of models paradigm detects conflicts and chooses the

correct assumption to change in more detail.

 

1. The equation is based on a law of rotational dynamics in which I is the rotational inertia, 1: is net—torque,
and a is the rotational acceleration

38
2.3.2.1 Detecting Conflicts

In the graphs of models framework, conflicts can occur in two ways: empirically or
internally. Empirical conflicts arise as a result of mismatches between the value of a
parameter predicted by the model and the value measured in the real world. Internal
conflicts arise when a parameter value supplied or derived within the model is inconsistent
with one of the model’s assumptions. Empirical conflict detection is a straight forward
process. The user supplies the system with a set of values for the parameters and the system
detects the conflicts by comparing its predictions with user supplied values. Internal
conflict detection requires knowledge about the assumptions. The knowledge about
assumptions is presented as rules called consistency rules. If a model’s predictions violate
any of the underlying model assumptions, the consistency rules automatically generate the

appropriate delta-vectors.

2.3.2.2 Changing Assumptions

Building the extended-delta-list is critical to determining the appropriate assumptions to
change. Therefore, the system has to identify all possible errors in the values of
intermediate parameters used in the derivation of the parameter in conflict. From the
example above, an error in an intermediate parameter such as t , will result in an incorrect
value for a. Each domain model maintains a data-dependency graph for all of its
derivations. This graph, called an Influence Net (I-net), explicitly represents known
parameter dependencies. The I-Net can be used to find all the parameters that affect the
parameter in conflict. Figure 2-6 is adopted from (Addanki, et al., 1991) and represents the
influences between acceleration (0t ), torque ( t ), rotational inertia (I) and other parameters

in solid dynamics.

39

 

 

 

 

Figure 2-6: An Influence Net in Solid Dynamics (Addanki, et al., 1991)

In Figure 2-6, the arc from t to or signifies that a positive (negative) change in 1: will
cause a positive (negative) change in a. The are from I to or signifies that a positive
(negative) change in I will cause a negative (positive) change in or. The I-Net is used to
represent how changes in the value of intermediate parameters affect the parameters in
conflict. Therefore, by backtracking through this graph, the system can determine the
parameters that affect the parameter in conflict. These parameters are then added to the

extended-delta-list.

The qualitative effect of assumption changes are represented by parameter-change
rules. For instance, a rule for changing the frictionless assumption to the Coulomb friction
assumption asserts that when we consider friction, a resistive force causes a reduction in
the net-torque transmitted from one gear to another. The antecedents of the parameter-

change rules represent conditions in which the assumption change affects the parameters.

40
Further, the parameters that change are represented by the consequence of the parameter-

change rules.

With the parameter-change rules and extended-delta-list in hand, the “better model”
selection process is cast as a planning problem. The goal list is represented as the extended-
delta-list and the assumption transitions represent the individual actions that realize the
goals. Furthermore, the parameter-change rules specify how the values of the parameters
are affected by each assumption transition. Each domain model is an active agent and tries
to select a group of assumption transitions that are best suited to satisfy the extended-delta-

list.

In summary, Addanki et al. present their Graphs of Models technique for selecting
appropriate models with acceptable accuracy. They first select the simplest model and then
switch models until a model with acceptable accuracy is selected. They determine the
accuracy of the model either by using consistency rules or by asking the user. The
consistency rules are somewhat similar to the behavioral constraints we use in our standard
part selection procedure. The Graphs of Models technique also uses a set of domain
dependent rules called parameter change rules. These rules are used to select a more

accurate model when the previously selected model does not meet the required accuracy.

2.3.3 Modeling With Context Dependent Behaviors

Nayak, et a1. (Nayak, Joskowicz, & Addanki, 1992) introduce a framework for automated
modeling of physical systems. Their approach is known as the context-dependent
behaviors (CDBs) paradigm. In the CD38 paradigm, context-dependent modeling
constraints are encapsulated with the behavior of the component and represented as a
behavior model. Behavior models are represented by means of qualitative and quantitative
time-varying equations. Furthermore, the context-dependent modeling constraints consist

of structural and behavioral constraints. The main objective of the CDBs paradigm is to

41
automatically construct models of physical systems. This goal is achieved by constructing

simple and adequate device models by composing appropriate sub-device models. The
adequacy of a device model is determined by the context in which it operates. Nayak et a1.
identify three types of contexts: the structural context and behavioral context of the
components, and the expected behavior of the device. In the following section we discuss

the contexts, along with the model selection process in greater detail.

2.3.3.1 Context Dependent Behaviors

In the CDB’s framework, encapsulation of component behavior and context-dependant
modeling constraints is called context-dependent behaviors (CDBs). CDBs are the basic
building blocks for automated modeling of physical systems. A single CDB can model
different components and a single component can be modeled by utilizing many CDBs.
Thus, there is a many-to-many relationship between real-world components and the CD88.
During the selection process, the most complicated CDB is chosen and then simplified by

a simplifying procedure.

2.3.3.2 Structural Context

The structural context of a component consists of its structural properties (i.e., a
description of how the component is constructed). The structural context of a device
includes the structural properties of its constituent components and the structural relations
between the components. Before selecting a CDB to model a component, the structural
constraints of the CDB must be satisfied. In other words, the structural constraints are

necessary preconditions.

2.3.3.3 Behavioral Context

The behavioral context of a device is its behavior and the behavior of its constituent

components at a particular point in time. The behavioral context of a component

42
complements the modeling information available in the structural context. Before a CDB

is selected to model a component, its behavioral constraints must be satisfied.

2.3.3.4 Expected Behaviors

Nayak et a1. define the expected behavior of a device as an abstract description of what the
device does, without stating how it does it. The expected behavior of a device is used to
capture the function of the device. Knowledge of the expected behavior is assumed to be
always available from either a description of the problem to be solved or provided by the
user. The expected behavior is a necessary attribute of a device description and plays a
crucial role in the model selection process. Furthermore, the expected behaviors specify the
components that should be part of the model, and the causal relationships between the

components.

2.3.3.5 Example: a temperature gauge

To crystallize the concept of multiple device models, Nayak et a1. present a temperature
gauge example (Figure 2—7). As shown in Figure 2-7, the temperature gauge consists of
components such as a bimetallic strip, a wire, a thermistor, a pointer and a battery. To
model this temperature gauge, Nayak et al. use a component model library consisting of
multiple models of each component. For instance, the component library contains multiple

models of the wire as shown in Figure 2-8.

43

 

 

 

> Battery

 

( _ 1*-

 

 

 

 

 

 

 

 

 

F- ) Wire
C —‘
D Thermistor
Pointe I
B' etallic
trlp

 

Container of Water

 

Figure 2-7: A schematic for a temperature gauge (Nayak et al., 1992).

 

 

ect-conductor
lectric-conductor
nstant-resistor
lectromagnet
istor mp-dep-resistor

ermal-resistor
Wire 'nductor

lastic-wire
xpanding-MAennally-expanding—wire

~1iary-rotating-wimi:g1d-rotating-wire
rsion-spring

__.>Possible model link

 

Figure 2-8: The possible models of a wire (Nayak et al., 1992).

 

 

44
During the modeling of the temperature gauge, two models for the wire — a thermal-

resistor and a constant-resistor — are selected. Furthermore, the bimetallic strip is modeled
as a thermal-bms, the thermistor is modeled as a thermal-thermistor and the pointer is
modeled as a rotating object. In the CDBs framework, all constructed models must satisfy
two important properties, model simplicity and model adequacy. The model simplicity
property ensures that only the relevant physical phenomena required for explaining the
device’s behavior is captured by the model. The model adequacy property ensures that the

model correctly captures the device’s behavior.

2.3.3.6 Modeling Program

Nayak et al. describe a polynomial time algorithm for finding a simplest adequate model
using structural, behavioral, and expected behavior constraints. An adequate model is
defined to be a model that meets the modeling constraints such as the structural and
behavioral constraints. Finding the simplest model that satisfies the expected behavior is in
general intractable. However, Nayak et al. show that this problem can be solved by making
certain appropriate assumptions. Input to their problem solver includes the device
descriptions, expected behaviors, and any user selected CDBs for each component. The

output of the problem solver is the simplest adequate model.

2.3.3.7 Summary

In the context-dependent behavior approach of Nayak et al., structural, behavioral and
functional context constraints are used in the model selection process. Structural contexts
represent physical properties such as the physical dimension of the connection between
two components. Behavior contexts represent behavioral properties, such as the value of
certain state variables of the component. Finally, the expected behavior is the set of
constraints which are represented by the functional context. In the CDBs framework, each

component is represented with multiple models which capture different aspects of the

45
behavior of the component. However, device models are represented at a single level of

abstraction. This can be considered a major limitation of their approach.

2.4 Other Related Work

Also related to our work is that by Iwasaki and Levy (Iwasaki & Levy, 1994). Iwasaki and
Levy have extended the compositional modeling framework of Falkenhainer and Forbus.
In addition to the basic representation of physical knowledge as model fragments, they
have introduced additional constructs on model fragments called composite model
fragments and assumption classes. Their extension is motivated by the irrelevance
reasoning work of Levy (Levy, 1993). In their approach, model fragments are grouped into
composite model fragments (CMFs), and CMFs are further grouped into assumption

classes.

Rickel and Porter also extend the compositional modeling approach to the domain of
plant physiology (Rickel & Porter, 1994). They address limitations of the compositional
modeling approach and introduce a modeling algorithm to overcome these limitations.
Their algorithm identifies the ways in which quantities of interest interact with conditions
in the scenario. They use graphs of interaction paths among variables to select relevant

model fragments.

Recently Thadani and Chandrasekaran (Thadani, 1994), have constructed a system for
building functional representations for devices. The key insight of their framework is that
expertise in a domain partially consists of structure-function-CPD templates at various
levels of detail. Each template has a representation similar to the device representation in
the functional modeling paradigm. Each template consists of a structural skeleton,
functions, and an abstract Causal Process Description (CPD) that describes how the
structural skeleton might achieve the indicated function. They define a template as an

organized fragment of knowledge about the domain.

46
Jonathan Amsterdam’s MM program (Amsterdam, 1992; Amsterdam, 1993) adopts the

bond graph modeling approach used in System Dynamics (Karnopp & Rosenberg, 1990).
In this approach, a system is viewed as a collection of spatial regions. Each region has a
uniform energy behavior represented schematically as elements. The behavior of these

elements is defined over efiort and flow variables.

The energy-based modeling approach classifies all standard physical phenomenon into
a fixed, finite set of elements and their interconnections. The MM program starts with a
base model for each device with behaviors represented using QSIM (Kuipers, 1990). The
program then dynamically generates a finite number of different models for a device. To do
this, the program adds energy storage or resistor elements to the base model as needed. The
major difference between this approach and our framework is that the MM program
dynamically generates standard part models. We start with a finite number of standard

models and dynamically instantiate complete models which are requested by the modeler.

MAX (Modeling and Analysis eXpert) is another example of an energy-based modeling
system (van Dijk, de Vries, Breunese, & Breesveld, 1992). MAX has been developed for
automated modeling of mechatronic systems. The concept behind MAX is multiple model
representation. Since members of the design team using MAX have different backgrounds,
they have difficulty in understanding each other’s points of view. To ease some of these
difliculties, different model representational schemes (i.e., bond graph, schematic
drawings, etc.) and their mutual transformations are supported. Graphical image editors are

used for entering and manipulating the models.

By using components from a hierarchically organized component library, a modeler can
construct a particular device model. A central model storage, called the core model,
integrates and coordinates different model representations. A major commonality between
our work and the MAX environment is the organization of the modeling building blocks in

the standard device library. We also recognize a close synergism in the usage of our

47
standard part library and the building block library for the MAX environment taken by the

modeler.

2.5 Discussion

There are some similarities between our work and the work of Falkenhainer and Forbus
(Falkenhainer & Forbus, 1991). First, their use of model fragment usage constraints is
similar to our use of functional and structural constraints. Second, they require that an
adequate scenario model must contain the terms in the query; this is similar to the
constraints imposed by the ports in our approach. Third, their model selection and model
validation is similar to our model selection and model validation which is performed by

either the human modeler or by simulation.

There are a number of differences between our work and the compositional modeling
work. The first important difference is in the use of modeling primitives. In the
compositional modeling framework, device models are constructed by composing a
collection of model fragments, in our work, standard part models are complete models of
artifacts. The second important difference is in the use of a query in their approach, there is
no counterpart for query in our work. The third difference is the use of the expected
function of a device in our work which has no counterpart in the compositional modeling
approach. Functional constraints in our work play a central role in standard part selection
and organization of the standard part library. In compositional modeling, the constraints on
the use of model fragments play a central role in composing adequate models. The model
selection algorithm in the compositional modeling approach is based on a dynamic
constraint satisfaction technique, which in the worst case, has exponential time complexity.
Our standard part selection procedure has been shown in real-world cases to be a tractable
algorithm.

48
Comparison can also be made between the graphs of models framework (Addanki, et al.,

1991) and our work. Addanki et al. represented the device library as a graph in which
different models of an artifact are represented at varying degrees of accuracy. In our
standard part library, a standard part is represented as a generic functional model that can
be instantiated to model a large number of physical devices. To get a comparable flexibility
in the graphs of models approach, there is a need to explicitly represent a large number of
device models since each device must be modeled at varying levels of accuracy. Another
difference between our approach and the graphs of models approach is that in our work, we
do not validate a standard part’s functions empirically. Our approach is geared toward
engineering design, in which case there is no real-world artifact yet constructed to be our
measuring stick. Finally, switching to a more accurate model in case of a conflict is not

applicable to our approach.

An important similarity between Addanki’s work and ours is the use of the consistency
rules to verify the accuracy of a model. In our approach we use functional constraints to
insure model accuracy. Furthermore, the graphs of models framework starts with the
simplest model and makes no effort to identify a better starting model. Our technique can
complement the graphs of models approach by providing an initial model. In other words,
our approach could be used to select an initial model and model switching could be done

using graphs of models framework.

There are a number of similarities between our work and the work reported by Nayak et
al. (Nayak, Addanki, & Joskowicz, 1990). Their use of structural and behavioral
preconditions and coherence constraints is similar to our structural and functional
constraints. Their use of expected behavior in finding an initial causal model is similar to

our approach in selecting a candidate standard part1 from a pool of applicable device

 

1. Standard part models are applicable if they satisfy the structural constraints imposed by the functional
modeler.

49
models. In their approach, user intervention plays an important role in focusing the search

for finding an adequate model fragment, user intervention may also play the same role in
our work (i.e. a human modeler selects the class or superclass of the desired standard part

from the standard part class hierarchy).

On the other hand, there are a number of differences. For instance, our representation of
standard part library is different from their representation of Context Dependent Behaviors
(CDBs). Models of artifacts in the CDBs approach are represented as a collection of model
fragments; we represent standard parts as complete models. Furthermore, Nayak chooses
the most complicated device model, and then uses a procedure to simplify the resulting
model. In our approach, standard part models are represented as classes and organized in a
component type hierarchy and indexed by functions they provide. There is no need to

simplify the selected standard part model.

Nayak et al. represent the expected behavior as a causal relation between parameters.
Falkenhainer and Iwasaki use the query as a causal relation between parameters. Addanki
uses delta lists (list of conflicts) as a causal relation between parameters. While their
representation has proven to be useful, it is clearly not very expressive. A more expressive
language such as Functional Representation has the potential to assist them in representing

a wider range of expected behaviors and queries.

2.6 Summary

We started this chapter by presenting an overview of related work in Functional Reasoning
(FR). We reviewed a small set of the major contributors to FR. These were the works of
Sticklen which this thesis is based on, Sun and Sticklen in deriving unavailable behaviors,
Goel’s work in design problem solving, the work of Chandrasekaran, Iwasaki, and Goel on

design verification and the work by Allemang on proof of program correctness and

program debugging.

50
Since connectivity and a standard part library are the two major extensions of our work

to the theory of FR, we gave special attention to the related work in these two areas. We
presented an epistemic view of ports, which is the basis of connectivity in this thesis. We

presented our view of ports and discussed views provided by other researchers.

Automated modeling of physical systems has been a central issue in Al research in
recent years. The first work we reviewed was the influential work of Falkenhainer and
Forbus. In their work, they select models by a technique called compositional modeling. In
compositional modeling; framework modeling knowledge is captured in a library called
domain theory, which consists of a set of model fragments. Each model fragment
represents some atomic aspect of a physical object or physical phenomenon. The model
composition process begins with a description of the artifact and a query about its
behaviors. An appropriate model for the device is built by composing model fragments

which are governed by the constraints imposed by a query and the domain.

We then presented an overview of another influential work in automated modeling
known as graphs of models developed by Addanki et al. The graphs of models approach
uses a fixed set of models, where each model contains reformulated knowledge from an
applied physics domain. The goal of this framework is to select models of acceptable
accuracy. Acceptable accuracy of a model is determined by the user or by using
consistency rules. In case of unacceptable accuracy, a set of domain dependent parameter
change rules are used to select a different, more accurate model. Graphs of models starts
with the simplest model, and then switches models until an acceptable accurate model is

found.

The compositional modeling approach and the graphs of models framework are
profoundly different frameworks. The former is based on elementary modeling constructs
called model fragments and the later is based on complete models of the artifacts being
modeled.

51
We presented research reported by Nayak et al. Their work has been inspired by the

work of Falkenhainer and Forbus. Nayak’s work, termed the Context Dependent Behaviors
(CDBs) approach, provides a starting point for the line of research we report in this thesis.
The goal of the CDBs approach is to construct simple device models by selecting
appropriate models for each component. Component models are determined by the context

in which they operate.

After presenting an overview of the key research reports in automated modeling, we
presented some other related automated modeling work in the area of energy-based
modeling. To place the key automated modeling research reported in this chapter into

perspective, we present a summary in Table 1.

52

cocoa: BER—8a m: can 380 on :8 .038 80388 a 523 Sea 8.83 meme—m3 Emma 05 we Sentence a mm awe—See :< .c
.32: m2“ .3 costume—c 580.5% 05 mm £5. .a

 

 

 

 

 

 

 

 

 

833.3 25. co>o own—Bo beau 05
.aefibmeoo anemone can 5 me .5333 c9898 82w 8:3 05 .33 05 we,
3.825.... 05 8593 35 05 Browne €23 ace—=08 038988 2588 1323 a 3:883. Geomafincem
.308 35388 owe—QEOU mason—web E58 .«o “8 < 55 Bee:— 32980 :02? ESE eta—Bow 39:5 59:0
mom—3:38 .
803% Wainscoagoofi Esc 502858.505 3:89?
523-33 eaEa are". Beaaaaam .eeamaaae e80 wees... ea... 536 easem—
eeuaESmm noun—=8?
329.com Ecouocam Row—2.3: can 963mg Eaton—a: can 258225 coca—=83 fictofiacana nag—Boon. noun—25m
boa—c 89c £58 hov—
meougtomoe Panacea
38:50 3:30:an .8253
85.388 Reeves...“— uxuaceo Ecogagom 8:: omen—.0 cocoa—Sam mam—258 we mafia—~88
8:35:00 Razogm fiance Begum 8:... 3:03.?an omen: e5 33sz saga—cu wean—co:
“caucus 05 me £302 @838 we moouwoe wfibg 3:35:00 omen:
Gnome—5n— SoEEoU Econ—mg Eco—2 .23 £on:— 803800 :05 e5 anon—wot Eco—2 9.32025
.5153 m8 5.3 “5.332 :23: .e ice usage—z 18%....an ease? 3182
race.— aaam 285m

 

 

 

 

 

 

fine: 3%.... e 3.32.. 3.88.... .e S33 ._ Sufi.

 

Chapter 3
F/A-lS Fuel System Domain

The domain described here is the fuel system of the F/A-18 Hornet, an advanced Fighter/
Attack aircraft in service in the United State Navy and the United States Marine Corps. The
motivation for modeling this complex system is two fold: to provide useful results for
McDonnell Douglas, the manufacturer of the F/A-l8 and our collaborator in this research,
and to provide empirical results for the framework of Functional Modeling. The lessons
learned while utilizing the fuel system as our test bed became the motivation leading to the
“connectivity and flow” and the “library of standard parts” extension to the Functional

Modeling framework which are described in Chapter 6 and Chapter 7 respectively.

3.1 Domain Motivation

Because of its safety record, cost effectiveness, and performance in Operation Desert
Storm, advanced versions of the F/A-l8 Hornet (the F/A-18 models E and F) have been

selected as the next-generation of carrier-based fighter by the US. Government.

The PIA-18 is a twin-engine, single or two-seated high performance aircraft (Barnes &
Noble, 1990). It is highly maneuverable and can switch between fighter and attack mode

easily. During Operation Desert Storm, on January 17, 1991, two F/A-lSs on a bombing

53

S4
mission demonstrated this capability. While carrying four ZOOO-pound bombs, these

aircraft were able to engage and shoot down two Iraqi MIG-21 fighters, without having to
jettison their payload. After downing the two Iraqi fighters, they were able to continue their

bombing mission without interruption (Polmar, 1993).

The PIA-18A (a single-seated fighter) and TF-18 (a two-seated trainer) were the two
initial versions of this aircraft. The PIA-18 was then improved and replaced by the FIA-
18C model, while the PIA-18D model replaced the TF-18 aircraft. The new versions — El
F models — are upgraded variants of the F/A-l8C/D design. Compared to the F/A-l8C/D
series, the new design has larger wings and improved engines. However, the new models
inherit subsystems such as avionics from the older series. Their proposed Initial

Operational Capability (IOC) is set to 1998 (Polmar, 1993).

The fuel system of the F/A-18 Hornet has historically been a source of many
maintenance actions. Fault isolation and correction have been tedious tasks for the Hornet
maintenance crew (Herbert, 1989). The maintenance engineers are continually searching
for ways to increase aircraft reliability, maintainability, combat readiness and at the same
time, reduce life cycle costs. Reducing fault isolation time, the ambiguity rate and fuel

system down time are effective ways of achieving these goals.

AI techniques, such as the Functional Approach to system modeling, can be applied to
the maintenance of avionic1 and non-avionic systems. These techniques aim at providing
effective and convenient troubleshooting methods, the ability to distinguish between

system failures and anomalies introduced in extreme flight conditions, and simulating the

 

1. An avionic system integrates the complex components of crew (i.e., displays and controls), airframe,
power plants, sensors and specialized subsystems (i.e., guidance, navigation and control) into an intelli-
gent airborne system for achieving specific mission objectives within time and space constraints (Jor-
gensen & Hernandez, 1983). Avionic system components (black-boxes) are mounted on surfaces that
provide mechanical tie—down. The components are then electrically interconnected to form a working
unit. To reduce maintenance time, avionic system components are designed as line replacement units
(Coglianese & Szymanski, 1993).

55
effects of such flight conditions (Herbert, 1989). The potential result is a decrease in repair

time, a reduction in false alarms and lower maintenance costs.

The development of a high-performance aircraft, such as the PIA-18, typically spans
many years, involves many engineers and consumes a great deal of money. Furthermore,
the defense industry, including the McDonnell Douglas Corp., is under increasing pressure
to “build it less-expensive, more powerful, lighter and more reliable” (Fikes, Gruber,
Iwasaki, Levy, & Nayak, 1991). If a component fails, the least qualified engineers should

be able to perform effective and timely fault isolation.

Transferring knowledge from senior engineers to their junior colleagues, and replication
and distribution of past experience, design intent, designed products, and device models

will result in low-cost, high-quality end products.

3.2 Domain Characteristics

The F/A-18 fuel system consists of tanks, pumps, valves, electrical switches, transducers
and other similar components. Many of the components in the fuel system have similar
functions. For instance, there are more then 90 valves in the fuel system, each of which has
an enabling/disabling flow function. Since the fuel system is composed of components
covering a wide variety of technologies, it is necessary for a human modeler to have a

unified approach to modeling a large range of components.

The fuel system is significant in terms of a functional slice of the entire aircraft.
Furthermore, anomalous behavior in the fuel system has a severe impact on the combat
readiness of the aircraft. Unlike many other components, the fuel system is not a line
replacement unit. In other words, it is not a modularized component and a faulty fuel
system cannot be swapped with an operational one. A great deal of fuel system
maintenance operations must be performed without removing fuel system components

from the aircraft.

56
3.3 Description of the Fuel System Domain

Our domain is the fuel system of the F/A-18C and PIA-18D Navy model aircraft built by
the McDonnell Douglas Corporation. In Figure 3-1, we have shown a schematic of this
system. The internal fuel tanks consist of four fuselage tanks and two wing tanks. The
internal fuselage tanks 1 and 4 are transfer tanks, and the internal fuselage tanks 2 and 3 are
engine feed tanks. The fuselage fuel transfer system pumps enough fuel from transfer tanks
to the feed tanks to keep the feed tanks full at all times. The fuel in either transfer tank can
be transferred to either feed tanks. The wing fuel transfer system pumps fuel from the wing
tanks to the feed tanks. The right wing transfers only to tank no. 3 and the left wing

transfers only to tank no. 2.

The power supplier for subsystems of the fuel system is the motive flow system. The
motive flow system supplies pressurized fuel, called motive flow, to operate three major

subsystems of the fuel system. These three subsystems are:
0 Engine fuel supply system
0 Internal fuel transfer system
0 Fuel dump system

In addition to these three subsystems, the motive flow system provides pressurized fuel

demanded by other systems such as the hot fuel recirculation system.

The motive flow system is the hydraulic subsystem of the fuel system. The pressure
transporter (i.e., hydraulic fluid) in this system is the engine fuel. Motive flow is generated
by two pumps called the left and right motive flow/boost pumps. These pumps are two-
stage (low pressure and high pressure stage) pumps. The low pressure stage supplies fuel

for engine operation and the high pressure stage generates high pressure fuel (i.e., motive

flow).

57
The engine fuel demanded by the two engines is supplied by the engine fuel supply

system. This system consists of the left engine fuel supply subsystem and the right engine
fuel supply subsystem. The left engine fuel supply subsystem pulls engine fuel from tank
no. 2, while the right engine fuel supply subsystem pulls engine fuel from tank no. 3. There
are two turbine pumps inside tank no. 2 and tank no. 3. These two pumps are operated by
the motive flow. Moreover, these two pumps independently supply fuel to the left and right

engine fuel supply subsystems.

58

 

 

Right engine
Right motive flow
Right wing tank boost pump
Fuel transfer “-—
turbine pump

 

 

 

  
   

Engine turbine
boost pump

 

 

«“—

Left motive flow
boost pump

Left wing tank

Left engine

 

Figure 3-1: High Level Schematic of F-18 (model A and C) Fuel System

 

The original design documentation of the PIA-18 fuel system was not available to us
during the implementation of the functional model. Thus, it was necessary to “reverse
engineer” some of the high-level functions of the fuel system by using a detailed
description of the operation of the system from a technical manual. We decomposed the
fuel system into the major components shown in Figure 3-2. We are confident that via the
reverse engineering1 process, we have successfully captured the overall functional intent

of the original system. We demonstrate a portion of our model and present a synopsis of

our results in Chapter 6 of this thesis.

59

 

F/A-18 fuel system ——

 

 

IIHIIIIIIIII

Engine fuel supply system

External fuel system

Fuel dump system

Fuel pressurization and vent system
Fuel quantity gauging system

Fuel quantity low level warning system
Fuel quantity low level signal system
Fuel storage system

Hot fuel recirculating system

Inflight refueling system

Internal fuel transfer system

Motive flow system

Refuel/defuel system

 

Figure 3-2: Components of the F/A-18 Fuel System

 

l. The term “reverse engineering" is borrowed from hardware development where it is typically applied to

the process of discovering how other people’s systems work.

 

3.4 Statistical Data

FlA-18

0 Manufacturer:McDonnell Douglas

0 Crew:
- Engines:

0 Weight:

0 Dimensions:

0 Speed:
0 Ceiling:
0 Fuel Tanks:

0 Range:

- Armament:

- Radar:
0 Photo:

(1) pilot in F/A-18A/C.
(2) pilot, bomber/navigator in F/A-18D.

2 General Electric engines/2 Pratt and Whitney engines.

empty 28,000 pounds (12,700 kg).
fighter mission normal takeoff 37,000 pounds (16,783 kg).
attack mission normal takeoff 43, 253 pounds (21,888 kg).

length overall: 56 ft (17.07 m).

wing span: 37 ft 6 in (11.43 m).
40 ft 5 in (12.32 m) with Sidewinder AAMs fitted.
wing area: 400 ft2 (37.16 m2)
height: 15 ft 3.5 in (4.66 m).
maximum 1,185 mph (1,900 kmh) at 37, 000 ft. (11, 280 m).
50,000+ ft (15, 244 m).
4 internal.
2 wing tanks.

up to 3 external.

radius 415 nautical miles (768 km) in fighter role.
radius 550 nautical miles (1, 1018 km) in attack role.

varies.
APO-65 multi-mode digital.
Figure 3-3.

61

35 E was: 25 an 25 55 32...: 2.3a arm 2:»...—

 

62
3.5 Major Subsystems

We decomposed the fuel system of the PIA-18 into the major subsystems shown in Figure
3-2. The subsystems we concentrated on were the internal fuel transfer system, engine fuel
supply system and the motive flow system. In terms of complexity, these three subsystems
constitute most of the fuel system. On a base component by base component count, the

current model represents approximately 75% of the entire fuel system.

Simply stated, the function of the internal fuel transfer system is to transfer fuel from the
non-feed tanks to the feed tanks. The function of the engine fuel supply system is to deliver
fuel from the feed tanks to the engines. Finally, the function of the motive flow system is to
provide the hydraulic power that operates the pumps that allow the fuel system to operate.
In the following sections, we present a brief overview of the major functional units of the

entire fuel system.

3.5.1 Engine Fuel Supply System

The engine fuel supply system supplies fuel to the engines. This system is powered by
motive flow pressure. Separate feed systems supply fuel to each engine. The left motive
flow supplies fuel to the left engine from fuel tank no. 2. The right motive flow supplies
fuel to the right engine from fuel tank no. 3. These two fuel supply systems are connected
by the fuel crossfeed valve. During inverted flight, the inverted flight baffles provide
captive fuel for engine operation. In emergency conditions, engine fuel shutoff valves can
interrupt engine fuel flow to either tanks. Furthermore, in case of a failure in either the left
or the right feed systems (i.e., engine fuel supply subsystems) the functioning feed system

supplies engine fuel to the engine at‘ the failed feed system.

63
3.5.2 External Fuel System

The external fuel system consists of one, two or three external fuel tanks. These tanks are

mounted on the inboard wing pylons and/or centerline pylon.

3.5.3 Fuel Dump System

The fuel dump system dumps all fuel aboard the aircraft, except a small amount of fuel in
each feed tank. Fuel is dumped directly into the atmosphere in emergency situations where

keeping the fuel would be detrimental to flight personnel.

3.5.4 Fuel Pressurization and Vent System

The fuel pressurization and vent system maintains a positive pressure on fuel in all tanks.

3.5.5 Fuel Quantity Gauging System

The fuel quantity gauging system measures the fuel quantity in each fuel tank.

3.5.6 Fuel Quantity Low Level Warning System

The fuel quantity low-level warning system is composed of a fuel low-level sensing unit
and two low-level warning sensors. This system warns the pilot when the internal fuel

amount fall below a minimum amount in either fuel feed tanks.

3.5.7 Fuel Storage System

The fuel storage system consists of four fuselage tanks, two wing tanks and up to three
external tanks. Fuselage fuel tanks are all bladder-type tanks and are supported in the tank
cavity by various brackets, fittings, and nylon lacing cords. The wing tanks are an integral

part of the wing structure and transfer fuel to feed tanks.

64
3.5.8 Hot Fuel Recirculation System
The hot fuel recirculation system provides cooling for the fuel used to dissipate heat from

the hydraulic system and the Airframe Mounted Accessory Drive (AMAD) gearbox oil.

3.5.9 In-flight Refueling System

The in-flight refueling system allows refueling of the aircraft while in—flight.

3.5.10 Internal Fuel 'D'ansfer System

The internal fuel transfer system consists of fuselage transfer, wing transfer, crossmotive
transfer and gravity transfer. To keep the feed tanks full at all times, the fuselage transfer
system pumps enough fuel from the transfer tanks to the feed tanks. Fuel can be transferred
from either transfer tanks to either feed tanks. The wing fuel transfer system pumps fuel
from the wing tanks to the feed tanks. The right wing transfers fuel only to tank no. 3 and
left wing transfers fuel only to tank no. 2. The crossmotive valve interconnects the left and
right side transfer systems. When there is loss of motive flow pressure on one side, the
crossmotive valve opens, allowing the motive flow pressure of the functioning side to
transfer the otherwise unavailable fuel in the disabled side. The valve opens when the feed
tank needs fuel and the transfer tanks have fuel to transfer.

The gravity transfer system allows fuel to flow from the transfer tanks to the feed tanks,
when normal transfer fails. Interconnect valves prevent reverse flow from feed tanks to the
transfer tanks. Gravity flow from tank no. 1 goes to tank no. 2. Gravity flow from tank no.
4 goes to tank no. 3. Some wing fuel cannot transfer, at level flight. This fuel can be

transferred by flying with one wing high, allowing the fuel to drain.

65

3.5.11 Motive Flow System

The motive flow system provides high pressure (approximately 45 to 138 psi) fuel for
operation of the engine fuel turbine boost pumps, fuel dump system, and internal fuel
transfer system. This high pressure fuel (motive flow) is generated by the motive flow-
boost pump. The motive flow-boost pump is a two stage, single shaft centrifugal pump,
mounted on the left and right Airframe Mounted Accessory Drive (AMAD). The low
pressure (boost) stage supplies approximately 10 to 53 psi fuel for engine operation and the

high pressure stage provides high pressure fuel.

3.5.12 Refuel/Defuel System

The refuel/defuel system allows refueling/defueling of the aircraft fuel tanks.

3.6 Conclusion

This chapter started with the underlying motivations for selecting the F/A-l8 aircraft fuel
system as the testbed for the research reported in this thesis. The motivation for selecting

the fuel system was two fold:

a. The F/A-l8 aircraft is an active project in the defense industry
and McDonnell Douglas, our collaborator in this work, was
seeking to gain a better understanding of the aircraft’s major

subsystems.

b. Lessons learned in this work can be used to extend the theory

and practice of the Functional Modeling framework.

The F/A-18 aircraft fuel system has many unique characteristics when compared to the

other domains studied by the FR community. The fuel system consists of heterogenous

66
components. It is a vital part of the aircraft and not a line replacement unit. Thus, it was a

challenging exercise for the Functional Modeling Approach.

To construct a functional model for the F/A-18 fuel system, we decomposed the entire
fuel system into thirteen major subsystems. The decomposition was based on the
functionality which each individual subsystem provided to the entire fuel system. Because
of the modularity of the fuel system, our functional decomposition was a mirror image of

the fuel system’s actual constituent subsystems.

In describing the major subsystems of the fuel system, we gave special attention to the
motive flow system. Motive flow system is the power supplier for subsystems of the whole
fuel system. It carries hydraulic power demanded by numerous components of the fuel

system.

Before we attempt to construct a functional model for the fuel system, we are obliged to
present an overview of the modeling paradigm. Thus, we first present an overview of the
Functional Modeling Approach in the next chapter (Chapter 4). We then exercise the
Functional Modeling techniques to represent and reason about the PIA-18 aircraft fuel

system in Chapter 5.

Chapter 4

Functional Modeling

In this chapter, we first present an overview of the Functional Modeling (FM) approach to

device representation and reasoning. The goals of FM are two fold:

1. To utilize knowledge about the purpose of a device to organize a causal

understanding of how the device “works”.

2. To utilize the causal understanding of the device to simulate its behavior

under a set of initial conditions.

This chapter paves the way for representing and reasoning about the F/A-18 aircraft fuel
system. In this chapter, we present a simplified example from the fuel system domain in
anticipation of Chapter 5 where we lay out a portion of our functional representation of the

fuel system.

4.1 Introduction to Functional Modeling

Functional Modeling (FM) (Sticklen, Chandrasekaran, & Bond, 1989a) extends the
research reported by Sembugamoorthy and Chandrasekaran (Sembugamoorthy &
Chandrasekaran, 1984; Sembugamoorthy & Chandrasekaran, 1986) at Ohio State

67

68
University called Functional Representation (FR). FR is considered by many to be the most

influential work in functional-base reasoning about physical systems. The intellectual
aspects of FR were inspired by the desire to understand the relationship between a device’s
functions and its structure. The goal of FR was to represent the functional knowledge of a
device to enable reasoning about the device. Since its inception, FR has been augmented

and applied across diverse domains.

The Functional Representation (FR) (Sembugamoorthy & Chandrasekaran, 1986)
provides a language for describing devices at multiple levels of abstraction based on the
device’s known functions or expected functions. In this framework, devices are recursively
decomposed into their constituent subdevices, whose own functions can then be composed
in order to understand the functioning of the composed device. In engineered artifacts, this
decomposition typically parallels major structural systems of the device. The causal
behaviors of each device or subdevice are indexed according to their function(s). Since
behaviors of the higher level device can be expressed in terms of the behaviors of its
subdevices, this formalism supports abstraction of behavioral detail across levels of the

device decomposition.

The Functional Modeling (FM) approach begins with the same intuitions as the original
approach for functional representation. The basis for understanding PM are two fold:
understanding the principles of device representation in FM, and understanding the
reasoning mechanism that uses such a representation. From the representational
perspective, FM largely adopts the original approach for functional representation of
Sembugamoorthy and Chandrasekaran described earlier. However, the computational
goals of FM differ from the original approach. We use FM’s representation to find the
consequences of a particular set of boundary conditions. We present the consequence

finding procedure later in this chapter.

69
In modeling a device, we draw a boundary between the device and the rest of the

universe, called the local environment of the device. Where this boundary is drawn
depends on the needs and desires of the modeler (Karnopp & Rosenberg, 1990). The
subdevices are represented by their names and the name of their functions. Furthermore, all
subdevices are connected to each other and to their local environment through a finite

number of ports].

4.2 Components of Functional Modeling

Before we present the components of Functional Modeling (FM), we clarify the meaning
of the term “device”. In the Webster Dictionary, a device is defined as “something that has
been designed.” In (Keuneke, 1989), Keuneke proposes that “Devices are objects either
explicitly designed to achieve a goal, or objects to which a goal has been attributed” pg. 2
(Keuneke, 1989). We adopt Keuneke’s definition of device. However, in this work, we are
mainly concerned with the functions and behaviors of engineered artifacts. Therefore, we

focus on physical devices.

The functional description of a device consists of three main components. These

components are:
0 a description of a device’s structure,
0 a description of a device’s functions, and

o a description of the behaviors of the device which implement the given

function.

 

1. We discussports in Chapters6and 7.

70
4.2.1 Structural Description of the Device
The structural description of a device is the specification of its components and their
relationships. These components supply the functionality of the device. Each component
(subdevice) is represented by a domain specific name and by the name(s) of its

function(s)’.
Formally, the structure of a device is defined as a triple, (D, C, F) where:

o D is the name of the device, which is a domain dependent string of

characters.

0 C is the set of components of the device. Each component is a device by

itself.
0 F is a set of Functions.

The functions of a component in a device are specified with respect to the device.
Components can be replaced with structurally different, but functionally identical
components (within geometrical constraints). Furthermore, the components themselves are

devices, thus they can be represented as devices in their own terms.

4.2.2 Functional Description of the Device

In the Oxford English Dictionary, one definition of function is “the special kind of activity
proper to anything; the mode of action by which it fulfills its purpose”. Similar general
definitions can be found in other approaches, such as design methodology, bond graphs,
and Qualitative Physics (deKleer & Brown, 1984; Karnopp & Rosenberg, 1990).
Chandrasekaran interprets the function of a device as the distinguished properties of

interest for some observer (Chandrasekaran, 1994), where properties are behavioral states.

 

1. In the Functional Approach, we recognize a component can provide more than one function. The particular
function provided at a given point in time is context dependent.

71
Furthermore, a device must interact with its local environment to produce the distinguished

properties of interest.

We define a function of a device as “one purpose of the device in its local environment.”
It is important to note that the functions of a man—made device are defined by the designer

of the device and not derived from the operation of its subdevices.
We formally represent a function of a device as a sextuple
(DP, NP Tn CF, GP BF), where

- DpzThe component that owns this function. This device must exist in the

model.
0 NF:The function name.

0 T F:The function type. This is one of the types ToMake, ToMaintain,
ToControl, ToPrevent (Keuneke, 1991), and ToAllow (Bonnet, 1992).

o szThe context under which the function N; is applicable (i.e., the

preconditions).

- szThe goal of function NF. The functional goal is either some goal states
that have to be reached or maintained, or the control relations that have to be

maintained.

a szA pointer to a causal description of how the function is implemented

(i.e., the “By” clauses described in Section 4.2.4).

Functions provide a means of abstractly knowing what the device can achieve, what
must be true for a given function to be applicable, and where to find a causal description of

how the function is implemented.

72
4.2.3 Taxonomy of Function Types
ToMake is the basic functional type defined by Sembugamoorthy and Chandrasekaran
(Sembugamoorthy & Chandrasekaran, 1984; Sembugamoorthy & Chandrasekaran, 1986).
Keuneke (Keuneke, 1991) proposed the next three function types (i.e. ToMaintain,
ToPrevent, and ToControl). The final function type (ToAllow) was added by Bonnet
(Bonnet, 1992). All of these function types, except ToControl and T oAllow, take as an
argument a predicate, defined over the state variables of the device. The major differences
between these function types are the functional goals (expectations) and the functional
capabilities. Iwasaki and Chandrasekaran have developed formal definitions for these
functions (Iwasaki & Chandrasekaran, 1992). However, in this thesis, we consider
informal definitions for the function types. In the following, we will describe the functional

types and elaborate on the expected goal as necessary.

1. ToMake. This function type represents the post—condition of the behaviors
that implement the functions of a device. The objective of the ToMake type
may be thought of as the achievement of a specific partial state. According

to Chandrasekaran,
“the function is of the ToMake type if the goal is to make the device
reach a state in which P,- (a predicate defined over the state vari-
ables of the device) is true, and after that state is reached no specific
effort is needed to keep the predicate’s value to True, or it doesn’t

matter what state the device goes to after the desired state is reach”
p. 21 (Chandrasekaran, 1993).

2. ToMaintain. The intention of the ToMaintain function type is to reach the
desired partial state and remain in that partial state until a trigger situation is
reached. For instance, we may want to maintain fuel pressure in the range of
45-138 psi. The ToMaintain function type requires continuous monitoring
of the desired device parameters (i.e. fuel pressure) to ensure that they are

within an expected range. Furthermore, there is the potential for an

73
adjustment which is needed to keep the parameter values within that range.

Functions of this type achieve the desired state (i.e. achieve a desired value
of some substance parameters) and sustain the substance parameters at the

desired values over a period of time.

3. ToPrevent. The intention of the ToPrevent function type is to explicitly
prevent the device from reaching an undesirable state. According to
Chandrasekaran, “the function type is ToPrevent if the goal is to keep PF (a
predicate defined over the state variables of the device) from ever being
true, and some active causal process in the device is required to ensure it” p.

21 (Chandrasekaran, 1993) .

4. ToControl. The difference between the first three function types and the
ToControl type is that the previous three function types take as an argument
a predicate defined over the state variables of the device. On the other hand,
the ToControl function type takes as an argument a specific relation between
the state variables of the device. For instance, the objective of the
ToMaintain function type is to ensure a predicate defined over the state
variable of the device remains true in the presence of any exogenous1 or
endogenous2 disturbances that could affect the state of the device. However,
with the ToControl function type, the goal is to control the value of a

specific variable as a function of the values of some other variables

(Chandrasekaran, 1993).

 

1. We define exogenous variables as those variables that interact with the local environment through either
the input, output or input/output ports.

2. We define endogenous variables as those variables that are internal to the component. Endogenous vari-
ables cannot directly interact with the component’s local environment. They can only interact with the
local environment through the exogenous variables.

74
5. ToAllow: Functions of this type are used to allow some physical or abstract

material (i.e. substance) to change its location from one end of a component
to another. The intuition behind this function type is that a component may
behaviorally interact with some material (i.e. substance) by providing some
environment (i.e. path) for its transfer. The major functional concern in such
cases is the relevant dimensions of the component (i.e. physical shape,
solidity). For example, the function of a conduit is to allow transfer of some
liquid from one location to another, in which case the component pipe is

behaviorally interacting with the material liquid.

4.2.4 Behavioral Description of the Device

According to the Oxford English Dictionary, behavior is “the manner in which a thing acts
under specific conditions or circumstances, or in relation to other things”. As in the
definition of device functions, this definition is too general for our purpose. In Functional
Modeling, we define the behavior of a device is as “a description of how the function of a
device is accomplished”. The intuition behind this definition is that we understand how
devices work by composing a causal story of how they go through various state changes
until the desired states are reached. Behaviors are specified by annotated acyclic digraphs
G = (V, E, A) called behavior graphs where:

o Vis a set of vertices.
- E is a set of directed edges among vertices,
- A is the annotations on the edges.

The set Vincludes two distinguished sets of vertices, the initial vertex set, V. and the

mi:
final vertex set, V fin a 1' The initial vertices are tests on state variables of the device, and at
least one final vertex corresponds to the desired state when the function is achieved. The

remaining vertices represent descriptions of changes in state variables. Each directed edge

75
represents a causal dependence between vertices. Behaviors resemble fragments of causal

nets (Sticklen, 1987). However, unlike causal nets, the edges of the digraph are annotated
with an elaboration of why each state transition takes place. These annotations are either
pointers to “world knowledge” or pointers to other parts of the functional description itself
(i.e., to lower level functions or behaviors). Thus, a state transition is “what is achieved”

and its annotation describes “how it is achieved”.

4.2.5 Link Annotations

The type of annotations allowed on an edge in G are By_Function_0f_Component,
By_Behavior_0f_C0mponent, By_Definition, and By_Knowledge.

By_Function_0f_Component annotations refer to the function of the component that
explains the state transition. This annotation may be used to construct behaviors that
explain the functions of the device in terms of the functions of its subcomponents. This is
how Functional Modeling describes a function of a device by calling on a function of
another component. To a large extent, this corresponds to a human expertise in forming
knowledge about generic components and their functions, even though the detailed
functions of the components may be unknown. The ability to explain device functions in
terms of component functions enables us to form functional and structural hierarchies to

describe the functionality of a device.

By_Behavior annotations specify that the detailed causal story is being suppressed in the

behavior graph. The annotated behavior specifies the details of the transition.

By_Definition annotations indicate that the transition from one partial state to another
can be made because the predecessor partial state means the same thing as the successor

partial state.

By_Knowledge refers to some knowledge beyond the functional model. In this case, the

State transition can be explained by appealing to general domain knowledge. For example,

76
in engineering domains, scientific laws (often in the form of analytical equations or

mathematical relations between parameters) provide the ultimate explanation for the state
transition. Furthermore, this allows FM to utilize numerical simulations (Sticklen, Kamel,

& Bond, 1991).

4.2.6 Behavior Graph Semantics

Each edge of the behavior graph G connects exactly two nodes, corresponding to the initial
state and the final state. The semantics of this state transition are that if the initial state is
true then the final state will become true if the annotation is completed successfully. The
annotations on the edge then provide the explanation. In the behavior graph, more than one
edge may branch out of a vertex or may converge into a vertex. For example, in Figure 4-
l (a), the partial state S3 would be true if and only if the partial states SI and 82 are true and
if function F] of CI and F2 of C2 are accomplished. In Figure 4-1 (h), the semantics of the
edges are that if partial state S] is true and if function F1 of C1 is achieved, then the partial

state $2 is true and if the functional F2 of C2 is achieved, the partial state S3 is true.

77

 

 

 

 

 

Initial State 51 Initial State 32

 

 

 

 

 

  
  

By_Function: F1 of C1. By_Function: F2 0f C2-

 

Final State 83

 

 

 

(a)

 

 

Initial State 81

 

 

By_Function: F1 of C1. By_Function: F2 0f C2.

 

 

Final State 32 Final State 33

 

 

 

 

 

 

(b)

 

Figure 4-1: Behavior Graph Semantics

 

78
4.2.7 Summary of Components of Functional Modeling
To summarize, there are four central facets of the Functional Approach to device
understanding. First, the Functional Representation is a conceptual abstraction of what a
device is and how it works. The “what it is” part is represented as a collection of subdevices
related by ComponentOf relations. The “how it works” is represented as the functionality

of which the device is capable and the behaviors that accomplish those functions.

Second, a functional description exhibits a natural modularity. For example, a subdevice
of the overall device may be replaced with another totally different subdevice which
accomplishes the same functions. This property plays a central role in the standard part

selection process of the standard part library.

Third, in understanding the device functionality from the top level, we are normally led

via a chain of
device -) function —> behavior
—) subdevice —> function —-) behavior

to lower and lower levels of understanding. However, this path of understanding may be
terminated before the lowest levels of the device are reached. Once a level is reached at
which a particular functionality of some underlying subdevice may be “assumed true,”
then further probing along the current path is unnecessary. This ability to probe only as far
as needed follows directly from the modularity of the representation adopted. In the
Functional Approach to device understanding, there is a natural “layering of

understanding” from the most abstract levels of device description to the most detailed.

Finally, and related to the last point, each behavior in a functional representation can be
thought of as a fragment of a complete causal net. Each of the fragments carries with it (in
its starting nodes) predicates which indicate when the fragment is applicable. Overall, FM

manages the complexity involved in comprehending a complex device by decomposition.

79
The decomposition is along two dimensions: the device-subdevice dimension, and the

device causality dimension, where the fragments of causal knowledge are “behaviors”

which are indexed by abstractly stated functions.

4.3 Functional Representation Example

To put our introduction to Functional Representation in perspective, we present a simple
device and develop a functional representation for the device. As we stated earlier, the

functional level description of a device includes three main components:
0 a description of the device’s structure,
0 a description of the device’s functions, and

o a description of the device’s behaviors which implement the abstractly

stated functions.

To illustrate these three components of the functional representation, we present the

simple device shown in Figure 4-2 and Figure 4-3, the Solenoid Valve.

 

 

l
\\\\\\\

 

 

 

 

 

Magnetic Field .

   
      
      

    

m: V“

m-

   

        

/////

  
  

//
///~

//

 

 

 

82
We present a partially complete functional description of the Solenoid Valve shown in

Figure 4—4 to Figure 4-6. Figure 4-6 shows a description of the Open Behavior of the

Solenoid Valve. There are three important ingredients in this description.

1. The starting state which can be considered as the preconditions for the
behavior which implements the function Open of the Solenoid Valve
Device.

2. The annotated links between states which represent both the transition from

one state to another and the reason behind these transitions.

3. The partial state descriptions of the Solenoid Valve which does not represent

a total state description of the device.

 

Device: SolenoidValve
Subdevices: (Piston, PistonSpring,...)
Function: (Open, Close)

 

 

 

Figure 44: Description of the Solenoid Valve

 

Function: Open of SolenoidValve

ToMake: SolenoidValve Open

Provided: (magnetic-field-force-applied-
greater-than-spring-restoring-force)

By: Open Behavior

 

 

 

Figure 4-5: Function Open of Solenoid Valve

83

 

Initial Condition

 

magnetic-fie]d-force-applied-greater-than-spring-restoring-force

 

 

 

By Function:
TransmitForceFromMagneticFieldToSpring
Of: Piston

 

force-applied-on-spring-greater-than-restoring-force

 

 

 

By Knowledge Of:
Newton’s Second Law

 

SolenoidValve-open

 

 

 

 

 

 

Figure 4-6: The implementing behavior for the Open Function of the Solenoid Valve

4.4 Reasoning

In this section, we present the reasoning mechanism called consequence finding (Sticklen,
Chandrasekaran, & Josephson, 1987). Consequence finding is the computation goal of
Functional Modeling (FM). The functional representation fully supports the reasoning
aspect of FM. Consequence finding is undertaken to determine the consequences of a
particular set of boundary conditions. The result of the consequence finding process is a
complete state change diagram constructed from the knowledge fragments that exist in the
behaviors of the functional representation. Simply stated, the computational process of FM

builds a specialized causal net from the given boundary conditions.

The procedure for finding consequences is fully described in (Sticklen, et al., 1989a).
Since we are utilizing the consequence finding algorithm to reason about the F/A-18 fuel
system, and we do not want to alter the integrity of the procedure, we instead borrow the

consequence finding algorithm from (Sticklen, et al., 1989a) and present it in this section.

34
The consequence finding algorithm is a four step procedure described as follows:

0 Step 1: Specify the initial conditions. The variables of the device have
associated with them “default values” so that only device variable bindings
which are not the normal state of the device need to be set. Likewise, only

missing functions, or altered functions need to be explicitly input.

0 Step 2: Determine the functions/behaviors that should be used as a starting
point. Once the initial conditions of the device are specified, it becomes
possible to use those initial conditions to index behaviors and functions of
the device that would be applicable under those starting conditions. After a
round of “filtering” to remove redundant functions/behaviors, we are left
with a set of functions/behaviors we will call the “invocable functions/
behavior”. If there are no invocable functions/behaviors the functional

reasoner halts.

- Step 3: Starting with the invocable functions/behaviors from the previous
step, construct a new state-change graph structure particularized for the
current situation. Call this new structure a Particularized State Diagram
(PSD). Each node in the PSD will be a partial state description in the same
sense as before - that is, as a pointer to a variable of the device and as a

statement about how that variable is altered.
The PSD is constructed by traversing each of the starting behaviors.

a. When at a partial state, place into the PSD which is being built a
corresponding node to mark a partial state change, and, in addi-

tion, update an associated state variable database accordingly.

85
b. If we are at an annotation which is non-decomposable then

remember that succeeding partial states assume whatever the
annotation points to but make no changes in the PSD that is

being built.

c. If we are at an annotation which is decomposable (that is,
another function or behavior), remember that succeeding partial
states assume the function/behavior pointed to (as in b) and also
at this point in the construction expand the function/behavior
pointed to whether possible. To determine whether a given func-

tion/behavior may be expanded, check its starting predicates.

0 Step 4: The process of expanding the annotation links continues until there

remain no more links that are decomposable.

The PSD is built by following all decomposable annotations that were in the starting
behaviors and expanding them recursively until what is left is a PSD which includes only
partial state transitions. Each node in the PSD contains knowledge of the state variable it
alters and the nature of the alteration. In addition, each node contains a listing of the
assumptions under which this state change takes place. Once the PSD has been
constructed, it is easy to determine what the effect on the device will be by traversing the
PSD and noting cumulative changes that take place in the state description variables of the

device.

4.5 Conclusion

In this chapter, we presented the Functional Modeling (FM) framework. Central to FM are
the representation language (Functional Representation) and the reasoning strategy

(Consequence Finding). The Functional Representation consists of the following elements:

86
1. A description of the structure of the device (i.e., the subdevices which make

up the overall device).
2. A description of the intended function(s) of the device.

3. A description of how the device achieves its function(s), in other words, the

behavior(s) of the device.

The Functional Representation makes no commitment to the internal structure of the
device. Therefore, a device may be replaced by another device, provided the replacement
provides the same functionality as the original device. The modularity provided by the
representation, along with the ability of the modeler to bottom out at an appropriate level

of detail, makes FM the modeling framework of choice.

The reasoning mechanism of FM is called Functional Level Consequence Finding. The

input for consequence finding are:
0 the initial conditions of the device,
- unavailable device functions, and
o altered device functions.

The results of the consequence finding procedure is a set of state changes over time which
describe the behavior of the device. These results are useful in many aspects and can be
utilized as the input to other reasoning tasks. In the next chapter, we apply the Functional
Modeling framework discussed here to our F/A-l8 fuel system test bed introduced in
Chapter 3.

Chapter 5
F/A-18 Fuel System Model

In the preceding two chapters, we have presented an overview of the F/A-18 aircraft fuel
system which serves as the test-bed for our investigation in this thesis. We also presented
the Functional Modeling framework which we exercise to represent and reason about the
fuel system. In this chapter, we discuss our application of Functional Modeling to the FIA-

18 aircraft fuel system. In particular, we set the following five major tasks for this chapter.

1. Functional decomposition of the fuel system.

N

. Representing the Engine Fuel Supply System.

w

. Representing the Fuselage Fuel Transfer System.
4. Reasoning about the Fuselage Fuel Transfer Control System.
5. Discussing the synopsis of our results.

In discussing the synopsis of our findings in this chapter, we will give special attention

to the following goals we set in Chapter 1.

87

88
0 Testing the scalability of the Functional Approach in a heterogenous

domain which is profoundly different than the previous problem domains

attacked by the Functional Approach.

0 Testing the feasibility of the Functional Approach in constructing functional

models through reverse engineering.

0 Our proposed extensions to the Functional Modeling approach.

5.1 Functional Representation of the F/A-l8 Fuel System

AS the first step in modeling the F/A-18 aircraft fuel system, we decompose the entire fuel
system into thirteen functional units shown in Figure 5-1. We then decompose each of these
functional units into its constituent components. We continue this process of device
decomposition until we reach the level of detail desired in modeling the fuel system]. After
the completion of the component decomposition process, we define functions for each of
the components in the component decomposition hierarchy and represent their
corresponding behaviors which carry out the defined functions. In the following sections,
we lay out a portion of our functional model for two of the major subsystems of the FIA-

18 aircraft fuel system.

1. The desired level of detail is the off the shelf standard part level.

89

 

Engine fuel supply system

External fuel system

Fuel dump system

Fuel pressurization and vent system
Fuel quantity gauging system

Fuel quantity low level warning system
Fuel quantity low level signal system
Fuel storage system

Hot fuel recirculating system

Inflight refueling system

Internal fuel transfer system

Motive flow system

Refuel/defuel system

F/A- 18 fuel system

 

 

 

 

Figure 5-1: Components of the F/A-l8 Fuel System

5.1.1 Representing a Vertical Slice of the Engine Fuel Supply System

In this section, we present a small portion of our functional representation for the Engine
Fuel Supply System. We focus heavily on the representation of behavior. Before we present
the representation of behavior, we first lay out a top-level view of the Engine Fuel Supply
System decomposition. Figure 5-2 shows the component decomposition for the Engine
Fuel Supply System. In Figure 5-3, we present the device-function-behavior representation
for the Engine Fuel Supply System. Since this system is responsible for supplying fuel to
the left and right engine crossfeed manifolds, we define two functions for the Engine Fuel
Supply System, Supply-fuel-to-left-engine-crossfeed-manifold and Supply-fuel-to-right—
engine-crosfieed—manifold. We implement these two functions using four behaviors as
shown in Figure 5-3. This representation is based on our observation that the normal
operating mode of the right or left engine fuel supply units pulls the fuel from tank no. 3 or
tank no. 2 respectively. However, when one of the engine fuel supply units fails, the other

functioning unit supplies fuel to the engine with the failed fuel supply unit. This

90
redundancy built into the system ensures that each engine can be feed through two

independently operated fuel supply units.

Now let us examine one of the implementing behaviors of the function Supply-fuel-to-
right-engine-crossfeed—manifold. In Figure 5-4, we detail the behavior Supplying-firet-to-
right-engine-fmm-lefl-crossfeed-manifold. There are two starting conditions for this
behavior. The two conditions must be satisfied before the behavior is activated. The first
starting condition, “boost-pressure-from-left-motive/flow-boost-pump greater than 20”
signifies that the left motive flow system (responsible for supplying engine fuel to the left
engine) is functioning normally. However, the second starting condition “boost-pressure-
from-right-motive/flow-boost-pump less than 20” indicates an anomalous behavior in the
right motive flow system (responsible for supplying engine fuel to the left engine). Thus,
our objective is to show that the functioning engine fuel supply unit will supply engine fuel
to the engine with a failed fuel supply unit (i.e., the right engine fuel supply system in this

case).

91

Hoaxm Sam oemwem .«e 3289:0006 316n— uutm 0.3mm

 

 

.§.§§.¥§.§§&8§-3%§.

taggiééaeveaéaaageflééaevfi.

ofisfiu.ifieoo.b&3.3-oafieo¢o_e

.e_eca§§§§é.§$e§-_§§a.§e§u985.3.
.naiesefifieggaaesééflgsagfi.

eg.§§o>uee.¢o_e

V eEBuaubugmflégaao—céafieoéo—e
DEE-”gash 5 Egan—Dug.

nfii§.§3.§e

V eEBuxieheeOtn—nnaaflcéefieoéx.
.3?.es§-_ae.8aev§.

.§.§gc.9§efie§.91>.h8=€._2¢.83u9.fiee

.3369a...incinevaueéaaafiefiaeéaeznne.

.§.:=veeotm_&=u-~ua-8mueo.fiute
.3§u§.v8~398.5ut.8.§.egg—Raggguéugfiute

Eateseafieagzgéefiuaeégée.
.Eaeeeguéeeaéuc.

.5383; 43.8333»... V
.§$.§8&aaa.§3.3efie.

.§.e§§._§éafi.aue.

.as:.-§»5é&3-_oa-aa8afie.

Vegiegaggéeflgsfite

eEBnauégaaflcbn—Egco?

.93.:seaeooe832e.

ega-:&=u-_2c-8mweoafite

ogaégaaétoafieoo

 

 

92

533m human ~25 oemwem 05 we 53853—qu uofiusoméouogmtoogon ”Wm gamma

 

 

“4:56..oZ-Ep¢-o£weo.Ewtt9-_oa-mc_>395

V 28«58608380.ofimeoénwFSAoatbqn—am
20b5860£$89¢£-Eecofiweotfimtterfiameg—33

*Eoumhmiamsioatofimeoa
vista.oZ-EobtoEm=o.¢o_.9403-3533
VE8:88-38386.05meetco_to.-_o£-b&=m
Roman—utgmmmobtfiwttfiob-ofiweotco_.8-_oa-me5&3

floggom meouoesm 838

 

 

93

SSS—om Beams—afiéooumuéoéo.-EoctoemweoaamtéAoatbanm sin 8:!"—

 

 

EomEaE-coofimohotfiwtéioatofimao “Gem

.

$2.5 838.2-.me

r

2838-363meg—Ettore,R>fie3nméoommmeioaauocéou-33 :mom

.

m285863.?may—0.53.72-o>R>fioSnméo£mmEEo:m-8£-_o&-w§o_ “22209.53

_

~ on .Am o>fi>$2=€60£$8933-3-23329—03 03205 _

a

was: Seasoning

_

o>R>umoSnm-eoofimohvoBéomoéofian—o amen

’

fl$3.258-coommmeugawterfleaaa-eooummEoéoTEobéou-_o£-w£3aeo Hom>anom$a

>

 

 

 

 

 

 

 

 

 

 

 

 

 

 

cm 52:. .8380 9:393:30u-o>coE-¢o_.th-8=mm2m¢moon

 

 

 

 

cm 55. m8..— 989960333-o>uoE-Ewt.Eo¢-o.—=mmoa&moon

 

 

 

 

 

94
We want to point out that the behavior shown in Figure 5-4 (Supply-fuel-to-right-engine-

from-left-cmssfeed-manifold) uses two behaviors (represented by the “By-Behavior” link
annotations) to explain how the function will be accomplished. Furthermore, the “By-
Knowledge” link annotations are used to represent world knowledge. If we reach the final
state of this behavior, meaning the final state is completed, “engine-fuel-in-right-crossfeed-
manifold” will be reached. Thus, if we assume that the right engine fuel supply system is
not functioning normally (i.e., it is not pulling engine fuel into the right crossfeed
manifold) and we assume that the left engine fuel supply system is functioning normally
(i.e., it is pulling engine fuel into the left crossfeed manifold) then the behavior Supply-
fuel-to-right-engine-from-left-crossfeed-manifold indicates how the functioning system
(i.e., the left fuel supply system) covers for the failed system (i.e., the right fuel supply

system).

Let us now go back to the component decomposition diagram shown in Figure 5-2 and
examine a low-level subdevice of the Engine Fuel Supply System. One of the two low-
level subdevices under the left-engine—fuel-supply-control-system is the left-engine-fuel-
shutoff-valve. The purpose of any shutoff valve is to open or to close a passage for
substance flow. In Figure 5-5, we define two functions, Enableflel-flow-to-left-motive-
flow/boost-pump and Disable-fuel-flow-to-left-motive-flow/boost-pump of the left-engine-
fuel-shutoff-valve. The implementing behaviors of these two functions are Opening-left-

engine-fuel-shutoff-valve and Closing-left—engine-fuel-Shutoff-valve.

We close this section by presenting the Closing-left-engine-fuel-shutoff-valve behavior
of the 1eft-engine-fuel-shutoff-valve. Figure 5-6 depicts this behavior. As required by the
Functional Approach, we begin the behavior with the preconditions of the behavior. The
left-engine-fuel-shutoff-valve is an electrical motor operated valve and can be energized
open or energized closed. Thus, in this example, the two starting conditions are “Present

energized-close-signal-for—left-engine-fuel-shutoff-valve” and “Present fuel-flow-from-

95
left-engine-fuel-turbine-boost-pump-to-left-engine-fuel-shutoff—valve”. Moreover, the

starting conditions must be satisfied before the behavior is activated. This behavior uses
two world knowledge fragments represent by the “By-Knowledge” links. If the behavior
successfully completes, the final state of the device, “Decrease-fuel-pressure-at-left-

engine-fuel-shutoff-valve-source By 10”, will be reached.

96

33> maxim 3.5 2.3.5 Ema 05 we gag—8052 832095859335 ”Wm 8.5mm

 

 

oi? $32? .03 ofiweo afl mama—o Ignaz 6330c 0385 c2 9 Ben 33 0335
93> banana Ba cameo a2 madame It 93a “8333“ 2508 $2 8 Bow Ba 033m

”5332“ weave—Sm

Vn.o>_u>.t2::m-BEbEmcoéu—n.

836n—

 

 

97

paragon o>=2,.mouangoaéemweoéoww:mac—U ”9m Bswfi

 

 

 

 

2 hm 08new-o>fi>$o§nmtfiatofiwao££3-8332938 83on

+

:23 ewee_3e§-§

 

 

 

o>fi>.b¢§fi40£-ofii

tumoontoEEBAoa-053023788.“-Bo“Eon... 388m sonobzgfioannmAofléfiweoén: ouamoZ—

 

 

 

 

 

+

A8:989?Hewiéigéomofi omeo~3oav~$mw

 

 

o>E>tm8=fi-BabEweoéo—.uofifiawmmemo—oéofiwuog 889$

 

 

 

 

 

98
5.2 Functional Representation of the Fuselage 'll'ansfer

Control System
In this section, we detail another small portion of our functional representation for the FIA-
18 fuel system. We begin with the component decomposition diagram of the internal fuel
transfer system shown in Figure 5-7. We discuss only a portion of the total representation
which progresses from one particular starting point (i.e., we will look at a vertical slice
through the representation by following one behavior, and how it leads us to deeper level

behaviors.)

99

.8893 commas. ~05 HESS 05 no 888988“. Eocene—e0 ”Wm 853m

 

 

eo>3>fiezfieouu§biq$wd7r
eESmmmAebeoueflmF—gowa—omee
eo>_u>.t8=fi¢£§-x:8-m.eze.
«Ecummmeouéuloaoma—omae
.aaea-oseaeeaeae-_oa-€s-_.ez.
V e83m»m-w=_>te¢oum§h.omflom&e
teenageaeeagee€34.62_..

aa>a>ee_a-_e>e_-ewz-a§-~.ez.
.a>_§-.e_a-_e>e_-._m2-3a.ez.

names—8-029,$955-30c-o>uoE-m53-ao__..
eESmmEequoeoumfihmcmBe

...o>E>é3=fi-BocééoEeoumcgmfiaéor

sumac—86>E>é8=fi§ece>uoE-wEB-Ewte
*Eoemhmeamfibéamege

40>E>éo3€§oce>uoE...8§-m£3-Ewte

teneFEeeaefiaeEéer

eESmamtwegguoumfibmfike
teesqveEaCESefiafie.

eEBmAmeoumegauaAaF—Ser

 

 

100

5.2.1 Representation of the Fuselage Transfer Control System

We start with the Component—Function-Behavior representation of the internal fuel

transfer system. Figure 5-8 shows the functions of each of the components, and the

behaviors that implement these functions. The function Transfer-Vra-Transfer—Lines is

detailed in Figure 5-9.

 

/

 

\

Intemal-Fuel-Transfer—System—Transfer-Fuel-To-Feed-Tanks é

Fuselage-Fuel-Transfer-System — Transfer-Vla-TransferLines

To-Tank 2
To-Tank 3

Figure 5-8: Device-Function-Behavior for a portion of the fuel system

 

 

Function:
Provided:

ToMake:
By:

Transfer— Via-Transfer-Lines

right motive flow at tube restrictor
side of Tank 3 was filter present?

fuel transfer to feed tank enabled
to-Tank 2, to-Tank 3

 

 

Figure 5-9: A high-level function

5.2.2 Behavior Representation of the Fuel System

From-Tank 1
From-Tank 4
From-left-wing
From-right-wing

 

J

In the following, we examine one of the implementing behaviors of the function Transfer-

Via-Transfer-Lines in Figure 5-9. In Figure 5-10, we detail a top-level behavior for the fuel

101
transfer control subsystem, to-Tank 3. Figure 5-11 shows a second level behavior of the

transfer control subsystem. This behavior results in enabling fuel transfer to tank no. 3. The
link annotation shows how this action is achieved. Recall that during internal transfer, the
tank no. 1 and tank no. 4 supply fuel to tank no. 2 and tank no. 3. Transfer motive flow fuel
pressure overcomes the shutoff valve spring pressure, forcing the piston open. High
velocity fuel continuously enters the piston chamber through the orifice and is relieved by
an outlet leading to the pilot valve. Transfer motive flow fuel flows to the transfer turbine

pump, which enables fuel transfer to feed tanks.

 

 

right motive flow at tube restrictor
side of Tank 3 wash filter present?

 

 

 

. By-Behavior:
control motive flow pressure to
Tank 3 transfer shutoff valve

 

motive flow pressure at inlet side of
Tank 3 shutoff valve produced

 

 

 

By-Behavior:
enable fuel transfer to Tank 3
transfer shutoff valve

 

Tank 3 transfer shutoff
valve opened

J By-Definition-Of:

 

 

 

transfer shutoff valve

 

fuel transfer to feed tank enabled

 

 

 

 

 

 

Figure 5-10: A behavior: to-Tank 3

102

 

 

 

right motive flow at tube restrictor

side of Tank 3 wash filter present? clear srphon tube present?

 

 

 

 

 

 

 
   

. By-Knowledge-Of:
incompressible fluids

 

motive flow pressure at inlet
side of sensor produced

 

 

 

. By-Knowledge-Of:
incompressible fluids

 

motive flow pressure at outlet
side of sensor produced

 

 

 

. By-Knowledge-Of:
incompressible fluids

 

 

 

motive flow pressure at Tank 3 motive flow pressure at inlet side
fuel level sensor transducers 0f Tank 3 ShUtOff valve produced

 

 

 

 

 

 

 

 

 

Figure 5-11: A behavior: control motive flow pressure to Tank 3 transfer shutoff valve.

If we look closely at the first link in Figure 5-10, we observe that the link annotation is one
of the decomposable types, the By-Behavior type. If we follow this link, we come to an
object having internal structure. In this case, the object is another represented behavior

shown in Figure 5-11.

In Figure 5-11, the presence of motive flow fuel at the tube restrictor side of the Tank
No.3 wash filter leads to the presence of motive flow fuel at the inlet side of the sensor.
Motive flow fuel pressure bridges the fuel level sensor and flows to the transfer shutoff

valve, diaphragm and plunger.

103
Next we describe the behavior “enable fuel transfer to Tank 3 transfer shutoff valve”

shown in Figure 5-10. The plunger unseats a check valve, allowing transfer fuel pressure
entering the piston chamber to be relieved through a vent port. This causes the piston to

overcome spring pressure and open.

Finally we describe the behavior disable-fuel-transfer-to-feed-tank of the fuel transfer
shutoff valve. As the fuel level in the feed tanks rises to the fuel level sensor, the motive
flow jet stream is interrupted. This causes the shutoff valve diaphragm and plunger to
retract, closing the check valve. Fuel flow through the piston chamber is no longer relieved
through the vent port. This causes fuel pressure inside the piston chamber and inlet fuel
pressure outside the piston chamber to equalize. The static pressure area inside the piston
chamber is greater than the area outside the piston chamber at the shutoff valve inlet. Static

pressure and the piston spring pressure close the valve, stopping transfer to the tank.

Note that in the less detailed behavior shown in Figure 5-10, there is one partial state
which precedes the annotated link pointing to function control-motive-flow-pressure-to-
No.3-tank-transfer-shutofl-valve. Basically, this is an assertion that motive flow fuel is
present at the inlet side of tank no. 3 shutoff valve. Also note that other starting condition(s)
(if any) for the function can be found by following the knowledge pointer from the link

annotation and examining the knowledge source it points to.

We started in Figure 5-10 at the highest level of the control system for fuselage fuel
transfer. At that level, it was easy to determine the overall functionality of the control
system. However, given the modular nature of the functional representation, it was also
easy to follow one link annotation to deeper levels of detail in the system. The exposition
of the functional representation up to this point has followed a “browsing” characteristic.
In the following section, we will show how a functional reasoner makes use of the

representation we have just described.

104
5.2.3 Reasoning About The Fuselage Transfer Control System
Assuming a starting condition of “Present right motive flow at tube restrictor side of No.3
tank wash filter”, we now go through the steps of the consequence finding algorithm to

determine the effect on fuselage transfer system.
- Reasoning Step 1: specify the initial conditions.

The initial condition we set for this case is “Present right motive flow at tube

restrictor side of No.3 tank wash filter”.
- Reasoning Step 2: determine the “invocable” behaviors.

This step determines which of the functions and/or behaviors are applicable
with respect to the initial conditions given in the previous step. The behav-
ior shown in Figure 5-10 is one such behavior. Note that the Figure 5-10
behavior directly points to the Figure 5-11 behavior from its first level anno-

tation.

The first sub-step of Reasoning Step 2 is to index from the starting condi—
tions the behaviors and/or functions which are applicable. The second sub-
step is to filter out those behaviors/functions which are either directly or
indirectly pointed to by other members of the index set. Thus, since the Fig-
ure 5-10 behavior points to the Figure 5-11 behavior, only the top level
behavior of Figure 5-10 remains after filtering the sub-step. This illustrates

the concept of “filtering” that is used in the functional reasoning algorithm.

0 Reasoning Step 3: build a Particularized State Diagram (PSD).

105
At this step, the functional reasoning algorithm takes the initially indexed

behaviors/functions and produces a knowledge structure representing the
state changes the device will go through as a result of the stated initial con-

ditions.

Following the rules of Step 3 of our algorithm, we traverse the behavior of
Figure 5-11. At each point in the traversal, we expand any decomposable
link annotations. The result of the complete traversal is shown in Figure 5-
14. In this graph structure, the nodes correspond to partial states in the

behavior from which they were derived.

The PSD as shown in Figure 5-14 contains all state transitions which are
due to the initially indexed behaviors and all behaviors/functions those ini-
tial behaviors point to, either indirectly or directly. However, one may view
the PSD at varying levels of detail. The lowest level of detail corresponds to
the initial behavior(s) with all the knowledge pointers masked out. The case
we are examining here, the least detailed level, Level 0, is shown in Figure
5-12. Note the direct correspondence with the behavior shown in Figure 5-
13. The next higher level, Level 1, is shown in Figure 5-13 which corre-
sponds to all partial states used in Level 2 and those that are in behaviors/

functions pointed to from the annotated link at Level 2.

Let us look more carefully at the PSD under the three “magnifications.” At
level 0, in Figure 5-12, we observe the initial condition, the presence of
“right motive flow fuel at tube restrictor side of No.3 tank wash filter,” fol-
lowed by “fuel transfer to feed tank enabled”. Now suppose we would like
to know how this is achieved. We can answer this by showing the graph of
Figure 5-13, at Level 1 and in more detail in Figure 5-14 at Level 2.

106

 

Level 0

Starting Condition

 

 

right motive flow at tub restrictor side
of Tank3 wash filter present?

 

 

 

 

 

fuel transfer to feed tank enabled

 

 

 

 

Figure 5-12: Coarse grain view of a Particularized
State Diagram (PSD).

 

 

Level 1

Starting Condition

right motive flow at tub restrictor side
of Tank3 wash filter present?

 

 

 

 

 

 

motive flow pressure at inlet side of
Tank 3 shutoff valve produced

 

 

 

 

 

Tank 3 transfer shutoff valve opened

 

 

 

 

 

fuel transfer to feed tank enabled

 

 

 

 

 

Figure 5-13: The Particularized State Diagram
(PSD) after one round of expansion.

 

107

 

Level 2

Starting Condition

right motive flow at tub restrictor
side of Tank3 wash filter present?

 

 

 

 

 

 

motive flow pressure at inlet
side of sensor produced

 

 

 

 

 

motive flow pressure at outlet
side of sensor produced

 

 

 

 

 

 

motive flow pressure at Tank 3 motive flow pressure at inlet side of
fuel level sensor transducer Tank 3 shutoff valve produced

 

 

 

 

 

 

l

l

 

Tank 3 transfer shutoff valve opened

 

 

 

l

 

fuel transfer to feed tank enabled

 

 

 

 

Figure 5-14: The most detailed view of the Particularized State Diagram (PSD).

 

108
- Reasoning Step 4

Once the PSD is constructed, it becomes a relatively straightforward task to
determine what the consequences on the fuselage transfer will be due to the
presence of right motive flow fuel at tube restricted side of N 0.3 tank wash
filter. We require an auxiliary “scratch pad” — a simple database of values
for the state variables of the system. After initializing the database of state
variables, we traverse the PSD making appropriate updates to the database
at each node. Once completed, the consequences to the system can be read

off as the changes to the state variable database.
- Reasoning Step 5

At this Step in our process we take the results of step 4 (i.e. the cumulative
changes to the device) and use them as starting conditions for the next iter-

ation of these steps starting from Step 2.

5.3 Synopsis of Findings

In this chapter, we presented a snap shot of our implementation of the F/A-18 aircraft fuel
system. We initially implemented the fuel system in our FM environment running on a
XEROX 1186. We later ported the fuel system to a new PM environment which was
implemented on top of Allegro-Common Lisp running on Sun hardware. Currently, a new
implementation of the F/A-18 aircraft fuel system is running in the Smalltalk 80
environment (Goldberg & Robson, 1989). Since Smalltalk 80 is cross-platform
Compatible, our fuel system implementation is able to run on numerous hardware
Platforms. In this chapter, we only presented a very small portion of the full
implementation of the fuel system. In this thesis, we do not have enough space to present
the full implementation. The screen shots of the functions and behaviors of the fuel system

is over 200 pages in length.

109
There are three important items which we want to emphasize. The first item is the

approach we took to acquire the required knowledge about the fuel system. The second and
third items are our results concerning the scalability of our approach and results concerning
desirable extensions of the approach which inspired the next two chapters. In the following

sections, we present these three items.

5.3.1 Modeling Via Reverse-Engineering

We acquired almost all of the project’s detailed knowledge from a technical manual of the
PIA-18 fuel system. This technical manual consisted of various internal descriptions and
simplified schematics of the fuel system and its components, along with some information
about the operation of components. Although the technical manual was a great source of
information, it had a major drawback in that it did not include any direct information

regarding the intended functions of the fuel system’s components.

The knowledge acquisition strategy we undertook to build the functional model was to
reverse-engineer the functions of the fuel system from the technical manual. We first
obtained a top-level understanding of the fuel system and its constituting subsystems. This
top—level understanding helped us organize our causal understanding of the components at
the next level, and guided us to develop deeper levels of understanding. The process

continued until we reached the most detailed level.

5.3.2 Scalability

In the introductory chapter of this thesis, we noted two senses of the concept of scalability
that we hoped to address, scalability in terms of the size of the project undertaken and
scalability in terms of the diversity of the targeted domain. An important result was to
demonstrate that the Functional Approach to representing and reasoning about devices will
scale to (at least some) real world problems in the aerospace domain. Many of the Model-

Based Reasoning approaches have proven difficult to scale up from demonstration sized

110
problems.This has been especially true in the research aimed at digital electronic circuit

troubleshooting (Davis & Hamscher, 1988).

Prior to this research project, the Functional Approach had been applied to a number of
problem areas, the largest, in a domain sense, being a project to model the human body
complement system (a subsystem of the immune system). This physiological model
contained on the order of 20 components. The model of the fuel system contains on the
order of 100 components, and was constructed using exactly the same representational and
reasoning approaches as the earlier work. Therefore, our results have verified the
hypothesis that the Functional Approach is applicable to realistic sized systems in the

aerospace domain.

The second sense of scalability was that of being useful over diverse domains. The FIA-
18 fuel system is a distinctly engineered domain with unique characteristics as we describe
in Chapter 3 of this thesis. By successfully representing the fuel system, and utilizing the
reasoning mechanism provided by FM, we have shown that the Functional Approach is

applicable to (at least some) engineered systems.

5.3.3 Extensions

In addition to the concrete results we obtained concerning the scalability of the Functional
Approach, we also gained new insight into desirable extensions to our methodology

through our experience in the fuel system project.

First, we noted in our experience with the F/A-18 fuel system that at various points in
the representation a convoluted use of device—behavior—function was necessary to
re=prresent, what seemed to be, a simple example of fluid flow and connectivity of parts. The
difficulty which we encountered was largely due to a lack of any explicit representational
element in the Functional Approach to address the issues centering around ideas of flow

and connectivity.

1 1 1
Second, we noted when modeling the F/A-18 fuel system that many components are of

standard functionality. For example, there are many instances of various types of valves
throughout the fuel system. These valves may be of different structure, size, and so on, but
each functions as a generic valve. (In fact, that is why we call it a valve.) This observation
inspired us to suggest that the Functional Approach should be extended to include the
ability to create and maintain a library of standard parts. When a system designer needs a

valve, he/she could instantiate the appropriate valve from the library.

The insights gained concerning these desirable extensions are the springboards for the
next two chapters. In Chapter 6, we present our suggestions concerning fluid flow and
connectivity of components. Later, in Chapter 7, we address the issues centering around the

idea of the standard part library.

5.4 Conclusion

I

We started this chapter by presenting a portion of the functional model for the F/A-l8
aircraft fuel system. In the exposition which followed, we focused heavily on the
representation of behavior. We presented a small portion of the total representation for two
major functional units of the fuel system. The two examples in this chapter illustrated the
use of the functional representation, its primitive constructs and organization for the task of
reasoning about the fuel system. In other words, these examples showed how the functions
and their implementing behaviors can be viewed as modular chunks of knowledge and

combined to form a causal story of the fuel system’s behavior under the initial conditions.

We presented a synopsis of our findings at the conclusion of the modeling of the fuel
SYStem. We showed the effectiveness of the Functional Approach in modeling large scale
heterogenous domains. Furthermore, we tested the feasibility of the Functional Approach

in constructing functional models through reverse engineering. Finally, we discovered

l 12
valuable lessons which paved the way for possible extensions to the Functional Approach

which are addressed in the remaining chapters of this thesis.

Chapter 6

Connectivity and Flow

One of the shortcomings we found when applying the Functional Approach to the F/A-18
fuel system project, was the lack of explicit representational elements for representing
connectivity and flow. In the Functional Modeling (FM) framework, devices are
constructed by composing subdevices. The subdevices are themselves devices, they have
functions, and can be analyzed in the same manner as the device of which they are a part.
The function of the overall device is derived by composing the functions of its subdevices.
As stated previously, the initial representation was well equipped to handle device
decomposition, functional representation and reasoning. However, devices are also
equipped with “ports” or points of interaction where substances1 are passed in and out of
the device. The interconnection of the devices at their ports plays a major role in
determining the functionality of the overall device. The initial representation used to model
the F/A-18 had no notion of ports or flows passing from one component to the next. Below
We describe our extension to the basic representation, and how it aids in modeling and

Verification.

 

 

1- By the term “substances”, we mean physical substances and abstract substances such as information and
Signals.

113

114
6.1 Motivations for Connectivity

In this section, we present an overview of some of the motivations that inspired us to

propose the connectivity extension to Functional Modeling:

0 Model Validation: Verification of a model is the first step in model
validation. Verification is needed to ensure that the model behaves as the
model builder intended. The first step in model verification is to determine
if the model correctly represents the physical structure of the components
and the connections between its components. Of course, even if a model is
verified structurally, there is no guarantee that predictions made by the
model will themselves be valid.

- Diagnoses at the Ports: In many real-world diagnostic problems,
diagnosticians first isolate suspected components and then test them at their
ports (the points of interactions with other components). The input ports are
tested to determine if the necessary inputs are available. The output ports are
tested to verify the component is producing the anticipated results.
Explicitly representing the desired behaviors at the ports is instrumental in
this type of diagnosis. This is especially true in electrical and fluid networks,
where electrical and fluid flows and pressures are tested at the component’s

ports.

- Intuitiveness of the Model: Design engineers carefully document their
designs in terms of the individual components and required connectivity
(Mittal & Frayman, 1989). Explicit representation of connectivity brings the
functional models closer to their real-world device counterparts. The
naturalness of the model promotes the use of the Functional Modeling tool
by real-world engineers and also reduces the learning curve of the

Functional Approach.

115
o Multi-Paradigm Modeling: Devices are often composed of subdevices

requiring vastly different implementing technologies. It is often difficult to
model each technology within the bounds of a single modeling paradigm
and to predict the overall function of the device (Fishwick, N arayanan,
Sticklen, & Bonarini, 1993). Thus, it is often desirable to integrate several
different technologies with the Functional Modeling Framework. Explicitly
representing the interaction points and connectivity between models will

facilitate this form of integration from a software engineering viewpoint.

- System Understanding: Early expert systems have been criticized for
lacking an understanding of their own limitations (Top & Akkermans,
1991). In other words, unless the knowledge was explicitly represented in
the system, the expert system could not reason with it. Later in this chapter,
we show that connectivity is an equivalence relation. By equipping
Functional Modeling with the theory behind this equivalence relationl, we
allow the functional reasoner to reason about the connections between
components. This can result in the system deducing information not

explicitly represented in the models.

For example, if Component A is connected to Component B, and Compo-
nent B is connected to Component C, the system could deduce that Compo-
nent A is connected to Component C. This is especially useful in diagnosis
where the failure of a downstream device could be a manifestation of a fail-
ure in an upstream device. By having the ability to find these upstream

devices, the diagnosis of such a problem is possible.

 

 

1- A relation, 9t , over a set S, is said to be an equivalence relation over S iff it is symmetric, reflexive, and
transitive over S.

116
- Concurrent Modeling: Another important advantage offered by

representing connectivity and flow is that it allows different parts of the
model to be developed independently and then integrated to produce the
overall model. Thus, a group of modelers could develop different
submodels of the overall system independently. Then, when these
submodels have been developed and tested, they could be integrated into the

Functional Model of the overall system.

0 Component Model Assembly and Design Modification: Like many other
engineered artifacts, the fuel system components are interconnected to each
other. Explicit representation of the connectivity allows engineers to quickly
connect together functional units. Furthermore, it provides the ability to

perform quick reconfiguration for design modifications.

0 Standard Part Library: Finally, the most important motivational factor
for representing connectivity is its role in the standard part library. In our
standard part model selection algorithm, described in the next chapter, we
use the connectivity constraints to build a list of structurally fit standard part
models. This approach is based on the fact that the standard part models
must fit structurally into the overall device model before being considered

as a candidate model.

Structural constraints are represented by their input ports and output ports.
Thus, the component's interactions must be explicitly represented in the
device model. Moreover, since the type of substance flow imposes further
constraints on integrating the standard part model into the overall device

model, we need to explicitly represent the type of substances present at the

ports as well.

117
6.2 A New Relationship Between Components

Previously, the relationships between components included only the component/
subcomponent relationship in FM. We have extended the relationships available between
components to include the connections between components at their ports. Each
component has associated ports, and a set of connections between the ports. We define a
port as a point of interaction where connections are attached or components are connected.
The passage of substances takes place through ports and connections. A port is identified
by a number unique to the device and by the type of substance flowing through the port.
The types of ports include Input ports, Output ports and Input/Output ports. The substance
describes the kinds of connections a component can participate in, such as electrical flow,

fuel flow, etc.

Each device has a characteristic behavior, in the sense that actions at the input ports
invoke the functions of the device and induce behavior at the output ports. In other words,
the device delivers its functions at its output ports. The disturbance at the output port of the
device can be transferred to the input port of another device to induce behavior at output
ports of the second device. These two connected devices form a composed device.
Therefore, the behavior of the composed device is determined by the subdevices’ behavior,
together with the manner in which the subdevices are interconnected. Hence, we can infer

the behavior of the overall device from the functions of its subdevices.

We extend the previous definition of a device presented in the previous chapter.

Formally, we define a device as a quintuple,
(D, C, F, P, R) where:

o D is the name of the device, which is a domain dependent string of

characters.

—‘— V“

1 18
C is the set of components of the device. Each component is a device by

itself.
0 F is a set of Functions of the device D.
o P is a set of Ports of the device D.

o R is a set of relations between components (i.e., ConnectedTo)

6.3 Connectivity Definition

)l

Device connectivity hinges on two core concepts: subdevices and input/output port
connections. A device is decomposed into subdevices which themselves are devices. The
port connections define the interconnection links between subdevices. Each port

connection is a quintuple:
(F, C“, Pu, Cd, Pd) where:
o F defines the type of substance flow at the port (electrical, fluid, etc.)
0 Cu defines the upstream subdevice linked by the connector.
- Pu defines the upstream port.
0 Cd defines the downstream subdevice linked by the connector.
- Pd defines the downstream port.

Recall that a port is identified by a number unique to the device, the port’s type, and the
type of substance allowed at the port. The types of ports include Input ports, Output ports
and Input/Output ports. The substance allowed at the port describes the kinds of
connections a component can participate in, such as electrical, fuel, kinematic, etc. One
purpose of the substance is to facilitate consistency checking of the device’s structure. A

major advantage of this extension to FM is the opportunity it provides for connections to

l 19
be checked, which is the first step toward model validation. By introducing a substance

flow variable for each port connection, consistency checking can include insuring that the
variables at the two connected ports are the same. Although we extend the Functional
Modeling framework to include ports and substance flow, both ports and substance flow are
defined within the device. Therefore, the device representation retains its distinct

advantage of compactness.
In our representation, the input ports and output ports are represented as pairs
(N, o) where:

0 N is the number of ports.

0 9 is an array of size N containing pairs of the form:

(I‘, P") where:

r F is the type of substance.
' Pu is the port number.

We illustrate the idea of connectors and ports by considering a simple device, containing

five subdevices, connected as shown in Figure 6—1.

6.3.1 Example of Connectivity Representation

. In this example, we have decomposed the device D into five subdevices. There are five
connectors that connect the five subdevices to each other. The first connector, for instance,
connects port number 2 of subdevice d1 to port number 1 of subdevice d2. Since the type
of substance flow of the two connecting ports matches, the connection is a valid connection

and does not violate the physical structure of the device D.

120

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Si :11 signal
1 d2 2 g“ 12 d5 3 —>
signa
fuel 2
1 d1 3 fuel
ax ,u

el

fuel

Figure 6—1: Example of connections and ports.
0 Device: D

Subdevices: (d1, d2, d3, d4, d5)

Connectors: (ct (signal, d1, 2, d2, 1), ct (fuel, (11, 3, d3, 1),
Ct (Signal, d2, 2, d5, 1), Ct (fuel, d3, 3, d4, 1), Ct (fUCl, d3, 2, d5, 2))

Input Ports: (1, fuel, 1)
Output Ports: (2, signal, 3, fuel, 2)

Functions: unspecified

0 Device: (11

Subdevices: none

Connectors: none

Input Ports: (1, fuel, 1)

Output Ports: (2, signal, 2, fuel, 3)
Functions: unspecified

0 Device: d2

Subdevices: none

Connectors: none

 

121
Input Ports: (1, signal, 1)
Output Ports: (1, signal, 2)

Functions: unspecified

0 Device: d3

Subdevices: none

Connectors: none

Input Ports: (1, fuel, 1)

Output Ports: (2, signal, 2, fuel, 3)

Functions: unspecified

0 Device: d4

Subdevices: none
Connectors: none

Input Ports: (1, fuel, 1)
Output Ports: (1, fuel, 2)

Functions: unspecified

0 Device: d5

Subdevices: none

Connectors: none

Input Ports: (2, signal, 1, fuel, 2)
Output Ports: (1, signal, 3)

Functions: unspecified

6.4 The Connectivity Relation

Our proposed connectivity scheme explicitly represents the connectivity relationships that
exist between connected components in the overall system. This relationship is a binary

relationship. In our representation, the connectivity relation is represented as:

C( (du, p), (dd, q)) where:

122
o C is the connectivity relation].

- du is the upstream device with connecting port p, connected to port q of

device dd.

- dd is the downstream device with connecting port q, connected to port p of

device d“.

The two devices, du and dd are different devices, p and q are two connected ports from the

two different devices.

Let P be the set of all ports of the device du and Q be the set of all ports of the device dd.
The connectivity relation C on the two sets of ports, P and Q, is a subset of the Cartesian
product P x Q. Therefore, by definition, C is a binary relation (Cormen, Leiserson, &
Rivest, 1990). We identify the following special properties of this relation:

0 The relation C is reflexive. Since every port p of a component d is connected
to itself, we make the following definition C (d, p, d, p). Therefore, the

relation C is reflexive.

- The relation C is symmetric. If a port p of component d, is connected to a
port q of component d2, then port q of component d2 is connected to port p
of component d1. Therefore, C (d1, p, d2, q) 4: C (d2, q, d1, p) which

implies the relation C is symmetric.

o The relation C is transitive. Simply stated, if port p of device d, is
connected to port q of device d2, and port q of device d2 is connected to port

r of device d3, then port p is connected to port r. Therefore,

k

l. The connectivity relation C is equivalent to the connectors discussed in Section 6.3 except for Simplicity
we disregard the type of substances flowing between the connected components.

123
C ((1,, p, d2, q) A C (d2, q, d3, r) = C ((1,, p, d3, r) which implies the

relation C is transitive.

We have shown the relation C is reflexive, symmetric and transitive. Therefore, the

relation C is an equivalence relation by definition.

6.4.1 Observations about the Connectivity Relation.

Observation 1: The transitive property of the connectivity relation allows the transitive
closure of the resulting connectivity network to be computed. The connectivity network is
a directed graph G = (V E), with vertex set Vof ports, and edge set E of links between two
ports. Suppose we wish to determine whether there is a path in G from port P,- to port PJ- for

all vertex pairs (Pi, P1) in V. The transitive closure of G is defined as the graph:
G* = (V, E*) where
E* = {(Pi, PI.) I there is apath from port P,- to port PJ- in G}.

The transitive closure of a graph can be computed in 0 (n3) time by known methods
such as the Floyd-Warshall Algorithm described in (Cormen, et al., 1990). The transitive
closure allows us to determine which devices are connected along a path. As stated in the
motivation for connectivity, this is especially useful in diagnosis where the failure of a
downstream device could be a manifestation of a failure in an upstream device. By having
the ability to find these upstream devices in the representation, the diagnosis of such a

problem is possible

Observation 2: If a device with m ports has k connections to a device with n ports,
where k < m and k < n , then there are m + n - 2k open ports in a system consisting of
these two devices. This is the result of the binary relation property of the connectivity
relation. By using this observation, we can determine the number of input and output ports

of a composite device.

124
6.5 Example: Pressure-Balance-Shower-Valve for Household

Shower Faucets
This example describes a new shower faucet designed to automatically maintain bathing
water temperature during sudden external changes in the demand for hot or cold water. We
utilize our proposed extension to Functional Modeling to construct a complete functional
model of this device. This example will also motivate the discussion in the following

chapter.

6.5.1 Overview

When showers share the same water line with other plumbing fixtures, an abrupt change in
the demand for water — such as flushing a toilet or turning on a whirlpool — changes water
line pressure. A pressure change in the water line can drastically affect the bathing water
temperature — by up to i15°F according to some shower faucet manufacturers. This causes
a soothing shower to become uncomfortably hot or cold. Pressure balance valves balance
water line pressure to eliminate uncomfortable and dangerous bathing water temperature
fluctuations. As a result, bathing water temperature remains consistent within a
comfortable and safe range (i.e., within i3°F as defined by ANSI/ASSE standard 1016
(Wright, 1994)) despite sudden changes in the demand for water.

The integral structure and the core behaviors of the Pressure-Balance-Shower-Valve
for this case study are based on a well studied class of valves called Directional Flow
Valves. References (Blackburn, Reethof, & Shearer, 1960; Oster, 1969; Pippenger & Koff,
1959; Wolansky, Nagohosian, & Hanke, 1977) provide detailed information regarding
applications, design issues, functions, and the structures of directional flow valves. The
main function of a directional flow valve is to direct the flow of liquids in hydraulic
systems. They may operate hydraulically (by difference of force set up on opposite sides of
some movable parts), manually, or by mechanical means. Directional flow valves are of

two designs — spool and rotary. In the spool design, a specially shaped sliding spool moves

125
back and forth inside a cylinder, opening and closing passages through the valve. The

shower valve in this example is of the spool design, with four separate working ports and
a three position spool. The position of the spool inside the cylinder determines the number
of alternative flow conditions. This type of valve is referred to as a three-position, four-way
valve. Figure 6-2 illustrates a photo of the shower valve and in Figure 6-3 we show a

component connection diagram for the entire device.

6.5.2 Operation

Figure 6-4, taken in conjunction with Figure 6-3, shows how the Pressure-Balance-
Shower-Valve works. When the spool inside the cylinder is hydraulically balanced (i.e.
hydraulic forces are equal and the spool is in an intermediate position), flow through the
valve from Check-Valve-hot and Check—Valve-cold are directed to outlet port hot and outlet
port cold, respectively. This situation is shown in Figure 6-4:a. In Figure 6-4:b, with the
spool to the far left in the cylinder, liquid from Check- Valve-hot flows from inlet port hot
through the left end of the cylinder, directed into outlet port hot, while the input passage for
port cold is restricted. In Figure 6-4:c, with the spool to the far right of the cylinder, the
situation is reversed. In this case, the liquid from Check-Valve-cold now flows to outlet port
cold, while the input passage for port hot is restricted. When an input pressure drops to 0
PSIG, the spool moves completely over to block flow from the other inlet. The balancing
force in this case comes from the housing. This is also an ANSI/ASSE 1016 requirement
(Wright, 1994). '

126

o>fi>¢oB£W8§fiflé=82m 05 .«o 395 ”Ne 0.5mm"—

aa>a> n85

38m

maize:
mammaom

33> 35:00 36E 33> 3.5.80 303

 

52:6 is 232 Sea? 93> 3580 3am

127

 

 

 

Unit ‘

r

Check Valve Check Valve
Backflow InletPort-A InletPort-B
Preventlon 2 {

 

“‘

    

Spool

Pressure Equalizer UnitU
|

/ \

Flow Control‘ (Flow Control
Valve-A L Valve-B

 

 

   
   
 

 

 

Flow Control Unit

 

 

    

 

 

 

 

Mixing Unit

 

 

Figure 6—3: Component Connection Diagram for the Pressure-Balance-Shower-Valve

 

128

 

 

From Check- From Check-
Valv -cold

 

Figure 6—4: (a)

 

Figure 6-4: (h)

 

Figure 6-4: (c)

 

Figure 6-4: Cross-section of three-position, four-way valve

 

129
6.5.3 Component Decomposition of the Shower Valve
Figure 6-5 shows the component decomposition of the Pressure-Balance-Shower-Valve.
We decompose the entire shower valve into four functional units. These four functional
units are labeled as shown in Figure 6-3. Then we decompose each functional unit into

subdevices.

6.5.4 Conceptual Diagram of the Pressure-Balance-Shower-Valve

Before presenting the top level function and implementing behaviors of the shower valve,
we describe a high-level conceptual diagram which is constructed directly from the
component connections diagram of the Pressure-Balance-Shower-Valve shown in Figure
6—3. Figure 6—6 illustrates the conceptual diagram of the shower valve. The arrows in the
diagrams represent the flow of substances between the components, and are labeled with
the type of substance that flows at the ports. The connectivity points (i.e., ports) of each
component are numbered and referenced later accordingly. For example, the Pressure-
Equalizer-Unit has two input ports and two output ports. The input ports are numbered 1
and 2. The type of substances which flow into these ports are hot-water and cold-water as
shown in the diagram. Further, these input ports are connected to output ports 3 and 4 of

the Backflow-Prevention-Unit.

130

o>_a>¢030:m-oo=a_am-2:mmo£ 05 .8.“ 5289:0000 Eocene—cu ”we gamma

 

 

 

as: «:32
33>» 260 a. How...
teamsmaé
mo>_a> .8280 30E...
AoEm 835 30an /
em 33> 35.50 32m... LED
3.5.50 Born—a.
Aofimm nous? HOE \\
e95. _..< 02.9 .2280 32m...
EOEQEOUHBEB Home
:0 Eco a e o ...o>_m> 5305
«25 in 55 U 8 B. m... Bone—em 2:32;...
.eesgaaeuesaa 8:...
to???
“LED
“unsung c.5305
*OBH. Loam... s
“cogmaonvuoumg 200*
«SeoEQEoU page? 200...
Q «0:0
Eon—ta So 2... e

U. 3 E 0... 32m use? 28%

em o>_a> x0050...

LED
AoEm has? “3.6 =ou=o>2m 36E x93...
_..< o>_d> u30:0...

 

 

131

 

 

hot water I
l

cold water

 

 

 

 

 

 

 

 

 

 

 

 

 

 

l 2
Backflow Prevention Unit
3 4
u
l
hot—water 1 cold-water
1 2
Pmsure-Equalizer-Unit
3 4
t
I
I
hot-water; cold-water
manual 1 2

F___i J, \

adjustment

 

adjustment
""'"' -—>’ 5 FIow-Control-Unit 6 k

 

 

 

 

 

 

 

 

3 4
hot water? cold water
1 2
Mixing-Unit

 

 

 

 

 

Soothing water at shower

 

 

Figure 6-6: Conceptual Diagram of Pressure-Balance-Showcr-Valvc

 

132

6.5.5 Functionality of the Pressure-Balance-Shower-Valve

Figure 6—7 shows the Device-Function-Behavior representation of the Pressure-Balance-
Shower-Valve. This device is responsible for one high-level abstract function: Maintain-
steady-water-temperature-at-the-shower. This function is implemented by the behavior:
equalize-hot-and-cold-water-pressure-in-the-compartments. Figure 6-8 illustrates the
high-level description of this behavior. There are four preconditions listed at the top of the
figure which must be satisfied before the behavior is activated. As the figure shows, the
behavior of the Pressure-Balance-Shower-Valve is achieved by the functionality of its four
major subcomponents (the Backflow-Prevention-Unit, the Pressure-Equalizer—Unit, the
Flow-Control-Unit, and the Mixing-Unit). The functions and the implementing behaviors

of the lower-level subdevices are shown later in this chapter.

133

.o>_a>.332__m-oo§_am-o§mmo.& 05 mo Sfianom-=ouo§m.3m>on ”We Bani

 

 

fiaognaoobfiévosmmoa
.8336Buéaaéonmanagao I.6305-ofi-fi-o.§8&88¢o§3->33?58=32I ...o>3>¢oBoaméo§R92835...

 

 

5330mm sarcasm $0309..

 

 

134

8cognfiOYofi-cm-pfiga-asmuahaai63065-00:-mcfinaaro 20 000855055 ”me 2:92

 

 

fl .0303 .0 2803 9:508 #

 

£03552 «0
2803-2020502-005800 “souocnm 03

 

 

% o A An :05 A2325 5.03-203 JEs-wcig _

 

 

_ o A 2 :05 A2335 cask-05 .zca-wixzzv

 

   

:=D-_0b=00-30E ”.5
2385-0550-2033-0_0o-0§-.0:-_0b:00 ”zone—Sm E

 

o A AN :05 A23325 «BER-200v .::=-_0b=00-30EV _

 

 

_ o A 2 :05 A2385 2203-005 J_=:-_0b:00-30Ev

 

 

HEB-20230092385 co
23325-3305 “00355 .3

 

o A 2 :05 A23325 583-208 .oco-Eocfiumfioo-BHB-Eoov _

 

 

fl o A 2 :05 A2385 cogs-.05 .oco-EoEwamEoo-BEB-va F

 

 

gab-coucgoE-Bocxoum «O
000020-309:Tbs-330255 ”0000.5"— .3

 

AN :05 A23m25 2803-208 .m-o>_a>-0_8:Uv
A 2 :05 A2385 5003-203 .m-o>_a>-0_8:UV

 

 

 

o A 2 :05 A2335 cogs-200v .m-ozg-xoosov _

 

  

 

 

AN :05 A2325 0203.005 {dig-032.9
A 2 :05 A2325 0803-005 4-029-328

 

 

— c A 2 20..— A2332; 3003-85 .<-o>_a>-xoo:UVL

 

 

 

135

6.5.6 The Functionality of the Pressure Equalizer Unit

Since the Pressure-Equalizer-Unit is the most complex unit in the Pressure-Balance-
Shower-Valve, we begin with the functionality of the Pressure-Equalizer-Unit and its
subcomponents. We present its high-level and low-level behaviors in their entirety. Figure
6—9 presents a conceptual diagram of the Pressure-Equalizer-Unit. The arrows in the
diagram represent the flow of substances between the components. These arrows are
labeled, indicating the type of substance which is flowing between the two ports. The ports

of each component are numbered and referenced in the text below accordingly.

In the example, we represent values as (substance, attribute) pairs where substance is
the particular substance of interest and attribute is a particular attribute of the substance we
would like to measure. For example, (cold-water, pressure) represents the pressure of the
cold-water. In some cases, the representation (substance) is used if the substance is directly
measurable. We represent values at ports by (Component, (substance, attribute), Port No.),
where Component is the device under study, Port No. is the port, and (substance, attribute)

is as described above.

During the modeling of the Pressure-Equalizer—Unit, we assume a qualitative space
defined to be a set of discrete values for all variables. For example, the (cold-water,
pressure) ranges from 0 (meaning there is no cold water pressure) to 10 (meaning

maximum cold water pressure). Other values also taking on this range are:
- (hot-water, pressure)
- (mechanical-energy, energy)
- (control-signal).

The spool position is also measure within a qualitative space ranging from -5 to 5. At 0,
the spool is in the middle position. This is the default initial set-point, and will be used as

the initial condition during the reasoning process.

136
6.5.7 High-level View of the Pressure-Equalizer-Unit
In Figure 6—10, we show the Device-Function-Behavior representation of the Pressure-
Equalizer-Unit. The function of this component is to equalize the pressure between the hot
and cold water that comes into the unit. The intent is that sudden changes in the pressure of
the cold (hot) water will be balanced with an equal change in the pressure of the hot (cold)
water. Figure 6-11 shows the behavior seeking-equilibrium-between-hot-and-cold-water-

pressure which implements this functionality.

The figure of the Pressure-Equalizer-Unit’s behavior indicates that pressurized hot water
must be at the input port of Hot-Water-Compartment-One and pressurized cold water must
be at the input port of Cold-Water—Compartment-One. If these preconditions hold, then the
function Convert-fluid-energy-to-mechanical-energy of the Cylinderl will use the
pressurized fluid to transmit mechanical energy to the inlet port of the Spool. The function
Convert-mechanical-energy-to-control-signal of the Spool is activated by the input of
mechanical energy. The Spool’s behavior resembles that of a piston by converting the
mechanical energy from the Cylinder into linear motion. It is the amount and direction of
the motion that determines the control signals sent to the signal ports of Cold-Water-
Compartment-One and Hot-Water-Compartment-One. The Hot-Water-Compartments and
Cold-Water-Compartments have functions which direct the water through these
compartments. It is these functions which interpret the control signals and change the

pressure in the compartments accordingly, resulting in the equalized pressure.

The previous paragraph has illustrated one of the biggest advantages of Functional
Modeling, its use in explanation. We were able to explain, at a very high-level, the
functionality of the Pressure-Equalizer-Unit. After this high-level description is fully

understood, we can then follow the “By Function: sz” calls to investigate how the

 

1. A Cylinder is defined as a device which converts fluid energy to mechanical energy as defined by the
National Fluid Power Association as found in (Pippenger & Koff, 1959).

137
subcomponents are performing these functions. In the following section, we detail these

function calls.

138

 

 

W

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

hot water cold water
1 1
Hot Water Cold Water
Compartment Compartment
One One
3 2 2 3
I
: I
I control signal control signal '
hot water 3 2 cold water
Spool
4 1
mechanical mechanica
energy energy
6 5 2 1
Cylinder
4 3
hot water cold water
1 1
Hot Water Cold Water
Compartment Compartment
Two Two
2 2

 

 

 

 

 

 

f

hot waterl

f

 

J

l cold water

 

Figure 6-9: Conceptual Diagram of Pressure Equalizer Unit

 

139

“ED-2033792385 .20 “03309003009338 5— .0 20w?—

 

 

2:325.333-200-03-00n-coogon-Estfizsco-wcioom

22>Eom

2385-32303

 

 

*0203-232305-23329,

 

00000:"—

*8309...

 

 

140

2:35.833660-2320200053-E=tn=3co-w=203 ”.20 002352052 ”2.0 2:25

 

 

AN :05 A2385 833-203 .030-EoEt5Eoo-833-20Uv AN 205 A2385 833-005 .030-3035500-833-005
"23:5 68:25

 

    

88355002033230 «0
aE:202303-29020-2233-200-325 20:00:"— .3

853580083320: «0
2::2023:8-cmsohE-22a3aos-fi25 20.3.55 3

 

000-00ofifi5E00-ho33-00: 23
0:0-3035E00-833-200 20 305 .253 3 3.53 32:00

_

 

saw 20
3:23-8238-00-33:232—350:.-20200 E0803”— 3

 

 

.005m 20 3205 3:: 3 388 323:82

 

285:0 ”00
38:0-323:88-9-388-2:c-2350 203255 .3

 

 

o A 2 :05 A2385 833-203 600-0835282833-209 _ _ o A C :05 A2385 833-85 ace-30358002033205

 

 

 

 

141

6.5.8 The Functionality of the Pressure Equalizer Unit’s
Subcomponents

We proceed to discuss each of the major subcomponents of the Pressure-Equalizer—Unit in
turn. We begin with the Cylinder (Figure 6-12 - Figure 6-16). The primary function of the
Cylinder is to Convert-fluid—energy—to-mechanical-energy. We have adopted this definition
from the National Fluid Power Association (Pippenger & Koff, 1959). In Figure 6-15 and
Figure 6-16, we show the two behaviors which implement this function. The first behavior
we discuss is greater-fluid-energy-at—cold—water-side. As the name denotes, when there is
greater fluid energy at the cold water side, this behavior will be invoked. As shown, when
the initial conditions are true, the behavior will cause the mechanical energy at the output
Port 2 to equal the difference between the pressure at the hot-water side and the cold-water
side. Recall that we have defined a qualitative space from O to 10 for water pressure. Thus,
we will obtain a value for the mechanical energy somewhere between 0 and 10 at the cold
water side of the cylinder. The behavior greater-fluid—energy-at-hot-water-side is
analogous to the one we just described. In this case, however, the mechanical energy is at

output Port 5, which is on the hot water side of the cylinder.

After the Cylinder has created mechanical energy at one of its output ports, the Spool
(Figure 6-17 - Figure 6-19) is ready to perform its function, Convert-mechanical—energy-
to-control-signal. Figure 6-18 and Figure 6-19 show the behaviors which implement this
function. The mechanical energy from the Cylinder will either be at the cold-water side of
the Spool or at the hot-water side of the Spool. In the first case, the behavior mechanical-
energy-at-cold-water-side-of-spool is invoked. As Figure 6-18 shows, the mechanical
energy will move the Spool left from its current spool position by an amount equal to the
mechanical energy coming into the Spool. Since the Spool is blocked by the housing at the
left, the Spool will stop as soon as it hits the position -5 in the qualitative space. The
position of the Spool is then converted to control signals at both output ports 2 and 3 of the

Spool. Once again, the behavior mechanical-energy-at—hot-water-side-of-spool is

142
analogous when the Cylinder transfers mechanical energy at the hot-water side. However,

as shown in Figure 6-19, in this case the Spool will move right.

The control signals from the Spool are passed to both Hot-Water-Compartment-One and
Cold-Water—Compartment-One as shown in the block diagram (Figure 6-9). Thus, we next
describe the functionality of Hot-Water-Compartment-One (Figure 6-20 - Figure 6-21).
The Cold-Water-Compartment-One’s functionality (Figure 6-22 - Figure 6-23) is
analogous, so it is not described here. The control signal from the Spool will be presented
to Hot-Water-Compartment—One’s Port 2 along with pressurized hot water. The control
signal will be a value from O (entirely closed) to 10 (entirely open). The amount of water at
the output port of the Hot-Water-Compartment-One is defined to be a function of this inlet
water pressure and the control signal. Close observation of the functionality of the spool
will show that the movement of the spool will cause a change in the control signal at both
the hot-water side and the cold-water side. The actual function shown in Figure 6-21 is
chosen so that the control signals will cause the hot-water side to make up for half of the
pressure difference and the cold-water side to make up for the other half of the pressure

difference.

At this point, hot-water is at output Port 3 of Hot-Water-Compartment-One and cold-
water is at output Port 3 of Cold-Water—Compartment-One. The Cylinder now performs its
second function, Transfer-hot—and-cold—water. This second function is straightforward and
is implemented by the behaviors transferring-hot-water—at—hot-water-side and
transferring-cold-water—at-cold—water-side depicted in Figure 6-13 and Figure 6-14. When
pressurized hot-water is at input Port 6 of the Cylinder, then pressurized hot-water is at
output Port 4 of the Cylinder. The behavior in Figure 6—14 for the cold-water side is

analogous.

Finally, when pressurized water is at the output ports of the Cylinder, the water is ready

to enter Hot-Water—Compartment-Two and Cold-Water-Compartment-TWo. We will

143
describe the functionality of Hot-Water—Compartment-Two. The functionality of Cold-

Water—Compartment-‘I‘wo (Figure 6—26 - Figure 6-27) is analogous and will not be
described here. Figure 6-24 and Figure 6-25 depict the functionality of Hot-Water-
Compartment—Two. The function of this component is to simply T ransfer—hot-water though
from the input port to the output port. As Figure 6-25 shows, when pressurized hot-water

is present at input Port 1, then pressurized hot-water is present at output Port 2.

In Figure 6-28 and Figure 6-29, we present the composite device Hot-Water-
Compartments. This device is composed of Hot-Water-Compartment-One and Hot-Water-
Compartment-Two. The function of this composite device is to Direct-hot-water—through-
equalizer-unit. Figure 6-29 presents the implementing behavior of this function. As shown,
this behavior is a high-level description of the causal story defined in the last three
paragraphs. Figure 6-30 and Figure 6-31 present the same description for the cold-water

side’s Cold-Water—Compartments.

6.5.9 Summary

In the proceeding three sections, we presented the most complex functional unit of the
Pressure-Balanced-Shower—Valve example, the Pressure Equalizer Unit. In this section we
crystallize the important aspects of the way in which the Pressure Equalizer Unit achieves

its functionality.

The Pressure Equalizer Unit consists of four compartments, a cylinder, and a spool
inside the cylinder. Figure 6-9 showed the components of the Pressure Equalizer Unit
along with their connections. The function of the Pressure Equalizer Unit is to control the
flow of hot and cold water which are passed through its four compartments and its cylinder.
As demonstrated by our functional representation, this unit achieves its functionality by

moving a spool inside the cylinder. Furthermore, we showed that the movement of the

144
spool inside the cylinder restricts the flow of hot and cold water, and results in equal

pressure in the two hot and cold water compartments accordingly.

145

80550 .«0 22359008556038 “~70 2:me

 

 

o 33533-00 3438:0- S .832w
n. a 0. c V 385-303288-9-380925c-2350
0232033-28-3-hw88-E:c.2032»
£3.83B-uon-ua-uouma-wgoumcab / £00530...

\ 8336—0063-02223325-

 

02m.2833-20932033222335

 

Hoganom 00:00an l 2.00309,

 

 

146

0032833-0—00-3-2833-522820 #0 0035008295 “mA-e 20mm"—

 

 

 

: :2 .6522 saga-280 62:60 |.v a com Aegean 533.280 .3239

 

 

32:6 cc 82500 3

 

 

 

o A 2 com .2385 seas-280 52:60

 

 

 

 

147

£32033-0093-2833-552835 ”.20 000358055 ”3.0 oSmE

 

 

 

6 :8 2:32.. 533.85 52.350414 com Aegean. ease-85 58:60

 

 

32:6 3 5%qu B

 

 

 

o A G :8 Aeneas cans-85 52:80

 

 

 

 

148

023-2833-02-3-Eoco-20c.2802» «0 0058008055 £70 20wE

 

 

 

: Em .3582 533.280 .5360 - 3 com .3520... 333.85 322.60 am
Am 205 A388 Swuoco-auofiv 80539 "0820:—

 

8335 50 333 .3

 

 

3 e8 .3532 .§§-2§ 52:60 A G to.— Aegean cans-65 SEQ

 

 

 

 

 

 

149

3mm.§a3-2ou¢a-§o=oém=:38“an mo mounds—moan: 67o anE

 

 

 

3 tom A2885 ..§a3-~05 5.25.59 - 3 tom A8385 533-208 .325»an ram
AN tom 638:0 .§=?:8Ev 59:38 ”83.85

 

863m m0 253 .3

 

 

3 tom .Aaasa .§§-.c5 Eucafiv A 2 tom A238...“ .gsésv 52:»8

 

 

 

 

 

 

 

 

150

.025 .«o Hom>£om-:ouo§m-3m>un ”:6 0.5me

 

 

30%.uobEm.HBaBé—ooé-anufioawnooa /
30%.HoéEmLofia¢on¢¥§o§-308238 \

Rama-3chVou->muoao-~wo§:ooe-to>=ou

 

HOS—Eon

canon—E

 

18%...

.835...

 

 

151

30%.3.oEm¢BuB-3._.§-gocoufiomfifioofi ".3 confine—=33: “w _ .0 guru

 

 

 

fl 2:338 .395 - C IV AN com 353-3550 .339 _ _ 2.528.“ .383 + 9 IV 3 com .R:w_m-_ob:oo .389

 

     

30mm 3 :oumccon— mm 30% 3 525.39 am

 

:9. tom 635:0 .mwuocoéoofiv .30awv + Acoummoa .30%& .0 :3: ”oh
Acacia .325 ”Ewing—2

 

 

 

39$ .3 52.68 am

 

 

fi 0 A Av tom .9925 imagine—5 .389

 

 

 

152

.000m.3.02m¢303-200.§->80:o._ao§oofi ”.3 000858200: ”2.0 803"—

 

 

35280 .3003 - 9 Iv AN :00 .R=w_m-_0b:00 .3009 _ _ 200280 .3003 + 9 Iv Am :00 3.56-3008 .3009

 

 

     

300m .3 coumccoa hm 300m 00 003539 am

 

22 :00 .9925 $3000-:85v .3009 - 90280 30039 .w-v 525 ”00.
30.0600 .3003 ”tux—0.62

 

 

300m 3 002.63 mm

 

 

o A 2 :00 .9928 xwhocufioofiv .3009

 

 

 

153

o=O¢=o§0fioun§§>¢0= 3 33209335000309 ”0N6 8:30

 

 

83.833-32-323on

3330mm

33.533-33.05000

 

GOUOGSH—

*o:O..EoE§0E¢U¢2§9¢0r—*

 

.3038...

 

 

154

uo_=_..§a3..oa-w£=ob=8 ac nous-“2:295 ”ab 0.53"—

 

 

AR: ZN :om ._«:w_m-_ob:ou .oco-EoE§mEooL8aB-~o=vv
* 2 tom A8385 £295-85 .oc9acognfionz2ukéomvv
Iv Am tom A8335 533-85 .oco-EoEtamEoo¢2~B-.ov—V

 

 

 

82282 22m mo 03.2320— 3

 

o A AN ton— ._a=w_m-_ob:8 .o=o¢=oE:amEoo..§aB¢o:V _ g o A 2 tom A2385 £033-85 .o:°.EoEtamEoo..§aB-8=v

 

 

 

 

155

0:0..EongoUL8aBéEU mo hom>£om-=ouo§m-oo_>ofl ”mmé 83E

 

 

83.833-209wfizobc8

8330mm

33.333-28.3b80

 

aoaoasm

l*o:O-EoE§QERu.B§3-EOU*

 

*8309

 

 

156

~0E_¢8a3-28-m£=g=8 do cou8=oEoEE_ ”mmé Bani

 

 

 

a: ZN com .B:m_m-_ob=ou .o:o-~:o§q88¢3~3-2005
* C :om A2335 533-208 .o:o¢=oEuumEoo¢8mB-u—ouvv
IV Am tom A2335 583-203 .oco-.:o=EmQEoo¢8a3-v—ouv

 

 

 

mag—«€02 25E mo onto—Bog 3

 

_r o A AN tom .RcmGAEEOo .o:o-Eo=E~mEooL8~B-c—oov _ _ o A 2 tom A2383 533-208 .oaoéungoEBmBéBUv

 

 

 

157

89:30 mo Hom>Eom-:owu=:m-oo_>oQ “vmé Baum

 

 

833-85%:anm55

8323mm

 

HuuwkI—Ofluuommghh.

 

couoasm

*og-u:o§qaou.u8§?¢om*

 

“neutron—x.

 

 

158

883..o:-w:_b£m=g ”.8 83858085 ”3% 95me

 

 

 

 

3 tom 6033-85 .ofiw.£o§mfioU.§aB.8—.c

 

 

80:53:80 8 cog—con .3

 

2 tom €083-85 .o3.—..~5§qfioU.§a3-8mc

 

 

 

 

 

159

89:30 8 8m>acoméouu==méom>oa “cmé gamma

 

 

8853-Eoo-wfib£m§b

8328mm

 

 

885m

 

833-28.8wmcfih Il*o3,_.-80§mEoULBmB-EOU*

*859

 

 

160

833-209wfibou8g ”.8 82386295 ubmé oSwE

 

 

 

 

3 tom A§a3683 .~.8w§qfioo¢o§3-2ouv

 

 

825.8800 8 82.599 .3

 

 

2 tom A833688 .m-80§a88.§a3680v

 

 

 

 

161

acogfioquofiB-8: .8 8320988598300 ”3% 333m

 

 

8:382.“=3fim8§¢2~3¢o§w=u§ I: 85.835=3fi8§¢8a3¢938hfl I *9aognEoULSa3-8=*

 

“crimson c2895 “Barron?

 

 

 

162

aEa-8n:~=vo-:w8..5¢8~3-8:-m=888 ”8 88808038— umN-e 88E"—

 

 

 

 

oE-Eogqaou-883-8: 8 8:8 8 883 8: 8:95.80

 

og-ucognquuBaB-uo: «O
§a3-8:-88=8H ”885m 3

 

o338§m§8¢o83¢om 8 8:: 8 883 8: 8:85.80

 

 

 

83:30 «0
883-8888.“. ”8855 3a

 

8830 8 8:: 8 883 8: 8.8.280

 

 

 

80-88898098383-8: "m0
«aim-88.83.858.580 ”aouocsm 3n

 

 

 

 

c A 8 tom 8:38-8:88 .o8-8858q8098383-85 o A 2 tom A8388 883-85 .occ-Eogmfioo-883-8E

 

 

 

 

 

 

 

 

163

$8§m€o0¢o83680 8 83209888900300 ”cm-o Bswfi

 

 

“Es-88:888-nwsefi-883-Eoo-wcug laws-8N:88?:805-883-28-883 '888889800-883680...

83855

 

 

88:5 80:89..

 

 

164

80-888:68.808.8883-0—00-w880 8 8888828: :m-e 8mm

 

 

 

08-80888-8083680 8 8:8 8 883 900 8:880

 

 

«3888380988330: :0
8383-85888; ”888m .3

 

08-030838008883680 8 8:: 8 .883 900 88:80

 

 

 

89:30 «0
883-888.“. ”8:05:— 3

 

 

89:30 8 8:: 8 883 900 88.080

 

 

ago-8883800888330: ”.5
88:...883-858580 ”888m .3

 

 

 

 

 

o A AN 80m 888-8580 68.808380983836805 o A 3 tom A8888 883-905 88.808380988836805

 

 

 

 

 

32m .83 SE $233886 8 Season-8858-838 ”NE 2:3”.

 

165

 

32m 88>? “3.:

co: -30 -5-30 -wS 8
.083 c . u .38 V coug-Boc-E-xao-Bou-aaom *<-o>~8>-xoo:0*

 

no:8:?8:mo&o-E-3cu-w=:8m6

8323— 8285.”— .8289.”

 

 

 

 

166

8888-30cam-33-8388 ”mo 88.88088: ”mm-c 88E

 

 

 

2 tom A8588 883-85 {-23.938839 Iv AN com A8888 883-8.: {Aggy-80:8

 

 

28> v.85 B 883.8 3

 

 

 

a :8 .8538 533.85 8.0%?gi
A 2 tom A8588 883-85 .<-o>8>-xoo:0v

 

 

 

 

 

c A c :8 .Aaaaa 983.85 {-23.gi

 

 

 

 

167

8588-8888-5-35-8388 8 88.88088— ”vm-o 88$

 

 

 

 

88880 02

 

23> u.35 no .5833 E

 

 

2 .88 A8888 8083-85 .<-o>8>-xoonov A AN “88 A8388 883-85 .<-o>8>-xoonuv

 

 

 

 

 

168

9% 333 28V 8-2.3286 8o .om>a_om-=ouo§m-8_>8 ”m3 2&8

 

 

8888-30new-305-8288

8888-8688-5305$538G

8320mm

/
\

8885-3oc-E-zfio-3ou-HEQA

 

88.58

35% .883 2005

 

._.

maze/-886-

 

*oo_>oQ*

 

 

169

8:88-309:T358585 8 cow—35:88:: “om-o 85mm"—

 

 

: .88 A8388 883-208 (.028?gi IV AN 88 A8388 883688 .m-o>8>-xoonuv

 

 

 

22> u.85 8o 88qu 3

 

 

 

a :8 83328 gag-285 8-25-8865

A 3 ~88 A8388 883-285 .m-o>_a>-xoo:UV o A C 808 A8=mm88 883-205 .m-o>_a>-v_oo:Uv

 

 

 

 

 

 

 

 

 

170

=33§§$§§o§m==§€ ac gag—080.95 ”two 2&5

 

 

:ouflono oz

 

 

 

23> “.026 we 5535 B

 

 

2 5.. 6382“. 533-25 .995-gi A a =8 @335 833.23 .m-o>_§-xu£ov

 

 

 

 

 

171

46343504505 05 mo uo_>a:0m-:ouo§m-oo_>ofl ”wmé 0.5mm"—

 

 

23m8989:9383-Eoo.u§-~oa-w5=obcou III 25mm893930¢0H§>6~oo駢oc-3980 III LED.._ob=oU-BcE*

 

 

Hoganom :Ofloannm .3030ng

 

 

172

gammy—5.59:0...2a3-200-03-8:-w==.8300 «0 5332:258— Ham-c 2:3,...—

 

 

 

 

G 205 A3253?“ .Eogmamwa-fincafiv J§-_0b:00-30EV Am 205 A3333? acogmnqva-ggv JE=-_gao?30_..b
lv 3. :05 A3325 533-208 Jan-35:00.32": IV S :05 A3385 533-005 ..E=-_0b:00-30EV

 

 

 

 

 

 

9:255:80
9.2320230305 50 .2255 .3

 

 

 

 

 

G :05 6:253:03 Jcogmswxw-Racdfiv 3540230030.": An :05 6.22.3593 Jeogmamua-fincafiv fins-3250305
- AN :05 A2325 533-208 Jig-339092335 - 2 :05 A2385 2033-85 Jada-232300.253
IV R 205 A2335 2033-208 amas-uonmaavo-Bzmmué Iv 2 205 A2385 2033-206 gin-232.352.902.328

 

 

 

 

 

3:032:00 50 53223.5. .3

 

 

 

 

 

 

c A AN :05 A2325 2033-203 JE=-_0b=00-30Ev o A C :05 A2325 2033-85 JET—9300305

 

 

 

 

173

23-2222 50 2023som-aouocsm-820Q Nov-o 2:me

 

 

333-200-03-uon-w025800

2022232

 

333-200.03-205-0222800

 

005255

 

0-30-22:-

 

*850-

 

 

174

“233-200.03.202-w520800 “50 0233222585 “:10 2:25

 

 

 

a :8 533-855 23-9.36

 

 

as 353 3o 8:38 B

 

 

 

 

: :8 233-8,. 423.320

 

 

 

2 com .§§-§ 43..-»st

 

 

 

 

175

6.6 Conclusion

In this chapter, we have discussed a proposal for a connectivity extension to Functional

Modeling. As we discussed at the end of the previous chapter, during the modeling of the

F/A-18, serious limitations of the Functional Representation were encountered when
modeling what seemed to be simple examples of component connectivity and fluid flow.
For instance, when representing the Engine fuel supply subsystem, we had to represent the
conduit system in a very convoluted fashion. The main cause of this difficulty was the lack

of mechanisms in Functional Modeling to explicitly represent connectivity and flow.

Our proposed connectivity representation was motivated, in a large part, by the needs of
such representational primitives with our standard part library and model selection
algorithm discussed in the following chapter. Furthermore, explicitly representing

connectivity and flow will eliminate some of the difficulties caused by the lack of such

representation mechanisms when applying Functional Modeling.

Chapter 7
Standard Part Library

“There has been sensational changes in design engineering. There ’s
more of a system approach now, where we look at the aesthetic
dimension, the functional design, and manufacturability consider-
ations. ” (Design News, July 11, 1994, pg. 57 (emphasis added))

Modeling complex engineering artifacts is difficult in substantive domains and requires
skilled and experienced engineers. Although complete automation of practical engineering
modeling is still beyond current technology, supplying a repository of standard part models
could alleviate some of the modeling difficulties faced by the human modeler. Such a
repository, or standard part library in our terminology, would not only assist the non-
designer engineer in understanding the intended function of each component, but would
also allow engineers to experiment with alternative designs, cost-effectively and

efficiently.

The increasing complexity of engineered artifacts demands methods and tools which
facilitate the design proCess. For instance, it is desirable to automatically generate a design
given a specification of the design requirements, such as the required functionality of the
artifact. Currently, except for some restricted applications such as electric circuit design

(Schwarz, 1993), a fully automated design procedure is unavailable. Furthermore, in

176

177
conventional computer aided design environments, there are currently no tools available to

assist the design engineer in automatically creating models to meet a given objective (Stein
& Tseng, 1991). The representation of the intended function of a component and the
incorporation of this knowledge into a design environment is still beyond the horizon.
Thus, we are forced to search for methods and tools which have the potential to reduce the

required investment in the design efforts.

In this chapter, we focus on applying the Functional Modeling Approach to construct a
library of standard part models. Our intent is to capture design knowledge for engineered
artifacts and to utilize it in building functional models. The standard part library can also
be used during the conceptual design phase of the design process. The goals of this chapter
are to present our framework for augmenting the Functional Modeling Approach with a
standard part library and to discuss the use of the library in support of the conceptual design
stage of the design process. We use our research in the domain of the F/A-l8 fuel system
as the basis of our discussion and examples. At the end of this chapter, we address potential

payoffs of our framework.

7 .1 Standard Part Library Motivations

Modeling complex engineering systems is a difficult, error-prone, and time consuming
activity requiring skilled and experienced engineers. System modeling plays an important
role in model-based diagnostic systems, system performance tuning, design sensitivity
analysis and other design activities. Most often, the system models are constructed by
someone other than the designer of the artifact. However, difficulties arise when
constructing functional models after the device is produced because often only the end
result of the design process is available (i.e., the product itself and the structural
blueprints). This information does not include the intended functionality of the designed

artifact, nor the intended functionality of its subcomponents. Therefore, we predict that a

178
functional model of a designed artifact will be more accurate if it is crafted and used during

the design process (Bond, Sticklen, & Pegah, 1991). In other words, it is highly desirable

to fully capture the designed artifact’s intended purpose at design time.

This practice will allow functional models to represent the intended functions of the
designed artifact. The models can be deposited into a library of standard parts for the
domain of discourse, and utilized during the modeling of new systems in the same or
similar domains. In this way, the decisions made by the design engineer during the design

process will be captured and known to others that use the library.

During the past few years, considerable progress has been made in Computer Aided
Engineering (CAE) and Computer Aided Design (CAD) Systems. Modern CAE and CAD
systems provide engineers with design and analysis tools, such as finite element techniques
and dynamic simulation packages. However, these tools remain based on the paradigm of
drafting. The models used in CAD systems contain information such as the parametric
geometry, topology, materials, etc. about the “final” product, but do not contain any
information about the functionality of its constituent components nor their design intent
(Henderson & Taylor, 1993). The increasing demand for an intelligent design support
environment presents the challenge of developing a modeling tool that supports the capture

of device functionality and design intent.

To develop such a modeling tool, there is the need to lay a foundation for the evolution
of CAD systems from the current limited paradigm of drafting, to support the functional
description of devices. Although this transition is viewed as a step function increase in the
capabilities of current CAD systems, it is one that is necessary to support the current trends
in engineering practices, such as concurrent engineering. Concurrent engineering practices
bring together experts from the design, production and marketing departments at the
conception of a project so that all aspects of product development are considered in the

early stages. There are two fundamental motivations for concurrent engineering practice.

179
First, to avoid costly revisions, mistakes must be caught in the early stages of product

development. Second, to improve cost effectiveness, different steps must be implemented
concurrently. According to experts (Kaplan, 1994), the key to the success of concurrent
engineering is the collaboration of experts from all relevant department during the entire

development process of the product.

From a designer’s perspective, there are key issues in concurrent engineering which
must be addressed. To insure that the required design specifications are met, the
component’s descriptions must be organized into a representational framework that can
represent the evolving design. The representational framework, called the design model,
should form the basis for sharing design knowledge among diverse departments involved
in the project. Ironically, the design models in current design environments (i.e., the CAD
data files) do not support knowledge sharing among diverse departments. Moreover, in
concurrent design environments, design models at various stages of the design process
must be presented with the right level of abstraction and granularity to address the needs

and interests of all groups involved.

Functional Modeling (FM) supports the concept of shared design-domain ontologies
(i.e., an agreed upon vocabulary to describe the artifact). Furthermore, functional models
in the FM framework can be utilized at different levels of abstraction and granularity. We
do not intend for our work to be viewed as a complete foundation for CAD evolution, but

a first step toward laying the groundwork.

Earlier, we described the results of applying Functional Modeling (FM) to the modeling
of the F/A-l8 aircraft fuel system. We utilized FM in support of simulation and
consequence finding. The success of our earlier research encouraged further investigation
into PM as a modeling tool. We wanted to tackle another task in the PIA-18 fuel system
domain to determine if the functional viewpoint can be used to support the engineering

design process.

180
In engineering domains, design engineers build models to see whether a device will

behave as expected. Typically, they do not produce designs for new devices from scratch.
Instead, they search the domain specific catalogs of existing designs to find previous
designs that closely match. Design engineers often recursively decompose a device under
design, until they reach a level at which they can insert an “off-the—shelf”, previously
designed component. As shown in Chapter 4, Functional Modeling supports this recursive
component decomposition. If a standard part is used for constructing functional models of
a device, then the model building activity can be viewed as a “natural device purpose mind
set” (Ermer, Goodman, Hawkins, McDowell, Rosenberg, & Sticklen, 1993) process to
designing the new device. In other words, the design engineer searches for a standard part
that is best suited for the intended purpose. We propose augmenting the Functional

Approach with a library of standard parts and a model selection procedure in support of this

type of design.

7 .2 Conceptual Design Phase of the Engineering Design
Process

In the area of design problem solving, design problems have been characterized as
“wicked”, “ill-defined” problems, with many solutions (Smith & Browne, 1993). In the
design literature, the design process is considered as transformations between different
consecutive processes (Tong & Gomory, 1993). For example, Gero describes the design
process as the function-to-structure transformation (Gero, 1990). The early part of the
design process, in which the functional requirements, solution principles and
configurations are determined, is known as the conceptual design stage. According to
design guidelines (VDI-GKE, 1987) published by the VDI (Verein Deutscher Ingenieure)
(Society of German Engineers) and reported by other researchers in design (Hundal &
Langholtz, 1992; Klein, 1992), during the conceptual design stage, the required functions

of the artifact being designed are analyzed. The complex functions are decomposed into

181
simpler sub«functions. Furthermore, a set of behaviors capable of carrying out these

functions is determined. At this stage, it is often feasible to form the desired behaviors by
rearranging and combining other behaviors. Thus, behaviors which implement the required
functions are selected and combined to form a number of concept variants for the artifact

being designed. The concept variants are evaluated and the best one is selected.

Conceptual design plays an important role in the overall success of the designed artifact.
During the conceptual design phase, the majority of the important design decisions will be
made. Moreover, poor design decisions at the conceptual design stage will have
devastating effects on the end product and often cannot be corrected in other stages of the
design process. Figure 7-1 shows the conceptual design slice of the design process. The last
stage of the design process is the detailed design stage in which the descriptive details, such
as production drawings, are finally produced (VDI—GKE, 1987).

 

Design Process More Detail

Functions Conceptual

Behavior to D6813“
implement functions
Standard part selection and
device configuration - - - — .
V / Detailed Design \ V

Figure 7-1: Conceptual Design Phase

 

 

 

 

 

 

 

1 82
The conceptual design phase is classified as the transition between three different stages

(Welch & Dixon, 1992).
1. Determine the required functions of the device under consideration.
2. Determine a set of behaviors that carry out the functions identified in Step 1.

3. Determine a set of preliminary devices that meet the set of behaviors from

Step 2.

In Chapter 4, we presented the functional representation for defining the functions of
devices and the behaviors that implement those functions. This representation is applicable
during the first two stages of the conceptual design process shown in Figure 7-1. The last
stage of the conceptual design phase is the part selection and device configuration stage.
The end result of the conceptual design phase is a configuration of components whose
behaviors fulfill the desired functions and is physically realizable. A device configuration
is defined as an arrangement of a set of standard parts. The particular arrangement is
determined by the individual behaviors of the standard parts and their physical relationship
with each other. In other words, the behavior graphs are used to guide the selection and
arrangement of standard parts to build different system configurations. In the following, we
discuss how a standard part library can enhance the human designer’s ability to perform

this stage of the design process.

7.2.1 Addressing the Challenges of Conceptual Design

In the design literature, it has been shown that the integration of knowledge-based systems
with computer-based model design environments is a challenging and promising activity
(Coyne, Rosenman, Radford, Balachandran, & Gero, 1990). The utilization of knowledge-
based systems in design opens a new approach to computer-based design. The integration
of computer-based design with the power of knowledge-based systems provides a more

robust and flexible medium for design engineers than was previously possible.

183
As we stated earlier, modern computer-based design systems provide engineers with

design and analysis tools. However, there are no tools to assist the design engineer in
automatically creating models to meet a given objective (Stein & Tseng, 1991). In other
words, there are no mechanisms which aid in the part selection and device configuration
stage of conceptual design. Currently, this stage of the design process is completely
performed by human designers. We identify a tool that assists a design engineer during this

stage as a conceptual design tool.

In developing new products, creativity and heuristics play a key role during the early
stages of the design process. Creativity is essential during all phases of design, including
the part selection and detail design stages. However, in the conceptual design phase,
abstraction, modularization and combination of solutions are the most central activities
(Dixon, Duffey, Irani, Meunier, & Orelup, 1988). Like other phases of the design process,
the conceptual design phase is affected by current trends toward concurrent engineering.
Concurrent engineering moves many issues forward into the conceptual design phase.
Previously, these issues were considered later in the design and production stages. Dealing
with new engineering and manufacturing trends, conceptual design is becoming

increasingly more demanding and complex.

While conceptual design is becoming more demanding, the shortage of experienced
design engineers is becoming a major issue]. Moreover, critical activities during the
conceptual design phase demand extensive practical knowledge about the models of
systems in the domain. According to Engelrnore (Engelmore & Tenenbaum, 1990) citing
from “C“ I Report, June 25, 1990”, experienced design engineers are disappearing. They
are being replaced by an influx of technically skilled, new engineers who lack the

knowledge of how theoretical models translate into operational artifacts. Industrial

 

1. This issue has been argued by many researchers, and is a strong driving force behind the “Toward the
Engineers Associate: a National Computational Infrastructure for Engineering” initiative (Engelmore &
Tenenbaum, 1990).

184
engineers agree that theoretical knowledge cannot replace practical experience, nor can

theoretical knowledge be organized into a series of design rules (Domeshek, Hemdon,
Bennet, & Kolodner, 1994). To be competitive in a global environment, experienced design

engineers must transfer practical knowledge to their less experienced colleagues.

An important objective of an industrial enterprise is to improve the cost-effectiveness of

the design/fabrication process. This objective can be broken down into two components:
1. Reduce the time required to develop and deliver the end product to market.

2. Improve the consistency, testability, manufacturability and maintainability

of the product, which results in increased customer satisfaction.

Reuse and improvement of existing designs are steps towards achieving the above
objectives. Moreover, as the designed artifacts become more technical and complex, model
reusability is becoming more important (Saulnier & Bortscheller, 1994). In the domain of
aircraft engineering and manufacturing, design decisions made by expert design engineers
are heavily influenced by existing designs. One common practice in the aerospace industry
is to start a new design by choosing a similar, existing artifact and simply borrowing its
design principles as a baseline design (Domeshek, Hemdon, Bennett, & Kolodner, 1994).
The borrowed design is then modified to satisfy the behavioral requirements imposed by

the new design and to incorporate applicable new technologies.

This practice is based on the traditional iterative design method. In this method, an initial
design is chosen from a pool of existing designs. In the next step, the design is analyzed to
determine if the design is an acceptable design. If the design is not acceptable, the design
is modified to create a new revised design. The revised design is analyzed as before and the
iterative method is repeated until an acceptable design is found. We illustrate this practice

in Figure 7-2. Of course, to select a baseline design, the design engineer must be familiar

185
with previous designs and should be able to relate past designs to the requirements imposed

by the new design.

 

 

(Existing Design)

Design Parameters ———> i

 

 

> Analyze the Design

 

 

 

Behavioral Requirement —>

 

 

.._ Design Modifications Anaccel’mb'e Evaluate
Wig]! /

 

 

 

 

Design

(New DesigD

Figure 7-2: The Typical Design Practice.

lAcceptable

 

 

 

 

To develop a strong modeling environment to support design engineers, we need to
consider the subtasks of the conceptual design process that can be delegated to the
modeling tool, and the subtasks that must be performed by the design engineers. Common
experience suggests that people are not always good at identifying relevant past
experiences. Furthermore, reports from analytical reasoning research suggest that humans
often fail to remember potentially useful experiences (Holyoak, 1985). Studies in social
psychology indicate that human designers, with a great deal of experience, are likely to
have a limited number of favorite design experiences that they rely on as a basis for new

designs (Gilovich, 1981). In summary, people are not efficient at recalling relevant past

186
experiences. This limitation of human designers can be overcome by computers. On the

other hand, our current computers still have difficulties applying previous solutions to new
situations. However, people are very good at analyzing and applying previous solutions to

new problems.

Given these strengths and weaknesses, the design task can be shared by human
designers and computers in a comprehensive environment supporting the engineering
design process. A modeling framework equipped with a library of standard parts is an
important step towards building such an environment, applicable to a wide range of
engineered systems. Selecting standard parts from a library will shorten the development
time of the product and aid the human designer in selecting alternative solutions with
different properties. In addition, it will facilitate the assimilation and reuse of the captured
knowledge. Finally, productivity can be enhanced by using the library of standard parts to

couple engineers, designers, and manufacturers.

7 .3 Standard Parts Library

Although current modeling software provide the tools necessary for developing modular
models of a system, in most cases, the human modeler does not want to develop models of
the basic components (standard parts) in his/her application area from scratch. Modeling
software which is domain-independent can be enhanced by augmenting the software with
domain-dependent model libraries. The model library is a domain-dependent repository for
generic/non-generic standard part models. The potential benefits of model libraries have
been recognized in numerous other disciplines. Moreover, human modelers in other

domains are currently using these libraries in their work.
Some examples of the current uses of standard part libraries are as follows:

0 A modeling library for electrical power systems should contain standard

part models for pipes, heat exchangers, pumps, turbines, valves, etc. The

187
Modular Modeling System (MMS) (Weiner & Cellier, 1993) is an

environment for modeling power systems, and contains a library of standard

parts required for modeling power plants.

A modeling library for electrical circuit simulation should contain standard
part models for basic building blocks such as transistors, resistors, voltage
sources, etc. Augmenting modeling tools, such as SPICE (Tuinenga, 1988;
Vlademirescu, 1994), with a standard part library would make such
programs more powerful and valuable.

With the introduction of VLSI (Very Large Scale Integrate Circuits) and
VHSIC (Very High Speed Integrated Circuits) technology, a typical circuit
design includes over 100,000 gates on a single chip. Thus, designing the
various components of typical hardware is a complex and error-prone task.
Even with the modeling aids in VHDL (Virtual Hardware Description
Language), some of the problems such as configuration control remain.
VHDL alleviates many of these problems through the use of libraries of
design units (Lipsett, Schaefer, & Ussery, 1989). Using libraries of
previously developed designs in VHDL allows electronic hardware

designers to simplify the task of hardware designs.

A modeling library for chemical process modeling should contain models
of different types of separation columns, such as distillation and stripping,
as well as compressors/condensers. The modeling environments Design-Kit
(Stephanopulos, Johnson, Kriticos, Lakshmanan, Mavrovouniotis, & Siletti,

1987) is a working example in the domain of chemical process modeling.

A modeling environment for energy-based modeling should provide basic

models of junctions, transformers and gyrators (Amsterdam, 1993).

188
o A modeling library for thermal heating systems should contain basic

models of radiators, walls, windows, etc. The modeler should be able to
construct models of buildings by instantiating and assembling these basic
models and should not be concerned with the low level descriptions of these

building blocks.

7.3.1 Library Construction

Preferably, either domain experts or design engineers develop the standard part library. Of
course, the standard part library can also be constructed by an experienced human modeler
with extensive domain knowledge gathered through reverse engineering. The later is the

approach we took to construct the standard part model library for the F/A-18 fuel system.

We were inspired to build a standard part library by the fact that the most tedious and
error-prone aspect of modeling is the need to copy the same type of component many
times. Our own experience, as well as the observations of others (Gruber, 1992), has shown
that developing a standard part library from scratch is a formidable task. At the start of the
development process, we had strong intuitions about the organization of the F/A-18 fuel
system library. These intuitions included the concepts of classes and inheritance from the
object-oriented paradigm. We initially developed a few fully specified model components.
Then we realized that there are strong similarities between some of the models. We then
developed generic component models which shared the strong similarities we discovered

earlier.

Constructing a well-structured and reusable device library from scratch is a difficult
task. However, once it is developed, it can be easily extended. The potential uses of a
standard part library are strong incentives to building the library and using the device
models as components in other models. We can summarize our approach for constructing

the library as a four step procedure:

189
1. Understand the device through reverse engineering.

2. Group artifacts with similar functions.
3. Construct generic models.

4. Organize generic models in a class hierarchy.

7 .3.2 Library components structure

The core of the standard part library is the abstract generic models of the off-the-shelf
artifacts. The generic models to be represented include the structural and functional
descriptions which describe each artifact. Each component in the library is equipped with
ports which pass substances1 in and out of the standard part. Each standard part model
represents the characteristic behavior of the device in terms of the substances at the input
ports inducing behaviors at the output ports. The standard parts are interconnected at their
ports to form an overall system. The behavior of the overall system is determined by the

standard part behaviors, together with the way in which they are interconnected.

In designing library standard parts, we have followed the principle that in describing the
functions of a device, we make no assumptions about the internal structure of the device,
nor how a device achieves its function. This principle is based on the guiding intuition that
the “same function of a device may be achieved in different ways” (Chandrasekaran,
1994). Thus, a description of a device’s function should not make any commitments to the
device’s structure. This principle is called the “No Structure in Function” (Keuneke &
Allemang, 1989). For our standard parts library framework, we reason about the
connectivity between the components of the overall model. Thus, we need to describe

some minimum amount of structure.

 

1. Recall that substances can be physical substances, as well as abstract substances such as information, con-
trol signals, etc.

190
We consider a standard part as an abstraction of a known off-the-shelf artifact suitable

for instantiation and define it as a quintuple,
(D, C, F, P, R) where:

o D is the name of the standard part, which is a domain dependent string of

characters.

0 C is the set of components of the standard part. Each component is a

standard part by itself.
0 F is a set of Functions.
- P is a set of Ports.

0 R is a set of relations between components].

7.3.3 Standard Part Library Organization

In the object-oriented paradigm, the concept of class2 is used to define an abstract data
structure. Classes are hierarchically arranged and the concept of “inheritance” plays a key
role in the organization. Inheritance implies that all attributes of a super class are available
in the subclass. In addition, new attributes can be added to the subclass to extend its
definition. A text by Rumbaugh et al. (Rumbaugh, Blaha, Premerlani, Eddy, & Lorensen,
1991) presents a good introduction to object-oriented terminology and concepts. Our main
objective in this section is to present the concepts of inheritance, subclasses and
superclasses which are used to structure the standard part models and to construct the
library of standard parts. In this work, we view standard part models as classes,

hierarchically organized by the type of standard part. Thus, the library uses a type hierarchy

 

1. Currently, we are only representing the relation ConnectedTo.

2. A class defines an abstract definition type. Furthermore, a class can be defined as a subclass of another
class called the super class.

191
that supports inheritance for modeling lower level objects. Figure 7-3 shows a slice of the

hierarchy.

The root of the class hierarchy in the library is “F/A-18 aircraft standard parts”. This
class is an empty base-class used to organize the other classes. As we continue to define a
complete standard part library for the F/A-18 aircraft, we realize that many of the
components are quite similar. For example, a valve is a device which has two functions,
enabling and disabling fluid flow. A more specialized valve, such as a check valve, has
similar specialized functions. Inheritance can take advantage of such similarities between
standard part models. By organizing the standard part models in a class hierarchy, we can
exploit the functional similarities between standard part models. Figure 7 -3 shows the class
hierarchy for the standard part library. As shown, the classes in the lower levels of the
hierarchy inherit attributes from their superclass and additional attributes can be added to

extend or specialize the subclass definition.

In summary, we are organizing the standard part library of the F/A-18 aircraft by using
the concept of classes and inheritance. The class hierarchy is built in a topdown fashion,
starting with the most general classes and working down to more specialized classes. The

leaf nodes in the hierarchy represent fully specified F/A-18 aircraft standard parts.

192

37$... 2.. é 2253 can: Se 26:3 ”3 25mm

 

 

2303525.
£83m Dunne-Dun— V 5033“
use: :3»?— 50956

 

 

 

 

.532 30
95: uses? 95: e§> sunny: n... 3
5:55 :35 W 5
5:55 300m 5 8:5 .
-325 0502 I 8:5 :80 omega-035. 5:35 800 .
3 03 o o o
53>». cm. Eons a m o>3>58300
93> 333 seen—=53 9:3 33> SE
o>3> 55825 32:00 50>“: 52.5 o>3> 5503.5 30> . 52.05800
23> 333 225320 33> .23. 3> .880 see
o>3> .5035 20582.5. o>3> «00:0
85am 6.883% 8.3..— 6.323%
20532 329.80 20232 225 .5223 2&5
uni .
out: 2885—00-5. V 30:05:50
:3 .2289... eeeeeeeeWH 29.3 22a .
E
.82 :33 III-It-I-I 2.3—E
cows—.035 30:
e . 3805800
:5... 3:33 333 =85 22... 3am panes
. o:
35. 22225. .
“Se .82 accuse man. 28:3
e383

32.353

 

 

193

7.3.4 Modeling Ontology

Knowledge Acquisition (KA)/Knowledge Engineering (KE) is the process of constructing
a formal representation of human knowledge in a form that can be interpreted by a
knowledge-based system (KBS). This process of translation is the most difficult part of
knowledge-based system construction because of the conceptual gap, or representational
mismatch between the form which is described by the domain expert and the form which
is interpreted by the KBS (Gruber & Olsen, 1993).

To be effective, the gap between the two representations must be reduced. In recent KA
literature (Motta, Rajan, & Eisenstadt, 1990), the subject of domain conceptualization has
received special attention as a way to reduce this gap. A domain conceptualization
represents an abstract, simplified view of the domain of discourse. Furthermore, it is an
intermediate mapping step between the knowledge described in the natural discourse of the
domain experts and the form in which the knowledge is used for inferencing. The end result
of the domain conceptualization is a domain ontology, which is a semiformal

representation of a conceptualization.

The word ontology as used here follows the usage from philosophy: an ontology is a
“systematic account of existence” (Gruber, 1993). In practical terms, an ontology is a
vocabulary for describing the domain of discourse. For our purpose, an ontology serves as
a specification of the vocabulary that describes the domain entities and the relationships
among them. The ontology should be a machine and human readable notation for
representing the domain. In the fuel system domain, the entities include the fluids
contained in the subdevices. We speak, for example, of the motive flow pressure at the inlet

port of the turbine pump.

In the fuel system domain, like other fields, we need to construct a skeletal model
organization and semantic primitives at an appropriate level of abstraction to describe our

domain (i.e., we need to define our modeling ontology). However, this task is not always

194
simple to perform. One difficulty is determining the range of semantic primitives, their

identification, and their generality across different domains and different applications. The
predefined ontology is used to construct causal models for both the standard part library

and during the functional modeling stage of the overall system.

7.3.5 Standard Part Selection Modes

As we have demonstrated earlier, Functional Modeling can scale up to meet a formidable
real-world problem — the fuel system of a F/A- l 8 aircraft. In continuation of our work, we
now focus on enhancing functional modeling by adding a standard part library. Our library
of standard parts represents classes of abstract standard parts, their functions, and causal
behaviors, all at multiple levels of abstraction. In our approach we have identified three

modes of use for the library, namely:
0 A modeler could use the library as a static repository of standard parts.

0 A modeler could use the library to automatically choose the appropriate
device based on the structural and functional constraints imposed by the

requirements.

0 A modeler could select a class of models without the current functional
constraints being strong enough to force the selection of a single model
from the class. During qualitative simulation, however, the need for a group

of functions might become strong enough to force a selection.

In this thesis we focus on the first two modes.

7.3.6 Definitions

In our approach, we represent standard parts as classes of generic components. The
functions of the components are defined in isolation from their environment and are

realized through their interactions with the environment. Furthermore, we visualize an

195
engineered artifact as an assemblage of interconnected components. Each component will

have substances flowing into it from other components and/or its local environment called
inputs, and substances flowing from it to other components and/or local environment

called outputs.

Chandrasekaran interprets the “function of a device” as “the distinguished behavior of
interest for some observer” pg. 16 (Chandrasekaran, 1994). A device must interact with its
local environment to produce the distinguished behavior of interest. Moreover, a device
interacts with its local environment through its connecting points which are called ports.
Therefore, the function of a component can be defined in terms of its ports. For example,
the function of a shutoff valve is to enable/disable flow of some substance. In terms of its
ports, the function of a valve is to control the flow of some substance through its ports.
Since the only interaction between a device and its local environment takes place though
its ports, our device’s functions are defined in terms of their ports. Along these lines we

define the following terms.

0 Exogenous variables: Those variables that interact with the local

environment through either the input, output or input/output ports.
. Endogenous variables: Those variables that are internal to the component.

0 Port: A port is a point of interaction between a component and its local
environment, where local environment is defined as the boundary between
the device and the rest of the universe. All components have ports to connect
with other components. (Two connected ports share their state variables
which must represent a substance of the same type, like fuel. In our
representation, ports are used as binding interfaces, like formal parameters

in functions in a programming language). This definition is inspired by the

bond graph formalism as found in (Paynter, 1961; Rosenberg & Karnopp,
1990).

 

196
0 Output Variables: A set of exogenous variables that can be set by a model

of a device. These variables represent outputs of a device.

0 Input Variables: A set of exogenous variables that may affect the function

of a device. These variables represent inputs for a device.

0 Input Port: A port through which the desired substance from the local
environment flows into a device. The desired substance’s state is

represented by input variables.

0 Output Port: A port through which the desired substance flows from a
device to the local environment. The desired substance’s state is represented

by output variables.

- Input/Output Port: A port which acts as both an input and an output port.

7 .4 Model Selection Procedure

As we stated earlier, we have identified three modes for using the library of standard parts.
The main focuses of our work are on the first and second mode: A modeler uses the library
as a static repository of standard parts and the model of a standard part is selected based on

the functional constraints imposed by the requirements.

The following procedure starts with a class library of complete standard part models]. It
selects functionally matched models and assembles them into a set of candidate models.
During the validation stage, a selected model is validated by the modeler and/or by

functional simulation (i.e., consequence finding (Sticklen, Chandrasekaran, & Bond,

 

1. By complete, we mean that the model fidly represents the behavior of the device at a particular level of
abstraction. Moreover, a complete model of a device represents the basic comprehensive unit of that
device. The models in the standard part library must be complete to allow the standard part model to be
instantiated and inserted into the overall model of another device.

197
1989a)). If an acceptable model is found, it is selected and integrated into the overall device

model.
Inputs:
In our model selection procedure we assume the following inputs:

0 A standard part repository which includes a collection of standard part

models stored in a hierarchically organized class library.

0 A desired device with a particular expected functionality and connectivity
constraints (i.e. number of input and output ports, and the type of substance

at each port).
0 The class or superclass for the desired device.

Outputs:

The procedure outputs a complete model for the desired device by instantiating it from

its appropriate device class or it announces failure.
Procedure:
In detail, the standard part model selection procedure is as follows:

1. Specify the library of standard parts to be used for model selection. Each
element of the library is a class of a complete standard part model. The

library is organized into a device type hierarchy.

2. Specify the desired device’s connectivity and functional constraints.

198
The connectivity constraints consist of the number of input and output ports

and the type of substance imposed by the human modeler. The functional
constraints consist of the statements specified according to the predefined
ontology of the standard part library. The statements are built by the human

modeler to describe the functional requirements of the desired device.

. Select the device class or possible super class for the desired device from the
class hierarchy (i.e., click on the appropriate class in the standard part class

browser).

The human modeler can select the desired device class from the leaf nodes
of the library. In this case, he/she is utilizing the library as a repository of
standard parts. If the selected model meets the connectivity and functional
constraints, then it will be instantiated and integrated into the overall system

model.

. Starting with the selected class or super class for the desired device from the
previous step, construct a list of standard part classes with the same number
of input ports as the desired device. This step reduces the number of possible
candidates for the desired device. Let us call the constructed list the

Candidate List, CL.

. Construct a new list by selecting classes of candidate parts from CL with the

same number of output ports as the desired device.

. From the list constructed in the previous step, eliminate those candidate
parts whose type of substance at their input ports and output ports do not
meet the type of substance required at the ports of the desired device. The
standard parts remaining after this step meet connectivity constraints

imposed by the desired device; let us call this list CM.

199
7. Remove the first element from the list CM, and instantiate it as a potential

model for the desired device.

8. Map actual parameters (exogenous state variables representing substance

flow through ports) to their corresponding formal parameters.

9. Validate the model generated in the previous step to make sure that it
matches the functional requirements of the desired device. This is done by

using functional simulation or by modeler guidance.

10. If the device meets the required functional constraints, it is used by the

modeler, otherwise, we repeat from step 7, until the list CM is exhausted.

This procedure may fail to select a standard part from the library. The causes of failure

include the following:

a. the standard part model is missing from the library and should be
added to the library.

b. the desired component may not exist and should be designed and

then added to the library.
c. the standard part models may be incorrect.
d. the overall system being modeled is improperly designed.

e. the system model is oversimplified (in other words, it is not at

the same level of abstraction as the standard part models).

Depending on the type of failure, the modeler can take further action to correct the

problem.

200
Given the description of a device’s connectivity requirements and its expected function,

this procedure instantiates and outputs a complete model for the requested component. If it

fails to find a functionally matching model, it announces failure.

7.4.1 Discussion

In steps 1 through 3, we take input from the model builder to guide in standard part
selection. Steps 4 and 5 reduce the size of the search space for a possible model of the
desired device. The main idea behind these steps is to make sure that the standard part
model selected from the library has the required number of connecting ports. Otherwise,
the selected model will not meet the connectivity constraints and will not have the expected
functionality. In step 6, we continue to refine the list of candidate standard parts by
analyzing the consistency between the ports of the desired device and the ports of each
candidate standard part. We eliminate those candidate standard parts whose type of
substance flow at their ports does not meet the type of substance flow at the ports of the
desired device. Since the input ports of the devices selected in step 4 have their own type
of substance flow, we must eliminate those devices from the list CL that do not match the

type of substance flow at the ports of the desired device.

The standard parts remaining after step 6 meet the connectivity constraints imposed by
the desired device. During the conceptual design stage, the designer has to make sure that
the device under consideration physically fits into the overall model of the design. After
step 6, we have a list of classes for candidate standard parts whose connectivity constraints
fit the system we are modeling. In steps 7 through 10, we go through this list and identify
one of them as the actual desired device, using a combination of functional simulation and
modeler guidance. Step 7 through 10 are used to establish whether the standard part model
meets the functional constraints imposed by the functional requirements of the desired

device. Figure 7-4 shows a simplified schematic of the model selection procedure.

201

 

 

 

<<<<

Library of Standard Parts

 

 

 

 

Candidate Standard Part
List Construction

 

 

 

 

Refinement

 

 

 

 

Parameter Mapping

 

 

 

 

Validation

 

 

 

 

Figure 74: Standard Part Selection Process

 

202
7 .4.2 Model Selection Algorithm

Since we want to present a time complexity analysis of our model selection procedure, we
present the model selection procedure in a semiformal manner, and call it the Model

Selection Algorithm.
Given:

0 Astandard part libraryL = {11,12, ...,lt} where each 1;, ie {1, ...,t} ,is

a complete model of a standard part.
c A desired device D defined by:

Connectivity constraints C for device D. Recall the connectivity constraints
consist of the number of input and output ports and the type of substance at

each port.

Functional constraints F of device D. Recall the functional constraints con-
sist of the statements specified according to the ontology of the standard

part library.
0 The desired device class xe L forD
Instantiate:
- Standard part model for D from L.
Algorithm:

1. Let P be the list of n input ports for device D. This information is part of the

structural constraints C specified by the human modeler.

P = {n,(1‘.9)*}

203
2. Let 0 be the list of m output ports for device D. This information is part of

the structural constraints C specified by the human modeler.
0 = {m. (1“, 9>*}

3. Construct a list from x and its subclasses in L, of candidate standard parts

with exactly n input ports. Designate this list the candidate list, CL.
CL = {cl,c2, ..., cq} ;L

4. Construct a new list from CL of candidate standard parts with exactly m

output ports. Designate this list CL’.
CL’ g; CL g L

5. From the list CL' constructed in the previous step, eliminate those
candidate parts whose type of substance at their input ports and output ports
does not match the type of substance at the desired device specified by the

human modeler.

In representing the desired device D and the models in the library, the ports
are ordered by their type of substance and are stored accordingly. Thus, by
linearly comparing the type of substance at the ports of the desired device to
those of a candidate part, an unmatched candidate part can be eliminated in

linear time.Thus, the entire list CL' can be examine in polynomial time.

Let’s call the new list generated in this step, the list of candidate coherent

standard part models1 CM.

CM = {ml,m2, ...,mk} :CL’QL

 

l. A standard part model is said to be a candidate coherent model if it satisfies the number of required ports
and the type of substance at each ports.

204
6. Foreach mie CM, i= 1 tok,

a. For j = l to the maximum number of mappings between actual
parameters of the desired device description and the correspond-

ing formal parameters of the standard part model.

i. Map actual parameters (exogenous state variables repre—
senting ports) to the corresponding formal parameters. The
result of this mapping is the device ij'. where C]. repre-

sents the 1‘“ state variable binding for m.

ii. Compare the functional requirements imposed by the
human modeler to the functionality provided by the device

jmi.

iii. If the function of the device ijt. matches the required
function of the desired device D, go to step 6.b, otherwise

continue.

b. If step 6.a.iii was successful, validate the device iji using

functional simulation and/or user guidance.

c. If the validation step (6.b) succeeds, announce success and ter-

minate, otherwise let CM = CM — m‘. and continue.

7. Ifthe candidate list CM is exhausted (CM = { }) announce failure.

7 .5 Complexity Analysis of the Model Selection Algorithm

In this section, we present the time complexity analysis of our model selection algorithm

and demonstrate that in most practical applications, it is tractable.

205
We start with Step 3. At this step, we construct a list of standard parts which partially

meet the structural constraints of the desired device (i.e., they have the same number of
input ports). The maximum number of components in the library is t. Since, in the worst
case we are interested in the number of input ports of each element in the library, we
require at most t comparisons. Therefore, the worst case time complexity of this step is

(Xt), which is linear in the size of the library.

In Step 4, we construct a subset of CL by eliminating those elements which do not have
the correct number of output ports. In this step, we examine every element of the list CL.
Thus, at most ICLI = q (q equals the cardinality of the set CL) comparisons are required.

Therefore, the worst case time complexity of this step is (Xq) where q S t.

In Step 5, we validate the type of substance at the input ports and output ports of each
candidate standard part model, and remove the violators from the list CL’. Before we
present the worst case time complexity of this step, we recall our input/output port

representation. The input and output ports are represented as pairs

(N, 4)) where:

N is the number of ports, possible 0.
o (I) is an array of size N containing pairs of the form:

(I‘, P") where:

F is the type of substance.

P" is the port number.

Within the array 4) , the pairs (I‘, P") are ordered by their substance type. We represent the
connectivity constraints (i.e., input and output ports) of the desired device D using the same

array representation. This representation permits us to compare the type of substance at the

206
ports of the desired device to the type of substance at the ports of the candidate standard

parts by an incremental comparison method described below.
1. Let 4) be the array that represents the input ports of the desired device D.
2. For each candidate component cj 6 CL’ where j e {1, ..., ICL'I} .

a. Let ¢j’ be the array that represents the input ports of the candi-

date device Ci

b. For i = 1 to n (where n is the number of input ports) do:

If the type of substance at port pl. 6 4) is not equivalent to the
type of substance at port pi’ e oj’ then reject the candidate

device cj, otherwise continue.

c. If not rejected, then add the candidate device c- as an element of

1
CM.

As the algorithm shows, we must examine each of the candidate components in the
candidate list CL'. For each component, we must examine each of the n input ports. We
use an analogous procedure to determine which candidate components violate the required
type of substances at the output ports. In this case, we must examine each of the m output

ports. If ICL’I = r, then the worst case complexity is 0(r- (n + m) ) .

Step 6 consists of two nested loops. In the inner loop we map the formal parameters of
the candidate model to the actual parameters of the system under construction, then we
compare the functional constraints imposed by the modeler to the functions delivered by
the candidate model under the mapping. The maximum number of times the inner loop
must be executed is equal to the maximum number of mappings between the actual
parameters of the desired device and the formal parameters of the candidate device. In the

worst case, this number is n! - m! where n is the number of input ports and m is the number

207
of output ports. The worst case is the result of identical substance types at the n input ports

and identical substance types at the m output ports, (i.e., all n input ports have the same
substance flowing through them and all m output ports have the same substance flowing
through them). Therefore, the number of times the inner loop of Step 6 may be executed is
0 (n! - m!) .

Although in theory, the worst case bound on the number of iterations of the loop is
0(n! - m!) , in most real-world applications, such as the domain of the fuel system, the
number of input ports and output ports are quite small. This observation significantly
reduces the time complexity of the loop. Furthermore, it is comforting to note that with
realistic values of n and m, the computing power of today makes 0(n! ~m!) iterations
feasible. More importantly, in most real-world devices, the ports have distinguishable type
of substance flowing through them. In other words, there is usually only one possible
physical mapping. Thus, the number of iterations of the inner loop in most practical cases

is constant.

The processing within the loop compares the functional requirements of the desired
device to the functionality of the candidate standard part under the mapping. Recall, in our
representation, functionality is delivered at the output ports, so each output port is checked
to determine if the functionality of the candidate device matches that of the desired device.
Therefore, the worst case time complexity of this step is (Xm), where m is the number of

output ports.

The outer loop of Step 6 is simply repeated k times, where k is the number of candidate
standard parts (i.e., standard part models which satisfy both the structural and functional
dimension constraints). By assuming a constant upper bound on the inner loop of Step 6,
which seems reasonable based on our experience, the overall complexity of the inner loop

of Step 6 is dominated by 0(m). Therefore, the overall complexity of step 6 is 0( k - m) .

208
In summary, under the above assumption, the overall time complexity of the standard

part selection algorithm is 0(t + q + r - (n + m) + k - m) which is tractable. In the worst
case q, r and k are equal to t, the number of devices in the library. In this case, the upper

bound on our algorithm under our assumption is O (t (2 + n + 2m) ) .

7 .6 Engine Fuel Supply System Example

The engine fuel supply system supplies fuel to the engines in all operating conditions. The
engine fuel supply system is powered by motive flow fuel pressure. Each engine has its
own separate fuel feed system. During normal operating conditions, the left engine feed
system is supplied fuel from tank no. 2 and the right engine feed system is supplied fuel
from tank no. 3. The two feed systems are connected by the crossfeed shutoff valve which

in energized closed during normal operating conditions.

7.6.1 Glossary of Key Terms

The following is a list of key terms that are used in our discussion of the fuel system of the

F/A-18 aircraft. These definitions are based on (Pippenger & Koff, 1959).

Manifold: A device that provides multiple connecting ports.

0 Pipe: A device whose primary function is to contain and direct substances.

A pipe acts as a conductor of fluids.

0 Pressure Switch: A switch that operates by responding to a rise and drop in

pressure.
0 Pump: A device for converting mechanical energy into fluid energy.
- T-Connector: A conductor that provides three connecting ports.

0 Transducer: A device that transfers energy from one system to another.

209
0 Valve: A device that controls fluid flow conditions such as pressure,

temperature, time or rate.

0 Valve, Check: A valve that permits the flow of fluid in only one direction.

The valve automatically closes to prevent flow in the opposite direction.

0 Valve, Shutofl': A valve that operates fully open or fully closed.

7.6.2 Component Description

In Figure 7-5, we show a simplified schematic for the engine fuel supply system. As we
described earlier, the engine fuel supply system consists of two separate feed systems
which are almost identical to each other. Before presenting a synopsis of the operation of

the system, we present a simplified overview of each component.

0 Motive Flow/Boost Pump. This pump is a two stage, single shaft pump
powered by the Airframe Mounted Accessory Drive (AMAD). The Motive
Flow/Boost Pump has five ports, which are connected to various other

components of the system.

0 Engine Fuel Turbine Boost Pump. There are two Engine Fuel Turbine
Boost Pumps in the engine fuel supply system. They are located in tank no.
2 and tank no. 3 and are powered by motive flow pressure. These two pumps
supply pressurized fuel to the inlet port of the Motive Flow/Boost Pump.
Each Engine Fuel Turbine Boost Pump consists of 3 ports: an inlet port for
motive flow, an inlet port for fuel from the feed tank and an outlet port for

pressurized fire].

. Engine Fuel Shutoff Valves. These are motive operated shutoff valves.

They prevent fuel flow to the engine when closed.

210
0 Fuel Crossfeed Shutoff Valve. This is also a motive operated shutoff valve.

This shutoff valve is used to control fuel flow between the two separate feed
systems. The engine fuel supply system has redundancy built in. When a
failure occurs in the left (or right) feed system, this valve will be energized
open. This permits the right (or left) feed system to supply engine fuel to the
engine of the failed feed system. Normally, the fuel crossfeed shutoff valve
is energized open or energized closed by the left or right Fuel Boost
Pressure Switches (explained below). It can also be operated by the pilot.

0 Fuel Boost Pressure Switches. These switches are pressure sensing
devices located on the Motive Flow/Boost Pumps. These switches are used

to identify and transmit a low pressure identification signal.

. Boost Inlet Pressure Transducers. These transducers measure the
pressure from the Engine Fuel Turbine Boost Pump and transmit the

measurements to the Flight Incident Recorder and Monitoring System

(FIRAMS).

. Engine Fuel Coupling Check Valve. These valves provide a quick

disconnect and check valve feature between the fuel feed lines and engine.

211

 

 

 

 

 

 

 

 

OUFUEL HEAT
CHANGER CHECK
VALVE
_>
Mama, I— (.0 <2
ENGINE FUEL COUPLING
n . ECI< VALVE
Boost Pump —’ ‘
' T Sensor
A's T m — — — —
'A' RIGHT ENGINE _> '3'“ °'
— — UEL SHUTOFF FUEL
VALVE Electric Signal ‘ ' CROSSFEED
LEFT ENGINE .,. SHUTOFF
_ _ UEL SHUTOFF VALVE
"‘ VALVE —>
'A' Transducer "' _ _ —
‘— 1 Sensor
Boost Pump —> -
V . E FUEL COUPLING
CHECK VALVE
“am I— (.0 :5
—>
OIL/FUEL HEAT
CHANGER CI-ECK
VALVE

 

Figure 7-5: Engine Fuel Supply System

 

212
7.6.3 System Operation
The operation of the engine fuel supply system is both straightforward and elegant. It is
elegant because there are two independently operated feed systems, and there is
redundancy built in to ensure the supply of fuel to both engines under all operating

conditions.

The system is powered by motive flow pressure generated by two Motive Flow/Boost
Pumps. Motive flow pressure operates the Engine Fuel Turbine Boost Pumps in fuel tanks
no. 2 and no. 3, inducing fuel at the fuel input ports of the Motive Flow/Boost Pumps. Each
Motive Flow/Boost Pump pumps fuel to a separate engine feed system. Each Motive Flow/
Boost Pump supplies engine fuel to the engines through the normally open Engine Fuel
Shutoff Valve. In emergency situations, a failed feed system can be isolated/disabled by

closing the fuel shutoff and fuel crossfeed shutoff valves.

In Figure 7-5, we show a simplified conceptual connection schematic for the engine fuel

supply system. We will be referring to this schematic during the modeling process.

7.6.4 Engine Fuel Supply System Library of Standard Parts

The first step of the Functional Modeling procedure is the component decomposition
process. Although there is no requirement to utilize a top-down or bottom-up approach for
component decomposition, we choose to use the top-down approach. In the following, we
describe the decomposition shown in Figure 7-6 and the modeling of the fuel system’s

components for inclusion in our standard part library.

Our top level device is the “engine-fuel-supply-system”. There are two separate feed
systems in the engine fuel supply system. We decompose the engine fuel supply system
into these two separate feed systems called the “right-engine-fuel-supply-system” and the

“left-engine-fuel-supply-system.” Since the fuel crossfeed shutoff valve does not provide

2 l 3
any direct functionality to these two feed systems, we leave it as a component of the engine

fuel supply system only.

There are two distinct components providing functions for the two feed systems.
Therefore, we represent these two components as functional components of the two feed
systems. The two components are basically the driving components and control
components of the fuel in each feed system. These two components are shown in the

components decomposition diagram Figure 7.7.

214

.8893 .2596 33.5 ofimcm 05 Co.— Eflwamc noummafiooon— 6.5. 0.5me

 

 

..58:5.~moo£30c-o>uoaéor

...eamzmmagt?2553403-“...—Ecoéo—a.
...5E:5-.883££B-33-ofimcoé2...

_..823?.»353403-059.0352...

...585,9.-253255555383335-co—_..

...Eoummm-.obaoo.b55=m-_oa-o£w=o-¢o_...

\/ \/

...o>3>..c2=fi-3£-ocmwcoéo—...

ao>3>$9=nmé35mm$3€a

*5E=5-amoo£>>oc-o>uofi-fimts
...829?.-m5>5-b55:m-_oa-o£meo-fiwt_..

...5E=5smoo€oE€E3£oEw=o¢nmt_..

...Eo.m>m-b55:m38-059835?

...:85...-8:$25.58:5¢83-38-Ewt...

...839$-_ob:oo-b55=m-_o&.o£w=o.fimt...

\/ \/

...o>3>.b8=:m-_o£.oamw=o.fiwta

..EBmzm->_55=m-_oa-oEwcoe

 

 

215
We are now at the final stage of the component decomposition. Each engine fuel supply

control system consists of an Engine Fuel Shutoff Valve and a Fuel Boost Pressure Switch.
Each engine fuel supply driving system consists of a Motive Flow/Boost Pump and Engine
Fuel Turbine Boost Pump. In our component decomposition, we stop component
decomposition at this level. Thus, the Motive Flow/Boost Pump is considered the most
elementary or “finest grained” standard part for our modeling process. A major factor in
our decision was the unavailability of a description of the internal elements of the pump.
Also, moving further down the component decomposition hierarchy would complicate the
example, and not add to the understanding of the standard part library. Therefore, each

device at this stage is considered an “off-the-shelf’ standard part for the fuel system.

7 .7 Structural Description of Standard Parts

In this section, we present structural descriptions of the standard parts for the engine fuel

supply system by utilizing the representation we defined earlier.

Device: Pipe
- Subdevices: none
0 Connections: none
0 Input Ports: (1, fuel, Port 1)
0 Output Ports: (1, fuel, Port 2)

Device: T-Connector-Split

- Subdevices: none

0 Connections: none

0 Input Ports: (1, fuel, Port 1)

0 Output Ports: (2, fuel, Port 2, fuel, Port 3)

Device: T-Connector-Merge

- Subdevices: none

0 Connections: none

216
0 Input Ports: (2, fuel, Port 1, fuel, Port 2)

0 Output Ports: (1, fuel, Port 3)
Device: Shutoff-Valve

- Subdevices: none

' Connections: none

0 Input Ports: (2, fuel, Port 1, signal, Port 2)
0 Output Ports: (1, fuel, Port 3)

Device: Check-Valve
° Subdevices: unspecified

- Connections: unspecified
0 Input Ports: (1, fuel, Port 1)
0 Output Ports: (1, fuel, Port 2)

Device: Turbine-Pump

0 Subdevices: unspecified

0 Connections: unspecified

0 Input Ports: (2, motive-flow, Port 1, fuel, Port 2)
° Output Ports: (1, fuel, Port 3)

Device: Motive-Flow-Boost-Pump

0 Subdevices: unspecified

0 Connections: unspecified

0 Input Ports: (2, mechanical—energy, Port 1, fuel, Port 2)

0 Output Ports: (3, fuel, Port 3, motive-flow, Port 4, fuel, Port 5)

Device: Manifold

- Subdevices: unspecified

0 Connections: unspecified

0 Input Ports: (3, hot-fuel, Port 2, fuel, Port 3, fuel, Port 5)

0 Output Ports: (3, engine-fuel, Port 1, engine-fuel, Port 4, fuel, Port 5)

Device: Pressure-Switch

' Subdevices: unspecified

2 17
0 Connections: unspecified

0 Input Ports: (2, fuel, Port 1, control-signal, Port 2)
0 Output Ports: (1, control-signal)

Device: Transducer

0 Subdevices: unspecified

0 Connections: unspecified

0 Input Ports: (1, fuel, Port 1)

0 Output Ports: (1, electrical-signal, Port 2)

7.7.1 Fuel System Ontology

For our purposes here, we present only a subset of the ontology needed to describe the fuel
system of the F/A-18. Only that portion that is necessary for the examples of the engine

fuel supply system is presented here.
- ElectricalEnergyAt: (port description)
Electrical Energy is at the port.
- EnergizedClosed: (port description)
A control signal is indicating the device should close.
0 EnergizedOpen: (port description)
A control signal is indicating the device should open.
- FuelAt: (port description)

Fuel is present at the port, however it is not pressured so cannot move with-

out outside force.
- GroundSignalAt: (port description)

The port is grounded.

21 8
- MechanicalEnergyAt: (port description)

Mechanical energy is at the port.
. MotiveFlowAt: (port description)

Motive flow is at the port.
. NegativeControlSignalAt: (port description)

There is a control signal at the port which indicates “negative”.
0 NoPressurizedFuelAt: (port description)

Either no fuel is at the port, or the fuel is not pressured.
o PositiveControlSignalAt: (port description)

There is a control signal at the port which indicates “positive”.
0 PressurizedFuelAt: (port description)

Pressurized Fuel is at the port.

7 .8 Example

For the engine fuel supply system problem, graphical representations of the initial standard
part library components are shown in Figure 7-7 through Figure 7-19. This is a small slice
of the standard part library for the fuel system. In our terminology we represent this small

slice as:

L = { Pump, Valve, Pipe, Check Valve, Shutoff Valve, Turbine Pump,

Motive Flow-Boost Pump, Pressure Switch, Transducer, Manifold, T-Connector, ..... }

organized in a Class hierarchy as shown in Figure 7-3.

219
Suppose the human modeler is constructing a functional model for right-engine-fuel-

supply system shown in Figure 7-5. He/she has decomposed the system into three
subcomponents, (control system, driving system, and passage system), as shown in the
device decomposition hierarchy. For the right-engine-fuel-supply system the human
modeler needs a pump with certain structural requirements which delivers a certain

functionality.
In our terminology, the desired device D has the following structural constraints
P = (2, (fuel, 1), (mechanical-energy, 2))
0 = (3, (fuel, 3), (fuel, 4), (motive-flow, 5))

Suppose the human modeler chooses the class Pump since he/she needs a pump.
Therefore I: = Pump. Under the class Pump, there are three classes of pumps, two of
which meet the number input ports constraints, thus we add these two classes of pumps and

their subclasses into the list CL.

CL = {Gear Pump, Vane Pump, Motive Flow-Boost Pump,
Turbine Pump, Two-Stage Gear Pump}.

The structural description of these classes of pumps are represented as follows:
0 Device: Gear Pump

Subdevices: unspecified

Connectors: unspecified

Input Ports: (2, (mechanical-energy, Port 1), (fuel, Port 2))
Output Ports: (1, (fuel, Port 3))

Functions: unspecified

0 Device: Turbine Pump

Subdevices: unspecified

220
Connectors: unspecified

Input Ports: (2, (motive-flow, Port 1), (fuel, Port 2))
Output Ports: (1, fuel, Port 3)

Functions: unspecified

0 Device: Vane Pump

Subdevices: unspecified

Connectors: unspecified

Input Ports: (2, (fluid-energy, Port 1), (fuel, Port 2))
Output Ports: (1, fuel, Port 3) '

Functions: unspecified

0 Device: Two-Stage Gear Pump

Subdevices: unspecified

Connectors: unspecified

Input Ports: (2, (mechanical-energy, Port 1), (fuel, Port 2))

Output Ports: (3, (fuel, Port 3), (motive-flow, Port 4), (fuel, Port 5))

Functions: unspecified

0 Device: Motive Flow-Boost Pump

Subdevices: unspecified

Connectors: unspecified

Input Ports: (2, (mechanical-energy, Port 1), (fuel, Port 2))

Output Ports: (3, (fuel, Port 3), (motive-flow, Port 4), (fuel, Port 5))

Functions: unspecified
Now, from the list CL, we remove those elements which do not meet the constraints
imposed by the input and output port requirements of the desired device D. For example,
by considering the list 0, we realize that the standard part must have 3 output ports.
Therefore, we check the structural representations of the standard parts in the list CL, and

remove those which violate this requirement. Since the Vane Pump Class does not meet the

221
necessary conditions, we remove its subclasses along with itself from the list CL. Thus, in

our terminology, this results in the list
CL ’ = {Gear Pump, Two—stage Gear Pump, Motive Flow-boost Pump}.

Next, we remove those devices from CL’ whose type of substance at their input ports
and output ports do not match those of the desired device. This process eliminates the Two-

Stage Gear Pump and the Gear Pump classes from CL’. Therefore,
CM = {Motive Flow-Boost Pump}.
The only remaining standard part in this case is the Motive Flow-Boost Pump.
0 Device: Motive Flow-Boost Pump

Subdevices: unspecified

Connectors: unspecified

Input Ports: (2, (mechanical-energy, Port 1), (fuel, Port 2))

Output Ports: (3, (fuel, Port 3), (motive-flow, Port 4), (fuel, Port 5))

Functions: MotiveFlowAt: (Motive Flow-Boost Pump, fuel, Port 4), Pres-
surizedFuelAt: (Motive Flow-Boost Pump, fuel, Port 3) PressurizedFuelAt:
(Motive Flow-Boost Pump, fuel, Port 5)

Behavior: shown in Figure 7-13.

The desired device D has the following specifications
0 Device: D

Subdevices: to be determined

Connectors: to be determined

Input Ports: P = ( 2, (fuel, 1), (mechanical-energy, 2))
Output Ports: 0 = (3, (fuel, 3), (fuel, 4), (motive-flow, 5))

Functions: MotiveFlowAt: (D, motive-flow, 5), PressurizedFuelAt: (D,
fuel, 3) PressurizedFuelAt: (D, fuel, 4)

Behavior: to be determined.

222

Provided: MechanicalEnergyAt: (D, mechanical-energy, 2), PressurizedFu-
elAt: (D, fuel, 1)

Now, we map the formal parameters to actual parameters as follows: :

TABLE 2. Mapping from Formal to Actual Parameters

 

Formal Actual
Motive Flow-Boost Desired
Pump Device D
Port 1 —> 2

Port 2 —> 1

Port 3 —-> 3

Port 4 —> 5

Port 5 —> 4

 

 

 

Now, we check the functionality of the newly created device using simulation or
modeler guidance; if it meets the functional requirements, we instantiate it and then
validate the model. Otherwise, we keep searching. Since we succeeded in this example, we

stop at this point.

7 .9 Potential Payoffs of a Standard Part Library

Model selection is a day to day activity of human design engineers and modelers. The
ability to intelligently select models is part of their expertise. They intelligently choose the
best suited models from a repository of exact or approximate models of designed artifacts.
Design engineers and modelers accumulate experience over the course of their careers and
learn how to select those models that are best suited to a modeling task. The value of
accumulated experience is well known. Moreover, the accumulated experience is one
factor that makes a design engineer or modeler an expert. Automatic model selection from
a library of reusable models opens up a new approach to computer-based design and the
modeling process. In particular, it provides a very powerful and flexible medium to assist

human designers and modelers.

223
A library of reusable models can be utilized in support of preliminary design, design

knowledge capture, concurrent engineering and a “virtual design team.” In a virtual design
team, some members are knowledge-based systems instead of real human design
engineers. Our library, coupled with the standard part selection algorithm, is oriented

toward such a virtual design team.

In crafting functional models of physical systems, a library of standard parts plays a
central role. Utilizing a device library during the functional modeling process permits more
rapid development of functional models. Additionally, it prevents possible modeling
errors. Resource sharing is another positive payoff of device libraries. Device libraries
from similar domains can be shared and the device models can be reused as is, or perhaps
with minor modifications. Resource sharing will result in model consistency and timely

model construction.

224

a5 33% 05 mo :ou8:8o.aom SA. 052m

 

vaumgosvag ”we 59558395 5

 

 

a com .33 8E ӣ8335
u

 

 

 

86.95 «c was an

 

 

 

 

2 e8 ..oa see Hosea—Beams:—

 

 

 

 

oqE we Swanson - eaten—fl - 03.69 ”a

 

 

 

 

Baggage—woo Rambo—6:00 III ...25...

 

8320m— eouoeam Illul c.8309...

 

 

 

 

225

882.509 mo confluomamom ”mg. 0.5an—

 

Eacazmm ac coaficofioafiu 5

 

 

 

a Em .3 58886 353235

 

 

3 tom 403 #900509: ”uSoshu—uontsmmam

 

 

833n— mo 95..— am

863n— mo «.33 mm

 

 

2 Se .33 5828.: 3525858:—

 

 

 

 

uouooeeood. we “org—om - couocam - 338 ”a

 

 

 

 

Eagwaweofi Ill. 2.5-0308
23-33% BauefiwVI 19888.?

Season .83an $0309..

 

 

 

 

 

 

 

226

882.50% «a 2.5692: «o cows—"2:395 no-5 83E

 

 

 

 

3 tom 403 £38559: 350:ng

 

863m .«o v.33 hm 8%».5 me 953 mm

 

 

 

 

3 Se .33 5826.: ”.Soameafimaa 2 ea.— ._oa 58586 ”.soameagfim

 

 

 

 

 

o>_d>.m9:nw 33% 05 we =ou8=omoeaom ”2A. 03mm"—

 

Bou-_o£-w==na=o co 55838038— 5

 

 

 

 

8 tom ._03 .o>_a>.b92_mv 353%?

 

23> mesa co 83qu E

 

 

227

 

a tem .aawmieaoo 623:9..an aaogaam : Em fie .ozgésfimv 35258535

 

 

 

 

 

 

o>_a>.h8=:m we Brazen - nouns."— - 3:69 ”a

 

Bou-_o&-wcmnam€

gout—OPHIme—DNGO V Bout—Ofith—Dflmmflb—n—Ncm Ill *0>~d>ub0~fl£m*

 

magnum .8585 $0309..

 

 

 

 

 

 

 

 

228

o>3>uc9=nm mo Boc-_o£-m==n8% co 39538295 ”:4. Bswfi

 

 

 

a :8 42¢ .ofiésaav "assmuBEaerz

 

 

33> mafia .8 83:8 3

 

 

 

a :8 figmeagaoo 623%:ng ”BSOBBMEE

 

 

: e8 .33 disease usage»:

 

 

 

 

 

229

aaabfinhfi. 333 05 mo cowfiuaemom ”~75. “SEE

 

930.2:cé=_-amuo=?ouo:§-wcuuo>=oo «o 32358395 5

 

 

 

 

9 En fie £88655 3533530:

 

3:059:80
aha—.9053 no .8325..— am

 

 

 

 

 

 

a :8 .33 $5-05..qu 353m c :8 £8.23... $656536 "2352?:

 

 

 

 

985.335 no 3333— - corona - 8309 ”a

 

 

 

Euouoémsuéfifmwuoao.o:o:§-ma€o>aoo 35568995-980.383-:980 III *985-05€:H*

 

 

33¢an nova—E .3259."

 

 

 

 

 

230

mgéooméofiééoz 33% 05 we :oufiaaemom um _ A. 0.53m

 

 

amt—.063c6~£$mb=38m§nuongub>=8 “we :o§:oEoEE~ b

 

 

AN tom .Bo¢-o>uoE dfismfiooméofibéozv u<BoEu>uoE

 

         

 

AN tom .38 dfiam-.mcom-30_m-o>uozv uSoPGoatsmmoE _ _ AN tom :08 .QEsm-umoom-BoE-o>zo—zv uSuamvoNtsmmoE #

 

35:23.8
9955 icon Bocé>uo2 mo cog—Em am

 

AN tom .33 dfizmémooméofiééozv afloamvgcamoi _ _r 2 tom .zwuocofiflcwsooE dEamémoomio—mésquzv u<awuu=m32=azoofl

 

 

 

mEa-.moom-BoE-o>on mo Hoganom - cove—5"— - 0359 ”a

 

 

33:92:98:_-%wuo=o-~ao€dnoofi-wfito>=8 l 385-2:a-oETRuocoAaowanoofiéoEoU | *mfism-aoom-3ofi-o>zoz*

 

8333 832:5 I'll $869"

 

 

 

231

28:32 838 05 .o 83:83; ”:4. 03mm

 

§E-fi§c:-88m.o_q£=fi-w§oo§8 ”no cou8=oEoEE~ 5

 

 

 

a :8 £3.05?» 635% 332585;

 

 

u

 

3. En 403.235 £833: “£2585an

 

 

 

3:82.88
920252 .3 :cuoaam am

 

 

 

AN tom 426 675536 330535395

 

 

 

 

 

: Em 403-8%.» .2853 353%8535

 

/\
\/

 

 

AN tom 403-8: 4:02:36 afloamvontsmmoum

 

 

 

28:32 mo .5323” - Sauna - 0330 ”a

 

 

 

ovofiéqauasva-€&-o_mE=E-w§ooE—oo /

 

258-R§0:-mtom-o_m£=8-wauoo§oo \

 

 

Hoganom

 

couogm

 

 

 

 

mta-o_q£:8¢oo§o0 $3352.."

 

 

232

29:52 .«o ovofiéggvou-83903258-»:u858 ac 5356395 ”24. 0.52"—

 

 

 

: ton— ..oaéo: 6355—6 352.993ng

 

 

8:309:00 ’

£852 mo 883m E

\

 

/

 

 

 

\ a :8 .aa £8236 35258533 /

 

 

 

AN tom ..oaéo: 6335—5 353%ng

 

3 Ba €3-05? .Eoéaé usoéuafiaamoz

 

 

 

 

 

 

233

:33m-8:mmo$ 0030: 05 mo :0u8:000&0- ”3A. 203%

 

8t-8:$899-w:=0:0%2 a0 3000:0833 5

 

 

 

 

 

a to: ._a_.0_m-_e.=8 58533020 05232880928:

 

35:09:00
9:836 gmmflm .«0 :000::& mm

 

 

 

 

a :8 .Ewu-_8=8 32392385: 05305230 2 no: .35 53995220 ”0505008532:

 

 

 

 

585995805 no 0030505 - 800:?— - 00309 ”a

 

 

 

 

008-8:mm2000-m:€:0%8 V

0w§:0-0::mm20.96:0%2
own-2:mm2:-8-w:€:0%2

*n00_3m-0::mm2m*

 

0030:3— :000::m $0309."

 

 

 

 

 

 

234

ssm3m.8=m8& .«o qggmgé$=€=oa§ ”no gouacofioafiu ”2 -5. 85mm

 

 

 

 

a com .a&_m-_8=8 £25353 u<§m§BSUo§moz

 

95:09:00
@555 838.5 mo nova—5n— mm

 

 

 

 

 

a :8 .a&_m-_§..8 .asim-§8e& u<a§mu§o5 2 :8 fie .:s_3m.§m§e 35335832

 

 

 

 

 

235

Boa-3:8,“. 830: 05 a: :oussgom “w _ -5 Baum"—

 

Eac-w:_§6:oo a: 53358395 5

 

 

a co: .a&_m-_8_a8_o :8..ng ”2905358.:

 

 

 

8:059:00
{cos—uméh no :ouogm am

 

 

 

2 no: :2: 50835 usofiuoafimme:

 

 

 

 

80:355. mo Brazen - :ouogm - 335 a

 

 

 

35:04:05oo_oéu->m:o:o.2:u-w:t:£m::b Ill Egonémgfi. II. 13:35: H...“

 

 

8320mm :ouofii ...ooSonT

 

 

 

 

236

50:355. 0030: 05 mo :ow8:008mom ”a -h oswfi

 

:ouoohv.8_mo&o.:m-30u-w:=nam€ a: 520550.95 n0

:0:02%.30¢-:T30c-w:=n::0 a: 52358035 x.

 

 

 

 

 

a no: .33 .22.gi 0533325.:

 

 

a no: :2: .23.“.850 0583932:

 

2? 0.86 0o 8:3»: B

 

 

 

2? U:20 :o 8%ch B

 

 

a to: :2: .23.:0200 0533532:

 

 

 

: E: :2: £328.50 ”.Sofiuafimsa

 

 

 

 

 

 

 

 

 

02.3.3030 mo Era—.3 - :ouogm - 00300 "a

 

 

:0:02€.B¢¢-:_-Bou-w:=n::0
5302803890.:730$32286

 

V 8:8:?§:-5-€938-.§£ *o>_d>-u_85*

 

8330mm 530:5 $0309.."

 

 

 

 

 

237
7.10 Conclusion

We started this chapter by presenting an overview of the conceptual design phase of the
engineering design process. Past experience plays a pivotal role in the field of engineering
design. Design engineers use engineering handbooks, design catalogs, as well as other
documents, such as principles of physics and description directed materials, when
designing new artifacts. However, recollections of successful designs often have an
important impact on how the current design will proceed. Design engineers begin a new
design by defining the high-level function of the artifact, then they refine the preliminary
design by determining the subdevice’s functionality. After they developed sufficient
details, they compose specific components to achieve the desired functions of the artifact.
We argue that a predefined set of standard components and connectors can be used during
the conceptual design phase to enhance the human modeler’s ability to use past experience
and reduce both design time and errors. Thus, the Functional Approach, augmented with
our library of standard parts and model selection procedure has been proposed as a

conceptual design tool.

In this chapter, we defined standard parts and showed how to construct a standard part
library. We gave special attention to our standard part selection procedure. Our standard
part selection algorithm is a novel approach to selecting standard parts from the library.
The complexity analysis of the algorithm shows that in real-world situations, it is a
tractable procedure. We used the engine fuel supply system of the PIA-18 aircraft to show
a slice of the fuel system’s standard part library and demonstrated its use during the
modeling process. We concluded this chapter with potential payoffs of augmenting

Functional Modeling with a library of standard parts.

Chapter 8

Conclusion

In our research, we have focused on extending the theory behind the Functional Approach
that was first introduced by Sembugamoorthy and Chandrasekaran in 1984
(Sembugamoorthy & Chandrasekaran, 1984). The test bed we used for our research was
the fuel system of the PIA-18 aircraft. Our functional model implementation of the fuel
system provided strong evidence for the scalability and representational power of the
Functional Approach. We also proposed an extension to the Functional Representation that
explicitly represents the connections between components and the flow of substances at the
connections. Finally, we augmented Functional Modeling with a standard part library and
model selection procedure. We will now present a summary of our findings and the
techniques developed in this thesis, crystallizing the main contributions. We will then

provide a road map for future work.

8.1 Summary

In this thesis, we addressed the four key goals set forth in Chapter 1. The first goal we
addressed was to test the feasibility of Functional Modeling (FM) for reverse engineering

of physical systems. We successfully constructed a functional model for the F/A- 18 aircraft

238

239
fuel system. Our method for knowledge acquisition was reverse engineering the system

using technical manuals provided by the McDonnell Douglas Corporation. Although
reverse engineering the fuel system was a tedious and time-consuming task, we acquired
the knowledge necessary to build a functional model of the fuel system. Furthermore, the
functional decomposition techniques set forth by FM provided the crucial organizational
structure needed to guide the knowledge acquisition process, thus demonstrating the power

of FM as a knowledge acquisition tool.

Our second goal was to investigate the scalability of Functional Modeling in a realistic,
heterogenous domain. The sense in which we used the term scalability was two fold. First,
we meant the ability of FM to scale to larger sized systems. Second, we meant FM’s ability
to model a system in a profoundly different domain than the previously investigated
domains. The complexity of the fuel system rendered our implementation the largest model
built to date in the Functional Reasoning community. The model was composed of 89
components, 92 functions, 118 behaviors, and 181 state variables. Furthermore, the fuel
system was a different domain than the previously investigated domains in the Functional
Modeling paradigm. The fuel system domain was a heterogenous domain consisting of
tanks, pumps with different characteristics, numerous valves with different operating

modes/structures, switches, and transducers.

By building a functional model of the fuel system, simulating the model, and producing
simulation results, we demonstrated that the Functional Approach was scalable to large,
complex devices in new domains. Among the important and interesting simulation results
we obtained was a demonstration of redundancy which was built into the engine fuel
supply system and motive flow system. Another important and interesting result we
acquired was the operation of the fuel level sensor and how it controlled the engine fuel

transfer shutoff valve for the fuel transfer system.

240
During the course of constructing the functional model of the fuel system, it was

necessary to represent the flow of fuel and connections between components in a
convoluted way. The difficulty was due to the lack of explicit representational primitives
for the basic ideas of connectivity and flow in the FM framework. Thus, modeling the fuel
system would have been more straightforward if we could represent the operation of the
fuel system’s components in terms of connectivity and fluid flow. This observation was the

motivation for the third objective of this thesis.

Thus, the third objective we addressed in this thesis was the incorporation of
connectivity into the current Functional Approach. The Functional Approach formed a
strong foundation for our proposed connectivity extension. Device models are constructed
by decomposing a device into its constituent subdevices. The subdevices are in turn
devices themselves. A device can be thought of as having input ports and output ports
through which it interacts with its environment. The manner in which the subdevices are
interconnected at these ports determines how the overall device will behave. Thus, our first
step in the connectivity representation was to include ports in the structural specification of
the device. Our next step was to explicitly represent how the subcomponents of the device
are interconnected to form the overall device. Although other researchers have defined
ports in previous work, we believe that our definition of ports and its usage to represent
connectivity is a novel approach. We have contributed to the theory of Functional

Modeling by explicitly representing connectivity and formalizing the connectivity relation.

In our experience with the F/A-l8 aircraft fuel system, we noticed that the fuel system
consisted of many components having standard functionality. For instance, there were
various types of valves, such as check valves, shutoff valves, and fuel dump valves.
Although these valves were different geometrical configurations, they each functioned as a
generic valve. Moreover, each specific type of valve appeared numerous times in the entire

model of the fuel system. These observations lead us to the next objective, to create a

241
library of standard parts to automate the modeler’s ability to select standard parts for a

specific task, which is the central goal of this research.

Hence, we discuss the final objective of this thesis: the standard part library construction
and model selection algorithm. We formulated the problem of standard part selection from
a library as a representation search problem and provided answers to the following four

questions:
1. What is a standard part model, and what is the library of standard parts?
2. What are the possible uses of a standard part library?

3. How do we search the library of standard parts for a desired standard part
model?

4. How do we incorporate a standard part model in the model of a whole

system?

We defined a standard part as an abstraction of a known, off-the-shelf artifact, suitable
for instantiation. We represented each standard part with its name, its constituent
components, a set of functions, a set of ports, and finally a set of relations between its
subcomponents (i.e., ConnectedTo). The set of ports represented the connectivity
constraints of the standard part. Only ports with equivalent types of substance flow were
allowed to be connected. For example, a port with fuel as its type of substance could not be
connected to another port with electrical-signal as its type of substance. The library of
standard parts was then defined explicitly as the repository of standard part models for the

physical systems being modeled.

We considered the organization of the standard part library as an important issue in
constructing and utilizing the library. The standard parts in the library are organized in a

class hierarchy. Although at first glance, the hierarchy may appear to be organized

242
according to the structure of each device, in actuality the standard parts are organized based

on the functions of each standard part. The class of a standard part is determined by the
function it delivers. For instance, a valve is a class of standard parts whose elements deliver
two functions, enable flow and disable flow. A check valve is a specialized valve, with

specialized functions. Therefore, the check valve class is a subclass of the valve class.

We enumerated possible uses of a standard part library in the PIA-18 domain and
numerous other domains, and presented a list of the potential domain advantages of
utilizing a standard part library. Among the potential advantages, the most formidable were
the facilitation of rapid development of functional models and the promotion of resource
sharing during the modeling of similar artifacts. We argued that a standard part library
could be considered a conceptual design tool. We then presented our approach to

constructing a library of standard parts.

For selecting a standard part from the library, we developed a computationally tractable
algorithm. The development of this algorithm was inspired by the approach taken by real-
world engineers when assembling an artifact from off-the-shelf standard parts. In our
algorithm, we first select standard parts that fit into the overall device model (i.e., satisfy
the connectivity constraints). If we succeed in selecting a set of standard parts that fit into
the model, we then choose those that deliver the required functions. As long as a
component satisfies the functional and connectivity constraints of the desired device, it is

selected without consideration of its internal structure.

The time complexity analysis of the model selection algorithm was the key to proving
the tractability of the algorithm. During the complexity analysis, we addressed two
different aspects of the procedure: the theoretical aspect and the real-world, practical
aspect. Theoretically, if we have a large number of uniformly labeled input and output
ports, finding the correct mapping between two sets of ports is an intractable operation.

However, when we viewed this problem from a real-world, real-device point of view, we

243
noted that most devices have a limited number of ports. Furthermore, the ports are

distinguished by their type of substance flow, which in most cases gives each port a unique
identity. In these cases, the number of possible mappings between the two sets of ports is a
constant. This characteristic of real-world devices makes the algorithm a tractable

approach for model selection.

8.2 Contributions of this Research

We believe our work in this thesis enhances the theory and practice of the Functional
Modeling framework. In this section, we summarize what we consider to be the most

significant contributions of this thesis.

First, our success in implementing the fuel system model demonstrated that the
Functional Approach is suitable for modeling large, complex devices. As we stated in
Chapter 3, the fuel system is a different domain than those previously investigated by the
Functional Approach. By constructing a functional model for the fuel system, we
empirically demonstrated the scalability of the Functional Approach. Previous test cases in
the Functional Reasoning community had not pressed this issue. With these empirical
results in hand, other researchers can approach large scale problems with added confidence
in FM’s ability to tackle such problems. In addition, by applying the Functional Approach
to model the fuel system, we uncovered the shortcomings of FM which paved the way for

our other contributions.

Our second contribution is related to the added expressive power of the Functional
Representation. In our work, we investigated different senses of ports and developed
primitives to explicitly represent the connections between components. Our connectivity
representation enhances the representational power of the Functional Approach so that a

more general sense of device can be captured. We consider our connectivity extension a

244
novel approach and a necessary extension to overcome the challenges presented by the fuel

system project, as well as other systems involving fluid flow.

Our standard part library extension and model selection algorithm contributes to a
modeler’s ability to construct functional models in an efficient manner. One of the most
time consuming and error-prone activities we encountered when modeling the fuel system
was copying the same type of component into the model several times. The standard part
library extension alleviates the modeling difficulties associated with a modeler reusing the
same component multiple times in a model. Thus, the standard part library has the potential
to facilitate more rapid development of a functional model and resource sharing when

modeling similar artifacts.

The Functional Approach augmented with the standard part library and model selection
algorithm also contributes to the engineering design process. More specifically, we
consider the standard part library an important step towards the capture and reuse of design
knowledge. We identify the library of standard parts, with its standard part model section
procedure, as a tool to support the conceptual design phase of the design process. In this
phase, the functional requirements of the artifact under design are defined, and behaviors
are composed which achieve the desired functions. The behaviors that carry out the
functional requirements are used to guide the selection of standard parts which can then be
composed into different system configuration. Functional Modeling supports the
representation of function and behavior demanded by the conceptual design process.
Furthermore, the standard part library and model selection procedure provide the
methodology of supplying the correct standard part based upon the desired function of the

artifact under design.

In the current competitive global economy, industrial enterprises seek to improve the
cost-effectiveness of their design and manufacturing processes. Thus, industry demands

tools and methods to:

245
0 reduce the development and delivery time of their products

. improve the quality, consistency, testability, manufacturability and

maintainability of the product

Functional Modeling supports the reuse and sharing of existing designs through our
standard part library facility. Reusing standard parts reduces the development time cycle of
the product since the component does not have to be redesigned from scratch. Furthermore,
reduction in product development time reduces product delivery time and its cost
effectiveness. Finally, reusing components which have been shown to function correctly in
the past will meet industries goals of improved quality, consistency, testability,

manufacturability and maintainability of the product.

8.3 Future Work

The work described in this thesis can be extended in a number of different ways. The
specific directions for future work are geared toward extending the theory and practice of
Functional Modeling. The following is a description of the possible directions for future

work in this area.

8.3.1 Graphical Model Editor

Intuitively, a graphical model editor is a utility that enables human modelers to construct
connectivity models (structural models) by selecting components from a palette and
positioning them graphically to represent the desired position of the component in the
model. This is precisely the intuition we would like to operationalize in a graphical model
editor for functional models. The standard part models would be represented by graphical
icons defined by the designer, the domain expert, or the human modeler. The editor would
generate FM code from the graphical representation developed by the modeler. The
graphical model editor would have the capability to perform consistency checks on the

246
connections between the standard parts as they are defined. The representation of ports

would be utilized to ensure that the connected ports are consistent (i.e., the type of

substance flow is the same for the connected ports).

8.3.2 Generating Reliability Causal Chain

One of the most active areas of research in model-based reasoning is fault diagnosis. Davis

defines model-based diagnosis as the following activity (Davis & Hamscher, 1988):

0 Given: Structural descriptions of an artifact, behavioral descriptions of the

components of the artifact and the input and output of the artifact.
0 Determine: The components that can account for the anomalous behavior.

Hamscher provides a similar definition. According to Hamscher, given the observations
of anomalous behavior, model-based diagnosis reasons backwards from a functional
schematic of a device to isolated faults (Hamscher, Console, & deKleer, 1992). In
(Hawkins, Sticklen, McDowell, Hill, & Boyer, 1993), Hawkins et al. show how Functional
Modeling can be leveraged to support the fault diagnosis problem. FM provides
mechanisms for both forward and backward reasoning. In other words, FM provides
capabilities to trace from hypothesized malfunctions to observed manifestations (forward
reasoning) or from observed manifestations to the hypothesized malfunctions (backward
reasoning) (Chandrasekaran, 1994). However, we feel this does not fully capture the

model-based fault diagnostic task.

The fault diagnosis problem inherently involves uncertainty. For complex systems, like
the fuel system, any number of individual faults or combinations of faults may be the cause
of the abnormal behavior. Thus, there are a large number of possible explanations for the
abnormal behavior. Instead of enumerating all possible faults, we would rather concentrate

on the most likely explanations.

247
During the design process, design engineers build functional models of the artifact being

designed. Often, in addition to the functional specifications, each designed artifact has a
reliability estimate assigned to it by design engineers and/or reliability engineers. A
standard quantity used to estimate reliability is the Mean Time Between Failures (MTBF).
The MTBF is used to quantify a device’s reliability, and is often available for off—the-shelf

components.

As an offspring of our standard part library, we aim to extend Functional Modeling to
include reliability estimates assigned to each standard part. The functional model of an
overall device composed of several standard parts can then be translated into a reliability
network. Integrating Functional Modeling and reliability estimates has the potential payoff
of addressing important problems such as preventive maintenance, optimal repair

strategies, and reliability analysis.

8.3.3 Integrating FM with Energy-Based Modeling

In this thesis, we argued that a library of standard parts in the Functional Modeling
framework can be utilized to support the conceptual design process. A primary objective of
the continuation of our research is to fully develop a strong conceptual design environment
to support the design of physical systems. One of the frameworks which is being
considered is the integration of functional-based modeling with the energy—based modeling
approaches used in system dynamics (Amsterdam, 1992; Karnopp & Rosenberg, 1990;
Paynter, 1961; Xia, Linkens, & Bennett, 1991). In energy-based modeling approaches, a
system is viewed as a collection of spatial regions. Each region has a uniform energy
behavior represented schematically as elements. The behavior of these elements is defined

over effort and flow variables.

The energy-based modeling approaches classify all standard physical phenomena into a

fixed, finite set of elements and their interconnections. The energy-based modeling

248
approach using Bond Graph notation is an ideal candidate for augmentation with

Functional Modeling because of the following characteristics of Bond Graphs which

complement our approach:

0 The Bond Graph modeling language can be utilized by an energy-based
modeling approach to describe the exchange of energy in devices.
Furthermore, the energy properties are congruent with the underlying
physical laws of the devices (Karnopp & Rosenberg, 1990).

o In system dynamics, devices are treated as collections of subdevices that
exchange, store and transform energy. These ideas have been used by design

engineers in modeling physical systems for years.

0 Both energy-based models and functional models demonstrate many of the
desired features of physical models, such as decomposability and
composability. Standard parts implemented in Bond Graphs with their
functional model counterparts have the potential to complement each other

in modeling physical systems.

0 Bond Graphs have concise and uniform syntax for describing engineered

systems.

- Augmenting Functional Modeling with Bond Graphs enhances model
validation. Bond Graphs support model validation against physical
principles. The integrated framework would put functional models on a
firmer ground. Currently, the only method of model validation is for the
domain expert to simulate predefined cases and compare the simulation

results to the anticipated results.

0 Bond Graphs provide a uniform database across energy domains such as

electronics, mechanics, and hydraulics. The Bond Graph representation is

249
hierarchical with models at multiple levels of abstraction. This feature is one

of the most desirable features of physical systems models.

There are some active research projects involving Qualitative Reasoning and Bond
Graph approaches (Top, 1992). Future work in this area will involve exploring the
literature of prior research in this area and augmenting FM with the Bond Graph

framework.

8.3.4 Enhancing Model Selection Procedure

In this thesis, we proposed three different usage modes for the standard part library.
0 A modeler could use the library as a static repository of standard parts.

. A modeler could use the library to automatically choose the appropriate
device based on the connectivity and functional constraints imposed by the

functional requirements.

0 A modeler could select a class of models without the current functional
constraints being strong enough to force the selection of a single model
from the class. During simulation, however, the need for a group of

functions might become strong enough to force a selection.

In our model selection procedure, we focused on the first and second usage modes. In
the continuation of our standard part library research, we aim at investigating model
selection problems in which the standard parts in the library meet only a portion of the
required functional constraints. In cases where the functional constraints are not strong
enough to force a selection of a single standard part, the standard parts that satisfy the
partially specified functional constraints can be used to suggest additional functional

constraints to force a choice.

250

8.3.5 Representation of Functions That Arise From Geometric
Descriptions.

Our long-term research goals are aimed at extending state representations to include
devices which are shapes. Currently, our state representation only includes high level state
predicates about the effects of shapes. Representing and reasoning about shape and motion
is time consuming and difficult even for experienced engineers. Joskowicz and Sacks
identify the tasks which must be performed by designers for reasoning about shape and
motion (Joskowicz & Sacks, 1994). According to their report, only a few aspects of
reasoning about shape and motion are supported by current Computer Aided Design
(CAD) systems. Furthermore, while those CAD systems which are based on the drafting

paradigm support the design of a part’s shape, they do not support reasoning about motion.

Representing shapes will help design engineers and human modelers avoid convoluted
modeling representations needed to model an object’s shape. In some cases, such as
explaining how a gear train works, it is extremely difficult to construct a device model
without some idea of the geometrical or structural descriptions. Extending the Functional
Approach to include geometrical descriptions will enable human modelers to represent
each component of the device in the closest and most natural way. This will also allow us
to incorporate some basic kinematic analysis tools into the Functional Modeling

framework.

8.4 Final Note

One of the most important issues we addressed in this thesis was the shortage of skilled
engineers in the United States (Engelmore & Tenenbaum, 1990). This is a critical issue that
should not be taken lightly. One way to address this issue is to increase the pool of highly
skilled engineers. Another way is to improve the effectiveness of current engineers by

providing intelligent assistance. This can be accomplished by utilizing the expertise of

25 I
experienced engineers in developing advanced modeling and simulation tools to assist all

engineers. As part of our future research, we will focus on sharpening our tools and
methods to help experienced practitioners put their expertise at the disposal of novice

engineers. We present this thesis as a first step toward this end.

BIBLIOGRAPHY

Addanki, S., Cremonini, R., & Penberthy, J. S. (1991). Graphs of models. Artificial
Intelligence, _5_1_, 145-177.

Allemang, D. T. (1990). Understanding Programs As Devices. Ph.D. Thesis, The Ohio
State University.

Amarel, S. (1968). On Representations of Problems of Reasoning About Actions. Machine
Intelligence, 3, 131-171.

Amsterdam, J. (1992). Automated Modeling of Physical Systems. Automated Modeling,
DSC-Vol. 41(ASME 1992), 31-36.

Amsterdam, J. (1993). Automated Qualitative Modeling of I_)ynamic Physical Systems.
Ph.D. Thesis, MIT Artificial Intelligence Laboratory.

Barnes, & Noble (Eds). (1990). America's Top Guns. Hong Kong: Barnes and Noble.

Blackburn, J. F., Reethof, G., & Shearer, J. L. (Eds). (1960). Fluid Power Control.
Cambridge, MA: MIT Press.

Bond, W. E., Sticklen, J ., & Pegah, M. (1991). Model Based Reasoning in the Aerospace
Domain. In American Institute of Aeronautics and Astronautics.

Bonnet, J. C. (1992). Towards Formal Representation of Device Functionality Tech. Report
92-54. Knowledge Systems Laboratory, Stanford University.

Bratko, I. (1994). Machine Learning and Qualitative Reasoning. Machine Learning, fi,
305-312.

Chandrasekaran, B. (1993). Functional Representation and Causal Processes Technical
Report, Ohio State University.

Chandrasekaran, B. (1994). Functional Representation and Causal Processes. In M. C.
Yovits (Ed), to appear in: Advances in Computers Academic Press.

Chandrasekaran, B., Goel, A., K, & Iwasaki, Y. (1993). Functional Representation as
Design Rationale. IEEE ComputerUanuary), 48-56.

Chandrasekaran, B., Smith, J. W., & Sticklen, J. (1989). Deep Models and their Relation to

Diagnosis. In Furukawa (Ed), Artificial Intelligence in Medicine Amsterdam, Netherlands:
Science Publishers.

252

253
Coglianese, L. H., & Szymanski, R. (1993). DSSA-ADAGE: An environment for

architecture-based avionics development. In AGARD confereng proceedings 545,

Aerespace Software Engineering for Advanced Systems Architectures, (pp. 32.1-32.8).
France: NATO.

Cormen, T. H., Leiserson, C. E., & Rivest, R. L. (1990). Introduction to Algorithms.
Cambridge, Massachusetts: The MIT Press.

Coyne, R. D., Rosenman, M. A., Radford, A. D., Balachandran, M., & Gero, J. S. (1990).
Knowledge-Based Design Systems. Reading, Massachusetts: Addison-Wesley.

Darden, L. (1990). Diagnosis and Fixing Faults in Theories. In J. Shrager & P. Langley

(Eds), Computational Models of Scientifie Discoveg and Theog Formations (pp. 319-
346). Hillsdale, N .J .: Laurence Erlbaum.

 

Davis, R., & Hamscher, W. (1988). Model-Based Trouble Shooting. In M. Shroke (Ed),
Explering Artificial Intelligence San Mateo, CA.: Morgan Kaufmann.

deKleer, J, & Brown, J. S. (1984). A Qualitative Physics Based on Confiuences. Artifieial
Intelligence, 24, 7- 83.

Dixon, J. R., Duffey, M. R., Irani, R. K., Meunier, K. L., & Orelup, M. F. (1988). A
Proposed taxonomy of Mechanical Design Problems. In fIfl_ie ASME Qornppteg in
Engineering Conference, 1 (pp. 41-46). San Francisco, CA: ASME.

Doebelin, E. O.(l980).S stemM 1' an R 8 ns: e 'cal Ex ri ental
Approaches. New York, N .Y.: Wiley.

Domeshek, E. A., Hemdon, M. F., Bennet, A. W., & Kolodner, J. L. (1994). A Case-Based
Design Aid for Conceptual Design of Aircraft Subsystems. In Proceedings of the Tenth

IEEE Conference on Artificial Intelligence for Applications, (pp. 63-69). San Antonio,
Texas: IEEE.

Engelmore, R. S., & Tenenbaum, J. M. (1990). fl'eward the Engineer's Asso_c_iste: A

Nationg Computatienal erastruegge for Engineering (Technical Report No. KSL 90-64).
Knowledge Systems Laboratory, Stanford University.

Ermer, G., Goodman, E, Hawkins, R., McDowell, J. ,Rosenberg, R, & Sticklen, J. (1993).
Steps toward Integrating Functional-based Models and Bond-Graph for Conceptual

Design in Engineering. In ASMEW inter Annual Meeting. New Orleans, LA: ASME.

Falkenhainer, B., & Forbus, K. D. (1991). Compositional modeling: finding the right
model for the job. Artifieial Intelligence, _5_1_, 95-143.

Faltings, B. (1990). Qualitative Kinematics in Mechanics. In D. S. Weld & J. deKleer
eadin in ' tiv eas nin About h sic ste San Mateo, CA:
Morgan Kaufmann.

Feigenbaum, E. A., Buchanan, B. & Lederberg, J. (1971). On Generality and Problem
Solving: A Case Study Using the DENDRAL Program. In D. Michie (Ed), M__achine
Intelligenee Elsevier.

254

Fikes, R., Gruber, T., Iwasaki, Y., Levy, A., & Nayak, P. (1991). How Things Work floject
Overview Technical Report: Knowledge Systems Lab, Computer Science Department,
Stanford University.

Fishwick, P. A., Narayanan, N. H., Sticklen, J ., & Bonarini, A. (1993). A Multimodel
Approach to Reasoning and Simulation. IEEE Transactions en Systems, Man and

W.
Forbus, K. D. (1984). Qualitative Process Theory. Artificial Intelligence, 25, 85-168.

Freeman, P., & Newell, A. (1971). A Model for Functional Reasoning in Design. In

Proceedings of the Second International Joint Conference on Artificial Intelligence, (pp.
621). London, England.

Gelsey, A. (1990). Automated Reasoning about Machine Geometry. In D. S. Weld & J.

deKleer (Eds), Readings in Qealitative Reasening About Physical Systems San Mateo,
CA: Morgan Kaufmann.

 

Gero, J. S. (1990). Design Prototypes: A Knowledge Representation Schema for Design.
AI Maggine, QM), 26-36.

Gilovich, T. (1981). Seeing The Past In The Present: The Effect of Associations to Familiar
Events on Judgements and Decisions. Persenality and Sggifl Psycholegy, Q6), 797-808.

Goel, A., & Chandrasekaran, B. (1989). Functional Representation of Designs and
Redesign Problem Solving. In Eleventh International Joint Confereng on Artificial
_I_n_t_efigen_ce, Detroit, Michigan.

Goel, A. K. (1989). Integretion of Case-Basfl Reasening Qd Mflel-Basg Reasem’ng
For Adaptive Design Problem Solving. Ph.D. Thesis, The Ohio State University.

Goel, A. K. (1992). Representation of Design Functions in Experienced-Based Design. In

D. Brown, M. Waldron, & H. Yoshikawa (Eds), Intelligent Computer Aided Desigp (pp.
283-308). Amsterdam, Netherlands: North-Holland.

Goldberg. A., & Robson. D. (1989). W- Reading.
Massachusetts: Addison-Wesley.

Gruber, T. R. (1992). Model Eqmulsp’en rig s Problem Selving fI'esk: Cemeter assism
Engineering Modeling (Technical Report No. KSL 92- 57). Stanford University.

Gruber, T. R. (1993). Towar Princi les for e si f On 01 i r owl
Sharing (Technical Report No. KSL-93-04). Knowledge Systems Laboratory, Stanford
University.

Gruber, T. R., & Olsen, G. R. (1993). An Ontology for Engineering Mathematics. In J.
Doyle, P. Torasso, & E. Sandewall (Eds), Fourth International Conference on Principles of
Knowledge Representation and Rwening, (pp. Available as Stanford Knowledge Systems
Laboratory technical report KSL-94-18). Gustav Stresemann Institut, Bonn, Germany:
Morgan Kaufmann.

 

Hamscher, W., Console, L., & deKleer, J. (1992). Model Based Diagnosis. San Mateo, CA:
Morgan Kaufmann Publishers, Inc.

255

Hawkins, R., Sticklen, J ., McDowell, J. K., Hill, T., & Boyer, R. (1993). Troubleshooting
Based on a Functional Device Representation: Diagnosing Faults in the External Active
Thermal Control System of Space Station FREEDOM. In The Working Notes of the

AAAI-23 Workshop on Reasoning About Functions, (pp. 149-156). Washington, DC:
American Association for Artificial Intelligence.

Henderson, M. R., & Taylor, L. E. (1993). A Meta-Model for Mechanical Products Based
Upon the Mechanical Design Process. Research in Engineering Design, S, 140-160.

Herbert, C. A. (1989). Hornet Maintenance. Peggedings of Annnal Reliabilig and
Maintainabilig Symmsium, 405-408.

Holyoak, K. (1985). The Pragmatics Of Analogical Transfer. In G. Bower (Ed), The
Psychology of Learning and Motivation New York, NY: Academic Press.

Hundal, M. S., & Langholtz, L. D. (1992). Computer-Aided Conceptual Design: An
Application of X Windows, With C. Design Theog and Methodology, DE-Vol.
4_2_(ASME), 1-9.

Iwasaki, Y. (1989). The Hgdbook ef Artificial Intelligence. Reading, Massachusetts:
Addison-Wesley.

 

Iwasaki, Y., & Chandrasekaran, B. (1992). Design Verification Through Function- and
Behavior-Oriented Representation. In J. S. Gero (Ed), Artifieiel Intelligeng in Design (pp.
597-616). Netherlands: Kluwer Academic Publishers.

Iwasaki, Y., & Chee, M. L. (1991). Model Generation and Simulation ef Device Behavior

with Conn'nnous an Discrete Changes (Technical Report No. KSL 91-69). Knowledge
Systems Lab, Stanford University.

Iwasaki, Y., & Levy, A. Y. (1994). Automated Model Selection for Simulation. In

Proceedings of the Twelfth National Cenference on Artificial Intelligence, 2 (pp. 1183-
1190). Seattle, Washington: AAAI Press/The MIT Press.

Jorgensen, D. E., & Hernandez, C. M. (1983). Advanced avionics systems for an aerospace

plane. In IEEE/AIAA, Fifm Digital Avionies Systems Conference, (pp. 25.1-25.7).
Seattle, Washington.

Josephson, J. R. (1993). Formalizatien ef Functional Repregntation Using Data 13553
(Technical Report Ohio State University.

Joskowicz, L., & Sacks, E. (1986). Computational Kinematics. M'ficial Intelligence, 22.
Joskowicz, L., & Sacks, E. (1994). HIPAIR: Interactive Mechanism Analysis and Design
Using Configuration Spaces. In Meedmgs ef the Twelfth National Confereng on
Artifieial Intelligence, 2 (pp. 1505). Seattle, Washington: AAAI Press/MIT Press.
Kaplan, G. (1994). Concurrent Engineering. W, fl(6), 33-43.

Karnopp, D. C., & Rosenberg, R. C. (1990). System Dynamics: A Unified Approach. New
York: John Wiley and Sons.

Keuneke, A., & Allemang, D. (1989). Exploring the 'No Function In Structure' Principle.
Journal of Exmrimentfl and Theoretical Artificial Intelligence, 1, 79-89.

256

Keuneke, A. M. (1989). Machine Understanding of Devices Causal Explanation of
Diagnostic Conclusions. Ph.D. Thesis, The Ohio State University.

Keuneke, A. M. (1991). Device Representation. IEEE Ex rt, 4, 22-25.

Klein, S. (1992). An Example of Knowledge-Based Decision Making When Selecting
Standard Components: Shaft-Hub Connections. Design Theory and Methodology, g, 149-
156.

Kuipers, B. (1986). Qualitative Simulation. Artificial Intelligence, 22, 289-338.

Kuipers, B. (1989). Qualitative Reasoning: Modeling and Simulation with Incomplete
Knowledge. Automatica, 25(4), 571-585.

Kuipers, B. (1990). Qualitative Simulation. In D. S. Weld & J. deKleer (Eds), Readings in
’tative easonin about Ph sical S stems San Mateo: Morgan Kaufmann.

Levy, A. Y. (1993). Irrelevance Reasoning in Knowledge Based Systems. Ph.D. Thesis,
Knowledge Systems Laboratory, Stanford University, Stanford, CA.

Lipsett, R., Schaefer, C. F., & Ussery, C. (1989). VHDL: Hardware Description and
Design. Boston: Kluwer Academic Publishers.

Mathworks, Inc. (1992). The Student Edition of MATLAB fer MS-DOS or Macintosh
Computers. Englewood Cliffs, NJ: Prentice Hall.

Mittal, S., & Frayman, F. (1989). Towards a Generic Model of Configuration Tasks. In
Prmeedings of UCAI 11, 2 (pp. 1395-1401). Detroit, MI: Morgan Kaufmann Publishers.

Motta, E., Rajan, T., & Eisenstadt, M. (1990). Knowledge Acquisition as a Process of
Model Refinement. Knowledge Acquisition, 2, 21-49.

N ayak, P., P, Joskowicz, L., & Addanki, S. (1992). Automated Model Selection using
Context-Dependent Behaviors. In mmr'ngs of AAAI-22, (pp. 710-716). San Jose,
California: AAAI Press/ The MIT Press.

Nayak, P. P., Addanki, S., & Joskowicz, L. (1990). Modeling \Vrth Context Dependent
Behaviors. In The Workin Pa rs f the l Wor h n Model Based Reasonin , (pp.
1-8). Boston, Massachusetts: American Association for Artificial Intelligence.

Oster, J. (1969). Basie Applied Fluid Power: Hydraulics. New York, NY: McGraw-Hill
Book Company.

Patil, R. S., Szolovits, P., & Schwartz, W. (1981). Causal Understanding of Patient Illness
in Medical Diagnosis. In Proceegh'ngs of IJCAI 7, 2 (pp. 893-899). Vancouver, BC,
Canada.

Paynter, H. M. (1961). Analysis and Design of Engineering Systems. Cambridge, MA:
MIT Press.

Paynter, H. M. (1992). An Epistemic Prehistory of Bond Graphs. In P. C. Breedveld & G.
Dauphin-Tanguy (Eds), Bond Graphs for Engineers (pp. 3-12). North-Holland: Elsevier
Science Publishers B. V.

257

Pippenger, J. J ., & Koff, R. M. (1959). Fluid-Power Controls. New York, NY: McGraw-
Hill Book Company.

Polmar, N. (1993). The Naval Institute Guide to the Ships and Aircraft of the US. Fleet
(Fifteenth ed). Annapolis, Maryland: Naval Institute Press.

Pople, H. (1982). Heuristic Methods for Imposing Structure on 111 Structured Problems:
The Structuring of Medical Diagnosis. In P. Szolovits (Ed), Artificial Intelligence in
Medicine (pp. 119-189). Westview Press.

Pugh, D. R., Hunt, J. E., & Price, C. J. (1994). Augmenting Raphael with BehaviourCharts.

In J. Hodges (Ed), Representing and Reasoning About mvice Funetion Workshop, .
Seattle, Washington: AAAI Press/The MIT Press.

Rand, R. H. (1984). Com ter Al ebra in A 1i Mathematics: An Intr c ' n to
MACSYMA. Boston, Massachusetts: Pitman Advanced Publishing Program.

Rickel, J ., & Porter, B. (1994). Automated Modeling for Answering Prediction Questions:

Selecting the Time Scale and System Boundary. In Medings of the Nelfth National
Conference on Artificial Intelligence, 2 (pp. 1191-1198). Seattle, Washington: AAAI Press/

The MIT Press.

Rosenberg, R. C., & Karnopp, D. C. (1990). System Dynm‘cs: A unified Approach. New
York: John Wiley and Sons.

Rumbaugh, J ., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991). Ohjgt-
Oriented Modeling and Design. Englewood Cliffs, New Jersey: Prentice Hall.

Saulnier, E. T., & Bortscheller, B. J. (1994). Simulation Model Reusability. IEEE
Computer, 22(3), 64-69.

Schwarz, A. F. (1993). Hanko of VLSI Chip Design and Enpert Systems. San Diego,
CA: Academic Press.

Sembugamoorthy, V., & Chandrasekaran, B. (1984). A Scheme for Representation ef

Functioning of Devices and Compilation of Diagnostic Expert Systems. (Technical
Report) Department of Computer and Information Science, Ohio State University.

Sembugamoorthy, V., & Chandrasekaran, B. (1986). Functional Representation of Devices
and Compilation of Diagnostic Problem-Solving Systems. In J. Kolodner & C. Reisbeck

(Eds), Exmrience, Memog, and Lem’ g Lawrence Erlbaum Associates.
Shortliffe, E. H. (1976). Computer-begs; Mesh'cnl Censnlm'ons: MYCIN. New York:

Elsevier.

Smith, G. F., & Browne, G. J. (1993). Conceptual Foundations of Design Problem Solving.
IEEE Transacdons en Systems, Men, And Cybernetics, 23(5), 1209-1218.

Stein, J. L., & Tseng, Y.-T. (1991). Strategies for Automating the Modeling Process.
Automated Modeling, DSC-Vol. 34(ASME 1991), 69-87.

Stephanopulos, G., Johnson, J ., Kriticos, T., Lakshmanan, R., Mavrovouniotis, M., &
Siletti, C. (1987). Design-Kit: An Object-Oriented Environment For Process Engineering.
Comput. Chem. Eng., C(6), 655-674.

258

Sticklen, J. (1987). MDXZ: An Integratfl Medical Diagnostic System. Ph.D. Thesis, The
Ohio State University.

Sticklen, J ., & Chandrasekaran, B. (1989). Integrating Classification-Based Compiled
Level Reasoning with Function-Based Deep Level Reasoning. In W. Horn (Ed), Causal AI
Models: Steps Towards Applicetions (pp. 191-220). Hemisphere Publishing.

Sticklen, J., Chandrasekaran, B., & Bond, W. (1989a). Distributed Causal Reasoning.
Knowledge Acquisition, I, 139-162.

Sticklen, J ., Chandrasekaran, B., & Josephson, J. (1987). Modularity of Domain
Knowledge. Exmrt Systems: Research and Applications, 1.

Sticklen, J., Goel, A., Chandrasekaran, B., & Bond, W. E. (1989b). Functional Reasoning

for Design and Diagnosis. In Proceedings ef the Mflel Based Diagnesis International
stigma.

Sticklen, J ., Kamel, A., & Bond, W. E. (1991). Integrating Quantitative and Qualitative
Computations in a Functional Framework. Engineering Applications of Artifieial

Intelligence, 51(1), 1-10.

Sticklen, J ., & Tufankji, R. (1992). Utilizing a Functional Approach for Modeling
Biological Systems. Mathematieal end Cemputer Mfleling, l_6, 145-160.

Stroulia, E. (1992). Towa_rds A Functional Mgel of Reflective Learning (Thesis Proposal
No. GIT-CC-92-56). Georgia Institute of Technology.

Stroulia, E., & Goel, A. K. (1992). Generic Teleological Mechanisms and Their Use in

Case Adaptation. In Proceedings of the Fonneenth Agual Conference of Cognin've
Science Socielx. (pp. 319-324).

Sun, J ., & Sticklen, J. (1990). Steps Toward Tractable Envisionment via a Functional

Approach. In The Working Papers of the 19% Workshop on Model Based Reasoning. (Pp.
50-55). Boston, Massachusetts: American Association for Artificial Intelligence.

Sussman, G. J ., & Steele Jr., G. L. (1980). CONSTRAINTS: A Language for Expressing
Almost-Hierarchical Descriptions. Artificifl Intelligence, fl, 1-39.

Thadani, S. (1994). Constructing Functional Models of a Device From Its Structural
Degription. Ph.D. Thesis, Ohio State University.

Tong, C., & Gomory, A. (1993). A Knowledge-Based Computer Environment for the
Conceptual Design of Small Electromechanical Appliances. IEEE Computer, (January
1993), 69-71.

Top, J. L. (1992). Bond Graphs for Causal Explanations. In P. C. Breedveld & G. Dauphin-
flfiufi (Eds), Bond Graphs for Engineers (pp. 313-321). North-Holland: Elsevier Science
'3 ers B. V.

Top, J. L., & Akkermans, J. M. (1991). Qualitative Reasoning about Physical Systems: an
Artificial Intelligence Perspective. Fraflin Institute, 328(5/6), 1047-1065.

Tuinenga, P. W. (1988). SPICE: A Guide to Circuit Simulation and Analysis Using
PSPICE. Englewood Cliffs, N.J.: Prentice Hall.

259

van Dijk, J., de Vries, T. J. A., Breunese, A. P. J., & Breesveld, B. C. (1992). Automated
Mechatronic Systems Modeling Using MAX. In P. C. Breedveld & G. Dauphin-Tanguy
(Edvs) Bond Caphs for Engineers (pp. 323- 332). Amsterdam: Elsevier Science Publishers

VDI-GKE (1987). Guideline-2221: Systematic Approach to the Design of Technical
Systems and Products. In Dusseldorf: VDI-Verlag.

Vescovi, M., Iwasaki, Y., Fikes, R., & Chandrasekaran, B. (1993). CFRL: A Language for
Specifying the Causal Functionality of Engineered Devices. In Proceedings of the Eleventh

National Conference on Artificial Intelligence, 1 (pp. 626-633). Washington, DC: AAAI
Press/MIT Press.

Vlademirescu, A. (1994). The SPICE Book. New York, NY.: J. Wiley.

Weiner, M., & Cellier, F. E. (1993). Modeling and Simulation of a Solar Energy System by

use of Bond Graphs. In Proceedings of Western Simulation Multi Conference en Bond
Graph Mfleling, (pp. 301-306). San Diego, CA:

Weintraub, M. A. (1991). An Explanation-Based Approach to Assigning Credit. Ph.D.
Thesis, The Ohio State University.

Welch, R. V., & Dixon, J. (1992). Representing Function, Behavior and Structure During
Conceptual Design. Design Theony and Methodology, 4_2, 11-18.

Wolansky, W. D., Nagohosian, J., & Hanke, R. W. (1977). Fundamentals of Fluid Power.
Boston, MA: Houghton Miffin Company.

Wright, J. C. (1994). AN SI/ASSE 1016 Requirement. Peerless Faucet Corp, (Personal
Communication).

Xia, S., Linkens, D. A., & Bennett, S. (1991). Integration of Qualitative and Bond Graphs:
an engineering approach. In P. C. Breedveld & G. Dauphin-Tanguy (Eds), Bend Graphs
for Enginee£§ (pp. 323-332). Amsterdam: Elsevier Science Publishers B.V. (North-
Holland).