Modularizing Product Architectures Using Dendrograms

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