at – Automatisierungstechnik 2020; 68(5): 312–324

Methods

Iris Graessler* and Julian Hentze

The new V-Model of VDI 2206 and its validation

Das Neue V-Modell der VDI 2206 und seine Validierung

https://doi.org/10.1515/auto-2020-0015 vorteil besteht darin, in der Darstellung unabhängig von

Received March 6, 2020; accepted March 11, 2020 der gewählten Form der Projektorganisation zu bleiben.
Abstract: Since 2016, a new version of the VDI (German Auf diese Weise kann das V-Modell sowohl in klassisch
Association of Engineers) Guideline 2206 has been devel- organisierten als auch in agilen Projekten angewendet
oped by the Technical Committee VDI GMA 4.10 “Inter- werden. Der Beitrag beschreibt das wissenschaftliche Vor-
disciplinary Product Creation”. This article presents the gehen und welche Potenziale ausgeschöpft wurden. Ba-
revision results of the VDI Guideline 2206:2004 “Design sierend auf den identifizierten Potenzialen wird das neue
methodology for mechatronic systems”. The core content V-Modell abgeleitet, erklärt und illustriert. Neue Inhalte
of the guideline is an updated and enhanced V-Model wie die Einführung von Kontrollpunkten und die Integra-
for Mechatronic and Cyber-Physical Systems. The inher- tion von Anforderungsentwicklung werden ausführlich
ent concern logic of the V-Model represents the logical se- erläutert. Darüber hinaus werden die Ergebnisse des In-
quence of tasks. Its key advantage lies in staying indepen- ternationalen Validierungsworkshops mit 25 Experten aus
dent from the chosen form of project organization. This Wissenschaft und Industrie dargestellt.
way, the V-Model can be applied in classically managed Schlagwörter: V-Modell, mechatronische und Cyber-
projects as well as in agile projects. In addition, the article Physische Systeme, Interdisziplinäre Produktentstehung
describes how the revision was performed and which po-
tentials were tapped. Based on the identified potentials,
the new V-Model is derived, explained and illustrated.
New contents such as the introduction of checkpoints and 1 Introduction and motivation
the integration of requirements engineering are explained
Mechatronic products, formed by the disciplines mechan-
in detail. Furthermore, the pursued scientific procedure
ics, electrics/electronics and software are pioneers in us-
and the results of the International Validation Workshop
ing interdisciplinary procedures. In addition, Systems En-
with 25 experts from science and industry are proposed.
gineering provides generic approaches and guidelines for
Keywords: V-Model, mechatronic and cyber-physical sys- the development of interdisciplinary products [1–5]. The
tems, interdisciplinary product creation first release of the VDI Guideline 2206 “Design methodol-
ogy for mechatronic systems” of the German Association
Zusammenfassung: Seit 2016 aktualisiert der VDI GMA
of Engineers (VDI), was published in 2004 [6]. Describ-
Fachausschuss 4.10 „Interdisziplinäre Produktentste-
ing the procedure for the development of mechatronic sys-
hung“ die VDI-Richtlinie 2206: 2004. Dieser Beitrag ent-
tems, the V-Model for the first time was transferred from
hält die Überarbeitungsergebnisse der VDI-Richtlinie 2206
Software Engineering [7] to Mechatronics. The V-Model,
„Entwurfsmethodik für mechatronische Systeme“. Der
which describes the macrocycle of product creation, rep-
Kerninhalt der Richtlinie ist ein aktualisiertes und erwei-
resents the idea of interlinking all disciplines involved in
tertes V-Modell für mechatronische und Cyber-Physische
engineering tasks. In order to meet the challenges of Cyber
Systeme. Die inhärente Ablauflogik des V-Modells reprä-
Physical Systems, Systems Engineering and Digital Busi-
sentiert die logische Abfolge von Aufgaben. Ihr Haupt-
ness Models, the V-Model meanwhile had to be enhanced.
Due to this need for revision, updating and extension of
the V-Model for Mechatronic and Cyber Physical Systems,
the VDI founded the Technical Committee (TC) VDI GMA
*Corresponding author: Iris Graessler, Chair for Product Creation,
4.10 “Interdisciplinary Product Creation” in March 2016.
Heinz Nixdorf Institut, Paderborn University, Paderborn, Germany,
e-mail: [email protected] This Technical Committee is chaired by the first author.
Julian Hentze, Dr. August Oetker Nahrungsmittel KG, Bielefeld, The aim was to identify necessary changes, updates and
Germany, e-mail: [email protected] revisions of the existing VDI 2206:2004 Guideline and to

Open Access. © 2020 Graessler and Hentze, published by De Gruyter. This work is licensed under the Creative Commons Attribution 4.0 Public
License.
 I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation | 313

Figure 1: Scientific approach of VDI 2206 revision.

create and validate a new enhanced V-Model. In order to 2 Scientific approach

achieve excellent applicability in industrial practice, the
TC is constituted by as many industrial as academic mem- The scientific procedure is characterized by a continuous
bers. Industrial members cover the application domains interplay of results generation and in-process-validation.
automotive, automotive electronics, aerospace, defense, In order to identify potentials of enhancing the V-Model,
chemistry, woodworking and textile industries. The aca- the authors started their scientific procedure with three
demic part is represented by scientists of the VDI society parallel analyses (Figure 1). First, literature dealing with
for measurement and automation technology as well as topics like Product Engineering, interdisciplinary work,
the VDI society for Product and Process Design. These in- Mechatronics, Cyber Physical Systems, Systems Engineer-
clude scientific employees working on their phD theses ing etc. was analyzed and existing reference models were
as well as their instructing professors [8]. This structure compared with each other [8–13]. Second, already exist-
guarantees fast results and deep discussions conducted ing V-Models and their individual adaptations to indus-
from different fields of expertise. In the course of the com- trial and scientific application cases were analyzed. The
mittee meetings, additional experts for dedicated topics individually tailored V-Models provide information on rea-
were invited to the TC meetings in order to even deeper sonable and already in numerous cases contextually mod-
and broader insights. The starting point for this publica- ified aspects [14, 15]. Third, further experts were involved
tion is the motivation and call for action for changing the and project experience from different application domains
V-Model and the VDI 2206:2004 Guideline. Further, the was taken into account [5, 16]. As a consequence, po-
chosen scientific approach is explained and validated re- tentials of enhancing the V-Model and the resulting call
sults are summarized. Finally, the new V-Model is pro- for action were derived [10, 17]. Thus, the call for action
posed and explained. was worked out, examined, changed and adapted to the
314 | I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation

Figure 2: Action field of Product Creation [19].

boundary conditions. Taking these basics into account, [6]. Mechatronic systems are characterized by the func-
the new V-Model was concepted in several iteration steps tional and spatial integration of sensors, actuators, infor-
and further enhancement potentials were continuously mation processing and a basic system [21]. The functional
elaborated. Step by step the results were validated using gain of mechatronic systems compared to electromechan-
the VDI GMA TC 4.10 as a sounding board. Thus, reac- ical systems relies on the synergetic effect of interdisci-
tions from participants’ different angles of experience to plinary technologies.
the suggested ideas and contents were used as a test of Early mechatronic systems of the 1960ies only were
validity. External experts from industry and science en- constituted by mechanics and electronics. They were not
riched the discussions in the TC meetings by presenting programmable [6], (Figure 3). Step by step, mechatronic
their own V-Model-approaches. Potentials described in lit- systems additionally gained software and became pro-
erature were used as a basis and as an input for the discus- grammable. Further, adaptronics such as anti-lock brak-
sions [10, 14, 15, 17, 18]. The final results were presented by ing systems emerged.
the authors and externally validated in a workshop with 25
international experts from science and industry during the
International DESIGN 2018 Conference in Dubrovnik.

3 State of the art

In the action field of Product Creation, Systems Engineer-
ing and Engineering Management build the core of the
Product Creation Process (Figure 2). Out of a promising
product idea, a product is engineered [19].

3.1 Mechatronic and cyber-physical systems

In 1969, the Japanese president of YASKAWA Electronic
Corporation, Ko Kikuchi, introduced the term “mechatron-
ics” [6, 20]. As manufacturer of automated technical prod-
ucts, such as servo drives and robots, YASKAWA coined the
understanding of the term “mechatronics” as the expan-
sion of mechanical components by electronic functions.
The term consists of mechanisms and electronics and was Figure 3: From simple mechatronic systems to Cyber-Physical Sys-
protected in the period from 1971 to 1982 as a trade name tems based on [41].
 I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation | 315

Figure 4: Definition of a Cyber-Physical System.

Today, cyber-physical systems (CPS) are created by ex- and strong innovative strength [23, 24]. For example, the
panding mechatronic systems with additional inputs and use of CPS in production as Cyber-Physical Production Sys-
outputs and coupling them to the IoT (Figure 4). With the tems (CPPS) will lead to a fundamental change in produc-
help of AI, the system properties change during opera- tion planning and control, expressed by the term “Indus-
tion. Thus CPS represent the next generation of integrat- try 4.0” [25]. The advantage of CPPS compared to conven-
ing software into technical systems towards fully software- tional production systems lies in the independent config-
integrated and networked systems. As illustrated in Fig- uration of the production systems for continuous adjust-
ure 4, CPS are interconnected mechatronic systems that ment to the order situation and to changing environmental
are additionally connected to the Internet of Things and conditions.
Services and adapting their properties during operation.
This enables them to communicate with each other and
use Internet services. Lee defines CPS as integrations of 3.2 The VDI 2206 guideline’s V-Model
computation with physical processes. Embedded comput- The original idea of a V-Model for engineering processes
ers and networks monitor and control the physical pro- was created 1995 by Bröhl and Dröschel in the applica-
cesses, usually with feedback loops where physical pro- tion field of Software Development [1]. In the core, the
cesses affect computations and vice versa [22]. Broy and symbol of the “V” represents decomposition of the sys-
Acatech define CPS as close connection between embed- tem into its elements on the left thigh and gradual integra-
ded systems for monitoring and controlling physical pro- tion of elements and sub-systems into the entire techni-
cesses by means of sensors and actuators via communi- cal system on the right thigh [8]. Besides these two thighs
cation devices with the global digital networks (the “cy- of the “V”, the properties of the product in development
berspace”). This type of system enables a connection be- are continuously validated and verified [8]. Thus, it is en-
tween processes of physical reality and the digital network sured that the “right” system (validation) is developed
infrastructures available today via chains of effects. This in the “right” manner (verification) [8]. In the 2004 ver-
allows diverse applications with high economic potential sion, requirements are graphically represented as an input
316 | I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation

box. At the bottom of the V-Model, system implementation variants differ in their granularity, their application pur-
is represented. Engineering of mechatronic and Cyber- pose and the envisioned target group [15]. While some rep-
Physical Systems involves multiple disciplines, e. g., me- resent the entire life cycle in the illustration, others only fo-
chanics, electrics/ electronics, software as well as pneu- cus on the phase of product development [15]. An overview
matics, hydraulics, optics or others. The result or output of of the compared characteristic properties is given in [15].
the V-Model is a product. The model is graphically framed In addition to the analysis of V-Model variants, litera-
by a bracket symbolizing modeling and model analysis, ture on the description of product engineering, interdisci-
which begins and ends at the middle height of the two plinary work, mechatronics and Systems Engineering was
thighs. Arrows between the two thighs of the V-Model illus- analyzed. In the publications [13, 14, 17] and [8] the result-
trate the assurance of properties comprising verification ing potentials are explained in detail. These revision po-
and validation activities. At this juncture, the assurance tentials were used as the basis for the discussion in the TC
of properties is indicated right-to-left, which gives the im- “Interdisciplinary Product Creation”. Three exemplary po-
pression of a retrospective process [15, 17, 26]. tentials are provided in the following: First, an integration
of the contemporary V-Model into its temporal and con-
textual environment is missing. The idea of starting with
3.3 Systems engineering requirements and finishing with a product is too limited.
Life-cycle-orientation with the inclusion of all life cycle
Systems Engineering is a structured, multi-disciplinary phases before, in parallel and after development plays a
engineering approach for technical systems, targeting at major role in development. This is underlined by the ap-
a cross-disciplinary optimum within a given time frame proaches and methods of Systems Engineering, which de-
and budget. For this purpose, the disciplines are struc- scribe holistic system thinking as a key feature of success-
tured and networked with each other using models [19]. ful product engineering [32]. Second, requirements elicita-
Besides cross-disciplinary optimum, often mentioned core tion is not integrated into the contemporary V-Model. Due
aspects of Systems Engineering are safety and reliability, to the illustration as an inbox, the contemporary V-Model
complexity management, user experience, lead-time re- gives the impression that requirements were a delimited
duction and cost saving. Emphasis is particularly drawn input. Instead, elicitation, structuring and analysis of re-
on cross-disciplinarity and frontloading, which describes quirements are integral tasks of product engineering. Fur-
focused management attention and high capacities spend ther, requirements collection, modification and manage-
in early stages of the development process. Systems En- ment has to be carried out continuously. Since require-
gineering comprises technical, organizational and man- ments engineering is one of the main success factors of de-
agerial tasks and balances them among each other [10]. velopment projects [15], the work with requirements has to
Systems Engineering provides a holistic approach, which be emphasized and the impression of a given input must
deals with all stages of life cycle of the System of Inter- be prevented. The third potential concerns modeling and
est (SOI) [27, 28]. Restrictions of such upstream and down- model analysis. Models are central in modern product en-
stream tasks shall be represented in the new V-Model. It gineering at any point of project maturity. Already in re-
is based on Systems Thinking, which includes the clear quirements elicitation, models are used to allow the de-
definition of the system, its elements, its interconnections scription of connections and structure. The representation
and the separation from the environment by definition of and explanation of modeling and analysis in the contem-
boundaries [4, 5, 27–31]. porary V-Model therefore should be universal so that the
importance of modeling in development is correctly under-
stood.

4 Need for revision

In addition to the V-Model of the guideline VDI 2206:2004, 5 Validation workshop
there is a large number of V-Models, which have a struc-
tural similarity to the VDI guideline. These V-Model vari- Within the validation workshop held at the 15th Interna-
ants were adapted to individual applications and specific tional DESIGN Conference on May 21st, 2018 at Dubrovnik,
domains [15]. Out of these, representative V-Model variants Croatia, the current state of work was discussed with 25
from Product- and Systems Engineering were chosen and international participants from industry and science. The
compared with each other in detail [15]. These V-Model aim of the workshop was to validate the pre-final state of
 I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation | 317

the V-Model and the guideline VDI 2206:2004. Validation the participants: the inclusion of the engineer as a hu-
of the described suggestions was structured and supported man being and a comprehensive modeling and analysis.
by elaborated discussion theses. Thus the basis for discov- First, the wish to include the human beings with their
ering additional improvement potentials and implications skills, competencies, convictions and emotions was dis-
for the revision of VDI Guideline 2206 was provided. Fur- cussed and taken up in the workshop. In the final version
ther aims of the workshop were to discuss the integration it is represented by coupling the V-Model with the Holis-
of examples, the definition of terms and the graphical il- tic Product Lifecycle (HPLC) Model, which has been de-
lustration of the V-Model, in order to include them into the veloped by the Technical Committee VDI 702 “VDI Sys-
finalization of the guideline. tem House” and will be published soon. Within the HPLC
Model, human beings are represented besides organiza-
tional approaches, information and communication tech-
nologies (ICT). Thus engineers are provided with a clear
5.1 Facilitation method
orientation and enabled to act as drivers in the design of
For the validation workshop, the facilitation method Digital Business Models. Second, comprehensive model-
“Open Space” was chosen. According to the so-called ing and analysis along the whole V-Model was required by
“coffee-break” anecdote, Harrison Owen invented the the participants. In contrast to the contemporary V-Model
open space method when he conducted a congress for 250 of VDI 2206, participants claim a model-based approach of
organizational developers in 1983. At the end of the confer- all engineering tasks. As a consequence, the New V-Model
ence, participants concluded that the “really useful part” is completely framed by the strand “modelling and analy-
of the otherwise successful meeting had been during the sis” (outer blue strand in Figure 5).
coffee breaks. Owen made this the principle of next con- Another key finding of the discussion was outlin-
ing the necessity of representing requirements engineer-
gresses. This implies that participants decide “by their
ing within the “V”. This reflects another weak point of
feet” which topics they want to discuss out of a selection
the former V-Model version of 2004, where requirements
of given topics. Further, they can even add their own top-
are illustrated as limited input box to upper left thigh of
ics. Thus from the participants’ viewpoint, the most impor-
the “V”. Neither the process of requirements elicitation
tant topics are covered. In this case, fifteen prepared dis-
nor requirements management are represented in the con-
cussion theses were offered to the participants. This wide
temporary V-Model. This visualization is based on the ide-
choice was highly appreciated by the participants. They
alized assumption that requirements could be collected
even added two further self-defined discussion theses. In
once and completely. In engineering practice however, re-
sum, eight theses were selected for deeper discussion. The quirements and their values change along the product de-
theses address the main revisions planned to be included velopment process. As a consequence, requirements elici-
in the new V-Model. This includes additions, such as the tation and management is illustrated by a separate strand
definition of a Main Feature List and the implementation (inner yellow strand in Figure 5).
of checkpoints into the model. The ongoing consideration Representation of verification, validation, planning
of requirements management or modeling of model-based verification and validation were another key element of
development in the entire V-Model are two additional im- the discussion. According to several Systems Engineering
portant suggestions. approaches, a set of three arrows is exemplarily represent-
ing continuous planning, verification and validation. It
was discussed that of course, the system is verified and
5.2 Results validated several times along the “V”. In order to simplify
the illustration and achieve good clarity, the arrows are in-
The workshop results comprise implications for the revi- cluded only once and exemplarily. As the system is veri-
sion of the V-Model as well as engineering design research fied at the same system level, this is represented with a
in general. In the following, accepted improvement poten- horizontal arrow, while validation is carried out against
tials and further implications for the revision of VDI Guide- the next higher level of stakeholder demands and interests
line 2206 are outlined. Goals and intentions of V-Model re- and represented by an upwards reaching arrow. Verifica-
vision were generally supported by the participants. On tion and validation are practiced from the very beginning.
the whole, a broad consensus upon the proposed pre- The inherent concern logic of the V-Model was consen-
final revision state of the V-Model and its key elements sus among all participants. To prevent the potential mis-
was achieved. Two further requirements were stressed by understanding of the former V-Model as a process model or
318 | I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation

Figure 5: The New V-Model as presented at DESIGN 2018 Conference in Dubrovnik (illustrated by the organization team of the “VALIDATE THE
V-MODEL FOR NEW VDI 2206” Workshop Iris Graessler and Julian Hentze).

a time sequence of activities, the graphical layout of the re- in product engineering processes and the implementation
vised version represents the logical sequence of tasks. The of holistic modeling aspects. The results from this work-
key advantage lies in staying independent from the chosen shop can also be seen as an initial set of requirements
form of project organization. This way the V-Model can be for a broad variety of methodological approaches towards
applied in classical project management as well as in an product engineering. These were gathered not only from
engineering project run by agile principles. an academic perspective, but also from the practical view-
The role of checkpoints was also emphasized by point of practitioners from companies such as Jaguar Land
the workshop participants. Nevertheless, one participant Rover, Saab, BMW and BST eltromat. These represent a
stimulated rethinking the naming in order to prevent an broad portfolio of products in various domains.
association of temporal dependence. A first idea was to
name them “revision points” for a consistency check of
tasks.
6 The new V-Model explanation
In order to foster industrial implementation of the
V-Model, the representation of the “V” shall be self-
Figure 5 illustrates the resulting new V-Model. The
explaining. Therefore, nestings are not incorporated in the
V-Model is based on the basic form of the contemporary
basic illustration of the V-Model. Nestings of V-Models ap-
VDI 2206:2004 Guideline.
pear on different system hierarchy levels, parallel system
elements and subsystems as well as on different maturity
levels. Those nestings shall be illustrated using product ex- 6.1 Structure
amples. Such examples are not meant to validate, but to
explain tailoring and application of the V-Model. The new V-model basically consists of three strands. The
In addition to the findings concerning the revision of central strand in orange describes the core activities and
the V-Model, the discussion of theses in the open space re- tasks. The inner, yellow strand describes the handling and
vealed further research fields for future engineering meth- the work with requirements. The outer, blue strand rep-
ods. These include planning verification and validation as- resents the modeling and analysis activities. Each of the
pects, the discussion of milestones as steering elements three strands graphically contains the involved disciplines
 I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation | 319

at the bottom of the V-Model. This graphic representation The target parameters for property assurance are also de-
shall symbolize that implementation of system elements rived from the requirements.
relies on deep and interwoven detailing in and between
the involved disciplines. This is underlined by a graphical
System architecture and design
consistent background in the individual strand color, since
The core of interdisciplinary Product Engineering takes
the exchange and the coordination among the disciplines
place in the phase of system architecture and design. In
is a crucial success factor. Possible disciplines are classic
the sub-section “system architecture” a cross-disciplinary
mechatronic disciplines such as mechanics, electrics/elec-
overall solution structure of the system is developed.
tronics and software as well as pneumatics, hydraulics,
Based on the functional structure and the underlying prin-
optics, human science, etc.. These disciplines are relevant
ciples of action, the system architecture comprises the
in the main strand as well as in modeling and analysis and
building structure in the mechanical sense, signal flow
in requirements engineering. A brief description of key ele-
structures and circuit diagrams in the electronic sense,
ments of the new V-Model will be given below. The detailed
as well as the structuring of a software program into its
description and the related examples are explained in the
modules and components, including the respective inter-
new guideline published in June 2020.
faces, from the perspective of software. The system archi-
tecture thus embodies elements, relationships and neces-
sary principles for the design and further development of
6.2 Core activities and tasks a system [4]. Structural alternatives are compared on the
Requirements elicitation basis of comprehensible criteria, such as the realisation of
Elicitation, structuring and analysis of requirements form interdependencies, functional analyses and the consider-
the basis of the development process. From needs and ation of exclusion criteria. Ideally, this evaluation is car-
wishes of the different stakeholders (stakeholder needs), ried out with the participation of users. The best possible
requirements are derived and documented in technically allocation of the individual functions to the disciplines in-
and formally language and form, e. g., in a requirements volved is determined in an iterative procedure on the basis
list or diagram. The requirements are described from the of system partitioning. The task of the system architect is
perspective of the stakeholder and do not describe the the decomposition of the system into implementable units.
system in the first step, but the needs and wishes of the Starting from the required system functions and proper-
ties, a system is broken down step by step from the func-
stakeholders (stakeholder requirements). These are sub-
tional, property and implementation point of view. The re-
sequently converted to the system view in the following
sult is verifiable units, i. e., system components with allo-
step (system requirements) [4]. The specification, which is
cated specified requirements and relevant interface infor-
the result of the requirements elicitation, is a description
mation. The number and design of the interfaces within
of the system to be developed with a usually huge num-
an architecture and to the system boundary significantly
ber of requirements. In order to develop a specification
influences the simplicity, adaptability and testability of a
that is as complete as possible, the new guideline offers
system.
an auxiliary instrument: The Main Feature List for Mecha-
tronic and Cyber-Physical Systems. This Main Feature List
supports the user of the guideline to achieve complete- Implementation of system elements
ness and a high quality of the specification [33]. Essential In the implementation of system elements, the specified
quality criteria for a product specification are complete- system elements are laid out, dimensioned, designed and
ness, clarity, consistency and correctness [34]. In the fur- detailed. Mechanical components are dimensioned us-
ther course of development, the requirements list will be ing Computer Aided Design (CAD), Finite Element Meth-
supplemented by successive concretisation and detailing ods (FEM), calculations and simulations. For example,
of the product properties. The objective is to have all essen- static and dynamic basic laws are applied in the design,
tial requirements quantitatively defined at the end of sys- stresses are calculated, deformations and heating under
tem architecture. In addition, requirements can change as load are analysed and service lives are calculated. This is
a result of feedback and iterations from downstream sec- followed by a detailing of the components up to the de-
tions or by updating customer wishes or market require- termination of the tolerances and fits required for the ful-
ments. Changes are therefore systematically tracked and fillment of the function as well as all manufacturing reg-
evaluated. Result of requirements elicitation is a descrip- ulations. Mechanical components include housings, cov-
tion of the system characteristics which are to be fulfilled. ers and flanges of control units in addition to those used
320 | I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation

to transmit forces or moments. For electrical and elec- against the required system properties in a virtual and/or
tronic components, for example, associated printed cir- physical environment. The property validation includes
cuit boards are designed and the electronic components verification and validation. Verification is the confirma-
selected, Application-Specific Integrated Circuits (ASICs) tion by objective proof that a specified requirement is ful-
specified or reconfigurable circuits (field programmable filled [35, 36]. It answers the question: “Was the system
gate arrays, FPGAs) selected as prefabricated components. built correctly? Requirements are verified at the same sys-
The classic Printed Circuit Board (PCB) is a printed cir- tem level at which they were specified. Each requirement
cuit and is used for mechanical fastening and electrical must be verified by an appropriate measure, e. g., analysis,
connection of the components. Electronic Design Automa- inspection, demonstration or test. A verification measure
tion (EDA) or electronic CAD (ECAD) as well as simula- can also demonstrate multiple requirements. It should be
tions of electronics and electromagnetism (FEM, FDTD, performed as early as possible and at the lowest possible
FIT) are used for design automation. In addition to the system level.
circuits, sensors and actuators are developed or selected Due to the close interdependence of integration and
and the electrical infrastructure is designed. For software property assurance, it must be planned in advance in
elements, the implementation includes the conversion of which stages the system will be integrated and for which
an algorithm or software design into a computer program. required scopes with which method, when and at which
Based on the software architecture, functions are imple- system level the implementation shall be proven. Basi-
mented using algorithms and the associated code is gener- cally, the following methods for property assurance are
ated. Database models are implemented by implementing distinguished: (1) Theoretical Analysis: Calculation, Mod-
the modelling in concrete schemes. Furthermore, the user
elling and Simulation; (2) Inspection: for easily visible,
or system interface is designed. During detailing and im-
measurable and recognizable properties; (3) Demonstra-
plementation, the respective mechanical, electronic and
tion: qualitative proof of functionality, usually with mini-
software interfaces are taken into account. At the same
mal instrumentation; (4) Test: quantitative proof, usually
time, this section serves to solve problems that have arisen
in a defined test environment; The integration into the
during system integration.
next higher system level must not start until the verifica-
tion of the initial level has been completed.
System integration and verification
The integration step-by-step merges the implemented
Validation and transition
system elements and subsystems into the next higher
Individual system elements and subsystems have to be val-
product-hierarchy level. The goal is that the integrated
idated; the approach depends on the individual planning
overall system meets the formerly specified requirements.
In the system integration, mechanics, hardware, software of the system or system element. In any case, the fully inte-
as well as service offers are combined to a system or step grated overall system is validated against the stakeholder
by step to system elements of a higher system level. System needs. At the end of the logical pass through the V-Model,
integration takes place in close interplay with detailing the system, whether it be a physical system, a prototype
and implementation, so that any problems that arise are or a simulation is handed over to another entity or stake-
resolved immediately. The interaction of the components holder. This can be a customer, but also another depart-
or elements of the disciplines involved is examined com- ment, a colleague or a subsequent project phase for it-
prehensively in the form of a system simulation or virtual erative development. Validation proves that the work re-
commissioning. The integration strategy must be agreed sult can be used by the user for the specified application
in advance with all relevant stakeholders. [35, 36]. The control questions are: “Was the right system
The property prognosis and assurance is carried out built? Is the customer satisfied? Were the requirements
during development. The system properties to be expected right? Do they represent the needs of the stakeholders?”
are forecasted at an early stage on the basis of models. The Validation is carried out with the customer or between the
property validation that accompanies the development is requirements provider and the recipient. The validation
used for the continuous examination of the pursued so- of the system takes place with the superordinate require-
lution on the basis of investigations with virtual proto- ments (next higher system level) and serves as proof of the
types (computer simulation), physical prototypes (hard- fulfillment of stakeholder needs or customer value. Each
ware experiment) or their combination (e. g., hardware-in- requirement must be verified and validated. In the event
the-loop, HiL). The progress of the product is thus checked of fuzzy requirements, suitable validation measures, such
 I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation | 321

as acceptance tests, are agreed with the stakeholders dur- Requirements management describes the handling of re-
ing the planning phase. In the case of large quantities and quirements. The structuring, allocation, analysis and in-
safety-critical applications, the product is not only speci- tegration of changes of requirements has to be handled
fied by models, but also functionally secured using proto- during the whole development project. Handling require-
types. All necessary models and documents for the subse- ments is supported by various tools, databases and meth-
quent stages in the product life cycle are stored and struc- ods. Requirements management is relevant on high system
tured using Product Data Management (PDM) along the level as well as on the level of system elements. The dif-
product development process. From this, the final prod- ferent system levels have high influences on each other,
uct documentation is built up and completed. As a pre- so changes in requirements must be reflected and docu-
requisite for a later digital twin [42], basic models are cre- mented to the overall project and all relevant project par-
ated which allow the simulation of system behaviour. This ticipants.
is also known as the Digital Master. The digital represen-
tation of the associated customer-specific versions of the
product is referred to as the Digital Twin. 6.4 Checkpoints
The three strands that represent the main tasks and activ-
ities in the New V-Model are backed by a structure of six
6.3 Additional general activities checkpoints. The checkpoints contain questions, which
help the user of the V-Model to carry out a structured and
Modeling and analysis
complete development process leading towards a success-
For efficient computer-based development of mechatronic
ful product. The six checkpoints are described in the pub-
and cyber-physical systems, a digital representation of the
lication [13]. The questions serve for orientation and have
system is required. Modern product development methods
no claim of completeness. They may also encourage ad-
are consistently supported by models. Models have to be
ditional questions for individual needs or standards on
created for the overall system, all subsystems and system
company or individual project level. In contrast to project
elements. Dependencies of subsystems and system ele-
management, in which decision gates or milestones are
ments on a high system level are taken into account as well
described as obligatory control points with the possibil-
as dependencies into and between the involved disciplines
ity of terminating a project, the checkpoints give hints to
[6]. Even requirements elicitation and analysis methods the user [40]. Checkpoints do not represent a structure of
generate computer-aided models: requirement diagrams a project, but deliver a substantive support for application
or stakeholder models are examples. As a result, a large [13]. Two exemplary checkpoints at the specification and
number of models is generated during the development of for the integration are provided in Tables 1 and 2.
system architecture and implementation. As graphically il-
lustrated in the New V-Model, modeling and analysis also
affects the individual disciplines: Each involved discipline 6.5 Assurance of properties
has a huge variety of models. In context of model-based
development and MBSE (Model-based Systems Engineer- In the middle of the model, between the two thighs of the
ing), the models of the disciplines are linked to the models V, three arrows symbolically indicate the activities of the
on system level and have an active exchange of informa- assurance of properties. The individual arrows are repre-
tion. Forming the models also requires active analysis and sentative of activities that can be highly relevant at almost
synthesis [37]. This concerns the evaluation, the interpre- any time. “Planning verification & validation” describes
tation and the simulation of system elements, subsystem the need to start extensive activities already on the left
or the entire system. thigh of the V-Model in order to be able to secure the de-
fined requirements in the sequence. The planning goes be-
yond the description of a good requirement. It not only de-
Requirements Engineering scribes how a request needs to be secured, but also how
In a multitude of definitions, Requirements Management it should be done. The representative arrows “Validation”
is described in conjunction with Requirements Elicitation and “Verification” divide the assurance of properties into
as “Requirements Engineering” [38, 39]. In order to stress the questions “Did we do it right?” (verification) and “Did
the importance of elicitation as the basis for a successful we do the right thing?” (validation). Validation is illus-
project, both terms are used individually in the V-Model. trated by an upward arrow towards a higher level, because
322 | I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation

Table 1: Checkpoint Specification.

not the technical specification is checked, but the fulfill-
ment of the wishes of the customer and other stakehold-
ers.

7 Summary and outlook

The high level of agreement with the discussed theses val-
idates the V-Model elaborations of the workshop organiz-
ers. None of the proposed changes was rejected. All dis-
cussed changes were confirmed and their importance was
stressed. Additional suggestions on formulation and pre-
sentation were reflected in the final version of the guide-
line. The dissemination of examples and their presenta-
tion in the guideline raise awareness and applicability.
During the workshop, some new members could be re-
cruited to join the TC 4.10 and from then on actively con-
tributed to the elaboration and formulation of the guide-
line. In June 2020, the New V-Model was published as a
“VDI Green Print”.

Acknowledgment: We would like to thank the members

of the technical committee VDI GMA 4.10 “Interdisci-
Table 2: Checkpoint Integration. plinary Product Creation” and all workshop participants
at the DESIGN 18 conference for the lively technical discus-
sions.

References
1. United States Department of Defense, “Systems Engineering
Fundamentals,” Fort Belvoir, Virginia, Jan. 2001.
2. U.S. Department of Transportation, “Systems Engineering
Guidebook for Intelligent Transportation Systems: Version 3.0,”
2009.
3. NASA, NASA Systems Engineering Handbook. Washington D.C.:
United States Government Printing Office, 2007.
4. D. D. Walden, G. J. Roedler, K. Forsberg, R. D. Hamelin and T. M.
Shortell, Systems engineering handbook: A guide for system
life cycle processes and activities, 4th ed. Wiley, 2015.
5. I. Gräßler, J. Hentze and C. Oleff, “Systems Engineering
Competencies in Academic Education: An industrial survey
about skills in Systems Engineering,” in 13th System of Systems
Engineering Conference, Paris, 2018, pp. 542–547.
6. VDI 2206 – Design methodology for mechatronic systems,
2206, Beuth Verlag, 2004.
7. A.-P. Bröhl (Ed.), Das V-Modell: Der Standard für die
Softwareentwicklung mit Praxisleitfaden, 2nd ed. München:
Oldenbourg, 1995.
 I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation | 323

8. I. Gräßler, “A new V-Model for interdisciplinary product 23. Acatech, Cyber-Physical Systems: Innovationsmotoren für
engineering,” (eng), in Engineering for a changing world: 59th Mobilität, Gesundheit, Energie und Produktion. Dordrecht:
IWK, Ilmenau Scientific Colloquium, Technische Universität Springer, 2011.
Ilmenau, September 11–15, 2017: proceedings, 2017. 24. M. Broy, Cyber-Physical Systems: Innovation Durch
9. I. Gräßler, “Umsetzungsorientierte Synthese mechatronischer Software-Intensive Eingebettete Systeme. Berlin, Heidelberg:
Referenzmodelle: Implementation-oriented synthesis of Springer-Verlag Berlin Heidelberg, 2010.
mechatronic reference models,” in Konferenzband der VDI 25. H. Kagermann, W.-D. Lukas and W. Wahlster, “Industrie 4.0:
Mechatronik: Fachtagung Mechatronik 2015, T. Bertram (Ed.), Mit dem Internet der Dinge auf dem Weg zur 4. industriellen
Dortmund, 2015, pp. 167–172. Revolution,” in vol. 13, VDI-Nachrichten, 2011.
10. I. Gräßler and J. Hentze, “Enriching Mechatronic V-Model by 26. J. Gausemeier and S. Moehringer, “New Guideline 2206:
Aspects of Systems Engineering,” in 2015 – Smart Structures A flexible procedure model for the design of mechatronic
and Materials, A. L. Araujo and C. A. Mota Soares (Eds.), 2015, systems,” in Proceedings of ICED 03, the 14th International
pp. 80–86. Conference on Engineering Design, Stockholm, 2003.
11. I. Gräßler, A. Pöhler and J. Hentze, “Decoupling of product and 27. IEEE, Systems and software engineering: System life cycle
production development in flexible production environments,” processes, 2nd ed. Geneva: ISO/IEC-IEEE, 2008.
in 27th CIRP Design Conference 2017, Cranfield Campus, 28. R. Haberfellner, Systems Engineering: Grundlagen und
Cranfield, United Kingdom, 2017, pp. 548–553. Anwendung, 12th ed. Zürich: Orell Füssli, 2012.
12. J. Hentze, T. Kaul, I. Gräßler and W. Sextro, “Integrated 29. C. W. Churchman, The systems approach, 2nd ed. New York, NY:
modeling of behavior and reliability in system development,” Laurel Book, 1984.
in ICED17: 21st International Conference on Engineering Design 30. L. van Bertalanffy, General system theory: Foundations,
Vancouver, 2017, pp. 385–394. development, applications, 14th ed. New York: Braziller, 2003.
13. I. Gräßler, “Competitive Engineering in the Age of Industry 4.0 31. R. D. Arnold and J. P. Wade, “A Definition of Systems Thinking:
and Beyond,” in Proceedings of TMCE, Las Palmas de Gran A Systems Approach,” Procedia Computer Science, vol. 44,
Canaria, 2018. pp. 669–678, 2015.
14. I. Gräßler and J. Hentze, “A V-model based comparison of 32. E. C.Honour, “Understanding the Value of Systems
Systems Engineering approaches,” in ECEC 2015, Lisbon, Engineering,” 2014. Willey.
Portugal, 2015, pp. 80–88. DOI:10.1002/j.2334-5837.2004.tb00567.x.
15. I. Gräßler, J. Hentze and T. Bruckmann, “V-Models for 33. I. Gräßler, M. Dattner and M. Bothen, “Main Feature List as core
Interdisciplinary Systems Engineering,” in Proceedings of the success criteria of organizing Requirements Elicitation,” Milan,
DESIGN 2018 15th International Design Conference, Dubrovnik, 2018. DOI:10.17619/UNIPB/1-679.
2018, pp. 747–756. 34. I. Gräßler, V. Haas and W. Suchowerskyj, “Innovation Based on
16. I. Gräßler, C. Oleff and J. Hentze, “Role Model for Systems Applying Design Methodology,” in TMCE 2012, 2012, pp. 37–43.
Engineering Application,” in 22nd International Conference 35. ISO 29119, Software and systems engineering: Software
on Engineering Design, Delft, The Netherlands, 2019. testing: Part 1: Concepts and definitions = Ingénierie du
17. I. Gräßler, J. Hentze and X. Yang, “Eleven Potentials for logiciel et des systémes: essais du logiciel. Partie 1, Concepts et
Mechatronic V-Model,” in Production Engineering and définitions. Geneva, s. l., New York: ISO, 2013.
Management: 6th International Conference, Lemgo, Germany, 36. M. Daigl and R. Glunz, ISO 29119 – Die Softwaretest-Normen
2016, pp. 257–268. verstehen und anwenden. Heidelberg: dpunkt.verlag, 2016.
18. G. Versteegen, Das V-Modell in der Praxis: Grundlagen, 37. K. Pohl, H. Hönninger, R. Achatz and M. Broy, Model-Based
Erfahrungen, Werkzeuge. Heidelberg: dpunkt.verlag, op. 2000. Engineering of Embedded Systems: The SPES 2020
19. I. Gräßler, “Implementation-oriented synthesis of mechatronic Methodology. Berlin, Heidelberg: Springer Berlin Heidelberg,
reference models,” in Fachtagung Mechatronik 2015, 2012.
Dortmund, Deutschland, 2015, pp. 167–172. 38. C. Ebert, Systematisches Requirements Engineering:
20. F. Harashima, M. Tomizuka and T. Fukuda, “Mechatronics – Anforderungen ermitteln, spezifizieren, analysieren und
“What Is It, Why, and How?”: An editorial,” IEEE/ASME Trans. verwalten, 4th ed. Heidelberg: dpunkt.verlag, 2012.
Mechatron., vol. 1, no. 1, pp. 1–4, 1996. 39. K. Pohl and C. Rupp, Requirements engineering fundamentals,
21. I. Gräßler, Kundenindividuelle Massenproduktion: 2nd ed. Santa Barbara, CA: Rocky Nook, 2015.
Entwicklung, Vorbereitung der Herstellung, 40. R. G. Cooper, “Perspective: The Stage-Gate ® Idea-to-Launch
Veränderungsmanagement. Springer Berlin, Heidelberg, New Process—Update, What’s New, and NexGen Systems,” J Product
York u. a., 2004. Innovation Man, vol. 25, no. 3, pp. 213–232, 2008.
22. E. A. Lee, “Cyber Physical Systems: Design Challenges,” 41. M. Abramovici and O. Herzog (Eds.), “Engineering im Umfeld
in 2008 11th IEEE International Symposium on Object and von Industrie 4.0”, 2016.
Component-Oriented Real-Time Distributed Computing, 42. R. Stark and T. Damerau, “Digital Twin”, in International
Orlando, FL, USA, 2008, pp. 363–369. Academy for Production Engineering, 2019.
324 | I. Graessler and J. Hentze, The new V-Model of VDI 2206 and its validation

Bionotes Julian Hentze

Dr. August Oetker Nahrungsmittel KG Bielefeld, Industry 4.0
Strategy & Competence, Bielefeld, Germany
Iris Graessler [email protected]
Chair for Product Creation at the Heinz Nixdorf Institute, Paderborn
University, Germany Julian Hentze studied mechanical engineering at Paderborn Univer-
[email protected] sity and had subsequently worked at the chemical company Flint-
Group in Ahaus. In 2014 he returned to Paderborn to jain the Chair for
Prof. Dr.-Ing. Iris Gräßler studied mechanical engineering at the RWTH Product Creation of Prof. Dr.-Ing. Iris Gräßler at the Heinz Nixdorf Insti-
Aachen University, where she received her doctorate degree in 1999. tute. Since January 2020 Julian Hentze has been a Senior Technology
In 2003 she qualified as a professor at the RWTH Aachen University Engineer at Dr. August Oetker Nahrungsmitteltechnik KG in Bielefeld.
due to her habilitation thesis entitled “Development of Configurable
Adaptive Mechatronic Systems”. After thirteen years as a manager at
Robert Bosch GmbH in the fields of product development, produc-
tion systems and change management, she has held the Chair for
Product Creation at the Heinz Nixdorf Institute of the University of
Paderborn since 2013. Her research focuses on model-based prod-
uct development, especially agile scenario technique, requirements
management, systems engineering, development methodology, dig-
italization and virtualization. The emphasis lies on adaptive config-
urable mechatronic systems and cyber-physical systems. In order to
further develop and transregionally harmonize development meth-
ods, Graessler commits herself to the VDI (Association of German En-
gineers) work on guidelines such as the reissue of the directive VDI
2206 in 2020. As a result of her scientific achievements, she was ap-
pointed to the Scientific Society for Product Development (WiGeP) in
2017 and to the Advisory Board of the Design Society in 2019. Fur-
ther functions include the Scientific Advisory Board of the VDI/VDE
Society for Measurement and Automation Technology (GMA), the Sci-
entific Advisory Board for the Application Center Industry 4.0 Pots-
dam, Chairwoman of the Examination Committee Industrial Engineer-
ing, Board of Directors of the Heinz Nixdorf Institute and the Scientific
and Technological Advisory Board of the Linz Center of Mechatronics
GmbH.