Content uploaded by Steven B. Shooter
Author content
All content in this area was uploaded by Steven B. Shooter on Jul 25, 2014
Content may be subject to copyright.
Content uploaded by Steven B. Shooter
Author content
All content in this area was uploaded by Steven B. Shooter
Content may be subject to copyright.
Product family design knowledge representation,
aggregation, reuse, and analysis
JYOTIRMAYA NANDA,
1
HENRI J. THEVENOT,
1
TIMOTHY W. SIMPSON,
1
ROBERT B. STONE,
2
MATT BOHM,
2
and STEVEN B. SHOOTER
3
1
Depar tment of Industrial and Manufacturing Engineering, Pennsylvania State University, University Park, Pennsylvania, USA
2
Depar tment of Interdisciplinary Engineering, University of Missouri–Rolla, Rolla, Missouri, USA
3
Depar tment of Mechanical Engineering, Bucknell University, Lewisburg, Pennsylvania, USA
(Received January 11, 2006; Accepted November 25, 2006!
Abstract
A flexible information model for systematic development and deployment of product families during all phases of the
product realization process is crucial for product-oriented organizations. In current practice, information captured
while designing products in a family is often incomplete, unstructured, and is mostly proprietary in nature, making it
difficult to index, search, refine, reuse, distribute, browse, aggregate, and analyze knowledge across heterogeneous
organizational information systems. To this end, we propose a flexible knowledge management framework to capture,
reorganize, and convert both linguistic and parametric product family design information into a unified network, which
is called a networked bill of material ~NBOM! using formal concept analysis ~FCA!; encode the NBOM as a cyclic,
labeled graph using the Web Ontology Language ~OWL! that designers can use to explore, search, and aggregate
design information across different phases of product design as well as across multiple products in a product family;
and analyze the set of products in a product family based on both linguistic and parametric information. As part of the
knowledge management framework, a PostgreSQL database schema has been formulated to serve as a central design
repository of product design knowledge, capable of housing the instances of the NBOM. Ontologies encoding the
NBOM are utilized as a metalayer in the database schema to connect the design ar tifacts as par t of a graph structure.
Representing product families by preconceived common ontologies shows promise in promoting component sharing,
and assisting designers search, explore, and analyze linguistic and parametric product family design information. An
example involving a family of seven one-time-use cameras with different functions that satisfy a variety of customer
needs is presented to demonstrate the implementation of the proposed framework.
Keywords: Design Repository; Information Management; Ontology; Product Family
1. INTRODUCTION
Managing product and process data over the total product
lifecycle is one of the most critical business processes for
many engineering products ~Bourke, 1999!. Continued pres-
sure to reduce product development time has resulted in an
increased focus on methods for representing and storing
engineering artifact knowledge in a way that facilitates its
retrieval and subsequent reuse ~Szykman et al., 2000!. Suc-
cessful product family planning places an even greater
requirement on effective information management to exploit
the potential of shared assets ~Simpson, 2004!. By sharing
assets such as components, processes, and knowledge across
products, companies can efficiently develop a family of
differentiated products for a variety of market segments
and increase the flexibility and responsiveness of their prod-
uct realization process ~Shooter et al., 2005!.
The need for computational design frameworks to sup-
port the representation and use of knowledge among dis-
tributed designers becomes more critical as product design
becomes increasingly knowledge intensive and collabora-
tive ~Szykman et al., 2000!. In the knowledge management
framework proposed in this paper, we capture, reorganize,
and convert component design information into a unified
Reprint requests to: Timothy W. Simpson, Department of Industrial
and Manufacturing Engineering, 329 Leonhard Building, Pennsylvania
State University, University Park, PA 16802, USA. E-mail: tws8@psu.edu
Artificial Intelligence for Engineering Design, Analysis and Manufacturing ~2007!, 21, 173–192. Printed in the USA.
Copyright © 2007 Cambridge University Press 0890-0604 007 $25.00
DOI: 10.10170S0890060407070217
173
network, called a network bill of material ~NBOM!, to facil-
itate both linguistic and parametric design information man-
agement for a family of products. The NBOM is encoded as
a cyclic, labeled graph using the Web Ontology Language
~OWL!, an open standard proposed by the Semantic Web
group at the World Wide Web consortium ~W3C!. Collab-
orative design in heterogeneous and distributed design envi-
ronments necessitates the use of ontologies as a common
communication framework. Ontologies have been devel-
oped for many fields to establish common vocabularies and
capture domain knowledge, and they have proven to be an
advantageous paradigm over recent years ~van der Vegte
et al., 2002!. Gennari et al. ~1994! discuss the high payoff
of saved effort due to reuse of preexisting knowledge cap-
tured in ontologies. The preconceived product family ontol-
ogies help designers explore, search, and aggregate design
information across different phases of product design as
well as across multiple products in a product family. A Post-
greSQL database schema has been formulated to serve as a
central repository of product design knowledge, capable of
housing the instances of the NBOM.
In the next section, we review related literature in prod-
uct representation and knowledge management. In Sec-
tion 3 we introduce the knowledge management framework
that is proposed in this paper for capturing, organizing, stor-
ing, and analyzing information during product family design.
An example involving a family of seven one-time-use cam-
eras is given in Section 4 to demonstrate the use of the
framework. Section 5 provides closing remarks and dis-
cusses future work.
2. BACKGROUND AND RELATED WORK
2.1. Product design information management
A design comprises information that can be in many forms
~Dixon & Poli, 1999!.Adesigned artifact has many differ-
ent kinds of information associated with it during product
realization, starting from highly abstract information in the
early phases of design to very detailed information at the
parametric phase. As the design evolves, the accompanying
information is represented at different levels of abstraction,
and Shooter et al. ~2000! present a model for the flow of
design information to eventually suppor t a semantics-based
approach for developing information exchange standards.
At the abstract end of the spectrum, Kirschman and Fadel
~1998! proposed a taxonomy of elemental mechanical func-
tions that can be used with many decomposition tech-
niques. Iwasaki and Chandrasekaran ~1992! focused on the
task of design verification using both knowledge of the
structure of a device and its intended functions. For more
detailed information, Bohm et al. ~ 2005! review commer-
cial software packages that provide a hierarchical decom-
position of product structure and their related proprietary
and nonproprietary output formats.
The complexity in managing product structure and the
associated information increases in a collaborative design
environment where the use of different software systems
is common, and the task is fur ther complicated by the
proprietary nature of much of this information ~Hatvany
et al., 1993!. Saaksvuori and Immonen ~2003! discuss the
many common output standards that many of these sys-
tems use, including the data exchange format, standard for
the exchange of product model data, and initial graphics
exchange specification, to name a few. Conversion tools
among these formats are costly, application-specific, and
often lead to further uncertainty about data integrity. The
limited design information captured by the individual soft-
ware systems in proprietary data structures makes it diffi-
cult to index, search, and browse design artifacts across
the organizational information systems.
The National Institute of Standards and Technology
~NIST! is involved in the development of an intelligent
design repository based on data language ~DL! and a design
representation language ~Murdock et al., 1997; Szykman
et al., 2000!. The design repository at the University of
Missouri–Rolla ~UMR!, following NIST’s approach toward
neutral data exchange, has implemented an extensible
mark-up language ~XML!-based approach to import and
export the product knowledge from the design repository
~Bohm et al., 2005!. Although the XML representation pro-
vides a standard data structure for describing the artifacts,
it does not provide the semantics, that is, the meaning of the
data structure. As part of the proposed knowledge manage-
ment framework, we address this limitation by adding a
semantic layer using OWL ontologies to the UMR Design
Repository that contains more than 100 products ~http:00
function.basiceng.umr.edu0repository!. To organize both the
linguistic and parametric design information, we use for-
mal concept analysis ~FCA!, as discussed in the next section.
2.2. FCA
FCA is used for analyzing data and forming semantic struc-
tures that are formal abstractions of concepts of human
thought ~Ganter & Wille, 1999!. It borrows its mathemati-
cal foundation from order theory, particularly the theory of
complete lattices ~Gratzer, 1998!. In the literature, FCA is
used for natural language processing ~Priss, 2003!, modu-
lar information retrieval ~Godin et al., 1993!, query-based
software component retrieval ~Lindig, 1995!, identification
of potential modules in computer programs ~Siff & Reps,
1997 !, design decision making in educational applications
~Fernandez-Manjon & Fernandez-Valmayor, 1998!, and data
analysis and machine learning ~Kuznetsov, 2001!. Godin
and Mili ~1993! proposed a formal method for building,
maintaining, and refining hierarchies in object-oriented pro-
grams using Galois lattices.
The basic notion of FCA is structured around the notion
of a formal context and a formal concept.Aformal context
is a triple K
:
⫽ ~C, P, R!, where C is a finite set of objects,
174 J. Nanda et al.
P is a finite set of attributes, and R is a binary relation
between C and P.Aformal concept of K is represented by
the elements of B~K !
:
⫽ $~C
1
, P
1
! 6 C
1
債 C, P
1
債 P, C
1
'
⫽
P
1
, P
1
'
⫽ C
1
%; hence, a formal concept is a combination of a
set of objects ~called its extent! and a set of attributes ~called
its intent! such that all objects have all attributes and all
attributes belong to all objects. A relation R is represented
as a subset of the cross product between the finite sets of
objects and attributes, that is, R 債 C ⫻ P. The mappings
captured by relation R give rise to a Galois connection ~Erné
et al., 1991!.Across table is used to capture the binary
relation R between objects C and attributes P.
A many-valued formal context ~C, P, W, R! consists of
sets C, P, and W and a ternary relation R between C, P , and
W ~ see Figure 1!, that is, R 債 C ⫻ P ⫻ W for which it holds
that ~c, p, w! 僆 R and ~c, p, v! 僆 R always imply w ⫽ v. The
notation ~c, p, w! 僆 R is read as “the attribute p has value
w” for the object c. The many-valued attributes are regarded
as partial maps from C in W. Conceptual scaling ~Ganter &
Wille, 1999! is the method that is used on many-valued
contexts to derive the concept lattice.
The Galois or concept lattice of K is a partially ordered
set represented by tB~K ! ⫽ ~B~K !, ⱕ! with ~C
1
, P
1
! ⱕ ~C
2
,
P
2
! :? C
1
債 C
2
~?P
1
傶 P
2
!. Here, tB~K ! is a complete
lattice ~ Gratzer, 1998! for which the infimum ~greatest com-
mon formal subclass! and supremum ~smallest common for-
mal subclass! are given as the following:
∧
i僆I
~C
i
, P
i
! ⫽
冉
艚
i僆I
C
i
, s
冉
t
冉
艛
i僆I
P
i
冊冊冊
, ~1!
∨
i僆I
~C
i
, P
i
! ⫽
冉
t
冉
s
冉
艛
i僆I
C
i
冊冊
,
艚
i僆I
P
i
冊
, ~2!
where I is an index set.
A concept lattice is graphically represented using a line
diagram known as the Hasse diagram ~Ganter & Wille, 1999!.
The nodes in the Hasse diagram of a context are labeled
dually with the objects ~below! and attributes ~above!, and
the vertices represent the relationships between the objects.
A reduced labeling scheme is often used and is applied in
this work as demonstrated in Section 4.
FCA can be used to construct lattice structures for large-
scale problems in real time. Let l be the total number of
formal concepts, m be the total number of properties, and k
the total number of classes in a concept lattice. Then the
worst case complexity of the lattice constructing algorithm
is generally admitted to be O~~k ⫹ m!lmk!~Valtchev et al.,
2002!. Using the algorithm proposed by Nourine and
Raynaud ~1999! reduces the complexity to O~~k ⫹ m!lm!.
Dividing the concepts and forming partial lattices before
forming the global lattice structure reduces the complexity
to O~~k ⫹ m!lm log m!~Valtchev et al., 2002!.
There are a number of software tools developed in the
last two decades to support FCA in different fields. General
Lattice Analysis and Design ~Duquenne et al., 2001!, Con-
texts and Implications ~Burmeister, 2003!, Tools of Con-
cept Analysis ~TOSCANA; Groh et al., 1998!, and ToscanaJ
~Vogt & Wille, 1995; Becker, 2004! are some of the soft-
ware tools that support FCA. Tilley ~2004! reviews these
and various other tools available for FCA in more detail.
2.3. Knowledge management and ontologies
The knowledge management community has developed a
wide range of technologies and applications as reviewed by
Liao ~2003! . Among these, the Semantic Web is envisioned
by W3C as an extension of the current Web to create Web-
based knowledgeable systems with various specialized rea-
soning services systems ~Davies et al., 2003!. The goal of
the Semantic Web is to develop standards and technologies
designed to help machines understand more information on
the Web and support richer discovery, data integration, nav-
igation, and automation of tasks ~Koivunen & Miller, 2001!.
Ontologies play an important role in achieving this goal.
An ontology consists of a set of concepts, axioms, and rela-
tionships that describes a domain of interest. These con-
cepts and the relationships between them are usually
implemented as classes, relations, properties, attributes, and
values ~of the properties0attributes; Daconta et al., 2003!.
The W3C’s Semantic Web initiative proposes a layered
approach to a standard Web ontology language, namely,
OWL ~McGuinness & van Harmelen, 2004!. OWL is cur-
rently the most expressive semantic markup language for
publishing and sharing ontologies on the World Wide Web.
Figure 2 summarizes the degree of formality ~level of seman-
tic information! stored along with the data by a particular
method of information storage, and presents the technolog-
ical maturity level of OWL and many methods that have
preceded it.
Ontologies, like OWL, are well suited for product family
design knowledge representation by supporting reasoning
outside the transaction context, that is, it avoids a protocol
specification to handle standard data format. Instead of try-
ing to capture all the knowledge about a domain or family
in a single ontology, OWL promotes distributed ontology
development and enables multiple ontologies to be easily
linked. OWL ontologies can store the structure of several
products in a product family in multiple distributed ontol-
ogies to facilitate design information sharing over the Inter-
net. This is also useful for concurrent product family
development where the semantics of multiple products need
Fig. 1. A multicontext cross table.
Product family design knowledge representation 175
to be shared across multiple stages of product development.
OWL is supported by description logic ~Baader et al., 2003!,
which makes it easier for computers to interpret the seman-
tics without human intervention. Programming packages
like Protégé ~Noy et al., 2001! can provide a graphical user
interface for editing ontologies, and Jena ~McBride, 2002!
has application programming interfaces for generic OWL
manipulation and a rule-based inference engine. Conse-
quently, OWL is central to our knowledge management
framework, which is introduced next.
3. KNOWLEDGE MANAGEMENT
FRAMEWORK FOR PRODUCT
FAMILY DESIGN
To manage the design knowledge associated with a group
of related products, we propose the product family knowl-
edge management framework shown in Figure 3. There are
three steps to the framework, which aims to organize and
analyze both linguistic and parametric product family design
information. The first step uses the product family ontology
Fig. 2. Methods of persistent information storage.
Fig. 3. The product family knowledge management framework. @A color version of this figure can be viewed online at www.jour-
nals.cambridge.org#
176 J. Nanda et al.
development methodology ~PFODM! for design knowl-
edge acquisition, graph-based organization, and ontology
development ~Nanda et al., 2006!. The second step employs
a database and ontology metadata to represent design knowl-
edge as a graph-based product family uniform information
model ~Nanda et al., 2005a!. In the third step, the product
family representation and redesign framework ~PFRRF! is
used for commonality assessment as well as product family
redesign ~Nanda et al., 2005b!. The steps are cyclical to
ensure and maintain the relevancy of design information in
the database ~in our case, the UMR Design Repository!,
and to help designers analyze multiple products within a
single product family. The primary contribution in this paper
is the integration of these three steps into the framework
shown in Figure 3; details on the implementation of each
step and their integration follow.
3.1. Step 1: Capture and organize component
design information into an NBOM
The first step in the proposed framework is to obtain the
necessary data for the product family concerned. This first
step is critical to ensure that information is captured and
organized in a way such that relevant data can then be rep-
resented and stored ~see Step 2!. The typical way to capture
data is using a bill of materials ~BOM!; hence, if the infor-
mation is already available through a BOM, then the user
can directly reuse the data. If the information is not readily
available, dissection of the products in the family is required.
We employ the subtract and operate procedure of Otto and
Wood ~ 2001! to gather the following information for each
part: size, geometry, material, manufacturing process, and
assembly0fastening scheme. Production volume and unit
cost for each part should also be obtained. If they are not
readily available, appropriate methods should be used to
estimate them ~Boothroyd & Dewhurst, 2002; Ulrich &
Eppinger, 2004!. In this paper, only high-level features are
captured to demonstrate the proposed approach; however,
the list can be as refined and detailed as needed for a par-
ticular product family. Likewise, for complex large-scale
systems, the level of granularity can be varied as needed to
build ontologies at the component level, module level, or
subsystem level, or any combination thereof, as appropriate
for the family being analyzed.
3.1.1. Overview of the database schema to capture
linguistic and parametric design data
In this research, we are using an already extensively devel-
oped design repository, the UMR Design Repository. It cap-
tures design information instances that are useful during
product family design. The design information captured by
the design repository data schema can be classified into
seven main groups: artifact-, function-, failure-, physical-,
performance-, sensory-, and media-related information types
~Bohm et al., 2005!. The database tables are broken up into
two separate categories: those that directly store product
information and those that are referenced by product stor-
ing database tables ~Bohm et al., 2006!. Figure 4 shows an
illustration of the UMR Design Repository schema. The
boxes represent data tables, and the arrows represent data
relationships. All the repository data tables are represented
in this figure with the 13 data storing tables highlighted. A
data table makes a reference to another table by an out-
bound arrow to a particular data table. The tables that store
taxonomies and bases are denoted with _type after the table
name. Taxonomy and basis storing tables do not reference
design data storing tables. Thus, for example, the failure
table references the artifact, failure_type and failure_rating_
type tables but is referenced by the failure_data_info table.
There are several types of media that can be associated
with ar tifacts. Media types can take the form of pictures,
graphical functional models, graphical assembly models,
two-dimensional CAD files, three-dimensional CAD files,
stereo lithographic ~.stl! files for rapid prototyping
machines, and many others. All the types of media, men-
tioned and unmentioned, reside in the media table of the
repository. Instances of media are unique and associated
with an artifact, which is captured by the id and describes_
artifact field. The data field in the media table is the “large
object” pointer for the actual media files of any type.
Information entry occurs within a front-end entry appli-
cation, whereas information retrieval occurs over the Inter-
net through the UMR Design Repository’s Web portal. The
current and emerging versions of the repository are built
and served by a PostgreSQL ~a SQL variant! database ~Doug-
las & Douglas, 2003!. There are close to 100 products present
in the current PostgreSQL database. In the next section, the
specific use of FCA to organize and extract semantic design
information is discussed.
3.1.2. Using FCA to organize the database
information as a graph
The information stored in the design repository is then
organized using FCA to transform stored information into
reusable knowledge. FCA is semantically enriched using
OWL by applying the PFODM shown in Figure 5 ~Nanda
et al., 2006!. In this methodology, the individual product
hierarchies in a BOM are merged to create the product–
component cross table ~see Figure 6!, which is the input for
FCA. In the product–component cross table , products are
represented as objects and component instances as attributes
with single or multiple values. The product–component cross
table can capture both the binary and multicontext relation-
ships between components and products.
A component can exist in many component instances.A
component is a part that is used for a certain function or set
of functions. Two parts are component instances from the
same component if they are used for the same functions or
set of functions and they differ slightly by size, shape, mate-
rial, and so forth. The decision to group a number of com-
ponent instances under a par ticular component is mainly
made by a designer. For example, consider the two flash
Product family design knowledge representation 177
buttons shown in Figure 7 taken from two one-time-use
cameras. They are two different component instances ~flash
button 1 and flash button 2! of the component flash button:
they provide the same function ~turn on the flash! but differ
in shape and color. Once these decisions are made, the
NBOM can be created as discussed in the next section.
3.2. Step 2: Represent and store product
design information
Once the information has been captured and relationships
have been created ~Step 1!, this knowledge is then repre-
sented and stored using a product family unified information
model ~Step 2!. This step aims at visualizing relationships
that are not captured in traditional product family data infor-
mation management, and at helping designers navigate
through the extensive information collected in Step 1.
3.2.1. Encoding the NBOM using OWL
The many-valued formal contexts captured in step 1 are
used to develop the product family concept lattice using
FCA, which is then converted into OWL using the PFODM
shown in Figure 5 ~Nanda et al., 2006!. The partial order
set of the concept lattice is used to develop the subsumption
Fig. 4. A graphical view of the University of Missouri–Rolla Design Repository database tables ~Bohm et al., 2006!.
Fig. 5. The product family ontology development methodology ~PFODM!.
178 J. Nanda et al.
hierarchy of the product family ontology. Figure 8 shows
the mapping between the products and the component lat-
tices after the ontologies are constructed. Components that
are part of a product also have their own lattice structure
based on their individual properties. This way, all product
and component knowledge is connected as a graph in the
knowledge base and stored as multiple OWL ontologies to
facilitate browsing, graph-based queries, and ultimately com-
ponent reuse.
We refer to the resulting concept lattice as the NBOM
~Nanda et al., 2005c!. The NBOM can capture the unique,
variant, and common components in a product family as
shown in Figure 9. Representing the NBOM in ontologies
enables designers to query the knowledge base based on
graph pattern matching using querying languages like RDQL
~Miller et al., 2002!, SPARQL ~Clark, 2005!, and OWL-QL
~Fikes et al., 2003!. The NBOM also allows instances of
classes that represent the components to be compared against
each other, which is useful for product family assessment
and redesign ~see Step 3!.
In addition to the NBOM, the product vector matrix
~PVM! and function component matrix ~FCM! are used to
represent and map different design information structures.
Because of unique and variant components present in indi-
vidual products, each mapping is unique for a particular
product in a product family.
The PVM maps the relationships between the functions
listed in the function structure model and the weighted cus-
tomer needs ~see Fig. 10!. The first column of the PVM
lists the product functions ~PFs!, and the weighted cus-
tomer needs ~CNs! are listed across the top row of the PVM.
Because we are only interested in the mapping between
design information structures, we do not consider customer
needs weights in the PVM at this time. For each function
that impacts a particular customer need, a “1” is entered
into the cell in the matrix. In Figure 10, the highlighted cell
signifies that for product X customer need 1 ~CN
1
X
! is sat-
isfied by product function 2 ~PF
2
X
!.
FCM maps the relationships between the functions cap-
tured in the function structure model and the components
listed in the BOM ~see Fig. 11!. Similar to PVM, for each
component that impacts a particular product function, a “1”
is entered into the cell in the matrix. In Figure 11, the high-
lighted cell signifies that for product X component 2 ~C
2
X
!
partially satisfies product function 1 ~PF
1
X
!.
Figure 12 describes the multimodal design representa-
tion of a product family using common ontologies. A single
ontology is built across the various phases of product fam-
ily design and is used by each individual product to repre-
sent the unique component instances in a product family.
The common ontological layer not only ensures data con-
sistency in a given phase but also helps in aggregating infor-
mation across products in a product family.
The designer can perform an exploratory data analysis in
the product family by choosing any single design artifact
from a single product and then going back and forth between
Fig. 6. A product–component multicontext cross table.
Fig. 7. Two component instances of a camera flash button. @A color ver-
sion of this figure can be viewed online at www.journals.cambridge.org#
Fig. 8. Product–component–attribute integration.
Product family design knowledge representation 179
the common ontological layer and the product instance rep-
resentation. The product family design information aggre-
gation can further be subdivided into two groups: design
information aggregation between products of a product fam-
ily and design information aggregation across different
phases of the product realization process. Both are described
in more detail in the following.
3.2.2. Product family design information aggregation
spanning multiple products and across phases
Due to the common ontology layer, each design entity
that is par t of an individual product is an instance of an
OWL class. This conceptual grouping using ontologies helps
aggregate information between products within a family.
Star ting with a single design instance selected by the
designer, the information system can query and list all the
other instances of that particular class present in the design
repository. The information system can also query related
classes from the ontology and present them to the designer.
For example, if we start with a single product function for
product X, say PF
1
X
, then the system can locate the class for
this instance as PF
1
C
and list all the other instances of this
class present in the system automatically. In addition, when
new products are introduced in the product family, they will
be represented using these preconceived ontologies making
the integration and design analysis process automatic.
PVM and FCM also capture the relationships between
two different design information structures. This mapping
helps the system to transparently present design informa-
tion from across different phases of the product realization
process. For example, if we start with a single customer
need instance for product XCN
1
X
, we can easily get the
components that satisfy this customer need by moving from
customer need to product function to component space using
PVM first and then FCM.
3.3. Step 3: Product family analysis and redesign
After the design repository is populated with data for each
product ~Step 1! and a metadata layer is created using ontol-
ogies ~Step 2!, the product family can be analyzed to iden-
tify oppor tunities to redesign products in the family to
improve commonality. In this paper, we use commonality
indices for this purpose; they are one of many tools avail-
able to support product family analysis and redesign ~Simp-
son, 2004!. Commonality indices are reviewed next, followed
by methodologies to redesign products in the family using
the NBOM.
3.3.1. Using commonality indices to analyze
a product family
The primary motivation for product family design is to
increase commonality among the products in the family,
and several component-based commonality indices have been
developed to assess the degree of commonality within a
product family. Thevenot and Simpson ~2006a! provide a
detailed comparison between many of these commonality
indices and discuss their usefulness for product family
redesign. Five such indices are used for illustration pur-
poses in the example in Section 4.3: the Degree of Com-
monality Index ~DCI! proposed by Collier ~1981!, the Total
Constant Commonality Index ~TCCI! from Wacker and Trel-
evan ~1986!, the Commonality Index ~CI! introduced by
Fig. 9. The networked bill of material ~NBOM! lattice structure. @A
color version of this figure can be viewed online at www.journals.
cambridge.org#
Fig. 10. The product vector matrix for an individual product.
Fig. 11. The function component matrix for an individual product.
180 J. Nanda et al.
Martin and Ishii ~1997!, the Product Line Commonality
Index ~PCI! of Kota et al. ~2000!, and the Comprehensive
Metric for Commonality ~CMC! developed by Thevenot
and Simpson ~2006b!.
3.3.2. Using the graph structure to redesign the
product families
Based on the NBOM representation developed in Step 2,
we have proposed two approaches to navigate the concept
lattice to redesign the product family ~see Fig. 13! . The first
is a component-based approach, wherein designers select
unique or variant components in a product family and try to
make them variant or common to improve commonality in
the family. The second is a product-based approach, whereby
designers select multiple products from a product family
and try to increase the commonality between the selected
products. In both cases, preference is given to making vari-
ant components common over making unique components
variant to maximize economies of scale. The steps for imple-
menting both approaches are listed in Figure 13 and details
can be found in Nanda et al. ~2005b! where the resulting
PFRRF was first introduced. Its use is demonstrated in the
next section, along with the first two steps of the proposed
knowledge management framework, with an example involv-
ing a family of one-time-use cameras.
4. PRODUCT FAMILY KNOWLEDGE
MANAGEMENT: A CASE STUDY
The following sections demonstrate implementation of the
three steps that constitute the knowledge management frame-
work to organize and analyze product family design infor-
mation. For this example, a family of seven one-time-use
cameras manufactured by Kodak is used ~see Table 1!. These
cameras are readily available in the market, and offer spe-
cific differentiating functions: flash, digital processing,
waterproof, black and white, and the Advanced Photo Sys-
tem with switchable format as listed in the table.
4.1. Step 1: Capture and organize product family
design information
To develop the lexicon set to describe the components in
the family of one-time-use cameras, they are disassembled
to the component level where a component is a part of the
camera that cannot be further decomposed into design arti-
facts. Sections 4.1.1 and 4.1.2 discuss capturing and orga-
nizing the design artifact data about the camera family.
4.1.1. Capturing design information for the
camera family
After the products are disassembled, all of the terms asso-
ciated with the components are collected in a dictionary
form, including synonyms for the components. Based on
this dictionary of terms or lexicon set, the product family
ontology is formalized. For example, the lexicon set for
describing the shutter cover for the MAX Outdoor camera
can be L
1
:
⫽ $MAX Outdoor shutter cover, shutter cover of
MAX Outdoor, MAX shutter cover%. Figure 14 shows both
the linguistic and parametric information associated with
a camera shutter cover as stored in the UMR Design
Repository.
The linguistic information captured for the Water & Sport
and Plus Digital cameras is presented in Figure 15. The
Fig. 12. The model for product family design information aggregation ~Nanda et al., 2005a!.
Product family design knowledge representation 181
Fig. 13. The product family representation and redesign framework ~PFRRF; Nanda et al., 2005b!.
182 J. Nanda et al.
linguistic information thus captured is also used to create a
dictionary to store the commonly associated keywords. These
keywords help reduce the proliferation of synonyms in the
design repository. Alternatively, standard terms from the
functional basis ~Hirtz et al., 2002! and component basis
~Kurtoglu et al., 2005! could be used.
4.1.2. Organizing the design information for the
camera family
Once the design information is captured, FCA is used to
organize the information in a graph structure, which pro-
vides the link between all the terms associated with design
artifacts in the design repository. To demonstrate the pro-
posed approach, we consider three cameras from the prod-
uct family: MAX Power Flash, Plus Digital, and Water &
Sport. Seven types of components ~front cover insert, water-
proof front cover, battery, film advance wheel, shutter spring,
exposure counter! that are part of the three products are
used to illustrate the NBOM. Table 2 shows the compo-
nents and their relationships with the cameras in a multi-
context cross table. Different numbers are used in the cross
table to differentiate component types. For example, to rep-
resent two types of film advance wheel, the numbers 1 and
2 are used in the cross table.
Table 1. Summary of one-time-use cameras
MAX Outdoor MAX Flash Plus Digital MAX HQ
ADVANTIX
Switchable
Black & White
MAX Water
& Spor t
Film 35 mm
color
35 mm
color
35 mm
color
35 mm
color
24 mm
color
35 mm
black & white
35 mm
color
Flash No Yes Yes Yes Yes Yes No
Waterproof No No No No No No Yes
Switchable format No No No No Yes No No
Digital processing No No Yes No No No No
A color version of this table can be viewed online at www.journals.cambridge.org
Fig. 14. Shutter cover details in the design repository. @A color version of this figure can be viewed online at www.journals.
cambridge.org#
Product family design knowledge representation 183
The cross table in Table 2 is then converted into the
NBOM using FCA. The resulting NBOM structure of the
product family is shown in Figure 16. The products are
shown below the nodes of the NBOM, whereas compo-
nents are represented on the top of the nodes in the lattice.
The formal context and the concept lattice for the one-time-
use camera family ontology is formalized using ToscanaJ
~Vogt & Wille, 1995; Becker, 2004!.
The component cross table is built using attributes for
material, color, manufacturing process, and weight for illus-
tration ~see Fig. 17!. Designers can include as many attributes
as necessary to compare components between each other
and develop component lattices. The cross table facilitates
building of the lattice structure using FCA ~see Fig. 18!,
which is then stored as an OWL ontology for later retrieval
and reuse.
4.2. Step 2: Represent and store design information
using ontologies
The lattice structure developed in the previous section is
next encoded using OWL-DL and enriched using Protégé-
2000 ~Noy et al., 2001!, an ontology editor and a knowl-
edge base editor, with the OWL ~http:00protege.stanford.edu0
plugins0owl0! and the ezOWL plug-ins ~http:00smi-protege.
stanford.edu0svn0ezowl0!. Protégé-2000 is one of the most
Fig. 15. Kodak one-time-use camera linguistic information capture.
184 J. Nanda et al.
Tab le 2. Kodak product family cross table
Front Cover
Inser t
Waterproof
Front Cover Battery
Film Advance
Wheel
Shutter
Spring
Exposure
Counter
MAX Power Flash 1 1 1 1
Plus Digital 1 2 2 1 1
Water & Sport 1 2 1 1
Fig. 16. The networked bill of material ~NBOM! based on the product family lattice structure. @A color version of this figure can be
viewed online at www.journals.cambridge.org#
Fig. 17. A product family component cross table.
Product family design knowledge representation 185
popular ontology editing tools as it allows users to con-
struct domain ontologies, customize data entry forms, and
enter instances of the ontology ~Denny, 2004!.
4.2.1. Encoding the NBOM using OWL
The partial order set of the concept lattice developed in
Section 4.1.2 is used to develop the subsumption hierarchy
of the product family ontology using the PFODM ~see Fig. 5!.
Figure 19 partially shows the ontology structure of the cam-
era family using OWL ontology, which is automatically
drawn using ezOWL plug-ins in Protégé-2000. Figure 20
shows the document object model structure of the one-time-
use camera product family. The first few lines of the ontol-
ogy contain the annotation part and specify all the URI
references. The complete ontology is available on-line at
http:00edog.mne.psu.edu0owl0kodak.owl.
As noted in Section 3.2, the PVM captures the relation-
ships between the customer needs and product functions
and the relationships between product functions and prod-
uct components are captured by constructing the FCM.
Figure 21 shows the PVM for the Water & Spor t camera.
For each function that impacts a particular customer need,
a “1” is entered into the cell in the matrix; thus, for exam-
ple, the customer need $~compact design!% is fulfilled by
functions ~$actuate mechanical energy%, $convert human
energy to mechanical energy%, $guide mechanical energy%,
$import human energy%!. Figure 22 shows the FCM for the
Water & Sport camera. Here a “1” is entered into the cell
of a matrix for each component that impacts a particular
product function. For example, the product function ~$guide
mechanical energy%! is fulfilled by component ~$arm retain-
er%!. These matrices are created for all seven products in
the family.
All customer needs, product functions, and information
about the components are aggregated in this manner, and a
generic ontology is created for the entire product family.
After creating the ontologies and the individual instances,
the entities between the three types of design information
are mapped using PVM and FCM to aggregate information
within the family and across different design phases.
Fig. 18. A component–attribute lattice for batteries in the one-time-use cameras. @A color version of this figure can be viewed online
at www.journals.cambridge.org#
Fig. 19. The camera family ontology. @A color version of this figure can be viewed online at www.journals.cambridge.org#
186 J. Nanda et al.
4.2.2. Information aggregation across cameras and
design phases
The common ontological layer in conjunction with PVM
and FCM help in automatic design aggregation across phases,
and the BOM structure helps design information aggrega-
tion across products in a single phase for the designers. For
example, let us consider a scenario where the designer is
redesigning the $Water & Sport shutter cover%. The system
can aggregate all the shutter covers used in the entire prod-
uct family by first getting the class $Shutter Cover% from
which the individual $Water & Sport shutter cover% is an
instance and then listing all the other instances of type $Shut-
ter Cover%, that is, ~$MAX shutter cover%, $Advantix shutter
cover%, $Black and white shutter cover%!. The system can
also compare the attributes of each shutter cover and present
them to the designer. This automatic context-based aggre-
gation of design information can be applied to all of the
design entities in every phase of product realization that is
represented within the ontology.
The PVM and FCM help aggregate the information across
different phases of product design. For instance, the Water
& Sport camera customer need $rugged and durable% is sat-
isfied by five product functions ~$actuate mechanical ener-
gy%, $guide mechanical energy%, $store solid%, $translate solid%,
$link solid%!. Similarly, the product function $translate solid%
is fulfilled by two components ~$film advance gear%, $film
advance wheel 2%!. Combining the common ontologies,
PVM, and FCM with a NBOM makes the design informa-
tion model transparent, flexible, and interoperable across a
network of different systems.
4.2.3. Storing and querying the ontology metalayer
Using the one-time-use camera product family ontology,
product designers can explore various types of cameras as
well as the components that are part of the camera product
family. The one-time-use camera product family ontology
can also be queried using semantic queries based on graph
pattern matching that can span multiple products across the
entire ontology. For example, the RDQL query “SELECT
?classAnyCamera, ?instanceFlash WHERE ~?classAnyCam-
era, ^KodakFamily:Has_Flash &, ?instanceFlash! USING
KodakFamily FOR ^http:00edog.mne.psu.edu0ontology 0
kodak#&” can query the ontology and list all the cameras
and their corresponding flash components ~i.e., classes hav-
ing Has_Flash property! across the product family. In this
case, it would return $~Plus_Digital, Flash_Max!, ~MAX_
Flash_Camera, Flash_Max!, ~ MAX_HQ, Flash_Max!,
Fig. 20. A sample of the Web Ontology Language ~OWL! ontology for the cameras. @A color version of this figure can be viewed
online at www.journals.cambridge.org#
Fig. 21. The product vector matrix for the Water & Spor t camera.
Product family design knowledge representation 187
~Advantix_Switchable, Flash_APS!, ~Black_and_White,
Flash_Black_and_White!%, which is an array of cameras
and their flash components. The semantic query and retrieval
is currently being implemented within the UMR Design
Repository to facilitate designer-initiated Web-based design
exploration. In the next section, further analysis of the cam-
era family is discussed.
4.3. Step 3: Product family analysis and redesign
Once the information is stored in the appropriate format, a
product family can be redesigned using either the component-
based approach or the product-based approach described
in Section 3.3.2. In this example, only seven components
are used for ease of understanding; however, the methodol-
ogy is scalable to larger problems involving more compo-
nents and products. The components used here are listed in
Figure 23. The products are listed in rows, and the compo-
nents are listed in columns.
Once all of the concepts are defined, ToscanaJ is used
again to automatically generate the concept lattice shown in
Figure 24. Note that the nodes associated with objects are
larger than the nodes only associated with concepts for ease
of visualization. At the top of Figure 24 are the design
artifacts that are common throughout the whole product
family. In this case, six concepts are identified: has Arm,
has Arm retainer, has Back panel, has Identification label,
has Shutter, and has Shutter cover. In other words, these six
concepts tell us that all the cameras have an arm, an arm
retainer, a back panel, an identification label, a shutter, and
a shutter cover.
To demonstrate the product-based approach to redesign,
consider two cameras: the MAX Flash and the Advantix
Switchable. The algorithm presented in Figure 13b first rec-
ommends making the Shutter common between the two
products ~by using Shutter:vs1 in both cameras!. In the cur-
rent design, the two products both use a shutter, but two
different instances exist. Implementing these recommenda-
tions will remove the concept Shutter:vs3 and will move
the Advantix Switchable under the node where Shutter:vs1
is located.
Meanwhile, the component-based approach seeks to reuse
critical component instances throughout a product family
while giving preference to making variant components com-
mon over unique components variant. Consider the Arm as
an example. We see that all the cameras have an arm ~the
concept has Arm is found in the top node!.Ifwenowgo
down into the graph, two concepts are found for the Arm:
Arm:va1 and Arm:va2. Below the node where Arm:va1 is
found, we identify six products: MAX Outdoor, MAX Flash,
MAX HQ, Black & White, Plus Digital, and MAX Water &
Sport, whereas there is only one product below the node
Arm:va2 ~Advantix Switchable!. The recommendation is to
change Arm:va2 to Arm:va1, if possible. Note that no other
consideration except the algorithm presented in Figure 13a
is used here, and other constraints, such as the cost of the
Fig. 22. The function component matrix for the Water & Spor t camera.
188 J. Nanda et al.
components, could affect the recommendation. Similarly,
all the other components can be chosen, and the same algo-
rithm can be applied.
Table 3 shows the results of using the five commonality
indices mentioned in Section 3.3.1: DCI, TCCI, CI, PCI,
and CMC. For the component-based approach, the focus is
on making the arm common throughout the family. For the
product-based approach, the shutter is made common
between the two cameras concerned. The resulting changes
to the commonality indices are noted in the table. Note that
all increases are positive, and in many cases identical between
the two approaches. This is because most of indices are
simply component based, that is, making one additional
component common, be it the shutter or the arm, has the
same effect regardless of which component is changed;
meanwhile, more comprehensive indices such as the CMC
Fig. 23. The product family components analyzed in this study.
Fig. 24. The concept lattice for the one-time-use camera. @A color version of this figure can be viewed online at www.journals.
cambridge.org#
Product family design knowledge representation 189
also take the cost of components into account, rewarding
commonality decisions based on the cost savings that result
~Thevenot & Simpson, 2006b!.
5. CONCLUSIONS AND FUTURE WORK
Representing product families in a knowledge base by pre-
conceived common ontologies shows promise in promot-
ing component sharing across multiple products in a family,
while assisting search and exploration of linguistic and
parametric design information over various phases of the
product realization process. Unlike unstructured design
information, the taxonomic generalization as well as par-
tonomic aggregations captured as part of structured OWL
ontologies provides the designer much greater control over
the depth and breadth of the semantic graph that needs to
be analyzed for product family design decision making.
Product vector and function component mapping matrices
along with the common ontologies are utilized for designer
initiated information exploration, aggregation, and analy-
sis. Use of FCA in the development of the NBOM and
application of commonality indices provide a systematic
way for redesigning existing product families to increase
commonality within a product family. Recent develop-
ments with the UMR Design Repository ~a PostgrsSQL
database used to store the design artifact instances! are
also presented. The use of OWL for metadata representa-
tion facilitates data access across proprietary software pro-
grams and computational platforms. An example involving
a family of seven one-time-use cameras is presented to
demonstrate implementation of the three steps of the pro-
posed knowledge management framework.
Future work involves incorporating more low-level design
features and additional information ~e.g., process planning
and assembly! into the knowledge management frame-
work. We also plan to exploit the semantic descriptions
within the OWL ontologies more, as it is backed by DL
~Baader et al., 2003!, which makes it easier for computers
to interpret. Finally, as the product platform design ontolo-
gies grow, we will also explore inference as a tool for auto-
matic design information interpretation as well as the
appropriate level of granularity when analyzing large-scale
complex systems.
ACKNOWLEDGMENTS
This work was funded by the National Science Foundation under
Grants IIS-0325402, IIS-0325321, IIS-0325415, and DMI-0133923.
Any opinions, findings, and conclusions or recommendations pre-
sented in this paper are those of the authors and do not necessarily
reflect the views of the National Science Foundation.
REFERENCES
Baader, F., Calvanese, D., McGuinness, D., Nardi, D., & Patel-Schneider,
P. ~2003!. The Description Logic Handbook: Theory, Implementation
and Applications. Cambridge: Cambridge University Press.
Becker, P. ~2004!. Numerical analysis in conceptual systems with ToscanaJ.
Concept Lattices: Second Int. Conf. Formal Concept Analysis (ICFCA),
pp. 96–103, Sydney, Australia.
Bohm, M.R., Stone, R.B., Simpson, T.W., & Steva, E.D. ~2006!. Introduc-
tion of a data schema: the inner workings of a design repository. ASME
Int. Design Engineering Technical Conf. Computers and Information
in Engineering Conf., Paper No. DETC20060CIE-99518, Philadel-
phia, PA.
Bohm, M.R., Stone, R.B., & Szykman, S. ~2005!. Enhancing virtual prod-
uct representations for advanced design repository systems. Journal of
Computer Information Science in Engineering 5(4), 360–372.
Boothroyd, G., & Dewhurst, P. ~2002!. Product Design for Manufacture
and Assembly, 2nd ed., rev. New York: Marcel Dekker.
Bourke, R. ~1999!. Product information management: product lifecycle
management in complex industries, MidRange ERP. Accessed at http:00
industrydirections.com0midrange0rb0499.htm
Burmeister, P. ~2003!. Formal Concept Analysis With CONIMP: Introduc-
tion to the Basic Features. Darmstadt, Germany: Darmstadt University
of Technology, Department of Mathematics.
Clark, K.G., Ed. ~2005!. SPARQL protocol for RDF. World Wide Web Con-
sor tium. Accessed at http:00www.w3.org0TR02005 0WD-rdf-sparql-
protocol-200505270
Collier, D.A. ~1981!. The measurement and operating benefits of compo-
nent par t commonality. Decision Sciences 12(1), 85 –96.
Daconta, M.C., Obrst, L.J., & Smith, K.T. ~2003!. The Semantic Web: A
Guide to the Future of XML, Web Services, and Knowledge Manage-
ment. Indianapolis, IN: Wiley.
Davies, J., Fensel, D., & van Harmelen, F. ~2003!. Towards the Semantic
Web: Ontology-Driven Knowledge Management. West Sussex: Wiley.
Denny, M. ~2004!. Ontology Tools Survey, Revisited. O’Reilly. XML.com.
Accessed at http:00www.xml.com0pub 0a02004 0070140onto.html
Dixon, J.R., & Poli, C. ~1999!. Engineering design & design for manufac-
turing: A structured approach. Conway, MA: Field Stone Publishers.
Douglas, K., & Douglas, S. ~2003!. PostgreSQL, 1st ed. Indianapolis, IN:
Sams.
Duquenne, V., Chabert, C., Cherfouh, A., Delabar, J.-M., Doyen, A.-L., &
Pickering, D. ~2001!. Structuration of phenotypes0genotypes through
Galois lattices and implications. Int. Workshop on Concept Lattice-
Based Theory, Methods and Tools for Knowledge Discovery in Data-
bases, Stanford University, Stanford, CA.
Erné, M., Koslowski, J., Melton, A., & Strecker, G.E. ~1991!. A primer on
Galois connections. Proc. Summer Conf. General Topology and Appli-
cations in Honor of Mary Ellen Rudin and Her Work, pp. 103–125,
Madison, WI.
Fernandez-Manjon, B., & Fernandez-Valmayor, A. ~1998!. Building edu-
cational tools based on formal concept analysis. Education and Infor-
mation Technologies 3(3), 187–201.
Fikes, R., Hayes, P., & Horrocks, I. ~2003!. OWL-QL—A Language for
Deductive Query Answering on the Semantic Web. Palo Alto, CA:
Stanford University, Knowledge Systems Laboratory.
Ganter, B., & Wille, R. ~1999!. Formal Concept Analysis: Mathematical
Foundations. Heidelberg: Springer–Verlag.
Gennari, J.H., Tu, S.W., Rothenfluh, T.E., & Musen, M.A. ~1994!. Map-
ping domains to methods in support of reuse. International Journal of
Human–Computer Studies 41(3), 399– 424.
Tab le 3. Commonality within camera family before and after
redesign recommendations
Before
Redesign
Product-Based
Redesign
Component-Based
Redesign
CI 0.568 0.574 ~⫹1.06%! 0.574 ~⫹1.06%!
DCI 1.861 1.880 ~⫹1.02%! 1.880 ~⫹1.02%!
TCCI 0.465 0.4706 ~⫹1.20%! 0.4706 ~⫹1.20%!
PCI 54.000 54.500 ~⫹0.91%! 54.500 ~⫹0.91%!
CMC 0.500 0.512 ~⫹2.37%! 0.539 ~⫹7.73%!
190 J. Nanda et al.
Godin, R., & Mili, H. ~1993!. Building and maintaining analysis-level
class hierarchies using Galois lattices. Proc. Eighth Annual Conf. Object-
Oriented Programming Systems, Languages, and Applications, pp. 394–
410, Washington, DC.
Godin, R., Missaoui, R., & April, A. ~1993!. Experimental comparison of
navigation in a galois lattice with conventional information retrieval meth-
ods. International Journal of Man–Machine Studies 38(5), 747–767.
Gratzer, G.A. ~1998!. General Lattice Theory. Boston: Birkhäuser.
Groh, B., Strahringer, S., & Wille, R. ~1998! . Toscana-systems based on
thesauri, conceptual structures: theory, tools and applications. 6th Int.
Conf. Conceptual Structures (ICCS’98), pp. 127–138, Montpellier,
France.
Hatvany, J., Newman, W.M., & Sabin, M.A. ~1993!. World survey of
computer-aided design. Computer Aided Design 25(12), 776–798.
Hir tz, J., Stone, R., McAdams, D., Szykman, S., & Wood, K. ~2002!.A
functional basis for engineering design: reconciling and evolving pre-
vious efforts. Research in Engineering Design 13(2), 65– 82.
Iwasaki, Y., & Chandrasekaran, B. ~1992!. Design verification through
function and behavior-oriented representations: bridging the gap between
function and behavior. Second Int. Conf. Artificial Intelligence in Design,
Pittsburgh, PA.
Kirschman, C., & Fadel, G.M. ~1998!. Classifying functions for mechan-
ical design. ASME Journal of Mechanical Design 120(3), 475– 482.
Koivunen, M.-R., & Miller, E. ~2001!. W3C Semantic Web activity. World
Wide Web Consortium. Accessed at http:00www.w3.org020010120
semweb-fin0w3csw
Kota, S., Sethuraman, K., & Miller, R. ~2000!. A metric for evaluating
design commonality in product families. ASME Journal of Mechanical
Design 122(4), 403 – 410.
Kur toglu, T., Campbell, M.I., Bryant, C.R., Stone, R.B., & McAdams,
D.A. ~2005!. Deriving a component basis for computational functional
synthesis. Int. Conf. Engineering Design (ICED05), Melbourne,
Australia.
Kuznetsov, S.O. ~2001!. Machine learning on the basis of formal concept
analysis. Automation and Remote Control 62(10), 1543–1564.
Liao, S.-H. ~2003!. Knowledge management technologies and
applications—literature review from 1995 to 2002. Expert Systems
with Applications 25(2), 155–164.
Lindig, C. ~1995!. Concept-based component retrieval. Int. Joint Conf.
Artificial Intelligence: Formal Approaches to the Reuse of Plans, Proofs,
and Programs (IJCAI-95), Montreal, Canada.
Mar tin, M.V., & Ishii, K. ~1997 !. Design for variety: development of com-
plexity indices and design charts. 1997 ASME Design Engineering
Technical Conf. Design for Manufacturability, Paper No. DETC970
DFM-4359, Sacramento, CA.
McBride, B. ~2002!. Jena: a semantic web toolkit. In IEEE Internet Com-
puting, pp. 55–59.
McGuinness, D.L., & van Harmelen, F. ~2004!. OWL web ontology
language overview. Recommendation. World Wide Web Consor-
tium. Accessed at http:00www.w3.org 0TR020040REC-owl-features-
200402100
Miller, L., Seaborne, A., & Reggiori, A. ~2002!. Three Implementations of
SQUISHQL . A Simple RDF Query Language. Bristol: Hewlett–
Packard, Information Infrastructure Laboratory.
Murdock, J.W., Szykman, S., & Sriram, R.D. ~1997!. An information mod-
eling framework to support design databases and repositories. ASME
Design Engineering Technical Conf., Paper No. DETC970DFM-4373,
Sacramento, CA.
Nanda, J., Simpson, T.W., Shooter, S.B., & Stone, R.B. ~2005a!. A unified
information model for product family design management. ASME Int.
Design Engineering Technical Conf. Computers and Information in
Engineering Conf., Long Beach, CA.
Nanda, J., Thevenot, H., & Simpson, T.W. ~2005b!. Product family repre-
sentation and redesign: increasing commonality using formal concept
analysis. ASME Int. Design Engineering Technical Conf. Computers
and Information in Engineering Conf., Paper No. DETC2005 0
DAC84818, Long Beach, CA.
Nanda, J., Thevenot, H.J., & Simpson, T.W. ~2005c!. Product family design
knowledge representation, integration, and reuse. IEEE Int. Conf. Infor-
mation Reuse and Integration, pp. 32–37, Las Vegas, NV.
Nanda, J., Simpson, T.W., Kumara, S.R.T., & Shooter, S.B. ~2006!. Prod-
uct family ontology development using formal concept analysis and
web ontology language. ASME Journal of Computing and Information
Science in Engineering 6(1), 103–113.
Nourine, L., & Raynaud, O. ~1999!. Fast algorithm for building lattices.
Information Processing Letters 71(5–6), 199–204.
Noy, N.F., Sintek, M., Decker, S., Crubézy, M., Fergerson, R.W., & Musen,
M.A. ~2001!. Creating semantic web contents with Protégé-2000. IEEE
Intelligent Systems 16(2), 60–71.
Otto, K.N., & Wood, K.L. ~2001!. Product Design: Techniques in Reverse
Engineering and New Product Development. Upper Saddle River, NJ:
Prentice–Hall.
Priss, U. ~2003!. Linguistic applications of formal concept analysis. Proc.
First Int. Conf. Formal Concept Analysis (ICFCA’03), Darmstadt,
Germany.
Saaksvuori, A., & Immonen, A. ~2003!. Product Lifecycle Management.
Heidelberg: Springer–Verlag.
Shooter, S.B., Keirouz, W.T., Szykman, S., & Fenves, S.J. ~2000!. A model
for the flow of design information in product development. Journal of
Engineering with Computers 16(3–4), 178–194.
Shooter, S.B., Simpson, T.W., Kumara, S.R.T., Stone, R.B., and Terpenny,
J.P. ~2005!. Toward a multi-agent information infrastructure for prod-
uct family planning and mass customization. International Journal of
Mass Customization 1(1), 134–155.
Siff, M., & Reps, T. ~1997!. Identifying modules via concept analysis.
IEEE Int. Conf. Software Maintenance, pp. 170–179, Bari, Italy.
Simpson, T.W. ~2004!. Product platform design and customization: status
and promise. Artificial Intelligence for Engineering Design, Analysis
and Manufacturing 18(1), 3 –20.
Szykman, S., Racz, J., Bochenek, C., & Sriram, R.D. ~2000!. Web-based
system for design ar tifact modeling. Design Studies 21(2), 145–165.
Thevenot, H.J., & Simpson, T.W. ~2006a!. Commonality indices for prod-
uct family design: a detailed comparison. Journal of Engineering Design
17(2), 99 –119.
Thevenot, H.J., & Simpson, T.W. ~2006b!. A comprehensive metric for
evaluating commonality in a product family. ASME Int. Design Engi-
neering Technical Conf. Computers and Information in Engineering
Conf., Paper No. DETC2006-DAC99268, Philadelphia, PA.
Tilley, T. ~2004!. Tool support for FCA, concept lattices. Second Int.
Conf. Formal Concept Analysis (ICFCA), pp. 104–111, Sydney,
Australia.
Ulrich, K.T., & Eppinger, S.D. ~2004!. Product Design and Development.
New York: McGraw–Hill0Irwin.
Valtchev, P., Missaoui, R., & Lebrun, P. ~2002!. A partition-based approach
towards constructing Galois ~concept! lattices. Discrete Mathematics
256(3), 801–829.
van der Vegte, W.F., Kitamura, Y., Mizoguchi, R., & Horváth, I. ~2002!.
Ontology-based modeling of product functionality and use—part 2:
considering use and unintended behavior. Proc. EdiPROD Conf.,
pp. 115–124.
Vogt, F., & Wille, R. ~1995!. Toscana— a graphical tool for analyzing and
exploring data. Proc. DIMACS Int. Workshop on Graph Drawing,
pp. 226–233, Princeton, NJ.
Wacker, J.G., & Trelevan, M. ~1986!. Component part standardization: an
analysis of commonality sources and indices. Journal of Operations
Management 6(2), 219 –244.
Jyotirmaya Nanda is a Research Scientist at Intelligent
Automation, Inc., Rockville, MD. He obtained his his MS
degree in industrial engineering from Penn State University
in 2002, his BE in mechanical engineering from Visves-
varaya National Institute of Technology, Nagpur, India, in
1998, and his doctorate in industrial engineering with a
minor in high performance computing at Penn State Uni-
versity with Dr. Timothy W. Simpson in 2006. Dr. Nanda’s
research interests are in mass customization, knowledge man-
agement using ontologies, autonomic agent systems, and
design optimization.
Henri J. Thevenot is a Fixed-Term Instructor and a Post-
doctoral Research Associate working in product family
Product family design knowledge representation 191
design at Penn State University. He received his MS degree
in industrial engineering from both Ecole Centrale de Lyon
~France! and Penn State University in 2004 and his PhD
degree in industrial engineering from Penn State University
in 2006. Dr. Thevenot is currently developing tools and
methods for product family design and redesign in the con-
text of globalization and innovation. He is also interested in
developing tools and methods to help designers in the early
stage of the product design process.
Timothy W. Simpson is a Professor of mechanical and
industrial engineering and engineering design and the Direc-
tor of the Product Realization Minor at Penn State Univer-
sity. He received his BS ~1994! in mechanical engineering
from Cornell University and his MS ~1995! and PhD ~1998!
degrees in mechanical engineering from Georgia Tech. His
research and teaching interests include product family and
product platform design, product dissection and concurrent
engineering, and visualization methods. Dr. Simpson is a
member of the ASME Design Automation Executive Com-
mittee and the AIAA Multidisciplinary Design Optimiza-
tion Technical Committee.
Robert B. Stone is an Associate Professor in the Interdisci-
plinary Engineering Department and the Director of the
Student Design and Experiential Learning Center at the Uni-
versity of Missouri–Rolla. He joined the faculty in 1998
after completing his PhD in mechanical engineering from
the University of Texas at Austin. Prior to academia, he
worked as a Space Shuttle Flight Controller at NASA-Johnson
Space Center. He assisted in creating the design-focused in-
terdisciplinary engineering degree program. Dr. Stone’s
research interests include design theories and methodolo-
gies, specifically product architectures, functional represen-
tations, and automated conceptual design techniques. He has
authored chapters on product architecture in design texts.
Matt Bohm is currently a PhD student. He is performing
research with the Interdisciplinary Engineering Depar t-
ment and is a student in the Systems Engineering Depart-
ment. He joined the Interdisciplinary Engineering
Department as an undergraduate Researcher in December
2001 while working on a bachelors degree in mechanical
engineering. After finishing his bachelors degree he contin-
ued performing research in the area of conceptual design
and design information storage while working toward a mas-
ters degree in mechanical engineering.
Steven B. Shooter is an Associate Professor of mechanical
engineering at Bucknell University where he has taught
since 1995. He is a registered professional engineer in the
state of Pennsylvania and has been the principal investiga-
tor on numerous projects with industry involving new prod-
uct development and the design of production infrastructure.
Dr. Shooter has been a Researcher at NIST in the Design
Engineering Technologies Group, a Visiting Professor at
the Swiss Federal Institute of Technology in Lausanne
~EPFL!, and a Process Engineer for Sony Music Corpora-
tion. His research interests involve information manage-
ment for design and the design of mechatronic systems and
products. Integral to this research is the exploration of
approaches for the capture, storage, and retrieval of product
development information.
192 J. Nanda et al.
