| dc.description.abstract | A module is a structurally independent building block of a larger system with well-defined
interfaces. A module is fairly loosely connected to the rest of the system allowing an
independent development of the module as long as the interconnections at the interfaces are
well thought of. [1][2]
The advantages of modularity are possible economies of scale and scope and economies in
parts sourcing [1]. Modularity also provides flexibility that enables product variations and
technology development without changes to the overall design [2]. Same flexibility allows
also for independent development of modules, which is useful in concurrent design or
overlapped product development [3], collaborative projects, or when buying the module from
a supplier [4]. Modularity also eases the management of complex product architectures [2]
and therefore also their development. Modularity can also be used to create product families
[5] [6] [7]. This saves design and testing costs and can allow for greater variation but one
must be aware of possible excess functionality costs if a low cost and low functionality part is
replaced by a higher cost part in order to use the same part in both products [8] [9].
Modularity and product platforms have been shown to be useful [e.g. 6] but there seem to be
few methods to choose the best modules for a product family or joint development platform.
Baldwin and Clark [1] discuss how to modularize but they do not address the problem of
what exactly should be included in a module. Ericsson [2] has developed a modularization
method called Modular Function Deployment (MFD) but it is intended for single products
only, not product families. Also Design Structure Matrix clustering [10] [11] is intended for
single products, but it has an advantage that it has been reduced to a repeatable algorithms that
2
can be run by a computer, which enables the modularizing of also complex systems. Stake
[11] introduces a clustering algorithm for MFD to group functions according to modularity
driver scores. He and Blackenfelt [12] also show how MFD and DSM can be integrated to
combine benefits of the two methods but they are still intended for single products only. Kota
et al. [13] present a benchmark method to compare own platform to competitor’s platform.
The method takes manufacturing, component’s size, and material into account in addition to
functionality, but it is not a platforming tool. Stone et al. [14] discuss heuristics to group
functions in a function structure [for more about function structure see 15] into modules
within a product and Zamirowski and Otto [7] add three additional heuristics to apply across
products in a product family. Dahmus [5] et al. apply the heuristics and introduce a
modularity matrix to help decide what modules should and what should not be shared across a
product family. The weakness of the heuristics is that they are not repeatable since the
functional decomposition and the use of heuristics depend on the user’s point of view. Our
goal is to overcome these weaknesses by introducing a more systematic method for grouping
functions into modules.
Another weakness of the existing methods is that they use nominal or ordinal scales instead of
more rigorous ratio scales. Sosa et al. [16] use ordinal scale (-2,-1,0,1,2) in component DSMs,
Ericsson [2] in MFD, and Stake [11] and Blackenfelt [12] in their combined MFD/DSM
approach. Dahmus [5] as well as Zamirowski and Otto [7] suggest the use of Pugh’s concept
selection that is also based on ordinal scales. Kmenta and Ishii [17] discuss the problem of
performing arithmetic operations on ordinal measures. Stated simply, it produces inconsistent
results. Otto and Wood [18] discuss more broadly the strengths and weakness of these
different type measures. Kurshid and Sahai [19] present a rigorous treatment of these
measures. Ratio scales are most useful because the point zero has meaning, and mathematical
operations such as multiplying and dividing have meaning, e.g., meters/second.
In this paper, we address the weakness of all the above. We use a more flexible flow method
[20] for identifying possible modules in a function structure and our algorithm can be put into
a computer. In addition we develop a genuine metric space with a distance function that is
based on the flow characteristics and we will use a ratio scale.
This algorithm is designed especially for the flow method [20] but it could possibly be used
also in conjunction with other modularization methods. The flow method is based on the
heuristics introduced by Stone et al. [14] and further developed for product families by
Zamirowski and Otto [7]. The difference is that in flow method the focus is on the flows
instead of the functions in a function structure. Functions can even be ignored since often the
end result (outputs) and the requirements needed to achieve it (inputs) are all that matter. The
flow method was designed to identify commonalties between different products. It is more
flexible than the function focused heuristics and can therefore be used also in case of joint
development of a common module for even very different products. It is also applicable in
product family platforming.
The problem we address in this study is how to group functions in a functional
decomposition, such as a function structure, to form a module commonalty hierarchy that can
be used to define common modules across products. The following section will introduce the
grouping algorithm. We will then go on to show an example of this method applied to four
products. We will end the article with our conclusions and suggestions for further study | en |
