The Evolution of the V-Model: From VDI 2206 to a System Engineering Based Approach for Developing Cybertronic Systems

Abstract

By talking about complex systems, systems engineering is always named as the only way out for the enhancement of system understanding and the reduction of system complexity in the design process. After an identification of the essential aspects and concepts for pursuing systems engineering, this paper shows how well these key factors are integrated in today's methodologies for developing mechatronic and cybertronic systems. The content of this paper is based especially on current and previous research activities on the field of modelbased development at the Institute of Virtual Product Engineering.

The KSCM as Part of a Holistic Methodology for the Development of Cybertronic Systems in the Context of Engineering 4.0

“…The MVPE adds Model-based Systems Engineering (MBSE) and System Lifecycle Management (SysLM) aspects to the original VDI V-Model. Additionally, focusing at the shift of today's technical products toward cyber-physical or cybertronic systems, two approaches stand out in particular -the mecPro² Model Framework (Eigner et al, 2015(Eigner et al, , 2016(Eigner et al, , 2017b and the System Concretization Model after Pfenning (Pfenning, 2017). They both aim at handling the rising complexity of cybertronic systems and ensuring consistent, interdisciplinary and model-based development process.…”

“…The MVPE suggest, in addition to the system development, the importance of a parallel development of services in the early phases as well as the non-neglecting of the topics Product Line Engineering (PLE) and Service Lifecycle Engineering during the lifecycle. (Eigner et al, 2017a) The newly developed methodology presented in the fifth section integrates with the MVPE Model providing the methodological guidance for completing the mentioned modelling tasks.…”

“…This transition also results in variability, because the solution concretization does not occur without the consideration of design alternatives. The system under development is described on each level from a structural and behavioural point of view (Eigner et al, 2015(Eigner et al, , 2016(Eigner et al, , 2017b. The Model Framework is subdivided into a requirement and a solution space, whereby the Context Level corresponds to the requirement space.…”

“…The Context Level facilitates the translation of natural language requirements into a model-based requirements specification and the synchronization in case of changes. The translation and synchronization process is performed in two main steps: a context-based differentiation of the system from its surroundings (this includes the environment, stakeholder, and external systems); and a detailed description of the system use cases in regard to its expected behaviour (Eigner et al, 2015(Eigner et al, , 2016(Eigner et al, , 2017b. The solution space is subdivided into three levels.…”

“…The aim of this level is a detailed white-box description of the system in terms of its structure and its tested behaviour. The end result of this process is the definition of the complete system architecture (which includes the form and function of the system) based on the requirements of the varying contexts in which the system will be used during its lifecycle as a part of one or more cybertronic systems (Eigner et al, 2015(Eigner et al, , 2016(Eigner et al, , 2017b.…”