a framework for product platform knowledge management
TRANSCRIPT
The Pennsylvania State University
The Graduate School
Department of Industrial and Manufacturing Engineering
A FRAMEWORK FOR PRODUCT PLATFORM KNOWLEDGE
MANAGEMENT USING THE SEMANTIC WEB PARADIGM
A Thesis in
Industrial Engineering
by
Jyotirmaya Nanda
© 2006 Jyotirmaya Nanda
Submitted in Partial Fulfillment of the Requirements
for the Degree of
Doctor of Philosophy
August 2006
The thesis of Jyotirmaya Nanda was reviewed and approved* by the following:
Timothy W. Simpson Professor of Mechanical and Industrial Engineering Thesis Advisor and Chair of Committee
Soundar R.T. Kumara Distinguished Professor of Industrial Engineering
Richard A. Wysk Professor and Leonhard Chair in Engineering
Lyle N. Long Professor of Aerospace Engineering
Steven B. Shooter Special Member Associate Professor Mechanical Engineering Bucknell University
Richard J. Koubek Professor of Industrial Engineering Head of the Harold and Inge Marcus Department of Industrial and Manufacturing Engineering
*Signatures are on file in the Graduate School
ii
ABSTRACT
The new form of competitive advantage for many companies in today’s global
market place is platform-based product development and customization. For many
engineered products, one of the most critical business processes is managing product data
over the entire product lifecycle. The design information captured by heterogeneous
software systems in proprietary data structures makes it difficult to index, search, refine,
reuse, distribute and browse design artifacts across different organizational information
systems. In this research, simple yet innovative methodologies are developed to (1)
capture and reorganize component design information as a graph model in a Networked
Bill of Material (NBOM) to facilitate both linguistic and parametric design information
management for a family of products, (2) represent and store design information using
ontologies that promote sharing and reuse of components for integrated platform-based
product development across various phases of product design, and (3) perform product
family analysis of the set of products based on linguistic and/or parametric information.
In the proposed methodologies, the components and products of the product family are
represented as a complete lattice structure using Formal Concept Analysis (FCA). The
lattice structure formed using FCA facilitates the creation of the NBOM. The NBOM
and component designs are subsequently encoded using the Web Ontology Language
(OWL), a semantic web standard, to enable automatic processing of information by
different applications. The design of a family of one-time-use cameras and a family of
power tools serve as prototypes for verifying and validating the proposed product
platform knowledge management framework.
iii
TABLE OF CONTENTS
LIST OF FIGURES .....................................................................................................vii
LIST OF TABLES.......................................................................................................x
ACKNOWLEDGEMENTS.........................................................................................xii
Chapter 1 Introduction to Product Platform Knowledge Management ......................1
1.1 Introduction to Product Family and Product Platform Design .......................3 1.2 Product Design Representation and Repositories...........................................6 1.3 Motivation for the Research Motivation.........................................................8 1.4 Research Objectives in the Dissertation .........................................................9 1.5 Outline of the Dissertation..............................................................................10
Chapter 2 Literature Review of Product Platform Design and Knowledge Management .........................................................................................................12
2.1 Existing Product Design Information Management Frameworks ..................12 2.2 Product Family Design Representation ..........................................................13 2.3 Knowledge Management and Ontologies.......................................................15
2.3.1 Methods of Persistent Information Storage..........................................15 2.3.2 Ontologies in Knowledge Representation ............................................16 2.3.3 Methods and Tools for Ontology Development ...................................18
2.4 Semantic Web.................................................................................................19 2.4.1 History and Evolution of the Semantic Web........................................20 2.4.2 Web Ontology Language (OWL).........................................................22
2.5 Formal Concept Analysis (FCA) ....................................................................26 2.5.1 Some Basic Definitions of FCA...........................................................26 2.5.2 Applications of FCA in Different Fields ..............................................30 2.5.3 Software Tools for FCA .......................................................................31
2.6 Summary and Preview....................................................................................32
Chapter 3 Product Platform Design Information Representation and Encoding........33
3.1 Product Family Ontology Development Methodology ..................................33 3.1.1 Step 1: Component Lexicon Acquisition and Pruning .........................34 3.1.2 Step 2: Formal Contexts Composition .................................................35 3.1.3 Step 3: Concept Hierarchy Formulation using FCA ............................36 3.1.4 Step 4: Product Family Ontology Formation and Enrichment using
OWL.......................................................................................................39 3.2 Summary and Preview....................................................................................41
Chapter 4 Product Family Knowledge Sharing ..........................................................43
iv
4.1 Product Family Unified Information Model for Design Representation........43 4.1.1 Step 1: Individual Product Documentation via Dissection...................44 4.1.2 Step 2: Entity List Creation for Each Type of Design Information .....45 4.1.3 Step 3: Common Ontology Layer formation for the Entire Product
Family.....................................................................................................47 4.1.4 Step 4: Mapping between Different Phases of Design Information....48
4.2 Product Family Design Information Aggregation ..........................................50 4.2.1 Step 5a: Product Family Design Information Aggregation Spanning
Multiple Products ...................................................................................52 4.2.2 Step 5b: Product Family Design Information Aggregation across
Phases .....................................................................................................52 4.3 Summary and Preview....................................................................................53
Chapter 5 Product Family Representation and Redesign ...........................................54
5.1 Product Family Representation and Redesign Framework ............................54 5.2 Input: Product Family NBOM........................................................................56
5.2.1 Step 1: Product-Component Formal Context Formation......................56 5.2.2 Step 2: Product Family Representation ................................................58
5.3 Step 3: Approaches to Product Family Redesign ...........................................60 5.3.1 Step 3a: Component-Based Approach to Product Family Redesign....63 5.3.2 Step 3b: Product-Based Approach to Product Family Redesign..........67
5.4 Step 4: Post-Redesign Commonality Analysis ...............................................70 5.4.1 The Degree of Commonality Index (DCI) ...........................................71 5.4.2 The Total Constant Commonality Index (TCCI) .................................72 5.4.3 The Commonality Index (CI) ...............................................................74 5.4.4 Commonality Analysis after Product Family Redesign .......................75
5.5 Summary and Preview....................................................................................75
Chapter 6 Case Study 1: Knowledge Management in a Homogeneous Product Family ...................................................................................................................77
6.1 Introduction to the One-time-use Camera Product Family.............................77 6.2 Product Platform Design Information Representation & Encoding Using
PFODM .........................................................................................................78 6.2.1 Step 1: Camera Component Lexicon Acquisition and Pruning............79 6.2.2 Step 2: Formal Context Composition of the Camera Cover Class.......79 6.2.3 Step 3: Camera Concept Hierarchy Formulation using FCA...............82 6.2.4 Step 4: Camera Family Ontology Formation and Enrichment .............84
6.3 Product Platform Knowledge Sharing Using PFUIM ....................................91 6.3.1 Step 1: Camera Product Family Product Dissection ............................91 6.3.2 Step 2: Camera Product Family Entity List Creation...........................91 6.3.3 Step 3: Camera Product Family Common Ontology Layer
Formation ...............................................................................................92
v
6.3.4 Step 4: Mapping Between Heterogeneous Design Information in Camera Product Family..........................................................................94
6.3.5 Step 5: Kodak Product Family Design Information Aggregation ........96 6.3.5.1 Design Information Aggregation Spanning Multiple Products..97 6.3.5.2 Design Information Aggregation across Design Information
Structures ........................................................................................98 6.4 Product Family Redesign using PFRRF.........................................................98
6.4.1 Kodak Cameras Formal Concept Analysis using ToscanaJ .................99 6.4.2 Component-Based Approach to Redesign the Kodak Cameras ...........102 6.4.3 Product-Based Approach to Redesign the Kodak Cameras .................102 6.4.4 Post-Redesign Commonality Assessment ............................................103
6.5 Discussion and Preview..................................................................................104
Chapter 7 Case Study 2: Knowledge Management in a Heterogeneous Product Family ...................................................................................................................105
7.1 Introduction to the Power Tool Product Family .............................................105 7.2 Product Platform Design Information Representation & Encoding Using
PFODM .........................................................................................................106 7.2.1 Step 1: Component Lexicon Acquisition and Pruning .........................107 7.2.2 Step 2: Formal Context Composition of the Power Tool Cover
Class .......................................................................................................107 7.2.3 Step 3: Concept Hierarchy Formulation using FCA ............................109 7.2.4 Step 4: Power Tools Ontology Formation and Enrichment .................111
7.3 Product Platform Knowledge Sharing Using PFUIM ....................................114 7.3.1 Step 1: Versapak Product Family Product Dissection..........................114 7.3.2 Step 2: Versapak Product Family Entity List Creation ........................115 7.3.3 Step 3: Versapak Product Family Common Ontology Layer
Formation ...............................................................................................116 7.3.4 Step 4: Mapping Between Heterogeneous Design Information in
Versapak Product Family .......................................................................119 7.3.5 Step 5: Versapak Product Family Design Information Aggregation....120
7.4 Product Family Redesign Using PFRRF ........................................................122 7.4.1 Formal Concept Analysis Using ToscanaJ...........................................122 7.4.2 Component-Based Approach to Redesign the Power Tools ................124 7.4.3 Product-Based Approach to Redesign the Power Tools.......................125 7.4.4 Post-Redesign Commonality Assessment ............................................126
7.5 Comparison between Homogeneous and Heterogeneous Product Families ..126 7.6 Discussion and Preview..................................................................................128
Chapter 8 Contributions, Recommendations, and Future Work.................................130
8.1 Research Summary .........................................................................................130 8.2 Contributions from the Research ....................................................................131
8.2.1 Product Family Ontology Development Framework (PFODM)..........131
vi
8.2.2 Product Family Uniform Information Model (PFUIM) .......................132 8.2.3 Product Family Representation and Redesign Framework (PFRRF)...133
8.3 Future Work....................................................................................................134
Bibliography ................................................................................................................137
Appendix A Parts for the Kodak Single-use Camera Product Family........................146
Appendix B Kodak One-time-use Cameras PVM and FCM......................................148
Appendix C Computation of Commonality Indices for Redesigning Cameras..........159
Appendix D Parts for the Black & Decker Versapak Power Tools Product Family ..161
Appendix E Black & Decker Versapak Power Tools PVM and FCM.......................163
Appendix F Computation of Commonality Indices for Redesigning Power Tools....174
Appendix G List of Acronyms....................................................................................177
vii
LIST OF FIGURES
Figure 1-1: Example of product family design strategies and approaches ..................5
Figure 1-2: Product family knowledge management framework ...............................9
Figure 2-1: Methods of persistent information storage...............................................16
Figure 2-2: Semantic web stack [63] ..........................................................................21
Figure 3-1: Product family ontology development methodology (PFODM) .............34
Figure 3-2: NBOM lattice structure............................................................................37
Figure 3-3: Graphical representation of AND-NOT quadrant....................................39
Figure 3-4: Product – Component – Attribute integration..........................................40
Figure 3-5: Mapping between product structure and design ontology .......................40
Figure 4-1: Methodology for creating a PFUIM.........................................................44
Figure 4-2: Entity list for each type of design information and their interrelationship ....................................................................................................47
Figure 4-3: Common ontology layer development for customer needs phase ...........48
Figure 4-4: Product vector matrix for an individual product......................................49
Figure 4-5: Function component matrix for an individual product ............................50
Figure 4-6: Model for product family design information aggregation......................51
Figure 5-1: Product family representation and redesign framework (PFRRF)..........56
Figure 5-2: Two instances of camera flash button......................................................57
Figure 5-3: Visualizing common, variant, and unique components in a Hasse diagram .................................................................................................................59
Figure 5-4: NBOM for the product family cross table example.................................63
Figure 5-5: Component-Based approach for product family redesign .......................65
Figure 5-6: NBOM of the product family after component-based redesign...............66
Figure 5-7: Product-Based approach for product family redesign..............................69
viii
Figure 5-8: NBOM of the product family after product-based redesign ....................70
Figure 5-9: Computational examples for the DCI [106].............................................72
Figure 5-10: Computational examples for the DCI and TCCI [107] ..........................74
Figure 6-1: Entering the kodak:cover context into ToscanaJ .....................................82
Figure 6-2: Concept lattice of the kodak:cover generated by ToscanaJ ....................83
Figure 6-3: AND-NOT quadrant for Kodak camera {Cover} and {Shutter Cover} ..84
Figure 6-4: OWL representation of kodak:cover class ...............................................85
Figure 6-5: Property reference of Kodak camera component class............................86
Figure 6-6: Component class and sub-classes in the Kodak camera ontology ...........86
Figure 6-7: Protégé IDE showing the Kodak camera ontology..................................87
Figure 6-8: Ontology enrichment of kodak:cover class..............................................88
Figure 6-9: Concept lattice of the kodak:camera generated by ToscanaJ ..................89
Figure 6-10: Camera class hierarchy representation using ezOWL ...........................89
Figure 6-11: Sample of the Kodak camera ontology ..................................................90
Figure 6-12: Development of camera ontology from aggregated customer needs.....93
Figure 6-13: Ontology of Kodak one-time-use camera functions ..............................94
Figure 6-14: Kodak Water & Sport camera product vector matrix ...........................95
Figure 6-15: Kodak Water & Sport camera FCM .....................................................96
Figure 6-16: Entering one-time-use camera data in ToscanaJ....................................100
Figure 6-17: Example of entry for a common camera component .............................100
Figure 6-18: Example of entry of a variant camera component .................................100
Figure 6-19: Hasse diagram for the Kodak one-time-use cameras.............................101
Figure 7-1: Black & Decker Versapak product family...............................................106
Figure 7-2: Entering the bd:cover context into ToscanaJ...........................................110
ix
Figure 7-3: Concept Lattice of the bd:cover generated by ToscanaJ .........................111
Figure 7-4: OWL representation of bd:cover class.....................................................112
Figure 7-5: Component class and sub-classes of the power tool ontology.................113
Figure 7-6: Concept Lattice of the Versapak:power tools generated by ToscanaJ ....113
Figure 7-7: Power tool class hierarchy representation using ezOWL ........................114
Figure 7-8: A part of the bill of material for Versapak drill .......................................115
Figure 7-9: Versapak product family entity list creation ............................................116
Figure 7-10: Development of power tool ontology from aggregated customer needs .....................................................................................................................117
Figure 7-11: Ontology of power tool product functions.............................................118
Figure 7-12: Ontology of product family components ...............................................118
Figure 7-13: Versapak drill product vector matrix .....................................................119
Figure 7-14: Versapak drill function component matrix ............................................120
Figure 7-15: Versapak design information aggregation .............................................121
Figure 7-16: Entering Versapak power tool data in ToscanaJ.....................................123
Figure 7-17: Hasse diagram for the Versapak power tool family...............................124
Figure 8-1: Use of Platform Information Model for product family knowledge management ..........................................................................................................134
x
LIST OF TABLES
Table 1-1: Different types of product data [20] ..........................................................7
Table 2-1: OWL DL Constructors, Axioms and Facts [69]........................................25
Table 2-2: Example of a cross table............................................................................28
Table 2-3: Multi-context cross table example ............................................................28
Table 3-1: Pair-wise comparison of classes................................................................38
Table 5-1: Product-Component multi-context cross table ..........................................57
Table 5-2: Cross table of example product family......................................................59
Table 5-3: Example product family cross table ..........................................................62
Table 5-4: Before and after redesigning the example product family ........................75
Table 6-1: Summary of Kodak one-time-use cameras [110]......................................78
Table 6-2: Initial multi context cross table of kodak:cover class ...............................80
Table 6-3: Clarified cross table of kodak:cover class.................................................81
Table 6-4: Kodak Water & Sport one-time-use camera entity list creation ...............92
Table 6-5: Kodak one-time-use cameras and components analyzed in this study .....99
Table 6-6: Commonality indices before and after camera redesign ...........................104
Table 7-1: Initial multi context cross table of bd:cover class.....................................108
Table 7-2: Clarified cross table of bd:cover class ......................................................109
Table 7-3: Black & Decker power tool products and components analyzed in this study......................................................................................................................122
Table 7-4: Commonality indices before and after power tool redesign......................126
Table 7-5: Comparison of methods for homogeneous and heterogeneous product families .................................................................................................................128
Table B-1: Kodak Water & Sport PVM ...................................................................148
Table B-2: Kodak Water & Sport FCM....................................................................149
xi
Table B-3: Kodak Plus Digital PVM........................................................................150
Table B-4: Kodak Plus Digital FCM ........................................................................150
Table E-5: Kodak Black & White PVM...................................................................151
Table B-6: Kodak Black & White FCM...................................................................152
Table B-7: Kodak Advantix Switchable PVM .........................................................153
Table B-8: Kodak Advantix Switchable FCM..........................................................154
Table B-9: Kodak MAX Outdoor PVM ...................................................................155
Table B-10: Kodak MAX Outdoor FCM..................................................................155
Table B-11: Kodak MAX Flash PVM......................................................................156
Table B-12: Kodak MAX Flash FCM ......................................................................156
Table B-13: Kodak MAX HQ PVM.........................................................................157
Table B-14: Kodak MAX HQ FCM .........................................................................158
Table E-1: Versapak Drill PVM ................................................................................163
Table E-2: Versapak Drill FCM ................................................................................164
Table E-3: Versapak Circular Saw PVM...................................................................165
Table E-4: Versapak Circular Saw FCM...................................................................166
Table E-5: Versapak Flashlight PVM........................................................................167
Table E-6: Versapak Flashlight FCM........................................................................167
Table E-7: Versapak Reciprocating Saw PVM .........................................................168
Table E-8: Versapak Reciprocating Saw FCM..........................................................169
Table E-9: Versapak Rotary Tool PVM ....................................................................170
Table E-10: Versapak Rotary Tool FCM...................................................................171
Table E-11: Versapak Screwdriver PVM ..................................................................172
Table E-12: Versapak Screwdriver FCM ..................................................................173
xii
ACKNOWLEDGEMENTS
I am deeply indebted to Professor Timothy W. Simpson for his encouragement,
advice, mentoring, and research support throughout my master's and doctoral studies. I
am especially grateful to him for giving me the freedom to explore different areas of
research and his guidance in helping me understand the different problems in product
family design.
I would also like to thank my committee who distinguish themselves through both
brilliant scholarship and exceptional teaching: Professor Soundar R.T. Kumara, Professor
Richard A. Wysk, Professor Lyle L. Long, and Dr. Steven B. Shooter (Bucknell
University), for their help, encouragement, and valuable feedback in this work; without
their contributions it would not have been possible.
I also wish to thank the following people for their assistance with this research:
Dr. Robert B. Stone (University of Missouri-Rolla), Dr. Janis P. Terpenny (Virginia
Tech), Dr. Mary Frecker, and my peers: Jaeil, Henri, Fabrice, and Esli, along with the
many NSF REU (Research Experiences for Undergraduates) students who helped gather
data for the design repository.
I would also like to gratefully acknowledge support from the National Science
Foundation under Grant Nos. IIS-0325402 and DMI-0133923. Any opinions, findings,
and conclusions or recommendations presented in this dissertation are mine and do not
necessarily reflect the views of the National Science Foundation.
xiii
I also want to extend my words of thanks to everyone in the Engineering Design
and Optimization Group. They were supportive and friendly, and they showed me the
beauty of being in a research group.
I would like to thank Dr. Kannan Govindrajan, Kevin Wilkinson, Dr. Harumi
Kuno, Kei Yusa, and Kevin Smathers who supported me in extending my research at
Hewlett-Packard labs, Palo Alto during Summer 2005.
I am indebted to my good friends whose understanding, example, and
encouragement inspire me to achieve higher goals. I truly hold dear their friendships. I
appreciate all the interesting and endless discussions we had concerning my research and
many other things.
I would also like to gratefully acknowledge my elementary and secondary school
teachers for providing me the sound foundation upon which I could realize my dream.
A very special thanks go to my relatives for their comfort and encouragement.
I owe special thanks to my parents, my lovely wife Anupama and my little brother
Debasis. They had made me believe that I can do anything I want and never stop having
faith in me. Their unconditional love and support throughout my life is immeasurable,
and I am forever indebted to that.
Last, but not the least, thank you GOD for everything.
xiv
To My Parents
Chapter 1
Introduction to Product Platform Knowledge Management
Product representation schemes and design repositories have progressed
remarkably in the past decade to facilitate platform-based product development and
product family design to support mass customization [1]. In engineered products, one of
the most critical business processes is managing product and process data over the total
product lifecycle [2]. Developing complex, customized products requires timely,
accurate design information be exchanged between designers who are usually distributed
across space and time. As design becomes increasingly knowledge-intensive and
collaborative, the need for computational design frameworks to support sharing of
knowledge among distributed designers becomes more critical [3]. In addition to sharing
and exchanging information, pressure 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 [3]. In order for
designers to create or develop better designs in a limited time, they need more than the
geometric data and its associated documentation while designing a product. A
computational framework that can capture the design process and the associated
knowledge is driving the research in the area of design repositories - knowledge bases of
heterogeneous product design information that can be searched and reused [4].
The objective in this research is to develop a flexible Knowledge Management
System that can capture both linguistic and parametric product design information to
facilitate systematic development, deployment, and management of multiple product
2
families using an open data structure during the early phases of product family design.
Simple yet innovative methodologies are developed to: (1) capture and reorganize
product design information as a graph model in a Networked Bill of Material (NBOM) to
facilitate both linguistic and parametric design information management for a family of
products, (2) represent and store design information using ontologies that promote
sharing and reuse of design information for integrated platform-based product realization
across the various phases of product design, and (3) perform product family analysis of
the set of products based on linguistic and/or parametric information during the early
stages of product family design which comprises of engineering conceptual design and
configuration design of parts [5]. This chapter is dedicated to describing the foundation
for developing these methods.
Section 1.1 introduces product family and product platform design to provide a
background and context for the current research. Current product design representations
and repositories are discussed in Section 1.2 to provide an introduction to the
fundamental concepts employed throughout the dissertation. Section 1.2 also motivates
the need for research in Knowledge Management Systems to support platform-based
product development. Research questions, hypotheses, and contributions from the
research are presented in Section 1.3. In Section 1.4, the chapter concludes with an
overview of the dissertation.
3
1.1 Introduction to Product Family and Product Platform Design
A product family is defined as a set of individual products that share common
technology yet address a related set of market application [6]. In general terms, a product
family is a group of related products that is derived from a product platform by sharing
and scaling common features, components, and subsystems to satisfy a variety of market
niches. A product platform can be either narrowly or broadly defined as:
• “a set of common components, modules, or parts from which a stream of
derivative products can be efficiently developed and launched” [6], or
• “the collection of assets [i.e., components, processes, knowledge, people and
relationships] that are shared by a set of products” [7].
Manufactures are primarily using product families to reduce part inventory, reduce
procurement costs, and be more capable of handling volatility in consumer demand while
increasing the diversity of their product offerings.
The key to a successful product family is platform-based product development
where platform variants are derived either by adding, removing, or substituting one or
more modules to the platform or by scaling the platform in one or more dimensions to
target specific market niches [1]. Thus there are two basic design strategies when
designing product families: (1) module-based product family design and (2) scale-based
product family design. In a module-based product family, products are made from a
common platform by combining distinct modules with common interfaces. The merit of
module-based product family design is that the modules can be easily changed without
necessarily affecting the design of other modules and adding tremendous complexity to a
4
manufacturing system when design variety is required [8]. Sony Walkmans [9], Hewlett
Packard printers [10], Nippondenso Co. Ltd. automotive components [11] and Bally
Engineering Structures environmentally-controlled structures [12] are some of the better
known examples of module-based product families. In a scale-based product family,
products are realized by scaling or stretching the platform in one or more dimensions to
satisfy a variety of market niches. Platform scaling is a common strategy employed by
many companies. Some of the better known examples include the 737-X and 777-X
commercial airplanes by Boeing [13], the “World Car” of Honda [14], the RTM322
aircraft engine of Rolls Royce [15], and the universal electric motors of Black & Decker
[6,16].
There are mainly two approaches for developing either a module-based product
family or scale-based product family: (1) a top-down (pro-active platform) approach and
(2) a bottom-up (reactive redesign) approach. The top-down approach involves
strategically managing and developing a new product platform from which a family of
products is then derived. Sony Walkmans [9] and Hewlett Packard printers [10] provide
the two examples of the top-down approach of developing a product family. The bottom-
up approach entails redesign or consolidation of existing components resulting in the
commonality or standardization of product components with improved economies of
scale and thus either creating or improving a product platform. Nippondenso Co. Ltd.
automotive components [11] and the universal electric motors of Black & Decker [6,16]
are examples of the bottom-up approach. Figure 1-1 summarizes the examples for each
approach and strategy for product family design.
5
A design (noun) comprises information that can be in many forms [17]. A
designed artifact has many different 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. During the early phases of product
development, product design information remains rather incomplete and is often also
inconsistent [18]. As the design evolves, the accompanying information is represented at
different levels of abstraction [19].
In addition to the information captured during the different phases of product
design, product family design has the added complexity of managing design information
across multiple products. Collaborative design in such a heterogeneous and distributed
design environment mandates the unambiguous sharing of design information.
Successful product family planning places a even greater emphasis on effective
Figure 1-1: Example of product family design strategies and approaches
6
information management to exploit the potential of shared assets [1]. By sharing assets
such as components, processes and knowledge across a family of products, companies
can efficiently develop differentiated products and increase the flexibility and
responsiveness of their product realization processes. Product design repositories
facilitate product design information management as discussed in the next section.
1.2 Product Design Representation and Repositories
The complexities of modern products require expertise in a broad range of
disciplines during design and development. Design repositories make use of research in
knowledge-based design to capture design processes, design rules, constraints, rationale,
etc., which helps in reduction of product design and development time.
The complexity in managing a product’s structure and associated information
increases in a distributed design environment where the use of different software systems
is common. Due to past limitations in information technology capabilities, product
information management systems often evolved in an uncoordinated fashion, resulting in
islands of automation that do not easily communicate with each other. Many design
representation formats evolved to capture product design information across different
phases of the product realization process. Existing product design information systems
produce output in one or more of the standards summarized in Table 1-1.
7
Traditional computer-aided design (CAD) models help in capturing parametric
information and geometric constraints of components in a design process. New
generations of product data management (PDM) tools help capture some types of non-
geometric knowledge along with basic parametric information like manufacturing
processes, bills of materials, inventory, etc., but these systems often lack an open way of
capturing a formal product representation that includes function, behavior, and structure
of a product. These systems also focus primarily on database related issues while
ignoring information models for engineering artifact representation [3]. As an example,
the lack of a formal product representation that includes function, behavior and structure
has been identified by Bilgic and Rock [21] as a shortcoming of existing PDM systems.
The burgeoning proprietary standards for product design information storage
make it difficult to integrate and thus reuse component design information across an
enterprise. A computational framework that can capture the design process and the
associated knowledge is driving the research in the area of design repositories -
Table 1-1: Different types of product data [20]
8
knowledge bases of heterogeneous product design knowledge that can be searched and
reused [4]. A review of existing design repositories is presented in Section 2.1.
1.3 Motivation for the Research Motivation
In current practice, information captured during the early stages of product design
is often idiosyncratic, incomplete, and is mostly unstructured. Unarticulated design
information at various phases of the product realization process is seldom captured in a
way that can lead to cohesive aggregation, visualization, and ultimately product family
analysis. Even articulated parametric design information, widely captured by multiple
software systems, is normally encapsulated in proprietary data structures. Data captured
in proprietary data structures hinders seamless collaboration between cross-functional
team members both inside and outside of an organization and makes it difficult to index,
search, refine, reuse, distribute, browse, and aggregate design information across
heterogeneous organizational information systems. Towards this end, a flexible
Knowledge Management System that can capture both linguistic and parametric product
design information to facilitate systematic development, deployment and management of
multiple product families, during the early stages of design, using an open data structure
is critical. The use of open data structures is necessary to promote flexible, seamless and
automatic integration and extension of spatially dispersed design information captured in
disparate software systems. Formal Concept Analysis, Ontologies, Semantic Web
standards, and product family commonality analysis are the fundamental techniques on
which this research is built as discussed in Chapter 2.
9
1.4 Research Objectives in the Dissertation
The primary objective in this research is to facilitate the development of a flexible
Knowledge Management System that can capture both linguistic and parametric product
design information for systematic development, deployment, and management of
multiple product families using an open data structure during the early stages of product
family design. To manage the design knowledge associated with a group of related
products, the proposed Product Family Knowledge Management System in this
dissertation is shown in Figure 1-2.
There are three main parts to the proposed knowledge management system:
Figure 1-2: Product family knowledge management framework
10
(1) A systematic methodology, called the Product Family Ontology
Development Methodology (PFODM), is developed using Formal
Concept analysis to convert product family design information into a
unified network, called a Networked Bill of Material (NBOM). 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.
(2) A uniform information model, called the Product Family Uniform
Information Model (PFUIM), is developed using the preconceived product
family ontologies 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.
(3) A product family redesign framework, called the Product Family
Representation and Redesign Framework (PFRRF), is introduced to
support component redesign to increase commonality in existing product
families.
Two product families - Kodak one-time-use cameras and Black & Decker power tools are
used to demonstrate and validate the proposed methodologies in Chapters 6 and 7.
1.5 Outline of the Dissertation
In Chapter 2 the literature review for product platform knowledge management is
presented. In Chapter 3 the product platform ontology development methodology
11
(PFODM) is introduced. In Chapter 4 the product family unified information model
(PFUIM) is presented. In Chapter 5 the product family representation and redesign
framework (PFRRF) is discussed. To demonstrate and validate the proposed
methodologies, a homogeneous family of one-time-use cameras is presented in Chapter
6, followed by a heterogeneous family of power tools in Chapter 7. Chapter 8 gives
closing remarks and future work.
Chapter 2
Literature Review of Product Platform Design and Knowledge Management
The complexities of modern products require expertise in a broad range of
disciplines for design and development. Design repositories make use of research in
knowledge-based design to capture design processes, design rules, constraints, rationale,
etc., which helps in reduction of product design and development time. In this chapter a
review of the existing product design information management frameworks and product
family representation schemes is presented in Sections 2.1 and 2.2. Section 2.3 covers
knowledge management and ontologies, Section 2.3 presents Semantic Web and Web
Ontology Language, and Section 2.4 introduces the fundamentals of formal concept
analysis.
2.1 Existing Product Design Information Management Frameworks
The problems associated with the growing complexity of engineering design and
tactics for tackling this complexity have been discussed by Bhatta and Goel [22]. Since
modern engineering design can involve so many different parameters, they cite
‘analogical design’ as a way of overcoming these problems. Kirschman, et al. [23]
proposed a taxonomy of elemental mechanical functions that can be used with many
decomposition techniques. The taxonomy proposed a common language for designers to
refer to the same function but was limited in its vocabulary and was short of a neutral
13
format of capturing the information. Iwassaki and Chandrasekaran [24] focused on the
task of design verification using both knowledge of the structure of a device and its
intended functions. The National Institute of Standards and Technology (NIST) is
involved in development of an intelligent design repository, based on Data Language and
a Design Representation Language [3,25]. Shooter, et al. [19] presented a model for the
flow of design information that is sufficiently formal to eventually support a semantics-
based approach for developing information exchange standards. More recently, the
design repository at the University of Missouri – Rolla, following NIST’s approach
toward neutral data exchange, has implemented a XML-based approach [4] to import and
export the product knowledge from the design repository. In a related domain of
modeling process flows, Bock and Gruninger [26] at NIST have proposed the use of
Process Specification Language (PSL) for describing the semantics of manufacturing
processes using first order logic notations. Commercial Software packages like
Unigraphics1, 3SL – Cradel2, Nu Thena Systems – Foresight3 provide some kind of
hierarchical decomposition of product structure. A detailed analysis of these commercial
products can be found in Ref. [4].
2.2 Product Family Design Representation
The ability to define design artifacts in a way that makes it easy to manage
information about the product during all phases of the product life cycle is crucial for
1 http://www.ug.eds.com/ug/ 2 http://www.threesl.com 3 http://www.nuthena.com
14
product-oriented organizations. NEWTON, an expert problem solver developed by de
Kleer [27] uses multiple-representations of design knowledge, such as envisioning,
qualitative, quantitative, and mathematical, for problem solving. Geer, et al. [28] propose
a component basis as the framework for the development of a standard naming
convention of mechanical parts. The component basis uses a lexical scheme to identify
major categories, to define classification terms for mechanical components. Stahovich, et
al. [29] developed an ontology of mechanical devices by emphasizing common patterns
of behavior of mechanical components over structural representation. Stahovich, et al.
[30] developed a program called SketchIT that employs a paradigm of abstraction and
resynthesis based on qualitative configuration space. Nahm and Ishikawa [31] describe an
integrated product and process modeling framework for the collaborative product design.
In Axiomatic Design [32], the design space is divided into four domains: the customer
domain, the functional domain, the physical domain, and the process domain.
The use of different software systems in a collaborative design environment
increases the complexity of managing product structures and the associated design
information. The observation about the proprietary nature of information captured in the
design phase by Hatvany et al. [33] still holds true. Existing product design information
systems produce output in one or more of the following common standards: the Data
Exchange Format (DXF), Standard for the Exchange of Product Model Data (STEP),
Continuous Acquisition and Life cycle Support (CALS), Initial Graphics Exchange
Specification (IGES), Standard Generic Markup Language (SGML) and Extensible
Markup Language (XML) [34]. Conversion tools among these formats are costly,
application-specific and often lead to uncertainty about data integrity. The limited design
15
information captured by the individual software systems in proprietary data structures
makes it difficult to index, search, and browse design artifacts across the organizational
information systems. Most software systems also fail to capture the design rules,
rationale, and constraints associated with a product’s design at different levels.
2.3 Knowledge Management and Ontologies
In this section the level of semantic information stored for persistent information
storage is introduced followed by the use of ontologies in knowledge management.
2.3.1 Methods of Persistent Information Storage
Figure 2-1 summarizes the degree of formality (i.e., level of semantic
information) stored along with the data by a particular method of information storage and
presents the technological maturity level of the methods. Ontologies, like OWL, are well
suited for design knowledge representation by supporting reasoning outside the
transaction context, i.e., avoiding a protocol specification to handle standard data format.
Any knowledgebase expressed in OWL implicitly includes the axioms and definitions
from OWL's ontology and facilitates greater machine interpretability. OWL is backed by
Description Logic (DL) [35], which makes it easier for computers to interpret the
semantics without human intervention. Also, software tools, irrespective of the subject
domain, can provide support for the ontologies. Programming packages such as Protégé
[36] provide a graphical user interface for editing ontologies, and Jena [37] has
16
application programming interfaces (APIs) for generic OWL manipulation and a rule-
based inference engine.
2.3.2 Ontologies in Knowledge Representation
An ontology consists of a set of concepts, axioms, and relationships that describes
a domain of interest. These concepts and the relationships between them are usually
implemented as classes, relations, properties, attributes, and values (of the
properties/attributes) [38]. An ontology can be defined as: “a formal, explicit
specification of a shared conceptualization” [39]. The attributes “formal” and “explicit”
enable the automatic machine-based interpretation of the conceptualization; “shared”
enables the sharing, combination, and integrated use of ontological information [40].
In the research field of knowledge representation and knowledge processing, the
application of ontologies has proven to be an advantageous paradigm over recent years
Figure 2-1: Methods of persistent information storage
17
[41]. The high payoff of saved effort due to reuse of pre-existing knowledge captured in
ontologies is discussed by Gennari, et al. [42]. Sharing common vocabulary of a domain
of information among people or software agents is one of the more common goals in
developing ontologies. Ontologies are generally classified into three levels: (i) upper
ontology (generic common knowledge), (ii) middle ontology (domain-spanning
knowledge), and (iii) lower ontology (individual domains and sub-domains) [38].
Some well known ontologies are the WordNet [43,44], containing over 100,000
concepts in English; the RosettaNet4 in the IT and electronics industry; the CYC [45]
knowledgebase, a formalized representation of a vast quantity of fundamental human
knowledge: facts, rules of thumb, and heuristics for reasoning about the objects and
events of everyday life; Standard Upper Ontology (SUO) of IEEE5, a standardization
project in progress for conceptually high level ontologies; and Gene Ontology, applied to
all organisms even as the knowledge of gene and protein roles in cells is accumulating
and changing6. DOLCE is the first module of a Library of Foundational Ontologies
being developed within the WonderWeb project, a project that is developing an
infrastructure for the large-scale deployment of ontologies [46]. The National Cancer
Institute (NCI) developed an interconnected set of software and services called caCORE
[47] that contains an ontology containing over 500,000 tuples providing consistency and
comparability across Cancer related data sets. In order to transform the information in the
4 http://www.rosettanet.org 5 http://suo.ieee.org 6 http://www.geneontology.org
18
World Wide Web into universal, sharable, and machine processable information, many
tools and web languages have been created by World Web Consortium7.
2.3.3 Methods and Tools for Ontology Development
Defining a common vocabulary, formalizing an ontology development process,
and implementing it becomes an exceedingly important step in a distributed knowledge-
sharing environment. There are a relatively small number of methodologies reported in
the literature for building formal ontologies. Uschold and King [48] present a “skeletal
model” for the design and evaluation of ontologies. Gruninger and Fox [49] developed a
methodology for design and evaluation of ontologies while developing the TOVE
(Toronto Virtual Enterprise) project ontology. Fernandez, et al. [50] present a structured
method and technique for building ontologies from scratch, called METHONTOLOGY.
Staab, et al. [51] present a methodology that makes a distinction between the knowledge
process and the knowledge meta-process. The methodology was created in course of the
On-To-Knowledge (OTK) project. Cimiano, et al. [52] recently proposed the application
of Formal Concept Analysis (FCA) in natural language processing (NLP) for acquisition
of domain concept hierarchies. In product design, even though some work exists in
formalizing design knowledge [53], we have not found any unified methodologies for
proceeding from a design vocabulary to an ontological implementation. The
methodology proposed in Chapter 3 seeks to address this limitation. Due to the lack of
common ontology development languages, ontology development methodologies, and
7 http://www.w3.org
19
ontology sharing protocols, large undivided (i.e., monolithic) ontologies were often
developed to represent products and systems. The use of large undivided ontologies
created difficulties in the area of ontology creation, maintenance, distribution, and
evolution. In Chapter 4 this limitation is addressed through the use of multiple ontologies
to represent different phases of product design, and a unified information model is
proposed to share design knowledge in a distributed ontology environment to avoid
having to create a single monolithic ontology.
For managing knowledge, the knowledge management community has developed
a wide range of technologies and applications for both academic research and practical
applications [54]. Among these, the Semantic Web is envisioned by World Wide Web
Consortium (W3C)8 as an extension of the current web to create web-based
knowledgeable systems with various specialized reasoning services systems [55]. In the
next section we describe the Semantic Web and the related standards in detail.
2.4 Semantic Web
As described by Berners-Lee [56], the inventor of the World Wide Web, “The
first step is putting data on the web in a form that machines can naturally understand, or
converting it to that form. This creates what I call a Semantic Web – a web of data that
can be processed directly or indirectly by machines.” The goal of the Semantic Web is to
develop enabling standards and technologies designed to help machines understand more
8 http://www.w3.org
20
information on the Web and support richer discovery, data integration, navigation, and
automation of tasks [57].
2.4.1 History and Evolution of the Semantic Web
To support Semantic Web development, the U.S. Defense Advanced Research
Projects Agency (DARPA) launched the DARPA Agent Markup Language (DAML)
initiative to fund research in languages, tools, infrastructure and applications that make
web content more accessible and understandable. DAML+OIL [58] evolved from
merging of DAML-ONT [59], an earlier DAML ontology language, with the Ontology
Inference Layer (OIL) [60], a description logic. DAML+OIL introduced several language
constructors that increased the expressive power of DAML. The Web Ontology
Language, OWL [61], has been developed as a vocabulary extension of RDF [62] and is
derived from the DAML+OIL Web Ontology Language. Currently, OWL is the most
expressive semantic markup language for publishing and sharing ontologies on the World
Wide Web sponsored by the W3C9. Figure 2-2 shows the stack that can be used in a
namespace - globally unique names used by any individual/organization. All the layers
in Figure 2-2 use XML for syntax, but specific interpreters are needed to understand a
particular language. A higher layer language interpreter should understand every
language below it.
9 http://www.w3.org/2004/OWL/
21
XML provides the syntax for structured documents, but it imposes no semantic
constraints on the meaning of these documents. XML Schema (XML-S) is a language
for restricting the structure of XML documents. RDF is a data model for objects
("resources") and relations between them that provides a simple semantics for data
models, and these data models can be represented in XML syntax. RDF Schema (RDF-
S) is a vocabulary for describing properties and classes of RDF resources, with semantics
for generalization-hierarchies of such properties and classes. Additional vocabularies in
OWL describe among others, relations between classes (e.g., disjointness), cardinality,
equality, richer typing of properties, characteristics of properties (e.g., symmetry), and
enumerated classes [61]. OWL facilitates greater machine interpretability of Web
content than that supported by XML, RDF, and RDF-S by providing additional
vocabulary along with a formal semantics [61].
Figure 2-2: Semantic web stack [63]
22
2.4.2 Web Ontology Language (OWL)
The Web Ontology Language (OWL) is designed for use in applications that need
to process the content of information instead of just presenting information to humans.
OWL comes in three sublanguages - OWL Lite, OWL DL, and OWL Full - to support
different levels of expressiveness [64]. OWL Lite supports classification hierarchy and
simple constraints. For example, while OWL Lite supports cardinality constraints, it only
permits cardinality values of 0 or 1. OWL DL provides computational completeness (all
conclusions are guaranteed to be computed) and decidability (all computations will finish
in finite time) while providing more expressiveness than OWL Lite. OWL Full is meant
for users who want maximum expressiveness and the syntactic freedom of RDF with no
computational guarantees. A valid conclusion in OWL Lite is a valid conclusion in OWL
DL and OWL Full whereas a valid conclusion in OWL DL is a valid conclusion in OWL
Full but not necessarily in OWL Lite.
A typical OWL ontology contains a sequence of annotations, axioms, and facts
which provide information about classes, properties, and individuals in the ontology [65].
The ontology vocabulary must include all the uniform resource identifier (URI) [66]
references and literals in that ontology, as well as ontologies that are imported by the
ontology. Annotations in an OWL document usually carry the authorship, version
information, related documents, comments and the import statements of other ontologies.
Each class, property, and individual in OWL ontology must have an URI identifier, either
user-defined or supplied by W3C. Axioms are used to associate class and property
identifiers with either partial or complete specifications of their characteristics, and to
23
give other information about classes and properties. There are many built-in data types in
OWL that are built on top of XML Schema data types and RDF data types (see
http://www.w3.org/TR/owl-semantics/syntax.html#owl_built_in_datatypes for a
complete listing). There are two built in classes in OWL, owl:Thing and owl:Nothing,
referred to using the “http://www.w3.org/2002/07/owl#” namespace. owl:Thing is the
class of all individuals whereas owl:Nothing is the empty class. Thus, all user-defined
classes become a subclass of owl:Thing. Facts are also of two kinds in OWL. One gives
information about a particular individual in the form of classes that the individual belongs
to plus properties and values of that individual. The second kind of fact is used to make
individual identifiers be the same or pair-wise distinct [65].
OWL DL is a frame-based description logic system with well defined first-order
semantics. This means that the language can be provided with a reasoning support system
such as the Fast Classification of Terminologies (FaCT) system [67], a Description Logic
(DL) classifier that can also be used for modal logic satisfiability testing. Reasoning is
useful, for example, when determining the logical subsumption relations between
descriptions and for determining whether the ontological theory is consistent [68].
A summary of OWL DL constructors, data ranges, axioms and facts is presented
in Table 2-1. The complete documentation of OWL DL can be found in Ref. [65]. An
OWL DL document, like other OWL documents conforms to the XML syntaxes. An
OWL DL “class” represents the generic concept of the vocabulary. Classes are arranged
into conceptual hierarchies. The “rdfs:subClassOf” construct specifies the class subclass
subsumption relationship, in the spirit of object oriented programming. Thus if class B is
a subclass of class A, it will contain all the properties of class A. Objects are instances of
24
classes represented by the construct “individual”. Properties, represented by
“rdfs:property”, are used to state relationships between individuals or from individuals to
data values. Properties may have certain characteristics, e.g., transitive, functional,
symmetric, inverse, and cardinality. Also, properties can be of type “ObjectProperty”
that associates pairs of individuals or “DatatypeProperty,” which associates an individual
with a data value. Properties can also form hierarchies and “rdfs:subPropertyOf”
construct captures such a relationship. A property hierarchy can be exploited by a
reasoner for deriving conclusions on the ontology. All the properties usually belong to a
domain that is captured using the construct “rdfs:domain”. A domain of a property limits
the individuals (instances of classes) where the property can be used. If the property has a
range then the domain limits the individuals that the property may have as its value.
OWL DL properties can have restrictions that dictate the usage of a property in an
instance of a class. Restrictions can be placed on the cardinality of a property or the type
of a property. Five annotation properties are predefined by OWL, namely,
owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, and rdfs:isDefinedBy. The
owl:versionInfo construct helps in keeping track of OWL document evolution.
25
OWL DL requires a pair-wise separation between classes, datatypes, datatype
properties, object properties, annotation properties, ontology properties, individuals, data
values and the built-in vocabulary [70]. This means that, for example, a class cannot be
at the same time an individual. The OWL DL constraints are based on work in the area
of reasoners for Description Logic, which require these restrictions to provide the
ontology builder or user with reasoning support.
Table 2-1: OWL DL Constructors, Axioms and Facts [69]
26
2.5 Formal Concept Analysis (FCA)
Formal concept analysis (FCA), introduced by Wille in 1982 [71], is used for
analyzing data and forming semantic structures that are formal abstractions of concepts of
human thought. FCA borrows its mathematical foundation from order theory, the theory
of complete lattices [72] in particular. In this section, important terminology for
describing FCA are modified to facilitate the understanding of OWL constructs in
conjunction with FCA.
2.5.1 Some Basic Definitions of FCA
Following the presentation of basic notions of concept analysis, a few definitions
of FCA follow [71].
Definition 1: A formal context in FCA is a triple K =: (C, P, R), where C is a finite set of
objects (henceforth referred to as classes), P is a finite set of attributes
(henceforth referred to as properties) and R is a binary relation between C
and P.
Definition 2: A relation R is represented as a sub-set of the cross product between the
finite sets of classes and properties, i.e., R ⊆ C × P. If a class c1 has
property p1, where c1 ∈ C and p1 ∈ P, then the relationship is represented as
(c1, p1) ∈ R. The mappings captured by relation R gives rise to a Galois
connection [73].
27
Definition 3: Common properties for a set of classes C1 ⊆ C
C1′ =: σ (C1) (= {P1 ∈ P | ∀C1 ∈ C : (C1, P1) ∈ R})
and correspondingly common classes for a set of properties P1 ⊆ P
P1′ =: τ (P1) (= {C1 ∈ C | ∀P1 ∈ P : (C1, P1) ∈ R})
Definition 4: A formal concept of K is represented by the elements of B(K) =: {(C1, P1) |
C1 ⊆ C, P1 ⊆ P, C1′ = P1, P1′ = C1}; hence, a formal concept is a combination
of a set of classes (called its extent) and a set of properties (called its intent)
such that all classes have all properties and all properties belong to all
classes.
Definition 5: A Galois or concept lattice of K is a partially ordered set represented by
B(K) = (B(K), ≤) with (C1, P1) ≤ (C2, P2) ⇔: C1 ⊆ C2 ( ⇔ P1 ⊇ P2). The
formal concept (C1, P1) in this case is called a formal sub-concept of formal
concept (C2, P2). There are several algorithms for computing a concept
lattice from a given formal context [74].
Definition 6: A cross table is a table that captures the relationship between classes C and
properties P. The classes are represented as rows of the cross table and the
properties as columns. The binary relation R between a class and a
28
property is captured by putting a checkmark in the cross table as shown in
Table 2-2.
Definition 7: 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 Table 2-3), i.e., 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 property p has value w” for the class c.
The many valued properties is regarded as partial maps from C in W. Conceptual scaling
[71] is the method that is used on many-valued contexts to derive the concept lattice.
Using this method, the many valued contexts are first transformed into single-valued
contexts and then interpreted as the concepts of the many-valued context.
Definition 8: A context K =: (C, P, R) is called clarified if for any classes C1, C2 ∈ C, C1′
= C2′⇒ C1 = C2. Correspondingly for all P1, P2 ∈ P, P1′= P2′ ⇒ P1 = P2.
Table 2-2: Example of a cross table
Table 2-3: Multi-context cross table example
29
Theorem 1 [71]: The concept lattice B(K) is a complete lattice [72] for which the
infimum (greatest common formal sub-class) and supremum (smallest
common formal sub-class) are given by equations Eq. (2.1 and Eq. (2.2.
Theorem 1 states that in order to compute the infimum of two classes, their
extents must be intersected and their intents must be joined; the latter set of properties
must then be “blown up” in order to fit to the class set of the infimum. Analogously, the
supremum of two classes is computed by intersecting the properties and joining classes.
A concept lattice is graphically represented using a line diagram known as the
Hasse Diagram [71], named after mathematician Helmut Hasse. A Hasse diagram is a
graphical rendering of a partially ordered set displayed via the cover relation of the
partially ordered set with an implied upward orientation of generalization. Hence more
precise information about the classes can be obtained by going down the lattice’s
structure. The nodes in the Hasse Diagram of a context are labeled dually with the
classes (below) and properties (above) and the vertices represent the relationship between
the classes. A reduced labeling scheme is often used wherein each class and property
appear only once in the diagram.
⎟⎟⎠
⎞⎜⎜⎝
⎛⎟⎟⎠
⎞⎜⎜⎝
⎛⎟⎟⎠
⎞⎜⎜⎝
⎛=
∈∈∈Λ UI
Iii
Iiiii
IiPCPC τσ,),( where I is an Index set (2.1)
( ) ⎟⎟⎠
⎞⎜⎜⎝
⎛⎟⎟⎠
⎞⎜⎜⎝
⎛⎟⎟⎠
⎞⎜⎜⎝
⎛=
∈∈∈IU
Iii
Iiiii
IiPCPC ,,V στ where I is an Index set (2.2)
30
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) [75].
Dividing the concepts and forming partial lattices before forming the global lattice
structure reduces the complexity to O((k + m)lm log m) as shown by Valtchev et.al. [75].
The complexity of the algorithm is reduced to O((k + m)lm) by the use of the algorithm
proposed by Nourine and Raynaud [76]. Computing and comparing the complexity of
lattice constructing algorithms is a difficult task and a discussion about the complexity of
algorithms can be found in [75].
2.5.2 Applications of FCA in Different Fields
FCA has been used extensively in Natural Language Processing (NLP) and
several applications of FCA in analyzing linguistic structures, lexical semantics and
lexical tuning are mentioned in Ref. [77]. Godin, et al. [78] recommend the use of a
Galois lattice structure for modular information retrieval after comparing the Galois
lattice retrieval method with manually built hierarchical classification and Boolean
querying with index terms. Lindig [79] used concept lattices for an incremental query-
based software component retrieval. Siff and Reps [80] presented an algorithmic
framework based on FCA to identify potential modules in computer programs.
Fernandez-Manjon and Fernandez-Valmayor [81] use FCA to support design decisions
about the structure and the interface of educational applications. Godin and Mili [82]
proposed a formal method for building, maintaining, and refining hierarchies in object
31
oriented programs using Galois lattices. Kuznetsov [83] proposed mathematical models
of data analysis and machine learning from positive and negative examples in terms of
FCA. Though FCA has been successfully applied in many domains it has never been
extended to product family design management. In this work FCA is used, for the first
time, to identify similarities among a finite set of design artifacts based on their
properties and then to develop and refine an ontology using OWL.
2.5.3 Software Tools for FCA
There are a number of software tools developed in the last two decades to support
FCA in different fields. General Lattice Analysis and Design (GLAD) is a tool developed
by Duquenne [84] for analyzing finite lattices, facilitates analysis of FCA. Contexts and
Implications (ConImp) [85] is another text-based tool that supports a wide range of
features for manipulating contexts in FCA. Concept Explorer (ConExp)10 is a Java-based
open-source tool that supports context creation and visualization in FCA. Tools of
Concept Analysis (TOSCANA) [86] is a tool used for building concepts from data stored
in relational databases. ToscanaJ [87,88] is an implementation of the TOSCANA system
in the platform-independent Java language that supports FCA. An overview and detailed
discussion of these and various other tools available for FCA can be found in Ref. [89].
Apart from being platform-independent, ToscanaJ supports richer graph visualization in
terms of Hasse Diagrams and numerical analysis of the concepts that are part of a formal
context [87]; hence, it is the software used in this research.
10 http://sourceforge.net/projects/conexp
32
2.6 Summary and Preview
In this chapter a literature review of existing product design knowledge
management systems is presented. The use of ontologies in knowledge management
systems is discussed. Also the importance of Semantic Web standards, particularly the
Web Ontology Language is presented. The basics of FCA and its usage is discussed. In
the next chapter a methodology for systematic development of product design ontologies
is introduced to address limitations noted in Section 2.3.
Chapter 3
Product Platform Design Information Representation and Encoding
The use of ontologies for information sharing is well documented in the literature,
but the lack of a comprehensive and systematic methodology for constructing product
ontologies has limited the process of developing ontologies for design artifacts. In this
chapter, the proposed Product Family Ontology Development Methodology (PFODM), a
novel methodology to develop formal product ontologies using the Semantic Web
paradigm, is introduced. PFODM combines distinct, yet complementary, research in
Formal Concept Analysis (FCA), Semantic Web, and Web Ontology Language (OWL).
In Section 3.1, PFODM is presented followed by a summary and preview in Section 3.2.
3.1 Product Family Ontology Development Methodology
A structured methodology for product family ontology building will facilitate
shared, consistent, and traceable ontology development in a diverse product development
team. Figure 3-1 illustrates the proposed ontology development process called the
Product Family Ontology Development Methodology (PFODM) for building product
family ontologies using FCA and OWL. In the PFODM, special importance is given to
the tabular and graphical representation of product design artifacts and their properties
using FCA to readily tie to an existing design repository. The steps are described in the
sections that follow.
34
3.1.1 Step 1: Component Lexicon Acquisition and Pruning
In this first step, a set of terms describing the components in a product family
along with the required properties is acquired from the Bills of Materials (BOMs) or by
dissecting the products to the component and/or subassembly level of interest if BOMs
are not readily available. If a product already has a bijective mapping of design terms
and components (e.g., a BOM), then this step is not necessary. Many approaches for
disassembly can be found in the literature. The reverse fishbone approach [90], product
design decomposition by Pimmler and Eppinger [91], virtual disassembly process by
Srinivasan et al. [92], Design Structure Method (DSM) [93], system decomposition by
Browning [94], Subtract and Operate Procedure (SOP) [95], Force Flow (Energy Field)
Diagrams [96,97], and Design For Assembly [98] are some of the methods that are
commonly used in reverse engineering. In this research the reverse engineering and
redesign methodology proposed by Otto and Wood [95], namely, SOP [97], is followed
for generating a listing of components and the functionalities of the product families
Figure 3-1: Product family ontology development methodology (PFODM)
35
through product dissection. SOP is useful for understanding component functions during
reverse engineering. The procedure aims at eliminating redundant components in a
product. After disassembly of the products in a family, a lexicon set is developed of all
the components that includes synonyms of their description and properties. This provides
the necessary terms based on which the product family ontology will be constructed in a
dictionary form. In the component lexicon pruning stage, a bijective mapping between
components and their descriptions is formed from the lexicon set. For the bijective
mapping, synonyms of a component’s descriptions are grouped together, and a single
description is chosen out of the group to represent these components.
3.1.2 Step 2: Formal Contexts Composition
The classes and the properties developed in Step 1 are next represented in a cross
table. The relationship between the properties and classes are captured from which the
formal contexts are composed. The cross table can capture both binary and multi-valued
properties. In capturing the properties for the design artifacts, multi-valued properties are
most often used from which many valued formal contexts are formed. The many valued
formal contexts are used to develop the product family concept lattice using FCA.
To reduce the number of classes required to describe the product domain, a
clarified context is created from the initial many valued formal context. Developing a
clarified context requires grouping similar classes together (aggregation), which can
result in information loss about the domain. To keep the ontology developed from the
clarified context sufficiently representative of the domain, the designer may decide to
36
keep some clarified classes separate even if they can be grouped. An intermediate
formal context is formed from the clarified context that contains all of the classes that the
designer decides to keep for the development of the product family ontology.
3.1.3 Step 3: Concept Hierarchy Formulation using FCA
From the intermediate formal context formed in Step 2, a design concept lattice
for the design artifacts is created using FCA. The design concept lattice is henceforth
known as the Networked Bill of Material (NBOM). The NBOM helps in capturing the
unique, variant, and common components of a product family, allowing instances of
classes that represent the components to be compared against each other. The Hasse
Diagram for a NBOM is shown in Figure 3-2. An example of developing a subsumption
hierarchy in OWL ontology from the concept lattice in conjunction with pair-wise
comparison of the clarified classes is presented in Section 6.2.3.
37
The partial order set of the concept lattice is used to develop the subsumption
hierarchy of the product family ontology. The concept lattice developed from the
intermediate formal context groups clarified classes at the same level in the subsumption
hierarchy. When representing the subsumption hierarchy of the product family concept
lattice in OWL, the designer may decide to impose an order hierarchy on the clarified
classes. Though imposition of order hierarchy on clarified classes seems redundant, it
helps reduce information loss due to aggregation and improves the reliability and
adaptability of the ontologies for changes. Order hierarchy is imposed on the clarified
classes that belong to a single group using pair-wise comparison of the classes using
positive and negative instance examples (see Table 3-1).
Figure 3-2: NBOM lattice structure
38
To determine the relationship between two classes, c1 and c2, examples and
counter-examples of the two clarified classes are used from the product family domain.
If separately we can provide examples of c1 and c2 classes in a product family but cannot
provide an example of both together, then they satisfy the clause c1 ∨ c2 and are parallel
classes. The pair-wise comparison of the clarified classes to form parallel or hierarchical
representation of the classes can also be represented graphically using the AND-NOT
quadrant as shown in Figure 3-3. The designers can also use the AND-NOT quadrant,
which represents Figure 3-3 in a graphical format for deciding the relationship between
clarified classes. In the case of the AND-NOT quadrant, the designer tries to come up
with examples for as many quadrants of the table as possible, and the coverage of the
quadrant decides the relationship between the classes. In case of parallel classes c1 and
c2, the designer can only come up with examples for quadrants A and C, i.e., an example
of a component that belongs to class c1 NOT c2 (quadrant C) and a component that
belongs to class c2 and NOT c1 (quadrant A).
Table 3-1: Pair-wise comparison of classes
Type Example Entailment Quadrant 1 c1 ∨ c2 Parallel Class/Dissimilar A and C 2 c1 ∧ c2 Same Class/Synonym B 3 (c1 ∧ c2) ∨ c2 c1 subsumes c2 A and B
39
3.1.4 Step 4: Product Family Ontology Formation and Enrichment using OWL
The partial order set of the concept lattice is used to develop the subsumption
hierarchy of the product family ontology. Figure 3-4 shows the mapping between the
products and the component lattices after the ontologies are constructed. Components
that are part of a product also have their own lattice structure based on their individual
properties. Thus all of the product and component knowledge is connected as a graph in
the knowledgebase. The graphs are stored as ontologies, which helps in browsing design
information and perform graph-based queries, component reuse, and distribution in a
heterogeneous design environment. The relationship between a product structure and an
ontology is shown in Figure 3-5.
Figure 3-3: Graphical representation of AND-NOT quadrant
40
During the development of the class - sub-class hierarchies using FCA, constructs
like owl:class, owl:subclass, owl:datatypeproperty, owl:objectproperty are primarily
used. The initial product family ontology hierarchy formed using FCA is enriched by
capturing various constraints, characteristics, and relationships between different classes
and properties. Constructs for ontology headers like rdfs:comment, owl:priorVersion,
rdfs:label, and owl:AnnotationProperty can be used to capture information about the
generated OWL file. Components are declared as individuals that belong to various
classes. Components even if belonging to the same class can be different physically, and
this is captured in the ontology using owl:AllDifferent and owl:distinctMembers. The
owl:equivalentClass construct helps in defining classes as equivalent and is used to
describe components that are similar to each other at the concept level. Properties that
Figure 3-4: Product – Component – Attribute integration
Figure 3-5: Mapping between product structure and design ontology
41
are part of the ontology are improved with constructs like rdfs:range and
owl:minCardinality. The exact data types of owl:datatypeproperty are indicated with
XML Schema data types. Constructs like owl:oneOf, rdf:List, and rdf:rest are used to
define enumerated data types.
After declaring the concepts and properties, PFODM provides a process of
generating OWL ontologies that does not require further user interpretation. The
PFODM will be primarily used by design knowledge engineers while developing and
managing product family design repositories. To demonstrate the use of PFODM to
construct an ontology, products and components from a family of one-time-use cameras
and power tools are represented in OWL DL format in Chapter 6 and Chapter 7.
3.2 Summary and Preview
In this chapter three distinct yet interrelated ideas—product family design, FCA,
and OWL— have been synthesized to create a systematic and consistent methodology for
ontology development to support product family design, namely, Product Family
Ontology Development Methodology (PFODM). Representing the product family as a
NBOM, which essentially is a directed cyclic labeled graph structure, helps connect all of
the design artifacts in a product family with each other. The method of constructing
ontologies using PFODM imposes traceability on the development of formal ontologies
and minimizes user intervention for a consistent construction of product family
ontologies, which can later be linked to other ontologies within an organization over the
Internet. The resulting ontologies provide a hierarchical conceptual clustering of related
42
design artifacts, which is particularly advantageous for product family design where
parts, processes, and most importantly, information is intentionally shared and reused to
reduce complexity, lead-time, and development costs. PFODM is useful for creating
ontologies to support a unified information model for product family design knowledge
management that includes customer needs, functions, and components as discussed in the
next chapter.
Chapter 4
Product Family Knowledge Sharing
At every phase in the product realization process, certain entities are used to
represent a design (e.g., prototype design, CAD model, physical motor, etc.). In this
chapter, a Product Family Unified Information Model (PFUIM) is introduced to capture,
share, and organize product design contents, concepts, and contexts across different
phases of the product realization process using Web Ontology Language (OWL)
representation that can be accessed across proprietary software programs and
computational platforms. In this chapter three distinct types of design information for
product families, used in the early phases of design, are captured in the proposed unified
information model: (1) Customer Needs (CN), (2) Product Function Structure (PF), and
(3) Components (C). The unified information model is used to share design knowledge
across a product family.
4.1 Product Family Unified Information Model for Design Representation
Figure 4-1 describes the steps involved in creation of the PFUIM for design
representation. Starting with individual product dissection (if a Bill of Material (BOM) is
not available) to the development of common ontologies, the proposed information model
is generic enough to capture design information across different phases of product
realization. This information can also be shared across multiple products that are part of
44
a product family. In the following sections each step in design knowledge sharing across
a product family using PFUIM is described in detail.
4.1.1 Step 1: Individual Product Documentation via Dissection
In the first step, the products that are part of the product family are dissected to
the lowest level possible, if necessary. If detailed BOM documentation for each product
is already present in some digitized form then this step may be skipped. The basis of the
disassembling procedure in this research, as described in Section 3.1.1., is the reverse
engineering and redesign methodology called the Subtract and Operate Procedure (SOP)
proposed by Otto and Wood [95]. From the detailed product dissection, a BOM is also
created and stored for each product.
Figure 4-1: Methodology for creating a PFUIM
45
4.1.2 Step 2: Entity List Creation for Each Type of Design Information
In this step a list of entities that influence a particular phase in the design process
are documented. In this work, only three types of design information are considered to
illustrate the unified information model: (1) customer needs (CN), (2) product function
(PF) structure, and (3) components (C). The proposed unified information model can be
easily extended to handle other types of design information captured during the product
realization process (e.g., process planning, manufacturing, etc.).
A number of design strategies exist to relate customer needs to product functions
[97,99,100]. In this work, the customer needs for each product are ascertained through
web searches, advertisements, and store displays. More accurate information can also be
obtained from other divisions like marketing and sales, when available. The customer
needs list represents the “best guess” as to the selling features for a product. A separate
list of customer needs is created for each individual product in the product family and is
represented by {CN1X, CN2
X, …, CNjX}. CNj
X represents the jth customer need for
product number X of a product family that has products {P1, P2, …, Pp}.
A function structure model for the product describes how the product functions in
a form-independent manner. The functional basis that is being developed by Stone and
his colleagues [101,102] is used to describe the individual product functionalities, in this
work. Functional basis provides a consistent language for describing product functions.
Clear definitions of product functions are characterized in a verb-object (function-flow)
format to describe each function and flow in the mechanical design space. An array of
46
product functions for each product is created and is represented by {PF1X, PF2
X, …,
PFkX} where PFk
X stands for the kth product function of product number X in the family.
The component list or Bill of Material (BOM) is created by capturing all of the
components in the product, including information for the attributes such as material,
manufacturing process, weight, overall dimensions of each component and a picture of
each component in the product. Similar to other types of design information under
consideration, an array of components is represented by {C1X, C2
X, …, CmX} where Cm
X
stands for the mth component of product X in the family.
If there are p products in a product family, then X will range from 1 to p. The
mapping between the three distinct information structures that are part of any product
realization process is shown in Figure 4-2. A single customer need can be satisfied by
one or more product functions and vice versa as shown by the arrows in Figure 4-2.
Similarly one product function is achieved by one or more components and vice versa.
This mapping is captured using the Product Vector Matrix (PVM) and Function
Component Matrix (FCM), which are discussed in detail in Section 4.1.4.
47
4.1.3 Step 3: Common Ontology Layer formation for the Entire Product Family
The entity list created in Step 2 is used to develop a common ontological layer
using OWL for each phase of design of the product family. To do this, all of the entities
of individual products representing different phases of product realization in a product
family are grouped together first. Figure 4-3 shows the ontology formation for the
customer needs analysis. Customer needs of individual products are merged to form a
master list and then grouped together by their attributes. Duplicate entries from this list
are removed, and common concepts are extracted from the grouped entities. The
common concept list is then arranged in a hierarchical structure that captures the context
in which the concepts are used using Formal Concept Analysis (see Section 3.1.3.). The
PFODM from Chapter 3 can be used to develop OWL ontologies from the concept list.
Figure 4-2: Entity list for each type of design information and their interrelationship
48
The customer needs ontology captures the relationship between various concepts
in “isa” object hierarchy. Each node in the ontology is represented as CNnC
where “n” is
the node number and “C” signifies an OWL class. Every product uses the instance of
these classes to represent their own customer need, i.e., CNjX will be an instance of CNn
C.
The ontological representation helps group, aggregate and capture the
interrelationship of the individual entities in an object-oriented way that can be used for
all of the products in a product family. The OWL ontologies developed for each phase of
design have an open standard of representation and can be interpreted and represented in
a distributed and varied software design environment. The individual ontologies can be
extended as (and when) required by adding new concepts in a proper context to
accommodate product design changes. The ontologies also capture the design rationale
and provide alternate design solutions that helps manage and improve a product family.
4.1.4 Step 4: Mapping between Different Phases of Design Information
The Product Vector Matrix (PVM) and Function Component Matrix (FCM) are
used to map between different design information structures during the different phases
Figure 4-3: Common ontology layer development for customer needs phase
49
of the product realization process. Because of unique and variant components present in
individual products, each mapping is unique for a particular product in a product family.
The Product Vector Matrix (PVM) maps the relationships between the functions
listed in the function structure model and the weighted customer needs (see Figure 4-4).
The first column of the PVM lists the product functions, and the weighted customer
needs are listed across the top row of the PVM. As the only interest at present is in the
mapping between design information structures, customer weights in the PVM are not
considered. For each function that impacts a particular customer need, a ‘1’ is entered
into the cell in the matrix. In Figure 4-4, the highlighted cell signifies that for Product
number X, customer need number 1 (CN1X) is satisfied by product function number 2
(PF2X).
The Function Component Matrix (FCM) maps the relationships between the
functions captured in the function structure model and the components listed in the BOM
(see Figure 4-5). Similar to the PVM, for each component that impacts a particular
product function, a ‘1’ is entered into the cell in the matrix. In Figure 4-5, the highlighted
Figure 4-4: Product vector matrix for an individual product
50
cell signifies that for Product number X component number 2 (C2X) partially satisfies
product function number 1 (PF1X).
Both PVM and FCM are created at the individual product level. The
preconceived common ontologies layer developed in Step 3 (see Section 4.1.3) is used
for product family design information aggregation as discussed next.
4.2 Product Family Design Information Aggregation
Figure 4-6 describes the multi-modal design representation of a product family
using common ontologies. The common ontological layer is created from the existing
products’ design information. A single ontology is built for every phase of product
family design realization and is used by each individual product to represent the unique
component instances in a product family. The common ontological layer provides the
standard that is used by designers when working in a given phase. The common
Figure 4-5: Function component matrix for an individual product
51
ontological layer not only ensures data consistency in a given phase but also helps in
aggregating information 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 common ontological layer and the product instance representation. The product
family design information aggregation can further be subdivided into two groups: (1)
design information aggregation between products of a product family, and (2) design
information aggregation across different phases of the product realization process. These
two ways of information aggregation during product family design are discussed next.
Figure 4-6: Model for product family design information aggregation
52
4.2.1 Step 5a: Product Family Design Information Aggregation Spanning Multiple Products
Due to the common ontology layer, each design entity that is part of an individual
product is an instance of an OWL class. This conceptual grouping using ontologies helps
aggregate information between products within a family. Every design entity is an
instance of an OWL class. Thus starting 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 one
starts with a single product function for product X, say PF1X, then the system can locate
the class for this instance as PF1C and list all the other instances of this class present in the
system automatically. Also, when new products are introduced later in the product
family, they will be represented using these preconceived ontologies, making the
integration and design analysis process automatic.
4.2.2 Step 5b: Product Family Design Information Aggregation across Phases
Each of the design entities is created as an instance of the preconceived common
ontology, and the PVM and FCM consist of individual instances of the ontologies. The
PVM and FCM also capture the relationship between the three types of design
information structure, (1) customer need, (2) product function, and (3) components. This
mapping helps the system to present design information transparently across different
phases of the product realization process. For example, if one starts with a single
53
customer need instance for product X, say CN1X, one can easily find the components that
satisfy this customer need by jumping from customer need to product function to
component space using the PVM first and then the FCM.
4.3 Summary and Preview
In this chapter a PFUIM to capture, share, and organize product design contents,
concepts, and contexts across different phases of product realization process using Web
Ontology Language (OWL) representation is introduced. The open standard of OWL can
be accessed across different proprietary software programs and computational platforms.
Representing product families by preconceived ontologies promotes component sharing,
learning across products, reduced product realization time and system complexity, and
can reduce product design lead-time. The product family examples presented in Chapters
6 and 7 demonstrate and validate the proposed uniform information model.
Chapter 5
Product Family Representation and Redesign
By redesigning existing products, a manufacturer can achieve higher levels of
commonality within a product family and take advantage of the associated cost savings
and indirect benefits. A significant concern while redesigning product families comes
from the interaction between different subsystems and components. Designers must
modularize the subsystems of a product family inexpensively to avoid the trial-and-error
process of redesigning multiple components. In this chapter, Product Family
Representation and Redesign Framework (PFRRF) is introduced to systematically
represent, analyze, and help improve commonality in existing product families.
5.1 Product Family Representation and Redesign Framework
As discussed in Chapter 2, design information is often captured as part of a single
product and represented as a tree structure (e.g. BOM). Single product specific
representation hampers the process of redesigning multiple products of a product family
as it becomes difficult to share and analyze design information across products. To
facilitate the redesign of a product family the designers need to have a representation that
captures the design information of multiple products as part of a single information
model. Within the context of FCA, the Networked Bill of Material (NBOM) can capture
all the product design information as part of a network (see Section 3.1.3). The NBOM
55
can then be redesigned using one of two following approaches: (1) Component-Based
approach, and (2) Product-Based approach. In a Component-Based approach, designers
select unique or variant components in a product family and try to make them variant or
common, thus improving the commonality in the product family. In a Product-Based
approach, the designers select multiple products from a product family and try to increase
the commonality between the selected products, thus improving the commonality in the
product family as a whole.
In the proposed approaches, the constraints on the technical feasibility of
redesigning a component are not considered. Thus, in both approaches, if all of the
recommended solutions are implemented, the resulting products will end up becoming
the same. Depending on the redesign requirements, designers can use either of the
proposed two approaches to improve commonality. The Product Family Representation
and Redesign Framework (PFRRF) is presented in Figure 5-1. It incorporates a visual
representation of the product family as a whole and both the Component-Based and
Product-Based approaches for restructuring product families iteratively. PFRRF helps in
improving the commonality of the product families in a systematic way. The remainder
of this chapter describes the steps of the Product Family Representation and Redesign
Framework (PFRRF) shown in Figure 5-1.
56
5.2 Input: Product Family NBOM
In the absence of a BOM, the individual products of a product family are
dissected and documented using SOP [95], as described previously in Section 3.1.1. The
detailed BOMs for products in the family are used as an input for FCA in PFRRF.
5.2.1 Step 1: Product-Component Formal Context Formation
In this step, the individual product hierarchies in each BOM are merged to create
the product-component cross table (see Table 5-1) for FCA. In the product-component
cross table, products are represented as objects and component instances as attributes
Figure 5-1: Product family representation and redesign framework (PFRRF)
57
with single or multiple values. The product-component cross table can capture both the
binary and multi-context relationships 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, only slightly in size, shape, material, etc. The decision to group a number of
component instances under a particular component is mainly made by the designer. For
example, consider the two flash buttons shown in Figure 5-2 taken from two one-time-
use cameras. They are two different component instances (say Flash button 1 and Flash
button 2) of the component Flash button, as they are used for the same function (turn on
the flash) but differ mainly by shape and color.
Table 5-1: Product-Component multi-context cross table
Figure 5-2: Two instances of camera flash button
58
A product in a product family uses one of the many component instances
available, i.e., an individual one-time-use camera uses one of the many flash buttons
available. Table 5-1 captures this relationship between each product and each type of
component. The formal context made from the product-component cross table is used to
form the product family design concept lattice, known as the NBOM.
5.2.2 Step 2: Product Family Representation
The traditional tree-based design representation of individual products in a
product family does not show the designers component relationships within a product
family. When redesigning a product family or introducing a new product in the product
family, a unified product family visualization method provides designers with insight
about component relationships across products. Representing multiple products that are
part of a NBOM in a Hasse diagram helps designers visualize the relationship between
products and their components while differentiating between common, variant, and
unique components.
To form a product family NBOM, the design lattice structure from a product-
component multi-context cross table (see Table 5-1), let us consider a simple product
family as shown in Table 5-2. This product family has three products containing one
instance of Component 1, two instances of Component 2, and one instance of Component
3. Product 1, for example, is made up of Component 1 instance 1, Component 2 instance
1, and Component 3 instance 1. The Hasse diagram, representing the NBOM, from this
product-component cross table is shown in Figure 5-3.
59
The nodes in the Hasse diagram are dually labeled with the classes (above) and
properties (below). In this case, the components and component instances are presented
on the top of the nodes, and products are in the bottom of the nodes. The set of all of the
component instances that are part of a product is a subset or equal to the set of all the
component instances associated with the chain that leads from the top of the Hasse
diagram to that particular product. For example, in Product 1 in Figure 5-3, the set of
Table 5-2: Cross table of example product family
Figure 5-3: Visualizing common, variant, and unique components in a Hasse diagram
60
component instances that are part of Product 1 is a subset or equal to the set
({Component 1:has C1_1}, {Component 2:has C2_1}, {Component 3:has C3_1}).
The degree of product connectivity for a particular node in the NBOM is the
number of nodes in the lattice on or below a selected node that have products associated
with them. For example, the degree of product connectivity for node n1 in Figure 5-3 is
two, as two products, ({Product 1}, {Product 3}), are connected below node n1.
The product family NBOM also captures the common, variant, and unique
components in the product family. The components that are only associated with a
particular product are unique components belonging to that product. The variant
component concept is not associated with a particular product but form a node above the
products that share that component. All component instances that form part of the top-
most node (supremum) of the Hasse diagram are common for all the products. Figure 5-3
also labels the components as common, variant, and unique. Note that the common and
unique components have only one component instance, while the variant components
have two of more component instances. After forming the formal contexts between
component and products and visualizing the product family NBOM in a Hasse diagram,
the product family is redesigned by either using the component-based approach or
product-based approach as described next.
5.3 Step 3: Approaches to Product Family Redesign
When using either a component-based or product-based approach to redesign,
product family commonality is increased by either making variant components common
61
or by making unique components variant. In both cases, preference is given to making
variant components common over making unique components variant to maximize
economies of scale. This is done because unique components are typically used as (1)
external and/or differentiating components and (2) for a specific function that is present
in only one product. These components are used to keep each product different
asthetically and functionally. If it is decided to make unique components variant, either
the products in the family will lack distinctiveness, or they will have extraneous
functions. For example, in the case of the one-time-use cameras, making the waterproof
case variant instead of unique in the family will result in more than one camera being
waterproof, a function that is not required of every camera in the family. On the other
hand, variant components are neither used to differentiate the products nor to add specific
functional attributes to a product; hence, preference is given to make variant components
as common as possible.
An example product family that has four products and seven components is used
to illustrate the steps involved in the two approaches proposed for redesigning a product
family. Table 5-3 shows the four products and their relationships with the seven
components. There are four unique components (Components 1-4), two variant
components (Component 5-6), and one common component (Component 7) used in the
four products.
62
The NBOM of the example product family in Table 5-3 is shown in Figure 5-4.
The nodes in the Hasse diagram are numbered from n0 to n7 and are labeled dually with
the products (below) and components (above). In the NBOM in Figure 5-4, the nodes in
the path from Product 1 to the supremum (i.e. n0, n1, and n2) contain all the component
instances that are part of Product 1. The NBOM shown in Figure 5-4 is used to redesign
the product family using both approaches as explained next.
Table 5-3: Example product family cross table
63
5.3.1 Step 3a: Component-Based Approach to Product Family Redesign
The component-based approach consists of redesigning a product family by
looking at how variant components could be shared among the products in the product
family. Recommendations for redesigning a product family using a Component-Based
approach can be identified mathematically by analyzing the formal contexts associated
with a NBOM or visually by starting at the bottom of Hasse diagram and working up
toward the top. The steps involved in redesigning the product family using the
component-based approach are shown in Figure 5-5 and explained as follows.
Step 1: Choose a component instance whose commonality needs to be increased in the
product family (for example, a very expensive component that one would like to
make common or replace with a similar component in as many products as
possible).
Figure 5-4: NBOM for the product family cross table example
64
Step 2: Locate the generic component by traversing the chain from the component
instance towards the supremum of the NBOM.
Step 3: Once the generic component is located, traverse all the vertices coming out of
this node towards the infimum and locate all the nodes where other component
instances of this generic component are attached.
Step 4: Rank the nodes found in Step 3 by the degree of product connectivity. Let the list
obtained be {n0, n1,…, nm}. If the number of objects is equal below two nodes,
then other parameters (such as cost of the components, manufacturing time, etc.)
should be taken into consideration when ranking the nodes.
Step 5: After ranking the nodes, show the component instance associated with the first
node as the instance that needs to be made common by replacing the chosen initial
component instance. Sequentially present the component instances from the
ranked nodes as solutions until the designer decides on a solution.
65
With this approach, the component instance to redesign can be “pushed” up to a
node to make it common across multiple products. To illustrate this approach, the
redesign of Component 5 Instance 2 in the example product family to improve
commonality (see Figure 5-4) is presented. Component 5 is a variant component and is
present in all of the products in the family. Following the proposed approach, the first
location of the generic component “Component 5” is determined by traversing towards
n0. The generic component “Component 5” is associated with node n0. Now, a search
for the nodes that have this generic “Component 5” in the network below node n0 is
performed. Nodes n1 and n6 both satisfy this criterion, but as the degree of product
Figure 5-5: Component-Based approach for product family redesign
66
connectivity is higher for node n1, the first suggestion to improve commonality will be to
redesign Component 5 Instance 2 to make it common with Component 5 Instance 1. If
this initial solution is accepted, then the revised NBOM will be as shown in Figure 5-6.
The commonality of the product family increases due to the redesign of Component 5
Instance 2. The commonality, before and after the redesign of this generic product family
is discussed in Section 5.4.
Following the component-based approach, the next solution will be to push the
Component 5 instances to the top-most node (i.e., n0) and make Component 5 a common
component across the product family. Thus the component-based approach gives
preference to keep the selected component variant before making it common. In this
redesign approach, only component redesign is taken into consideration, and the
proposed redesign is decided based only on the impact on commonality within the family.
Figure 5-6: NBOM of the product family after component-based redesign
67
In the future, other parameters such as manufacturing time, component cost, and
technical feasibility should also be considered while ranking candidate solutions.
5.3.2 Step 3b: Product-Based Approach to Product Family Redesign
The product-based approach consists of redesigning a product family by choosing
two or more products in the product family and increasing commonality between them,
thus increasing the commonality of the product family as a whole. The designer can
choose between two or more products in the family to initiate this approach.
Recommendations for redesigning components of the selected products of a product
family using a product-based approach is identified mathematically by analyzing the
formal contexts or visually by starting at the bottom of Hasse diagram and working up
toward the top. Figure 5-7 shows the flow diagram of the various steps involved in the
product-based redesign approach.
Step 1: Choose two or more products in the product family.
Step 2: List all the component instances associated with the selected products by
traversing up the lattice structure.
Step 3: Locate generic components that belong to all of the selected products. Rank the
nodes associated with the generic components by the degree of product
connectivity (i.e., the number of products associated with or below the selected
node) with products.
Step 4: After exhausting the list of nodes in Step 3, generic components for two or more
of the selected products are identified. The nodes are again ranked by using the
68
degree of connectivity of the nodes. This time products not selected in the initial
list from the product family are also considered while ranking, which will
influence the maximum number of products while redesigning a component;
however, redesign suggestions are presented in such a way that the products not
selected in Step 1 are not affected.
Step 5: Identify unique component instances within the selected product list and locate
generic components for those in the whole product family. The same ranking
method is used to suggest redesign solutions.
Step 6: In the last step, all unique components that do not have any generic component in
the whole product family are considered for redesigning to increase the
commonality. This may not be suitable as the unique components often
distinguish the individual products in a product family, but the unique
components can be made common or removed from the existing products to
increase the commonality from a theoretical point of view.
Following the steps of the product-based redesign approach, a demonstration of
the redesign of the example product family is presented by improving the commonality
between Products 3 and 4 (see Figure 5-4). Product 3 is associated with node n5 and
Product 4 with node n6. The list of all the components for Product 3 is: {C3 Instance 1,
C5 Instance 2, C6 Instance 1, C7 Instance 1}. Similarly for Product 4 the component
instance list is: {C4 Instance 1, C5 Instance 3, C6 Instance 2, C7 Instance 1}. The list of
components that have generic components above nodes n5 and n6 are {C5, C6}. Out of
these components, {C6} is only present in the selected two products and thus will be
69
ranked higher than {C5}. Now, {C6} can potentially be made common across Product 3
and Product 4 by choosing Instance 1 or Instance 2 to make common.
Figure 5-8 shows the revised NBOM if Component 5 Instance 1 is made common
between Product 3 and Product 4. For each suggestion, the corresponding improvement
in commonality is shown to the designer for feedback as the feasibility of the redesign
suggestion is currently not automatically verified. This is discussed in more detail, as
part of future work in Chapter 8. In the next section, the indices used to compute the
commonality of a product family while performing component redesign is presented.
Figure 5-7: Product-Based approach for product family redesign
70
5.4 Step 4: Post-Redesign Commonality Analysis
The designer can evaluate various redesign solutions by computing commonality
indices available in the product family literature. A commonality index is a metric to
assess the degree of commonality within a product family. It is based on different
parameters such as the number of common components, the component costs, the
manufacturing processes, etc. These indices are often the starting point when designing a
new family of products or when analyzing an existing family [103].
Three commonality indices are used in this work: the Commonality Index (CI,
[104,105]), the Degree of Commonality Index (DCI, [106]), and the Total Constant
Commonality Index (TCCI, [107]). These three indices mainly focus on the number of
common, variant, and unique parts and do not take factors such as cost or material type
into consideration.
Figure 5-8: NBOM of the product family after product-based redesign
71
5.4.1 The Degree of Commonality Index (DCI)
The degree of commonality index (DCI), proposed by Collier [106] in 1981, is
one of the most traditional measure of component part standardization. The index
reflects the average number of common parent items per average distinct component part
(see Eq. (5.1):
where:
jΦ = the number of immediate parents’ component item j has over a set of end
items or product structure level(s).
d = the total number of distinct component items in the set of end items or product
structure level(s).
i = the total number of end items or the total number of highest level parent items
for the product structure level(s)
Component item = any inventory item (including a raw material) other than an
end item that goes into higher level items.
End item = finished product or major subassembly subject to a customer order or
sales forecast.
Parent item = any inventory item that has component parts
Equation (5.2 gives the upper and lower values of DCI.
dDCI
di
ijj∑
+
+=
Φ= 1
(5.1)
β≤≤ DCI1 (5.2)
72
where, ∑+
+=
Φ=di
ijj
1β is the total number of immediate parents for all distinct components
over a set of end items or product structure level(s). If a product family has DCI = 1 then
there is no commonality between the products as no item is being used more than once in
the products. On the other hand DCI = β signifies complete commonality in the product
family. Figure 5-9 illustrates the computation of DCI for three sets of two end items
(number 1 and 2).
5.4.2 The Total Constant Commonality Index (TCCI)
The Total Constant Commonality Index (TCCI), proposed by Wacker and
Trelevan [107], is a modified version of the DCI. Contrary to the DCI, which is a cardinal
index, the TCCI (see Eq. (5.3) is a relative index that has absolute boundaries.
Figure 5-9: Computational examples for the DCI [106]
73
where:
jΦ = the number of immediate parent items, component item j has over a set of
end items or product structure level(s).
d = the total number of distinct component items in the set of end items or product
structure level(s).
Component item = any inventory item (including a raw material) other than an
end item that goes into higher level items.
End item = finished product or major subassembly subject to a customer order or
sales forecast.
Parent item = any inventory item that has component parts
Equation (5.4 shows the upper and lower limits of TCCI. If the value of TCCI = 0
then there is no commonality in the product family, where as TCCI = 1 implies there is
complete commonality in the product family.
Figure 5-10 shows five different cases of products with zero commonality on the
left (DCI = 1.0 and TCCI = 0.0) to absolute commonality on the right (DCI = 12 and
TCCI = 1).
1
11
1−Φ
−−=
∑=
d
jj
dTCCI (5.3)
10 ≤≤ TCCI (5.4)
74
5.4.3 The Commonality Index (CI)
Proposed by Martin and Ishii [104,105], the Commonality Index (CI) is a measure
of unique parts, which is similar to the DCI proposed by Collier. It is given by
Equation (5.5.
where:
u = number of unique parts
pj = number of parts in model j
vn = final number of varieties offered
A higher CI is better since it indicates that the different varieties within the
product family are being achieved with fewer unique parts.
Figure 5-10: Computational examples for the DCI and TCCI [107]
∑=
−
−−=
nv
jjj
j
pp
puCI
1max
max1
(5.5)
75
5.4.4 Commonality Analysis after Product Family Redesign
The commonality indices are applied to the generic product family after
component-based and product-based redesign. The results are given in Table 5-4. In this
case, the commonality increment after the product-based approach yields the same
improvement in commonality as the component-based approach. This is because the
TCCI and the DCI only measure the ratio between the number of common components to
the total number of unique components. Hence, if two variant parts of two products in a
product family are made common, then the ratio will change for both indices at the same
time, no matter which component it is. Future work will include more detailed indices
like CI(C) [108] and PCI [109] for post-redesign commonality assessment that take
component cost, etc. into account.
5.5 Summary and Preview
In this chapter Product Family Representation and Redesign Framework (PFRRF)
to redesign existing product families using NBOM is presented. The proposed redesign
framework provides a systematic way to redesign products to improve commonality in a
product family. Two approaches, namely, the component-based approach and the
Table 5-4: Before and after redesigning the example product family
76
product-based approach, have been proposed to help redesign an existing product family.
The framework can also be applied to the entire product family or individual assemblies
within it. In Chapter 6, several products from a family of one-time-use cameras and in
Chapter 7 products from power tool product family are presented to demonstrate and
validate the methodologies developed in this dissertation to support knowledge
management in product family design.
Chapter 6
Case Study 1: Knowledge Management in a Homogeneous Product Family
In this chapter the proposed methods for product family knowledge management
introduced in Chapter 3 (PFODM), Chapter 4 (PFUIM), and Chapter 5 (PFRRF) are
demonstrated and validated using a homogeneous family of one-time-use cameras. A
homogeneous product family is comprised of products that exhibit similar dominant
functionality shared between the products.
6.1 Introduction to the One-time-use Camera Product Family
One-time-use cameras provide users with a simple and inexpensive way to take
pictures and digital photographs. These products offer consumers a variety of choice for
photography, which includes black & white pictures, indoor and outdoor, underwater
capabilities, and digital pictures. The one-time-use cameras contain a collection of
optical, electronic, and mechanical components to satisfy a variety of customer needs,
thus providing a rich set of design information for educational research. In this chapter, a
set of Kodak one-time-use cameras is dissected (see Appendix A), and the design
information is used to demonstrate and validate the proposed methodologies introduced
in earlier chapters. Details about the product family and their dissection can be found in
Refs. [110,111].
The Kodak one-time-use camera family consists of seven cameras readily
available in the market with specific functions: flash, digital processing, waterproof,
78
black and white, and APS (Advanced Photo System) with switchable format. A
summary of the cameras, showing some of the major distinguishing characteristics, is
presented in Table 6-1. The Kodak MAX Outdoor (35 mm film – 27 exposures) and the
Kodak MAX Water & Sport (35 mm films – 27 exposures) are the two cameras that
come without a flash. The Kodak Advantix Switchable is equipped with 24mm APS
film. Due to the technology being completely different from the other cameras, most of
the parts are unique in the Kodak Advantix Switchable. In this chapter, the Kodak one-
time-use camera family is used to validate the PFODM (see Section 6.2), the PFUIM (see
Section 6.3) frameworks and the PFRRF (see Section 6.4).
6.2 Product Platform Design Information Representation & Encoding Using PFODM
In order to demonstrate the steps of PFODM we discuss the kodak:cover class
that is a part of the Kodak one-time-use camera family. A group of shutter covers and
flash covers are formalized as part of the ontology using the proposed PFODM.
Table 6-1: Summary of Kodak one-time-use cameras [110]
79
6.2.1 Step 1: Camera Component Lexicon Acquisition and Pruning
To develop the lexicon set for the one-time-use camera family, the cameras are
first disassembled to the component level. A component is a part of the camera that
cannot be further decomposed into design artifacts. After the products are disassembled,
all of the terms associated with the components are collected in a dictionary form,
including any synonyms for the components. Based on this dictionary of terms ( lexicon
set) the product family ontology is formalized. For example, the lexicon set for
describing the shutter cover for the MAX Outdoor camera is L1 =: {MAX Outdoor
Shutter Cover, Shutter Cover of MAX Outdoor, MAX Shutter Cover}. In the next step,
the lexicon set is reduced such that a one-to-one relationship is formed between the
component and the term describing it; hence, after lexicon pruning, the shutter cover for
the MAX Outdoor camera is L1 =: {MAX Outdoor Shutter Cover}. All of the other
synonyms for the component can still be saved for reference, but they will not be used as
a part of the formal ontology. Properties of the components that are of interest for the
Kodak domain are also collected, e.g., P1 =: {Weight, Material, Color}.
6.2.2 Step 2: Formal Context Composition of the Camera Cover Class
The second step is to put the lexicon set in a cross table with the rows describing
the classes and the columns capturing the properties. For the kodak:cover class, Table 6-
2 shows the initial cross table for all the shutter and flash covers of the one-time-use
camera family with all the shutter covers as rows and their properties as columns.
80
After disassembling the covers, we found that there are three types of shutter
covers and three types of flash covers based on their shape. In Table 6-2, the relation R
between these cover classes and their multi-context properties is captured. For example,
the tuple (MAX Outdoor Shutter Cover, Shutter Cover Shape 1) is in R, but (Shutter
Cover, Flash Cover Shape 1) is not. As defined in FCA, a formal concept is a maximal
collection of classes sharing common properties. In Table 6-2, ({Cover, Shutter Cover,
Flash Cover}, {Material, Weight, Color}) is a formal concept whereas ({Cover, Shutter
Cover, Flash Cover}, {Material}) is not a formal concept. This is because σ ({Cover,
Shutter Cover, Flash Cover}) =: ({Material, Weight, Color}). Also based on the basic
theorem of FCA, ({MAX Outdoor Shutter Cover, MAX HQ Shutter Cover}, {Material,
Weight, Color, Shutter Cover Shape 1}) is a formal subconcept of ({Cover, Shutter
Cover, Flash Cover, MAX Outdoor Shutter Cover, MAX Flash Shutter Cover},
{Material, Weight, Color}).
Table 6-2: Initial multi context cross table of kodak:cover class
81
The initial context presented in Table 6-2 can be manually manipulated to make a
clarified context by merging classes with the same properties and properties with the
same classes. The clarified context does not alter the original concept lattice. The
clarified context for the covers in Table 6-2 is presented in Table 6-3.
For example, the classes ({MAX Outdoor Shutter Cover, MAX Flash Shutter
Cover}) have the same properties; hence, they are grouped as a single clarified class
({MAX Shutter Cover}). In this example, the clarified classes ({Cover, Shutter Cover,
Flash Cover}) are kept separate despite having common properties to reduce the
information loss during ontology formulation while making the ontology adaptable for
future changes. In this case, it is necessary to keep the {Shutter Cover, Flash Cover}
concepts along with the {Cover} concept to distinguish between different types of covers
as one goes down the taxonomic hierarchy. Similarly the properties ({Material, Weight,
Table 6-3: Clarified cross table of kodak:cover class
82
Color}) are kept separate. In the intermediate formal context of the kodak:cover class the
number of classes is reduced from the initial 15 to 9 as shown in Table 6-3. The
development of the OWL ontology for the kodak:cover class resulting from Table 6-3 in
conjunction with supervised pair-wise comparison is described next.
6.2.3 Step 3: Camera Concept Hierarchy Formulation using FCA
The intermediate formal context is entered in ToscanaJ for creating the concept
lattice of the kodak:cover context. The data entry for ToscanaJ is shown in Figure 6-1.
The conversion of the information in Table 6-3 to the representation shown in Figure 6-1
is currently done manually; however, this process could be automated in the future.
The Hasse diagram in Figure 6-2 represents the concept lattice of the kodak:cover
context induced by the relationship between the classes and properties presented in Table
6-3. ToscanaJ automatically generates the Hasse diagram once given the information
shown in Figure 6-1. This example of the kodak:cover context demonstrates one
possibility to interpret the formal concept lattice shown in Figure 6-2, namely, it provides
Figure 6-1: Entering the kodak:cover context into ToscanaJ
83
a hierarchical conceptual clustering of design artifacts for the cover, which may not have
been identified through manual inspection of a set of BOMs, especially as the number of
products and their complexity increases.
The AND-NOT quadrant (see Figure 3-2) is used to find the relationship between
clarified classes ({Cover, Shutter Cover, Flash Cover}). For example, to find the
relationship between {Cover} and {Shutter Cover}, the designer tries to provide
examples for the AND-NOT quadrants. We can provide examples of components that
satisfy {Cover} AND {Shutter Cover}, and {Cover} NOT {Shutter Cover}, but we
cannot provide an example of a component that is {Shutter Cover} NOT {Cover} as
illustrated in Figure 6-3. The examples entail {Cover} as a super-class of {Shutter
Cover} in the OWL ontology as they satisfy (c1 ∧ c2) ∨ c2. The concept lattice is used to
formalize the one-time-use camera product family ontology given next.
Figure 6-2: Concept lattice of the kodak:cover generated by ToscanaJ
84
6.2.4 Step 4: Camera Family Ontology Formation and Enrichment
The order hierarchy of the concept lattice formed using FCA in Figure 6-2 is used
to form the class sub-class hierarchy of the OWL ontology shown in Figure 6-4. The
partial ordering of the concept lattice facilitates the formation of sub-classes of the
kodak:cover class. A component in a sub-class inherits all the properties of the parent
class. For instance, the class ‘Flash_Cover’ is defined with properties such as
‘has_Weight’, and all the child classes (i.e., sub-classes) inherit this property.
In this example, the ‘APS_Flash_Cover’ class and the ‘MAX_Flash_Cover’, sub-
classes of ‘Flash_Cover’, also have ‘has_Weight’ as a property. All the sub-classes have
a “is a” relationship with their parent classes. For example, an individual of type
“MAX_Flash_Cover” is a “Flash_Cover”, which belongs to the “Cover” domain. All of
the properties of class “Cover” show up in “MAX_Flash_Cover”. When designing new
components in the one-time-use camera product family, the designer simply extends (i.e.,
creates sub-class of) one or more of the existing components. Thus the class diagram not
only captures the relationship among components but also helps trace the evolution of the
components in a product family.
Figure 6-3: AND-NOT quadrant for Kodak camera {Cover} and {Shutter Cover}
85
The properties of the camera ontology classes are either DatatypeProperty or
ObjectProperty. Data type properties are given preference while describing basic
attributes of a component, and they are grouped together in generic classes that form
object properties. For example, all the classes that belong to the base class “Component”
have Weight, Color, and Material that are object properties as shown in Figure 6-5.
Figure 6-4: OWL representation of kodak:cover class
86
Thus, the “Washer” class that is a sub-class of class “Component” has the
“has_Weight” property. To capture the weight of a washer, the “has_Weight”
ObjectProperty of the washer class’s “Weight_in_grams” DatatypeProperty, which is a
float, needs to be filled. The complete listing of the base class “Component” for the
Kodak one-time-use camera family is shown in Figure 6-6.
A screen capture of the implementation of the ontology for the one-time-use
cameras using Protégé is shown in Figure 6-7. On the left, the classes are displayed; the
information regarding the current class is either viewed on the right or in a new window.
Figure 6-5: Property reference of Kodak camera component class
Figure 6-6: Component class and sub-classes in the Kodak camera ontology
87
The example shows the class “Film” with its list of properties. Some of these properties
are inherited from the parent class “Component” while others are specific to the class.
For example, the properties “has_Weight”, “has_Material, “has_Color”, etc. are part of
the parent class “Component”, whereas “has_Exposure”, “has_Sensitivity”, and
“Is_Black_and_White” are properties associated with class “Film” and its sub-classes.
As discussed previously, OWL provides a layered set of constructs for different
levels of machine interpretability of design information. This representation of design
terms and their interrelationships can be enriched by the use of these terms in the
ontology hierarchy. Some of the OWL constructs that are used to enrich the kodak:cover
class are shown in Figure 6-8. The enrichment process is done manually by design
Figure 6-7: Protégé IDE showing the Kodak camera ontology
88
knowledge engineers after the ontological class hierarchy is formed and the properties are
associated with the classes.
The concept lattice of the one-time-use cameras that are part of the product family
is shown in Figure 6-9. The order hierarchy of classes ({Camera}, {Single use Film
Camera}, {Film Camera 35 mm}, {MAX Camera}, {MAX Camera Waterproof}) is
highlighted in the figure using dotted lines. The order hierarchy of the concepts helps in
developing the OWL ontology for the product family.
Figure 6-8: Ontology enrichment of kodak:cover class
89
The subsumption hierarchy of the classes of Figure 6-9 is captured using OWL
and is shown in Figure 6-10. To illustrate the transformation of the concept lattice into
an OWL ontology, the camera classes that are highlighted in Figure 6-9 are also
highlighted in Figure 6-10.
Finally, Figure 6-11 shows the source code for the OWL ontology. The first few
lines of the ontology contain the annotation part and specify all the Uniform Resource
Indicator (URI) references. All the classes, sub-classes, and properties are in the first part
of the ontology; the individuals (objects of the classes) follow. Since the OWL file
Figure 6-9: Concept lattice of the kodak:camera generated by ToscanaJ
Figure 6-10: Camera class hierarchy representation using ezOWL
90
conforms to the XML standard, it can be read by any XML parser (it is displayed using
Internet Explorer’s XML parser in Figure 6-11). The complete ontology is stored and
available at: http://edog.mne.psu.edu/owl/kodak.owl.
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 (?classAnyCamera, <KodakFamily:Has_Flash>, ?instanceFlash)
USING KodakFamily FOR <http://edog.mne.psu.edu/ontology/kodak#>” will query the
ontology and list all of the cameras and their corresponding flash components (i.e.,
classes having the Has_Flash property) across the product family. In this case, it would
return {(Plus_Digital, Flash_Max), (MAX_Flash_Camera, Flash_Max), (MAX_HQ,
Figure 6-11: Sample of the Kodak camera ontology
91
Flash_Max), (Advantix_Switchable, Flash_APS), (Black_and_White,
Flash_Black_and_White)}, an array of cameras and flash components.
6.3 Product Platform Knowledge Sharing Using PFUIM
Preconceived ontologies developed using PFODM in the previous section are
used for product platform knowledge sharing using the Product Family Uniform
Information Model (PFUIM). In this section, the Kodak one-time-use camera product
family is used as an example to illustrate the various steps involved in the creation of a
PFUIM.
6.3.1 Step 1: Camera Product Family Product Dissection
As discussed in Section 4.2.1, each product in the Kodak one-time-use camera
family is first dissected to the lowest level possible, leaving sub-assemblies such as the
flash printed circuit board intact for analysis. The Subtract and Operate Procedure (SOP),
the reverse engineering methodology of Otto and Wood [95], is used to dissect and
document the products in a systematic way. The BOM structure of the products is
captured from the documentation of the dissection process.
6.3.2 Step 2: Camera Product Family Entity List Creation
Once the products are dissected and documented, individual lists for each product
describing the customer needs, function structure, and components are created. Table 6-4
92
shows the entity list for the Water & Sport one-time-use camera, covering three distinct
types of design information in the product realization process. As we can see there are
some similarities between the product design information, which we intend to capture
and organize using the proposed PFUIM method. Similar lists of entities are created for
all seven products of the Kodak one-time-use camera family (see Appendix E).
6.3.3 Step 3: Camera Product Family Common Ontology Layer Formation
Once the entity lists are created for each product, a master list for each type of
design information is made by combining all of the entities from each individual product
Table 6-4: Kodak Water & Sport one-time-use camera entity list creation
93
in the family. Duplicate listings of entities are removed from this list. Then using
PFODM, the generic ontology is created and represented using OWL.
Figure 6-12 shows the master list of customer needs and the corresponding
ontological hierarchy. Each node in the OWL ontology represents a single class, and the
arrows capture the “is a” hierarchy between the classes. For example, the class
{kodak_Durability} “is a” type of class {kodak_Customer_Need}. The class
{kodak_Ease_of_use} has object properties called ({has_date-time_imprint},{
has_sunscreen}, {has_carryon_strap}, {has_film_counter}). The hierarchy diagram is
automatically made from the OWL ontology using the ezOWLplugin in Protégé-2000
[99]. The ontology captures the generic concepts and their attributes that cover all seven
products in the Kodak one-time-use camera family.
Similarly, the camera product functions are aggregated, and a generic ontology is
created for the entire product family, which is shown in Figure 6-13. The ontology for
Figure 6-12: Development of camera ontology from aggregated customer needs
94
product functions is unique to every product family although a higher-level ontology can
capture generic concepts across different product families.
Section 6.2.4 describes the development of the ontology for components of the
Kodak product family. Each of the ontologies for a particular product family is stored in a
different OWL file on the web server. When representing any design artifact for a
product, an instance of the OWL ontology class is used. For example the customer need
“Durability” for Kodak Water & Sport camera is an instance of class
{kodak_Durability}.
6.3.4 Step 4: Mapping Between Heterogeneous Design Information in Camera Product Family
After creating the ontologies and the individual instances, the entities between the
three types of design information are mapped using the Product Vector Matrix (PVM)
and the Function Component Matrix (FCM). As discussed in Section 4.2.4, the mappings
Figure 6-13: Ontology of Kodak one-time-use camera functions
95
are unique for every product in the family and are created using the instances of the OWL
ontology.
The PVM captures the relationships between the customer needs and product
functions. Figure 6-14 shows the PVM for the Kodak Water & Sport one-time-use
camera. The customer needs are presented on the top of the matrix, and the product
functions are on the left side of the matrix. As described in Section 4.1.4, for each
function that impacts a particular customer need, a ‘1’ is entered into the cell in the
matrix. For example, the customer need {rugged and durable} is fulfilled by functions
({actuate me}, {guide me}, {store solid}, {translate solid}, {link solid}). Similar
matrices are created for every product in the product family.
Figure 6-14: Kodak Water & Sport camera product vector matrix
96
Next, the relationship between product functions and product components are
captured by making the FCM. Figure 6-15 shows the FCM for the Kodak Water & Sport
one-time-use camera.
6.3.5 Step 5: Kodak Product Family Design Information Aggregation
The common ontological layer in conjunction with PVM and FCM help in
automatic design information aggregation across phases, and the BOM structure helps
design information aggregation across products in a single phase for the designers.
Figure 6-15: Kodak Water & Sport camera FCM
97
6.3.5.1 Design Information Aggregation Spanning Multiple Products
The design information is aggregated by going back and forth between the
common ontology layer and the design entities instances. For example, let us consider a
scenario where the designer is redesigning the {Waterproof shutter cover}. The
information model can aggregate all the shutter covers used in the entire product family
by first getting the class {Shutter Cover} from which the individual {Waterproof shutter
cover } is an instance and then listing all the other instances of type {Shutter Cover}, i.e.,
({MAX shutter cover}, {Advantix shutter cover}, {Black & white shutter cover}). The
information model can also compare the attributes of each shutter cover and present them
to the designer. This automatic context-based aggregation of design information can be
applied to all of the design entities in each phase of product realization.
The PVM and FCM help aggregate the information across different phases of
product design. The Water & Sport camera customer need {rugged and durable} is
satisfied by five product functions ({actuate mechanical energy}, {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
wheel2}). Combining the common ontologies,the PVM, and the FCM with a product
BOM makes the design information model transparent, flexible, and interoperable across
a network of different systems.
98
6.3.5.2 Design Information Aggregation across Design Information Structures
Using the one-time-use camera product family ontology, product designers can
also 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 (?classAnyCamera,
<KodakFamily:Has_Flash>, ?instanceFlash) USING KodakFamily FOR
<http://edog.mne.psu.edu/ontology/kodak#>” can query the ontology and list all of the
cameras and their corresponding flash components (i.e., classes having Has_Flash
property) within the product family. In this case, it would return {(Plus_Digital,
Flash_Max), (MAX_Flash_Camera, Flash_Max), (MAX_HQ, Flash_Max),
(Advantix_Switchable, Flash_APS), (Black_and_White, Flash_Black_and_White)}, an
array of cameras and flash components. The semantic query and retrieval is currently
being implemented directly on the design repository to facilitate designer initiated web-
based design exploration.
6.4 Product Family Redesign using PFRRF
Before redesigning the family of Kodak one-time-use cameras, each product is
dissected to the lowest level, and each component in each product is stored in a
spreadsheet. For ease of understanding, only 4 products (out of 7 different cameras) and
9 components are considered in this analysis (out of 42 different components). This will
99
not limit the recommendations and conclusions however. The components are listed in
Table 6-5. The products are in rows, while the components are listed in columns. The
product-component formal context table is created next.
6.4.1 Kodak Cameras Formal Concept Analysis using ToscanaJ
The data from Table 6-5 is entered manually in ToscanaJ (see Figure 6-16), a
dedicated software to plot lattice structures based on objects/attributes tables. Once the
data has been entered, the next step is to specify how to consider each attribute (here the
components). For the components that are common or unique, only one concept is
defined. For example, if we look at the first component, Arm 1, this component is
common throughout the whole family; hence, only one concept is defined: has Arm 1
(see Figure 6-17).
Table 6-5: Kodak one-time-use cameras and components analyzed in this study
100
For the components that are variant in the product family (that is to say there are
two or more instances of this component), more concepts need to be defined. For
example, Back Panel has two different instances. In this case, three concepts are defined:
has Back Panel 1, has Back Panel 2, and has Back Panel (see Figure 6-18), where has
Back Panel is a concept that groups has Back Panel 1 and has Back Panel 2.
Once all of the concepts are defined, the software automatically generates the
Hasse diagram shown in Figure 6-19. The concept associated with the attributes (e.g.,
has Back Panel) are shown above the nodes, while the objects (i.e., the products within
Figure 6-16: Entering one-time-use camera data in ToscanaJ
Figure 6-17: Example of entry for a common camera component
Figure 6-18: Example of entry of a variant camera component
101
the product family) are shown below the nodes. Note that the nodes associated with
objects are larger than the nodes only associated with concepts for ease of visualization.
At the top of the Hasse diagram in Figure 6-19, we can see the concepts that are
common throughout the entire product family. In this case, six concepts are identified:
has Exposure Counter, has Film, has Arm 1, has Arm 2, has Cam and has Back Panel.
These six concepts tell us that all the cameras have an exposure counter, a film, an arm 1,
an arm 2, a cam and a back panel.
Figure 6-19: Hasse diagram for the Kodak one-time-use cameras
102
6.4.2 Component-Based Approach to Redesign the Kodak Cameras
This approach aims at reusing critical component instances throughout a product
family while giving preference to making variant components common over unique
components variant. Let us consider the Film. We can see that all of the cameras have a
film (the concept Has Film is found in the top node). If we now go down into the graph,
two concepts are found for has Film: has Film 1 and has Film 2. Below the node where
has Film 1 is found, we can identify three products: Plus Digital, MAX Flash, and MAX
Water & Sport, while there is only one product below node Has Film 2. The
recommendation is to change Film 2 to Film 1, if possible. Note that no other
consideration except the algorithm presented in Figure 5-5 is used here, and other
constraints, such as the cost of the components and technical feasibility, could affect the
recommendation. Similarly, all of the other components can be chosen, and the same
methodology can be applied.
6.4.3 Product-Based Approach to Redesign the Kodak Cameras
This approach aims to improve commonality between multiple products in the
product family. Let us consider two products: the MAX HQ and the MAX Water &
Sport. Using the algorithm shown in Figure 5-7, the following recommendations are
given to improve commonality between the two products. The first recommendation is to
make the exposure counter common between the two products: in the original design, the
two products both use exposure counters, but two different instances exist. Implementing
these recommendations will remove the concepts has Exposure Counter 1 and has
103
Exposure Counter 2 and will “push” this concept to the parent node as has Exposure
Counter. Based on the algorithm developed (see Figure 5-7), the Back Panel, and the
Film are the possible other changes. Note that this recommendation is given as possible
choices and it involves all of the products in the family. These recommendations are
given without checking the technical feasibility of such changes. In this research, no
constraints are given to the products (such as “MAX HQ can only be equipped with Film
2”), and the feasibility of the proposed redesign solutions can be included as an extension
to further reduce the redesign space. The proposed method rather focuses on how to use
Formal Concept Analysis to represent product families and how to analyze these graphs.
These three recommendations seek to make variant components common throughout the
family. The assessment of the effect of the implementation of the recommendation of
making exposure counter common on the commonality in the family is discussed next.
6.4.4 Post-Redesign Commonality Assessment
Table 6-6 shows the result of using the three commonality indices presented in
Section 5.4 (see Equations 5.1, 5.2, and 5.3). For the product-based redesign approach
the first recommendation given in Section 6.4.3 (i.e., making the exposure counter
common between the two cameras) is implemented. For the component-based redesign,
the focus is on making the film common throughout the family. In both cases, the value
of the commonality indices increases, meaning that there is an overall increase in
commonality in the product family (see Appendix B).
104
6.5 Discussion and Preview
This chapter demonstrated and validated the PFODM, PFUIM, and PFRRF
through a case study involving a homogeneous product family. The product family
ontology for Kodak one-time-use cameras was systematically developed using PFODM.
A common ontological meta-layer was formed in the Kodak one-time-use camera to
share design information across three phases of product design as well as across seven
products in the product family. Four of the Kodak one-time-use cameras are redesigned
using PFRRF, and the commonality is improved in the product family using both the
product-based approach and the component-based approach. In the next chapter, a
power tool product family is analyzed to demonstrate and validate the proposed
methodologies using a heterogeneous product family.
Table 6-6: Commonality indices before and after camera redesign
Chapter 7
Case Study 2: Knowledge Management in a Heterogeneous Product Family
In this chapter the proposed methods for product family knowledge management
introduced in Chapter 3 (PFODM), Chapter 4 (PFUIM), and Chapter 5 (PFRRF) is
demonstrated using a heterogeneous product family. A heterogeneous product family has
products that have different dominant functionality shared between the products.
7.1 Introduction to the Power Tool Product Family
Power tools are designed to meet the needs of amateur and professional users for
a variety of home and outdoor projects like interior and exterior home remodeling,
plumbing, heating, air conditioning, flooring, ventilating, and vehicle maintenance.
Power tool product families usually contain a drill, a saw, a rotary tool, and a flash light.
These products contain a collection of electrical and mechanical components to satisfy
the diverse customer needs, thus providing a rich set of design information for validating
the proposed knowledge management methodologies.
The Black & Decker Versapak family contains six different tools (see Figure 7-1):
a cordless circular saw, a cordless reciprocating saw, a cordless drill, a cordless
screwdriver, a cordless rotary tool, and a flashlight (see Appendix C). In the Versapak
product family, each product has a specific function, but they still share some common
components (such as the rechargeable battery). The individual tools primary functions
are unique but some of the sub-functions (such as power supply) are shared across all the
106
models. Details about the product family and their dissection can be found in Refs.
[110,111]. In this chapter, the Black & Decker Versapak product family is used to
demonstrate the PFODM (see Section 7.2), the PFUIM (see Section 7.3) and the PFRRF
(see Section 7.4).
7.2 Product Platform Design Information Representation & Encoding Using PFODM
In order to demonstrate the steps of PFODM we discuss the Black & Decker
cover class (bd:cover) that is a part of the Black & Decker Versapak power tool family.
A group of front, back, left, and right covers are formalized as part of the ontology using
the proposed PFODM.
Figure 7-1: Black & Decker Versapak product family
107
7.2.1 Step 1: Component Lexicon Acquisition and Pruning
The lexicon set for the power tool is developed by dissecting the products to their
component levels. The components can not be further decomposed and are considered as
the basic design artifacts. After the products are disassembled, all the terms associated
with the components are collected in a dictionary form, including any synonyms for the
components. Based on this dictionary of terms or lexicon set the power tool product
family ontology is formalized. To describe the cover of a drill the lexicon set L1 =:
{Drill right cover, Drill front cover, Right cover of drill} can be used. In the next step,
the lexicon set is reduced such that a one-to-one relationship is formed between the
component and the term describing it; hence, after lexicon pruning, the drill cover for the
Black & Decker drill is L1 =: {Drill right cover}. All of the other synonyms for the
component can still be saved for reference, but they will not be used as a part of the
formal ontology. Properties of the components that are of interest for the power tool
domain are also collected, e.g., P1 =: {Weight, Material, Color, Cover Shape,
Orientation}.
7.2.2 Step 2: Formal Context Composition of the Power Tool Cover Class
The second step is to put the lexicon set in a cross table with the rows describing
the classes and the columns capturing the properties. Table 7-1 describes the initial cross
table for all the covers present in the power tool family. The rows capture the possible
classes for the formal ontology, and the columns capture the properties associated with
the cover classes.
108
After disassembly, we found that all of the covers have a different shape. So,
there are twelve different types of cover shapes in the family. Also, there are four types of
orientations associated with the covers. In Table 7-1 the relation R between these cover
classes and their multi-context properties is captured. Next, the initial context formed in
Table 7-1 is manually manipulated to construct the clarified intermediate formal context.
The clarified intermediate formal context for the covers in Table 7-1 is presented in
Table 7-2 .
Table 7-1: Initial multi context cross table of bd:cover class
109
In this example, the clarified classes ({Component, Cover}) are kept separate
despite having common properties to reduce the information loss during ontology
formulation while making the ontology adaptable for future changes. The properties
({Material, Weight, Color}) are kept separate for the same reason.
7.2.3 Step 3: Concept Hierarchy Formulation using FCA
The intermediate formal context is entered in ToscanaJ for creating the concept
lattice of the bd:cover context. The data entry for ToscanaJ is shown in Figure 7-2.
Table 7-2: Clarified cross table of bd:cover class
110
The Hasse diagram in Figure 7-3 represents the partially ordered structure or the
concept lattice of the bd:cover context induced by the relationship between the classes
and properties presented in Table 7-2. This example of the bd:cover context
demonstrates one possibility to interpret the formal concept lattice shown in Figure 7-3,
namely, it provides a hierarchical conceptual clustering of design artifacts for the cover,
which may not have been identified through manual inspection of a set of BOMs. The
AND-NOT quadrant (from Figure 3-2) is next used to find the relationship between
clarified classes ({Component, Cover})
Figure 7-2: Entering the bd:cover context into ToscanaJ
111
7.2.4 Step 4: Power Tools Ontology Formation and Enrichment
The order hierarchy of the concept lattice formed using FCA in Figure 7-3 is used
to form the class sub-class hierarchy of the OWL ontology shown in Figure 7-4. The
partial ordering of the concept lattice facilitates the formation of sub-classes of the
kodak:cover class.
Figure 7-3: Concept Lattice of the bd:cover generated by ToscanaJ
112
The properties of the power tool ontology classes are either DatatypeProperty or
ObjectProperty. Data type properties are given preference while describing basic
attributes of a component, and they are grouped together in generic classes that form
object properties. For example, all the classes that belong to the base class “Component”
have Weight, Color, and Material that are object properties.
Figure 7-4: OWL representation of bd:cover class
113
The complete listing of the base class “Component” for the power tool family is
shown in Figure 7-5. The concept lattice of the power tool products that are part of the
product family is shown in Figure 7-6. The order hierarchy of the concepts helps in
developing the OWL ontology for the product family
The subsumption hierarchy of the classes of Figure 7-6 is captured using OWL
and is shown in Figure 7-7.
Figure 7-5: Component class and sub-classes of the power tool ontology
Figure 7-6: Concept Lattice of the Versapak:power tools generated by ToscanaJ
114
Using the power tool product family ontology, product designers can explore
various types of power tools as well as the components that are part of the power tool
family. The power tool product family ontology can also be queried using semantic
queries based on graph pattern matching that can span multiple products across the entire
ontology.
7.3 Product Platform Knowledge Sharing Using PFUIM
Preconceived ontologies developed using PFODM in the previous section are
used for product platform knowledge sharing using the Product Family Uniform
Information Model (PFUIM). In this section Black & Decker Versapak product family is
used as an example to illustrate the various steps involved in the creation of a PFUIM.
7.3.1 Step 1: Versapak Product Family Product Dissection
As discussed in Section 4.2.1, each product in the Versapak family is first
dissected to the lowest level possible, leaving sub-assemblies such as motors and trigger
Figure 7-7: Power tool class hierarchy representation using ezOWL
115
mechanisms intact for analysis. SOP, the reverse engineering methodologies of Otto and
Wood [95], is used to dissect and document the products in a systematic way. The BOM
structure of the products is captured from the documentation of the dissection process.
Figure 7-8 shows the BOM structure for the Versapak drill. Similar documentation is
created for all the six products of the product family (see Appendix F).
7.3.2 Step 2: Versapak Product Family Entity List Creation
Once the products are dissected and documented, individual lists for each product
describing the customer needs, function structure, and components are created. Figure 7-
9 shows the entity list of the Versapak drill and Versapak flash light, covering three
distinct types of design information in the product realization process. As we can see
there are some similarities between the product design information, which we intend to
capture and organize using the proposed common ontologies method. Similar lists of
entities are created for all six products of the Versapak product family.
Figure 7-8: A part of the bill of material for Versapak drill
116
7.3.3 Step 3: Versapak Product Family Common Ontology Layer Formation
Once the entity lists are created for each product, a master list for each type of
design information is made by combining all the entities from each individual product in
the family. Duplicate listings of entities are removed from this list. Then using PFODM
[112], the generic ontology is created and represented using OWL.
Figure 7-10 shows the master list of customer needs and the corresponding
ontological hierarchy. Each node in the OWL ontology represents a single class, and the
arrows capture the “is a” hierarchy between the classes. For example class
(a) Versapak Drill
(b) Versapak Flash Light
Figure 7-9: Versapak product family entity list creation
117
{versapack.Appearance} “is a” type of class {versapack.Customer.Need}. The class
{versapack.Appearance} has object properties
({versapack.has.Finish},{Versapak.has.Color}). The hierarchy diagram is automatically
generated from the OWL ontology using ezOWL11 plugin in Protégé-2000 [36]. The
ontology captures the generic concepts and their attributes that represent all the products
in the Versapak product family.
Similarly, the product functions are aggregated, and a generic ontology is created
for the entire power tool product family, which is shown in Figure 7-11. The ontology
for product functions is unique to every product family though a higher-level ontology
can capture generic concepts across different product families.
11 http://iweb.etri.re.kr/ezowl/index.html
Figure 7-10: Development of power tool ontology from aggregated customer needs
118
Figure 7-12 shows a partial hierarchy of the OWL ontology that captures the
relationship between different components that are part of the Versapak product family.
The components are arranged in an “is a” hierarchy, which captures the semantics of the
components.
Each of the ontologies for a particular product family is stored in a different OWL
file on the web server. When representing any design artifact for a product, an instance
of the OWL ontology class is used. For example a gear used in the Versapak drill is an
instance of class {versapak.Gear}. The customer need “Affordability” for the Versapak
drill is an instance of class {versapak.Affordability}.
Figure 7-11: Ontology of power tool product functions
Figure 7-12: Ontology of product family components
119
7.3.4 Step 4: Mapping Between Heterogeneous Design Information in Versapak Product Family
After creating the ontologies and the individual instances, the entities between
the three types of design information are mapped using Product Vector Matrix (PVM)
and Function Component Matrix (FCM). As discussed in Section 4.2.4, the mappings are
unique for every product in the family and are created using the instances of the OWL
ontology. Figure 7-13 shows the PVM for the Versapak drill. The customer needs are
listed along the top of the matrix, and the product functions are on the left side of the
matrix. As described in Section 4.1.4, for each function that impacts a particular
customer need, a ‘1’ is entered into the cell in the matrix. For example, the customer need
{circular action (torque)} is fulfilled by functions ({change torque}, {convert electricity
to torque}, {transmit torque}). Similar matrices are created for every product in the
product family.
Figure 7-13: Versapak drill product vector matrix
120
Next, the relationship between each product function and its components are
captured by making the FCM. Figure 7-14 shows the FCM for Versapak drill. Here also
a ‘1’ is entered into the cell of a matrix for the components that impact a particular
product function. For example, the product function ({change torque}) is fulfilled by
components ({Connecting gear subassembly}, {Chuck/Drive train subassembly}). The
FCM matrices are created for all the six products in the product family. The detail of
design information aggregation is described in the next section.
7.3.5 Step 5: Versapak Product Family Design Information Aggregation
The common ontological layer in conjunction with PVM and FCM help in
automatic design aggregation across phases, and the BOM structure helps aggregate
design information across products in a single phase for the designers.
Figure 7-14: Versapak drill function component matrix
121
The design information is aggregated by going back and forth between the
common ontology layer and the design entities instances. For example let us consider a
scenario where the designer is redesigning the {Versapak drill motor}. The system can
aggregate all the motors used in the entire product family by first getting the class
{Motor} from which the individual {Versapak drill motor} is an instance and then listing
all other instances of type {Motor}, i.e., ({Versapak screwdriver motor}, {Versapak
rotary tool motor}, {Versapak reciprocating saw motor}, {Versapak circular saw
motor}). The system can also compare the attributes of each motor and present them to
the designer. Information presented to designers about similar components not only
facilitates the redesigning of existing products but also while introducing new products in
a product family. This automatic context-based aggregation of design information can be
applied to all of the design entities in every phase of product realization.
The PVM and FCM help aggregate the information across different phases of
product design. Figure 7-15 shows the mapping for Versapak drill.
The Versapak drill customer need {circular action} is satisfied by three product
functions: ({change torque}, {convert electricity to torque}, {transmit torque}).
Similarly, the product function {change torque} is fulfilled by two components
({connecting gear subassembly}, {chuck/drive train subassembly}). Combining the
Figure 7-15: Versapak design information aggregation
122
common ontologies, PVM, and FCM with a product BOM makes the design information
model transparent, flexible, and interoperable across network of different systems.
7.4 Product Family Redesign Using PFRRF
In this section several products from the Black & Decker Versapak power tool
family are used to demonstrate the Product Family Representation and Redesign
Framework (PFRRF). For the ease of understanding, only 7 components are considered
in this analysis (see Table 7-3). This will not limit the recommendations and conclusions
as the component information analyzed represent every kind of components (e.g.,
common, variant, and unique) found in a product family. The products are in rows, while
the components are listed in the columns. The product-component formal context table is
created next.
7.4.1 Formal Concept Analysis Using ToscanaJ
The data from Table 7-3 is manually entered in ToscanaJ (see Figure 7-16).
Table 7-3: Black & Decker power tool products and components analyzed in this study
123
Once the data has been entered, the next step is to specify how to consider each
attribute (here the components). For the components that are common or unique, only
one concept is defined. For example, if we look at the first component, Battery, this
component is common throughout the entire four products; hence, only one concept is
defined.
Once all of the concepts are defined, the software automatically generates the
NBOM shown in Figure 7-17. The concept associated with the attributes (e.g., has
Battery) are shown above the nodes, while the objects (i.e., the products within a product
family) are shown below the nodes (e.g., Drill).
At the top of the NBOM in Figure 7-17, we can see the concepts that are common
to the four products in the family. In this case, seven concepts are identified: has Battery,
has Bottom housing, has Button, has Switch, has Wires, has Motor and has Battery
Connection. These seven concepts tell us that the four power tools considered have a
battery, a bottom housing, a button, a switch, wires, a motor and a battery connection.
Figure 7-16: Entering Versapak power tool data in ToscanaJ
124
7.4.2 Component-Based Approach to Redesign the Power Tools
This approach aims at reusing critical component instances throughout a product
family while giving preference to making variant components common over unique
components variant. Let us consider the Switch. We can see that all the power tools
have a switch (the concept has Switch is found in the top node). If we now go down into
the graph, three concepts are found for has Switch: has Switch 1, has Switch 2, and has
Switch 3. Below the node where has Switch 1 is found, we can identify two products:
Circular Saw and Reciprocating Saw, while there is one product below the node has
Switch 2 and one below has Switch 3. The recommendation is to change Switch 2 and
Switch 3 to Switch 1 if possible. Note that no other consideration except the algorithm
Figure 7-17: Hasse diagram for the Versapak power tool family
125
presented in Figure 5-5 is used here, and other constraints, such as the cost of the
components and technical feasibility, could affect the recommendation. Similarly, other
components can be chosen, and the same approach can be applied.
7.4.3 Product-Based Approach to Redesign the Power Tools
This approach aims at improving commonality between multiple products in the
product family. Let us consider three products: the Drill, the Rotary Tool and the
Circular Saw. Using the algorithm shown in Figure 5-7, the following recommendations
are given to improve commonality between the three products. One recommendation is
to make the motor common between the three products: in the original design, the three
products all use motors, but three different instances exist. Implementing these
recommendations will remove the concepts has Motor 1, has Motor 2, and has Motor 4
and will “push” this concept to the top node as has Motor. This change will also make
the property has Motor 3 common. Another recommendation will be to make the switch
common across the products. Both recommendations lead to the same change in
commonality and in this case the designer has to decide which change will be better for
the redesign based on other parameters, such as cost. The assessment of the effect of the
implementation of these recommendations on commonality in the family is discussed
next.
126
7.4.4 Post-Redesign Commonality Assessment
Table 7-4 shows the results of using the three commonality indices presented in
Section 5.4. For the product-based redesign, the first recommendation given in Section
7.4.3 (i.e., making the motor common between the four power tools) is implemented. For
the component-based redesign, the focus is on making the switch common throughout the
family. In both cases, the value of the commonality indices increases, meaning that there
is an overall increase in commonality in the product family (see Appendix D).
7.5 Comparison between Homogeneous and Heterogeneous Product Families
Table 7-5 lists some of the patterns observed during the development and
validation of the proposed Knowledge Management System for homogeneous and
heterogeneous product families. The remarks listed in Table 7-5 are subjective in nature,
and further research is needed to statistically verify the conclusions drawn.
When developing the lexicons of design artifacts as part of PFODM it is observed
that the number of concepts needed to describe the design space is much larger for
heterogeneous product families. This translates into an increase in the computational
expense of creating the NBOM. The ontology development time remains almost the
Table 7-4: Commonality indices before and after power tool redesign
127
same between homogeneous and heterogeneous product families as the taxonomic and
partonomic relationships are already captured as part of the NBOM .
The ontology development in PFUIM for both homogeneous and heterogeneous
product family for different phases of product development is essentially the same. Due
to the diversity in the components used in the development of heterogeneous product
family, the utility of ontologies and information sharing is more useful. The diversity in
design artifacts makes the ontology graph structure sparse in case of heterogeneous
product family, where as the similarity in design artifacts in case of homogeneous
product family makes the ontological graph structures dense.
The NBOM graph structure is dense for homogeneous product families, and thus
the computational effort associated in moving nodes is less as compared to heterogeneous
product families. The utility in product family redesign remains same as the
commonality analysis is currently performed only on component redesign. Inclusion of
additional factors in redesigning, such as cost, technical feasibility, etc. may change this
observation.
128
7.6 Discussion and Preview
This chapter demonstrated and validated PFODM, PFUIM, and PFRRF through a
case study involving a heterogeneous product family. The product family ontology for
the Black & Decker Versapak power tool set was systematically developed using
PFODM. A common ontological meta-layer was formed for the Black & Decker
Versapak power tools to share design information across three phases of product design
as well as across six products of the family. Four power tools in the product family were
redesigned using PFRRF, and the commonality is improved in the product family using
both product-based approach and the component-based approach. Section 7.5 discusses
some of the observations made during the development and validation of proposed
Table 7-5: Comparison of methods for homogeneous and heterogeneous product families
129
methodologies. In the next chapter the research summary, research contributions and
future work are discussed.
Chapter 8
Contributions, Recommendations, and Future Work
In this dissertation, simple yet innovative methodologies are introduced for
systematic design and development of product families during all phases of the product
realization process. A summary of the research follows, and contributions from the work
are described in Section 8.2. Future work is then discussed in Section 8.3.
8.1 Research Summary
Representing product families in a knowledge base by preconceived common
ontologies shows promise in promoting component sharing, and assisting search and
exploration of linguistic and parametric design information over various phases of the
product realization process while spanning multiple products in a family. Product vector
and function component mapping matrices along with the common ontologies are utilized
for designer initiated information exploration, aggregation, and analysis. Use of FCA in
the development of NBOM structure and application of commonality indices provide a
systematic way for redesigning existing product families and increase product family
commonality. The following section elaborates the research contributions in detail.
131
8.2 Contributions from the Research
To manage design knowledge associated with a group of related products, there
are three main parts to the proposed knowledge management system: (i) the Product
Family Ontology Development Framework (PFODM), (ii) the Product Family Uniform
Information Model (PFUIM) [113], and (iii) the Product Family Representation and
Redesign Framework (PFRRF) [114]. The contributions from each are discussed next.
8.2.1 Product Family Ontology Development Framework (PFODM)
The use of ontologies for information sharing is well documented in the literature.
The lack of a comprehensive and integrated methodology for building product ontologies
has limited the process of developing design artifact ontologies. Formal product
representation using ontologies can (i) facilitate design information sharing over the
Internet, (ii) store both the taxonomic and partonomic structures of several products in a
product family, and (iii) capture the evolution of different components in the product
family. As part of this research, PFODM, a novel methodology to develop formal
product ontologies using the Semantic Web paradigm, is developed. Within PFODM,
Formal Concept Analysis (FCA) is used first to identify similarities among a finite set of
design artifacts based on their properties by creating a NBOM and then to develop and
refine a product family ontology using the Web Ontology Language (OWL). The benefit
of PFODM lies in providing a systematic and consistent methodology for constructing
ontologies to support product family design. PFODM, for the first time, provides a
unified methodology for proceeding from design vocabulary to an ontological
132
implementation for the product family. PFODM supports an explicit and fully
documented way of developing product family design ontologies. The resulting
ontologies, represented as a directed cyclic labeled graph, provide a hierarchical
conceptual clustering of related design artifacts, which is particularly advantageous for
product family design where parts, processes, and mostly importantly, information is
intentionally shared and reused to reduce complexity, lead-time, and development costs.
8.2.2 Product Family Uniform Information Model (PFUIM)
PFUIM proposes a flexible information model for systematic development and
deployment of product families during multiple phases of the product realization
proposes. PFUIM is used to capture, share, and organize product design contents,
concepts, and contexts across different phases of the product realization process using a
Web Ontology Language (OWL) representation. Representing product families by
preconceived common ontologies shows promise in promoting component sharing and
facilitating search and exploration of design information over various phases of their
development and spanning multiple products in a family. Three distinct types of design
information, namely (1) customer needs, (2) product functions, and (3) components,
captured during different phases of the product realization process are considered in this
work to demonstrate the proposed unified information model. Product Vector and
Function Component Mapping Matrices along with the common ontologies are utilized
for designer-initiated information exploration and aggregation. Context-based design
information exploration and aggregation provides the designer insight into different
133
components that are part of the product family and not just a single product. This
facilitates the analysis of relationships in the design space within a product family that
are otherwise difficult to identify in a single product-centric representation.
8.2.3 Product Family Representation and Redesign Framework (PFRRF)
PFRRF is also based on Formal Concept Analysis (FCA) and can be applied
systematically to (1) visualize a product family and (2) improve commonality in the
product family. Within this framework, the components of a product family are
represented as a NBOM using FCA. A Hasse diagram composed of the lattice structure
graphically represents all the products, components, and the relationships between
products and components in the product family NBOM. The NBOM structure is then
analyzed to identify prospective components to redesign to improve commonality. Two
approaches have been proposed as part of this product family redesign methodology: (1)
component-based approach, and (2) product-based approach. In the component-based
approach, emphasis is given to a single component that could be shared among the
products in a product family to increase commonality. In the product-based approach,
multiple products from a product family are selected, and commonality is improved
among the selected products. Three commonality indices are used to assess the degree of
commonality within a product family during its redesign.
Figure 8-1 shows a scenario in which the proposed research can be used in a
product-oriented organization. A unified platform information model is developed to
represent various phases of product design by an Ontology Manager. Multiple products
134
in a product family are represented as instances of the unified information model.
Various role-based as well as need-based views can be created from these product
instances and are presented to the users of the organization. A Bill of Material, for
example, will be a view that is generated from the product instance. Product family
optimization will be performed on the product instance graph structure or using multiple
views of the product instance. These views will also be integrated with existing product
design management software, computer-aided design software, and optimization
software. These views can also be shared easily over the Internet as the product family
information is presented using Web Ontology Language (OWL).
8.3 Future Work
In future work, the granularity of product design knowledge can be increased by
capturing design information structures such as process planning, component cost,
Figure 8-1: Use of Platform Information Model for product family knowledge
management
135
geometric features and technical feasibility, etc. into the Knowledge Management
System. Also, PFODM needs to be automated by implementing a software translator that
converts the NBOM structure to ontologies. Handling part of the ontology structure (e.g.,
a sub-graph), while developing product families, needs to be studied.
The PFUIM can be further extended to include information from other phases in
product family design, such as manufacturing information, component sourcing, process
planning etc. Inclusion of more phases as part of the uniform information model will
facilitate a more holistic analysis of the product family.
Cost savings and technical feasibility of product family redesign recommendation
need to be incorporated as part of the PFRRF. At particular level of abstraction it may be
difficult to access the final feasibility of a redesigned component or product . Research
needs to be done to find out ways in which feasibility across various abstractions can be
maintained during product family design.
The Knowledge Management System, in its current form (see Figure 1-2), also
does not support the inclusion of component behaviors. Component behaviors need to be
incorporated as part of the system to analyze continuous performance measures like heat
transfer, fluid flow, etc. OWL is backed by Description Logic (DL) [54], which makes it
easier for computers to interpret the semantics without human intervention. As the
product platform design ontologies grow, inference should be included for automatic
design information interpretation.
Providing structure to the largely unstructured design information is necessary for
any product-oriented organization. Towards this end, a lot of research in information
management still needs to be performed. The current research formalizes some of the
136
aspects of product family knowledge management and a lot of research still needs to be
done for building the foundation and theory for design knowledge management.
Bibliography
[1] Simpson, T. W., 2004, "Product Platform Design and Customization: Status and Promise," Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 18(1), pp. 3-20.
[2] Bourke, R., 1999, "Product Information Management: Product Lifecycle Management in Complex Industries," http://industrydirections.com/midrange/rb0499.htm, March 24, 2004, MidRange ERP.
[3] Szykman, S., Racz, J., Bochenek, C. and Sriram, R. D., 2000, "Web-based System for Design Artifact Modeling," Design Studies, 21(2), pp. 145-165.
[4] Bohm, M. R., Stone, R. B. and Szykman, S., 2005, "Enhancing Virtual Product Representations for Advanced Design Repository Systems," Journal of Computing and Information Science in Engineering, 5(4), pp. 360-372.
[5] Dixon, J. and Poli, C., 1999, Engineering Design & Design for Manufacturing: A Structured Approach, Field Stone Publishers, Conway, MA, USA.
[6] Meyer, M. H. and Lehnerd, A. P., 1997, The Power of Product Platforms: Building Value and Cost Leadership, Simon and Schuster Inc., New York, NY, USA.
[7] Robertson, D. and Ulrich, K. T., 1998, "Planning Product Platforms", Sloan Management Review, 39(4), pp. 19-31.
[8] Ulrich, K. T. and Eppinger, S. D., 2003, Product Design and Development, Third Edition, McGraw-Hill/Irwin, New York.
[9] Sanderson, S. and Uzumeri, M., 1995, "Managing Product Families: The Case of the Sony Walkman," Research Policy, 24(5), pp. 761-783.
[10] Feitzinger, E. and Lee, H. L., 1997, "Mass Customization at Hewlett-Packard: The Power of Postponement," Harvard Business Review, Boston, MA, pp. 116-122.
[11] Whitney, D. E., 1993, "Nippondenso Co. Ltd: A Case Study of Strategic Product Design," Research in Engineering Design, 5(1), pp. 1-20.
[12] Pine II, J. B., 1993, "Standard Modules Allow Mass Customization at Bally Engineering Structures," Planning Review, 21(4), pp. 20-22.
[13] Sabbagh, K., 1996, Twenty-First Century Jet: The Making and Marketing of the Boeing 777, Scribner, New York, NY, USA.
[14] Naughton, K., Thornton, E., Kerwin, K. and Dawley, H., 1997, "Can Honda Build a World Car?" Business Week, September 8, pp. 100-107.
138
[15] Rothwell, R. and Gardiner, P., 1990, "Robustness and Product Design Families," Design Management: A Handbook of Issues and Methods, M. Oakley, ed., Cambridge, MA, USA, Basil Blackwell Inc., pp. 279-292.
[16] Lehnerd, A. P., 1987, "Revitalizing the Manufacture and Design of Mature Global Products," Technology and Global Industry: Companies and Nations in the World Economy, B. R. Guile and H. Brooks, eds., Washington, D.C., USA, National Academy Press, pp. 49-64.
[17] Dixon, J. R. and Poli, C., 1999, Engineering Design & Design for Manufacturing: A Structured Approach, Field Stone Publishers, Conway, MA, USA.
[18] Claesson, A., Johannesson, H. and Gedell, S., 2001, "Platform Product Development: Product Model a System Structure Composed of Configurable Components," 13th International Conference on Design Theory and Methodology, September 9-12, Pittsburgh, PA, United States, American Society of Mechanical Engineers, Vol. 4, pp. 317-326.
[19] Shooter, S. B., Keirouz, W. T., Szykman, S. and Fenves, S. J., 2000, "A Model for the Flow of Design Information in Product Development," Journal of Engineering with Computers, 16(3-4), pp. 178-194.
[20] Zhang, S., Shen, W. and Ghenniw, H., 2004, "A Review of Internet-based Product Information Sharing and Visualization," Computers in Industry, 54(1), pp. 1–15.
[21] Bilgic, T. and Rock, D., 1997, "Product Data Management Systems: State-of-the-art and the Future," ASME Design Engineering Technical Conferences, September 14-17, Sacramento, CA, USA, DETC97/EIM-3720.
[22] Bhatta, S. R. and Goel, A. K., 1996, "Model-Based Design Indexing and Index Learning in Engineering Design," Engineering Applications of Artificial Intelligence,, 9(6), pp. 601-609.
[23] Kirschman, C. F., Fadel, G. M. and Jara–Almonte, C. C., 1996, "Classifying Functions for Mechanical Design," ASME Design Engineering Technical Conference and Computers in Engineering Conference, August 18–22, Irvine, CA, USA, 96–DETC/DTM–1504.
[24] Iwassaki, Y. and Chandrasekaran, B., 1992, "Design Verification through Function and Behavior-Oriented Representations: Bridging the gap between Function and Behavior," Second International Conference on Artificial Intelligence in Design, June, Pittsburgh, PA, USA, Kluwer Academic Publishers Group.
[25] Murdock, J. W., Szykman, S. and Sriram, R. D., 1997, "An Information Modeling Framework to Support Design Databases and Repositories," ASME Design Engineering Technical Conferences, September 14–17, Sacramento, CA, USA, pp. 1-12. DETC97/DFM-4373.
[26] Bock, C. and Gruninger, M., 2005, "PSL: A Semantic Domain for Flow Models," Journal of Software and Systems Modeling, 4(2), pp. 209-231.
139
[27] de Kleer, J., 1977, "Multiple Representations of Knowledge in a Mechanics Problem-solver," International Joint Conferences on Artificial Intelligence (IJCAI), Cambridge, Massachusetts, USA, pp. 299-304.
[28] Greer, J. L., Stock, M. E., Stone, R. B. and Wood, K. L., 2003, "Enumerating the Component Space: First Steps Toward a Design Naming Convention for Mechanical Parts," 2003 ASME Design Engineering Technical Conference and Computers and Information in Engineering Conference, Sep 2-6 2003, Chicago, IL, United States, American Society of Mechanical Engineers, Vol. 3, pp. 707-718.
[29] Stahovich, T. F., Davis, R. and Shrobe, H., 1993, "An Ontology of Mechanical Devices," American Association for Artificial Intelligence Eleventh National Conference on Artificial Intelligence (AAAI-93), July 11-15, Washington, D.C., USA.
[30] Stahovich, T. F., Davis, R. and Shrobe, H., 1996, "Generating Multiple New Designs from a Sketch," Proceedings of the 13th National Conference on Artificial Intelligence. Part 2 (of 2), Aug 4-8, Portland, OR, USA, AAAI, Menlo Park, CA, USA, Vol. 2, pp. 1022-1029.
[31] Nahm, Y.-E. and Ishikawa, H., 2004, "Integrated Product and Process Modeling for Collaborative Design Environment," Concurrent Engineering, 12(1), pp. 5-23.
[32] Suh, N. P., 2001, Axiomatic Design: Advances and Applications, Oxford University Press, New York, USA.
[33] Hatvany, J., Newman, W. M. and Sabin, M. A., 1993, "World Survey of Computer Aided Design," Computer Aided Design, 25(12), pp. 776-798.
[34] Saaksvuori, A. and Immonen, A., 2003, Product Lifecycle Management, Springer Verlag, Heidelberg, Germany.
[35] Baader, F., Calvanese, D., McGuinness, D., Nardi, D. and Patel-Schneider, P., 2003, The Description Logic Handbook: Theory, Implementation and Applications, Cambridge University Press, Cambridge, UK.
[36] Noy, N. F., Sintek, M., Decker, S., Crubézy, M., Fergerson, R. W. and Musen, M. A., 2001, "Creating Semantic Web Contents with Protege-2000", IEEE Intelligent Systems, March-April 2001, 48(2), pp. 60-71.
[37] McBride, B., 2002, "Jena: A Semantic Web Toolkit", IEEE Internet Computing, Nov.-Dec. 2002, 6(6), pp. 55-59.
[38] Daconta, M. C., Obrst, L. J. and Smith, K. T., 2003, The Semantic Web: A Guide to the Future of XML, Web Services, and Knowledge Management, Wiley Publishing, Inc., Indianapolis, Indiana.
[39] Gruber, T. R., 1993, "A Translation Approach to Portable Ontology Specifications," Knowledge Acquisition, 5(2), pp. 199-220.
[40] Hyvönen, E., 2001, "The Semantic Web - The New Internet of Meanings," Semantic Web Kick-Off in Finland - Vision, Technologies, Research, and Applications, October 2, Helsinki, Finland, Helsinki Institute for Information Technology Publications, pp. 3-26.
140
[41] van der Vegte, W. F., Kitamura, Y., Mizoguchi, R. and Horváth, I., 2002, "Ontology-based Modeling of Product Functionality and Use - Part 2: Considering Use and Unintended Behavior," EdiPROD Conference, October 10th, Poland, pp. 115-124.
[42] Gennari, J. H., Tu, S. W., Rothenfluh, T. E. and Musen, M. A., 1994, "Mapping Domains to Methods in Support of Reuse," International Journal of Human-Computer Studies, 41(3), pp. 399-424.
[43] Miller, G. A., 1985, "WordNet: A Dictionary Browser," First International Conference on Information in Data, University of Waterloo, Waterloo, Canada,
[44] Fellbaum, C., 1998, WordNet: An Electronic Lexical Database (Language, Speech, and Communication), MIT Press, Cambridge, MA, USA.
[45] Reed, S. L. and Lenat, D. B., 2002, "Mapping Ontologies into Cyc," American Association for Artificial Intelligence Conference Workshop on Ontologies for the Semantic Web, July 28-August 1, Edmonton, Canada, AAAI.
[46] Gangemi, A., Guarino, N., Masolo, C., Oltramari, A. and Schneider, L., 2002, "Sweetening Ontologies with DOLCE," 13th International Conference on Knowledge Engineering and Knowledge Management (EKAW02), Oct. 1-4, Sig uenza, Spain, Vol. 2473.
[47] Covitz, P. A., Hartel, F., Schaefer, C., Coronado, S. D., Fragoso, G., Sahni, H., Gustafson, S. and Buetow, K. H., 2003, "caCORE: A Common Infrastructure for Cancer Informatics," Bioinformatics, 19(10), pp. 2404-2412.
[48] Uschold, M. and King, M., 1995, "Towards a Methodology for Building Ontologies," International Joint Conference on Artificial Intelligence, August 20-25, Montreal, Quebec, Canada, AIAI-TR-183.
[49] Gruninger, M. and Fox, M. S., 1995, "Methodology for the Design and Evaluation of Ontologies," International Joint Conference on Artificial Intelligence, August 20-25, Montreal, Quebec, Canada.
[50] Fernández-López, M., Gomez-Perez, A. and Sierra, J. P., 1999, "Building a Chemical Ontology using Methontology and the Ontology Design Environment," Intelligent Systems, IEEE, 14(1), pp. 37-46.
[51] Staab, S., Studer, R., Schnurr, H.-P. and Sure, Y., 2001, "Knowledge Processes and Ontologies," Intelligent Systems, IEEE, 16(1), pp. 26-34.
[52] Cimiano, P., Hotho, A., Stumme, G. and Tane, J., 2004, "Conceptual Knowledge Processing with Formal Concept Analysis and Ontologies," Concept Lattices: Second International Conference on Formal Concept Analysis (ICFCA), P. Eklund, ed., February 23-26, Sydney, Australia, Springer-Verlag, pp. 189-207.
[53] Kumara , S. R. T., Ham, I., Al-Hamando, M. and Goodnow, K., 1989, "Causal Reasoning and Data Abstraction in Component Design," Annals of the CIRP, 38(1), pp. 145-149.
141
[54] Liao, S.-H., 2003, "Knowledge Management Technologies and Applications - Literature Review from 1995 to 2002," Expert Systems with Applications, 25(2), pp. 155-164.
[55] Davies, J., Fensel, D. and Harmelen, F. v., 2003, Towards the Semantic Web: Ontology-Driven Knowledge Management, John Wiley & Sons, West Sussex, UK.
[56] Berners-Lee, T., 2000, Weaving the Web - The original design and ultimate destiny of the World Wide Web, by its inventor, 1st Edition, HarperCollins Publishers Inc., 10 East 53rd Street, New York, NY 10022.
[57] Koivunen, M.-R. and Miller, E., 2001, "W3C Semantic Web Activity," http://www.w3.org/2001/12/semweb-fin/w3csw, March 20, 2004, The World Wide Web Consortium.
[58] McGuinness, D. L., Fikes, R., Hendler, J. and Stein, L. A., 2002, "DAML+OIL: An Ontology Language for the Semantic Web", IEEE Intelligent Systems, Sept.-Oct. 2002, 17(5), pp. 72-80.
[59] McGuinness, D., Fikes, R., Stein, L. A. and James, H., 2002, "DAML-ONT: An Ontology Language for the Semantic Web," The MIT Press, D. Fensel, J. Hendler, H. Lieberman and W. Walhster, eds., Cambridge, MA, USA.
[60] Bechhofer, S., Broekstra, J., Decker, S., Erdmann, M., Fensel, D., Goble, C., van Harmelen, F., Horrocks, I., Klein, M., McGuinness, D., Motta, E., Patel-Schneider, P., Staab, S. and Studer, R., 2000, "An informal Description of Standard OIL and Instance OIL," www.ontoknowledge.org/oil/downl/dialects.pdf, On-To-Knowledge: Content-driven Knowledge-Management through Evolving Ontologies.
[61] McGuinness, D. L. and Harmelen, F. v., 2004, "OWL Web Ontology Language Overview," http://www.w3.org/TR/2004/REC-owl-features-20040210/, March 20, 2004, The World Wide Web Consortium - Recommendation.
[62] Beckett, D. and McBride, B., 2003, "RDF/XML Syntax Specification (Revised), W3C Proposed Recommendation," http://www.w3.org/TR/2003/PR-rdf-syntax-grammar-20031215/, February 2, 2004, The World Wide Web Consortium.
[63] Berners-Lee, T., 2000, "XML and the Web," http://www.w3.org/2000/Talks/0906-xmlweb-tbl/, March 20, 2004, The World Wide Web Consortium.
[64] Smith, M. K., Welty, C. and McGuinness, D. L., 2003, "OWL Web Ontology Language Guide," http://www.w3.org/TR/owl-guide/, February 2, 2004, The World Wide Web Consortium - Proposed Recommendation.
[65] Patel-Schneider, P. F. and Horrocks, I., 2003, "OWL Web Ontology Language Semantics and Abstract Syntax," http://www.w3.org/TR/owl-semantics/syntax.html, March 20, 2004, The World Wide Web Consortium.
[66] Berners-Lee, T., Fielding, R., Irvine, U. C. and Masinter, L., 1998, "Uniform Resource Identifiers (URI): Generic Syntax," http://www.isi.edu/in-notes/rfc2396.txt, March 20, 2004, The Internet Society (Request for Comments: 2396).
142
[67] Horrocks, I. and Patel-Schneider, P. F., 1999, "Optimizing Description Logic Subsumption," Journal of Logic and Computation, 9(3), pp. 267-293.
[68] Kivela, A. and Hyvönen, E., 2003, "Ontological Theories for the Semantic Web," Semantic Web Kick-Off in Finland - Vision, Technologies, Research, and Applications, Feb 11, 2001, Helsinki, Finland, Helsinki Institute for Information Technology Publications.
[69] Horrocks, I. and Patel-Schneider, P. F., 2003, "Reducing OWL Entailment to Description Logic Satisfiability," Proceedings of the 2003 Description Logic Workshop (DL 2003), Sun SITE Central Europe (CEUR), Vol. 81, pp. 1-8.
[70] Bechhofer, S., Harmelen, F. v., Hendler, J., Horrocks, I., McGuinness, D. L., Patel-Schneider, P. F. and Stein, L. A., 2003, "OWL Web Ontology Language Reference," http://www.w3.org/TR/owl-ref/, January 31, 2004, The World Wide Web Consortium.
[71] Ganter, B. and Wille, R., 1999, Formal Concept Analysis: Mathematical Foundations, First, Springer-Verlag, Heidelberg, Germany.
[72] Gratzer, G. A., 1998, General Lattice Theory, Second, Birkhäuser, Boston, MA, US.
[73] Erné, M., Koslowski, J., Melton, A. and Strecker, G. E., 1991, "A Primer on Galois Connections," Proceedings of the Summer Conference on General Topology and Applications in Honor of Mary Ellen Rudin and Her Work, S. Andima, R. Kopperman, P. Misra, M. E. Rudin and A. R. Todd, eds., June 26-29, Madison, Wisconsin, U.S.A., Annals of the New York Academy of Sciences, Vol. 704, 1993, pp. 103-125.
[74] Snelting, G., 1996, "Reengineering of Configurations based on Mathematical Concept Analysis," ACM Transactions on Software Engineering and Methodology, 5(2), pp. 146-189.
[75] Valtchev, P., Missaoui, R. and Lebrun, P., 2002, "A partition-based approach towards constructing Galois (concept) lattices," Discrete Mathematics, 256(3), pp. 801-829.
[76] Nourine, L. and Raynaud, O., 1999, "Fast algorithm for building lattices," Information Processing Letters, 71(5-6), pp. 199-204.
[77] Priss, U., 2003, "Linguistic Applications of Formal Concept Analysis," Proceedings of the First International Conference on Formal Concept Analysis (ICFCA'03), February 27-March 1, Darmstadt, Germany, Springer-Verlag.
[78] Godin, R., Missaoui, R. and April, A., 1993, "Experimental Comparison of Navigation in a Galois Lattice with Conventional Information Retrieval Methods," International Journal of Man-Machine Studies, 38(5), pp. 747-767.
[79] Lindig, C., 1995, "Concept-Based Component Retrieval," International Joint Conference on Artificial Intelligence: Formal Approaches to the Reuse of Plans, Proofs, and Programs (IJCAI-95), J. Köhler, F. Giunchiglia, C. Green and C. Walther, eds., August 20-25, Montreal, Quebec, Canada.
143
[80] Siff, M. and Reps, T., 1997, "Identifying Modules Via Concept Analysis," IEEE International Conference on Software Maintenance, M. J. Harrold and G. Visaggio, eds., Bari, Italy, pp. 170-179.
[81] Fernandez-Manjon, B. and Fernandez-Valmayor, A., 1998, "Building Educational Tools Based on Formal Concept Analysis," Education and Information Technologies, 3(3), pp. 187-201.
[82] Godin, R. and Mili, H., 1993, "Building and Maintaining Analysis-level Class Hierarchies using Galois Lattices," Proceedings of the eighth annual conference on Object-oriented programming systems, languages, and applications, A. Paepcke, ed., September 26-October 1, Washington, DC, USA, ACM Press, New York, NY, USA, pp. 394-410.
[83] Kuznetsov, S. O., 2001, "Machine Learning on the Basis of Formal Concept Analysis," Automation and Remote Control, 62(10), pp. 1543-1564.
[84] Duquenne, V., Chabert , C., Cherfouh, A., Delabar, J.-M., Doyen, A.-L. and Pickering, D., 2001, "Structuration of Phenotypes/Genotypes through Galois Lattices and Implications," International Workshop on Concept Lattice-based theory, methods and tools for Knowledge Discovery in Databases, E. M. Nguifo, M. Liquière and V. Duquenne, eds., July 30, Stanford University, CA, USA.
[85] Burmeister, P., 2003, "Formal Concept Analysis with ConImp: Introduction to the Basic Features," Department of Mathematics (Arbeitsgruppe Allgemeine Algebra und Diskrete Mathematik), Darmstadt University of Technology, Darmstadt, Germany.
[86] Groh, B., Strahringer, S. and Wille, R., 1998, "TOSCANA-Systems Based on Thesauri," Conceptual Structures: Theory, Tools and Applications: 6th International Conference on Conceptual Structures (ICCS'98), M.-L. Mugnier and M. Chein, eds., Montpellier, France, Springer-Verlag Heidelberg, Vol. 1453, pp. 127-138.
[87] Becker, P., 2004, "Numerical Analysis in Conceptual Systems with ToscanaJ," Concept Lattices: Second International Conference on Formal Concept Analysis (ICFCA), P. Eklund, ed., February 23-26, Sydney, Australia, Springer-Verlag, pp. 96-103.
[88] Vogt, F. and Wille, R., 1995, "TOSCANA - a Graphical Tool for Analyzing and Exploring Data," Proceedings of the DIMACS International Workshop on Graph Drawing, R. Tamassia and I. G. Tollis, eds., October 10-12, Princeton, NJ, USA, Springer-Verlag, pp. 226-233.
[89] Tilley, T., 2004, "Tool Support for FCA," Concept Lattices: Second International Conference on Formal Concept Analysis (ICFCA), P. Eklund, ed., February 23-26, Sydney, Australia, Springer-Verlag, pp. 104-111.
[90] Ishii, K. and Lee, B. H., 1996, "Reverse Fishbone Diagram: A Tool in Aid of Design for Product Retirement," ASME Design Engineering Technical Conferences, J. M. McCarthy, ed., August 18-22, Irvine, CA, USA, 96-DETC/DFM-1272.
144
[91] Pimmler, T. U. and Eppinger, S. D., 1994, "Integration Analysis of Product Decompositions," ASME Design Engineering Technical Conferences - Design Theory and Methodology, Minneapolis, MN, USA, ASME.
[92] Srinivasan, H., Shyamsundar, N. and Gadh, R., 1997, "Framework for Virtual Disassembly Analysis," Journal of Intelligent Manufacturing, 8(4), pp. 277-295.
[93] Steward, D. V., 1993, "Re-engineering the Design Process," Second Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, April 20-22, Morgantown, WV, USA, IEEE, pp. 94-98.
[94] Browning, T. R., 2001, "Applying the Design Structure Matrix to System Decomposition and Integration Problems: A Review and New Directions," IEEE Transactions on Engineering Management, 48(3), pp. 292-306.
[95] Otto, K. N. and Wood, K. L., 1996, "A Reverse Engineering and Redesign Methodology for Product Evolution," ASME Design Engineering Technical Conferences and Design Theory and Methodology Conference, August 18-22, Irvine, CA, USA, 96-DETC/DTM-1523.
[96] Lefever, D. D. and Wood, K. L., 1996, "Design for Assembly Techniques in Reverse Engineering and Redesign," ASME Design Engineering Technical Conferences and Design Theory and Methodology Conference, August 18-22, Irvine, CA, USA, ASME, 96-DETC/DTM-1507.
[97] Otto, K. and Wood, K., 2000, Product Design: Techniques in Reverse Engineering, Systematic Design, and New Product Development, Prentice Hall, New York.
[98] Boothroyd, G., Dewhurst, P. and Knight, W., 2001, Product Design for Manufacture and Assembly, 2nd Edition, Marcel Dekker, Inc., New York, NY.
[99] Pahl, G. and Beitz, W., 1984, Engineering Design: A Systematic Approach, Design Council, London.
[100] Ullman, D. G., 2002, The Mechanical Design Process, Third Edition, McGraw-Hill, New York.
[101] Stone, R. B. and Wood, K. L., 2000, "Development of a Functional Basis for Design," Journal of Mechanical Design, 122(4), pp. 359-370.
[102] Hirtz, J., Stone, R. B., McAdams, D. A., Szykman, S. and Wood, K., 2002, "A Functional Basis for Engineering Design: Reconciling and Evolving Previous Efforts," Research in Engineering Design, 13(2), pp. 65-82.
[103] Thevenot, H. J. and Simpson, T. W., 2006, "Commonality Indices for Product Family Design: A Detailed Comparison," Journal of Engineering Design, 17(2), pp. 99-119.
[104] Martin, M. V. and Ishii, K., 1996, "Design for Variety: A Methodology for Understanding the Costs of Product Proliferation," ASME Design Engineering Technical Conferences and Computers in Engineering Conference, August 18-22, Irvine, CA, USA, 96-DETC/DTM-1610.
145
[105] Martin, M. V. and Ishii, K., 1997, "Design for Variety: Development of Complexity Indices and Design Charts," ASME Design Engineering Technical Conferences, September 14-17, Sacramento, CA, DETC97/DFM-4359.
[106] Collier, D. A., 1981, "The Measurement and Operating Benefits of Component Part Commonality," Decision Sciences, 12(1), pp. 85-96.
[107] Wacker, J. G. and Trelevan, M., 1986, "Component Part Standardization: An Analysis of Commonality Sources and Indices," Journal of Operations Management, 6(2), pp. 219-244.
[108] Jiao, J. and Tseng, M. M., 2000, "Understanding Product Family for Mass Customization by Developing Commonality Indices," Journal of Engineering Design, 11(3), pp. 225-243.
[109] Siddique, Z. and Rosen, D. W., 1998, "On the Applicability of Product Variety Design Concepts to Automotive Platform Commonality," ASME Design Engineering Technical Conferences, September 13-16, Atlanta, GA, USA, ASME, DETC98/DTM-5661.
[110] Thevenot, H. J., 2003, "A Comparison of Commonality Indices for Product Family Design," M.S. Thesis, Industrial Engineering, The Pennsylvania State University, University Park, PA.
[111] Feliz, E. N., 2004, "Design Repository Enhancement for Product Family Information Capture," M.S. Thesis, Mechanical Engineering, The Pennsylvania State University, University Park, PA.
[112] Nanda, J., Simpson, T. W., Kumara, S. R. T. and Shooter, S. B., 2006, "Product Family Ontology Development using Formal Concept Analysis and Web Ontology Language," Journal of Computing and Information Science in Engineering, 6(1), pp. 103-113.
[113] Nanda, J., Simpson, T. W., Shooter, S. B. and Stone, R. B., 2005, "A Unified Information Model for Product Family Design Management," ASME International Design Engineering Technical Conferences & Computers and Information in Engineering Conference, Long Beach, CA, USA, DETC2005-84869.
[114] Nanda, J., Thevenot, H. and Simpson, T. W., 2005, "Product Family Representation and Redesign: Increasing Commonality using Formal Concept Analysis," ASME International Design Engineering Technical Conferences & Computers and Information in Engineering Conference, September 24-28, Long Beach, CA, USA, DETC2005-84818.
Appendix A
Parts for the Kodak Single-use Camera Product Family
Module Module type
MAX Outdoor
MAX Flash
Max HQ
Plus Digital
Black & White
Max Water
& Sport
Advantix switchable
Arm 1 Variant 1 1 1 1 1 1 2
Arm 2 Variant 1 1 1 1 1 1 2
Arm retainer Common 1 1 1 1 1 1
Back panel Variant 1 2 2 2 3 4 5
Battery Variant 1 1 1 2 3
Battery connection
Unique 1
Bottom cover Unique 1
Button Variant 1 1 1 1 2 3
Cam Variant 1 1 1 1 1 1 2
Exposure counter
Variant 1 1 1 1 2 2 3
Film Variant 1 1 2 1 3 1 4
Film advance gear
Variant 1 1 1 1 1 1 2
Film advance wheel
Variant 1 1 1 1 2 3 4
Film advance wheel 2 (on the waterproof box)
Unique 1
Film base Variant 1 2 3 3 4 4 5
Film holder Variant 1 1 1 1 2 3
Flash Variant 1 1 1 2 3
Flash cover Variant 1 1 1 2 3
Flash PCB Variant 1 2 2 3 4
Front cover Unique 1
147
Module Module type
MAX Outdoor
MAX Flash
Max HQ
Plus Digital
Black & White
Max Water
& Sport
Advantix switchable
Front panel Variant 1 2 3 3 4 5 6
Gear 1 Unique 1
Gear 2 Unique 1
Identification label
Variant 1 2 3 3 4 5 6
Lens 1 Variant 1 1 2 2 2 2 3
Lens 2 Variant 1 1 1 1 2
Lens 2 cover Variant 1 1 1 1 2
Lens cover Variant 1 1 2 2 3 3 4
Rubber band Unique 1
Shutter Variant 1 1 2 2 2 2 3
Shutter cover Variant 1 1 2 2 2 2 3
Spring 1 Variant 1 1 1 1 1 1 2
Spring 2 Variant 1 1 1 1 1 1 2
Spring 3 Unique 1
Spring 4 Unique 1
Switchable viewfinder holder
Unique 1
Switchable viewfinder
Unique 1
Viewfinder Variant 1 1 2 2 3 4 5
Washer Unique 1
Waterproof back cover
Unique 1
Waterproof front cover
Unique 1
148
Appendix B
Kodak One-time-use Cameras PVM and FCM
In this appendix, the product vector metrics (PVM), and function component
metrics (FCM) for all the Kodak one-time-use cameras have been presented.
Table B-1: Kodak Water & Sport PVM
149
Table B-2: Kodak Water & Sport FCM
150
Table B-3: Kodak Plus Digital PVM
Table B-4: Kodak Plus Digital FCM
151
Table E-5: Kodak Black & White PVM
152
Table B-6: Kodak Black & White FCM
153
Table B-7: Kodak Advantix Switchable PVM
154
Table B-8: Kodak Advantix Switchable FCM
155
Table B-9: Kodak MAX Outdoor PVM
Table B-10: Kodak MAX Outdoor FCM
156
Table B-11: Kodak MAX Flash PVM
Table B-12: Kodak MAX Flash FCM
157
Table B-13: Kodak MAX HQ PVM
158
Table B-14: Kodak MAX HQ FCM
159
Appendix C
Computation of Commonality Indices for Redesigning Cameras
Table B-1 summarizes the calculation of DCI and TCCI for one-time-use cameras
after product-based and component-based redesign.
Table C-1: Computation of DCI and TCCI for one-time-use cameras
Initial DCI for one-time-use cameras = 1229 = 2.417
After component-based redesign DCI = 1129 = 2.636
After product-based redesign DCI = 1129 = 2.636
160
Similarly, initial TCCI for one-time-use cameras = )129()112(1
−−
− = 0.607
After component-based redesign TCCI = )129()111(1
−−
− = 0.643
After product-based redesign TCCI = )129()111(1
−−
− = 0.643
Table B-2 summarizes the calculation of CI for one-time-use cameras.
Table B-2 summarizes the calculation of CI for one-time-use cameras.
Table C-2: Computation of CI for one-time-use cameras
Initial CI for one-time-use cameras = )929()912(1
−−
− = 0.85
CI after component-based redesign = )929()911(1
−−
− = 0.9
CI after product-based redesign = )929()911(1
−−
− = 0.9
161
Appendix D
Parts for the Black & Decker Versapak Power Tools Product Family
Part Module type
Circular saw
Drill Recipro-cating saw
Screw -driver
Rotary tool
Flashlight
Ball bearing Variant 1 2 1 Batteries connection Variant 1 1 1 2 3 4 Batteries holder Variant 1 1 2 2 Battery Common 1 1 1 1 1 1 Battery spacer Unique 1 Bearing Unique 1 Bit holder Unique 1 Bottom housing Variant 1 2 3 4 5 6 Bulb Unique 1 Bulb cover Unique 1 Button Variant 1 2 1 3 4 End bit holder Variant 1 2 Front housing Variant 1 2 Gear 1 Variant 1 2 3 4 Gear 1 holder Unique 1 Gear 2 Variant 1 2 3 Gear 2 holder Unique 1 Gear housing Variant 1 2 Gear housing cover Unique 1 Guide Unique 1 Identification label 1 Variant 1 2 3 4 Identification label 2 Variant 1 2 Keyless Chuck Unique 1 Left battery holder Unique 1 Lock button Variant 1 2 Motor Variant 1 2 3 4 5 Motor cover Unique 1 Needle Unique 1 Needle bearing Unique 1 Needle bearing housing
Unique 1
Output shaft Variant 1 2 3 4 Pins Unique 1 Reversing button Unique 1 Right battery holder Unique 1 Screws 1 Variant 1 2 3 4 5 Screws 2 Unique 1 Screws 3 Unique 1
162
Part Module type
Circular saw
Drill Recipro-cating saw
Screw -driver
Rotary tool
Flashlight
Securing band Unique 1 Shoe Variant 1 2
163
Appendix E
Black & Decker Versapak Power Tools PVM and FCM
In this appendix, the product vector metrics (PVM), and function component
metrics (FCM) for all the Black & Decker Versapak tool sets have been presented.
Table E-1: Versapak Drill PVM
164
Table E-2: Versapak Drill FCM
165
Table E-3: Versapak Circular Saw PVM
166
Table E-4: Versapak Circular Saw FCM
167
Table E-5: Versapak Flashlight PVM
Table E-6: Versapak Flashlight FCM
168
Table E-7: Versapak Reciprocating Saw PVM
169
Table E-8: Versapak Reciprocating Saw FCM
170
Table E-9: Versapak Rotary Tool PVM
171
Table E-10: Versapak Rotary Tool FCM
172
Table E-11: Versapak Screwdriver PVM
173
Table E-12: Versapak Screwdriver FCM
174
Appendix F
Computation of Commonality Indices for Redesigning Power Tools
Table F-1 summarizes the calculation of DCI and TCCI and Table D-2
summarizes the calculation of CI for Black & Decker Versapak power tools after
product-based and component-based redesign.
Table F-1: Computation of DCI and TCCI for power tools
Initial DCI for power tools = 2028 = 1.4
175
After component-based redesign DCI = 1928 = 1.474
After product-based redesign DCI = 1628 = 1.750
Similarly, initial TCCI for one-time-use cameras = )128()120(1
−−
− = 0.296
After component-based redesign TCCI = )128()119(1
−−
− = 0.333
After product-based redesign TCCI = )128()116(1
−−
− = 0.444
176
Table F-2: Computation of CI for power tools
Initial CI for power tools = )728()720(1
−−
− = 0.381
CI after component-based redesign = )728()719(1
−−
− = 0.429
CI after product-based redesign = )728()717(1
−−
− = 0.524
177
Appendix G
List of Acronyms
FCA Formal Concept Analysis RDF Resource Description Framework RDF-S Resource Description Framework Schema OWL Web Ontology Language DL Description Logic XML Extensible Markup Language XML-S Extensible Markup Language Schema HTML Hypertext Markup Language CAD Computer Aided Design PDM Product Data Management PFODM Product Family Ontology Development Methodology PFUIM Product Family Uniform Information Model PFRRF Product Family Representation and Redesign Framework DXF Data Exchange Format STEP Standard for the Exchange of Product Model Data CALS Continuous Acquisition and Life Cycle Support SGML Standard Generic Markup Language W3C World Wide Web Consortium DARPA Defense Advanced Research Projects Agency DAML DARPA Agent Markup Language OIL Ontology Inference Layer URI Uniform Resource Identifier TOSCANA Tools of Concept Analysis BOM Bill of material DSM Design Structure Matrix FCM Function Component Matrix
178
VITA
Jyotirmaya Nanda
Jyotirmaya Nanda is working on his doctorate in Industrial Engineering with a
minor in High Performance Computing at the Pennsylvania State University with Prof.
Timothy W. Simpson. He obtained his Master of Science degree in Industrial
Engineering from the Pennsylvania State University in December 2002. He obtained his
Bachelor of Engineering degree in Mechanical Engineering from Visvesvaraya National
Institute of Technology, Nagpur, India, graduating with distinction. His research interests
are in mass customization, knowledge management, and design optimization. He is
currently employed as a Research Scientist at Intelligent Automation, Inc., Rockville,
MD.