INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN

ICED 03 STOCKHOLM, AUGUST 19-21, 2003

NEW GUIDELINE VDI 2206 – A FLEXIBLE PROCEDURE MODEL FOR

THE DESIGN OF MECHATRONIC SYSTEMS

Jürgen Gausemeier and Stefan Moehringer

Abstract
Mechatronics - the synergetic integration of different engineering domains such as mechanics,
electronics and information technology can create new products and stimulate innovative
solutions. In order to yield this potential, experts from the involved domains need a
mechatronic-specific guideline for the systematic design of mechatronic systems. In industry
guidelines are unfortunately not accepted in the intended way; adaptability to the present
design situation is missed. The contribution presents a flexible procedure model taking the
specific needs of mechatronic design into account and offering elements for individual
adaptation. The procedure model is part of the new guideline VDI 2206.

Keywords: Adaptive Design, Design Methodology, Design Process, Integrated Product

Development, Mechatronics

1. Introduction
Innovative products demand the synergetic integration of different engineering domains such
as mechanics, electronics and information technology; this is expressed by the term of
mechatronics. For the systematic design of mechatronic products the design engineer in
practice need a guideline to select the suitable procedures, methods and tools for his/her
individual design task.
Surveys show however that guidelines are often not accepted and used by industry in the way
they are expected. Practicians claim that the proposed procedures are too rigid, often phase-
oriented and cannot be adapted to the individual design situation. The results of the empirical
design research confirm that there is no "optimal form of the design process the design
engineer can follow according to a fixed flowchart“ [1]. Successful design processes are
individually influenced and can vary strongly from a general pattern like the guideline VDI
2221 [2], [3]. Therefore new research approaches try to provide procedures and methods in a
flexible and situation-specific way, e.g. [4], [5].
The design of mechatronic systems differs from the design of products which are mainly
coined by one engineering domain: Mechatronic systems are especially complex due to the
great number of connected elements. These elements are realized furthermore in different
engineering domains (heterogeneity). In order to manage complexity and heterogeneity the
methods of modelling and model analysis – among others – are very important. They need to
be integrated in design procedures for mechatronic systems. Existing guidelines like the VDI
2221 or VDI 2422 [6] do not fulfil the special requirements of mechatronics in a sufficient
way. The wide spectrum of mechatronic-specific research and industrial developments of the
last decade is not yet considered in these guidelines.

1
Two main questions are raised:
• How should a guideline look like offering methodical support in a flexible and situation-
specific way and being accepted and used by industry?
• What are the specific requirements of mechatronics to the design? How should procedure
models by designed to meet these requirements?
Facing these questions the committee of the Association of German Engineers (VDI) has
worked out a new guideline, the VDI 2206 „Design Methodology for Mechatronic Systems“
[7]. The following objectives are in the foreground:
• Supporting the design of mechatronic systems by integrating mechatronic-specific
procedures, methods and tools and by structuring the variety of findings in the
mechatronic field.
• Proposing a flexible procedure model which can be adapted to the individual design task.
• Complementing existing guidelines, especially the VDI 2221 and VDI 2422; latest
findings of design research should be integrated.
This contribution explains the main elements of the procedure model of the VDI 2206 and
exemplifies its practical application.

2. Specific Requirements to the Design of Mechatronic Systems

Before introducing the procedure model the requirements of mechatronics to its design will be
pointed out. These requirements can be grouped into two categories: 1) impacts of complexity
and 2) impacts of heterogeneity.

2.1 Impacts of Complexity

Mechatronic systems are characterised by high complexity due to the cross-linkage of
different engineering domains. The complexity is caused by the increasing number of
connected elements. Mechatronics does not only improve behavior, precision or the cost-
value ratio of known solution principles. It especially creates new functions: Active
suspension and electronic stability features in the automotive industry or fly-by-wire in
aeronautics are only possible thanks to the permanent interaction of mechanical, electronic
and software elements. Therefore complexity is a necessary accompaniment in mechatronics
and leads to four requirements:
1. Procedure with changing level of detail and abstraction: During the design process the
designing engineers need the reciprocal action between the overall context and the detail
focus. Because of the cross-linkage to other elements new detail solutions and findings have
to be checked permanently in the overall context as well.
2. Methods of structuring and hierarchisation: Mechatronic systems should be structured
in order to reduce complexity and to minimise interactions, e.g. the hierarchical structure in
basic elements, systems and linked systems [8].
3. Early modelling and simulation: Interactions between sub-systems, e.g. coupling of
engine management and brake system for the electronic stability program (ESP), can only be
anticipated by the early modelling and simulation of the system behavior. Suited methods and
software tools are necessary.

2
4. Integration and verification/validation of properties: The design results have to be
integrated to an overall system and to be checked continuously by means of the specified
solution concept and the requirements. It is to be assured that the actual system characteristics
match with those wanted. Hardware-in-the-Loop (HIL) plays an important role to analyse real
and virtual components in a common environment.

2.2 Impacts of Heterogeneity

Solutions and components are coming from different engineering domains such as mechanics,
electronics and information technology. These involved domains are working on the basis of
established, specific design methods, their own ways of thinking, nomenclatures and
experiences. The integration of heterogeneous components to mechatronic systems is a big
challenge expressed by four requirements:
1. Cross-domain collaboration in teams: Communication and co-operation between the
involved disciplines is required to bring together synergetic knowledge and to design an
entirely optimised solution.
2. Cross-domain specification: Experts from different disciplines need a common method to
specify the results of product conceptualisation in a cross-domain way [9].
3. Partitioning: The partitioning, i.e. the distribution into working principles/solution
elements of the involved domains and their assignment to functions, is an important step.
Especially the heterogeneous partitioning needs methodical support.
4. Exchange/integration of models: The design results – modelled by the domains with
different model languages and tools – need to be integrated. Procedures e.g. MechaSTEP [10]
and new languages e.g. Modelica [11] are necessary.

3. A Flexible Procedure Model for the Design of Mechatronic

Systems
These requirements lead to a specific procedure model for the design of mechatronic systems.
It is characterised by two levels of design support and elements for adaptation to individual
design tasks.

3.1 Design Support on the Micro-Level and Macro-Level

The design process distinguishes between the problem solving process of the individual
designer (micro-level) and the generic process related to design phases and corresponding
product states (macro-level). The micro-level supports the designer in an action-oriented way:
alternation between systematic and associative ways of proceeding, reacting in unforeseen
situations, structuring design sub-tasks etc. The macro-level helps to survey the total design
process: setting mile-stones, planning and controlling the design progress etc.

Micro-level
The presented cycle of problem solving on the micro-level (cf. figure 1) comes from systems
engineering. Its basic validity for the planning and realisation of problem solving processes
was confirmed from the point of view of psychology [12]. The cycle of problem solving
comprises the following steps:
Situation analysis and/or take-over of target: A basic cycle starts either with the situation
analysis or the take over of the target: An externally pre-set target can be taken over by the

3
acting group and/or the individual; the situation analysis will follow (proceeding oriented to
the target condition). Otherwise a first unclear situation will be analysed and the target will be
formulated respectively (proceeding oriented to the actual condition).

a
a

Figure 1. Cycle of problem solving on the micro-level [13]

Analysis and synthesis: It is the aim to search for solutions for the given problem and to
elaborate alternative solution variants. This process represents in practice a permanent
interaction of synthesis and analysis steps which the design engineers carry out - partly
conscious, partly unconscious as well. During the solution search additional aspects of the
problem can be recognized that might require a return to the situation analysis and target
formulation or the consideration of supplementary criteria.
Analysis and evaluation: The solution variants are subject of a detailed evaluation phase. If
certain solution ideas differ too strongly to be compared appropriately, a return to the phase of
solution search should be considered. The evaluation of the solution variants is done on the
basis of the evaluation criteria defined within the target formulation and solution search. The
result consists of a proposition for one or several solution alternatives.
Decision: It must be found out whether the previous process of the problem solution has led
to a satisfactory result. If that is not the case, one must return to the situation analysis and
target formulation. Otherwise one, maybe also several solution alternatives are chosen and
represent the basis for the further planning.
Planning of the further proceeding resp. learning: The further procedure leads in many
cases more or less continuously to further cycles of problem solutions and thus to an efficient,
situation-adapted process. Beside the evaluation of the design result the process itself should
be analysed critically as well. By understanding the positive and negative impacts on the

4
process, knowledge for coming design tasks can be generated. This helps to improve future
design processes in a systematic way.

Macro-level
The v-shaped model is well-established in the domain of software engineering [14]. There are
three reasons why it seemed to be suited for mechatronics:
1. The v-shaped model illustrates the top-down-approach (system design: dividing into sub-
functions) and the bottom-up-approach (system integration: integrating of results to the
overall system) in an obvious way.
2. It allows to point out the need of permanent verification/validation between the
requirements/specified functions (left hand side) and the actual (virtual and/or real) system
(right hand side).
3. It is already used by the industry in the context of mechatronics which helps to increase
the acceptance of the guideline.
Therefore the v-shaped model was chosen and has been adapted to mechatronic needs. It
describes the generic procedure for the design of mechatronic systems which has to be
specified according to the individual design task (figure 2).
requirements product

ion
grat
sys

inte
te

verification/validation
md

tem
esig

sys
n

domain-specific design
mechanical engineering
electronic engineering
information technology

modelling and model analysis

Figure 2. V-shaped model on the macro-level

Requirements: Starting point is an individual design task. The task has been clarified/defined
and described with the help of requirements. These requirements represent at the same time
the measure for the evaluation of the later product.
System design: The object is to define a cross-domain solution concept which describes the
essential physical and logical characteristics of the future product. The overall function of a
system will be divided into sub-functions. Suitable working principles and/or solution
elements are assigned to these sub-functions and the fulfilling of the functions regarding the
overall system context is evaluated. In mechanical engineering this phase is called
“conceptualisation”, but this term has not the same meaning within software and electronic
engineering. Therefore “system design” has been chosen as a cross-domain term. The
integration of the involved disciplines is supported by methods and tools: Structuring
mechatronic systems in modules in order to reduce complexity [8], using a common language
to specify the solution concept [9], early modelling and tool-supported simulation [10] [11],

5
organisational support (project teams, integration of external design partners etc.). These
methods and tools are described in detail in [7].
Domain-specific design: The solution concept which has been developed conjointly by the
involved domains will be worked out in detail mostly separately in the concerned domains.
Elaborate design and calculations are necessary in order to guarantee the functional
performance, in particular that with critical functions.
System integration: The results from the specific domains are integrated to an overall system
in order to analyse the interrelations.
Verification/validation: The design progress has to be checked continuously by means of the
specified solution concept and the requirements. It is to be assured that the actual system
characteristics match with those wanted.
Modelling and model analysis: The described phases are flanked by the modelling and
analysis of the system characteristics with the aid of models and computer-aided tools for
simulation.
Product: The product is the result of a macro-cycle sucessfully passed through. It does not
exclusively mean the finished, really existing manufactured item, but the ongoing concretion
of the future product (product maturity). Degrees of maturity are, for example, concept model,
functional model etc.
This procedure model differs from the classic phase-oriented procedure e.g. [2]: First it
clearly distinguishes between micro- and macro-level supporting both the designer and the
design management. Second the macro-model combines top-down and bottom-up approach.
Mechatronic design is often bottom-up-driven (integration of components from different
disciplines by interfaces). New mechatronic functions (functional and spatial integration) need
however the combination of top-down-proceeding to create and bottom-up-proceeding to
evaluate. Third the model is not understood as a rigid plan, it integrates elements for
adaptation.

3.2 Elements for Adaptation to Individual Design Tasks

The feed-back of practicians in industry and the findings of empirical design research
motivated to integrate two elements of adaptation to the procedure model: varying the number
and the specification of macro-cycles and integrating user-specific process modules.

Macro-cycles according to the degree of maturity

The introduced v-shaped model on the macro-level is understood as a generic procedure
pattern. A complex mechatronic product will normally not be finished within one macro-
cycle. Rather several passes are necessary (figure 3).
During a first cycle, for example, the system will be specified functionally, first working
principles and/or solution elements are selected and specified roughly and at the same time
checked for consistency in the system context. First laboratory samples are the result. These
results are worked out in detail within a second cycle (detailed specification of the structures,
behavior and shape simulation) in order to generate early prototypes. The macro-cycles can be
adapted to the specific design task: According to the company convention, the type and
complexity of product etc. the number of macro-cycles and the corresponding product
maturity gates can be specified individually. It allows to vary the level of abstraction of the
procedure model from a generic level (one macro-cycle) to a more detailed level (several
macro-cycles) e.g. for project management and design controlling.

6
 degree of maturity degree of maturity

access
lab. early preprod.
requirements sample …prototype … product … …

Figure 3. Proceeding with several passes (macro-cycles) and increasing product maturity

User-specific process modules for repeating operation steps

The main phases in the v-model are not yet specified in detail. This has to be done by the
individual designer or team. Especially design procedures which occur regularly during the
design can be described in terms of partly predefined process modules. These process
modules – representing procedures and methods for different design tasks – can be organized
in a data base (figure 4).
requirements product

data base
with process modules
ion
grat
syste

inte

verification/validation
md

tem
esig

sys
n

domain-specific design
mechanical engineering
electronic engineering
information technology

modelling and model analysis

selection/
phases/milestones tasks/activities results
adaptation
of process clarification and
definition of the task
module
1 requirements
list
abstraction and problem
system design formulation
establishing functional structures
overall function - sub-functions

Figure 4. Configuration of process modules for individual operation steps

7
According to the individual design task the designer can choose the appropriate process
modules meeting his requirements; if necessary he can adapt them or create new ones. In
figure 4 the process module “system design” is selected and specified. The description can be
e.g. phase-milestone-diagrams, checklists, process-flow-diagrams etc. Process modules
motivate the designer to organise repeating design steps systematically, but not in a rigid way.
Individual design procedures can be generated combining and adapting appropriate process
modules. Experiences from former projects can be reused and company-own or product-own
process standards can be established.

4. Practical Application of the Procedure Model

The guideline provides the methodical frame and illustrates the practical application with the
help of examples. The following example shows the design task “design of the drive unit for a
varnishing line” (figure 5) [15]. The focus is on the sub-function “create and control a
oscillating translation movement of the spray head“. Solution variants have to be found and
evaluated, the dynamic behavior of the controlled system has to be analysed. The varnish has
to be layed on in a very equal way. Therefore the spray head has to be moved with constant
speed on a defined distance. It is a mechatronic task to control speed and to minimize
unwanted oscillations.

spray vertical
heads varnishing

horizontal
varnishing
Y
X spray head
object to be Z

varnished

belt conveyor

Figure 5. Design sketch and main functions of a varnishing line

For this design task mainly the two design phases “system design” and “modelling/system
analysis” are mainly concerned. Therefore the designer will select among the predefined
process modules the most similar ones and adapt them if needed to the present situation
(figure 6).

8
 requirements product

searching for variants to transform

system design a rotational to a linear movement

tion
gra
sys
rough specification of the

inte
tem
verification/validation
mechanical and electric drive

tem
des
components ( power, mass, -

sys
ign
inductivity etc.)

evaluation and selection of the domain-specific design

variants mechanical engineering
electronic engineering
information technology

modelling and model analysis

modelling / sys- modelling of the total system

tem analysis (MatrixX/SystemBuild model)
design of the control structure
.
resp. the control system
verification of the requirements
in the simulation model

Figure 6. Design-specific v-shaped model with the detailed process modules “system design” and
“modelling/system analysis”

5. Conclusion
Mechatronics offers success potentials for the creation of new products, makes however
special requirements to the design process: Mechatronic systems are characterised by high
complexity due to the great number of connected elements which are realized furthermore in
different engineering domains (heterogeneity). In order to manage these requirements a
procedure model for the systematic design of mechatronic systems is needed. Adaptability to
the individual design task has to be supported to ensure acceptance and use in industry.
The contribution presented the main elements of the flexible procedure model as a part of the
new guideline VDI 2206. The Elements are: 1) general cycle of problem solving on the
micro-level, 2) v-shaped model on the macro-level, 3) macro-cycles according to the degree
of maturity and 4) user-specific process modules for recurring operation steps.
The guideline is a step towards a mechatronic-specific methodology comprising basis of
mechatronic systems, procedure model, methods of modelling and model analysis, computer-
aided tools and selected aspects of mechatronic organisation. The “green print” of VDI 2206
is published in March 2003, the “white print” with translation in English is scheduled for
2004. Discussion within the design research community is greatly appreciated. Especially the
feed-back of practicians in industry is important in order to evaluate and to improve the
methodology.

6. Acknowledgements
Parts of this contribution originate from the guideline VDI 2206. The guideline has been
worked out by the guideline committee with about 40 well-known specialists in the field of
mechatronics. The authors want to thank all members of the guideline committee, especially
the core team, for the excellent collaboration and the supply of knowledge, tables and figures.
Thanks are also given to the VDI for the organizational support.

9
References
[1] Dörner D., „Gedächtnis und Konstruieren“, Pahl G. (Hrsg.): Psychologische und
Pädagogische Fragen beim methodischen Konstruieren, Ergebnisse des Ladenburger
Diskurses, Mai 1992 - Oktober 1993, TÜV Rheinland, Köln, 1994.
[2] VDI 2221, „Methodik zum Entwickeln und Konstruieren technischer Systeme und
Produkte“, Beuth Verlag, Berlin, 1993.
[3] Birkhofer H. and Lindemann U., „Empirical Design Research - what we know and what
we want to know, Critical Enthusiasm - Contributions to Design Science“, A 'festschrift'
for Mogens Myrup Andreasen the occasion of his 60th birthday, 17. December 1999,
Trondheim/Lyngby, Norwegian University of Science and Technology, 1999.
[4] Birkhofer H., Lindemann U., Albers A. and Meier M., “Product Development as a
Structured and Interactive Network of Knowledge – a Revolutionary approach”,
Proceedings ICED 2001, Glasgow, 2001.
[5] Lindemann U., “Flexible Adaptation of Methods within the Design Process”,
Proceedings DESIGN 2002, Dubrovnik – Croatia, Zagreb, 2002.
[6] VDI 2422, „Entwicklungsmethodik für Geräte mit Steuerung durch Mikroelektronik“,
Beuth Verlag, Berlin, 1994.
[7] VDI 2206, „Entwicklungsmethodik für mechatronische Systeme“, Entwurf, Beuth
Verlag, Berlin, 1993.
[8] Liu-Henke X., Lückel J. and Jäker K.P., „Development of an Active Suspension/Tilt
System for a Mechatronic Railway Carriage“, Proceedings IFAC ´00, Darmstadt, 2000.
[9] Gausemeier J., Flath M. and Möhringer S., „Modelling and Evaluation of Principle
Solutions of Mechatronic Systems, Exemplified by Tyre Pressure Control in
Automotive Systems“, Proceedings ICED 2001, Glasgow, 2001.
[10] PAS 1013, „MechaSTEP - STEP Datenmodelle zur Simulation mechatronischer
Systeme“, Publicly Available Specification, Beuth-Verlag, Berlin, 2001.
[11] Modelica: Object-oriented language for the modelling of multidisziplinary systems,
http//:www.modelica.org.
[12] Kranach M. von, Ochsenbein G. and Valach L., „The Groupe as Selfactive System:
Outline of a Theorie of Groupeaction“, European Journal of Social Psychology, 16,
1986, pp. 193-229.
[13] Daenzer W.F. and Huber F., „Systems Engineering - Methoden und Praxis“, 8.
verbesserte Auflage, Verlag Industrielle Organisation, Zürich, 1994.
[14] Bröhl A.-P. (Hrsg.), „Das V-Modell – der Standard für die Softwareentwicklung“, 2.
Auflage, Oldenbourg, München, 1995.
[15] Nordmann R., „Maschinenelemente und Mechatronik“, 2. Auflage, Shaker Verlag,
Aachen, 2001.

Prof. Dr.-Ing. Jürgen Gausemeier

Heinz Nixdorf Institut, University of Paderborn, Fürstenallee 11, 33102 Paderborn, Germany, Tel.: +49-5251-
606267, Fax: +49-5251-606268, e-mail: [email protected], http://wwwhni.upb.de/rip/
Dr.-Ing. Stefan Moehringer
Simon Moehringer GmbH, Industriestrasse 1, 97353 Wiesentheid, Germany, Tel. +49-9383-950-29, Fax: +49-
9383-95015, e-mail: [email protected], http://www.moehringer.com

10