Keywords

1 Introduction and Motivation

Contemporary and future technological products are multi-disciplinary systems developed by multiple engineering disciplines with a significant level of complexity [1]. By talking about complex systems, we talk about systems with a large number of diverse and highly interconnected elements. These systems are characterized by dynamic system boundaries and cross-linkages between their elements [23]. Systems like these, which have the capabilities to communicate with each other, collect and distribute information or are able to autonomously adapt their behavior based on information available across different systems, are termed as Cyber Physical Systems (CPS) [2, 3] or Cybertronic Systems (CTS) [4, 5]. In order to handle the rising complexity of today’s innovative and multi-disciplinary products, it is necessary to rethink and refine current design methodologies, processes, IT solutions as well as the entire enterprise organization. This paper shows an approach how essential aspects and concepts of systems engineering can be integrated in the development process of mechatronic systems in a model-based way to support the reduction of system complexity in the design process of mechatronic and cybertronic systems. In order to analyze todays design processes regarding to the incorporation of systems engineering aspects, chapter two gives a brief overview of design methodologies and extensions in the field of mechatronic and cybertronic systems. While chapter three identifies essential aspects and basic ideas each systems engineering process should include, chapter four compares how well the different approaches from chapter two implements them. This paper ends with chapter five, which summarizes the results after demonstrating how the introduced approaches complement each other.

2 Development of Mechatronic and Cybertronic Systems

2.1 VDI 2206 – Design Methodology for Mechatronic Systems

During the last decades, dozens of methodical approaches for the development of new products or the further development of existing products have emerged in the field of mechatronic systems development [6]. The best known representative of these methodologies is the guideline VDI 2206 [7]. As a supplement to the guidelines VDI 2221 (systematic approach to the development and design of technical systems and products) and VDI 2422 (systematical development of devices controlled by microelectronics), VDI 2206 is intended to describe the methods of developing mechatronic systems. The objective of this guideline is to provide methodological support for a cross-domain development especially in the early phase of development, concentrating on system design. As a whole, the guideline consists of three essential elements: a general problem-solving cycle as a micro-cycle, the V-model as a macro-cycle, and predefined process modules for recurrent working steps. In the description of the micro-cycle, the guideline VDI 2206 refers to the problem-solving cycle used in systems engineering (see [8]). In general, the micro-cycle supports the work on predictable and consequently plannable subtasks as well as the solution process of suddenly occurring and unforeseeable problems. The macro-cycle guides along the logical sequence of important sub-steps in the development of mechatronic systems. Based on ideas from software development, the generic procedure is implemented along the V-model (see [9, 10]). Some of these sub-steps, which keep recurring when designing mechatronic systems, are described in the guideline in a more concrete way. The process module system design is essential for the interdisciplinary development. Its aim is to establish a cross-domain system architecture. This architecture describes the main operating characteristics of the future product. Therefore, the overall function of a system is broken down into main sub functions, which are assigned to suitable operating principles or solution elements [8].

2.2 The MVPE Model for Multidisciplinary Product Development

The MVPE Model is an extension of the VDI guideline 2206, more precisely an extension of the macro-cycle of the guideline, which has been developed at the Institute of Virtual Product Engineering (University of Kaiserslautern, Germany) in the last years [6, 11,12,13]. The extensions focus on two essential points: the support of the left “wing” of the V-model by methods from model-based systems engineering and on the seamless integration and management of data from the entire product lifecycle by a System Lifecycle Backbone. With regard to the left “wing” of the V-model, Eigner et al. identifies three levels of modeling: modeling and system specification, modeling and first simulation, and discipline specific modeling (see Fig. 1) [11]. On the specification level, the system is described by qualitative models, which include the system requirements as well as the functional und logical system structure. These models are descriptive and cannot be simulated. For an early system description, [11] recommend the use of modeling languages like SysML. The second level, modeling and first simulation, focuses on the integration of quantitative aspects by the creation and use of multidisciplinary simulation models (in e.g. Matlab or Modelica). On the last level, the system is modeled more precisely in a discipline-specific way. These models include discipline-specific aspects like e.g. concrete geometry representations and built by specific CAx tools. Parallel to these overlapping levels, the information artifacts or model elements are differentiated in requirements (R), functions (F), logical architecture elements (L) and physical parts (P), which are modeled in languages using authoring tools along the three levels of modeling [13].

Fig. 1.
figure 1

The MVPE-model (after [13])

Full size image

Gilz developed a SysML-based interdisciplinary approach for the creation of a model-based system architecture based on a functional and logical breakdown in the early phase [12]. This approach, the SE-VPE method, guarantees both “horizontal” and “vertical” traceability along the different model elements (R-F-L-P) and is as well construed for a transfer of this elements into a System Lifecycle Management (SysLM) solution. Similar to Product Lifecycle Management (PLM), SysLM [14,15,16] is a general information management solution extending PLM to the early development phase and all disciplines along the lifecycle including services [13].

2.3 The mecPro2 Architectural Framework

With the fourth industrial revolution in engineering, mechatronic systems enhanced to cybertronic systems. To handle the complexity of such innovative, interdisciplinary, and interconnected products and their production systems, a rethinking of current design methodologies, processes, IT solutions, and the entire enterprise organization is needed [17]. The German research project mecPro2 (Model-based Engineering of Products and Production Systems) seized on this requirements and created a concept to increase the efficiency of development projects in the field of Cybertronic Systems by using Model-Based Systems Engineering [18]. One result of the project is the mecPro2 Architectural Framework. Integrated in the mecPro2 Process Framework (another result of the research project [5]) the Architectural Framework is an interdisciplinary, model-based approach to describe a system during the phase of system design supported by the modeling language SysML. The mecPro2 Model Framework, as an essential part of the architectural framework, forms the foundation for the description of the technical system in the early phase (see Fig. 2). It implements basic ideas of various development methodologies in the fields of mechatronic, mechanic, electric/electronic, software and systems engineering [17, 18], especially the RFLP approach from the MVPE model [6, 11], the viewpoints of the SPES Modeling Framework [19], the consideration of principle solutions [20, 21], and the subdivision in requirement and solution space including the three axes of detailing, variability and concretisation derived from the so-called Munich Model of Product Concretisation [21].

Fig. 2.
figure 2

The mecPro2 architectural framework and its model framework [18]

Full size image

As shown in Fig. 2, the description of the system consists of four levels with increasing solution concretization. On the context level the system is described as a black box with its interfaces. The focus of this level is the translation of natural language requirements into a system model. This includes the distinction of the system of interest in regard to its context-based environment as well as a detailed description of the expected system behavior. On the functional level, non-redundant and solution neutral system functions are identified based on the defined system behavior. The result of this level is a hierarchical and structural depiction of the system functionality including all material, energy and signal flows. On the principle solution level, the technical aspects, which realize the desired function, are considered. Therefore, principle solution alternatives should be systematically identified, analyzed and evaluated to make an optimal selection with respect to the requirements. The evaluation and selection should be made in two stages: first with respect of the degree of fulfilment of a function and second with respect of the degree of fulfilment of possible principle solution structures, which are based on the functional structure of the level before. On the technical solution level, the maximum concretization of a solution, for which an organizational unit is responsible for, is reached. The concept to identify the final system structure is similar to the one of the principle solution level. Thereby, solution components will be identified, which realize the system functions by applying the chosen principle solution [17, 18].

3 Systems Engineering

All methodologies and approaches of chapter two include or are based on concepts or aspects from the field of systems engineering. In general, especially if technical products become more and more complex, systems engineering e.g. model-based systems engineering looks like a common concept to solve the problem [8, 22, 23]. INCOSE describes System Engineering as an interdisciplinary approach for the realization of successful systems by considering the whole problem [24]. In the context of problem solving, Haberfellner et al. describes systems engineering as the methodical factor that helps to synchronize other problem solving factors to find the best solution [23]. Therefore, the system design in system engineering is based on two fundamental concepts. Systems thinking as a mindset, that enables a better understanding and redesign of complex systems, and a procedure model based on basic principles and components to support the development and realization of a solution by subdividing them into understandable sub-steps [8, 23].

Systems thinking supports holistic thinking within interdependencies as well as the differentiation and the structuring of the system. Thereby, it contains the essential terms as well as exemplary approaches for the description and illustration of complex object, without unallowed prohibited simplifications. Crawley et al. defined four tasks, which base on the essential features of a system to aid people in practicing systems thinking [22]. The first task is to identify the system, its form, and its function. Each system has form and function, whereby the form is the instrument of function. In the most cases, the primary function of a system is clear. The second task is to identify the entities of a system, their form and functions as well as the system boundary and context of use. System entities are, in general, also systems, which have a form and a function. The system of interest itself could be an entity of a larger system. Important to know is, what is part of the system under development and what is interacting with the system in its context? Based on this, task three helps to identify what are relationships among the entities of the system and at the boundary. Each link between the system entities as well as links to entities outside the system have a formal and functional character. The fourth task is to identify the emergent properties of the system based on the functions of the entities and on their functional interactions. It is the synergy that gives the system its power, because through the interaction between the entities a new function or characteristic arise, that is greater than the sum of the functionalities of its parts [22]. Haberfellner et al. clarify in their approach, that system thinking can be characterized by different perspectives of the system [23]. Therefore, it is essential to describe the system by models, which specify a specific problem of the reality in an abstract and simplified way. The identified perspectives are environmental, impact, structure, and hierarchical oriented. The environmental orientated perspective serves to identify factors, which influence the system or get influenced by it. The impact oriented perspective considers the system - like the first perspective - as a black box. But here, the focus is on the determination of the input and output values. The structure orientated perspective helps to identify, understand and determine the internal structure of the system. This includes dynamic aspects like object, energy or information flows, processes or mechanisms of action. The hierarchical perspective considers the system from two sub-perspectives. The first one is a bottom-up perspective, which considers the system as part of another system. Through this, new comprehensive system delimitation that supports a holistic thinking becomes visible. The second perspective is a top-down one, which shows the system breakdown into its subsystems on different levels. In this scope a system of systems evolves, if systems are getting joined into one system, if a system gets integrated into another one, or if the system of interest was developed independent from the other parts and can realize its functions independently from a specific system context [23].

Like in fields of mechanical, mechatronic, electrical/electronical or software engineering, in systems engineering a lot of procedure models and methodologies have been developed over the last years as well [24]. Haberfellner et al. identified four essential basic ideas each procedure model should include [23]. These principles are:

  1. (1)

    starting from the rough and going to the details

  2. (2)

    consideration of alternative solutions

  3. (3)

    divide the process into chronological steps (phases)

  4. (4)

    use a formal guideline (problem-solving cycle)

    to find for each problem a solution

The first principle is related to several points already mentioned in the context of systems thinking. Thereby, the engineer should start with a large field of consideration for the system that will be restrict step by step. This includes the region of interest (the system and its environment) as well as the design of solutions. Starting with a system as a black box, the levels of detail and concretization will increase stepwise until all system entities and their connections are known (white box). With each level of solution concretization variability occurs. This means that there could be more than one solution to solve the problem. To obtain the best result, it is important to analyze, compare and evaluate these alternatives. In general, this could be alternatives on a very early level of the solution finding process, where each alternative based on different basic idea, or alternatives that are based on the same principle solution but disagree in the pre or final design. The third idea describes a macro strategy that extends the first two ideas. It divides the solution finding process into chronological steps and defines decision and corrections nodes with the aim to reduce complexity as well as the risk of wrong decisions. This allows to jump back to a preceding phase and/or to focus on a different solution alternative. The problem-solving cycle describes a reusable micro-strategy, which can be used in each step of the development process. In general, it is based on the identification of a problem, the search of alternative solutions strategies as well as their analysis, evaluation, and final selection [23].

Systems engineering, in general, includes more than systems thinking and a procedure module which helps to turn a problem into a solution. Especially business needs, which are considered in the project management are as much as important as the technical needs. This paper, however, deals only with the aspects mentioned in this chapter.

4 Comparison Based on Essential Systems Engineering Aspects

While the second chapter with the VDI 2206 guideline, the MVPE model and the mecPro2 Architectural Framework gives a specific overview about design methodologies in the field of mechatronic and cybertronic systems, chapter three introduces essential aspects and principle ideas a system development process based on concepts of systems engineering should include. Table 1 gives an overview, whether and to what extent these fundamental aspect of Systems Engineering are included in the presented methodologies and approaches of chapter two.

Table 1. Comparison of design approaches based on essential systems engineering aspects
Full size table

As seen as in Table 1, each approach includes one or more of the identified essential aspects and concepts of systems engineering. While the VDI 2206 is very abstract on the identified points, individual views of the mecPro2 Architectural Framework can be assigned to the criteria. This is because the VDI 2206, on the one hand, looks at the entire development process from the requirements up to the finished product and, on the other hand, the VDI 2206 is a general guideline, which should guide the engineer during the development process. Whereas the mecPro2 Architectural Framework is a specific methodological and model-based approach developed specifically for the system design phase of cybertronic systems. Although the MVPE model is an extension of the V-model from VDI 2206. It extends the scope of the view by the increase of the System Lifecycle Management Backbone to the entire life cycle and contains - with the SE-VPE method - a model-based procedure for the system design phase. While in the sense of cybertronic, mecPro2 focuses primarily on a context-related description of the system, the focus of the SE-VPE method is mainly on the integration and administration of the essential system elements into a Product Lifecycle Management environment. This is especially evident in the rows ‘environmental orientated perspective’ and ‘impact orientated perspective’ of Table 1. In general the SE-VPE method served as an important basis for the development of the mecPro2 Architectural Framework.

5 Conclusion and Outlook

Based on the statement that systems engineering helps to reduce the complexity of today’s products [23, 24], this paper identified essential aspects and concepts a system engineering-based approach should include. Therefore, chapter four analyzed whether and to what extent these aspect are included in the selected methodologies for mechatronic and cybertronic development. Due to the fact that the introduced approaches build upon each other and represent enhancements, the level of fulfillment increases

with each approach. Nevertheless, each approach has its own right of consent. While the VDI 2206 describes a general guideline for the development of mechatronic systems, the MVPE model - especially with its SE-VPE method and the mecPro2 Architecture Framework - represent methodical and model-based procedures for the design process. Since the mecPro2 approach focusses exclusively on the design phase, there is no problem to integrate it into the interdisciplinary system design phase of the MVPE model (see Fig. 3). However, the SE-VPE method is not to be replaced by the mecPro2 Architectural Framework, but it is an important alternative, especially for the specification of very complex systems.

Fig. 3.
figure 3

Integration of the mecPro2 architectural framework into the system design phase

Full size image