2016-12-09T13:43:20ZPlatform Architecture A Two-Level Optimization Approachhttp://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
2002-10-03T00:00:00ZArchitecting Option Contenthttp://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.
2000-01-01T00:00:00ZModularization to Support Multiple Brand Platformshttp://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.
2001-09-09T00:00:00ZModularizing Product Architectures Using Dendrogramshttp://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
2003-01-01T00:00:00Z