This article was downloaded by: [Columbia University]

On: 12 December 2014, At: 01:12

Publisher: Taylor & Francis
Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,
37-41 Mortimer Street, London W1T 3JH, UK

International Journal of Production Research

Publication details, including instructions for authors and subscription information:
http://www.tandfonline.com/loi/tprs20

An artificial intelligence-based constraint network

system for concurrent engineering
a a a
ROBERT E. YOUNG , ARTHUR GREEF & PETER O'GRADY
a
Group for Intelligent Systems in Designing and Manufacturing, Department of Industrial
Engineering , North Carolina State University , Campus Box 7906, Raleigh, North Carolina,
27695-7906, USA.
Published online: 08 Jul 2010.

To cite this article: ROBERT E. YOUNG , ARTHUR GREEF & PETER O'GRADY (1992) An artificial intelligence-based
constraint network system for concurrent engineering, International Journal of Production Research, 30:7, 1715-1735, DOI:
10.1080/00207549208948116

To link to this article: http://dx.doi.org/10.1080/00207549208948116

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) contained in the
publications on our platform. However, Taylor & Francis, our agents, and our licensors make no representations
or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of the Content. Any
opinions and views expressed in this publication are the opinions and views of the authors, and are not the
views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon and should be
independently verified with primary sources of information. Taylor and Francis shall not be liable for any losses,
actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoever or howsoever
caused arising directly or indirectly in connection with, in relation to or arising out of the use of the Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematic
reproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in any
form to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://
www.tandfonline.com/page/terms-and-conditions
 INT. J. PROD. RES., 1992, VOL. 30, No.7, 1715-1735

An artificial intelligence-based constraint network system for

concurrent engineering

ROBERT E. YOUNGt, ARTHUR GREEFt and

PETER O'GRADYt

This paper presents a new approach to concurrent engineering, namely the use of
artificial intelligence constraint networks to advise the designer on improvements
that can be made to the design from the perspective of the product's life-cycle. The
difficultiesassociated with performing concurrent engineering are reviewed,and the
various approaches to concurrent engineering are discussed.The requirements for a
Downloaded by [Columbia University] at 01:12 12 December 2014

system to support concurrent engineering are indicated. An overview of constraint

networks is given and this leads into a description of SPARK, an artificial
intelligence constraint network systems for concurrent engineering. The operation
of SPARK is illustrated by considering an example application of printed wiring
board manufacture. The advantages of SPARK include being flexible enough to
allow the designer to approach a problem from a variety of viewpoints,allowing the
designer to design despite having incomplete information, and being able to handle
the wide variety of life-cycle information requirements.

1. Introduction
Concurrent engineering (sometimes called simultaneous engineering or life-cycle
engineering) involves the simultaneous consideration of product, function, design,
materials, manufacturing processes and cost, taking into account later-stage consider-
ations such as testability, serviceability, quality, reliability and redesign. In such a
manner, life-cycle factors are brought into consideration as early as possible in the life-
cycle, that is at the design stage.
This is of considerable importance to the manufacturing industry since it is at the
design stage that the life-cycle requirements are defined. After a product has passed
from the design stage it is then often too late to make significant changes to reduce life-
cycle expenditures. For example, it has been reported that upwards of 70% of a
product's manufacturing cost is dictated by design decisions (Andreasen et al. 1983,
Maddux and Jain 1986, National Science Foundation 1987). The experience of Ford
Motor Company illustrates this point: Ford estimates that although product design
constitutes 5% of total product cost, design's influence on product cost is 70% (Plastics
World, December 1988).
Although the evidence is largely anecdotal, it appears that concurrent engineering is
not generally performed well in western manufacturing industry in that design is
carried out without due regard to the various life-cycle factors. This can result in
designs that are expensive to manufacture, test, service, maintain and redesign.
This paper presents a new approach to concurrent engineering, namely the use of
artificial intelligence constraint networks to advise the designer on improvements that

Received March 1991.

t Group for Intelligent Systems in Designing and Manufacturing, Department of Industrial'
Engineering, Campus Box 7906, North Carolina State University, Raleigh, North Carolina
27695-7906, USA.
002()-7543/92 sioe © 1992 Taylor & Francis Ltd.
 1716 R. E. Young et al.

can be made to the design from the perspective of the product's life-cycle.The format of
the paper is as follows: the difficulties associated with performing concurrent
engineering are reviewed, the various approaches to concurrent engineering are
discussed and the requirements for a system to support concurrent engineering are
indicated. An overview of constraint networks is given and this leads into a description
of SPARK, an artificial intelligence constraint network system for concurrent
engineering. The operation of SPARK is illustrated by considering an example printed
wiring board (PWB) application.

2. Difficulties associated with performing concurrent engineering

The fact that concurrent engineering is not performed well is due primarily to three
main sources of difficulty: the characteristics of the design process, the volume. and
variety of life-cycle knowledge, and the separation of life-cycle functions (Evans 1988,
Downloaded by [Columbia University] at 01:12 12 December 2014

Ruizand Koenigsberger 1970, Harfmann 1987,Baxter 1984, Peck 1973, Runciman and
Swift 1985).
2.1. Characteristics of the design process
Design is thought to involve the separation of the design problem into stages. These
stages are conceptual design, detailed design, and analysis and evaluation. It is also
thought that designers divide up each stage into a number of subproblems. Design is
then carried out by iteratively solving each subproblem until the overall design is
thought to be adequate. H problems occur then the designer backtracks to alter the
solutions to individual subproblems. It is this division into stages and the further
division into subproblems that is the first source of difficulty in achieving integrated
concurrent engineering in that this division of the design problem can result in 'sub-
optimization' where the designer concentrates on narrow issues while ignoring the
overall concurrent engineering problem (Chieng and Hoeltzel1986, 1987, Rosen et al.
1986).
2.2. Volume and variety of life-cycle knowledge
The second source of difficulty in achieving integrated concurrent engineering is the
volume and variety of the knowledge required to consider life-cycle factors. The
knowledge required is voluminous since it will include design, manufacturing,
manufacturing control, testing, servicing and redesign. Furthermore the required
knowledge will have a large degree of variety, including both quantitative and
qualitative knowledge. The problem is compounded in that much of the life-cycle
knowledge is interrelated. This large volume and variety oflife-cycle knowledge results
in designers developing their knowledge in relatively narrow functional domains while
ignoring the rest of the life-cycle knowledge (Swift and Doyle 1988, Kalay 1987, Kroll
. et al. 1988, Bishop 1986, Dieter 1983, Eversheim and Muller 1984, Murthy and
Addanki 1988, Medland 1986).

2.3. Separation of life-cycle functions

The third source of difficulty associated with concurrent engineering is that
different life-cycle functions (such as design, process planning, manufacturing, testing,
and servicing) are often separated by being the responsibility of different departments
in an organization. The difficulty of communication within such an organization will
mean that knowledge about life-cycle factors is only infrequently passed back to the
designer (Medland 1986,Dieter 1983, Maddus and Jain 1986,Oakley 1984,Chieng and
Hoeltzel 1986, 1987). .
 Al constraint network for concurrent engineering 1717 '

The overall result of these three major sources of difficulties is that designers
frequently defer considering life-cycle requirements until late in the design process
(Gairola 1986), or abdicate responsibility to the relevant life-cycle function within the
company (Evans 1988, Riley 1983).

3. A pproaches to concurrent engineering

There are a number oftechniques and systems that support concurrent engineering
by advising designers on aspects that reduce life-cycle problems (Jakiela et al. 1984).
These include the use of design teams, design handbooks, checklists and structured,
procedures, manufacturing simulation and process planning, and the use of expert
systems.

3.1. Design teams

Downloaded by [Columbia University] at 01:12 12 December 2014

One way of integrating design and life cycle is by the use of design teams. This
approach requires early and frequent interaction between design and the other life-
cycle functions. It has traditionally been accomplished with post-design reviews which
are usually considered to be less effective than reviewing the design while it is being
developed (Heller 1971). A better approach is to have team members actually design the
product and process together (Maddux and Jain 1986,Evans 1988). Group approaches
do provide alternate perspectives to the design problem, and the group approaches can
also be useful for initial idea generation. However, group decision making (for creative
tasks, in particular) is difficult (Harfmann 1987). The operation of design teams would
be further improved by the use of suitable techniques and systems that advise on good
designs from the life-cycle perspective.

3.2. Handbooks
The most conventional approach to advising on design is to provide compiled life-
cycle experience in handbooks, standards, and design guides. The designer is then
responsible for considering and integrating this documented information into design
decisions (Bralla 1986,Trucks 1987, Stein and Strasser 1986). However, this approach
has not been entirely satisfactory since the designers still have to cope with the high
volume, variety and interdependence associated with life-cycle knowledge.

3.3. Checklists and procedures

Post-design review checklists and procedures are available for some aspects of life-
cycle design, notably manufacturing. The designer typically classifies the design and
obtains guidelines for that class of design feature or problem (Eversheim and Muller
1984, Heller 1971, Oakley 1984, Redford et al. 1981, Boothroyd et al. 1981, Redford
1986,Boothroyd and Dewhurst 1988). The main advantage of classification tables and
checklists are that they are relatively easy to construct and can be used in a
straightforward manner. However, these approaches tend to depend on accurate cost
information. This is considered by some to be a major weakness (Kroll et al. 1988)since
accurate cost information is often difficult to obtain (Heller 1971). Others would
suggest that the biggest danger in using this type of evaluation is that it will be
approached in a mechanical way and the results will be viewed with greater accuracy
than they actually merit (Oakley 1984). Haeusler (1981) points out that structured
procedures can conceal the danger of suboptimization. A further potential problem is
that the rigid structuring may also be unrealistic (Kroll et al. 1988, Dieter 1983, Lu
1986, Gross et al. 1987, Rosen et al. 1986, Heller 1971).
 1718 R. E. Young et al.

3.4. Process planning and manufacturing simulation

The use of process planning and manufacturing simulation systems (such as NC
tool cutting graphics systems) to aid the designer in considering the life-cycle aspect of
manufacturing has been proposed by several researchers (Maddux and Jain 1986).
Such approaches suffer from the disadvantage that they tend to concentrate only on
process operations and provide only indirect feedback to the designer on potential
problems.
,
3.5. Rule-based expert systems
There are relatively fewcomputerized systems that support concurrent engineering.
Those that do exist are mainly rule-based expert systems (Chao 1985, Sevenler et al.
1986). Work on design for assembly has produced several rule-based systems, including
(Oh and O'Grady 1990):
Downloaded by [Columbia University] at 01:12 12 December 2014

• A systematic approach to design for assembly from Lucas Engineering &

Systems Ltd (Assembly Automation, August 1989). This provides sequential
iterative analysis of function, feeding, gripping, insertion, assessment and gives
out cost-related indices. It has a similar aim to that of the Boothroyd and
Dewhurst (1988) system in that it strives for reductions in the number of
components. A single system is used for both robotic and automatic assembly.
• ADAM (assisted design for assembly and manufacture) provides verbal advice
and parts list on minimizing parts, rationalization, and insertion guidelines
(Sackett and Holbrook 1988).
• DACON (design for assembly consultation) attempts a CAD interface. It
provides redrawing of parts as output from an analysis of the design by an expert
system (Swift 1987).
• PACIES (a part code identification expert system) (Chen and Young 1988)
generates three digit U-Mass part codes based on the shape, important features
and symmetries of the part. The system is implemented under DOS using the
micro-PROLOG programming language, and consists of a rule set containing
163 rules.
• Bao (1988) develops a prototype expert system for the DFA or surface mounted
printed circuit boards.
The advantages of rule-based systems are that they are relatively simple. There are,
however, several disadvantages of rule-based systems. Most are applicable to a very
small application area and have problems in being expanded to handle a wider
application area. They are unable to allow designers to approach the design problem
from whatever perspective is appropriate given the information available at a
particular stage of the design process. Furthermore, a prime requirement of supporting
concurrent engineering is the ability to respresent the mutually constraining influences
that different aspects of a product's life-cycle exert on each other. This requirement is
not easily achieved using rule-based systems.

4. Requirements for a system to support concurrent engineering

The previous section has reviewed the present approaches to concurrent engineer-
ing. It can be seen that the work done thus far on supporting concurrent engineering is
limited. As has been indicated, design teams that possess the requisite life-cycle
information can produce good results. However, it is becoming increasingly clear that
design teams not only can be difficult to manage but that they can be expensive to
 AI constraint network for concurrent engineering 1719

operate, especially for the medium/small volume producer. There are also difficulties
associated with ensuring that team members have the necessary up-to-date expertise.
As an alternative to design teams, we therefore propose the use of a computerized
support tool to bring up-to-date life-cycle information to the designer in a readily
usable form. This support tool will, in effect, emulate a good design team by suggesting
changes that will improve the design from the life-cycle perspective. The requirements
for such a support tool are rigorous and encompass a number of substantial research
issues.
Designers can typically undertake the design process by a number of routes
depending on such factors as the information available and the application. Personal
preference also plays a part. The support tool should therefore be flexible enough to
allow the design problem to be approached from a variety of viewpoints.
Design may also have to be initiated in the absence of complete information. Indeed
Downloaded by [Columbia University] at 01:12 12 December 2014

it may be well into the final design stages ..before full information is available. The
support tool should therefore allow the designer to design in the absence of complete
information.
When it is considered that concurrent engineering includes design, manufacturing,
testing and redesign, then it can be readily seen that the information requirements are
immense. The support tool should therefore be capable of handling this large volume
and variety of information.
The information may come from a variety of sources including the user, domain
experts, CAD and database management systems. The support tool should therefore
have a good user interface and readily link to CAD and database management systems.
It should also be able to explain itself in a manner comprehensible to humans.
As a product goes through its life-cycle, it may have to be redesigned. If the
information is kept as to why design decisions were made, then this can significantly
improve the redesign process. A further requirement for the concurrent engineering
support tool is therefore that it should support such design audits.
Overall, therefore, the following are the principal requirements of a computerized
system to support concurrent engineering (Bowen and O'Grady 1989):
• it should be flexibleenough to allow the design problem to be approached from a
variety of viewpoints;
• it should allow the designer to design despite the absence of complete
information;
• it should handle the large volume, variety, and interdependence of life-cycle
information;
• it should readily interface to database management and CAD systems;
• it should have a good user interface and be able to explain itself in a manner
comprehensible to humans;
• it should support design audits.

5. Constraint networks
It is widely accepted that design activities can be regarded as involving search to
satisfy constraints (Gross et at. 1987, Wu 1988). This model of design has been applied
to a wide variety of design domains including electrical circuits (Tong 1987),
mechanical design (Ishii et at. 1988) and VLSI design (Wu 1988).
A constraint network is a collection or constraints which are interconnected by ,
virtue ofsharing variables. An example is shown in Fig. 1.The variables (ovals in Fig. 1) ,
 ....,
~
Downloaded by [Columbia University] at 01:12 12 December 2014

Minimum ca.lallatedbolediameter
• nomiDa.I lead diameter + :z • platinl thicmc:ss
+ oYe1Sizc of insenionbole y
hoIe"",,"_
il 4 onJyif pLlting thickness. 0 ~

::0;,

unsupponed
C§0f~)hoIe_ c::
1 0.6' s:
....ppomd 2 O.so
unsupponed 3 <E
r
0.33
uQ$Upponed
uasvppol1ec1
•s 0.25
0.10
~
placed lima 1 0.33 ~
pla1ed -lima 2 0.33 Determine numberof
pllted-lima 3 0.25 existing holesacs from
plated=tlma • tbe Iis1 of existing bole

0
0.10
pla~ed}hru j 0.10 ,;",
mk U the drillsize: for
';;
hole is in the lisr: of
standard drillsizes
then put it in the
Minimum ltd bolediameter
• < drill me for bole list of C<isting hoi. ~
sizes for the PWB

Figure I. An example constraint network for selecting component lead hole sizes for printed wiring boards.
 A I constraint network for concurrent engineering 1721

link the constraints (rectangles in Fig. I). The network contains the constraints that
must be considered in determining a hole diameter in a printed wiring board. This
example will be discussed in more detail later in this paper.
The problem of selecting and testing the values of the variables can be done by a
combination of computers and humans. If done by computer then it is termed
constraint satisfaction (Fikes 1970). Constraint satisfaction is analogous to automatic
design in concurrent engineering and carries crippling disadvantages: the computation
involved can prove to be impractical and there can be severe problems in ensuring that
all relevant information is included. At the other extreme, full human selection and
testing of variable values can, because ofthe time and effort involved for even relatively
small constraint networks, also be impractical.
If however the selection and testing of variable values is carried out by a
combination of humans and computer then it becomes a practical proposition for
Downloaded by [Columbia University] at 01:12 12 December 2014

application to concurrent engineering. This human/computer combination is termed

constraint monitoring. Such a constraint monitoring approach used in a design advice
system has the potential for computational efficiency when compared with constraint
satisfaction/automatic design approaches.
There are several constraint-based languages including Sketchpad (Sutherland
1963), ThingLab (Borning 1979), IDEAL (Van Wyk 1981), CONSTRAINTS (Sussman
and Steele 1980) and TK!Solver (Konopasek and Jayaraman 1984). All these
constraint-based languages have disadvantages when considered for a design advice
system for concurrent engineering. The primary disadvantage is that they were mostly
developed for fairly narrow application areas and they are therefore not suitable for
application to the side domain of concurrent engineering. The development of a viable
constraint network language is therefore a crucial step in developing an effective
concurrent engineering system. The recognition of this has Jed to the development of
SPARK which is a successor to CADEMA (O'Grady et al. 1988).

6. SPARK: a constraint network programming language

SPARK is a constraint network programming language with frame-based in-
heritance based upon an implementation of first-order predicate logic. This allows
users to model concurrent engineering systems as constraint networks, e.g. a collection
of constraints that are interconnected through shared variables. The constraints, their
shared variables, and their interconnections, can be represented graphically as a
network. Figure I is an example constraint network for hole specification on printed
wiring boards. The objective of a SPARK program is to find a set of variable values that
does not violate any of the constraints. Values are propagated bi-directionally among
constraints through the shared variables. The values are determined automatically by
the system, when possible, or are input by the user. Consequently, within a SPARK-
based constraint network, the user is utilized a priori as part of the inference
mechanism.
Since a SPARK session is an interaction between the user and the system, and
because a constraint network uses bi-directional propagation, there is no specified
starting point nor a chronologically imposed solution sequence. This differs from rule-
based expert systems that impose a specificstarting point and a chronological solution
sequence (Greef and Young 1990). This offers advantages to both experienced and
inexperienced users. Inexperienced users can begin at a suggested starting point and be
guided to a solution in a manner analogous to a rule-based expert system. Experienced
 1722 R. E. Young et aI.

users can initiate a solution at whatever place their experience suggests is the most
appropriate. This allows users to use a SPARK-based constraint network in a manner
consistent with their own personal problem-solving approach. Thus, in the example
shown, an inexperienced user may be instructed to start at a specific node and proceed
through the network in a prescribed manner; whereas an experienced user would start
at whatever node seemed the most appropriate for the problem at hand.

6.1. The SPARK system

Figure 2 shows the SPARK system architecture. It consists of a full-screen editor
with Wordstar-like editing commands. A program is created either as a text file and
loaded into the editor, or created from within the editor. A function key initiates the
scanner/parser. The SPARK program is scanned for syntax errors and then parsed into
an internal representation. If a syntax error is found by the scanner, the cursor is placed
Downloaded by [Columbia University] at 01:12 12 December 2014

at the location of the error and an error message is presented to the user. Once the
program is successfully scanned and parsed, an initial constraint propagation is made
by the inference engine and the results are displayed on the program interface.
The inference engine is a theorem prover that tries to find values for variables in the
constraints that will make the constraints true. The inference engine uses a three-valued
logic so that a constraint can be either true, false or undetermined. If values are
unknown for any variable in a constraint, then the constraint is logically undetermined
and the inference engine will attempt to find values through local propagation. If it is
not successful then it returns control to the user and the user must assign values. If it is
successful in finding the missing values then the inference determines whether the
constraint is logically true or false. A logically true constraint is a satisfied constraint
and a logically false constraint is a constraint violation. When a constraint is violated
the violation detection system traces the possible sources of the violation and displays
them to the user. Correcting a violation usually involves changing the value of a
variable.
When a variable's value is changed the truth maintenance system retracts the value
from the variable and traces through all the dependency links to retract the other

••
+ ..
•+ ++
•+
Figure 2. SPARK system architecture.
 AI constraint network for concurrent engineering 1723

variable's values and the constraint's truth values that are dependent upon them. The
system then performs a constraint propagation and the variable values are redeter-
mined and constraints re-evaluated. This may result in the constraint being satisfied, its
still being violated, or another constraint being violated. When all variables have been
assigned values and all constraints are satisfied, then a solution to the problem has been
found.
The program interface supports the user in finding a set of variable values that
satisfy the constraints through its spreadsheet-like representation and its mouse-driven
interaction with the user. Using the mouse, variables and constraints are selected for
detailed examination and for assigning values to variables. When a value is assigned to
a variable it is automatically propagated throughout the network by the inference
engine. Constraint propagation is shown on the screen as it occurs. Variables with
assigned values appear as a different colour to those without values. Satisfied
Downloaded by [Columbia University] at 01:12 12 December 2014

constraints also appear as a different colour to constraints that are indeterminate.

Violated constraints flash and the system displays information describing the
constraints violated and the source of the violation. When a solution has been found,
the variables and constraints are all the correct colour and no constraints are flashing.
A simple escape sequence returns the user to the full-screen editor.

7. An example: design or printed wiring boards (PWBs)

In this next section we present an example that successfully demonstrates the
concurrent engineering objective to simultaneously consider the functional design
requirements and the manufacturing requirements. The example illustrates how
constraint networks can support correct functional design while helping the designer
design a product that manufacturing can produce with existing capability and with
reduced machine setups. Figures 3 (a}-(c) show a SPARK program for the constraint
network of Fig. 1. It supports the specification of hole sizes for component leads on a
printed wiring board (PWB). A PWB contains many holes, sized for the leads that will
attach components to the board and to connect different conducting planes within a
multi-layered circuit board. Hole size is determined by the board thickness, the need to
accommodate the size and shape of the component lead, whether copper plating is
needed to connect different conducting planes within a multi-layered board, and the
need to physically and electrically connect the component lead to the PWB with solder.
If the hole is too small, then after plating, a lead may not fit into it. If it does fit and there
is insufficient oversize, then solder cannot wick into the hole. If the hole is too large,
then solder will not wick into it. Poor solder wicking results in poor solder joints and is
a source of mechanical and electrical failure.
From a manufacturing perspective, hole specification should be constrained by
manufacturing capability and cost. Although there is potentially an infinite number of
hole sizes,all production facilities have a finite set of drill sizes.The drills are held in the
tool inventory. To avoid adding tool sizes to the tool inventory, a hole size should be
selected that can be drilled by an existing tool. If the hole size variation on a board
exceeds the magazine size for the drilling machine, then additional machine setups are
required. If wecan keep the hole size variation within the maximum drill magazine size,
then we can manufacture the PWB with a single setup and avoid increased production
time and cost. Consequently, the example successfully demonstrates the concurrent
engineering objective to simultaneously meet the functional design requirements and
the manufacturing requirements. .
 1724 R. E. Young et al.

1 DOMAINS r Domain Declarations */

2 hole_type = {unsupported, plated_thru}.
3 class_type = {I, 2, 3, 4, 5}.
4 factor_type = {0.67, 0.50, 0.33, 0.25, 0.20}.
Downloaded by [Columbia University] at 01:12 12 December 2014

5 std_ovr_type = {0.020, 0.028}.

6 STRUCrtJRES r Frame-based Inheritance Structure Declarations */

7 plating_spec [
7a 'plating thickness' (plate), [0,0),
7b 'solder plating thickness' (solder), [1,0) (0.0005),
70 'copper plating thickness' (copper), [2,0] (0.001) : number].

8 hole_spec [
8a 'nominal lead diameter' (lead_di), [0,0] (0.02),
8b 'minimum calculated hole diameter' (calc_di), [1,0],
80 'minimum standard hole diameter' (min_dia), [2,0],
84 'maximum standard hole diameter' (max_dia), [3,0] : number].

9 unplated_hole [
9a 'hole type' (holetyp) [0,0] (plated_thru) : hole_type,
9b 'standard oversize' (std_ovr) [1,0] : std_ovr_type,
90 'drill size for lead hole' (drill), [2,0],
94 'oversize of insertion hole' (oversiz) [3,0] : number,
ge r inherited structure */ hole data [4,0) : hole_spec].

10 general_hole [
lOa r inherited structure 0/ basic_hole [0,0) : unplated_hole,
lOb r inherited structure */ plating_data [8,0] : plating_spec].

Figure 3. (a) A SPARK program for hole specification in a printed wiring board: domain and
frame-based inheritance structure declarations.
 Al constraint network for concurrent engineering 1725

11 VARIABLES /* Variable Declarations */

12 holel r Ist plated hole instance */ [4,4] : general_hole.

Downloaded by [Columbia University] at 01:12 12 December 2014

13 'size of the drill magazine' (mag_siz) [6,0] (3),

14 'board thickness' (board) [7,0],
15 'number of existing hole sizes' (no_hole) [8,0] : number.

16 'list of standard drill sizes' (std_drl) [9,0],

17 'list of existing hole sizes' (holelst) [10,0] : set of number.

18 'fractional factor' (factor) [11,0]: factor_type.

19 'PWB class' (class) [12,0] : classtype,

/*** labels for column headings *** /

20a "(variabl) [0,0],

20b "(constra) [0,2],
20e " (holes) [0,6],
204 "(hole_l) [1,4],
20e " (hole_2) [1,5],
20f "(hole_3) [1,6],
20q " (hole_4) [1,7],
20h " (hole_5) [l,8],
201 "(xxxxxxx) [2,0]," (xxxxxxx) [2,1]," (xxxxxxx) [2,2],
20j " (xxxxxxx) [2,3], " (xxxxxxx) [2,4]," (xxxxxxx) [2,5],
20k "(xxxxxxx) [2,6], "(xxxxxxx) [2,7]," (xxxxxxx) [2,8] : label.

Figure 3. (b) A SPARK program for hole specification in a printed wiring board: variable
declarations.
 1726 R. E. Young et at.

21 RELATIONS r Relation Declarations • /

22 compatible(hole_type, classtype, factor_type) =

{(unsupported, I, 0.67), (unsupported, 2, 0.50),
(unsupported, 3, 0.33), (unsupported, 4, 0.25),
(unsupported,S, 0.20), (plated_thru, I, 0.33),
Downloaded by [Columbia University] at 01:12 12 December 2014

(plated_thru, 2, 0.33), (plated _thru, 3, 0.25),

(plated_thru, 4, 0.20), (plated_thru, 5, 0.20) }.

23 CONSTRAINTS r Constraint statements • /

24 1 [3,2] no_hole = card(holelst).

25 2 [4,2] no_hole = < mag_siz.
26 All (general_hole(X»
26a [
26b 3 [5,2] X.min dia = factor" board.
260 4 [6,2] X.calc_di = X.lead_di + 2·X.plate + X.oversiz.
264 5 [7,2] X.plate = X.copper + X.solder.
268 6 [8,2] X.max dia = X.lead di + X.std ovr.
26f 7
- - -
[9,2] X.plate = 0 < = > X.holetyp = unsupported.
26q 8 [10,2] X.holetyp = unsupported ==> X.std_ovr = 0.020.
26h 9 [11,2] X.holetyp = plated_thru = => X.std_ovr = 0.028.
26i 10 [12,2] compatible(X.holetyp, class, factor).
26j 11 [13,2] X.drill > = X.min dia.
26k 12 [14,2] X.drill =< X.max dia.
261 13 [15,2] X.drill > = X.calc di.
26m 14 [16,2] X.drill element of std drl ==> X.drill - > holelst. ]
- -
27 15 [17,2] std_drl = {0.024,0.031, 0.043, 0.045, 0.052, 0.055, 0.063}.

Figure 3. (c) A SPARK program for hole specification in a printed wiring board: relation
declarations and constraint statements.
 AI constraint network for concurrent engineering 1727

7.1. SPARK program

A SPARK program consists of definitions and declarations. Each program must
contain variable and constraint declarations. A program may also contain domain
definitions, structure definitions, and relation definitions. Figures 3 (a)-{c) contain the
SPARK program for the network shown in Fig. 1. The bold numbers on the left in the
figure are not part of the program and are included to assist in discussing the example.
The declarations and definitions are grouped together under identifying headings as
shown in lines 1, 6, 11, 21 and 23.

7.1.1. Domain declarations

Domain declarations allow the possible values for variables to be restricted to a
programmer-defined set. When a variable has been restricted to a specific domain, the
Downloaded by [Columbia University] at 01:12 12 December 2014

SPARK system will not allow the user to assign it a value outside the programmer-
defined domain. Definitions defining domains for some of the SPARK variables are
shown in lines 2 to 5. Diverse domains are possible in SPARK. The syntax for a
programmer defined domain declaration is:
domain name = {list of possible values}.

7.1.2. Variable declarations

The variable declarations identify variables that are used in constraints. A
variable's properties are defined within its declaration. These include its domain,
whether it is a structure or not, whether it belongs to a structure or not, its description
and name, and where it will be located within the spreadsheet-like interface. SPARK
uses a two dimensional spreadsheet-like user interface to display the variables, any
structures, and the constraints. The syntax for variable declarations is as follows:
'variable name' (pseudonym) [location] (default value): domain declaration.
Default values are optional.
As an example, in Fig. 3 (b), line 15 contains the declaration for the variable Dojlole.
nohele has a descriptive name of 'number of existing hole sizes', a pseudonym of
no.hole located in position [6,0] on the spreadsheet-like interface, no default value,
and uses the domain of real numbers, Since the variables in lines 13-15 all have the
domain of real numbers, they are grouped together and use a common domain
declaration, ':number' (in line 15),specifying the real number domain. Other variables
have explicitly defined domains grouped together under domain declarations. As an
example, variable class in line 19 of Fig. 3 (b) has the domain class_type. This domain is
defined in line 3 as the set {l, 2, 3, 4, 5}. SPARK will not allow a value to be assigned to
class that is not within this domain. Consequently, domains are a means of constraining
variables to a finite set of possibilities.

7.1.3. Frame-based inheritance structures

Frame-based inheritance allows us to represent the set of all holes in the PWB by
capturing the notion of a hole. Using inheritance structures we group together the
general properties that define a hole. We then create instances of this general definition
and tailor each instance to define a specific hole. The 'tailoring' is accomplished by ,
 1728 R. E. Young et al.

satisfying the constraints. The use of inheritance structures in constraint statements is

discussed in section 7.1.5. The syntax for an inheritance structure declaration is:
inheritance structure [x" ... ,xr ]
where Xl> k = I, ... , r are either variables, Vi> or are other inheritance structures, isj , that
are incorporated into the definition; Vi> i = I, ... , n are variable declarations whose
syntax is defined in section 7.1.1; isp j= I, ... ,m define other structures from which
properties are inherited and have the syntax:
structure instance name [location]: referenced inheritance structure name
Figure 3 (a) contains an example of a complex inheritance structure. In the figure there
are four interrelated structures, plating..spec (line 7), hole...,spec (line 8), unplated.hole
(line 9), and generaLhole (line 10). Figure 4 shows the relationships among the
Downloaded by [Columbia University] at 01:12 12 December 2014

structures.
Inheritance allows us to organize properties into groups and subsequently
incorporate the groups into other structures. A frame consists of a structure name, such
as plating..spec in line 7 of Fig. 3 (a), and a variable name for each property, such as
those in lines 7a-7c. Variables may also be references to other structures as shown in
lines ge, and lines 1Oaand lOb.The variable name to structure name linkage creates the
inheritance reference. As inheritance implies, the properties and default values in an
inherited structure are automatically available to the structure in which they are
incorporated.
In the example program we grouped the plating thickness properties together
under the structure plating..spec and the hole diameter properties under the structure
hole...,spec. To specify an unsupported hole (i.e. a hole that is not plated through), we
created the structure unplatelLhole with the properties of hole type, standard hole
oversize, drill size for the lead hole, and the oversize of insertion hole. These properties
are defined by giving values to the variables holetyp, std_ovr, drill, and oversiz (lines
9a-d). Since hole diameter properties are also needed to complete the specification of
an unsupported hole, they are included by specifying a structure instance hole_data
(line ge) of the structure hole...,spec. This allows the structure unplated_hole to inherit all
the properties of the structure hole...,spec.

platiog_spec
\
unplated_hole
generalproperties of objects
grouped usinginheritance
structures

~/ general , hole

1 specificinstances of objects
created inter~ctiv:Jy. ~ the
} userthrough instantiation

Figure 4. Inheritance structure for the printed wiring board example.

 AI constraint network for concurrent engineering 1729

A general hole contains all the properties of an unplated hole and also contains the
plating specifications. The structure generaLbole is constructed by grouping the
unplated hole properties together with the plating specification properties by
combining a structure instance basic.hole ofthe unplated.hole structure (line lOa)with
a structure instance plating....data of the plating....spec structure (line lOb). Thus, the
structure general.hole inherits all properties from an unplated hole and inherits the
properties needed to specify the plating thickness.
Frame-based inheritance allow us to group properties together in a common
structure, and then define more complex groups of properties by combining structures
into super-structures. The super-structures inherit properties from the combined
structures. The structures and super-structures define general properties for general
objects. When we need to describe a specific object, such as a specific hole in a circuit
board, we create an instance of the general object and assign it a unique name. The
Downloaded by [Columbia University] at 01:12 12 December 2014

name acts as a unique identifier for each instance. To denote a specific object's
properties we assign values to the variables for each instance. In the example, we would
denote a specific hole's properties by assigning values to the variables for each hole we
instantiated. In Fig. 3 (b), line 12 creates the first instance of a specific hole. Other
instances of holes are created dynamically at the user interface by the user as they work
through all the holes on a PWB. Consequently, the example in Fig. 3 is a generic
program that can be used to determine hole specifications for a PWB with any number
of holes.
Figure 5 is an example of a user introduced instantiation. It is a screen image from
the spreadsheet-like interface. It shows variables (column 0), the constraints Cl
through Cl5 (column 2), and the first instantiation ofa hole (column 4). Let us suppose
that the user wants to describe the characteristics of a second hole in a PWB. The user
would type inst bole2 [4,5]: generaLhole on the command line as shown. When
executed, the command results in a second instantiation of a hole placed in column 5 as
shown in Fig. 6. Continuing in this way, a user would work through a PWB
instantiating a hole in the program for each hole in the PWB. Also shown in Figs 5 and
6 are screen labels. The SPARK language includes a screen labelling capability. Lines
20a through 20k in Fig. 3 (b) created the labels shown in the figures. .
F = = = = = = = = = = = spark User Interface ===========,
o 1 2 3 4 5 6 7 8
o variabl constra holes
1 hole_l hole_2 hole_3 hole_4 hole_5
2 xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx
3 "Cl"
4 "C2" holetyp
5 "C3<1 std ovr
6 mag_Biz "C4" drill
7 board "CS .. oversiz
8 no hole "C6 4 lead di
9 std drl "C7" calc-di
10 holelst "CO" min dia
11 factor "Cg4 max-dia
12 class "CIO" plate
13 "CII· solder
14 "C12" copper
15 ..elJ ..
16 "C14"
17 ..CIS ..
18
g>inst hole2 [4,5] : general_hole.
SPARK Ver 1.0 copyright (C) 1990 NCSU Industrial Engineering Department
Enter command. <CR> to process. <ESC> to cancel.

Figure 5. Screen printout of the SPARK spreadsheet-like interface for the example with
instantiation command for hole 2 entered on the command line.
 1730 R. E. Young et al.

7.1.4. Relation declarations

Relations are a means of representing and indexing among tabular information. A
relation is defined in Fig. 3 (c), line 22 for the tabular constraints shown in Fig. 1. A
relation has the following syntax:
relation name (domain I, ... ,domainn)
= {(Vil>"" Vi n),··· ,(Vii"'" Vin), · · · ,(Vmi,···, vmn)}

where there are i= I, ... ,m rows and j= I, ... ,n columns of values, Vij' in the table.
If n- I values are assigned to n variables in a relation, the missing variable value will
be determined by the inference engine by searching the table.

7.1.5. Universal quantification of inheritance structures

Although frame-based inheritance allows us to differentiate among different objects
Downloaded by [Columbia University] at 01:12 12 December 2014

which have the same general properties, it says nothing about how we should apply
constraints to the instances that define specific objects. To specify how constraints are
to be applied to instantiated objects we have included universal quantification for
structures. This is similar to universal quantification for predicate calculus except that
it is restricted to structures. The syntax for universally quantifying inheritance
structures is:
All (is.(X), ... , isn(X)) [CSI>"" csm ]
where is" i = I, ... , n are the inheritance structures to be quantified, and cSj ' j = I, ... , m
are the constraints within the quantified structure. The syntax for constraints is defined
in section 7.1.6. A constraint, CSj, can contain variables applicable to all objects and
variables applicable to instances of an object. Variables applicable to instances of an
object are preceded by a capital letter, such as X, and a period.
In the example, to differentiate between values applicable to all holes and values
uniquely applicable to a specific instance of a hole we quantified the structure
generaLhole as shown in line 26 of Fig. 3 (c) in which All (generaLhole(X)) appears.
Line 26 specifies that the set of values for each instance of a hole is propogated through
the constraints enclosed within the left and right square brackets. The variables
preceded by an X. appear within the super-structure generaLhole. As a new value is
assigned to a variable within an instance of a hole all the variables within the instance's
structure are propagated through the constraints. In this way, the constraint network
of Fig. 1 is applied to each instance of a hole for the PWB.

7.1.6. Constraint declarations

Constraints are declared in lines 24 through 27. The syntax for a constraint is:
constraint number [location] constraint
The numbers in square brackets define the position on the spreadsheet-like interface
where the constraint will be located. The constraint number identifies the constraint in
the interface display. For example, in Fig. 3(c), line 25 shows constraint number 2
restricting the number of selected hole sizes to be less than or equal to the size of the drill
magazine. The constraint is located in row 4 of column 2 in Figs 4 and 5, and is
identified by C2. All constraints in the spreadsheet-like interface are identified by their
constraint number preceded by a 'C'. Thus, in Figs 4 and 5 all fifteen constraints are
located in column 2.
 AI constraint network for concurrent engineering 1731

Constraints are defined using logical operators. Constraints in Fig. 3 (c) contain
both atomic and logic constraints. Examples of atomic constraints with equality ( =)
and with inequality (= <) are shown in lines 24 through 25. Examples of atomic
constraints with the set operators, inclusion testing (elemenLof) and element insertion
(- > ), are shown in line 26m. Another set operator, cardinality (card), is shown in line
24. Logic constraints are composed from atomic constraints using negation (the 'not'
operator), conjunction (the 'and' operator, &), disjunction (the 'or' operator, #), logical
implication (the 'implies' operator, = = > ), and logical equivalence (the 'equivalence'
operator, < = ». Conjunction, disjunction and negation are not included in this
example; however, an example or logical equivalence ( < = > ) is shown in line 2M.
Conditional constraints using implication (= = > ) are shown in lines 26g, 26h and in
line 26m. In a conditional constraint, the antecedent (i.e. X.holetyp = plated_thru in line
26h) acts as a guard expression for the consequent (X.stovr = 0.028). The consequent is
Downloaded by [Columbia University] at 01:12 12 December 2014

asserted only when the antecedent is satisfied.

The size of the drill magazine, magsiz is specified as a default value in line 13, and
the list of standard drill sizes, std_drl, is specified as a constraint in line 27. Although we
have explicitly specified this information in the example, in actuality this information
would be retrieved from a database as the program executed.

8. Operation of SPARK
To illustrate the operation of SPARK, let us assume the designer has instantiated a
new hole, say hole four, and now proceeds to determine a drill for it. Let us also assume
that the following values for variables in hole4's structure have been set:
hole type (holetyp) plated_thru
solder plating thickness (solder) 0·0005
copper plating thickness (copper) 0·001
maximum standard hole diameter (max_dia) 0·048
mimimum standard hole diameter (min_dia) 0'025
In addition, let us assume that as a result of specifying variable values for previous
holes, the list of existing holes is:
list of existing hole sizes (holelst) 0,031, 0'045, 0·063
The designer now proceeds to select a drill size (drill) for hole4 which has a minimum
calculated hole diameter (calc_di) of 0'043. Since the minimum calculated hole diameter
(calc.di) now exceeds the minimum standard hole diameter (min_dia) for this hole,
constraint 11 in line 26j will never be violated; thus, for this hole, the minimum
calculated hole diameter defines the minimum range value. If the designer decides to
use a value (such as 0·052 as shown in Fig. 7) outside the range defined by the calculated
hole diameter (calc.di) or the maximum standard hole diameter (max_dia), 0·043
through 0'048, SPARK detects a violation of either constraint 12 or constraint 13 and
will notify the designer. Figure 8 shows a violation of constraint 12. If the designer
decides to use a non-standard drill size, SPARK also detects a violation of constraint
14.
Suppose, however, that the designer decides to use a standard drill size of 0'043,
which satisfies the constraints or being a standard drill size and of being within the
minimum or maximum range for this hole (constraints 12, 13 and 14). SPARK then
detects a violation of constraint 2 and will then point out to the designer that the
number of bits would exceed the capacity of the drill magazine.
 1732 R. E. Young et al.

F===-~---==== Spark User Interface - - - - - - - - - = = = = = ; J

0
0
variabl
1 2
constra
J
• 5 6
holes
7 8

1 hole 1 hole_2 hole_4 hole 5

hole J
2 xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx
J ..Cl ..
•
5
"C2"
"C3"
holetyp holetyp
std ovr std ovr
6 mag_siz .. C4" drill drill
7 board "C5<t oversiz oversiz
8 no hole "C6'" lead di lead di
9 std drl .. C7" calc-di calc-di
10 hole1st ..CO" min dia min dia
11 factor "Cg .. max-dia max-dia
12 class "CIO" plate plate
13 "CII" Bolder solder
14 .. e12" copper copper
15 "C13"
16 "C14"
17 ..CIS"
18
Downloaded by [Columbia University] at 01:12 12 December 2014

a>
SPARK Ver 1.0 Copyright (C) 1990 NCSU Industrial Engineering Department
Use arrow key or mouse to select variable or constraint.

Figure 6. Screen printout after hole 2 has been instantiated.

IF====-=~----- Spark User Interface ------==~~--"""'i

0: SOBJ->drlll size for lead hole D: number
012 J • 5 6 7 8
o variabl constra holes
1 VARIABLE - - - - - - - - - - - - - - ,
2
3 Long variable Name: SOBJ->drill size for lead hole
•
5 Short Variable Name: general_hole:holel+
6 unplated_hole:basic_hole.drill
7
8 Variable Domain: number
9
10 Variable Value: 0.052
11
12
13
14
15
16
17
18
a>
SPARK Ver 1.0 Copyright (C) 1990 NCSU Industrial Engineering Department

.
Please enter the new variable value. (It must be a number)

Figure 7. Variable assignment window shown with 0-052 assigned to variablefor the selected
drill size.

At this stage, the designer could decide to use a different drill machine with a larger
drill magazine size, or the designer could choose a different drill size. Of these options,
the more sensible approach would be to use a drill size of 0·045 inches. If this is done,
SPARK will check the network for constraint violations and finding none will report
this to the designer. In this way a designer would work through all the hole sizes in a
printed wiring board by instantiating a hole and then assigning values to the variables
in the hole's frame-based inheritance structure until all variables in all structures for all
holes have been assigned values that do not violate any constraints.
This example illustrates how the constraint networks in SPARK provide life-cycle
information to a designer that results in hole specifications for a printed wiring board
using standard drill sizes while remaining within drill magazine capacity, thereby
reducing both potential manufacturing problems and cost.
 AI constraint network for concurrent engineering 1733

0: SOB.J->drill
o 1 6 7 8
o variabl holes
1 , - - - - - - - - - - - - VIOLATIONS - - - - - - - - - - - - - - ,
2
3 Constraint 12.001 is violated due to the following user assignments:
4 general_hole:holel+unplated_hole:basic_hole.drill = 0
5 .052
6 qeneral_hole:holel+unplated_hole:baslc_hole+hole_spec:hole_da
7 ta.1ead di a 0.02 .
8 -general_hole:holel+unplated_hole:basic_hole.holetyp c plated_
9 thru
10
11
12 Do you want to save this in the
13 VIOLATE.TXT file? (Yin):
14
15
16
17
18
=>
Downloaded by [Columbia University] at 01:12 12 December 2014

SPARK Ver 1.0 Copyright (e) 1990 NCSU Industrial Engineering Department
Please enter the new variable value. (It must be a nUmber)

Figure 8. Constraint violation window showing that constraint 12 have been violated.

9. Summary and conclusions

Concurrent engineering is important in that it is at the design stage that much of a
products costs are specified. This paper has reviewed the difficulties associated with
performing concurrent engineering, discussed the various approaches to concurrent
engineering, and described the requirements for a system to support concurrent
engineering. A new approach to concurrent engineering that uses AI-based constraint
networks to meet these requirements has been presented. The SPARK constraint
network programming language has been described. An example concurrent engineer-
ing problem of PWB design is presented. This example demonstrates a system that
combines design guidelines with manufacturing constraints to help a designer produce
a PWB that simultaneously meets its functional specifications and could be manu-
factured on existing resources with minimum machine setups.
The use of AI constraint networks in SPARK provides a powerful system to
support concurrent engineering. The advantages of SPARK include being flexible
enough to allow the designer to approach a problem from a variety of viewpoints,
allowing the designer to design despite having incomplete information, and being able
to handle the wide variety of life-cycle information requirements. This approach also
allows the integration of knowledge from all aspects of the product's life-cycle into a
,?ommon format that is accessible to the designer.

Acknowledgment
This work was funded in part by the National Science Foundation, grant number
DDM-89 14200.

References
ANDREASEN, M. M., KHLER, S., and LUND, T., 1983, Design for Assembly (London: IFS
Publications).
BAO, H. P., 1988, An expert system for SMT printed circuit board design for assembly.
Manufacturing Review, 1 (4).
BAXTER, R., 1984, Companiesmust integrate-s-or stagnate! Production Engineering, April 1984.
London: Institute of Production Engineers.
 1734 R. E. Young et al.

BISHOP, A. W., 1986, Mechanical CAE in 1990. Knowledge Engineering and Computer Modelling
for CAD (UK: Butterworth & Co. (Publishers), Ltd).
BOOTHROYD, G., and DEWHURST, P., 1988, Product Design for Manufacture and Assembly.
Manufacturing Engineering, April 1988. USA: Society of Manufacturing Engineers.
BOOTHROYD, G., SWIFT, K., and REDFORD, A., 1981, Desiqnfor Assembly Handbook. University of
Salford Industrial Centre Ltd.
BORNING, A., 1979, ThingLab-A Constraint-Oriented Simulation Laboratory. Stanford
Technical Report STAN-CS-79-746.
BOWEN, J., and O'GRADY, P., 1989, Characteristics of a Support Tool for Life Cycle Engineering,
LISDEM Technical Report, North Carolina State University.
BRALLA, J. G. (editor in chief), 1986, Handbook ofProduct Designfor Manufacturing (New York:
McGraw-Hili).
CHAO, NIEN-HuA, 1985, The Application of a Knowledge Based System to Design for
Manufacture. IEEE Document number CH2125-7/85/()()()()/0182.
CHEN, Y., and YOUNG, R. E., 1988, PACIES (a part code identification expert system), lIE
Transactions, 20, 132-136.
Downloaded by [Columbia University] at 01:12 12 December 2014

CHIENG, W.-H., and HOELTZEL, D. A., 1986, An interactive hybrid (symbolic numeric) system
approach to near optimal design of mechanical components. Computers in Engineering, I.
CHIENG, W. H., and HOELTZEL, D. A., 1987, A generic planning model for large scale engineering
design optimization with a power transmission case study. Computers in Engineering, I.
DIETER, G. E., 1983, Engineering Design: A Materials and Processing Approach (New York:
McGraw-Hili).
DIXON, J. R., 1986, Artificial intelligence and design: a mechanical engineering view. Proceedings
of Fifth National Conference on Artificial Intelligence, AAAI-86, Volume 2, Engineering.
EASTMAN, C M., 1973, Automated space planning. Artificial Intelligence Journal, 4, 41~.
EVANS, 8., 1988, Simultaneous engineering. Mechanical Engineering, 110 (2).
EVERSHEIM, W., and MULLER, W., 1984, Assembly oriented design. Programmable Assembly,
edited by W. 8. Heginbotham (London: IFS Ltd).
FIKES, R. E., 1970, REF-ARF: a system for solving problems stated as procedures. Artificial
I ntelliqence, I (I), 27-120.
GAIROLA, A., 1986, Design for assembly: a challenge for expert systems. Robotics, 2.
GREEF, A., and YOUNG, R. E., 1990, Representing Rule-based Expert Systems as Constraint
Networks, TR-90-22. Laboratory for Intelligent Systems in Design and Manufacturing,
North Carolina StateUniversity. .
GROss, M., ERVIN, S., ANDERSON, J., and FLEISHER, A., 1987, Designing with constraints.
Computability of Design, edited by Y. H. Kaley (New York: John Wiley and Sons).
HAEUSLER, J., 1981, Design for assembly-state of the art. Proceedings of the 2nd International
Conference on Assembly Automation, Bedford, England.
HARFMANN, A. C, 1987, The rationalizing of design. Computability of Design, edited by Y. H.
Kaley (New York: John Wiley and Sons).
HELLER, E. D., 1971, Value Management: Value Engineering and Cost Reduction (New York:
Addison-Wesley).
ISHII, K., ADLER, R., and BARKAN, P., 1988, Knowledge-based simultaneous engineering using
design compatibility analysis. Artificial Intelligence in Engineering Design: Design, edited
by J. S. Gero (New York: Elsevier).
JAKIELA, M., PAPALAMBROS, P., and ULSOY, A. G., 1984, Programming Optimal Suggestions in
the Design Concept Phase: Application to the Boothroyd Assembly Charts. ASME
Technical Paper, No. 84-DET-77.
KALAY, Y. H. (ed.), 1987, Computability of Design (USA: John Wiley and Sons).
KONoPAsEK, M., and JAYARAMAN, S., 1984, The TK!Solver Book (Berkeley, CA:
Osborne/McGraw-Hili).
KROLL, E., LENZ, E., and WOLFBERG, J. R., 1988, A knowledge-based solution to the design for
assembly problem. Manufacturing Review, I (2).
Lu, C- Y. S., 1986, Knowledge Based Expert Systems: A New Horizon for Manufacturing
Automation. Knowledge Based Expert Systems for Manufacturing, PED-VoJ. 24 (New
York: ASME).
MADDUX, K. C, and JAIN, S. C, 1986, CAE for the manufacturing engineer: the role of process
simulation in concurrent engineering. Manufacturing Simulation and Processes, edited by
A. A. Tseng, D. R. Durham and R. Komanduri (New York: ASME).
 AI constraint network for concurrent engineering 1735

MEDLAND, A. J., 1986, The Computer Based Design Process (New York: Springer Verlag).
MURTHY, S. S., and ADDANKI, S., 1988, PROMPT: an innovative design tool. Proceedings of
National Conference on Artificial Intelligence, St. Paul, August, pp. 637--M2.
NATIONAL SCIENCE FOUNDATION, 1987, Research Priorities for Proposed NSF Strategic
Manufacturing Initiative, Report of a National Science Foundation Workshop.
O'GRADY, P., and KIM, J. Y., 1990, A Feature Taxonomy for Rotational Parts. LISDEM
Technical Report, North Carolina State University.
O'GRADY, P. J., and OH, J. S., 1990, An Artificial Intelligence Constraint Network Approach to
Design for Assembly, TR-90-14. Laboratory for Intelligent Systems in Design and
Manufacturing, North Carolina State University.
O'GRADY, P. J., RAMERS, D., and BOWEN, J., 1988,Artificial intelligence constraint nets applied to
design for economic manufacture and assembly. International Journal of Computer-
Integrated Manufacturing Systems, I (4), 204-210.
O'GRADY, P., YOUNG, R., GREEF, A., and SMITH, L., 1991, An advice system for concurrent
engineering. International Journal of Computer-Integrated Manufacturing, 4 (2), 63-70.
OAKLEY, M., 1984, Managing Product Design (New York: John Wiley and Sons).
Downloaded by [Columbia University] at 01:12 12 December 2014

OH, J., and O'GRADY, P., 1990, A Review of Approaches to Design for Assembly. LISDEM
Technical Report, North Carolina State University.
PECK, H., 1973, Designing for Manufacturing (London: Pitman Publishing).
REDFORD, A. H., SWIfT, K. G., and HOWIE, R., 1981, Product design for automatic assembly.
Proceedings 2nd International Conference on Assembly Automation.
REDFORD, A., 1986, Software aid to design for assembly. Assembly Automation, May 1986.
RILEY, F. 1., 1983, Assembly Automation: A Management Handbook (New York: Industrial Press).
ROSEN, D., RILEY, D., and ERDMAN, A., 1986, Development of an Inference Engine, with
Applications to Mechanism Synthesis part I: Introduction of the Inference Engine.
Technical Report 86-DET-156, American Society of Mechanical Engineers.
RUlZ,C; and KOENIGSBERGER, F., 1970, Designfor Strength and Production (New York: Gordon
Breach Science Publishers).
RUNCIMAN, C, and SWIfT, K., 1985, Expert system guided CAD for automatic assembly.
Assembly Automation, 5 (3).
SACKE1T, P. J., and HOLBROOK, A. E., 1988, DFA as a primary process decreases design
deficiencies. Assembly Automation, 137-140.
SEVENLER, K., REGHUPATHI, P. S., ALTAN, T., and MILLER, R. A., 1986,Knowledge-Based System
Approach to Forming Sequence Design for Cold Forging. Knowledge Based Expert
Systems for Manufacturing, PED-Vol. 24 (New York: ASME).
STEIN, J., and STRASSER, F., 1986, Metal Stampings. Handbook of Product Desiqnfor Manufactur-
ing, edited by J. G. Bralla (New York: McGraw-Hili).
SUSSMAN, G., and STEELE, G., 1980, CONSTRAINT8-a language for expressing almost-
hierarchical descriptions. Artijicial Intelligence, 14, 1-39.
SUTHERLAND, 1.,1963, SKETCHPAD: a man-machine graphical communication system.IFIPS
Proceedings of the Spring Joint Computer Conference.
SWIfT, K., 1987, Knowledge Based Design for Manufacture (London: Kogan Page).
SWIfT, K. G., and DoYLE, R., 1988, Design for Assembly in CAD Using Knowledge-Based
Systems. Technical report, University of Hull.
TONG, c., 1987,Toward an engineering science of knowledge-based design. Artijiciallntelligence
in Engineering, 2 (3), 133-166.
TRUCKs, H. E., 1987, Designing for Economical Production. Dearborn, MI. Society of
Manufacturing Engineers, Dearborn, MI.
VAN WYK, 1981, IDEAL User's Manual, Bell Labs Computer Science Technical Report 103,
Princeton, NJ.
WATERMAN, D. A., 1986, A Guide to Expert Systems (Reading, MA: Addison-Wesley), pp. 92-93.
Wu, P., 1988, Design for testability. Proceedings of the National Conference of the American
Associationfor Artificial lntelliqence, pp. 358-363.