Model Based Systems Engineering in Construction Kit Development – Two Case Studies

Abstract

To offer a large variety of end products with a limited number of components, more and more companies take advantage of the modular design, platform and type series principles resulting in a construction kit development. These standardization methods make the product development processes more complex. This can be encountered with the help of Model Based Systems Engineering (MBSE). In order to support construction kit development with the help of MBSE in a long term, definitions of such terms as module, platform, type series and construction kit are analyzed and defined in the context of MBSE. As a result, some implications of these definitions are presented in this paper. In addition, first findings out of two research studies conducted at an automotive manufacturer are presented and put into the context of MBSE. The studies indicate the potential of MBSE supporting construction kit development.

Full text

Available online at www.sciencedirect.com
Procedia CIRP 00 (2014) 000–000
www.elsevier.com/locate/procedia
2212-8271 © 2014 The Authors. Published by Elsevier B.V.
Selection and peer-review under responsibility of the International Scientific Committee of “24th CIRP Design Conference” in the person of the Conference
Chairs Giovanni Moroni and Tullio Tolio.
24th CIRP Design Conference
Model Based Systems Engineering in Construction Kit Development –
Two Case Studies
Albert Albersa, Helmut Scherera, Nikola Bursaca*, Galina Rachenkovaa
aIPEK – Institute of Product Engineering,at Karlsruhe Institute of Technology (KIT),
Kaiserstr. 10, 76131 Karlsruhe, Germany
* Corresponding author. Tel.: +49 721 608 46472; fax: +49 721 608 46051. E-mail address: Nikola.Bursac@kit.edu
Abstract
To offer a large variety of end products with a limited number of components, more and more companies take advantage of the modular design,
platform and type series principles resulting in a construction kit development. These standardization methods make the product development
processes more complex. This can be encountered with the help of Model Based Systems Engineering (MBSE). In order to support
construction kit development with the help of MBSE in a long term, definitions of such terms as module, platform, type series and construction
kit are analyzed and defined in the context of MBSE. As a result, some implications of these definitions are presented in this paper. In addition,
first findings out of two research studies conducted at Dr. Ing. h.c. F. Porsche AG are presented and put into the context of MBSE. The studies
indicate the potential of MBSE supporting construction kit development.
© 2014 The Authors. Published by Elsevier B.V.
Selection and peer-review under responsibility of the International Scientific Committee of “24th CIRP Design Conference” in the person of
the Conference Chairs Giovanni Moroni and Tullio Tolio.
"Keywords: Modular Design; MBSE; Systems Engineering; SysML"
1. Introduction
The immense diversity of creatures, art, human beings and
man-made products in our universe is based on merely few
basic components: electrons, protons and neutrons. The same
principle can be applied in the development of technical
systems. To meet increasing product individualization, more
and more manufacturers develop their products according to
construction kit principles: the desired variety of an end
product should be based on a limited number of elements.
Product costs are, thus, reduced by means of scale effects.
However, construction kit development becomes increasingly
complex, since separate products share the same modules [1,
2]. Thereby, interrelationships between products arise while
developing a module. Additionally, the requirements for a
module for different products are not always sufficiently
known throughout their development, since these products are
developed at different times. The complexity of construction
kit development can be mastered with the Model Based
Systems Engineering (MBSE) approach.
2. State of the Art
In this chapter, MBSE and subsequently the construction
kit development are introduced. Central definitions related to
construction kit development are analyzed based on the
existing literature and adapted for the application in MBSE.
2.1. Model Based Systems Engineering
MBSE is based on a system-theoretical model
understanding, in which a technical product can be regarded
as a system, which on the one hand is a component of a
superior system and on the other hand can be divided into
subsystems [3]. Thus, an approach which is valid at the
system level can likewise be applied on a subsystem level.
This phenomenon can be called the fractal character of
Systems Engineering [4].
With MBSE interdisciplinary development teams can
consistently and continuously capture and manage the

2 Author name / Procedia CIRP 00 (2014) 000–000
occurring data throughout the product development in
computer-based product models [5], instead of usually
working with a large number of documents. To build these
product models, Systems Modeling Language (SysML) can
be purposefully used in the development of the modular-built
products from the early stages of product development until
series production [6]. In particular, SysML supports
requirements engineering, function development as well as
systematic derivation of validating activities. Since the
knowledge about modules is captured by means of bundling
of product data in SysML models, their interactions and
uncertainties in the development are thus more transparent
[7].
However, the current research in the area of systems
engineering reveals lacking acceptance of MBSE in industrial
applications [8]. One possible explanation for this is that
models have a high degree of abstraction and appear to be too
abstract for practical applications. In addition, modeling
usually requires a lot of effort, since most of the time models
have to be created newly from scratch. To avoid this and to
create product models in a more efficient way, information
from previous generations of products should be used [9]. For
this purpose, the approach originally designated for process
modeling [10] has been transferred to product modeling. This
way, a modeling framework, which is presented in figure 1,
was derived in order to support the developers at different
degrees of abstraction throughout the product modeling [11].
Fig. 1. Degrees of abstraction in product modeling [11]
With the help of this approach product models can be
inductively derived based on real products. In the context of
product generation development, individual innovations are
developed throughout generations, in which the core structure
remains the same, which can be described as a reference
product model. Thus, project-specific product models can be
deductively derived out of the reference product models.
Additionally, several views at different degrees of abstraction
are applicable: generic (by means of multidisciplinary),
domain-specific (e.g. a specific industrial sector, area of
activity or product design type) and system-specific (with
focus on a specific product), which has to be developed. The
system-specific and domain-specific level can be further
specified depending on the purpose of the product model [11].
This framework hasn’t been regarded in the context of the
development of modular products so far.
2.2. Definitions related to construction kit development
In this section some key terms in construction kit
development are compiled from different authors and are then
applied to definitions in the context of MBSE. These
definitions are meant to be applied to the interdisciplinary
development of technical systems.
In order to determine the existing design type of a technical
system, the system’s architecture and the architecture of its
neighboring systems as well as its subsystems have to be
analyzed. Here, product architecture of a system is defined as
the functional and physical structure as well as their cross-
linkage [12, 13].
First of all, the term module has to be defined, which
according to LINDEMANN and MAURER designates functional
and logical units, which are completely exchangeable between
each other (similar definitions can be found in [14, 15]). The
module‘s relatedness with other design types (platform or
type series design types) are emphasized, since a module is a
foundation for other design types [16]. Many authors point
out the significant role of the interfaces between modules: one
characteristic feature of modules is that they have very few
interfaces [17, 18 1]. Those interfaces are required for
exchangeability of modules and thus should be clearly defined
and unified. Other authors define modules as subsystems with
functional and physical independency, while their boundaries
are specified by manufacturing and functional aspects [19, 20,
21, 22].
In the context of MBSE the following definition is
suggested by the authors for modular design: a system is of
modular design if its main functionality can be modified by
replacing one of the subsystems with a different subsystem.
Thus, a module is a subsystem which can easily be replaced
by a different one. Special cases of such substitutions are
addition or exclusion of a subsystem. As a result, modules are
suitable for the application within a single product or
throughout a product range.
The exchangeability of modules is a direct consequence of
pursuing a larger external product variety while reducing
internal systems variety within an organization as a goal in
product development. As a result of the required
exchangeability, modules possess functional and physical
independence as well as only few standardized interfaces.
A product built according to the platform design type
consists of a version-neutral product platform and product
specific extensions [23] (similar to [24]). Thus, a product
platform can be paraphrased as the “greatest common
denominator” of a product family [25]. It is also described as
an interface carrier [25, 26], especially if it contains a
standardized carrier structure [16, 27]. Furthermore, other
authors define a platform as a set of systems and interfaces,
which build a common structure, from which product variants
can be derived [28, 18] (similar to [2]).
All subsystems that are not located in the platform are
combined into the so-called “hat” section [16, 27], which is
also designated as the varying share in a platform-based
product [1].
In the context of MBSE a system is built according to the
platform design type when its subsystems can be

Author name / Procedia CIRP 00 (2014) 000–000 3
differentiated into the platform and the hat section. Thereby, a
platform includes all subsystems that are used in several,
different systems. In this way, a platform is a collection of
repeatedly used yet unchanged subsystems. These subsystems
do not necessarily have to be directly connected to each other
in the system’s product architecture. However, since this is
often the case, a platform is often referred to in literature as an
interface carrier. The hat section covers the remaining
subsystems, which differ from system to system. Different hat
sections have the same kind of interfaces connecting them to
the platform section. They don’t necessarily need to have any
further similarities.
A type series, according to PAHL and BEITZ, can be defined
as follows: it is a technical construct (machine, assemblies
and individual parts), which fulfill the same function using the
same technical solution and (if possible) manufacturing
scheme, yet in different size fractions for a wide application
area [25] (similar definitions in [2], [16], [29], [30]). Thus,
application of similarity laws here is compulsory. The product
architecture of all the members within one type series is
similar despite the scaling effects.
The definition of a type series within MBSE is very similar
to the rather consistent existing definitions: A type series
denotes several technical systems, which have similar product
architectures and whose dimensions, power outputs etc. can
be varied (under consideration of similarity laws) by scaling
of certain parameters.
The term “construction kit” is defined by KOLLER as
follows: A construction kit consists of components
(assemblies or parts) of identical or differing functionality and
build, which can be differently combined into more complex
systems with different functionality and build [31] (similar to
[25, 16, 32]). In other sources a construction kit is described
as a reservoir of elements [33] or as an organizing principle
which contains a collection of standardized units [34].
Additionally, a construction kit provides a set of rules, which
allows for the configuration of a system out of the elements
[32].
The following definition of construction kits is proposed
for the context of MBSE: A construction kit is an abstract
construct, which contains all those subsystems, with which
various systems can be configured. Most importantly, a
construction kit comprises a set of rules which dictate the
product subsystems’ architecture (especially their interfaces),
which in turn ensures compatibility of these subsystems.
Within construction kit development, subsystems are
developed and combined into finished products. In addition,
the construction kit rule set is developed and adherence of it is
supervised. Very often, a construction kit development
implies the development of modular systems. In this case,
especially in the industrial context, the term modular
construction kit is used. This indicates that such construction
kit contains modules for the most part.
3. Methodology
Based on the state of the art, the MBSE approach is used in
this paper for construction kit development. Therefore, the
following research question has to be answered:
How can the framework be used to support the research of
construction kit development using SysML as an example?
Hence, at first some implications of the above mentioned
definitions are discussed and afterwards two case studies are
presented. The studies were carried out in cooperation with
the automotive manufacturer Dr. Ing. h.c. F. Porsche AG: one
study depicts the complete modular product in early
development stages and the other portrays the series
development of a single module. Both the complete car and
the single module development examples are suitable
examples for this study, since they are developed throughout
several product generations and thus comply with the
approach of product generation development [9]. Different
stages in the development process are used to investigate
different depths of detail and the possibility of a continuous
applicability of the models.
4. Results
In order to support the development of modular products
using the above mentioned framework, the domain level is
defined as the construction kit level and the system level as
the product level (see fig. 2). Thus, different products can be
mapped to the construction kit. Reference models describe the
construction kit structure (2) or product structure (6). In the
following it will be presented with the help of the two
research studies how the MBSE-approach can contribute to
overcoming of challenges in the construction kit development.
Fig. 2. Application of the framework in construction kit development
Based on the definitions presented in chapter 2, a fractal
description of design types is made possible. This is
demonstrated using the modeling framework. Furthermore, it
is shown in two research studies how SysML models can
practically support construction kit development.
4.1. Implications on design types in the context of MBSE
If the definitions presented in chapter 2.2 are considered in
the context of system levels within systems engineering (see
chapter 2.1), the following observation can be made: The
identification of the design type (modular, platform, or type
series design) of a system is only dependent on the properties
of its subsystems. A system can be described, for instance, as
modular when its subsystems are modules. Determining the
platform design type works the same way: Here, as soon as
the subsystems can be divided into the platform- and hat

4 Author name / Procedia CIRP 00 (2014) 000–000
sections, the system is of the platform design type. To sum it
up, in order to determine the design type of a system, the
following relationships have to be analyzed: system -
subsystem and subsystem - subsystem. However, at that point
no conclusions can be made about the internal structure of a
subsystem (which is in turn dependent on its sub-subsystems).
The subsystems themselves can therefore be designed with
either the modular, platform or type series design type,
regardless of the considered system. Thus, it is possible to
come across any combination of the mentioned design types
at different system levels of a product. This characteristic is
described as the fractal character of the design types.
Implications are illustrated in figure 3 with an example. A
product (7 in figure 2) is developed based on a construction
kit (3) which has a reference structure (2). This construction
kit reference model contains all relevant construction kit rules.
Fig. 3. Fractal character of design types
When regarding the product on the “system” level, one
might notice that some of its subsystems are exchangeable
(here: subsystems α-1 & γ-4 by α-2, respectively by γ-5 & γ-
6). According to the above mentioned definition these
subsystems can be regarded as modules. All other subsystems,
which are not exchangeable, are not referred to as modules (in
this example β-3 & δ-7). After analyzing the sub-subsystems
of, for instance, subsystem γ-4, one might discover that they
can be classified into platform and hat section, which
constitute the subsystem γ-4 built according to the platform
design type.
Analysis of literature reveals single aspects of the fractal
character of design types. However, a holistic description
using system levels of MBSE hasn’t been published yet.
HOFFMANN and VIETOR, for instance, describe the internal
structure of a module containing a basic section
(unchangeable) and a variable section (differing from module
to module) [27]. In addition, SCHUH describes a platform (i.e.
subsystem) that consists of modules (i.e. subsubsystems),
which are then referred to as base modules [24]. Other
literature examples implicitly indicate the fractal character of
the system design implying that a module can at the same
time be a member of a type series. KIESER and BLESSING
introduce such example, in which an electric motor type series
can be combined with different other powertrain modules in
order to configure different drive systems for hybrid and
electric vehicles [35]. AL GEDDAWY and ELMARAGHY
describe a similar case and use the term “scalable modularity”
whenever modules are scalable [36].
Beyond that, a construction kit is presented in figure 3,
which contains various subsystems. These subsystems are part
of the construction kit because their product architectures
follow the construction rules. Thus, it is permissible that the
construction kit contains not only modules but also non-
modules, as long as they are designed according to the
construction kit rules.
Furthermore, figure 3 demonstrates that a product can be
built by combining construction kit subsystems (α-1, β-3 &
γ-4) and subsystems not belonging to the construction kit (δ-
7). Hence, if the construction kit is completely described, all
products built out of this construction kit are fully described
as well.
The construction kit rules as well as compliance with them
are of a great importance: the construction kit can be extended
any time by adding new subsystems, as long as they follow
the construction kit rules. Moreover, construction kit
subsystems, which are initially applied in only one product,
can later be used for the configuration of new products, since
their compatibility is ensured by the construction kit rules.
4.2. Early stages of the complete vehicle development
In this case study early stages of vehicle development are
examined. Since vehicle development pursues the product
generation development approach, it likewise possesses a
reference model (6 in fig. 2). Based on an analysis in the early
stages of the product development there were various
document-centered reference product models identified: a
component-based product structure, a characteristics
catalogue, a technical system of objectives and a functions’
catalogue. These documents were transferred into a single
reference product model (6) based on SysML (1/5). The
content of the construction kit models can be understood as
aggregation of the system models. Thus, caused by the variety
within a construction kit, parameters which are single values
in the system’s model (e.g. the system’s weight) are
transferred to a band width from a minimum to a maximum
value in the construction kit model. Hereby, a construction kit
model can show the user, in which different products a single
module is at use as well as what different modules are used to
build a single product. This way a common understanding of
the construction kit conception can be facilitated with the
involved developers (3).
A dependency matrix is one of the ways of visualizing
dependency criteria in the SysML tool MagicDraw, which has
been used in this case study. It provides two kinds of
perspectives on the same information. This can be easily
explained in an example. Figure 4 shows the unfolded and
folded view of the MSB (Modular standard construction kit)-
based vehicles in the columns. There are arrow symbols in the
cells representing the dependencies between vehicles and
different kinds of engines. On the one hand, individual
dependencies can be seen and managed so it is immediately
apparent what engines are assigned to which vehicles in the
unfolded state. On the other hand, the number of usages of a
particular engine and other relationships of this engine can be
seen in the folded state. The given example includes elements

Author name / Procedia CIRP 00 (2014) 000–000 5
of the reference model (6) and particular vehicles (7); contents
of other technical documents are structured and linked in the
matrix in a similar manner.
Fig. 4. Reference and project-specific product models
As a functionality of SysML, user specific views of the
models can be generated, which are adapted for the
developer’s field of expertise and responsibility. These views
can be generated of the entire construction kit model as well
as of single product models. This way it is visualized which
components are assigned to which products, which of those
requirements have an influence on its directly related parts.
4.3. Series development of drivetrain components
The second case study contains initial important findings
regarding the application of SysML models in series
development. In the course of this investigation, modular
drivetrain components are regarded as systems, which are
modeled alongside their subsystems. An analysis has shown
that prior to introduction of SysML models the following
product models have been in use:
 CAD systems for the depiction of the system’s physical
structure
 Tools for Requirements Engineering
 Tools for Simulation and Computation
The SysML product model adds a functional architecture
of a product to these different model types. The functional
architecture model supports developers particularly in
recognizing complex interactions between different modules.
The modeling method of ZINGEL [37] is used for the creation
of the model and has been adapted to the specific needs of the
developers. The C&C² approach [38, 39] is used to model the
linkage between the functional and the physical architecture
within the models.
Fig. 5. SysML models of drive train modules
In figure 5 the results of this case study are reflected with
the help of the modeling framework, which is shown in figure
2. With the enhanced modeling technique of ZINGEL at hand,
a meta model (1) is created with which a SysML user can
build the actual product models (7), construction kit models
(3) and their respective reference models (6, respectively 2).
A meta model was used to create the product model (7) of a
real module (8). The initial creation of the functional and
physical architecture has already been completed, and all
major functions are implemented.
This model is currently being validated in an empirical
study in the area of the development of drive train modules.
Feedback from developers about the use of the SysML models
is recorded by means of interviews and questionnaires, while
the model is being permanently extended with minor
subfunctions.
If, as expected, the experience of the currently ongoing
series development is integrated into the model it will result in
a product reference model (6). This reference model can then
be used as a database for knowledge management in
upcoming product generations. Moreover, starting with the
product model (7), the construction kit model (3) can be
derived by enriching the product model with additional
construction kit data. This way all modules of the entire
drivetrain construction kit can be modeled. Based on the
construction kit model (3), a modular reference model (2) can
be derived which captures all the lessons learned during
construction kit development and makes them available for
future developments.
5. Conclusion and Outlook
To conclude, the research results presented in this paper
show some potential of SysML’s ability to support the
construction kit development. With the help of the reference
models in the first case study, products can be modeled more
efficiently, since existing models of subsystems out of the
construction kits can be attached to the reference product
models. Furthermore specific views of the construction kit as
well as of individual products are made possible. The second
case study shows that a comprehensive overview over hardly
recognizable interactions can be visualized, especially
between separate products using the same modules. This way
modeled product functions in SysML help developers to
understand the system’s structure and behavior.
At the same time, the findings of this paper provide
numerous references which indicate future and worthwhile
areas of research. Some essential investigations of the second
case study have already been completed (e.g. the initial
modeling). Further empirical studies are currently being
carried out. Outcomes of these investigations should shed
light on the capability of the SysML models to be extended by
a higher degree of model detail. Furthermore valuable data is
collected for an evaluation of efforts (creation and handling of
models) and benefits (knowledge gain and data bank for
knowledge management) of such models.
In another research project of the authors that goes beyond
the scope of this paper will apply the presented modeling
framework in the area of Requirements Engineering for

6 Author name / Procedia CIRP 00 (2014) 000–000
construction kits. Another worthwhile research area appears
to be the investigation of embedding SysML models into the
already existing tool chain of product development: If the
SysML models could e.g. be coupled with existing 3D
engineering design software, the effort for modeling the
physical structure of a system could be greatly reduced. To
sum it up, every single step ahead in MBSE research projects
can lead to helpful and well-integrated supports in future
construction kit developments.
References
[1] Wallentowitz H, Freialdenhoven A, Olschewski I. Strategien in der
Automobilindustrie. Wiesbaden: Vieweg + Teubner; 2009.
[2] Piller FT, Mass Customization - Ein wettbewerbsstrategisches Konzept im
Informationszeitalter. Deutscher Universitätsverlag Wiesbaden. 2.
Auflage; 2006.
[3] Ropohl G. Allgemeine Technologie - Eine Systemtheorie der Technik. 3rd
edition. Karlsruhe: Universitätsverlag Karlsruhe; 2009.
[4] Albers A, Braun A, Muschik S. Uniqueness and the Multiple Fractal
Character of Product Engineering Processes. In: Heisig, P, Clarkson, PJ,
Vajna S, editors. Modelling and Management of Engineering Processes.
London: Springer; 2010. p. 14-26.
[5] Gausemeier J, Dumitrescu R, Steffen D, Czaja A, Wiederkehr O,
Tschirner C. Systems Engineering: in der industriellen Praxis. Paderborn;
2013.
[6] Object Management Group (OMG). OMG Systems Modeling Language
(OMG SysML), Specification of Version 1.3; 2012.
[7] Lohmeyer Q. Human-centered modeling of product developement
systems in consideration of the synthesis and analysis of dynamic systems
of objectives. In: IPEK–Forschungsberichte 59; 2013.
[8] Albers A, Zingel C. Challenges of Model-Based Systems Engineering: A
Study towards Unified Term Understanding and the State of Usage of
SysML. In: Smart Product Engineering: Proceedings of the 23rd CIRP
Design Conference. Springer; 2013.
[9] Albers A, Bursac N, Urbanec J; Lüdcke R, Rachenkova G. Knowledge
Management in Product Generation Development. In: Beiträge zum 25.
DfX-Symposium; 2014. p. 13-24.
[10] Albers A, Muschik S. The role and application of activities in the
integrated product engineering model. In: Proceedings of international
Design Conference; 2010.
[11] Albers A, Matthiesen S, Bursac N; Moeser G, Schmidt S, Lüdcke R.
Abstraktionsgrade der Systemmodellierung – von der Sprache zur
Anwendung. In: Proceedings of the TdSE; 2014.
[12] Cornet A. Plattformkonzepte in der Automobilindustrie. Wiesbaden:
Deutscher Universitätsverlag, 2002.
[13] Ulrich K. The role of product architecture in the manufacturing firm. In:
Research Policy 24; 1995. p. 410-440.
[14] Ponn J, Lindemann U. Konzeptentwicklung und Gestaltung technischer
Produkte : Optimierte Produkte - Systematisch von Anforderungen zu
Konzepten. 1. Aufl. Heidelberg: Springer; 2008.
[15] Renner I. Methodische Unterstützung funktionsorientierter
Baukastenentwicklung am Beispiel Automobil. Dissertation Techniche
Universität München; 2007.
[16] Lindemann U, Maurer M. Entwicklung und Strukturplanung
individualisierter Produkte. In: Lindemann U, Reichwald R, Zäh M,
editors. Individualisierte Produkte: Komplexität beherrschen in
Entwicklung und Produktion. Berlin: Springer; 2006. p. 41–62.
[17] Koppenhagen F. Systematische Ableitung modularer
Produktarchitekturen. Dissertation Technische Universität Hamburg-
Harburg Aachen. Shaker Verlag; 2004.
[18] Blees C. Eine Methode zur Entwicklung modularer Produktfamilien.
Dissertation Technische Universität Hamburg-Harburg; 2011.
[19] Feldhusen J, Gebhardt B, Baumgart I. Modularisierung von Produkten
im Anlagenbau. Dissertation Rheinisch-Westfälische Technische
Hochschule Aachen, 2004.
[20] Sedchaicharn K. A computer-aided method for defining the product
architecture with consideration of function and geometry. Disstertation
Karlsruher Institut für Technologie, Karlsruhe; 2010.
[21] Göpfert J. Modulare Produktentwicklung. Zur gemeinsamen Gestaltung
von Technik und Organisation. Wiesbaden: Gabler; 1999.
[22] Lasch R, Gießmann M. Qualitäts- und Komplexitätsmanagement:
Parallelitäten und Interaktionen zweier Managementdisziplinen. In:
Hünerberg R, Mann A, editors. Ganzheitliche Unternehmensführung in
dynamischen Märkten; 2009. p. 93–124.
[23] Haf H. Plattformbildung als Strategie zur Kostensenkung. VDI Berichte
1645; 2001. p. 121–137.
[24] Schuh G. Produktkomplexität managen. München: Hanser Verlag; 2005.
[25] Pahl G, Beitz W, Feldhusen J, Grote KH. Konstruktionslehre. Berlin
Heidelberg: Springer; 2007.
[26] Feldhusen J, Gebhardt B. Product Lifecycle Management für die Praxis:
Ein Leitfaden zur modularen Einführung, Umsetzung und Anwendung. 1.
Aufl. Berlin, Heidelberg: Springer-Verlag Berlin Heidelberg; 2008.
[27] Hoffmann CA, Vietor T. Erklärungsmodell der modularen
Baukastensystematik in der Automobilindustrie. In: Konstruktion; 2014.
[28] Meyer MH, Lehnerd AP. The Power of Product Platforms: Building
Value and Cost Leadership. New York: The Free Press; 1997.
[29] Ehrlenspiel K, Kiewert A, Lindemann U, Mörtl M. Kostengünstig
Entwickeln und Konstruieren: Kostenmanagement bei der integrierten
Produktentwicklung. 6. Aufl. Heidelberg; 2007.
[30] Feldhusen J, Orloff M. Grundlagen technischer Systeme und des
methodischen Vorgehens. In: Grote KH, Feldhusen J, editors. Dubbel:
Taschenbuch für den Maschinenbau. 23. Aufl. Heidelberg: Springer;
2012. p. F1-F38.
[31] Koller R. Konstruktionslehre für den Maschinenbau. Berlin: Springer;
1994.
[32] Alt O. Modellbasierte Systementwicklung mit SysML. München: Carl
Hanser Verlag; 2012.
[33] Nasvytis A. Die Gesetzmäßigkeiten kombinatorischer Technik. Berlin:
Springer; 1953.
[34] Borowski KH. Das Baukastensystem in der Technik. Berlin: Springer;
1961.
[35] Kieser J, Blessing U. From Concept to Democar – the GETRAG
BOSCH Hybrid Cooperation. Getrag Drivetrain Forum.
Untergruppenbach; 2010.
[36] AlGeddawy T, ElMaraghy H. Reactive design methodology for product
family platforms, modularity and parts integration. CIRP Journal of
Manufacturing Science and Technology 6; 2013, p. 34-43.
[37] Zingel JC. Basis definition of a common language of product
engineering in the context of modeling of technical systems and a
modeling technique for the systems of objectives and objects of technical
systems on the basis of the ZHO-principle. In: IPEK Forschungsberichte.
Karlsruhe, 2013.
[38] Matthiesen S. A contribution to the basis definition of the element model
“Working Surface Pairs & Channel and Support Structures” about the
correlation between layout and function of technical systems. In: IPEK
Forschungsberichte, Band 6. Karlsruhe; 2002.
[39] Albers A, Sadowski E. The Contact and Channel Approach (C&C2-A):
Relatinga system’s physical structure to its functionality. In: An
Anthology of Theories and Models of Design. Blessing LTM, Chakrabarti
A, editors. Heidelberg: Springer; 2013.