ARTIFICIAL INTELLIGENCE IN COMPONENT DESIGN

Roberto Melli
University of Rome 1 "La Sapienza," Italy
Keywords: Expert Systems, Knowledge-Based Systems, Artificial Intelligence, Knowledge
Acquisition.
Contents
1. Introduction
2. Characterization of the Design Process
3. Expert Systems, Expert Assistants and Expert Advisors
4. The task of "Designing a Component"
5. Selection and Design of a Feedwater Pump
6. Choice and Design of a Shell-and-Tube Heat Exchanger
Related Chapters
Glossary
Bibliography
Biographical Sketch
Summary
Expert Systems (ES) constitute a particular application, of some of the techniques of Artificial
Intelligence, aimed at the construction of codes (more properly, "automatic procedures")
capable of logically selective rather than deterministic behavior. While the heart of such
systems is their Inference Engine (i.e, the portion in which the rules are properly compiled
and consulted to extract higher level information on the System's future actions), their
indispensable input is a certain amount of knowledge about the universe they are supposed to
interact with. Such knowledge must be properly extracted, catalogued, possibly ordered,
logically collected or re-fragmented, and systematically fed into a special data base called the
Knowledgc Base (KB) of the ES. This chapter describes the principles of Knowledge
acquisition and Knowledge Base assemblage, and discusses some of the problems that may
arise with the collection, classification, and application of knowledge to design of
compressors.

1. Introduction
As of today, engineers use computers almost exclusively to perform system analysis tasks,
and only rarely to tackle the crucial and sometimes mutually conflicting design decisions
required by complex engineering projects. This represents a cost both in terms of economic
implications and in terms of innovation drawback. A possible solution is to upgrade from
CAD (Computer-Aided Drafting) to KAD (Knowledge-Aided Design, which we envision to
embed CAD). CAD tools are primarily a drafting aid; they cannot be applied to other
important aspects of the design process such as maintenance or fault diagnosis or design
improvements. Presently, their only purpose is to produce detailed and/or assembly drawings
of the components, even if lately they have been improved by the addition of capabilities like
3D representation and Finite Elements Analysis (FEA) pre- and post-processing, Generally,
CAD analysis is a complement to numerical analysis, and the combination of the two allows
for a better evaluation of the structural performance and of the mechanical properties of the
proposed component.
 Figure 1: The logical steps of a design activity.
Dashed lines indicate possibility of backtracking
A KAD-tool should represent instead a real assistant to the design activity of an engineer, and
as such it must deal with problems concerning the functional performance of a component.
The process of designing an industrial component involves some creative contribution which
goes beyond the proper assembly of subcomponents and brings an improvement over
previous models. This is particularly important during the concept formulation stage. A good
solution is often the result of a conceptual synthesis arising from past experience and a well
structured knowledge base. This conceptualization of the design activity has been formulated
in a widely accepted set of specifications, shown in the simplified flow-chart in Figure 1.
The adoption of KAD techniques can also enhance the degree of coordination among different
design aspects by integrating the information acquired from different sources. KAD has been
formally introduced in 1994. The main obstacle to the development of these techniques is
their being based on a deep knowledge of the design activities: a breakdown of these activities
focuses on each step involved in component design both as a single task and as part of a
process, and it is obviously very difficult to acquire in a systematic way. As a result of this
inherent difficulty, engineering companies have been reluctant to develop KAD tools, due to
the large amount of time and resources needed to set up and validate the relevant knowledge
base(s). Any component analysis must possess enough generality to retain its validity across a
broad spectrum of applications: regardless of the nature of the equipment operation, a quite
large number of factors must be considered in designing any unit. The most important
consideration is often the selection of the type of unit that performs the required service in the
most satisfactory manner. In developing the design, other criteria must be considered, such as
the properties of the material used, cost, etc. In other words, a preliminary concurrent
engineering modeling work needs to be developed in a sort of virtual desk where all the
functional, production, maintenance and disposal requirements are analyzed and integrated
into the final product. The output of this complex process will be the sought after "general
component design tool".
In order to justify the need of Expert Systems to assist engineers in components design, it is
important to remark that a design process is, in our technologically mature society, no longer a
purely creative, but rather a well formalized process: most of the activities can be thought of
as logical analogues of Catalog and Handbook consulting", and recourse to "intuitive"
creativity is either limited to details or shifted back to system level. Such a process is well-
suited to be implemented into a knowledge-based system that can enhance both the engineer's
choices and productivity. Furthermore, the advances in AI techniques and applications provide
the possibility of building qualitative models that reproduce the creative steps as well, whose
output represents the abstraction of possible solutions.
A design process starts with the identification of a need that can be satisfied by an engineering
product. The recognition of a need may come from different sources: market analysis,
solution for a technical problem, improvement of obsolete products, customer requests,
upgrading of an existing product, conformity to new regulations, etc.
The conceptualization phase presents multiple alternative solutions, each of them focusing on
one or more different aspects of the problem, like minimum cost, maximum performance,
environmental issues, etc. These aspects can be viewed as constraints that the logical process
of component design" must abide by. A necessary initial step of every conceptualization is
the building of a proper model of the component. It is also important to be capable of
producing more than one solution as result of the conceptualization phase.
The activities breakdown phase subdivides at different levels the design process design
activity into hierarchically ordered sub-activities.
The preliminary design phase provides a first-trial solution to the specific design problem.
The overall system configuration is developed from general basic design concepts.
It has been shown that most large design problems can be decomposed into sub-components
("design-in-the-small") and then integrated into the final system (design in the large). While
such an approach is immediately applicable to Complex Systems (like Energy Conversion
Systems), its application to simple components is more difficult, because of the large body of
"modular knowledge" needed in this latter case. As an example, consider the choice of a
feedwater pump in a modern large Steam Power Plant: once the design specifications are
given, there are very few solutions available, and they can all be found in a "Pump-database"
of rather limited extent. But once the pump has been selected, to design it is a different story:
not only is the amount of required knowledge much larger in extent, but also the decision tree
corresponding to the automatic drafting of the pump assembly has so many branches that an
efficient scan becomes arduous (see Section 5 here below).
In the end, the application of ES to component design can be thought of as the transformation
of a list of activities into a decision tree. The most powerful characteristic of such an approach
is the capability of ES to handle incomplete and inconsistent data, which make them suitable
to:
1. Solve problems normally solved by human experts
2. Find solutions to non-conventional problems (provided sufficient expert knowledge is
available)
3. Find solutions to incomplete or ill-structured problems
4. Quickly produce prototypes
5. Provide explanations for the different design choices

2. Characterization of the Design Process

Before selecting a KAD system, it is of fundamental importance to clearly formulate the
logical path(s) one wishes to follow. The most commonly used methods are:
- Abstraction (for ill-structured problems)
- Classification (for well-structured problems)
- Analogy (comparison with other solutions of similar problems)
- Error Handling
- Hierarchical Knowledge Elicitation
2.1. Abstraction
This is the process the designer adopts to focus on the most important aspects of the final
object. The technical specification of a component is the result of a search in a very large and
complex set of incomplete alternatives and therefore most of the problems are ill-structured:
the solution relies on the designer's capability of inferring properties that are independent of
the application domain.
In such an environment, the Expert System can act as an "advisor" that simply lists possible
alternatives and constraint violations and leaves the human expert with the task of selecting
the most appropriate solution(s). The extent of the search in the domain space can be reduced
by heuristically pruning partial solutions that are clearly not acceptable.
Another way to conceptualize the design process is to reproduce sentence construction
process: both activities possess a syntax consisting of vocabulary of primitive elements and a
grammar that specifies legal configurations of elements as well as a semantics (functional
mapping of inputs and outputs). For instance, the "correct" structure of a type of sentence is
"noun-verb-predicate, and the correct structure of a certain sub-process is stream1-
componentA- stream2".
A procedure that enjoys a good degree of success in structural and mechanical design is based
on the same principles that guide Fault Diagnostics: it is possible to construct the expected
performance curve of the component (or of an assembly of components) under its operating
conditions and use it as a reference in the analysis of the design of a new component. Any
deviation -both quantitative and qualitative- from the expected curve points to a fault in the
component operating conditions. The resulting diagnosis process creates a set of specific rules
that can be implemented into the broader knowledge base for further use in future component
design process. An example could be like this: IF the value of the design parameter T is too
high THEN contact pressure in part A is too high. The suggestion to be introduced into the
broad knowledge base would be: "Reduce contact pressure between part A and part C.
Notice that this is the same logical path applied (at system level) existing Inverse Design
methods.
Yet another, very interesting, way to perform component design is to reproduce a reverse fault
diagnosis procedure, in the form of a series of "what if?": the task reduces to an iterative
process that searches for a series of successive solutions to the problem "what component
must be inserted to avoid a failure in satisfying design requirement number j? and looping
over the entire set of design constraints and specifications.
2.2. Classification
Classification consists in establishing a multiple relationship among Decision Variables (the
selection of which is under the control of the decision-maker), Input Variables (that represent
the specific application), Random Variables (that might influence the adopted solution) and
Output Variables. By heuristically changing the pre-assigned variables on the basis of
previous experience, it is possible to define different scenarios and find the solution
associated to an assigned working domain. Using an Object Oriented approach it is possible to
provide an immediate example of such a procedure: if the Design Task is "Selection and
Design of a Pump", then the Input Variables are the Pump specifications (i.e., a list of
attributes of the instance of the class "Pumps", called 'The-Pump-to-be-designed"), the
Decision Variables are some of the Relevant Design Parameters RDP (shaft speed, pump
material, pump type etc., which also constitute a list of attributes of the same instance), and
the Output Variables OV are the remaining design parameters of the pump, which can be
determined by the "Pump Design Algorithm" (itself an attribute of the class "Pumps"). These
Output Variables are equal in number to the Degrees of Freedom (DoF) in the design of the
pump, and the set (RDP+OV) completely identifies the sought after <instance of the class
"Pumps">. Experience shows though that design problems are very seldom suitable of such a
straightforward and heuristically deterministic formalization (Figure 2).
2.3 Analogy
This technique is based on a logical embedding procedure (see Sciubba, Melli). In the above
example, the selection and design of feedwater pump can be "reconstructed" on the basis of
previous successful designs of "similar" components. Recurring again to an Object Oriented
procedure to clarify the example, suppose we have access to a list of successful designs of
feedwater pumps, and that
 Figure 2: Design by classification.
IV = Input Variables; DV = Decision Variables; RV = Random Variables; OV = Output
Variables; PDA = Pump Design Algorithm
Figure 3: Design by analogy
 F(xj,Class-FWP) can be a similarity law, a geometrical or kinematical average, etc.
each one of these successful objects is represented in our KB by a member FWP of the class
"Feedwater Pumps". We can compare the attribute lists of this class with the (yet incomplete)
attribute list of the pump we must design: it is likely thal M out of the N attributes (M<N) of
the "new" pump will be equal to the corresponding attributes of the parent class. Some of the
remaining N-M attributes can be selected on the basis of physical or engineering analogy (as
expressed by the theory of similarity, for instance, or of structural design). The degree of
success of such a procedure strongly depends on how ''common'' our component is: in our
example, for instance, if the water to be pumped contains corrosive agents, it is likely that no
previously defined attribute in the parent class matches the attributerequired in the instance
"The-Pump-to-be-designed", and an external independent design decision is required.
Therefore, analogy works best for the design of standard components (Figure 3).
2.4. Error Handling
Any design task consists essentially of an iterative "generate-test-process" procedure. The
designer uses a variety of cognitive operators to generate a design, test it under various
conditions and repeat the process until a stopping rule is reached. The design process can thus
be viewed as a complex decision tree that is scanned in depth and breadth (Sciubba, Melli) to
correct mistakes by means of recursive procedures. Here, an "error" is a non-compliance with
design specifications, and every time such an error is detected, some higher-level corrective
procedure must be activated to correct it and bring the component back to specification.
2.5. Hierarchical Knowledge Elicitation
The design process can also be analyzed by watching real designers at work and observing
how they solve problems. By analyzing the sequel of design steps followed by expert
designers it is apparent that they apply both basic (meta-level) knowledge (general
conservation principles and general constitutive equations) and problem-specific knowledge
(component-specific operating maps, optimal or sub-optimal aspect ratios, critical shape- or
operating level ratios, etc.). Less expert designers, who by definition lack detailed domain
knowledge, apply only more basic and general concepts, and the space spanned by their
tentative solutions is much larger. Since initial data seldom suffice to define completely the
design requirements, expert designers invariably and knowingly make explicit and implicit
problem-specific assumptions or elicit the missing information from other sources.
Furthermore, some of these assumptions as well as some of the initial data may be non-
explicitly related to other features that may be deemed important for the proper serviceability
of the designed component, and it is the designer's duty to take into account such hidden
features. The sequence of the design steps strongly affects the solution strategy: any mistake
forces the designer to backtrack and revise the solution strategy: an expert designer backtracks
less frequently.
Experience shows that most design problems are ill-structured, and their boundary conditions
are not well defined: they represent a typical example of problems for which a heuristic
paradigm can be applied to reach a solution. The solution search begins by decomposing the
problem into a set of sub-problems and by assessing a few sets of typical partial solutions.
The complexity of the solution search is then reduced by a highly formal application of
common sense rules aimed at the definition of a small set of problem-relevant parameters
carefully selected from a much larger set. As aresult of this process, the problem is logically
broken down into a set of hierarchically organized classes, each one representing a particular
instance of an initial design problem. In the above case of the feedwater pump, one may start
for instance with selecting the pump type (radial vs. axial), then its number of stages,
rotational speed, material, general assembly and detailed design: each one of these selections
is a sub-task that again can be broken down into sub-tasks, until this logical branching
reaches a level at which there are N sub-tasks and for each of them there is only a limited set
of "known solutions" to choose from: at this point, some "engineering" or heuristic rule is
applied to make the decisions. Subsequently, a backward loop is started, and since it is likely
that the N decisions made at the "lower" level set strict bounds to the solution space at the
level immediately above it, the procedure is rapidly driven to convergence (possibly, after
some iterative loop between some of the intermediate leve1s). Clearly, a very extensive KB is
required, a large portion of which can be obtained only by Domain Experts (Figure 4).

Figure 4: Design by Hierarchical Knowledge Elicitation

Each one of the sub-problems implies at least one call to the PDA

3. Expert Systems, Expert Assistants and Expert Advisors

ES can be constructed with several degrees of built-in logical capability ("power"):
a) Design Demons, which alert the user of constraint violations;
b) Design Assistants, which leave the final decision to the user but can suggest feasible
solutions;
c) Traditional Expert Systems, which leave the user little or no control;
d) Design Strategists, which operate on a higher logical level and may even suggest
alternative sequences of design decisions.
The distinction between one class and the other is not so crisp, and the above classification is
thus rather flexible. In general, an increasing amount ofknowledge is required from a) to d).

4. The task of "Designing a Component"

4.1. General Strategies
Designing industrial components that are meant to perform a specified function under some
pre-assigned constraints is an important type of design task with very peculiar properties of its
own. As explained above, this task essentially consists in a search of possible alternatives in a
very large solution space under multiple constraints, and proceeds by repeatedly and
iteratively finding at each step the proper links between each design specification and one or
more devices that practically accomplish that specification. In order to make the scanning of
the search space more efficient, it is convenient for the designer to specify the problem, the
components' domains and all possible connections among components in a hierarchical order.
One important step in this process is that of defining the rules that allow the correct
arrangement of the components that comply with the constraints.
A common strategy adopted for design solution is the so-called Propose-Critique- Modify
method (Chandrasekaran - Knowledge Aided Design, Academic Press)
1. Given a design goal, propose a solution. If no proposal exit
2. Verify proposal. If verified, exit with success
3. If unsuccessful, critique the proposal to identify the reason of failure. If no useful
interpretation is found, exit with failure.
4. Otherwise, modify the proposal and go to step 2
Again, notice the logical similarity with the methods usually adopted to solve inverse design
problems.
Any procedure employed to make design proposals must begin by a consultation of the
domain knowledge base to establish a mapping between the design specifications and the
possible solutions. A useful strategy is that of decomposing the problem domain: in this case
the domain knowledge is used to map subsets of design specifications into a set of smaller
design problems. Another possible strategy is that of retrieving solutions previously stored
during the solution search of similar problems. A third choice is to apply the methodologies
developed in the qualitative simulation. An expert system is often a shallow model of the
application domain, in the sense that conclusions are drawn from the observation of the data
characteristic of the process or phenomenon. These observations suggest specific solutions in
the design of applications and in the construction and validation of the descriptive portion of
the knowledge base. Qualitative causal reasoning may be used (see Sciubba, Melli): it consists
of a description (implemented through a proper set of propositional operators) of the structural
"form" not of the task per se, but of a suitable abstraction of it. The construction of such an
abstraction requires of course both a previous "modeling" activity of the physical operation of
the component and a complete identification of the various steps in the design.
All possible "future states" of the system to be designed may be predicted by a qualitative
simulation that starts from an assigned initial state and proceeds within the bounds posed by a
suitable set of properly formulated constraints. A qualitative simulation produces thus the set
of possible future states by generating and filtering the set of possible transitions from the
initial qualitative state description to the next. The filtering criteria are formulated in a list of
rules corresponding to different directions of approach. A qualitative analysis can find the
space of all the "allowable" states of the system, and reject solutions that are intrinsically
inconsistent (an allowable state is any state that: a- abides by the constraints; b- can be
reached from the initial state after a finite number of acceptable transitions; c- is not explicitly
forbidden by the rule-base). Since the method cannot guarantee though that all the allowable
solutions are feasible, it becomes necessary to insert yet another filter, to discard all
practically impossible final states.
One application of qualitative analysis in engineering design is to predict possible inconsistent
or undesired solutions and the dynamical behavior of systems under study. As stated above,
the correct formulation of the problem constraints is crucial to the consistency and for
qualitative values consistency must be formulated. The value of a quantity is qualitatively
described in terms of the congruity of its elements. For instance, the result of an assemblage
of different parts must take into account some dimensional limitations each single part must
abide by: tolerances must be met, and gaps between adjacent parts must be either zero (if so
specified) or fall in a previously defined positive interval.
In conclusion, to develop an Expert System for Component Design, a Model of the Design
Process must be defined.
The development of modern Expert Design Assistant (EDA) consists of the following steps:
- Evaluation of the goal of the engineering design process;
- Definition of the tasks that must be performed in order to achieve the goal;
- Definition of the constraints;
- Definition of the inputs and outputs;
- Selection of the process technology to be used.
The definition of these elements represents the initialization of the design process and consists
in the production of a large number of drawings organized in a hierarchical structure.
4.2. Problem Breakdown into Structural Elements
This is a sequence of design steps that generally proceed backwards, starting from the final
goal. The search in the domain space is finalized to connecting pieces of equipment with each
other by matching their respective input and output flows. A general procedure for design
process includes the following activities:
Iteration: this is the activity a designer undertakes whenever the solution is not reached in a
straightforward fashion. It is usually needed when the conditions to be satisfied are (logically
or practically) complex. The procedure begins by finding an approximate solution, and
proceeds by using the results, together with modified conditions (assumptions) to find a new,
approximate but improved (i.e, nearer to the goal) solution. Iterations stop when an acceptable
solution has been obtained ("convergence").
Concretization: This is the process that converts the conceptualization into a workable object.
Improvement: This is the process in which the designer starts with an existing solution and
improves it through successive (possibly iterative) modifications (a measure of this
improvement is needed).
In order to develop an EDA, a model of the design process must be developed through the
definition of its structure. This process will define the hierarchically ordered mutual
relationship among its building blocks starting from the basic operations. This process can be
performed cyclically by stating and reformulating the final goal, searching new solutions from
the previously derived information, and evaluating the new solution and its conformity to the
assigned constraints.

5. Selection and Design of a Feedwater Pump

5.1. The Physical Problem
The design task requires that an automatic procedure be devised for the choice and
specification of a feedwater pump. Since the extra work is really negligible, it will be
convenient to construct the procedure so that it be capable of handling any kind of pump
geometry (axial, mixed, centrifugal), and of covering the entire range of possible operation.
The following is a "task list" which can be constructed by consulting a pump design textbook
(or by asking an expert!). For the significance of the symbols denoting design parameters,
refer to Figure 5.
 Figure 5: Pump geometry (axial & radial)
- read design data: Q, H
- read constraints (if applicable): NPSH, speed, service, etc.
- is rpm given?
if Y compute ns
if N : is NPSH given?
if Y compute iteratively s and derive rpm,,
if N (assume rpm, compute NPSH, check ns),
- check if multi-staging is required
- check if multiple pumps in parallel are required
- compute ds from Cordier line
- compute D2
- choose = V2m/U2
- compute b2
- choose D2/D1e and D1i/D1e
- compute Dle and Dli
- verify torsion stress on shaft
- compute overall dimensions (approximate)
- check component library for nearest defined pump type
- check characteristics: head at Qdesign, Qmin and Qmax
- produce a technical specification sheet
5.2 Some Theoretical Considerations
This is selection prohlem, which is one of the simplest forms of a design task, and certainly
requires manipulation of both qualitative and quantitative knowledge. Since the technology of
Hydraulic Pumps is very mature, it is likely that many viable designs exist, and that the task
could actually be rephrased as "selecting one among N possible objects that possesses the
attributes specified in the problem position and covers the required field of operation". The
simplest solution strategy is that of elimination: we can define some characteristic indices that
qualify each different type of pump, compute their numerical or logical values which are
determined by the problem position, and exclude all pumps whose attribute list does not
match these values. Notice that some of these indices are qualitative ("fluid is corrosive",
"fluid is hot", etc.).
5.3 Solution
The flow chart of the engineering design choices is depicted in Figure 6. We will try to reduce
the tree to a sequel of rules of the type:
IF p THEN q
Where p is the premise (which may consist of more than one rule), and q is a series of design
activities (sub-tasks).
In this example, the decision tree (that is in reality a portion of the domain KB, and that we
shall assume here to have been gathered by means of a proper Knowledge Elicitation activity)
shows that, in addition to conditional rules of the type shown above, there are some other
steps which imply some quantitative decision, like "choose NPSHmin" "choose D1", etc.. The
easiest way to account for these steps is to treat them as functional calls to some external
numerical procedure, which will return the values of the properly addressed variables.
Keeping this in mind, a set of rules which reproduces the decision tree of Figure 6 is
the following:
rule #1): IF rpm not given
THEN call CAVIT(NPSH,s,T) AND read resulting rpm value
ELSE IF rpm constrained
THEN call CAVIT(rpm,s,T) AND verify NPSH
rule #2): IF "pump type" not assigned
THEN call PTYPE(rpm,Q,H) AND read ns and resulting pump type
ELSE IF "pump type" assigned
THEN call PTYPE(rpm,Q,H, pump_type) AND verify that ns is in an acceptable Range
rule #3): IF nstages not assigned
THEN call PSTAGE(ns,Q,H) AND read resulting nstages
rule #4): IF ns(Q,rpm,Hstage) ns old
THEN call CAVIT AND call PTYPE AND call PSTAGE AND iterate
 Figure 6: Logical tree for pump selection
rule #5): IF dimensions are not constrained
THEN call PSHAPE(Q,Hs,ns) AND read D1.D2, etc.
The remaining steps (each one of which results in the selection of a design parameter) can be
executed conditionally at the user's prompt.
As an example, the PTYPE function could be expressed by the following "truth table"
(ns=2/60*Q0.5/H0.75):
ns Pump Type
<0.2 multistage radial
<1.5 single stage radial
 <2.5 single/multi stage mixed
<6 axial
>6 multiple axial in parallel

The use of functional maps for pumps greatly facilitates the execution of the procedure.
"Maps" for the choice of the type of pump are readily available, together with tables from
which one can choose D1, D2, 1etc. as functions of ns. This is not a marginal point,

nor it is by chance that such information has been codified for us in this form: these maps and
tables represent the combined knowledge of a multitude of experts who have solved the same
problems before us, and constitute in this case a conveniently structured, ready-to-use
Knowledge Base.

6. Choice and Design of a Shell-and-Tube Heat Exchanger

6.1. The Physical Problem
The design objective is that of designing a Shell-and-Tube Heat Exchanger under the
following requirements:
a) The two streams between which the exchange takes place are known both qualitatively
(type of fluids, their approximate temperature levels, their corrosion characteristics, etc.) and
quantitatively (mass flow rates, specific heats, etc.);
b) The Design Goal is a certain temperature gain in one of the fluids ("product") at the
expense of a temperature drop of the other ("fuel). Both of these temperature differences
have been previously computed via proper mass- and energy balances;
c) The explicit Design Variable is the overall coefficient of heat transfer between the two
streams, Uth: this coefficienf depends on the relevant geometric (tube diameter, spacing,
thickness, surface finishing, configuration, etc.), physical (materials and their compatibility,
etc.) and fluid dynamic (boundary layer thickness, turbulence characteristics, etc.) design
parameters. Thus, an accurate simulation procedure must be available to compute Uth for each
different configuration.
6.2. Some Theoretical Considerations
The problem can be solved by a search in a presumably small solution space: the number of
design options is limited both by theoretical considerations (high pressure stream ought to be
on the tube side, the number of tube passes is limited by approach temperature difference
limitations, etc.) and by technological restrictions (tubes are usually circular in shape, tube
arrangement is either in-line or staggered, fins can be pre-optimized with good approximation,
use of turbulators on the inside is restricted by pressure drop considerations, etc.). In
conclusion, the possible choices are (see Figure 7):
a) stream allocation (hot stream on the tube side or on the shell side) 2 possible altematives
b) type of front head (single chamber mixed, split chamber mixed, single chamber unmixed,
split chamber unmixed) 4 possible alternatives
c) type of shell (vertical, horizontal, single pass, double pass) 4 possible alternatives
d) type of rear head (U-tube, single chamber mixed, split chamber mixed, single chamber
unmixed, split chamber unmixed) 5 possible alternatives
e) number of tube passes (1, 2, 3,.. N) N possible alternatives
f) tube arrangement (in-line or staggered) 2 possible alternatives
g) tube diameter M possible alternatives, depending on the commercially available tubes
h) tube type (unfinned, finned, turbulators inside, no turbulators inside) 4 possible
alternatives

Figure 7: The first-level branching of the decision tree for a Heat Exchanger selection
There would be other design variables, but they are in effect secondary, and can be neglected
here. Thus, the raw solution space contains (2*4*4*5*N*2*M*4) = 1280*N*M
configurations, and an extensive search would appear very cumbersome (= resource
consuming). In this case, though, there are some design constraints we can make use of:
I. The fouling-prone stream should be on the tube side
II. The fouling-prone stream should be on the shell side
III. The hazardous stream should be on the tube side
IV. If front head is mixed, so is usually the rear head; if front is unmixed, rear is also unmixed
V. The number of passes (N) in practical cases never exceeds three
VI. The tube diameter is dictated by the maximum velocity inside of the tubes, which is a
discriminating parameter and depends on the volumetric flow rate. The choice is limited, i.e.,
M ranges between 2 and 6 (i.e., at most two or three commercial diameters above or below the
recommended one)
These constraints in effect limit the number of possible configurations quite drastically:
constraints I, II and III in practice reduce the 2 possibilities given by a) to 1; constraint IV
reduces the 5 alternatives of d) to 2 (U-tube or "like the front end"); constraint V implies that
N=3 at most, and constraint VI limits M to 6. Thus, the total number of the possible choices
ranges from (1*4*4*2*1*2*1*4) = 256 (if both N=l and M=l) to (1"4*4*2*3*2*6*4) = 4608,
and an exhaustive search is feasible. Its implementation is straightforward, and follows the
usual algorithmic procedures outlined in Heat Exchanger Design Handbooks. But we are
interested here in a Knowledge Based approach, and not in brute-force extensive searches!
That is, we are after a procedure that can strongly prune the decision tree (the number of
configurations) in a non-algorithmic fashion. This can be done in many possible ways, one of
which goes as follows:
1) rank the relevant design variables in descending order of importance
2) select all the configurations which the first design variable can generate;
3) attach to each configuration a numerical figure of merit which expresses our degree of
technical appreciation or distaste for that configuration;
4) proceed to the next design variable (in logical sense, from the root to the trunks of the
decision tree), and repeat the procedure. Discard the paths which are less appealing;
5) proceed similarly to the twigs and twiglets of the tree. At the end, only few leaves on
some twiglets will remain: these are the "preferred" configurations, on which a sensitivity
analysis or a refined extensive search can be performed if necessary.
6.3. Solution
To be able to develop the complete decision tree for the choice of the heat exchanger, we have
reduced the number of possible alternatives given by the list presented in Section 6.2 above.
This by no means detracts by the generality of the proposed procedure: in practical cases,
such a "preliminary pruning" action may be executed by -or with the help of- a Domain
Expert, with the goal of strongly reducing the viable alternatives, to make the decision tree
more manageable. Our arbitrary reduced list" is then the following:
a) stream allocation (hot stream on the tube side or on the shell side) 2 possible
alternatives
b) type of front 2 possible alternatives head (either single chamber mixed or single
chamber unmixed)
c) type of shell 2 possible alternatives (single pass, double pass)
d) number of tube passes 3 possible alternatives (1 ,2, or 3 passes)
e) tube arrangement 2 possible alternatives (in-line or staggered)
f) tube diameter 3 commercially available tubes
g) tube bank aspect ratio 3 possible alternatives (ar = (tube diameter)/(tube spacing) = 0.5,
1 or 2)
We shall rank the variables in the following descending order: stream allocation, shell type,
tube passes, tube arrangement, tube diameter, tube aspect ratio, and front head. In addition,
the figure of merit will be the total (installation and operation) cost of a unit heat exchanger"
of identical type as that which represents the configuration emerging from our choices. Such a
Unit Heat Exchanger is defined as the heat exchanger that performs the heat transfer under the
same inlet- and outlet temperatures, but for a unit mass flow rate of the stream with the higher
heat capacity. This is not an absolute criterion, and it has its shortcomings, but we will assume
that the convenience of such an approach has been proven by past experience. Then, after the
first choice, the tree will look like Figure 8. Notice that the figure of merit is expressed here
in arbitrary dimensionless units and is intended exclusively as an example of the applicability
of the method. After the second variable is considered, the tree has 4 branches (Figure 8), two
of which (1 and 2) are plagued by such high values of the penalty function that they can be
discarded. The procedure is repeated at a third, fourth...seventh level, and in the end, only the
3 configurations displayed in Figure 9 are left: on these, one can perform a detailed study.
An essential point here is to select the proper penalty function and to make sure that we do not
leave out branches that would start with high penalty values and then in the end possess a low
global penalty function: the selection of the penalty function is therefore a highly specialized
action and requires Domain Expert knowledge. In case of doubt, the procedure ought to be
repeated with a slightly different penalty function formulation, to get an idea of the sensitivity
of the solution to an error in the assessment of the operating costs.

Figure 8: The second level branching of the decision tree for a Heat Exchanger
selection
(The dimensionless penalty factors are purely indicative, and reflect no real design value)
 Figure 9: An example of the complete decision tree for the selection of a Heat Exchanger
(The penalty functions are purely indicative, and reflect no real design value)

Related Chapters
Click Here To View The Related Chapters

Glossary
Cordier line: (for a pump) the locus of the optimal (i.e., highest efficiency) values in the ns/ds
plane
List of symbols
b : axial length of a pump blade
D : diameter
H : pumping head
NPSH : net positive suction head
Q : volumetric flow rate
rpm : revolutions per minute
U : heat transfer coefficient
: flow coefficient

Bibliography

Brown D.C, Chandrasekaran B.(1989): Design problem-solving: knowledge structures and control strategies
M. Kaufmann Publishers [A good book with respect to the exploitation of the activities connected to
the engineering design. The book covers, with a clear presentation, a wide range of subjects. Particularly useful
for knowledge engineers.]

Coyne R.D. (1990): Knowledge based design systems Addison Wesley [The book covers in an
extensive manner the following topics: Engineering design, Architectural design, Data processing, Computer-
aided design, Expert systems]

Green M. (ed.) (1992): Knowledge Aided Design, Academic Press, 257 p. [A collection of specific topics in
direct AI applications to design. For specialists]

E.Sciubba, R.Melli (1998): Artificial Intelligence in Thermal Systems Design: Concepts and Applications,
NOVA SCIENCE Publishers, New York. [An introductory, but complete and well written, textbook on AI topics.
A very strong biasing towards applications results in a compression of the most theoretical topics, that are always
referred to but seldom thoroughly discussed. A textbook for AI users.]

Biographical Sketch

Roberto Melli is a Researcher at the Department of Mechanical and Aeronautical Engineering of the University
of Roma 1 La Sapienza (UDR1), Roma, Italy.
He received a Masters degree in Mechanical Engineering from UDR1 in 1974. From 1974 to 75, he was a
Research Assistant at the Chair of Machines in the same university.
As a faculty member he lectures on Machinery and Energy Systems Design in Nuclear Engineering Masters
level courses.
His research activities are equally divided in two main fields:
1) Energy Systems Simulation and Design
2) Applications of AI-related techniques and procedures to the Design, Synthesis and Optimization of Energy
Systems
His publications include more than thirty journal articles (mostly on international refereed Journals in the field of
Energy). He published one book on AI applications for the types of NOVA Science, USA.
Within his 24 year diverse management experience, ranging from founder and co-owner of a process engineering
consulting firm as a consultant for AGIP S.p.A. and AGIP Petroli designed an all energy (electrical and
mechanical) system for Agip Petrolis new employee recreational facility at its new headquarters in Rome
showcasing the effective deployment and use of solar energy. Led a 2 year, 30 person project to design and
construct Chinas Rural Energy Resources Training Center in Beijing and coached/mentored Chinese
counterparts in designing, building and deploying systems to convert renewable energy into usable energy.
Produced prototypes and simulation models for training purposes and provided much needed knowledge transfer
to the Chinese Government in availability and use of various energy sources.
In the late 90s he developed an extensive experience in the application and use of expert systems for energy
management applications

To cite this chapter

Roberto Melli, (2005), ARTIFICIAL INTELLIGENCE IN COMPONENT DESIGN, in Exergy, Energy
System Analysis, and Optimization, [Ed. Christos A. Frangopoulos], in Encyclopedia of Life Support Systems
(EOLSS), Developed under the Auspices of the UNESCO, Eolss Publishers, Oxford ,UK, [http://www.eolss.net]
[Retrieved September 6, 2007]