Chapter 1

Models and Procedures of Product

Development

Sándor Vajna, C. Burchardt, P. Le Masson, A. Hatchuel, B. Weil, T. Bercsey,

and F. Pilz

Sándor Vajna

Integrated Product Development (IPD) is one of the best-known integration

approaches to support product development [GeBa-2002], which is not limited to
specific industries. It arose from the necessity to integrate all areas involved in the
generation of a product (starting with marketing, followed by production to sales) into
product development by means of suitable measures, to overcome forms of organiza-
tion based on the division of labour and to concentrate not only on solving technical
problems but also on the associated processes [Olss-1985, Ehrl-1995, Burc-2001].
IPD focuses on the following objectives [Naum-2005]:

The author would like to cordially thank Prof. Dr.-Ing. K. Ehrlenspiel for numerous valuable
contributions to the entire chapter.

S. Vajna (B)
Weinheimer Str. 95, D-69469 Weinheim, Germany
e-mail: vajna@ovgu.de
C. Burchardt
Burgberg 3, D-31832 Springe, Germany
e-mail: carsten.burchardt@siemens.com
P. Le Masson · A. Hatchuel · B. Weil
Design Theory and Methods for Innovation, MINES Paris Tech, Paris, France
e-mail: pascal.le-masson@mines-paristech.fr
T. Bercsey
Budapest University of Technology and Economics, Budapest, Hungary
e-mail: bercsey.tibor@gt3.bme.hu
F. Pilz
Information Technologies in Mechanical Engineering, Otto-von-Guericke University Magdeburg,
POB 4120, D-39016 Magdeburg, Germany
e-mail: fabian.pilz@ovgu.de

© Springer Nature Switzerland AG 2020 1

S. Vajna (ed.), Integrated Design Engineering,
https://doi.org/10.1007/978-3-030-19357-7_1
2 S. Vajna et al.

• Shortening the time from capturing the needs and requirements of customers and
the market to production release, market launch, use and return of the product,
respectively, conception, market launch, usage and withdrawal of a service,
• The best possible implementation and fulfilment of these needs and requirements,
• Reduction of development, creation, usage and return costs of the product and
• Improvement of product and process quality.
IPD thus initially covers product development. This consists of product plan-
ning, sales and marketing, industrial design, (advance) development, (Engineering)
design, calculation and simulation, production preparation with a -**-sign and testing
[VWZH-2018]. In addition, it covers the entire life cycle of a product (product life
cycle, see Chap. 2). IPD is linked to the other divisions by a mutual flow of infor-
mation. This makes it possible to develop accompanying objects in close coordina-
tion with the actual product at the same time, for example operating materials and
packaging [Bram-2004].
In terms of planning and foresight (predictive engineering1 ), the information flow
from IPD contains, in addition to the complete product documentation at the time of
release for production, all specifications calculated, simulated and evaluated during
IPD for the various guidelines and activities in the company for production, sales and
distribution, use and maintenance/servicing as well as for the return and reuse of the
product or its components at the end of their life. To make this possible, the flow of
information into IPD is required in the form of feedback and preliminary information
from those areas of the product life cycle that follow the actual development (reverse
engineering2 ). This results in a cycle of predictive engineering, reverse engineering
and subsequent front loading [Geid-2000] of activities from downstream to product
development. With these approaches and activities, IPD is the most important source
of innovation in the company and is thus causally and decisively responsible for the
success of the company.
Due to its central role, IPD influences the major part of the total costs of product
realization, since during product development about three-fourth of the total costs
and about two-thirds of the manufacturing costs of a product3 are determined by
conceptual and strategic decisions, while the costs incurred (mainly personnel and
IT costs) amount to only one-seventh of the total costs [Wien-1970], Fig. 1.1.
With IPD, all subsequent product properties and the behaviour of the product
under operating conditions can be simulated during product development so that

1 In predictive engineering, the properties, behaviour and associated processes of a product and

its components are simulated in advance, both individually and in conjunction, by corresponding
systems (predominantly FEM systems) and evaluated with current information (at least from those
areas downstream of the IPD, usually from the subsequent product life) [Wart-2000].
2 Reverse engineering analyses an existing product in order to identify the components used in it

and their interrelations in order to create product documentation from it, especially if access to the
original product documentation is no longer possible [OtWo-2001].
3 This statement supports the Pareto Principle formulated by Vilfredo Pareto at the beginning of

the twentieth century according to which about 80% of the results can be achieved in 20% of the
total time of a project, but the remaining 20% of the results require 80% of the total time (see also
Sect. 15.4.3 in Chapter 15).
1 Models and Procedures of Product Development 3

release for production

100 %
costs incurred
costs incurred 80 % 75
(cumulated)
Front
60 %
43 Loading
defined costs
40 %
defined costs
24
(cumulated) 20
20 %
10 8
3 10 5 2

sales Industrial draft Eng. design process- schedu- pro- manu- administration market
research
marketing design layout detailing planning ling curement facturing sales entry

Fig. 1.1 Early cost determination in product development [Wien-1970] with the addition of front
loading

as many influences as possible from the life cycle of the product can be taken into
account at the earliest possible point in time and corresponding decisions can be made
and implemented in good time. Therefore, the focus in IPD is on the interdisciplinary
cooperation of all participants, the timely provision of knowledge and information
in the required quantity and quality, a flattening of hierarchies and the delegation of
competences. The aim is to ensure trouble-free production and use of the product
after release for production [Burc-2001].
In this chapter, we will first describe those procedural models that emerged in
the second half of the twentieth century, mainly in the German-speaking world, and
which created the basis for a methodical and systematic approach to Engineering
design. Then, both origin and further development of selected models of IPD are
described, before the Magdeburg model of IPD [Burc-2001], from which Integrated
Design Engineering (IDE) emerged, is dealt with in the third part. In the last part,
the C-K design theory, the Autogenetic Design Theory and the Development of
Simple Products are presented. These works do not originate from the tradition of
(mechanical) engineering procedures and methods, but use methods and procedures
from other disciplines (C-K design theory: Information processing, model theory
and cognitive science; Autogenetic Design Theory: Biological evolution and Chaos
Theory; Development of Simple Products: System Theory and multi-criteria opti-
mization). They are thus able to develop arbitrary tangible and intangible products
from different disciplines as well as to enable completely different and not necessarily
sequential processes and procedures to develop in a turbulent environment.

1.1 Procedure Models for Product Development

and Engineering Design

Methodical design can be traced back to Redtenbacher (1809–1863), who was a

professor of Mechanics and Mechanical Engineering at the Karlsruhe Polytechnic
from 1841 until his death. He founded scientific mechanical engineering by moving it
4 S. Vajna et al.

Pluralists “Pragmatic" “Flexible" Scientists

methodologists methodologists
"Art" Science
"Practitioners" “Critical" ”Taxonomists" and
methodologists ”rigid" methodists

1850 1850-1870
Redtenbacher
1870-1890
Reuleaux, Grashof
1890-1920
1900 Riedler, Ernst 1920-1950
Kniehahn, Franke,
Zwicky, Kesselring,
Wögerbauer
1950-1965 1950-1980
1950 Rauh, Leyer, Hansen, Bischoff, Müller (GDR)
Matousek,
Martyrer (D) 1965-1980
Rodenacker, Roth, Koller (D),
1980-2000 from 1977
Hubka (CH) & Eder (CDN)
Ehrlenspiel, Pahl & Beitz
2000 Schregenberger, Müller, from 1984 Wallace
Meerkamm

Fig. 1.2 Schematized phase model of methodological ideas between art and science between 1850
and 2000 (after [Ehrl-1995, Heym-2005])

from a rather empirical basis to a strictly mathematical basis. The further development
of methodological design up to the year 2000 is roughly shown in Fig. 1.2 (after
[Ehrl-1995] and [Heym-2005]). Interesting is the subdivision of the representatives
into the categories artists, practitioners, methodologists and scientists. Behind this
lies the question of whether designing is rather an art, i.e. an intuitive procedure, or
a strictly rational, almost mathematical procedure?
The first procedural models for design were developed on the basis of knowl-
edge and experience from various technical fields. Prior to this, and over the
centuries, the process from recognition of a market need or a customer order to
the beginning of the production of the product had been shaped almost exclu-
sively by intuition and empiricism, and in some cases even regarded as an artistic
process. It was not until the middle of the twentieth century that systematic
research began on the development and design process (for example [Wöge-1943,
BiHa-1953, Kess-1954]). This work has been intensified since the 1960s (for
example [Müll-1970, Rode-1970, Hubk-1973, Hans-1974, Kolle-1976, Hubk-1976,
PaBe-1977, Roth-1982, Müll-1990, HuEd-1992, Wall-1995]4 ). The relevant research
work, which since then has developed a methodical, comprehensible and therefore
more rational approach to design under the term Methodical Design, has not yet been
completed.

4 Ken Wallace (1944-2018) translated with L. Blessing and F. Bauert the most significant textbook

of German design, the ‘Konstruktionslehre’ by G. Pahl and W. Beitz, into English (‘Engineering
design—a Systematic Approach’) and edited it. Without his congenial treatment and adaptation of
the contents of the book to the Anglo-Saxon forms and ways of designing, the ‘Konstruktionslehre’
would not have acquired this importance in English-speaking countries that it has today.
1 Models and Procedures of Product Development 5

In the course of finding a solution, models and methods of different levels of

abstraction and with different information contents must be generated and combined.
Such models and procedures are required both for individual work steps and in
qualitatively different phases of the development process. In the research results, the
methodical creation, evaluation and continuous improvement of solution variants are
used as problem-solving strategies, so that the corresponding procedural models are
regarded as an evolutionary solution-finding process in development [VBCA-2005].
However, by focusing on the design process, cross-company considerations,
such as the inclusion of all areas from the product life cycle or the management
of development processes, have only recently become a topic of discussion.
In the following the general procedure model of designing according to Hubka
(because in this model a product is continuously defined and treated as a technical
system) and the current versions of the VDI guidelines 2221 and 2222 are described as
a synthesis of the extensive German research work in the field of design methodology.
The Taxonomy for Mechanical Design according to Ullmann offers a powerful tool
for classification and structuring process models.

1.1.1 General Procedure Model of Designing According

to Hubka

According to Hubka5 , the main task of the design process as an information

processing process is the transformation of requirements (also: the problem situ-
ation) into the description of the desired technical system. This system must have
certain properties and effects in order to meet the requirements. For this, it is neces-
sary to develop a synthesis of the different requirements and the environment in
which the system is to be used and to manifest it in the system [Hubk-1976].
The general procedure model of designing [Hubk-1980] describes an ideal work-
flow with a representation of the individual sequences of the work phases, which
Hubka called stages. In this procedure model, technical and logical connections are
shown, whereby idealized starting conditions are assumed, for example, with regard
to the working conditions of the groups of people involved.
In the conception of the general procedure model, different laws from the
fields of technical processes and systems, findings from psychology, heuristics and
ergonomics as well as the basics of model structuring are incorporated into the formu-
lation of the steps in designing. All steps in designing are described by the following
basic operations:
• Determine the task,
• Search for a solution and
• Decision and solution-finding.

5 Vladimir Hubka (1924–2006), pioneer of modern design sciences, founder of the International
Conference on Engineering design series (ICED) in 1981, which has been held since then every
two years at various locations around the world.
6 S. Vajna et al.

Product planning

Development contract / assignment

Clarify essential basic information Obtain basic information

Feedback– improving the quality (value) of the product

Development task / scope of work
Developing or clarifying the requirements list

Improve Evaluate – Select – Decide Verify

List of requirements
Full description of the technical system
Engineering Design Process

Devising
Product Development

Determine function structure - search for alternatives

Identify concepts – search for alternatives

Improve Evaluate – Select – Decide Verify

Functional structure / concept

Designing
Identify design – search for alternatives
Identify drafts – examine alternatives

Improve Evaluate – Select – Decide Verify

Conceptual design
Release
Elaborate
Detailing, elaborate – examine alternatives

Improve Evaluate- – Select- – Decide Verify

Complete description of a technical system

Prototype, production, testing, development
Document clean-up, release for manufacturing, distribution

Fig. 1.3 General procedure model for designing after Hubka [Hubk-1980]

These steps are supported by the results of the respective operations, provision of
information, verification and presentation. They can be applied in an iterative form
for each stage of the process, Fig. 1.3. The stages that are passed through sequentially
are subdivided into task formulation, conception, design and elaboration. Each stage
has defined the results of the activities it contains, which serve as input for the next
stage.
Within each stage, there is the same sequence of activities that serve to improve
the outcome of that stage. These activities are improving the current solution (so
that several alternatives emerge), evaluating these alternatives to select the most
promising one, and verifying the selected alternative (with a possible jump back if
previously unknown problems were discovered during verification).
The main features of Hubka’s process model are as follows:
• A product is regarded as a technical system that is embedded in its environment
and must exist there according to the requirements.
• Product development is superior to design because it covers several areas of the
product’s life cycle.
1 Models and Procedures of Product Development 7

• Activities can be basically divided into the sequential stages of developing tasks,
conceptualizing, designing and elaborating.
• In each group of activities there is the same pattern of activity from (1) Evaluate,
(2) Select, (3) Decide. Selected products must then be verified and, if necessary,
improved.
• Feedback and repetitions in the process are necessary to improve product and
process quality.
This procedure model is designed to be generally valid. The following influences
must, therefore, be taken into account when applying this procedure model to a
specific application:
• The technical system to be developed and its variety of components including
their degrees of complexity, the necessity of variants, etc.
• Boundary conditions for the realization of the idealized design process. These
conditions consist of both the knowledge and design experience of the employees,
given working conditions, available work equipment, etc.
• The affected organizational areas of the company with their structures, their
respective deadlines and capacities, the technical possibilities of production,
assembly, sales, etc.
• The social environment, for example, standards, regulations, environmental
protection.
During processing, the designer needs support not only in the form of suitable
tools but also in the form of prepared knowledge, which must be offered to him as
context-sensitive as possible. Chapter 17 deals in more detail with the aspects of
knowledge integration.

1.1.2 VDI Guidelines 2221 and 2222

The guidelines VDI 2221 (Methods for Developing and Designing Technical Systems
and Products) [VDI-2221/93] and VDI 2222 Part 1 (Methodological Development of
Solution Principles) [VDI-2222/97], which aim to describe the design process, were
developed in the 1990s as a synthesis of German-speaking design research after the
Second World War. From their origin, the two guidelines describe the methodical
design of mechanical products in the capital goods industry, preferably from large-
scale mechanical engineering and special mechanical engineering. The guidelines
contain descriptions of the procedures, presentation and application of individual
methods as well as their work results. Both guidelines quickly became international
standards after their publication, also through their provision in English and other
languages.
The system technical problem-solving methods are summarized in groups in the
form of a method catalogue. Their application is assigned to the individual work
stages of the general procedural plan. For the application of VDI Guideline 2221 in
8 S. Vajna et al.

Working steps Work results Implicit concept, phases

product model
Assignment

Plan (I)
Requirements specification
1
Iterative jumping forward and backward to

and actualisation Determine the

Requirements list solution space
Determine functions
2 Solution space

procedural
and their structures

Devise (II)
one or more work steps

solution space
Function structure

in the given
Search for solution principles
3

descriptive
Combine
and their structures
Principle solution
Organise into
4 realisable modules
Modular structure Solution patterns

procedural
Optimizing within

Design (III)
Embodiment design of the
5

solution space
relevant modules

descriptive
Preliminary designs

the given
Designing the
6 entire product

Preparation (IV)
Complete design
Draft
Preparation of execution and
7 usage documentation Partial models:
Product - Geometry
documentation - Technology
Product documentation, - Procedures
further realisation - Knowledge etc.

Fig. 1.4 General procedure for design [VDI-2221/93] with an addition from [VBCA-2005]

a company, a function-oriented organizational form is required. Both involvement

and integration of computer support are also required and shown exemplary Fig. 1.4.
Figure 1.4 describes under the heading ‘Implicit concept, product model’ the
design according to biological evolution as a process to determine the solution space
for possible solutions, to combine elements within this space and to create equivalent
but not similar solution patterns from which the desired solution is selected and the
required partial models are created (Autogenetic Design Theory, [VBCA-2005]).
In addition to the general procedure plan according to VDI 2221, the guideline
VDI 2222 provides detailed documents for task specification, function recognition
and function linking as well as for finding basic solutions. The individual methods
are subdivided into the following:
• Clarification of the task.
• Division of the overall function into sub-functions6
• Search for suitable solution principles (e.g. using design catalogues according to
Roth [Roth-1982]).
• Combination and definition of the solution concept (e.g. according to the
Morphological Box method after Zwicky [Zwic-1982]).
VDI Guidelines 2221 and 2222 contain a design procedure plan with individual
methods for the respective work steps. The two directives focused on mechanical
products and referred only to design and development phases, even though VDI
Guideline 2221 demonstrated the fundamental transferability to other disciplines

6 According to the Latin principle of ‘divide et impera’ (divide and rule).

1 Models and Procedures of Product Development 9

Product planning Activities Phases and milestones implicit concept,

product model
planning concept etc.
Determine and
Targets time Results mounting the
Development Clarifying and specifying solution space
Requirements

the solution space

order the problem / the task

procedural
Combine within
Determine functions
Function models
and their structures

descriptive
Search for solution principles Principle solu-
and their structures tion concepts
Rate and select Derivation of more
Solution concept
of solution concepts context-specific Solution patterns

Optimize within

procedural
models of product

solution space
Continuous Structuring into modules, System
refined and interface definition architecture
development:

descriptive
enhanced
requirements Designing the modules VDI 2221 Sheet 2 Partial designs

Integrating the
Complete design Complete design
entire product
Preparation of the execution Product
and usage data documentation

… …
Documents:
Functions
Components
Products
virtually
Parts lists
Work schedules
Simulations
physically Product Kinematics
Safeguarding of documentation Procedures
requirements fulfilment release etc.

Fig. 1.5 Current version of the VDI guideline 2221 of 2019 [VDI-2221/2019]

using examples. Therefore, the VDI guideline 2206 (Development Methodology for
Mechatronic Systems) [VDI-2206] extended the approaches of the aforementioned
guidelines to mechatronic products. The V-shaped structure of VDI 2206 is based
on the V-model from software development [IABG-2013]. Organizational aspects,
such as teamwork, are, however, only rarely explained in the guidelines mentioned
above, and possible forms of computer support are only shown as examples.
VDI 2221 was fundamentally revised and released in 2019 [VDI-2221/2019].
It forms a framework concept for all phases of the design process that also extends
beyond the core area of mechanical product design, because it can include software
development, for example. As before in the edition of 1993, the new edition of the
guideline contains the methodological principles for designing technical systems and
products. It proposes a general and cross-industry plan of action that would allow a
systematic approach to technical problems at different stages of development, from
the abstract to the concrete (Fig. 1.5).
• Incoming is the development order as a result of product planning. The output is
the description of the solution (‘product documentation’).
• In its structure, the model follows the so-called ZHO approach (in German: Ziel-
system—Handlungssystem—Objektsystem, in English: Target system—action
system—object system) that goes back to Ropohl [Ropo-1975] and that has
essentially been extended by Albers for product development [AlEL-2012].
• In the target system (left), it should be noted that the requirements for the product
to be developed are not static, but a change in the course of development—be
10 S. Vajna et al.

it due to changed external specifications (e.g. by the customer) or be it due to

identified errors and weaknesses, the elimination or mitigation of which become
new requirements.
• The action system (centre) shows in the vertical plane the different fields of
activity (almost identical, incidentally, in all the descriptions of the design method-
ology mentioned above): Clarification and specification of the problem/task,
functional and principle considerations, evaluation and selection, decomposition
into modules, their design and assembly into a functional overall product up to
the detailed elaboration of the execution information plus, if necessary, further
documents.
• In the horizontal, the recurring phases of a concrete development project are
indicated: All activities are planned, concepts are created and results are worked
out. However, depending on the type and scope of development, the activities
mentioned must be carried out more or less intensively. The derivation of a specific
process model for a given development task in a particular company depends on
a number of context factors. These are the subjects of the (new) Sheet 2 of the
VDI Guideline 2221 [VDI-2221/2019].
• The object system is represented by the work results in the individual fields of
activity: Requirements, functional and principle models, part drafts, overall drafts,
etc.
• In contrast to the earlier editions of VDI Guideline 2221, the continuous validation
of the relevant product properties is explicitly included in the model (lower part of
the action system in the centre). Virtual (CAx-) or physical methods (experiments)
can be used for this purpose. The safeguarding closes the circle by checking
whether the current work results meet the requirements or where there are still
gaps.

1.1.3 Taxonomy for Mechanical Design According to Ullman

In addition to his design method [Ullm-1992a], which is clearly oriented on the

work of Pahl and Beitz [PaBe-1977] and the VDI guidelines 2221 and 2222
[VDI-2221/93, VDI-2222/97], Ullman in the Taxonomy for Mechanical Design
describes, categorizes, classifies and compares procedures, features and proper-
ties of process models as well as corresponding tools and organizational forms
[Ullm-1992b]. The taxonomy is divided into three parts: Factors (environment, task
and process), characteristics of these factors and the concrete manifestations of the
process model examined, Fig. 1.6.
Ullman basically divides Engineering design into the environment in which
it takes place, the task to be solved, represented by the (respective) initial and the
(desired) final state, as well as the actual activities within the framework of the
design processes with the description of the steps leading from the initial state to the
final state, their effects on Engineering design and the strategies and tools of error
detection and error elimination.