http://hdl.handle.net/1721.1/3770 Sun, 19 May 2013 10:24:10 GMT 2013-05-19T10:24:10Z http://dspace.mit.edu:80/bitstream/id/3545/CIPDlogo_forDspace.gif http://hdl.handle.net/1721.1/3770 http://hdl.handle.net/1721.1/3958 Platform Architecture A Two-Level Optimization Approach de Weck, Olivier; Suh, Eun Suk Introduction to Platform Architecture in Products VW Golf 2 -Automotive Platforming Example:A Two-Level Optimization Approach 3 -Discussion Thu, 03 Oct 2002 04:00:00 GMT http://hdl.handle.net/1721.1/3958 2002-10-03T04:00:00Z http://hdl.handle.net/1721.1/3811 Architecting Option Content Otto, Kevin This paper presents an approach to determine the proper number of levels required on independent product architectural attributes, given their ability to generate added revenue through more direct targeting to smaller segments, and given the added costs of doing so. This is done in as simple and readily implementable manner as possible, making use only of conjoint data and cost estimates. From this, the order in which to consider added breakouts across the different attributes are prioritized. From this, for any minimum level of profit worth considering, a set of attribute levels to offer on each architectural attribute can be selected. Then, for any selected set of attribute levels to offer, the most effective product family using those levels is determined from the permutations. Sat, 01 Jan 2000 05:00:00 GMT http://hdl.handle.net/1721.1/3811 2000-01-01T05:00:00Z http://hdl.handle.net/1721.1/3810 Modularization to Support Multiple Brand Platforms Agus, Sudjianto; Otto, Kevin Methods to determine acceptable architecture for multiple platforms supporting multiple brands must represent both platform cost saving commonization as well as revenue enhancing brand distinctions. Functional architecting methods determine modularization based upon functional concerns. Brand identity is additionally determined by sensory aesthetics. We introduce three architecting rules to maintain brand identity in platforms. A dominant theme must be ensured on each product of a brand, and this must be transferred to each product's specifications and aesthetics. Elements critical to brand identity must be made common across all products in a brand. For any platform, brand specific elements must be maintained unique on each product variant. The set of elements not identified as a brand carrier can be made common to a platform. A matrix representation of each platform and its supported brand variants is useful as an architecting tool. Sun, 09 Sep 2001 04:00:00 GMT http://hdl.handle.net/1721.1/3810 2001-09-09T04:00:00Z http://hdl.handle.net/1721.1/3809 Modularizing Product Architectures Using Dendrograms Hölttä, Katja; Tang, Victor; Seering, Warren 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 Wed, 01 Jan 2003 05:00:00 GMT http://hdl.handle.net/1721.1/3809 2003-01-01T05:00:00Z