Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

5.1 Overview

The vision of the Digital Twin itself refers to a comprehensive physical and functional description of a component, product or system, which includes more or less all information which could be useful in all—the current and subsequent—lifecycle phases. In this chapter we focus on the simulation aspects of the Digital Twin. Today, modelling and simulation is a standard process in system development, e.g. to support design tasks or to validate system properties. During operation and for service first simulation-based solutions are realized for optimized operations and failure prediction. In this sense, simulation merges the physical and virtual world in all life cycle phases. Current practice already enables the users (designer, SW/HW developers, test engineers, operators, maintenance personnel, etc) to master the complexity of mechatronic systems.

Nevertheless, the technical challenges are further increasing. Software and especially network connectivity extend the functionality of mechatronic systems. As the traditional mechatronic disciplines (mechanics, electric and electronics) are realized in a more integrated way, their interfaces will be more intertwined. To design these systems and to validate properties by virtual tests in early phases as well as operation and service support multi-domain and multi-level simulation approaches are necessary. These approaches must be embedded in the system engineering and development process and reused in all following lifecycle phases.

In the two dimensions of time and level of detail a seamless Digital Twin is required, which focuses on the following points:

  • Reducing time-to-market is today, and will remain so into the future, a key aspect. The intertwining of simulation models over different levels of detail, over all involved disciplines and over lifecycle phases must be enforced.

  • The Digital Twin should be designed in its principal structure in advance and needs its own architecture. It extends the pure data which is available in design and engineering, and is collected during operation and service by simulation models. These simulation models describe and make available system behaviour, performance evaluations and quality considerations. The Digital Twin provides an interface to different models and data in different granularities and keeps them consistent.

  • Optimization of mechatronic products and systems during their use or operation, e.g. as an element of production equipment or supply part, will be more important. The gap between development and operation must be bridged. The redevelopment of models for operation and service is time-consuming and cost-intensive.

  • The Digital Twin connects different value chains. For example, a Digital Twin of a product which is used as production equipment in a production system transports important information (data and executable models) to producers and manufacturers, e.g. for an easier system integration (virtual commissioning, production planning, etc.). This requires that the Digital Twin contains models with different granularity and needs in general a predefinition of its principal architecture (structure, content and purposes). The Digital Twin is not a data monster, which includes everything from all lifecycle phases.

We show in this chapter that simulation has the potential to be integrated into all phases of system design in the future. As such it will be available as an additional feature during all operation phases. As more and more features are realized using software instead of hardware, simulation models are needed to describe all disciplines—separately and in combination—and on different levels of detail. In total, only simulation methods will master the extended challenges coming from new technologies used in all kind of technical systems.

5.2 The Waves of Simulation in System Development

In the last decades, simulation has developed from a technology largely restricted to computer experts and mathematicians to a standard tool used daily by engineers to answer manifold design and engineering questions, as suggested in Fig. 5.1.

Fig. 5.1
figure 1

The Digital Twin is the next wave in simulation technology

In the 1960s–1970s numerical algorithms, generally implemented in FORTRAN, were used to calculate specific physical phenomena to solve design problems. However, this was limited to very special cases, as there would have been few simulation experts. With the increasing spread of workstations and personal computers the number of users grew rapidly and the provision of simulation tools for repetitive tasks like control unit design began to be established.

With a higher number of simulation users, the economic growth of tool providers, technical improvements like increased computing power simulation of all involved disciplines and on different level of detail was possible. Today, simulation is the basis for design decisions, validation and testing not only for components but also for complete systems in nearly all application fields. This trend is unbroken and will be continued in the next years.

Simulation models for all aspects can be implemented and will be provided in parallel with the real component, product or system, and of course, its use does not stop with the commissioning phase. It will be used, for example, during operation for optimized operations and during service for lifetime calculation and improved maintenance.

Other indicators also suggest that the golden time of simulation has just begun. This can be seen from a look to the evolution of mechatronic systems. In the preliminary note from VDIFootnote 1 [1] released in 2004, one can find a description of mechatronics as:

Innovative products require an interdisciplinary combination of mechanical engineering, electrical engineering and information technology. The term ‘mechatronics’ is the expression of this

In the last 15 years, the nature of components, products and systems has changed. In particular, they offer a highly increased number of functions. This functional extension is realized by a larger number of parts and especially by a combined use of different disciplines. Beside mechanics, (or more generally physics) and electricity, the relevance of software and communication, e.g. intra- and internet connection, is raised. This leads to an increase of complexity and so to a stronger use of discipline over spanning methods—simulation is a powerful one. This trend will hold in the future.

Many products which were called “electro-mechanics” some years ago have evolved to mechatronic products. A very prominent example is a coffee machine which developed from a simple device for heating water to a fully automatic device with programs for different coffee taste and advanced cleaning processes. In examples like this, the following three phenomena can be observed:

  • Additional functions are offered by the mechatronic product which are realized more and more by software.

  • The number of parts like drives or sensors in components, products and systems is increased.

  • Intensive use of a combination of different disciplines. Software controls via actuators and sensors the physical section. In many cases the software is executed on microcontrollers which are located nearby and not on separated computer units.

These trends will continue, because there are simply no indicators that point to a change. Quite the contrary, in the near future two other trends will enforce the current development:

  • Components to systemsFootnote 2—Mechatronic products gain a hierarchical structure or will be added as ‘elements’ to larger systems.Footnote 3

  • Enforced connectivityFootnote 4—Such as web technology, internet protocols and increased computing power in the product or system itself.

Taking a more detailed look into the communication capabilities of future mechatronic systems, Fig. 5.2 shows the enhanced understanding of mechatronic systems supplemented by open network capabilities compared with the VDI representation [1]. This principle structure was elaborated in the German Industrie 4.0 BMBF project mecPro2 [2]. In this project the term cybertronicFootnote 5 is used to emphasize the importance of cyber capabilities for next generation mechatronic systems. Cybertronic was used as a shorter form for cyber-mechatronic to underline that the consideration of the physical system remains relevant for the complete system functionality. This all illustrates that the significance of simulation as a method to master complexity and to bridge disciplines will further increase.

Fig. 5.2
figure 2

Enhanced understanding of mechatronic system, as elaborated in the German Industrie 4.0 BMBF project mecPro2 [2]

On the one hand, the requirements for development of future mechatronic systems are rising, and on the other hand, the evolutionary development of simulation techniques leads to significant improvement in mastering the complexity during the design and operation phases. Nowadays in the industrial sector and in technical companies, simulation is still mostly considered to be a tool for research and development (R&D) departments. In addition to more traditional calculations, for instance in multiphysics simulation, aspects like “communication by simulation” and “virtual experience” are emerging applications in various phases of the development processes. Extending simulation to later life cycle phases as a core product/system functionality, e.g. delivered before the real product itself or supporting the operation by simulation-driven assistance, is the next big trend in simulation [3]. Therefore, the realization of a “Digital Twin” is the key vision for industrial application. It includes simplified modelling processes, easy use of simulation, simulation workflows and seamless simulation along all life cycle phases including operation support.

5.3 Concept of Twins

The concept of using “twins” dates back to NASA’s Apollo program, where at least two identical space vehicles were built, allowing the engineers to mirror the conditions of the space vehicle during the mission, the vehicle remaining on earth being called the twin. The twin was also used extensively for training during flight preparations. During the flight mission it was used to simulate alternatives on the Earth-based model, where available flight data were used to mirror the flight conditions as well as possible, and thus assist the astronauts in orbit in critical situations. In this sense every kind of prototype which is used to mirror the real operating conditions for simulation of the real-time behaviour, can be seen as a twin.

Another well known example of a “hardware” twin is the “Iron Bird”, a ground-based engineering tool used in aircraft industries to incorporate, optimize and validate vital aircraft systems [4]. It is the physical integration of electrical and hydraulic systems as well as flight controls, with each laid out in relation to the actual configuration of the aircraft, and all components installed at the same place as they would be on the real airframe. The actual cockpit for the Iron Bird is typically displayed by simulators along with a mobile visual system. From this flight deck, the Iron Bird can be “flown” like a standard aircraft, with a computer generating the aerodynamic model and environmental conditions such as air density, air temperature, airspeed and Mach number.

The Iron Bird allows engineers to confirm the characteristics of all system components as well as to discover any incompatibilities that may require modifications during early development stages. Additionally, the effects and subsequent treatment of failures introduced in the systems can be studied in full detail and recorded for analysis [5].

Due to the increasing power of simulation technologies, and thus more and more accurate models of the physical components today, the “hardware” parts in the Iron Bird are replaced by virtual models. This allows system designers to use the concept of an Iron Bird in earlier development cycles, even when some physical components are not yet available. Extending this idea further along all phases of the life cycle leads to a complete digital model of the physical system, the Digital Twin.

The term Digital Twin was brought to the general public for the first time in NASA’s integrated technology roadmap under Technology Area 11: Modelling, Simulation, Information Technology and Processing [6]. In this report the future development direction of modelling and simulation was outlined:

A Digital Twin is an integrated multiphysics, multiscale simulation of a vehicle or system that uses the best available physical models, sensor updates, fleet history, etc., to mirror the life of its corresponding flying twin. The Digital Twin is ultra-realistic and may consider one or more important and interdependent vehicle systems, including propulsion/energy storage, avionics, life support, vehicle structure, thermal management/TPS, etc. Manufacturing anomalies that may affect the vehicle may also be explicitly considered.

In addition to the backbone of high-fidelity physical models, the Digital Twin integrates sensor data from the vehicle’s on-board Integrated Vehicle Health Management (IVHM) system, maintenance history and all available historical/fleet data obtained using data mining and text mining. By combining all of this information, the Digital Twin continuously forecasts the health of the vehicle/system, the remaining useful life and the probability of mission success. The systems on-board the Digital Twin are also capable of mitigating damage or degradation by recommending changes in mission profile to increase both the life span and the probability of mission success [6].

Along with NASA’s ideas, the US Air Force published similar ideas [7] establishing the Digital Twin is part of the USAF long-term vision addressing a time frame of the next 30 years. The general idea is that along with every plane a digital model is delivered, specific to the individual plane. Being “specific to the tail number”, this digital model includes all deviations from the nominal design. The digital model will also be flown virtually through the same flight profiles as recorded for the actual aircraft and the data will be provided by the structural health monitoring (SHM) system of the flying plane. Comparing actual sensor readings with modelling results at critical locations allows engineers to update, calibrate and validate the model. Changes in the plane configuration like unanticipated damage will be added to the digital model. The Digital Twin hence always represents the current state of the actual aircraft. The main application of this digital model is to determine when and where structural damage is likely to occur and thus to predict the optimal maintenance intervals.

The aspect of a seamless coverage of the life cycle with digital models is not mentioned in the above publications. The USAF also introduced the concept of a Digital Thread [8] for the acquisition of new material to focus on rapid fielding, the development, employment and integration of digital design tools across the acquisition life cycle. The Digital Thread is the creation and use of a digital surrogate of a material system that allows dynamic, real-time assessment of the system’s current and future capabilities to inform decisions in the Capability Planning and Analysis, Preliminary Design, Detailed Design, Manufacturing and Sustainment acquisition phases.

The digital surrogate is thus a physics-based technical description of the system resulting from the generation, management and application of data, models and information from authoritative sources across the system’s life cycle. A Digital Thread capability is enabled through technical advances in modelling, data storage and analytics, computation and networks. The Digital Thread concept creates informed decision making at key leverage points in the development process that have the largest impact on acquisition programs. This would lead to earlier identification and a broader range of feasible solutions; a structured assessment of cost, schedule, and performance risk and accelerated analysis, development, test, and operation.

Looking at the basic message of these descriptions, the definition of the Digital Twin and the Digital Thread are nearly the same, only differing in position during the life cycle. Both concepts make use of all available virtual models which are interconnected to provide the best possible information. Also, additional data either from live systems or from historic data are used. Whereas, the Digital Thread concept is used to support the acquisition phase, and implicitly the design of new aircraft, the Digital Twin should support its operation and service. However, as both concepts are based on the same idea using simulation models to predict the behaviour of the real system, in the following only the term Digital Twin will be used regardless of the life cycle phase where the concept is used.

5.4 The Digital Twin from the Simulation Viewpoint

The general vision of the Digital Twin refers to a comprehensive physical and functional description of a component, product or system, which includes more or less all information, which could be useful in later lifecycle phases. This is from a technical point of view not feasible. The data volume is too huge, diverse and totally unstructured. Furthermore, new applications in later phases require specific preparation of data and information in previous phases. A specific architecture of a Digital Twin is necessary.

Before we discuss this aspect, we will describe the Digital Twin vision from a simulation viewpoint. The Digital Twin refers to a description of a component, product or system by a set of well aligned executable models with the following characteristics:

  • The Digital Twin is the linked collection of the relevant digital artefacts including engineering data, operation data and behaviour descriptions via several simulation models. The simulation models making-up the Digital Twin are specific for their intended use and apply the suitable fidelity for the problem to be solved.

  • The Digital Twin evolves along with the real system along the whole life cycle and integrates the currently available knowledge about it.

  • The Digital Twin is not only used to describe the behaviour but also to derive solutions relevant for the real system, i.e. it provides functionalities for assist systems to optimize operation and service. Thus, the Digital Twin extends the concept of model-based systems engineeringFootnote 6 (MBSE) from engineering and manufacturing to the operation and service phases.

We will discuss four aspects of the Digital Twin.

  • Principle approach and benefit

  • Architecture of the Digital Twin

  • Lifecycle aspects

  • Digital Twin and value chains.

5.4.1 Principle Approach and Benefit

In Fig. 5.3 the principle approach of the Digital Twin is shown. Existing IT systems like PLM, PDM and SCADAFootnote 7 systems store and provide huge amounts of information coming from multiple authoring tools and sources, e.g. user requirements, CAD applications, operation data. The Digital Twin uses this digital information and makes it available as data and simulation models. Therefore, the Digital Twin includes the relevant data for processing phase-specific simulation tasks. In addition it contains just the essential information which is required for succeeding steps and phases. In this way the Digital Twin is smart, increases productivity and leads to new offerings during operation like assist systems and service applications. Furthermore, the Digital Twin can close the loop from operation and service back to design of new products or updated revisions.

Fig. 5.3
figure 3

The Digital Twin uses the essential information originating from different IT systems and makes it available for succeeding phases

Nevertheless, the Digital Twin is a highly dynamic concept growing in complexity along the life cycle based on the application of MBSE concepts. The Digital Twin is handed over with the product or even before. During operation it is the basis for simulation-driven assist systems as well as control and service decisions in combinations with smart data approaches. The concept of the Digital Twin is independent of manifestations or specific realizations.

5.4.2 Architecture of the Digital Twin

The goal of the Digital Twin is to prepare solutions for different but specific objectives and questions. These questions can arise in all lifecycle phases. For instance in the design phase, if the functionality of different components should be validated in a simulated interplay. However, the main benefit of the Digital Twin is expected in later phases. Therefore, the Digital Twin is a product feature, which is planned from the early stages. Also its primary use is defined and so limited to solve specific questions.

This requires that a Digital Twin architect describes the purpose(s) of the Digital Twin. Derived from this goal the tasks are defined, which are later executed to answer the questions. The final step is the specification of needed data and simulation models, which builds the architecture of the Digital Twin for a concrete application and set of purposes. A positive side effect of such a well defined Digital Twin structure is that in some cases new applications—which may not have been initially thought of—can be realized as well, based on the available (and persistent) information provided by the Digital Twin architecture.

However, the Digital Twin is still an abstract concept that allows a better component, product or system development. The underlying methodology is based on several aspects. The first is model based development. The information exchange is no longer focused on documents; instead models are used as a compact means to exchange information and interdependencies. Another important aspect of the methodology is the fact that models can be used in different situations as they are modular and have standardized interfaces (e.g. FMI [10]). A model management system keeps the single models up to date as changes occur. Also, the model management system supports the coexistence of different models with different fidelity and allows choosing the right model for the right application. Choosing the right model for a “good enough simulation” means that the model with that granularity is chosen, that is just fine enough to answer the design question, but not finer. Further, algorithms for the analysis of real-time and historical data are included as well.

5.4.3 Lifecycle Aspects

The relevant parts of the Digital Twin have to be designed in parallel with the development and physical realization of the observed system. As described above a Digital Twin simulation architect defines in the very beginning the structure and interfaces of all simulation models to be contained in the Digital Twin. This structure combines the single digital artefacts into a comprehensive functional and physical description. This structure is guided by the intended application fields for the Digital Twin. Only the relevant models are included and prepared, other digital artefacts are still contained in the existing IT systems like PLM. As the development continues the structure is filled with the real models and associated data. In the end the Digital Twin becomes part of the physical product. This procedure is enabled by a consequent use of MBSE techniques.

In this way the Digital Twin is part of the Digital World, see Fig. 5.4, and contains all information and models which are needed to solve tasks in later phases and to create new values, e.g. assistance systems for operators, user and maintenance personnel. The volume of the Digital Twin will increase during design and engineering phases. Depending on the specific component, product or system the transition to the operation or use phase can be realized in different ways. So it is possible, that not all data and models will be transferred. However, the collected and stored data in the Digital Twin will increase again during operation and service phases. A special feature of the Digital Twin is that some of its content will become part of the real system, for instance an executable simulation model as an assist system module of the automation software. Thus, the Digital Twin implements the link-up of parts of the digital world with the physical system.

Fig. 5.4
figure 4

Digital Twin evolves along phases and will be used as an integrated added value during operation and service

5.4.4 Digital Twin and Value Chains

We have already stated, that Digital Twins will be elaborated for—at least—components, products and systems. If we take a look to value chains, this means that Digital Twins will overlap in particular at specific points of different value chains. A good example is a production system. The equipment of a production system consists of different production units, which are products from other companies. Digital Twins of these products can be useful for the (virtual) commissioning of the productions system and also for the operation of the production system, e.g. for maintenance planning.

From a technical perspective Digital Twins have to skip borders of legal entities and in many cases to bridge between different proprietary data formats. Similar challenges and opportunities are visible on the production site. The producer needs parts and semifinished products and delivers his goods to customers, which use the product as end customer or for his production.

This leads to the consequence that the Digital Twin has to be modular. This modularity is used to transfer data and information into other Digital Twins. Especially in late phases (production, operation) where the Digital Twin has already gained lots of data lies the main application for the Digital Twins. For example, product design data can be used for service lifetime calculations and the product structure can be used to optimize the assembling in production either for the single components but also for large systems.

The same data and information structures can, in such an environment, exist in several models in parallel, as the modular structure of the partial models, is not always employed to the full extent. This has to be decided on a case by case situation. Each Digital Twin relates the essential part of the existing data and information (from existing IT systems) and makes them usable for its specific purpose.

5.5 Use of Digital Twin: Several Aspects During Life Cycle

In this section we show how the change from simple mechanical or mechatronic components towards mechatronic systems will occur, and how the comprehensive Digital Twin influences this transition. As an illustrating example, one can think of an electromotor as a mechatronic component and the combination of the motor, driving electronics and software as a mechatronic system.

In contrast to current development philosophies dominated by the engineering of details, in the future the system view and the interconnection between the different development phases will become more important. Simulation will become an important method for the whole life cycle.

5.5.1 Design Phase

During the concept design of the motor, a number of data and models are created which lay the foundation of the Digital Twin. The design is mainly determined by high-level requirements and experience with former developments. This information is used for a first abstract design mainly from a functional view of the motor. Here it is not yet decided, how the concept will be realized (e.g. in software or in hardware). In further detailing steps, based on the requirements or assumptions, the design is concretized. During all subsequent phases the current design has to be validated against the assumptions and requirements. One possible mean for validation is virtual prototypes, which mirror the current development state. As the development goes on, the virtual mirror image grows as well.

In the example of the electro-mechanic drive system, the basic requirements and the functional decomposition of the design can be modelled in a structured way using system description languages like SysML [11]. The dependencies and mutual interactions of the functions and requirements are shown, which helps designers to react quickly with a minimum of errors when requirements change. Many, if not all consequences of the changes can be identified before unnecessary detailing is done, especially if automated checking is implemented—which by the formal nature of the system description is possible even for large complex systems. In the further detailing of the design—when first decisions are made, by which the functions are realized, the virtual representation of the design also has to be detailed.

5.5.2 Engineering Phase

In the next development phase, additional engineering data including executable simulation models are created. As the engineering questions are now more specific, the simulation models also have to include further details. There may exist several different models for the same physical component, depending on the dedicated question they are created to solve. For successful engineering of complex systems, domain specific models have to be used together with extended system models, which include the functionality realized in software as well.

In the case of the motor system, many simulation models are created. There are mechanical models to examine the mechanical stability of the rotor or the motor mounting. Electrical models are used to calculate magnetic fields and the resulting forces. Thermal models calculate heat generation due to electrical losses. Other models describe the electrics and automation, and system models simulate the whole drivetrain including gears and bearings.

As the complexity of the objects to be designed increases and more and more disciplines and people are involved, the need for consistency among these models increases. In an ideal world all information should be stored in a unique place—not necessarily at the same physical location—to provide a consistent source and all models should also use this source for all input. This information includes not only the initial design parameters but also all models which are created during the development. However, this is often not possible for real systems. But at least a common awareness among all stakeholders of the development process about commonly used information is indispensable for a successful development of next generation mechatronic systems. The Digital Twin as a common repository for all digital artefacts supports this.

The latest phase of product engineering is the integration of the different components to the full system. Here it is necessary that all components fit seamlessly together. Usually the components are not ready at the same time or are not available for testing as it is, for example, with the environment where the product (electromotor) is finally installed. In this case, models from the Digital Twin can be used to replace physical components in the system integration test for example, as it is done with the Iron Bird.

Mounting difficulties when parts from external suppliers have to be integrated can easily detected in advance if a digital representation of the component is provided along (or in advance) with the physical part. Such a procedure is supported by dedicated light-weight formats (e.g. JT [12]), that reduce the exchanged information to the necessary amount. So the model from the supplier can be integrated into the model representation from the Digital Twin easily and checked for any inconsistencies. This procedure works not only for physical components. Software for automation can also be tested in advance using the virtual representation of the real system (i.e. virtual commissioning).

Even the final operating environment can be simulated by numerical models to have a realistic final test before the deployment of the final product.

5.5.3 Model Reuse for Operation

The main purpose of the Digital Twin for mechatronic systems is that the information created during design and engineering is also available and ready for evaluation during the operation of the system. This is nowadays often neglected, as design and operation are mainly disconnected life cycle phases from the point of data usage. An obvious example for model reuse is continuous product improvement, for example, if the intended use of the product changed and product modifications are necessary. In this case the existing models can be used and slightly modified.

On the other side, if data from operation are also collected systematically as part of the Digital Twin, they can be used to verify and update the existing models for real operation conditions such that the gained knowledge can be used for next generation of products as well. As the Digital Twin is already planned from the earliest time, the suitable interfaces to interact with real data are already in place. Thus, the real data can be used as verification input for the simulation models and lead to their continuous improvement.

Online condition monitoring is also a growing application field for the Digital Twin. For more and more mechatronic systems, sensors are installed to monitor the operation and give early warning of a malfunction [13]. However, only relying on sensor data is sometimes not sufficient. Especially, as particular values may not be accessible for a direct measurement. In this situation the simulation models from engineering, provided by the Digital Twin, can be reused after some modifications. The existing models have to be streamlined, to cope with the real-time data and new requirements from operation. Based on the real sensor data the simulation models extend the measurements towards a “soft sensor”, which can also acquire virtual sensor data, where real measurements are technically not possible.

By using the simulation models, it is also possible to interpret the measurements in a different way, rather than just detecting deviations from the norm. Several modes of failure can be simulated for the current situation trying to reproduce the actual measurement signals. The comparison of the simulated signals with measured ones can help to identify the failure mode.

5.5.4 Service Phase

As the Digital Twin provides a smart view on the available system information, models and results from earlier life cycle phases are accessible also for users of different disciplines.

During engineering the product has to be designed such that it can withstand a given load. The proof is done via simulations. However, additional information from the simulation can be deduced with little extra effort, like the expected lifetime of the part or how “well” the design criteria are fulfilled. Parts which fulfil these conditions only tightly are natural candidates as causes for malfunction. The availability of this information allows an improved and enhanced service process, as the most important (with highest likelihood needed) spare parts are already known in advance.

Together with data from online measuring, the simulation models and operation history provided by the Digital Twin are also the base for more flexible service planning. Depending on the actual load exposure, the lifetime budget of the relevant parts—accounted for in the Digital Twin—is deduced. Therefore, a comprehensive picture exists of the condition of the system which also eases the inspection planning and spare parts logistics even before a failure occurs.

5.6 Conclusion and Outlook

For mechatronic systems new and novel goals will emerge, e.g. as caused by cyber-physical systems. These are networked systems, which interact together, and realize new functionalities by cooperation. Aspects like autonomy will be important and software-driven configuration and use (digitalization aspects) will increase. Therefore, mechatronics will evolve further. Mechatronic products will gain a more complex structure and will have more computing power and network connectivity. This leads to the extended design challenges where simulation will be a key technology to master it. Simulation will not only become an essential part during the development of mechatronic systems but it will also become a part of the systems themselves as well. It will be applicable and executable during the operation of the mechatronic systems for operation support and new service applications.

The classical goals will still remain valid: time reduction (development time, time-to-market), adherence to quality and fulfilment of customer needs and requirements.

Realizing the simulation aspects of the Digital Twin is a key vision from our point of view to make significant steps forward to reach these goals. It is the smart way to gather and provide all information stored in existing IT systems which is essential for life cycle over spanning use. The benefit of the Digital Twin concept will be the improved consistency, a seamless development process and the possibility of reuse in later life cycle phases. Further, there is the increased potential for using the complete set of information in the development of next generation products.