The Synthesis of Variety Developing Product Families

Abstract

The advent of the buyers’ market has imposed a necessity on manufacturing companies to suit individual customer requirements. Companies have answered this need by offering a large variety from which customers choose their ideal products. However, offering a large product variety is not a solution when this variety is accompanied by high internal costs. The solution for coping with the problem of mass-customisation lies in the development of product families, which offer a large variety from a small set of modules that can be easily combined. This thesis deals with such product families. It focuses on the structure of design information of product families and shows how the evolution of this information in the design process can be supported.

Full text

The Synthesis of Variety
Developing Product Families
Proefschrift
ter verkrijging van de graad van doctor aan de Technische
Universiteit Eindhoven, op gezag van de Rector Magnificus, prof.dr.
J.H. van Lint, voor een commissie aangewezen door het college van
Dekanen in het openbaar te verdedigen op maandag 10 juni 1996 om
16.00 uur
door
Frederik-Jan Erens
geboren te Geleen

ii
Dit proefschrift is goedgekeurd door de promotoren:
prof.dr.ir. J.C. Wortmann
prof.ir. P.W. Sanders
de copromotor: dr. S. Bloor
CIP-DATA KONINKLIJKE BIBLIOTHEEK, DEN HAAG
Erens, Frederik-Jan
The Synthesis of Variety : Developing Product Families /
Frederik-Jan Erens. - Eindhoven: Eindhoven University of
Technology. - III.
Thesis Technische Universiteit Eindhoven. - With index,
ref. - With summary in Dutch.
ISBN 90-386-0195-6
NUGI 689
Subject headings: product family / design management /
mass customization
Omslagontwerp: P. Geenen
Druk: Universitaire Drukkerij TU Eindhoven
Uitgever: KPMG
© 1996, F.J. Erens, Eindhoven
Alle rechten voorbehouden. Uit deze uitgave mag niet worden gereproduceerd door middel van boekdruk, fotokopie,
microfilm of welk ander medium dan ook, zonder schriftelijke toestemming van de auteur.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
by any means, mechanical, photocopying, recording or otherwise, without the written permission of the author.

iii
Logic brings you from A to B,
but imagination takes you everywhere.
A. Einstein

iv

v
Table of contents
1. Introduction _____________________________________________________ 1
1.1 Overview of this thesis ______________________________________________ 3
1.2 Defining the scope of research ________________________________________ 4
1.2.1 Products and product families ________________________________________ 5
1.2.2 Classification of design _____________________________________________ 10
1.2.3 Classification of manufacturing control ________________________________ 14
1.3 Product modelling languages and design methods _______________________ 16
1.4 Problem statement and research objective _____________________________ 17
1.5 Research method _________________________________________________ 18
2. Problems with product variety _____________________________________ 20
2.1 Domains, product models and representations __________________________ 21
2.2 Manufacturing disciplines and domains ________________________________ 25
2.2.1 Programme and product management ________________________________ 26
2.2.2 Marketing and sales _______________________________________________ 27
2.2.3 Manufacturing engineering _________________________________________ 27
2.2.4 Logistics and goods flow control _____________________________________ 29
2.2.5 Purchasing _______________________________________________________ 31
2.2.6 Accounting _______________________________________________________ 32
2.2.7 Service __________________________________________________________ 33
2.3 Industrial problem statement ________________________________________ 34
2.3.1 Uncontrolled growth of variety ______________________________________ 34
2.3.2 Preparing for product family design ___________________________________ 37
2.4 Design problems __________________________________________________ 39
2.4.1 Structuring the product family _______________________________________ 40
2.4.2 The product family’s variants ________________________________________ 41
2.4.3 Decomposition ___________________________________________________ 42
2.4.4 Allocation ________________________________________________________ 43
2.4.5 Composition _____________________________________________________ 44
2.4.6 Validation _______________________________________________________ 44
2.4.7 Constraints ______________________________________________________ 45
2.4.8 Documentation ___________________________________________________ 45
2.5 The intangibility of product families __________________________________ 47
2.6 Product family descriptions _________________________________________ 50
2.6.1 Describing preferred modules _______________________________________ 53
2.6.2 Describing preferred systems ________________________________________ 55
2.6.3 Variant bills-of-material ____________________________________________ 57
2.6.4 Generic bills-of-material ____________________________________________ 59
2.7 Requirements for the solution _______________________________________ 65
3. Languages for single products ______________________________________ 68
3.1 Informal modelling languages and specifications ________________________ 69
3.1.1 Function of the product ____________________________________________ 70
3.1.2 Constraints on the technological and physical solution ___________________ 71
3.1.3 Evaluation criteria _________________________________________________ 73
3.1.4 Specifications at Medical Systems ____________________________________ 73

vi
3.2 Compositional systems _____________________________________________ 74
3.2.1 Mechanical design_________________________________________________ 75
3.2.2 Electrical design___________________________________________________ 77
3.2.3 Software design ___________________________________________________ 78
3.2.4 Product architectures ______________________________________________ 80
3.2.5 Concluding remarks _______________________________________________ 81
3.3 Non-compositional systems _________________________________________ 82
3.3.1 Functional modelling_______________________________________________ 85
3.3.2 Technology modelling ______________________________________________ 91
3.3.3 Physical modelling _________________________________________________ 97
3.3.4 An integrated approach to three domains _____________________________ 106
3.4 Conclusions _____________________________________________________ 108
4. Languages for product families ____________________________________ 111
4.1 Feature-based design _____________________________________________ 112
4.2 Parametrised CAD ________________________________________________ 114
4.3 Generic product structures _________________________________________ 118
4.3.1 Structuring principle ______________________________________________ 119
4.3.2 Primitive families and primitive variants ______________________________ 119
4.3.3 Parameters and parameter values of a primitive family __________________ 120
4.3.4 Primitive configuration constraints __________________________________ 121
4.3.5 Selection conditions ______________________________________________ 121
4.3.6 Intermediate summary ____________________________________________ 122
4.3.7 Compound families and compound variants ___________________________ 122
4.3.8 Distributed parameters ____________________________________________ 124
4.3.9 Conversion functions _____________________________________________ 126
4.3.10 Multiple use of a family in a product family structure ___________________ 128
4.3.11 Variant specifications and identifications _____________________________ 128
4.3.12 Indirect specification of variants with parameters ______________________ 129
4.3.13 Creating a specific variant __________________________________________ 130
4.3.14 Separating the commercial catalogue and the GPS ______________________ 131
4.3.15 The software paradigm ____________________________________________ 131
4.3.16 Conceptual data model ____________________________________________ 133
4.4 Conclusions _____________________________________________________ 135
5. Design processes ________________________________________________ 138
5.1 Descriptive models _______________________________________________ 140
5.2 Prescriptive models _______________________________________________ 141
5.3 Artefact models __________________________________________________ 144
5.3.1 Axiomatic Design _________________________________________________ 145
5.3.2 Quality Function Deployment _______________________________________ 148
5.4 Organising Tasks _________________________________________________ 151
5.5 Design Cycle _____________________________________________________ 154
5.5.1 Productive Reasoning Model _______________________________________ 155
5.5.2 Introduction to the Design Cycle ____________________________________ 156
5.5.3 Exploration versus registration ______________________________________ 158
5.5.4 A framework for other design methods _______________________________ 160
5.5.5 Applicability of the Design Cycle ____________________________________ 161
5.5.6 Abstraction levels and domains _____________________________________ 164
5.5.7 Granularity______________________________________________________ 165

vii
5.6 Design process of Philips Medical Systems ____________________________ 167
5.7 Concluding remarks _______________________________________________ 168
6. Structuring product families ______________________________________ 170
6.1 Definition of a product family _______________________________________ 171
6.2 Specification of the product family modelling language __________________ 176
6.2.1 The nature of product families ______________________________________ 177
6.2.2 Design objects ___________________________________________________ 177
6.2.3 Decomposition and composition ____________________________________ 178
6.2.4 Architecture _____________________________________________________ 178
6.2.5 Parameters and values ____________________________________________ 179
6.2.6 Constraints _____________________________________________________ 180
6.2.7 Consistency between models _______________________________________ 180
6.2.8 Product platforms ________________________________________________ 181
6.2.9 Documentation __________________________________________________ 181
6.2.10 Derived models __________________________________________________ 182
6.3 Design of the product family modelling language _______________________ 182
6.3.1 Product models __________________________________________________ 182
6.3.2 Design objects ___________________________________________________ 183
6.3.3 Product hierarchies _______________________________________________ 184
6.3.4 Interfaces _______________________________________________________ 186
6.3.5 Mappings _______________________________________________________ 186
6.3.6 Parameters and parameter values ___________________________________ 187
6.3.7 Selection conditions ______________________________________________ 188
6.3.8 Selection constraints ______________________________________________ 189
6.3.9 Parameter conversion _____________________________________________ 190
6.3.10 Representations _________________________________________________ 191
6.4 Intradomain and interdomain consistency ____________________________ 192
6.4.1 Selection conditions versus selection constraints _______________________ 194
6.4.2 Families versus variants ___________________________________________ 196
6.4.3 Parameters versus interfaces _______________________________________ 196
6.4.4 Parameters versus families _________________________________________ 197
6.4.5 Functions versus modules and assemblies ____________________________ 200
6.5 Representations _________________________________________________ 200
6.5.1 Documentation __________________________________________________ 201
6.5.2 Derived models __________________________________________________ 204
6.6 Concluding remarks _______________________________________________ 207
7. Developing product families ______________________________________ 210
7.1 Overview _______________________________________________________ 212
7.2 Designing sub-systems ____________________________________________ 213
7.3 Considering variety _______________________________________________ 215
7.4 Modularity versus integration ______________________________________ 217
7.5 Observations ____________________________________________________ 219
7.5.1 The use of product architectures ____________________________________ 220
7.5.2 Sequential versus concurrent design _________________________________ 221
7.5.3 Platforms versus families __________________________________________ 223
7.5.4 Life-cycles ______________________________________________________ 224
7.5.5 Version management _____________________________________________ 225
7.5.6 Development organisation _________________________________________ 227

viii
7.5.7 Design considerations and the diabolo _______________________________ 229
7.6 Case studies _____________________________________________________ 232
7.6.1 Philips Medical Systems ___________________________________________ 232
7.6.2 Philips Lighting __________________________________________________ 238
8. Evaluation and conclusions _______________________________________ 245
8.1 Evaluation ______________________________________________________ 245
8.2 Conclusions _____________________________________________________ 247
8.3 Directions for further research ______________________________________ 248
8.3.1 Visibility support for concurrent engineering __________________________ 249
8.3.2 Enterprise document management _________________________________ 249
8.3.3 Quality in mechatronic development ________________________________ 250
8.3.4 Supply for customer orders in the extended enterprise __________________ 251
8.3.5 Support for initial purchasing ______________________________________ 252
8.3.6 Production control architectures ___________________________________ 253
8.3.7 Towards a multi-disciplinary framework for design _____________________ 254
8.3.8 Financial measures for developing product families _____________________ 255
8.3.9 Business roadmapping for product families ___________________________ 257
8.4 Summary in English _______________________________________________ 258
8.5 Samenvatting in het Nederlands ____________________________________ 259
9. Appendices and references _______________________________________ 262
9.1 Conceptual database models _______________________________________ 262
9.2 References to literature ___________________________________________ 264
9.3 Index of subjects _________________________________________________ 281

ix
Table of figures
Figure 1-1. From craft production to mass customisation ____________________________ 1
Figure 1-2. Overview of this thesis ______________________________________________ 3
Figure 1-3. Decreasing solution space ____________________________________________ 9
Figure 1-4. Diabolo _________________________________________________________ 10
Figure 1-5. Design hierarchy __________________________________________________ 12
Figure 1-6. Product families and design _________________________________________ 14
Figure 1-7. Customer-Order Decoupling Point ____________________________________ 15
Figure 2-1. Specifications, domains and product models ____________________________ 22
Figure 2-2. One product model, different representations __________________________ 23
Figure 2-3. Subsets of a product model _________________________________________ 24
Figure 2-4. Different product models and representations __________________________ 24
Figure 2-5. Reducing the control complexity _____________________________________ 28
Figure 2-6. Goods flow ______________________________________________________ 29
Figure 2-7. Vertical integration ________________________________________________ 31
Figure 2-8. Proliferation of products ____________________________________________ 34
Figure 2-9. Increasing product density __________________________________________ 35
Figure 2-10. Trade-off between development time and options ______________________ 36
Figure 2-11. Reactive development ____________________________________________ 37
Figure 2-12. Forward compatibility _____________________________________________ 39
Figure 2-13. Domains and shared memory _______________________________________ 40
Figure 2-14. Reduction of complexity ___________________________________________ 41
Figure 2-15. Decreasing scope of product family __________________________________ 41
Figure 2-16. Explicit documents containing implicit information ______________________ 45
Figure 2-17. Organisational borders and documents _______________________________ 46
Figure 2-18. References between documents ____________________________________ 47
Figure 2-19. Interaction between form and context ________________________________ 48
Figure 2-20. Cardio-Vascular system ____________________________________________ 52
Figure 2-21. Diabolo for product variety _________________________________________ 53
Figure 2-22. Defining modules ________________________________________________ 53
Figure 2-23. Catalogues and orders ____________________________________________ 54
Figure 2-24. Preferred systems ________________________________________________ 55
Figure 2-25. Selection tree ___________________________________________________ 57
Figure 2-26. Variant bill-of-material ____________________________________________ 58
Figure 2-27. Generic bill-of-material concept _____________________________________ 60
Figure 2-28. Choice-sheet of a Cardio-Vascular system _____________________________ 61
Figure 2-29. Product family structure ___________________________________________ 62
Figure 2-30. Inheriting parameters _____________________________________________ 64
Figure 3-1. Specification versus behaviour _______________________________________ 69
Figure 3-2. Choice-sheet of a motor car _________________________________________ 71
Figure 3-3. Functions, physical effects, physical principles and solution principles ________ 76
Figure 3-4. Transistor________________________________________________________ 78
Figure 3-5. Emitter follower __________________________________________________ 78
Figure 3-6. Interface description of a 4-bit adder __________________________________ 80
Figure 3-7. A logical realisation of a 4-bit adder ___________________________________ 81
Figure 3-8. Functions, modules and assemblies ___________________________________ 81
Figure 3-9. Modelling languages for non-compositional and compositional systems ______ 83
Figure 3-10. Classification hierarchy for verbs ____________________________________ 85

x
Figure 3-11. Classification hierarchy for nouns ____________________________________ 86
Figure 3-12. Functional decomposition of parking garage ___________________________ 87
Figure 3-13. Functional architecture ____________________________________________ 88
Figure 3-14. Functional architecture of the function P1: perform acquisition ____________ 89
Figure 3-15. Functional decomposition __________________________________________ 90
Figure 3-16. Technology decomposition of a parking garage _________________________ 93
Figure 3-17. Anti-lock braking system ___________________________________________ 94
Figure 3-18. Technology architecture of the X-ray system ___________________________ 95
Figure 3-19. Technology decomposition of the X-ray system _________________________ 95
Figure 3-20. Assembly, logistics and service ______________________________________ 98
Figure 3-21. Assembly architecture ____________________________________________ 100
Figure 3-22. Assembly architecture and decomposition____________________________ 101
Figure 3-23. Design for assembly _____________________________________________ 102
Figure 3-24. Physical architecture of a medical stand______________________________ 105
Figure 3-25. Physical decomposition of a medical stand ___________________________ 105
Figure 3-26. Chromosome model _____________________________________________ 107
Figure 4-1. GBOM versus a product model for single products ______________________ 111
Figure 4-2. Cube with hole and shaft __________________________________________ 112
Figure 4-3. CAD product structure ____________________________________________ 116
Figure 4-4. Classification of variety ____________________________________________ 116
Figure 4-5. Choice object ____________________________________________________ 117
Figure 4-6. Office-chair _____________________________________________________ 119
Figure 4-7. Choice-sheet ____________________________________________________ 119
Figure 4-8. Primitive family "stand" ___________________________________________ 120
Figure 4-9. Product family structure of the office-chair ____________________________ 123
Figure 4-10. Selection conditions _____________________________________________ 123
Figure 4-11. Customer-order specific BOM ______________________________________ 124
Figure 4-12. Distributed parameters ___________________________________________ 125
Figure 4-13. Conversion functions_____________________________________________ 127
Figure 4-14. Limiting variety _________________________________________________ 127
Figure 4-15. Multiple use of upholstery ________________________________________ 128
Figure 4-16. Separate commercial catalogue ____________________________________ 131
Figure 4-17. Conceptual datamodel of the GPS concept ___________________________ 134
Figure 5-1. Elements of design _______________________________________________ 138
Figure 5-2. VDI 2221 _______________________________________________________ 143
Figure 5-3. Four domains of Axiomatic Design ___________________________________ 146
Figure 5-4. Uncoupled design ________________________________________________ 147
Figure 5-5. Decoupled design ________________________________________________ 147
Figure 5-6. Coupled design __________________________________________________ 147
Figure 5-7. House of quality _________________________________________________ 149
Figure 5-8. Interaction matrix ________________________________________________ 150
Figure 5-9. Dependencies between design requirements __________________________ 150
Figure 5-10. Recursive use of QFD_____________________________________________ 151
Figure 5-11. Dependent, independent and interdependent design tasks ______________ 152
Figure 5-12. Productive reasoning ____________________________________________ 156
Figure 5-13. The Design Cycle ________________________________________________ 156
Figure 5-14. Exploration versus the Design Cycle _________________________________ 159
Figure 5-15. Allocation of one function to two modules ___________________________ 159
Figure 5-16. VDI 2221 and the Design Cycle _____________________________________ 160
Figure 5-17. Axiomatic Design and the Design Cycle ______________________________ 160

xi
Figure 5-18. Quality Function Deployment and the Design Cycle _____________________ 161
Figure 5-19. Organising Tasks and the Design Cycle _______________________________ 161
Figure 5-20. Formalised product descriptions ___________________________________ 162
Figure 5-21. Craftsmanship __________________________________________________ 162
Figure 5-22. Physical model and physical artefact ________________________________ 163
Figure 5-23. Specifications and physical model __________________________________ 163
Figure 5-24. Abstraction levels and domains ____________________________________ 165
Figure 5-25. Granularity and allocation _________________________________________ 166
Figure 5-26. Constraints on the functional decomposition__________________________ 166
Figure 5-27. Systems Management ____________________________________________ 167
Figure 6-1. Example of product variants ________________________________________ 171
Figure 6-2. Example of co-ordinated product architectures _________________________ 172
Figure 6-3. Scaleable interface _______________________________________________ 173
Figure 6-4. Non-scaleable interface ___________________________________________ 173
Figure 6-5. Non-scaleable component families ___________________________________ 174
Figure 6-6. Interfaces between component variants ______________________________ 174
Figure 6-7. Interfaces _______________________________________________________ 175
Figure 6-8. Overview of models ______________________________________________ 183
Figure 6-9. Families, subfamilies and variants ___________________________________ 184
Figure 6-10. Decomposition _________________________________________________ 184
Figure 6-11. Family and variant decomposition __________________________________ 185
Figure 6-12. Families and subfamilies __________________________________________ 186
Figure 6-13. Non-hierarchical relationships _____________________________________ 186
Figure 6-14. Mappings between models ________________________________________ 187
Figure 6-15. Parameters and parameter values __________________________________ 188
Figure 6-16. Selection conditions _____________________________________________ 189
Figure 6-17. Selection constraints _____________________________________________ 190
Figure 6-18. Parameter conversion ____________________________________________ 191
Figure 6-19. Documents ____________________________________________________ 192
Figure 6-20. Consistency ____________________________________________________ 193
Figure 6-21. Parameters driveable and turnable _________________________________ 195
Figure 6-22. Exchanging a component _________________________________________ 196
Figure 6-23. Parameters and interfaces ________________________________________ 197
Figure 6-24. Parameters and functions _________________________________________ 198
Figure 6-25. Function decomposition __________________________________________ 198
Figure 6-26. Reusing parameters _____________________________________________ 199
Figure 6-27. Design object and document ______________________________________ 201
Figure 6-28. Document with implicit structure ___________________________________ 202
Figure 6-29. Split documents _________________________________________________ 202
Figure 6-30. Document with implicit variety _____________________________________ 202
Figure 6-31. Conditional documents ___________________________________________ 203
Figure 6-32. The intradomain and interdomain perspectives ________________________ 203
Figure 6-33. Models and derived models _______________________________________ 204
Figure 6-34. Deriving a model ________________________________________________ 206
Figure 7-1. Different allocations ______________________________________________ 212
Figure 7-2. Verification of new information _____________________________________ 213
Figure 7-3. Overview of the design process _____________________________________ 213
Figure 7-4. Allocating system functions to a module ______________________________ 214
Figure 7-5. Designing a sub-system ____________________________________________ 214
Figure 7-6. Designing sub-systems in parallel ____________________________________ 215

xii
Figure 7-7. Integration of functions, modules and assemblies _______________________ 216
Figure 7-8. Function family versus module variant ________________________________ 217
Figure 7-9. Function variant versus module family ________________________________ 217
Figure 7-10. Initial costs versus operational costs ________________________________ 218
Figure 7-11. Design margin __________________________________________________ 219
Figure 7-12. Sequential design _______________________________________________ 221
Figure 7-13. Concurrent design _______________________________________________ 222
Figure 7-14. Timing the design process _________________________________________ 223
Figure 7-15. The scope of a product family ______________________________________ 224
Figure 7-16. Life-cycles _____________________________________________________ 225
Figure 7-17. Solution space __________________________________________________ 225
Figure 7-18. Path of changes _________________________________________________ 226
Figure 7-19. Standard products versus derived products ___________________________ 229
Figure 7-20. Derived products versus specials ___________________________________ 229
Figure 7-21. Differentiation versus reuse _______________________________________ 230
Figure 7-22. Early specific versus late specific____________________________________ 230
Figure 7-23. Commercial versus technical families ________________________________ 230
Figure 7-24. Completeness versus constraints ___________________________________ 231
Figure 7-25. Chance to meet customer requirements _____________________________ 231
Figure 7-26. Achieving a compromise __________________________________________ 232
Figure 7-27. Domains of Philips Medical Systems _________________________________ 233
Figure 7-28. Systems Management revisited ____________________________________ 235
Figure 7-29. Shapes of the CityVision __________________________________________ 239
Figure 7-30. Choice-sheet of the CityVision _____________________________________ 239
Figure 7-31. Light distributions _______________________________________________ 240
Figure 7-32. Electrical circuit _________________________________________________ 240
Figure 7-33. Allocating parameters to the HID electrical unit ________________________ 241
Figure 7-34. Shape drawings _________________________________________________ 241
Figure 7-35. Product Creation Process procedure ________________________________ 242
Figure 7-36. Product Creation Process of Philips Lighting ___________________________ 243
Figure 8-1. Functional and variety costs ________________________________________ 256
Figure 8-2. Life-cycles and orientation _________________________________________ 257
Figure 8-3. Business roadmaps _______________________________________________ 258
Figure 9-1. Decomposition of modules _________________________________________ 262
Figure 9-2. Instances of the classes: Module and Modular Structure _________________ 262
Figure 9-3. Modular structure ________________________________________________ 263
Figure 9-4. Notation conventions _____________________________________________ 263
Figure 9-5. Generalisation ___________________________________________________ 263

xiii
Table of tables
Table 1-1. A framework for defining innovation ___________________________________ 11
Table 2-1. Cardio-vascular parameters and the component families they effect _________ 63
Table 2-2. Selection conditions for primitive variants ______________________________ 64
Table 3-1. Function verbs ____________________________________________________ 76
Table 4-1. Parameters and parameter values ____________________________________ 120
Table 4-2. Selection conditions _______________________________________________ 121
Table 4-3. Example of implicit constraints ______________________________________ 122
Table 4-4. Complete generic product structure __________________________________ 126
Table 4-5. Identification and specification methods _______________________________ 129
Table 4-6. Example of identification methods ___________________________________ 130
Table 5-1. Unpartitioned and partitioned design structure matrix____________________ 153
Table 5-2. Relationships between product models ________________________________ 164
Table 6-1. Theoretical variants _______________________________________________ 195
Table 6-2. Parameters versus models __________________________________________ 199

xiv
Variety’s the very spice of life,
that gives it all its flavour.
W. Cowper

1. Introduction
The advent of the buyers’ market has imposed a necessity on manufacturing companies to
suit individual customer requirements. Companies have answered this need by offering a
large variety from which customers choose their ideal products. However, offering a large
product variety is not a solution when this variety is accompanied by high internal costs. The
solution for coping with the problem of mass-customisation lies in the development of
product families, which offer a large variety from a small set of modules that can be easily
combined. This thesis deals with such product families. It focuses on the structure of design
information of product families and shows how the evolution of this information in the
design process can be supported.
Today’s buyers’ market is a break with the past. The sellers’ market of the fifties and sixties
was characterised by high demand and a relative shortage of supply. Firms produced large
volumes of identical products, supported by mass production techniques. The traditional
mass-production company was bureaucratic and hierarchical. Under close supervision,
workers repeated narrowly defined, repetitious tasks. Of course, some companies produced
customised or highly differential products on customer-order, for example expensive
machinery. But their volumes were small and their costs were high. The main problem,
however, was that companies could pursue only two very distinct strategies. In other words,
companies had to choose between being efficient mass producers and being innovative
speciality businesses. According to Pine, Victor and Boynton [1993], this old competitive
dictum was grounded in the well-substantiated notion that the two strategies required very
different ways of managing, and, therefore, two distinct organisational forms.
The buyers’ market of the eighties and beyond is forcing companies making specific high-
volume products to manufacture a growing range of products tailored to individual
customer’s needs but at the cost of standard mass-produced goods. Figure 1-1 shows this
evolution in the automotive industry [Womack, 1991].
Figure 1-1. From craft production to mass customisation
Adapted from Womack ea. [1991]
Craft production is succeeded by mass production, in which a small set of products has to be
made in large volumes. Today’s mass customisation returns to craft production in the sense

Introduction
2
that a large set of products is made in small volumes, but now with the economy of scale of
mass production.
Nowadays, many companies go through these stages and adapt their products and design
strategies to cope with this changed environment. A first step in mass-customisation is the
adaptation of existing products and the creation of new products to individual customer
requirements. New components are developed to meet these requirements and initially the
added variety improves sales as the offerings become more attractive for individual
customers. The other side of this reactive approach is that the new products are dissimilar
and do not share a common architecture with common components. If sales engineers and
designers focus on individual customer requirements, they feel that sharing components
compromises the quality of their products. Therefore, they resist reuse of existing
components in a predefined architecture and diversity will be further increased.
A better approach is a pro-active development of product families. Reusable modules are
developed in such a way that they fit the predefined architecture of a product family.
Compromises are made in the design stage of the product family, independent from
individual customer-orders. The life-cycle of modules is considered so as to reuse modules in
different product variants and over different, possibly successive, product families. This
approach should maximise the ratio of external variety to internal design and manufacturing
efforts. It is, however, not the goal of this thesis to develop financial assessments for the
determination of optimal variety. The objective of this thesis is complexity management by
structuring design information in such a way that the transparency of a product family is
enhanced and that better decisions can be made using this information. This thesis will also
focus on the evolution of design information, since a well-understood design process is an
important factor in complexity management.
This thesis builds upon the work of many others. Much research in the modelling of product
families has been pursued by Wortmann, Van Veen and Hegge. They made an important
contribution to the reduction of complexity in the operational manufacturing process. The
objective of this thesis is to extend their concepts with the views that are relevant for the
design of product families. It will be argued that a product family can be described from
several perspectives, but that a complete design is constituted by putting together these
perspectives. Each perspective models the variety of a product family in a different way and
each model evolves in the design process in its own way. However, the consistency of
models in this dynamic process is vital to ensure that the developed product family meets
both external requirements such as customer variety and internal requirements such as
reusable modules.

Introduction
3
1.1 Overview of this thesis
Below the structure of this thesis is discussed. A graphical overview of the 8 chapters of this
thesis is depicted in Figure 1-2:
1. Introduction. Chapter 1 determines the scope of research and gives an introduction to
product families. A survey of terminology is presented and the role of product families in
business strategy, design and manufacturing is briefly discussed. Chapter 1 is concluded
with a problem statement and a research objective;
2. Problems with product variety. The problem of managing product families is defined in
more detail in chapter 2. Much attention is given to problems that different disciplines
face in the development of a large variety of products. The generic bill-of-material
concept is discussed as this concept has proven to be valuable for managing product
variety in the operational manufacturing process;
3. Languages for single products. In chapter 3, an overview of modelling languages for single
products is given. It is demonstrated that most product modelling languages are
applicable for a specific viewpoint or a specific technology and that these modelling
languages do not support the development of products in which several technologies are
incorporated, such as mechatronics;
4. Languages for product families. In chapter 4, an overview of modelling languages for
product families is given. Most of these languages are used in a specific field, such as
mechanical design, process planning or logistics. It is demonstrated that the generic bill-
of-material concept has a mechanism that can be used independent of a particular field
or discipline to model a product family in a non-redundant way;
Figure 1-2. Overview of this thesis
5. Design processes. Next to product modelling languages, this thesis discusses design
methods for supporting the design process. A distinction is made between models that
describe the design process and models that prescribe the design process. One design
method, named the Productive Reasoning Model, is discussed in more detail as it is an
important starting point for chapter 7;
6. Structuring product families. In this chapter, a definition of the notion product family is
given. Further, a product modelling language is developed to capture product variety in
the design process. It extends the generic bill-of-material concept with different domains
in which a product family is developed. Much attention is paid to consistency of
1. Introduction
2. Problems with
product variety
3. Languages for
single products
5. Design
processes
4. Languages for
product families
6. Structuring
product families
7. Developing
product families
8. Evaluation and
conclusions

Introduction
4
information, both within a domain and across domains. Finally, it is argued that product
models for use in operational processes can be derived from a product family model;
7. Developing product families. Chapter 7 proposes a design method for product families
that completes the product family modelling language of chapter 6. The family design
method can be used in all phases of the design process and for all levels of the design
hierarchy. Furthermore, issues such as reusability, concurrency, modularity and
integration are discussed;
8. Evaluation and conclusions. The solutions that are presented in this thesis are compared
with the original problem statement. Some conclusions are presented and directions for
further research are discussed.
Finally, this thesis is completed with appendices and literature references (chapter 9).
The remainder of chapter 1 defines the scope of research, discusses the role of product
modelling languages and design methods, formulates a problem statement and research
objective, and gives a short description of the applied research method.
Reading suggestion
The following chapters and sections are essential for achieving a good understanding of the
contents of this thesis:
1. Introduction
2.1. Domains, product models and representations
2.3. Industrial problem statement
2.4. Design problems
3.3. Non-compositional systems
4.3. Generic product structures (section 4.3.1. - 4.3.8)
5.5. Design Cycle
6.1. Definition of product family
6.2. Design of the product family modelling language
7. Developing product families
8.2. Conclusions
Furthermore, it can be recommended to read the introduction of each chapter.
1.2 Defining the scope of research
This thesis focuses on developing product families. Both the structure of product families
and the act of developing these families is discussed. This chapter first reduces the scope of
this thesis by defining product families in relationship to other classes of products. A
literature review (section 1.2.1) shows that the term product family is widely used, but refers
to different sets of products depending on the classification criteria that are used.

Introduction
5
Furthermore, this chapter discusses a few classifications concerning product families,
namely:
 a classification of design (section 1.2.2);
 a classification of manufacturing control (section 1.2.3).
The research discussed in this thesis focuses on product family development, although the
results seem to be generally applicable when it concerns the management of several
perspectives on a design.
1.2.1 Products and product families
In literature, product families are considered from many perspectives, each perspective
introducing its own terminology. Below, an overview of terminology is given to denote
product families and products in general. The term product family will be compared with
more general terms such as product platform and product range, and with more specific
terms such as product variant and single product. Then, for the purpose of this thesis, the
term product family will be defined in relationship to other definitions of products.
Terminology as used in literature
A literature review shows that many terms are used to describe a set of related products, for
example, product platform, product range, product family, product line, product class and
configuration product:
 Meyer and Utterback [1993] define product platforms and product families. A product
platform encompasses the design and components shared by a set of products. A robust
platform is the heart of a successful product family, serving as the basis of a series of
closely related products. New products are refinements or extensions of the platform.
These authors call products that share a common platform, but have specific features and
functions required by different sets of customers, a product family. A product family
typically addresses a market segment, while specific products or groups of products
within the family target niches within that segment. The commonality of technologies and
markets leads to efficiency and effectiveness in manufacturing, distribution, and service,
where the firm tailors each general capability to the needs of specific customer groups.
 Child, Diederichs, Sanders and Wisniowski [1991] define a product range as a set of
products that optimises market variety, maximises sales and minimises complexity. Such a
product range can be achieved by creating modular product concepts, in which large
components, sub-assemblies and interfaces are standardised. Furthermore, the number
of different manufacturing processes should be reduced.
 Onkvisit and Shaw [1989] distinguish product lines and product classes. A product line is a
group of related products, for example because they are sold together (e.g. hamburger
and a drink), they are used together (socks and shoes), or they are made together using
the same materials, equipment, technology or labour. If a line of audio products is taken
as an example, the product line consists of such products that perform complementary
functions related to sound production. Within each product line, there are usually

Introduction
6
product classes. A product class is a particular product designed to serve a specific
purpose or function. A product class often assumes a number of product forms. Such
forms may differ in shape, dimension, and other engineered characteristics. Yet all these
variations, regardless of their physical characteristics or appearance, still perform the
same function.
 Ulrich and Tung [1991] define a product family as a large set of end products constructed
from a much smaller set of components. They state that product variety is a potential
benefit of a modular design: the variety available in modular designs arises from the
ability to use one of several alternative component options to implement a functional
element of the design.
 Mittal and Frayman [1989] define configuration design as a special type of design activity,
with the key feature that an artefact of the family being designed is assembled from a set
of pre-defined components that can only be connected in certain ways. A configuration
product has the following properties:
 There is a limited and fixed set of components that can be used to configure new
artefacts, i.e. the number of possible configurations is restricted;
 Each component has predefined and fixed interfaces to connect to other components.
Interfaces are abstractions for places where a component can be connected to other
components. A solution not only specifies the actual components but also how to
connect them; it is not enough to just identify the components;
 Designing a class of artefacts leads to an understanding of the functions that must be
met and provides rules on how these functions compose and interact. This is often
codified in the form of an architecture that guides the design of such artefacts.
 Erens, Hegge, Van Veen and Wortmann [1992] focus on managing product variety in the
logistics process. They give a definition of a product family with similar properties to
those given by Mittal and Frayman:
 A product hierarchy is defined as an acyclic graph of product families. The leaves of the
tree are called primitive families, all other families are compound families. The latter
are composed of primitive and compound families. For example, a motor car family is,
amongst others, composed of an engine family, which in turn is composed of a
crankshaft piston family;
 Primitive families have a fixed number of (primitive) variants from which compound
variants (configurations) on higher levels in the product hierarchy can be assembled.
For example, crankshafts and pistons in different sizes create a variety of engines
which in turn create an even larger variety of motor cars;
 Parameters and parameter values can be linked to any family in the product hierarchy
and define the possible set of configurations from a commercial viewpoint. They are
used by customers and guide the selection of primitive variants for the assembly of
compound variants;

Introduction
7
 Constraints are defined in terms of parameters and parameter values to exclude
unwanted or impossible configurations by prohibiting the selection of certain
combinations of primitive variants.
 Most authors make a distinction between variants and versions. A variant is a unique
configuration of modules of a product family, while a version is a semantically meaningful
snapshot of a design object at a point in time. Both variants and families can have
versions. A version is descendent from existing versions and can serve as an ancestor of
additional versions. All versions of a design object together make a version history.
 Some authors discuss products on the level of features. In configuration design, a feature
is a functional attribute of a product family, similar to a parameter, and is used to specify
a unique variant. Therefore, each feature (or parameter) has a set of options (or
parameter values) from which one must be selected. Other authors discuss accessories as
a sort of modular options, in the sense that they can be easily added to an existing
product variant.
 In mechanical design, a feature is an abstraction of lower-level design information.
Cunningham and Dixon [1987] define a feature as any geometric form or entity that is
used for reasoning in design (product features) or in manufacturing (manufacturing
feature), for example surfaces of machined parts, holes, bosses and ribs. Also features can
have parameters, for example the diameter and size of a hole. Then the act of assigning
values to the parameters will make the feature specific in its application. In that respect, a
parametrised feature can be regarded as a family of which the variants are achieved not
by combining component variants into new configurations, but by machining a
component in a different way.
 Finally, Hatley and Pirbhai [1987] give a design method for real-time systems, in which
they pay attention to the behaviour of systems. A system is a collection of states, of which
one is valid at a certain moment in time. Past and present events, both external and
internal, change the product state and in that respect the behaviour of the system. For
example, the state of a gearbox depends on the gear that is selected and the power that
is provided by the engine. A gearbox, or any other specific machine, can be regarded as a
collection of states.
Terminology as used in this thesis
Based on the literature review, the following summary presents some terms that are used in
this thesis. Some of these terms will be defined more formally in chapter 4 and chapter 6
where product families are discussed from a modelling perspective.
product platform An architectural concept comprising interface definitions and key-
components, addressing a market and being a base for deriving
different product families. Examples of product platforms are a
digital architecture for medical equipment, an operating system, and
the floorpan of a range of cars.

Introduction
8
product architecture A set of modules connected through interfaces and performing a
certain operation. A product architecture partitions the solution
space of design, sets conditions for a further decomposition of these
modules and specifies the application of these modules in a bigger
whole.
product family A product concept that is designed for a market but caters for the
individual wishes of customers by introducing variety within a
defined product architecture and within a defined manufacturing
process. For example, a family of cars, televisions or medical systems.
product structure A description of the elements of a product identified by their
type, and the relations between these elements. A product structure
is context dependent: the selection of elements and their
relationships depends on the viewpoint taken.
product variant An occurrence of a product family, sometimes introduced as a
product of its own, sometimes derived from a product family on
customer-order. For example, a television set purchased at a retailer
or a medical system ordered at the manufacturer.
single product A product that has hardly any pre-defined relationships with other
products. Any resemblance with other products is mainly coincidence
or due to the style of the maker. For example, a painting by
Rembrandt, a house by Frank Loyd Wright or a machine that is
designed and built to meet unique customer requirements.
product feature A generic shape with which engineers associate certain properties or
attributes and knowledge useful in reasoning about the product
[Shah, 1991].
product parameter A variable quantity or quality that makes a product family specific.
Parameters are used to derive a product variant from a product
family, but also to make a product feature specific for its application.
version A semantically meaningful snapshot of a design object at a point in
time.
state The attributes’ values of a product variant or single product that are
relevant for its behaviour at a certain point in time.
Some of the above terms can be listed with a decreasing order of design freedom. Brown
and Chandrasekaran [1983] define the design problem as a search problem in a very large
space for objects that satisfy multiple constraints. Only a vanishingly small number of objects
in this space constitute satisfying solutions. The following figure expresses, in a rather
qualitative way, how this solution space is reduced in product design and variant derivation.

Introduction
9
Figure 1-3. Decreasing solution space
The initial solution space of a product platform is constrained by the current state of
technology, the market at which the product platform is addressed and the technical
possibilities for manufacturing. This solution space is further reduced by the specifications
for a product family and the power of a firm to turn these specifications into reality. Typical
for a product family is that the derivation of variants, and the accompanying shrinkage of
solution space, does not require intensive efforts in design. The possibilities to derive
variants from the product family concept are usually considered at an early stage of the
design process. This thesis will mainly consider product families that have been designed in
such a way that the design of variants has been converted into a parameter selection
problem.
After a specific variant has been determined, the customer can change the state of the
solution space by actually using the product variant. The horizontal line in Figure 1-3
represents the remaining solution space. Lately, the use of embedded software has enabled
manufacturers to enlarge the solution space without acquiring extra manufacturing costs.
The product application area, or in other words, the scope of the family of states, is
enlarged. This means that the use process has gained importance over the variant derivation
process with respect to making the product family specific for a certain user application
1
.
However, the use process and other dynamic aspects of the product family’s variants are not
discussed
2
.
This thesis will mainly concentrate on product families and their variants. Product platforms,
for example, are only discussed to show that the developed principles can be generally
applied in the aforementioned solution space. With respect to product families, it will be
stated that the variety at the top-level results from the variety at lower levels in the
predefined product structure.
Figure 1-4 shows a graphical presentation of variety using a diabolo, which represents the
number of products on the x-axis and the levels of the product structure on the y-axis. For
most assembled product families, the variety of end-products is caused by the variety of a
1
The use process and other dynamic aspects of the product family’s variants are not discussed in this thesis.
The interested reader is referred to Hatley and Pirbhai [1987] or Stevens [1994].
2
The interested reader is referred to Stevens ea. [1994] and Rumbaugh [1994].

Introduction
10
limited number of modules. These modules, in turn, are constructed from a larger set of
component variants.
Figure 1-4. Diabolo
The terminology that is introduced in this figure is subject to judgement. The remainder of
this thesis does not discriminate between end-products, modules and components. These
are just names for products at a certain level in the product structure. In chapter 3, 4 and 6,
more precise definitions from a modelling language viewpoint are given.
1.2.2 Classification of design
This section addresses two different classifications of design. The first classification discusses
the role of architectures and separates innovation of modules and innovation of the
relationships between modules. The second classification pays attention to how far the
requirements for a new design penetrate the product hierarchy and make use of existing
concepts and modules.
Modules and architectures
Henderson and Clark [1990] state that the distinction between radical and incremental
innovation has produced important insights, but is fundamentally incomplete. Incremental
innovation introduces relatively minor changes to the existing product, exploits the potential
of the established design, and often reinforces the dominance of established firms. Radical
innovation, in contrast, is based on different engineering and scientific principles and often
opens up whole new markets and potential applications. Radical and incremental
innovations have such different competitive consequences because they require quite
different organisational capabilities.
However, according to Henderson and Clark, there is growing evidence that there are
numerous technical innovations that involve apparently modest changes to the existing
technology but have quite dramatic competitive consequences. They give the following
example:

Introduction
11
“ Xerox, the pioneer of plain-paper copiers, was confronted in the mid-1970’ with competitors
offering copiers that were much smaller and more reliable than the traditional product. The
new products required little new scientific or engineering knowledge, but despite the fact that
Xerox had invented the core technologies and had enormous experience in the industry, it took
the company almost eight years of missteps and false starts to introduce a competitive product
into the market. In that time Xerox lost half of its market share and suffered serious financial
problems. ”
Henderson and Clark define innovations that change the way in which the components of a
product are linked together, while leaving the core design concepts untouched, as
architectural innovation. It greatly diminishes the usefulness of a firm’s architectural
knowledge but preserves the usefulness of its knowledge about the product’s components.
Table 1-1 classifies innovations along two dimensions. The horizontal dimension expresses
the impact of an innovation on core concepts, while the vertical captures its impact on the
linkages between modules.
Core concept reinforced
Core concept overturned
Linkages unchanged
Incremental Innovation
Modular Innovation
Linkages changed
Architectural Innovation
Radical Innovation
Table 1-1. A framework for defining innovation
Source Henderson and Clark [1990]
As can be seen from Table 1-1, radical and incremental innovation are extreme points along
both dimensions. Furthermore, two other types of innovation are shown. Modular
innovation changes the core concepts of some modules within a stable product architecture,
for example the replacement of an engine type in an existing car design. The second type of
innovation, named architectural innovation, changes the linkages between modules, for
example the design of a small copier that uses many modules of larger copiers, however in a
new arrangement.
The above classification shows that the concept of product families requires a certain
maturity of both market and technology. This maturity is reflected in a stable product
architecture that addresses a well-known market. Variety is created by changing
components in a pre-defined architecture. This requires the acceptance of a dominant
design which incorporates a range of basic choices about the design that are not revisited in
every subsequent design, for example when a specific variant is derived from the product
family concept. Usually, these dominant designs do not exist yet for innovative products, as
the relationships between function and technology are not fully understood and still subject
to improvement.
If the basic function, technology and architecture of a product are familiar enough to create
variations that cater for individual customer requirements, a product family can be
developed. If the architectural knowledge is stable, it tends to become embedded in the
practices and procedures of the (learning) organisation. In these cases, only incremental and
modular innovations seem to be possible. A radical or architectural innovation requires the

Introduction
12
development of a new product platform causing many changes for a company [Morris,
1993]. Real innovative products are usually not designed as a product family. New
technologies, or new combinations of technologies, require considerable experience before
they can be applied such that they meet a diverse range of customer requirements.
Reuse and product hierarchies
Design can be classified according to the extent that it makes use of existing designs and
solution concepts. For each design task, the availability of a possibly large and generally only
implicitly specified set of primitive design objects can be assumed [Brown, 1985]. The design
domain also specifies a repertoire of primitive relations or connections possible between
these design objects.
An automotive engineer, for example, may assume the existence of gearboxes and engines
when designing a new car. Knowledge about all functional and mechanical interfaces
provides for a design independent from the design of the gearbox and the engine. On a
lower level in the design hierarchy, another designer may assume primitive objects as chain-
wheels and shafts when designing a gearbox.
The idea that the primitiveness of design objects is a relative notion is depicted in the
following figure. The diamond-shaped figure represents the design hierarchy of a product
that is assembled from a large set of components, which in turn are manufactured from a
small set of chemical elements. The horizontal lines are natural or organisational boundaries
in the design and divide for each domain the primitive and assembled design objects.
Figure 1-5. Design hierarchy
Because the universe is a hierarchy of systems with many levels, the word system can be
applied at any of these levels [Bowler, 1981]. However, lower-level systems tend to have a
longer life-cycle than higher-level systems. The stability of primitive systems is a necessary
condition for the creation of compound systems. The above figure also illustrates that design
is a recursive activity: if an assumed primitive design object is not available, the design of
that object can be undertaken independent of the main design [Simon, 1981]. This requires
however that this object can be regarded as a black-box, of which the interfaces in terms of
function and physical fit are known.
According to Brown and Chandrasekaran [1989], the complexity of design is, to a large
extent, determined by the availability of primitive objects together with effective

Introduction
13
decomposition strategies to find the right combinations of primitive objects. Based on this,
they propose the following classification of design
1
:
 Class 1 design. This is an innovative type of design which leads to a major invention or
completely new products. Goals are ill-specified, no storehouse of effective
decompositions exists and no precompiled partial design solutions are available. For each
potential sub-problem, further work has to be done in evaluating if a design plan can be
constructed. Class 1 design is comparable to radical innovation (Table 1-1).
 Class 2 design. This type of design activity is characterised by the existence of powerful
problem decompositions. The design of a new motor car, for example, does not involve
new discoveries about decompositions: the structure of the automobile together with the
general interfaces of the main subsystems has been fixed for quite a long time. On the
other hand, several of the components in this architecture constantly undergo major
technological changes, and routine methods of design for some of them may no longer be
applicable. Class 2 design often reuses existing modules as the linkages between modules
remain unchanged. Class 2 design is comparable to modular innovation (Table 1-1).
 Class 3 design. This is relatively routine design, similar to incremental innovation (Table 1-
1), where effective problem decompositions and compiled design plans for the
component problems are known. Class 3 products are often tailored to the installation
site while retaining the same structure and general properties. For example, an air-
cylinder intended for accurate and reliable backward and forward movement of some
component will need to be redesigned for every new customer in order to take into
account the particular space into which it must fit or the intended operating
temperatures and pressures [Brown, 1983].
Shah and Wilson [1988] give similar design categories but add a fourth one, named design
synthesis, which can be regarded as simplified Class 3 design. It concerns the derivation of
products with a predefined architecture from standard components. All necessary design
effort can be automated, similar to the derivation of variants from a product family. In
literature, several approaches are mentioned for deriving variants from a generic design:
 Grammars. Mullins and Rinderle [1991] propose the use of grammars to automate the
design. A grammar is a definition of a language written in a transformational form. The
grammar of a natural language, such as English, determines how words may be arranged
to form a syntactically correct sentence [Rinderle, 1991]. A design grammar specifies how
components can be arranged into acceptable products. Design grammars are especially
suitable for alternative configurations with standard components and slightly different
product architectures.
 Rule-based systems. McDermott [1980] describes R1, a rule-based system, to configure
Digital Equipment Corporation’s VAX systems. The system contains descriptions of all
components supported for the VAX. As R1 begins to configure an order, it retrieves the
1
A similar classification is given by Muntslag [1993]. This classification is named the design decoupling point
as it states how far a new design penetrates the product hierarchy. It can be compared with the customer-
order decoupling point that is discussed in section 1.2.3.

Introduction
14
relevant component descriptions and production rules. Since an order frequently lacks
one or more components required for the system function, a major part of R1’s task is to
notice what components are missing and add them to the order. Its rules have conditions
that recognise situations in which a particular type of extension to a particular type of
partial configuration is permissible or required; the actions then effect that extension.
This thesis, however, concentrates on product families that are designed in such a way that
the designs of product variants can be automatically derived from the family design using a
parameter selection mechanism. The design of the product family itself, however, is usually
a Class 2 design. If there are any major technological changes (Class 1 design), they play a
role on the level of components and can be regarded as modular innovations, which do not
considerably modify the product family architecture. As stated before, Class 1 products are
usually not designed as product families. The complexity of interactions between new
primitive design objects does not allow the creation of several customer options.
Figure 1-6. Product families and design
Figure 1-7 repeats the diamond-shaped structure for product families. The main architecture
can be regarded as a Class 2 design, although some components that are critical to the
function can be considered Class 1 designs. The derivation of product variants, indicated
with a dotted line, is Class 3 design. This thesis only considers the automatic derivation of
variants with a parameter selection mechanism.
1.2.3 Classification of manufacturing control
In this section, attention is paid to an often used classification for goods flow control and
manufacturing. This classification is based on the concept of the customer-order decoupling
point. The customer-order decoupling point in manufacturing is similar to the design
decoupling point, which was discussed in the previous section. That section discusses how
design requirements for a new product are decomposed till the level that primitive design
objects are available that meet these detailed requirements.
In manufacturing, the customer requirements are decomposed into the product’s
components till the necessary components are available on stock. For understanding the
customer-order decoupling point, it is important to distinguish between anonymous and
dedicated stock. Anonymous stock decouples the main production process from the
fluctuating customer demands, while for dedicated stock, customer-orders are already
known. The first stock type is only needed if differences exist between the requirement time
and the precise moment of availability.

Introduction
15
The customer-order decoupling point separates the customer-order driven part of the
activities from the activities that are based on forecast and planning. In general, the
decoupling point will coincide with a main stock point. Hoekstra and Romme [1992]
distinguish five different positions of the customer-order decoupling point to describe the
most distinguishable product-market situations in the control concept. These are graphically
depicted in Figure 1-8.
1. Make and ship to stock. Products are manufactured and distributed to stock points, which
are spread out and located close to the customer.
2. Make to stock (MtS). End products are held in stock at the end of the production process
and from there are sent directly to many customers who are scattered geographically.
Figure 1-7. Customer-Order Decoupling Point
Source: Hoekstra and Romme [1992]
3. Assemble to order (AtO). Only system elements or subsystems are held in stock in the
manufacturing centre, and the final assembly takes place on the basis of a specific
customer-order.
4. Make to order (MtO). Only raw materials and components are kept in stock: each order
for a customer is a specific project.
5. Purchase and make to order. No stocks are kept at all: purchasing takes place on the basis
of the specific customer-order; furthermore, the whole project is carried out for the one
specific customer.
The above classification helps in understanding the presence of variety in a certain product-
market combination. Usually, products that are made or shipped to stock have a limited
variety, as it is not possible to keep all variants of a large product family on stock. On the
other hand, products that are assembled, made or purchased to order give the opportunity
to create with a limited number of modules an almost infinite variety. Recently, the
development of embedded software has enabled manufacturers to make a product specific
at the time of use.
As customers accept a longer lead-time, if they perceive the product as made to customer-
order, it is acceptable to move the customer-order decoupling point upstream and thereby
reduce considerable stocks of finished products [Giesberts, 1992]. However many
manufacturers pursue a hybrid manufacturing strategy in which a limited set of product

Introduction
16
variants is made to stock, while others are assembled to order and a third group is even
made or engineered to order
1
.
This thesis pays most attention to products that are assembled to customer-order. The
generic bill-of-material concept, which will be discussed extensively in chapter 2 and 4, is a
product modelling language that has been created to allow the derivation of a customer-
order specific bill-of-material from a family bill-of-material. It will be argued that this concept
can also be used to derive designs from a family design. Furthermore, a slightly modified
concept can be used to capture the characteristics of a product family in the process of
designing. The complexity of products that are assembled to customer-order for often
demanding and professional users is such that especially these manufacturers can benefit
from the product family modelling language and the design method for product families
defined in this thesis. However, some aspects of these modelling languages are useful
independent from the variety of the product or the chosen manufacturing concept as they
deal with preserving consistency between domains in the design process.
1.3 Product modelling languages and design methods
The introduction of this thesis already stated that the foundation of this research lies in
modelling languages
2
to describe the artefact. A large part of this thesis is devoted to these
languages and the models that can be created with them. This thesis distinguishes two types
of product modelling languages:
1. Languages for “compositional systems” are based on theories from natural science. As
these languages are based on the laws of nature (e.g. electronics and hydraulics) or
mathematical principles (e.g. software), they are able to formally define the relationship
between function and realisation. Important in these rational approaches is that natural
phenomena can be understood and modelled at all levels of the product model. In other
words, the function of a product can be composed from the functions of its components if
the components’ relationships are understood. As a consequence, also the design process
of these products can be executed in a methodical way, thereby decomposing the
function and realisation simultaneously;
2. Languages for “non-compositional systems” define the function and the realisation of a
product separately. For mechatronic products, comprising a variety of technologies, there
is no grand theory that links these technologies into one uniform and predictive theory.
Although some unified theories exist, for example for electro-magnetism, there is no
general design theory in which the function of a mechatronic product can be described
and predicted without considering the different technologies separately. Therefore,
dedicated modelling languages exist to describe the function of such a product,
1
Wemmerlöv [1984] discusses the relative differences between MtO, AtO and MtS strategies, including
reasons why a company may decide to be an AtO manufacturer. Chapter 2 discusses a case study of a
company which has gone through several of these manufacturing strategies.
2
A product modelling language is a system of symbols and rules which is meant to describe a product
unambiguously. In this thesis, a conceptual data model (see section 9.1) is used for defining a modelling
language for product families.

Introduction
17
independent from the possible technological solutions. Also the realisation of the product
is described with dedicated modelling languages, however without maintaining a formal
link between this realisation and the function.
Design is characterised by several domains that contribute simultaneously to the creation of
a product family. A domain is defined as a product model together with all viewpoints on
this product model. This thesis asserts that there are three domains in which a product
family is defined:
1. Functional domain, defining the required function or behaviour of the product family to
be designed;
2. Technology domain, defining the technological realisation of the function in terms of
solution principles, however independent of the final physical shape;
3. Physical domain, defining the physical materialisation of the technological solution
principles in such a way that the product variants can be efficiently manufactured.
Chapter 3 and chapter 4 of this thesis discuss a number of compositional product modelling
languages that cover the functional, technology and physical domain. However, products
that use different technologies to realise user functions are often described with dedicated
modelling languages for these three domains. For these non-compositional systems, there is
no modelling language that unites all natural phenomena and mathematical principles.
Although this thesis describes both types of modelling languages for these domains, the
scope of the solutions presented in this thesis is restricted to non-compositional product
families. This has consequences for the product family modelling language of chapter 6 and
the family design method of chapter 7. The product family modelling language should be
able to describe the structure of a product family in three domains independent of the
different representations of this structure. The family design method should be able to
relate function, technological realisation and physical implementation, not for reasons of
formalisation, but for managing the complexity of the design process.
1.4 Problem statement and research objective
This thesis focuses on ways to manage variety in the design process. Both, product models
for capturing the product definition and design methods for guiding the design process are
discussed. The problem statement of this thesis is summarised as follows:
 Currently, no attention is given to the integral design of product families. If families or
variants are discussed, it is presupposed that a product family is the result of several
related but sequentially designed variants. Existing product modelling languages focus on
the design of single products and do not support the structuring of a product family. This
statement holds especially for product families, in which different technologies are
applied;
 There are several domains, having different representations of a product family being
designed. All domains structure information in particular ways to accommodate their own
needs. The design of such an intangible entity as a product family is hindered if these

Introduction
18
domains are not linked in a consistent way. This concerns both representations used in
development and representations used in operational processes such as sales,
manufacturing and service;
 Product models for capturing the structure of a product family are insufficient if these are
not completed with design methods. Design is not only constituted by design processes
that take place within a domain, but especially by processes that take place between
domains. Furthermore, most design methods focus on defining phases of the design
process without considering the quality of the design artefact at each phase.
From this problem statement, the following research objective can be derived:
 Develop a product modelling language that is suitable for structuring product family
information in different domains. Link these domains in such a way that consistency of
information is preserved. Deduce how information that is used in operational sales and
manufacturing processes (including sales and service) can be derived from this design
information;
 Develop a design method that supports the design process of product families and guides
the evolution of design information, including the way that this information is structured.
State the interactions between the design process and the product family model, taking
into account the different domains in which a product family exists.
A solution to the problem statement is discussed in chapter 6 and chapter 7. The extent to
which this solution meets the research objective is subject of chapter 8.
1.5 Research method
The objective of this study is not to investigate all problems that manufacturing companies
face with the management of product variety. Neither is this a study that is based on a large
number of case studies. The seriousness of the variety issue is acknowledged through
literature and personal observations. According to the standards of natural science with its
analytical and empirical techniques, these observations are insufficient to draw general
conclusions [Popper, 1968]. Therefore, this research is design oriented. A modelling
language for product families and a modelling language for the design process of a product
family will be designed. The industrial merit is still small, but so far, several case studies have
approved the theories presented in this thesis.
It can be asserted that the theory of a product family modelling language, which is
developed in this thesis can be logically derived from theories of modelling languages for
single products and theories of variety management in manufacturing. Both, theories of
modelling languages for single products and theories of variety management in
manufacturing have proven their merit in many industrial companies. The combination of
both theories results in a theory for structuring a product family in different design domains.
The theory of a family design method is derived in a similar way from the product family
modelling language and existing design methods for capturing the design process.

19
Design is 100 people in a room arguing.
Anonymous

20
2. Problems with product variety
Many manufacturing companies face a problem with product variety. Difficulties occur when
companies cannot deal with the complexity of many similar, but not identical, products. This
part lists some problems, but also presents solutions that have been developed for
production control and which have been a source of inspiration for this thesis.
The overview of problems presented here is not meant to be exhaustive, neither is it stated
that manufacturing companies face all these problems simultaneously. As an illustration, this
thesis presents a case study and some examples, which put a selection of these problems in
an organisational context. This case study stresses the fact that product variety is especially a
problem when several domains are involved in the operational and development process.
The following sections discuss problems related to product variety:
2.1. Domains, product models and representations. This thesis acknowledges three
domains in which a product family is designed, namely the functional, technology and
physical domain. Each domain has a product model, which acts as a framework for
capturing domain specific information. Manufacturing disciplines in a company make
use of these domains in both development and operational manufacturing processes;
2.2. Manufacturing disciplines and domains. There are a number of disciplines that
contribute to the product development process, for example marketing,
manufacturing engineering, purchasing and service. Each of these disciplines imposes
different requirements on how the product family is decomposed. Different
manufacturing functions of a company face different problems regarding product
variety in these domains;
2.3. Industrial problem statement. The most evident aspect of product variety is its
uncontrolled growth. When products are added to an existing product family, the
possibility of managing all variants of the product family in the same way is diminished.
A solution lies in developing components that are reused over several product families
and product variants. This requires, however, sufficient knowledge about the market
and a development philosophy in which reusability is accommodated;
2.4. Design problems. The main focus of this thesis is on the design of product families,
through the extension of concepts developed for manufacturing control. In design,
several disciplines contribute to the evolution of product family data. In this chapter,
attention will be paid to problems arising from communication within and between
domains;
2.5. The intangibility of product families. Single products exist physically, product families
do not. The fact that a product family is an intangible entity is considered to be a
primary obstacle to effective communication in, and between, both the operational
process and the development process.
2.6. Product family descriptions. The problem of product variety was first signalled in
production due to its repetitive nature. An evolution of solution concepts is discussed

Problems with product variety
21
including the generic bill-of-material concept, which is amongst the most advanced for
managing product variety. The different concepts are illustrated with a case study of a
company named Philips Medical Systems. This company has been chosen for this case
study as it has gone through several phases of describing product families.
Finally, in chapter 2.7, a summary of problems is given. These problems will be used as
requirements for the design of a product family modelling language and a family design
method. The summary states that the origin of many problems lies in the definition of a
product family in several domains. Only if these perspectives agree on the boundaries and
characteristics of the product family being designed, it can be guaranteed that balanced
design decisions are taken and that eventually customers recognise their requirements in
the derived physical variants.
2.1 Domains, product models and representations
Development is characterised by several domains that contribute simultaneously to the
creation of a product family. As stated before, a domain is defined as a product model
together with all representations of this model. Chapter 3 of this thesis asserts that three
domains are sufficient to capture product information in the development process. These
domains are also acknowledged by other authors, including Pahl & Beitz [1984], Albano &
Suh [1992] and Kota & Lee [1990]:
 functional domain;
 technology domain;
 physical domain.
The initial specifications can not be attributed to one particular domain as they provide an
often informal description of the required function, the technological constraints and the
physical constraints. Specifications are the starting point for the development of a product
family. The fact that product families are mature products that are sold in often competitive
markets puts a high pressure on meeting individual customer wishes. Initial requirements
reflect these wishes by defining both the core function and the options in commercially
understandable terms. Therefore, the initial requirements are usually expressed in a text-
based format, which is convenient for validation with customers, but weak for indicating
dependencies and constraints. However, not all aspects of the initial requirements are
functional and therefore determined by customer wishes. Some aspects are stated by
product management and express the company’s demands with respect to the (re)use of
technology, components and manufacturing processes. In this sense, non-functional
requirements or constraints on the solution are stated. Finally, the initial requirements
should be such that the attributes of the resultant design, or any intermediate stage, can be
compared with these original requirements.

Problems with product variety
22
Figure 2-1. Specifications, domains and product models
Figure 2-1 shows that specifications are formalised in product models
1
. These models act as
backbones for structuring the domain specific information, which is represented with
modelling languages. The remainder of this section describes the functional domain,
technology domain and physical domain in more detail:
 The functional domain results from those initial requirements that define the function of
the product family. Functions should provide a complete and unambiguous description of
the product family, and are expressed in such a way that functional dependencies that
are relevant for development are clearly indicated. These dependencies concern interface
definitions that deal with interactions between functions. Interactions are often
represented as non-hierarchical relationships, for example flows of material, energy and
signals [Pahl & Beitz, 1984]. If a product function is too complex for a direct realisation, it
can be decomposed into sub-functions. This results in a hierarchical function structure,
which represents the function of the product on different abstraction levels. Customer
options are specified by introducing function variants, together with commercial or
functional restrictions on combinations.
 The technology domain represents the technological realisation of the design problem
and consists of a set of modules or solution principles, which together cover the required
function. For example, a company manufacturing X-ray equipment will have, among
others, the following technologies: image-quality, power generation, image acquisition
and user-interface. These company specific technologies build upon a large set of basic
technologies such as electronics, hydraulics, geometry and software. Designers map
functions onto modules, thereby taking into account constraints on the solution. A set of
modules is hierarchically composed to create the design artefact, but can also be further
decomposed by adding necessary detail. If functions are interconnected to express
functional dependencies, then modules have interfaces for technological dependencies.
Finally, modules can exist in module variants to cater for the functional variety;
 Just because a concept that is described in the technology domain proves to meet the
required function does not mean it can be manufactured. Therefore, the physical domain,
which is often the responsibility of engineering
2
, can differ from the technology domain.
1
In the remainder of this thesis, circles denote functions, squares denote technology modules and triangles
denote physical assemblies.
2
In this thesis, engineering is responsible for realising the physical product, while manufacturing engineering
is responsible for realising the manufacturing process. Design is responsible for creating the functional
definition and the technological realisation.

Problems with product variety
23
Nevertheless, engineers should be involved in both the functional specification and the
technological realisation to guarantee the creation of a suitable physical model. Despite
the fact that the physical domain eventually describes the same artefact as the functional
domain and the technology domain, it can be different as modules can be adapted for
physical reasons, for example resulting from a specific assembly process. An engine, for
example, is often assembled together with its gearbox, even when the engine and
gearbox are designed as relatively separate entities in the technology model. The
determination of valid assembly relationships puts specific requests on the geometric
relationships between the elements of the physical model. Similar to functions and
modules, (sub)assemblies can have variants from which instances of the family are
assembled.
Product models structure the product from the perspective of the functional domain,
technology domain and physical domain. Despite the fact that these structures prescribe the
design artefact, different disciplines can have their own views on these models, for example
a two-dimensional or three-dimensional view on the physical model. Further, some
disciplines define views that go beyond individual models. The service discipline, for example
is interested in functions, the applied technologies and the physical shape. Finally, some
disciplines can re-arrange the information that is contained in a product model for their
purposes. However, the source of information should be clear to maintain the domain’s
consistency between the product model and its representations.
Each discipline creates, edits and uses information, and some of this information will be
shared among several disciplines. The domains have product models, which act as back-
bones for the information needs of disciplines. Discipline specific information is represented
with specific modelling languages, which are assigned as documents to product models. A
domain is the ensemble of its product model and the different representations. In general
there are three ways to assign documents to a product model:
 The following figure shows a product model, which acts as back-bone for a variety of
representations. In this case the product model concerns the physical model. The
representations share this structure and are indicated with a document symbol. Due to
computerised means, it is often possible to derive several representations from a single
product model. A well known example concerns a solid-model in computer-aided design
(CAD) from which both 2-dimensional and 3-dimensional views can be obtained.
Figure 2-2. One product model, different representations
This “single product model” approach is often encountered in companies where the
logistic discipline is dominant. The database of a production control system (such as MRP
II) has then attributes for other disciplines as well. The attributes, however, follow the

Problems with product variety
24
physical model. Problems occur when the documents of other disciplines can not be
forced into one single structure, for example if the functional decomposition of a product
family differs from the physical decomposition.
 The second approach is a special case of the previous approach. A number of
representations makes use of the same product model, but not all levels in the product
model are relevant for all representations. The following figure shows that one
representation (for example assembly drawings, represented with black documents) uses
a subset of the physical model. If the node without a black document is a phantom, i.e. a
collection of parts that cannot be put on stock, the node cannot have an assembly
drawing.
Figure 2-3. Subsets of a product model
 The third approach shows a situation in which representations need own models for
storing information. In such a way, models can be fine-tuned to individual purposes. The
problem of this approach, however, is guaranteeing the communication and consistency
between the different product models. This becomes especially apparent in a concurrent
engineering environment where the early availability of constraints imposed by other
views is vital [Anderl, 1992]. The following figure shows the functional, technology and
physical model, each completed with specific documents, which stand for representations
of these models.
Figure 2-4. Different product models and representations
The focus of this thesis lies on the product models of these three domains. It is not tried to
(1) discuss all possible representations and (2) force all representations in one model as was
done in the first and second approach. This thesis agrees with Konda [1992] who states that
the interaction between disciplines creates the problems:
“ Design demands the linkage of disciplines without being a discipline itself. We contend that
design as a body of ‘intellectual tough, analytical, partly formalised, partly empirical, teachable
doctrine’ is but a collection of linkages and any attempt to force it into a single discipline loses
the essence of design. This is because it is impossible a priori even to identify completely which
disciplines are required to be involved for a design problem except through past records of
similar cases and the specifics of the design context. The essential characteristics of design
derives from the multiple and fluid interstices of several and varying disciplines. Hence, it is the

Problems with product variety
25
interactions between agents, human or otherwise, with different ways of looking at the same
problem that creates the problems which theories of design attempt to address. Rendering
design into a single discipline removes this difficulty for the design theorist but not for the
design. ”
The problems that originate from the communication between different disciplines are
discussed in the remainder of this chapter. It is demonstrated that the existence of domains
and the characteristics of a product family add some inherent complexity to the
communication in design and manufacturing. Chapter 3 asserts that the application of more
than one technology in a product family design is the main reason for not rendering the
functional model, the technology model and the physical model into a single model.
The next chapter considers some disciplines and states to which extent they make use of the
functional, technology and physical domain.
2.2 Manufacturing disciplines and domains
Development and manufacturing are collaborative processes, where people from various
disciplines interact to design or produce a product. The need for this interaction is especially
true in a concurrent engineering environment, which is characterised by high quality and
short development and production lead-times
1
. This thesis pursues a product modelling
language and an accompanying design method that make it possible for several disciplines to
share a common framework of the product family being designed. The following disciplines
are referred to in this thesis and therefore introduced briefly:
1. programme and product management;
2. marketing and sales;
3. manufacturing engineering;
4. logistics and goods flow control;
5. purchasing;
6. accounting;
7. service.
Together these disciplines contribute to the engineering and design function. The
engineering and design discipline is regarded as a facilitator in realising the required function
within the constraints of the manufacturing company. These constraints are elaborated in
chapter 2.4 (design problems).
It is not the goal of this chapter to elaborate all problems these disciplines face. The first
objective is to clarify in which domains these disciplines operate. Secondly, the
acknowledgement of the existence of different domains and disciplines eases the
understanding of why communication about product families is difficult.
1
In recent years, much attention has been given to Japanese management practice, which seems to support
concurrent engineering. Hartley [1990], for example, describes how Japanese managers from all disciplines
strive for consensus. After that, everyone is committed and will give their all to the project.

Problems with product variety
26
2.2.1 Programme and product management
A company must continue to invest in new products, particularly for markets with
accelerating rates of product introduction and competitive intensity. Meyer [1993] states
that much current management thought focuses on developing single products as rapidly as
possible. Product development when seen from this perspective has two essential problems:
redundancy of both technical and marketing effort and lack of long-term consistency and
focus.
Concentrating at the level