See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228581181

Modeling platform-based product configuration using

programmed attributed graph grammars

Article in Journal of Engineering Design · June 2003

DOI: 10.1080/0954482031000091482

CITATIONS READS
26 396

3 authors, including:

Roger Jianxin Jiao

Georgia Institute of Technology
279 PUBLICATIONS 10,496 CITATIONS

SEE PROFILE

All content following this page was uploaded by Mitchell M Tseng on 29 May 2014.

The user has requested enhancement of the downloaded file.

J. ENG. DESIGN, VOL. 14, NO. 2, JUNE 2003, 145–167

Modelling platform-based product configuration using

programmed attributed graph grammars

XUEHONG DU {, JI A N X I N J I AO { *
and MITCHELL M. TSENG §

The rationale of platform-based product configuration has been well recognized

for the implementation of mass customization. A product platform refers to the
conceptual structure and logical organization of product families from both
customer and technical viewpoints. This provides a generic umbrella under which
product configuration manifests itself through variant derivation within common
product line structures. Earlier research often highlights successful yet isolated
empirical studies without attempt to discuss the more general modelling issue
surrounding this economically important class of engineering design problems.
This paper introduces graph grammar formalisms to the representation of a product
platform and the modelling of variant derivation. The concepts of multi-pointed
hyper-graph, node nesting and graph class are developed for modelling platform
modules, multilevel variety origins and generic product instantiation, respectively.
A programmed attributed graph grammar is used to transform customer
requirements in the customer view to product family design in the technical view.
Mapping relationships from the customer view to the technical view are
represented in the form of production rules for graph transformation. The
application conditions of productions in cooperation with control diagrams
determine how a suitable variant can be derived from the base product of the
platform. A case study of power supply platform modelling is also reported.

1. Introduction
Facing the buyers’ market, many industries are now shifting from mass production
to mass customization, which demands quick response to the needs of individual cus-
tomers with high quality and acceptable costs (Pine 1993). Platform-based product
configuration has received an increasing interest in recent years because, by sharing
components across products, a product platform lends itself to the ability to derive
a family of products that are tailored to individual customer needs along with reduced
lead time and costs (Meyer and Lehnerd 1997). The platform performs as a generic
umbrella under which product configuration manifests itself through variant derivation
within common product line structures. Earlier research often highlights successful yet
isolated empirical studies without attempt to discuss the more general modelling issue
surrounding this economically important class of engineering design problem

Revision received January 2003.

{
Artesyn Technologies Asia–Pacific Ltd, 13–15 Shing Wan Road, Tai Wai, Shatin, N.T.,
Hong Kong.
{
School of Mechanical and Production Engineering, Nanyang Technological University,
Nanyang Avenue 50, Singapore 639798, Singapore.
§
Department of Industrial Engineering & Engineering Management, The Hong Kong
University of Science & Technology, Clear Water Bay, Kowloon, Hong Kong.
* To whom correspondence should be addressed. e-mail: mjiao@ntu.edu.sg

Journal of Engineering Design

ISSN 0954-4828 print/ISSN 1466-1387 online # 2003 Taylor & Francis Ltd
http://www.tandf.co.uk/journals
DOI: 10.1080/0954482031000091482
146 X. Du et al.

(Rothwell and Gardiner 1990, McGrath 1995, Sanderson and Uzumeri 1995, McKay
et al. 1996). To realize mass customization, the computerization and, eventually, auto-
mation of platform-based product configuration necessitates the formal representation
of a platform and the modelling of product variant derivation.
Towards this end, the present paper attempts to introduce graph grammar formal-
isms to product platform representation and variant derivation modelling. Owing to its
formality, executability, extensibility and generality in modelling and manipulation of
structural and non-structural information, the graph grammar approach has been
applied as a formal method to facilitate the characterization of design problems more
precisely (Mullins and Rinderle 1991). The generic term ‘graph grammars’ refers to a
variety of mathematical formalisms for specifying sets of graphs through manipulating
symbols representing graph vertices and edges. A graph re-writing system consists of
graphs (or starting graphs) and a set of operations (or productions) that can be applied
to manipulate the graphs. Graphs provide an expressive and versatile data representa-
tion. Typically, nodes represent objects or concepts, and edges represent relations
among them. If a system is modelled as graphs and the production rules for graph
operation are designed properly, as long as users apply the pre-defined productions
to manipulate a graph, then the graph produced will satisfy the characteristics of the
desired system model. All of the graphs that can be derived by applying productions
to the starting graph in certain order from the language of this graph grammar.
In the next section, key issues of platform-based product configuration and techni-
cal challenges of its modelling are discussed. Graph grammar concepts are then related
to platform representation and variant derivation modelling in section 3. Modelling
formalisms are developed in section 4, while in section 5 a case study of a power sup-
ply platform and related product customization is presented to illustrate the feasibility
and potential of graph grammars for platform modelling.

2. Platform-based product configuration

A number of perspectives on product platforms exist in the literature. A review
suggests that the product platform has been defined diversely, ranging from being gen-
eral and abstract (Wheelwright and Sasser 1989, Corso et al. 1996, Robertson and
Ulrich 1998) to being industry and product specific (Sanderson and Uzumeri 1995,
Ericsson et al. 1996, Jandourek 1996). In addition, meaning of the platform differs
in the scope. Some definitions and descriptions focus mainly on the product/artifact
itself (Meyer and Utterback 1993, McGrath 1995), whereas others try to explore the
platform concept in terms of a firm’s value chain (Sawhney 1998).
There are two streams of research prevailing in the field of developing product plat-
forms to support product family development. One perspective refers to a platform as a
physical one, namely a collection of elements shared by several related products.
Accordingly, the major concern is how to identify common denominators for a range
of products (Ulrich and Seering 1990, Ericsson et al. 1996, Jandourek 1996, Wilhelm
1997, Kota and Sethuraman 1998, McAdams et al. 1999). The effort is often geared
towards the extraction of those common product elements, features, and/or subsystems
that are stable and well understood, so as to provide a basis for introducing value-
added differentiating features (Robertson and Ulrich 1998, Moore et al. 1999).
Meyer and Lehnerd’s (1997) work may be the representative of another dominating
perspective to product platforms. They defined a product platform as ‘a set of
 Platform-based product configuration 147

subsystems and interfaces developed to form a common structure from which a stream
of derivative products can be efficiently developed and produced’ (Meyer and Lehnerd
1997, p. 39). The major issue is to exploit the shared logic and cohesive architecture
underlying a product platform. One endeavour towards product platform development
is to design product families in the way of ‘stretching’ and/or ‘scaling’ (Rothwell and
Gardiner 1990). The development of Boeing 7XX aircrafts epitomizes such a design
practice (Sabbagh 1996). The robust design of product families is discussed in Chen
et al. (1996) and Simpson et al. (1996a, 1996b). Simpson et al. (1999) proposed a
product platform concept exploration method to facilitate the synthesis and exploration
of certain common product platform concepts that can be scaled to generate an
appropriate family of products. Siddique et al. (1998) employed graph grammars to
identify the common platform for a set of similar products and to specify possible
product portfolio supported by the platform. To facilitate platform-based product
family development, interface management is reported as a distinct process of defining
the physical interfaces between subsystems (Sundgren 1999). Set-based model is an
attempt to the formal representation of product platform design and manufacturing
processes (Finch 1999).
While prevalent understanding of product platform refers to those shared physical
components (Ulrich 1995), this research emphasizes its architectural implication—the
conceptual structure and overall logical organization of generating a family of pro-
ducts. In other words, a product platform is a structured system creating a variety of
products with shared core product technologies. The common elements may be shared
physical components, customization modules, standard designs, and/or rules for
generating custom designs. Such an architectural perspective in fact manifests the
platform-based product configuration.

2.1. Key issues

2.1.1. Multiple views. Platform-based product configuration involves both the
customer and technical views (Du et al. 2001). From the customer or sales
viewpoint, the platform should reflect information on its capability in the form of
the range of available features and the associated feature levels and/or options for
certain product families derived from the platform. From the technical viewpoint,
the product platform embodies mechanisms of variety fulfillment.

2.1.2. Generic product structure and taxonomy of modules. As the backdrop of a

platform, the Generic Product Structure (GPS) refers to the generic organization of
all modules that may occur in the product families of a platform. Similar to the
generic bill-of-material concept (Hegge and Wortmann 1991), a generic module is
an abstract module representing a family of concrete modules that are similar (i.e.
variants). In general, three types of modules with regard to the origin of variety can
be identified. They are fixed modules, primitive generic modules and compound
generic modules. Figure 1 shows the structure of a generic product, M, representing
all product variants in a family. M0 is a fixed module that is commonly shared by
all products derived from the same platform, and thus is not relevant to any variety.
M2 is a kind of module that has more than one variant but cannot be decomposed
into any generic modules, and thus is called a primitive generic module (Erens and
Verhulst 1997). These primitive variants become the origin of variety as each of
them possesses more than one variant (e.g. {M(2j)}). On the contrary, M1 is a
148 X. Du et al.

compound generic module that is composed of fixed modules, primitive generic

modules, and/or other compound generic products. Its variety results from different
variants of its lower level component modules. As a result, a compound generic
module needs to be decomposed further to facilitate the production of desired
variants (Erens and Verhulst 1997).

2.1.3. Variety generation. To produce custom-built products under certain

customization circumstances, some universal methods for generating variety need to
be identified. Built upon the rationale of uncoupled modular product architecture
(Ulrich 1995), four platform-based variety generation methods can be identified.
More complicated customization can be implemented by nesting these basic
methods recursively (Du et al. 2001).
Attaching. A particular module carrying out certain additional functions can be
attached to a base product to create a new product variant. The attachable
modules should possess appropriate interfaces to the base product. Attaching
appears in many situations (Ulrich and Tung 1991), such as electronic devices
with optional accessories, and computer systems with peripherals, where
optional accessories and peripherals exemplify attachable modules. A variety
of end-products can thus be generated by attaching different attachable modules
to the base product.
Removing. Opposite to attaching, variant products can be derived through
removal of certain modules. In most cases, a module carrying out certain func-
tions that are redundant for a particular customer’s application can be removed to
have a simplified model with cost savings.
Swapping. Swapping frequently appears in practice (Ulrich and Tung 1991). In
fact, it can be regarded as the combination of attaching and removing. Swapping
is mostly related to variety due to different performance levels for the same func-
tion. Usually, substitutable modules should possess common interfaces to the other
parts of the product. In most cases they are the variants of the same module.
Scaling. This refers to the fact that the value of a certain operational parameter of
the product or a module can be changed following some system models or func-
tions. For example, the size of an office chair can be changed and is thus scale-
able. In this context, scaling is related to either the whole product or only a part
of the product. Nevertheless, the fundamental technology and the system struc-
ture remain unchanged. Scaling is consistent with approaches suggested by
Rothwell and Gardiner (1990) and Simpson et al. (1999), in which products are
regarded as scaled objects.

2.1.4. Variant derivation. A platform characterizes the architecture of product

families, thus revealing the organization of product families and the derivation of
product variants (Du et al. 2001). In the sales view, a product family is specified in
terms of functionality, including common features, optional features, and selection
constraints. In the technical view, all product variants share one GPS and are
derived from the base product by manipulating distinctive modules using scaling,
attaching, removing, and/or swapping. Figure 1 illustrates how product variants can
be derived from the base product through the instantiation of GPS according to
given family specifications.
 Platform-based product configuration 149

Figure 1. Product variant derivation through GPS instantiation.

To co-ordinate variety fulfillment across different views, the conditions and

sequences of module manipulation are introduced. The external, internal, and system
conditions should be considered. External conditions come from customer selections
and embody the mapping mechanism from customer requirements to technical solu-
tions. Internal conditions involve constraints such as compatibility, simultaneity, and
capacity constraints (Fujita et al. 1999), as well as coupling/decoupling relationships
between modules. System conditions result from considerations of both design and
manufacturing.

2.2. Technical challenges

In light of the architectural perspective, the modelling of product configuration
includes two aspects: representation of the platform and modelling of the variant deri-
vation process. As a result, the technical challenges can be observed as follows.
(1) It involves the representation of various product-specific data, such as func-
tional features and technical parameters, and hierarchical decomposition
structures, together with relationships of part-to-part and part-to-product.
(2) It also involves the representation of family-related data, such as common
elements and options, variety parameter instantiation, and relationships of
product to product (i.e. variant to family) and family to family.
(3) It should represent the mechanisms of variety generation and variant deriva-
tion, as well as those constraints relevant to the mapping relationship from the
customer to technical views and relevant to configuration compatibility and
precedence.
(4) It should be able to synchronize variety and family representations for both
the customer and technical views.

3. Graph grammars
As a complex system modelling tool, graph grammars excel in describing struc-
tural information and dealing with the transformation and generation of elements in
graph morphisms. With respect to architectural modelling, graph grammar concepts
are summarized as follows.
150 X. Du et al.

3.1. Graph schemes

Definition 1: An unattributed graph (u-graph) is a three-tuple, g ¼ (N , E, l), where (1) N is
a finite set of nodes; (2) E ¼ (Ew )w2W is a tuple of relationships, Ew
N  N , for each
w 2 W ; and (3) l: N ! V is the node labelling function (Bunke 1982, Kreowski and
Rozonberg 1990).
An edge can be directed, in which the graph is a digraph, or be undirected. A pair
(n, n0) is interpreted as a directed edge with label w from node n to n0. A self-loop in a
graph is an edge that starts and ends at the same node. Two sets of attributes are
involved, namely the set A for node attributes and the set B for edge attributes, where
an attribute is a function associating attribute values with nodes or edges.
Definition 2: An attributed graph (a-graph) is a five-tuple g ¼ (N, E, l, a, b), where (1) N,
E, and l are the same as in definition 1; (2) a is a function that associates a set of node
attributes with each node; and (3) b is a function that associates a set of set attributes with
each edge (Bunke 1982, Kreowski and Rozonberg 1990).
Definition 3: A multi-pointed hyper-graph (mh-graph) is a seven-tuple: g ¼ (N , E, l, a,
b, begin, end ), where (1) The first five components are the same as in definition 2; (2)
begin, end 2 N  (i.e., a subset of N); and (3) g is a (k, l)-hypergraph, begin ¼
{b1 , . . . , bi , . . . , bk } and end ¼ {e1 , . . . , ej , . . . , el } with I 2 [1, k], j 2 [1, l]. Then
EXTg ¼ {b1 , . . . , bk } [ {e1 , . . . , el } denotes the set of external nodes for g. All other nodes
are internal ones (Habel and Kreowski 1987).
The mh-graph is originally introduced to explore the generative power of edge
replacement. For example, a state graph of finite automation together with its initial
and final states exhibits an example of mh-graph, where the external nodes of a flow
diagram become its entries and exits. In the context of architectural modelling,
mh-graphs enable the modelling of the hierarchical structure of systems. In addition,
it allows modules of the system to be handled individually.

3.2. Graph manipulation

Definition 4: The direct derivation of a graph G0 from a graph G is an eight-tuple,
<D ¼ (Gl, Gr, Kl, Kr, gl, gr, T ) and is defined by the following procedures (Ehrig 1987,
Kreowski and Rozonberg 1990):
(1) Check whether Gl is a subgraph in G (i.e. g: Gl!G) and check the gluing
condition. If both conditions are fulfilled, go to step 2. The boundary points,
BOUNDARY, are those points in Gl (considered as a subgraph of G) that are
source or target of an edge in G!Gl. The gluing points, GLUING, of Gl are
given by K1. The condition, BOUNDARY  GLUING, is called a gluing
condition, assuring that the context D in step 2 is indeed a graph;
(2) Given gl: Kl!Gl and g: Gl!G, the context graph D is constructed by apply-
ing D ¼ G 7 g[Gl 7 gl(Kl)] to nodes and edges separately. The gluing condi-
tion makes sure that source and target of each arc in D themselves are also
nodes in D. The graph morphisms, d: Kl!D and c: D!G, are defined by
d(x) ¼ g[gl(x)] and c(y) ¼ y for all items x in Kl and y in D; and
(3) T is the set of pairs (kl, kr), kl 2 K1 and kr 2 Kr, which defines the correspond-
ing gluing points. G0 is constructed by gluing of D and Gr at corresponding
points.
Definition 5: Graph derivations are sequences of n  0 direct derivations.
 Platform-based product configuration 151

Definition 6: A gluing is a special case of direct derivation from graph G to G0, where
Gl ¼ Kl and g: Kl!G, D ¼ G. Therefore gluing is a six-tuple: <G ¼ (Gr, K1, Kr, g, gr, T),
where Gr, Kr, gr, and T are the same as in definition 4. A gluing operation is defined by the
following procedure:
(1) Check whether Kl is a subgraph in G (i.e. g: Kl!G) and check the gluing
condition. If both conditions are fulfilled, go to step 2; and
(2) G0 is obtained by gluing of G and Gr at corresponding points.
Definition 7: An attribute calculation production is a three-tuple, <A ¼ (n, attr, f ), where
(1) n 2 N is a node in G whose attribute attr 2 a(n) will be altered; and (2) f is a node
attribute equation.
Definition 8: A production rule is a two 2-tuple, PR ¼ (<, p), where (1) < is manipulation
to be applied to the graph, < 2 {<G, <D, <A}; and (2) p: G!{TRUE, FALSE} is the
applicability predicate.
Compared with the general definition of production as given in Bunke (1982) and
Blostein et al. (1996), three operations defined in definition 4, definition 6, and defini-
tion 7 explicate graph manipulation in the context of architecture modelling. Definition
8 emphasizes the applicability of a manipulation and allows the extension of defined
manipulations. In other words, if other manipulations other than <G, <D, and <A are
needed, they can be easily added to the set <.
The programming of an attributed graph grammar was originally introduced by
Bunke (1977) and is summarized below.
Definition 9: Let P be a finite set of production rules, P
P. A control diagram over P* is
a graph, with the set, P [ {I , F}, as node labels and the set, {Y, N, Either}, as edge labels.
Furthermore these conditions hold true: (1) there exists exactly one initial node nI labelled
with I; (2) there exists exactly one final node nF labelled with F; (3) there exists no edge
terminated with nI; and (4) there exists no edge originated from nF.
An example of the control diagram is shown in figure 2. Except the initial and
final nodes, all nodes are labelled with productions. To apply productions accord-
ing to the control diagram, we start with a production that is labelled as a direct
successor of the initial node and examine its applicability. This can be explained
using Y notations (Göttler 1983). Upon successful application of a production, a
Y-edge in the control diagram is tracked, whereas the tracking of the N-edge is
caused by the failure execution of a production. A derivation sequence stops when
the final node is reached. It may happen that there is a lack of an outgoing Y-edge,
although the production belonging to the actual control diagram node has been
successfully applied. In this case, the continuation of the current derivation
sequence is not defined and no graph will be generated. The analogous situation
arises when the considered production is not applicable and no out-going N-edge

Figure 2. An example of a control diagram.

152 X. Du et al.

exists. If more than one Y-edge/N-edge exists, leaving the same node in the control
diagram, any one can be chosen.
In some cases, certain variants have the same coupling/decoupling relationships as
the other parts of the product. Accordingly, in the control diagram, the productions
manipulating these variants possess the same predecessor and successor nodes; that
is, they are parallel. The pair of p1 and p2 in figure 3a exhibits such a situation.
Whenever the variants possess different coupling/decoupling relationships from the
other parts of the product, the productions manipulating these variants will not be par-
allel in the control diagram (e.g. p1 and p2 in figure 3b). In figure 3, M1 is independent
of any module manipulated through p3. However, M2 depends on that module. Once
M2 is manipulated, p3 has to be performed, if applicable.
Parallel productions are frequently encountered in product configuration, in parti-
cular when the high-level decomposition is involved. To represent this type of produc-
tion concisely, we introduce the concept of alternative production.
Definition 10: pk ¼ [O(Mk), pk] and pl ¼ [O(Ml), pl] are alternate productions, if
(1) M k and M l are variants of a generic module, M, 8 k, l 2 {1, . . . , K}, k 6¼ l;
(2) O(Mk) ¼ O(Ml); and
(3) pk 6¼ pl.
All alternative productions can be represented by a generic production,
P(M) ¼ { pk}. A generic production is defined for a generic module if all operations
of the productions are the same whereas the application conditions are different. In
the control diagram, a generic production is represented as a node with a self-looped
N-edge. Node 1 in figure 4a is labelled p1, which is the generic production
representing all alternative productions manipulating the variants of M1. The applica-
tion of productions according to the control diagram in figure 4a is described in
figure 4b, in which the dashed box highlights how alternative productions are applied.
When the preceding production of a generic production is successfully applied, one
of the alternative productions of this generic production should be executed. If it is
successfully applied, the derivation process will move to its successor node.
Otherwise, the second alternative production will be applied. This process continues
until all alternatives are experienced. In case none of them is applicable (i.e. all the
application conditions of alternative productions are false), the application of this
generic production then fails.

3.3. Graph grammars and graph language

Definition 11: A graph grammar is defined as a seven-tuple: GG ¼ (V, W, A, B, PR, S, CD),
where (1) V and W are alphabets for labelling the nodes and edges, respectively; (2) A and B

Figure 3. Examples of parallel productions.

 Platform-based product configuration 153

Figure 4. An example of alternative production and its application.

are finite sets of attributes for nodes and edges, respectively; (3) PR is a finite set of pro-
duction rules; (4) S is a set of initial graphs; and (5) CD is a finite set of control diagrams.
The distinction between terminal and non-terminal labels for either nodes or edges
is useful for non-programmed grammars, primarily in order to implicitly control the
stop of a derivation sequence. For programmed graph grammars, however, this distinc-
tion is no longer needed since control diagrams and control specifications provide
explicit tools for controlling the order of productions including the stop of a derivation
sequence.
Definition 12: Let GG be a programmed attributed graph grammar. The language of the
graph grammar consists of all a-graphs that can be derived by these steps: (1) start with
an initial graph; (2) apply productions in an order specified by the control diagram; and
(3) stop the derivation sequence when the final node in the control diagram is reached.
In most literature, graphs and productions are referred to as graph grammars no
matter whether a graph language is defined. Nevertheless, the graph language is
important in architectural modelling because it defines the generative power of a graph
grammar and consequently describes the design space that can be generated under the
architecture.

4. Modelling of platform-based product configuration

The relevance of programmed attributed graph grammars to platform representa-
tion is summarized in table 1. Elements of a platform such as feature values, types
of relationships between modules, and design parameters of modules can be character-
ized by the attributes of nodes and edges of a graph carrying structural information
(e.g. how modules are connected). Within a platform, a product must be decomposed
into different levels of abstraction. The concepts of multi-pointed hyper-graph and
node nesting can be introduced for this purpose. At a higher level, each module can
be represented by a node and the associated interfaces. Configuration constraints can
154 X. Du et al.

Entity Product platform Graph grammar

Product model
Product

Feature (feature value)

Module (design parameters)

Relationship (spatial, energy,
information, material)
Product platform model
Common elements

Optional elements

Hierarchical decomposition

Generic product/modules

Variety transformation
from customer view to
technical view
Derivation mechanism
Scaling

Swapping

Attaching

Constraints
Product configuration
Product family

Product variant generation

Sequence of variant
derivation

Diverse customer
selection
Table 1. Relating product platforms to graph grammars.

Graph

Node (attribute)

Node (attribute)

Edge (attribute: type,
label, value)

Starting graph

Multi-pointed
hyper-graph

Node-nesting

Graph class

Production rules

Attribute calculation

Direct derivation

Gluing

Application conditions
of production rules

Graph language

Graph re-writing

Control diagram
(programmed)

Event-driven graph
re-writing (critical path)

be dealt with using the application conditions of production rules. The application
sequence of production rules can be controlled by constructing control diagrams that
capture the complex relationships among modules.

4.1. Product model

4.1.1. Customer view. A product is a three-tuple: P ¼ (F, l, a), where (1) F is a finite
set of product (functional) features; (2) l(Fi) is the context (i.e. name) of feature Fi;
and (3) a(Fi) ¼ {a1, a2, . . . , am} denotes the attributes of feature Fi, where ai for
i 2 [1, m] is the value of the feature attribute, a(Fi).

4.1.2. Technical view. A product is a five-tuple: P ¼ (M, E, l, a, b), where (1) M is a

finite set of nodes representing modules that compose the product; (2) E is a finite set
of edges representing relations between modules. A pair, (Mi, Mj) ¼ Ew 2 E, is
interpreted as a directed edge with label w from node Mi to node Mj; (3) l(Mi) is
the name (i.e. context) of module Mi; (4) a(Mi) ¼ {a1, a2, . . . , am} denotes the
attributes of module Mi. They may be the design parameters of the module; and (5)
b(Ew) indicates the attributes of module Ew . They may be the types of relationships
between Mi and Mj, such as the spatial, energy, information or material interactions
between modules.
 Platform-based product configuration 155

4.2. Product platform model

4.2.1. Customer view. A product platform is a three-tuple: PP ¼ (F G, F O, F V), where
(1) F G is a finite set of given features; (2) F O is a finite set of optional features; and (3)
FV is a finite value set of variable features; that is, a(FiG) ¼ [AttributeID, Range,
Expression], where AttributeID is the identifier of an attribute, Range is the value
range of the attribute, and Expression is the equation calculating the value of the
attribute. It is possible that the values of certain features in F O are variables as
well, which can be denoted as F OV ¼ F O \ F V.

4.2.2. Technical view. A product platform is a five-tuple: PP ¼ (GB, M O, PR, CD)

based on the following.
(1) GB is a base product consisting of modules and their relationships shared
by the products derived from the same product platform. The associated
graph is the starting graph of graph grammars associated with the product
platform. For simplicity we use GB to denote both the starting graph and the
base product.
(2) M O is a set of optional modules. Each module of the product platform can be
represented as a mh-graph. Its external points, begin and end, define the
interface(s) of this module to its context. The attribute of a module is the
function of its design specification.
(3) PR is a set of production rules to be applied to the graphs of the platform.
Three basic variety generation methods (i.e. scaling, swapping, and attaching)
are associated with production rules (<A, p), (<D, p), (<G, p), respectively,
where p defines the applicability conditions for graph manipulation.
Applicability conditions include external, internal and system conditions.
External conditions come from customer selections and embody the mapping
mechanism from customer requirements to technical solutions. Internal con-
ditions involve constraints such as compatibility, simultaneity and capacity
constraints (Fujita et al. 1999). System conditions result from considerations
of design or manufacturing.
(4) CD is a control diagram defining the graph re-writing process; that is, how a
product is derived. The product derivation process is triggered by customers’
selection. Control specifications carry out the task of mapping customers’
requirements to design by executing the right production rules. The sequence
of applying production rules is determined by the couple, decouple and nest-
ing relationships among associated modules. Such a process can be modelled
as a control diagram.

4.3. Representation of modules

Those modules sharing the same external interfaces and performing the same func-
tion belong to a family. Selection of different variants may result in varied performance
of that particular function. Their associated graphs thus possess the same external
nodes and the same function entity. The graphs possessing such kind of properties can
be defined as a graph class. In this sense, the graphs of family members comprise a
graph class.
A compound module can be regarded as a variant generated from a platform. For
example, M1 in figure 1 is regarded as a platform, consisting of fixed module M10, as
156 X. Du et al.

its base product, and generic module M11, as well as the relevant production
rules. While compound generic modules are determined by their functions and sub-
modules, primitive generic modules are characterized by their variants and design
parameters. This implies a tree-like, hierarchical product structure with fixed modules
or primitive generic modules as leaves and compound generic modules as intermedi-
ary nodes. Such a phenomenon reveals the concept of node nesting in graph
formalisms.

4.4. Product variant derivation

The process of deriving a variant from the product platform can be modelled as the
process of re-writing the base graph, B, according to certain production rules. Once a
customer enters a set of selections, the longest applicable path will be triggered, which
means that all of the applicability conditions of production rules along the path take on
a TRUE value. Once the left-hand side of a production rule becomes a variant of a
secondary variable module, the re-writing process will be executed along the control
diagram of this module. As soon as a particular modular variant is generated, the pro-
duction rules of its parent’s diagram will be applied.
The hierarchical structure of products can be regarded as a collection of
compound modules organized at various levels of abstraction. The derivation of
variants thus becomes a recursive process of generating the variants of all compound
modules. Figure 5 illustrates such a recursive process. Each row corresponds to a
decomposition level of GPS. Each diagram in a dashed box indicates a path in the
control diagram for a compound module. While dark-coloured nodes are productions
used to manipulate compound nodes, light-coloured nodes are productions used to
manipulate primitive nodes. The derivation sequence can be traced along the dashed
arrows.

Figure 5. Variant derivation through multiple level graph re-writing.

 Platform-based product configuration 157

5. Case study
A switching mode power supply platform, called FB65-T, is adopted in this case
study. The structure of switching-mode power supplies is depicted in figure 6. The
characteristics of the FB65-T platform include universal input, triple output, 65 W nor-
mal output power, and flyback converter. Based on market research, four categories of
most required customization are identified: the value of output voltages, the accuracy
of output voltage, the output protection scheme, and auto-recovery (AuR). The port-
folio of the FB65-T platform is planned as follows.

(1) Base product: þ5 V, 12 V, normal output accuracy, and short-circuit (SC)
protection.
(2) The variety of output voltage is achieved using the scaling method, where the
secondary turns are calculated according to certain equations.
(3) The variety of output accuracy is fulfilled using the swapping method. Either
multiple-output sensing or single-output sensing can be selected as the feed-
back circuit in accordance with the accuracy level specified by customers.
(4) As for the protection scheme, two points have to be highlighted. At a higher
level of decomposition, the protection circuit is a module that is relatively
independent of other parts of the system. However, the module itself can
be further decomposed into SC protection, over-voltage (OV) protection and
compensation submodules. In power supply realization, a protection module
may consist of the compensation submodule and any one or two of the
protection submodules.
(5) If the AuR feature is desired, a shut-down-on-overcurrent start-up circuit is
required to replace the boot-strap circuit.

Figure 7 gives the graphical representation of all modules and module classes in
platform FB65-T. GB is the base product of FB65-T. G2, G6, and G8 are the primitive
generic modules. G7 is a compound generic module. The variety of module G7 comes
from different combinations of G7.1 and G7.2 with respect to G7.3—the starting
graph (base product) of platform M7. Table 2 presents the algebraic representation
of a specific variant of switching power supplies.
The production rules defined for FB65-T are presented in table 3. Production rules
can also be expressed in graphical form. Figure 8 shows the left-hand and right-hand

Figure 6. Structure of switching power supplies.

158 X. Du et al.

Figure 7. Representation of modules for the FB65-T platform.

sides of production rules PR2 and PR3. Figure 9 gives the Y notation of PR2. The
Y notation is also called a production graph, where the lower-left, lower-right and
upper corners are noted as Gl, Gr and Gc, respectively. The Gc in fact is the
context graph of the production rule. Edges across the branches of Y are embedding
transformations.
Figure 10 shows the control diagrams of platform FB65-T and its nested
platform M7. The control diagram of a platform defines the graph language of this plat-
form (i.e. all possible product variants generated from the platform). For instance,
there are three paths in the control diagram of M7. Therefore, three protection schemes
can be derived by applying PR4 and PR5 to the base product G7.3 in accordance with
the control diagram given by figure 10b.
The process of variant derivation follows the following steps: (1) let customers
enter their selections; (2) identify the longest applicable path in the control diagram
of FB65-T, noted as PATHFB65T ; (3) among all production rules along the
PATHFB65T , PR3 is associated with a compound module M7 that results in further
decomposition into primitive modules (such a situation indicates node nesting in graph
operations; therefore, the control diagram of M7 is invoked and its longest path is
identified, noted as PATHM7 ); and (4) executing production from node I to node F
along the PATHFB65T and PATHM7 . Then the required product variant can be
 Platform-based product configuration 159

Product: {universal input, 65 W; triple output, þ5 V, 12 V; normal output,

accuracy; short circuit protection, RFI}
Customer view: P ¼ (F, k, a); F ¼ {F1, F2, F3, F4, F5, F6}
l(F1) ¼ power-rate a(F1) ¼ {value, unit} ¼ {65 W}
l(F2) ¼ output-voltage-of-output 1 a(F2) ¼ {value, unit} ¼ {þ5 V}
l(F3) ¼ output-voltage-of-output 2 and 3 a(F3) ¼ {value, unit} ¼ {12 V}
l(F4) ¼ outputs-accuracy a(F4) ¼ {accuracy level} ¼ {normal}
l(F5) ¼ short a(F5) ¼ {protection-scheme}
¼ {short-circuit}
l(F6) ¼ RFI a(F6) ¼ {VDE safety}
Technical view: P ¼ (M, E, k, a, b); M ¼ {M1, M2, M3, M4, M5, M6, M7, M8, M9}
l(M1) ¼ input-rectifier b(Mi, Mj) ¼ {type of interaction}
l(M2) ¼ transformer b(1, 2) ¼ energy
l(M3) ¼ output-rectifier b(2, 3) ¼ energy
l(M4) ¼ switch b(2, 4) ¼ energy
l(M5) ¼ controller b(4, 2) ¼ energy
l(M6) ¼ feedback b(1, 8) ¼ energy
l(M7) ¼ protection b(9, 1) ¼ energy
l(M8) ¼ start-up b(8, 5) ¼ energy
l(M9) ¼ RFI b(3, 6) ¼ b(6, 5) ¼ b(5, 4)
¼ b(7, 5) ¼ b(3, 7) ¼ signal
a(M1) ¼ {Trec, type number of rectifier; C, filtering capacitor}
¼ {1N540X, 0.1 mF}
a(M2) ¼ {Tcor, core type number; Npri, number of turns of primary winding; Nsec,
number of turns of secondary winding}
¼ {F-43515-EC-02, 67, 3}
a(M3) ¼ {Trec, type number of rectifier; C, value of filtering capacitor}
¼ {P/N MBR340, 15 mF @ 10 V)
a(M4) ¼ {Tswi, type number of switch}
¼ {MTP4N50E}
a(M5) ¼ {Tcon, type number of controller}
¼ {UC3843P}
a(M6) ¼ {type of feedback}
¼ {single-sensing}
a(M7) ¼ {protection 1, . . . , protection k}
¼ {short-circuit}
a(M8) ¼ {boot strap; Vins, local input voltage; Vous, local output voltage}
¼ {385 V, 12 V}
a(M9) ¼ {(Lc, Cc), common mode choke; Lc, mode choke}
¼ {(900 mH, 0.18 mF), 318 mH)
Table 2. Algebraic description of a switching power supply variant.
RFI, radio-frequency interference; VDE, Verband Deutscher Elektrotechniker (a German
organization that tests equipment for public safety and emitted noise.)

obtained. Figure 11 illustrates the variant derivation process of protection module in

the graphical form.
The multilevelled control diagram is particular useful for product platforms with
node nesting. For example, considering constraints on SC and Au-R, a total of 20
paths can be identified from the FB65-T control diagram as shown in figure 10a.
Accordingly, table 4 presents all possible product variants of the FB65-T platform
along with their derivation mechanisms (in the form of PRs). Similarly, following the
 160

Number Left-hand Right-hand Operation Application Description

side side condition
PR1 Nil Nil <A ja(F2)j 6¼ 12 Value change of output voltage
PR2 G6(1) G6(2) <D a(F4) ¼ high Output accuracy changes from normal
to high
X. Du et al.

PR3 ; G7 <G Nil Add protection circuits

PR4 ; G7.1 <G a(F5) 2 {{SC}, {SC, OV}} Add short-circuit protection
PR5 ; G7.2 <G a(F5) 2 {{OV}, {SC, OV}} Add over-voltage protection
PR6 G8(1) G8(2) <D a(F5) 2 {{SC}, {SC, OV}} Add auto-recovery feature
Table 3. Production rules defined for the FB65-T platform.
 Platform-based product configuration 161

Figure 8. The left-hand and right-hand sides of PR2 and PR3.

Figure 9. Production definition for swapping between M6(1) and M6(2).

control diagram given in figure 10a and applying PR1, PR2, PR3 or PR6 consecu-
tively, a family of switching power supplies can be obtained. All variants in the family
possess common features such as 65 W, universal input, and triple outputs, and yet
meet specific requirements on output voltages, output accuracy, protection schemes
and auto-recovery.
The product platform of switching power supplies consists of given features,
optional features, variable feature values, the base product, optional modules,
production rules and control diagrams. The options include changing values of output
voltage, levels of output accuracy, protection schemes and the feature of auto-recovery
after failure. In the customer view, product variety is defined in terms of these
functional options. Then productions are applied to covert the functional specifications
to variant derivation in the technical view. The platform defined in the case study can
generate totally 20 members of the FB65-T family. The algebraic representation of
FB65-T platform is presented in table 5.
162 X. Du et al.

Figure 10. Control diagrams for the FB65-T platform.

6. Discussion
Based on programmed attributed graph grammars, this paper develops a formal
representation of the platform and related variant derivation. The preliminary results
indicate that some of the characteristics of graph grammars closely map to product
platform characteristics. A graph grammar can be used to transform customer require-
ments to the design of product variants of a family. The product platform is presented
in two views (i.e. the customer and technical views). In addition to those given func-
tional features, optional features and variable feature values comprise the basis for
customer selection (i.e. customization) and thus achieve variety in the customer view.
The mapping of customer requirements from the customer view to the technical view
manifests itself through defining application conditions for production rules, which, in
cooperation with control diagrams, determine how a suitable variant is derived from
the base product of the platform. Graph grammars also provide a means to describe
the design space of a product platform by the graph language.
In this research, variety fulfillment is approached between the customer view and
the technical view, rather than between the function view and the structure view as
done by Siddique and Rosen (1999) and Schmiddt and Cagan (1997). The rationale
lies in that product platform representation focuses more on the organization of data
and knowledge than on the platform development process; that is, how a product

Figure 11. Variety generation for protection scheme.

 Platform-based product configuration 163

Variant Description* Derivation mechanism**

PR4 PR3
#1 a(F3) ¼ 12 V; normal; SC G7:3 ! G7(1) , GB ! GP1
PR4 PR1,PR3
#2 a(F3) 6¼ 12 V; normal; SC G7:3 ! G7(1) , GB ! GP2
PR4 PR2,PR3
#3 a(F3) ¼ 12 V; high; SC G7:3 ! G7(1) , GB ! GP3
PR4 PR1,PR2,PR3
#4 a(F3) 6¼ 12 V; high; SC G7:3 ! G7(1) , GB ! GP4
PR4 PR3,PR6
#5 a(F3) ¼ 12 V; normal; SC; AuR G7:3 ! G7(1) , GB ! GP5
PR4 PR1,PR3,PR6
#6 a(F3) 6¼ 12 V; normal; SC; AuR G7:3 ! G7(1) , GB ! GP6
PR4 PR2,PR3,PR6
#7 a(F3) ¼ 12 V; high; SC; AuR G7:3 ! G7(1) , GB ! GP7
PR4 PR1,PR2,PR3,PR6
#8 a(F3) 6¼ 12 V; high; SC; AuR G7:3 ! G7(1) , GB ! GP8
PR5 PR3
#9 a(F3) ¼ 12 V; normal; OV G7:3 ! G7(2) , GB ! GP9
PR5 PR1,PR3
#10 a(F3) 6¼ 12 V; normal; OV G7:3 ! G7(2) , GB ! GP10
PR5 PR2,PR3
#11 a(F3) ¼ 12 V; high; OV G7:3 ! G7(2) , GB ! GP11
PR5 PR1,PR2,PR3
#12 a(F3) 6¼ 12 V; high; OV G7:3 ! G7(2) , GB ! GP12
PR4,PR5 PR3,PR6
#13 a(F3) ¼ 12 V; normal; G7:3 ! G7(3) , GB ! GP13
SC and OV; AuR
PR4,PR5
#14 a(F3) 6¼ 12 V; normal; G7:3 ! G7(3) ,
SC and OV; AuR PR1,PR3,PR6
GB ! GP14
PR4,PR5
#15 a(F3) ¼ 12 V; high; G7:3 ! G7(3) ,
SC and OV; AuR PR2,PR3,PR6
GB ! GP15
PR4,PR5
#16 a(F3) 6¼ 12 V; high; G7:3 ! G7(3) ,
SC and OV; AuR PR1,PR2,PR3,PR6
GB ! GP16
PR4,PR5
#17 a(F3) ¼ 12 V; normal; G7:3 ! G7(3) ,
SC and OV; AuR PR3,PR6
GB ! GP17
PR4,PR5
#18 a(F3) 6¼ 12 V; normal; G7:3 ! G7(3) ,
SC and OV; AuR PR1,PR3,PR6
GB ! GP18
PR4,PR5
#19 a(F3) ¼ 12 V; high; G7:3 ! G7(3) ,
SC and OV; AuR PR2,PR3,PR6
GB ! GP19
PR4,PR5
#20 a(F3) 6¼ 12 V; high; G7:3 ! G7(3) ,
SC and OV; AuR PR1,PR2,PR3,PR6
GB ! GP20

Table 4. Product variants of the FB65-T platform.

* Common features are not listed, including 65 W universal input, triple output,
þ5 V output, RFI, and so on.
** GPi (i ¼ 1, . . . , 20) denotes the graph for product variant #i.
164 X. Du et al.

Product platform:
Given: {universal input; triple output; þ5 V; 65 W; RFI}
Options: {12/12  (1 þ 15%); normal output accuracy/high output accuracy;
short circuit protection/over-voltage protection/auto-recovery}
Customer view: PP ¼ (FG, FO, FV)
F G ¼ {F1, F2, F7} a(F3) 2 [12, 12  (1 þ 15%)]
F O ¼ {F5, F6} a(F4) 2 {normal, high}
FV ¼ {F3, F4} a(F5)  {SC, OV}
a(F6) 2 {Yes, No}
Technical view: PP ¼ (B, MO, PR, CD, CS)
MO ¼ {m2, m6, m7, m8, m7.1, m7.2, m7.3}
m2: attri.fun ¼ transformer, b ¼ {1, 4}, e ¼ {4};
m6: attri.fun ¼ feedback, b ¼ {3}, e ¼ {5};
m6(i) 2 m6, i ¼ 1,2;
m7: attri.fun ¼ protection, b ¼ {3}, e ¼ {5};
m7(i) 2 m7, i ¼ 1,2,3;
m8: attri.fun ¼ start-up, b ¼ {1}, e ¼ {5};
m8(i) 2 m8, i ¼ 1,2;
m7.1: attri.fun ¼ SC, b ¼ {3}, e ¼ {7.3};
m7.2: attri.fun ¼ OV, b ¼ {3}, e ¼ {7.3};
m7.3: attri.fun ¼ compensation, b ¼ {3}, e ¼ {5}
PR ¼ {PR1, PR2, . . . , PR7}
PR1 ¼ (<A (M2, Nsec, f ), p), Nsec ¼ f [a(F3)],
p ¼ True, iff ja(F2)j 6¼ 12;
PR2 ¼ [<D (m6(1), m6(2), {3, 5}, {30, 50}, gl, gr, (3, 30), (5, 50)), p],
p ¼ True, iff a(F4) ¼ high;
PR3 ¼ [<G (m7, {3, 5}, {30, 50}, gl, gr, (3, 30), (5, 50)), p],
p ¼ True;
PR4 ¼ [<G (m7.1, {3, 7.3}, {30, 7.30}, gl, gr, (3, 30), (7.3, 7.30)), p],
p ¼ True, iff a(F5) 2 {{SC},{SC, OV}};
PR5 ¼ [<G (m7.2, {3, 7.3}, {30, 7.30}, gl, gr, (3, 30), (7.3, 7.30)), p],
p ¼ True, iff a(F5) 2 {{OV}, {SC, OV}};
PR6 ¼ [<D (m8(1), m8(2), {1, 5}, {10, 50}, gl, gr, (1, 10), (5, 50)), p],
p ¼ True, iff a(F5) 2 {{SC},{SC, OV}}.
Table 5. Algebraic description of the FB65-T platform.

platform is obtained. This coincides with the fact that one of the important instruments
of mass customization is to re-use previous knowledge. In such a situation, once rela-
tionships between customer requirements and technical design are identified, as long
as the design can be parsed, there is no need to follow the general design process to
construct the functional structure.
In addition, this research addresses the coordination of the customer and technical
views by designing the applicability of production rules, instead of by transformations
between graphs representing the functional and physical structures. This is because,
inherently, product features are non-structural. They are simply a list of customer
requirements, in which functional structures seldom exist. Furthermore, this research
uses the term ‘technical view’ rather than ‘structural view’, or ‘behaviour (physical)
view’. In practice, it is possible that the technical view means either the structure view
or the physical view, depending upon the characteristics of products and the design
strategy of the platform. For example, for electronics products, the technical view
 Platform-based product configuration 165

involves nothing but resistances, capacitances, ICs, and so on. The working principle
of a product is determined by the connection of these components (i.e. the circuitry
topology of the product). Then, the product platform focuses on the structure view.
On the other hand, for mechanical products, the physical structure is much significant
for functionality. Then, the physical view becomes the focus of the platform.
It is also realized that most product platforms are much more complex than the exam-
ple presented in this research. Also, the application of graph grammars is far from being
well exploited. Future work is geared towards developing platform-based product
configuration systems. One promising application may be the integration of object-
oriented methods with graph grammars (Blostein et al. 1996, Jones 1995). Combining
advantages of encapsulation, inheritance, and polymorphism, the graph grammar-based
system will be more concise and powerful to deal with complex design problems.

7. Conclusions
Recognizing the rationale of platform-based product configuration with respect to
mass customization, this paper tackles the formal modelling issue of product platform.
The graph grammar approach excels in architectural modelling. Graph grammars
make explicit the structural elements of the platform, such as general product struc-
tures, common/shared elements, and variant derivation mechanisms. Complex
family-based product configuration can be modelled as graph transformations through
node nesting and executing productions, which facilitates computational approaches to
variety design. Graph grammars also provide a means to describe the design space of
product platform using graph languages.

Acknowledgements
This research was partially supported by Artesyn Technologies Asia–Pacific Ltd.
Under grant CPI 95/96.EG01, the HKUST Research Infrastructure Grant (RI 93/94
EG08), and the Hong Kong Research Grant Council (HKUST 797/96E and
HKUST 6220/99E). The authors would like to express their sincere thanks to
Dr M. Eugene Merchant, Prof. Stephen C.-Y. Lu, Num P. Suh, Gunnar Sohlenius
and Martin Helander for their valuable advice. One of the anonymous reviewers is
thanked for the insightful comments.

References
BLOSTEIN, D., FAHMY, H. and GRBAVEC, A., 1996, Issues in the practical use of graph rewriting, In
Graph Grammars and Their Application to Computer Science, Lecture Notes in Computer
Science (Berlin: Springer-Verlag), 1073, pp. 38–55.
BUNKE, H., 1977, Programmed graph grammars, Lecture Notes in Computer Science, 56, 155–166.
BUNKE, H., 1982, Attributed programmed graph grammars and their application to schematic
diagram interpretation, IEEE Transactions on Pattern Analysis and Machine Intelligence,
PAMI-4, 574–582.
CHEN, W., SIMPSON, T. W., ALLEN, J. K. and MISTREE, F., 1996, Use of design capability indices to
satisfy a ranged set of design requirements, In Advances in Design Automation, edited by
D. Dutta (Irvine, CA: ASME), 96-DETC/DAC-1090.
CORSO, M., MUFFATTO, M. and VERGANTI, R., 1996, Multi-product innovation: emerging policies in
automotive, motorcycle and earth-moving machinery industries, 3rd International Product
Development Management Conference on New Approaches to Development and Engineering,
Fontainebleau, France.
166 X. Du et al.

DU, X., JIAO, J. and TSENG, M. M., 2001, Architecture of product family: fundamentals and
methodology, Concurrent Engineering: Research and Application, 9, 309–325.
EHRIG, H., 1987, Tutorial introduction to the algebraic approach of graph-grammars, In H. Ehrig,
M. Nagl, G. Rozenberg and A. Rosen (editors), Graph Grammars and Their Application to
Computer Science, Lecture Notes in Computer Science (Berlin: Springer-Verlag), 291, 3–14.
ERENS, F. and VERHULST, K., 1997, Architectures for product families, Computers in Industry, 33,
165–178.
ERICSSON, J., KARLSSON, P.-O., MERCER, G. and ROBERTSON, D., 1996, Sharing parts across car
models: lessons from the manufacturers, Europe’s Automotive Components Business, 1st
Quarter, 150–171.
FINCH, W. W., 1999, Set-based models of product platform design and manufacturing
processes, Proceedings of DETC99: 1999 ASME Design Engineering Technical
Conferences, Las Vegas, NV.
FUJITA, K., SAKAGUCHI, H. and AKAGI, S., 1999, Product variety deployment and its optimization
under modular architecture & module commonalization, In Proceedings of 1999 ASME
Design Engineering Technical Conferences, DETC99/DFM-8923, Las Vegas, NV, 12–15
September.
GÖTTLER, H., 1983, Attributed graph grammars for graphics, In H. Ehrig, M. Nagl and G.
Rozenberg (editors), Graph Grammars and Their Application to Computer Science, Lecture
Notes in Computer Science (Berlin: Springer-Verlag), 153, 130–142.
HABEL, A. and KREOWSKI, H., 1987, May we introduce you to: Hyperedge replacement, In H. Ehrig,
M. Nagl, G. Rozenberg and A. Rosen Graph Grammars and Their Application to Computer
Science (Berlin: Springer-Verlag), 291, 15–26.
HEGGE, H. M. H. and WORTMANN, J. C., 1991, Generic bill-of-material: a new product model,
International Journal of Production Economics, 23, 117–128.
JANDOUREK, E., 1996, A model for platform development, Hewlett-Packard Journal, Article 6.
JONES, C. V., 1995, Developments in graph-based modeling for decision support, Decision Support
Systems, 13, 61–74.
KOTA, S. and SETHURAMAN, K., 1998, Managing variety in product families through design
for commonality, In 1998 ASME Design Engineering Technical Conferences, DETC98/
DTM-5651, Atlanta, GA.
KREOWSKI, H.-J. and ROZONBERG, G., 1990, On structured graph grammars, Information Sciences,
52, 185–210.
MCADAMS, D. A., STONE, R. B. and WOOD, K. L., 1999, Understanding product similarity using
customer needs, In 1999 ASME Design Engineering Technical Conferences, DETC99/
DTM-5660, Las Vegas, NV.
MCGRATH, M., 1995, Product Strategy for High-Technology Companies (New York: Irwin
Professional Publishing).
MCKAY, A., ERENS, F. and BLOOR, M. S., 1996, Relating product definition and product variety,
Research in Engineering Design, 8, 63–80.
MEYER, M. H. and LEHNERD, A. P., 1997, The Power of Product Platforms: Building Value and Cost
Leadership (New York: The Free Press).
MEYER, M. and UTTERBACK, J., 1993, The product family and the dynamics of core capability, Sloan
Management Review, 34, 29–47.
MOORE, W. L., LOUVIERE, J. J. and VERMA, R., 1999, Using conjoint analysis to help design product
platforms, Journal of Product Innovation Management, 16, 27–39.
MULLINS, S. and RINDERLE, J. R., 1991, Grammatical approaches to engineering design, part I: an
introduction and commentary, Research in Engineering Design, 2, 121–135.
PINE, B. J., 1993, Mass Customization: The New Frontier in Business Competition (Boston,
MA: Harvard Business School Press).
ROBERTSON, D. and ULRICH, K., 1998, Planning for product platforms, Sloan Management Review,
39, 19–31.
ROTHWELL, R. and GARDINER, P., 1990, Robustness and product design families, In Design
Management: A Handbook of Issues and Methods, edited by M. Oakley (Cambridge,
MA: Basil Blackwell), pp. 279–292.
SABBAGH, K., 1996, Twenty-First Century Jet: The Making and Marketing of Boeing 777 (New York:
Scribner).
 Platform-based product configuration 167

SANDERSON, S. and UZUMERI, M., 1995, Managing product families: the case of the Sony walkman,
Research Policy, 24, 761–782.
SAWHNEY, M. S., 1998, Leveraged high-variety strategies: from portfolio thinking to platform
thinking, Journal of the Academy of Marketing Science, 26, 54–61.
SCHMIDT, L. and CAGAN, J., 1997, GGREADA: a graph grammar-based machine design algorithm,
Research in Engineering Design, 9, 195–213.
SIDDIQUE, Z., ROSEN, D. W. and WANG, N., 1998, On the applicability of product variety design
concepts to automotive platform commonality, Proceedings of 1998 ASME Design
Engineering Technical Conferences, 98-DETC/DTM-5661, Atlanta, GA, 13–16 September.
SIDDIQUE, Z. and ROSON, D. W., 1999, Product platform design: a graph grammar approach,
Proceedings of 1999 ASME Design Engineering Technical Conferences, DETC99/
DTM-8762, Las Vegas, NV.
SIMPSON, T. W., CHEN, W., ALLEN, J. K. and MISTREE, F., 1996a, Conceptual design of a family of
products through the use of the robust concept exploration method, 6th AIAA/USAF/NASA/
ISSMO Symposium on Multidisciplinary Analysis and Optimization, AIAA-96-4161-CP
(Bellevue, WA: AIAA), Vol. 2, pp. 1535–1545.
SIMPSON, T. W., ROSEN, D., ALLEN, J. K. and MISTREE, F., 1996b, Metrics for assessing design
freedom and information certainty in the early stages of design, Proceedings of 1996 ASME
Design Engineering Technical Conferences, 96-DETC/DTM-1521 (Irvine, CA: ASME).
SIMPSON, T. W., MAIER, J. R. A. and MISTREE, F., 1999, A product platform concept exploration
method for product family design, Proceedings of 1999 ASME Design Engineering Technical
Conferences, DETC99/DTM-8761, Las Vegas, NV.
SUNDGREN, N., 1999, Introducing interface management in product family development, Journal of
Production Innovation Management, 16, 40–51.
ULRICH, K., 1995, The role of product architecture in the manufacturing firm, Research Policy,
24, 419–440.
ULRICH, K. T. and SEERING, W. P., 1990, Function sharing in mechanical design, Design Studies,
11, 223–234.
ULRICH, K. and TUNG, K., 1991, Fundamentals of product modularity, Issues in Design
Manufacturing/Integration, 39, 73–77.
WHEELWRIGHT, S. C. and SASSER, W. E., Jr., 1989, The new product development map, Harvard
Business Review, 67.
WILHELM, B., 1997, Platform and modular concepts at Volkswagen—their effects on the assembly
process, In Transforming Automobile Assembly, edited by K. Shimokawa, U. Jürgens and
T. Fujimoto (Berlin/Heidelberg: Springer-Verlag).

View publication stats