# Implementation of a Digital Twin Starting with a Simulator

Léandre Guitard, Frédéric Noël, Daniel Brissaud

► To cite this version:

Léandre Guitard, Frédéric Noël, Daniel Brissaud. Implementation of a Digital Twin Starting with a Simulator. 17th IFIP International Conference on Product Lifecycle Management (PLM), Jul 2020, Rapperswil, Switzerland. pp.139-149, 10.1007/978-3-030-62807-9_12. hal-03140593

HAL Id: hal-03140593

https://hal.science/hal-03140593

Submitted on 22 Aug 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Implementation of a Digital Twin Starting with a Simulator

Léandre GUITARD¹*, Daniel BRISSAUD¹ and Frédéric NOËL¹

¹G-SCOP Grenoble INP 46 avenue Félix Viallet 38041 Grenoble Cedex 1, France
leandre.guitard@grenoble-inp.fr*, daniel.brissaud@grenoble-inp.fr, frederic.noel@grenoble-inp.fr

**Abstract.** The term complete Digital Twin describes a digital entity following and taking part in the life of a system, from its design during its regular use, up until its end of life. It is a coherent set of interoperable modules that will be used depending on the state of progress of the system. Since the Digital Twin follows the system from its design to its end of life, it can be a powerful lifecycle management tool.

In this framework, it seems too complicated to try integrating all the modules simultaneously. It's important to prioritize them and build an expandable architecture. One of the major criterion is ensuring the digital continuity in order to implement a sustainable model for the Industry 4.0.

The modules used after-sales, such as the predictive maintenance module, are harder to implement, because the connection/communication with the system after delivery must be managed which is not always possible. Therefore, the modules that are the easiest to implement are the ones before-sales, because they are integrally managed internally.

This study is conducted in a medium size enterprise which allows us to address in a concrete way the deployment of a digital twin in the industrial activities. The deployment strategy needs to be combined in order to prevent the features of the digital twin to be perceived as a hindrance. This study focuses on the development of a simulator that will link up offer design, detailed design and assembly/manufacturing follow up.

**Keywords:** Digital twin, Product lifecycle, Cyber-physical systems.

# 1 Digital Twins in the Literature

## 1.1 State of the Art

With the new technologies that Industry of the future offers us, there is a new tool that we can use to improve our systems; the Digital twin. Even if the wording is relatively recent [1] The concept was first introduced by Dr Grieves in 2005 under the term “Ideal Concept For PLM” [2] where it is described as consisting of three elements; “real space, virtual space(s) and a liking mechanism”. Later, the term used to describe this concept became “Mirror Spaces” in 2011 [3] until Dr. Grieves himself adopted the terminology of “Digital Twin” in 2014 [4] where the concept stayed the
same, based around the same three elements. NASA used a similar concept for their Apollo 13 mission [5] where the principle was to build an exact replica of the system to allow diagnosis and scenario testing without the consequences of the real environment. The US Air Force Also worked on the subject of a Digital Twin, by applying it to their aircrafts; the concept goes further in terms of precision, going down to the microstructure of the materials used to build the aircrafts [6]

Since the concept was introduced and developed for NASA and the US Air Force, the Digital Twin has been spreading to numerous other industrial fields such as the manufacturing of civilian ships [7]

In parallel, in 2006 the concept of a product avatar was also mentioned [8]. The concept came from the fact that there was no centralized data relating to a specific product thus making it increasingly complicated when another entity was added to the product's life-cycle. The paper suggested a centralized database relating to each specific product which is very close to the concept of a digital twin as we consider it in this article.

The term Digital Twin is now the one that is used by both, academics and in the industrial sector. The Digital Twin is considered as a virtual model of a physical system, but contrary to a Digital Mockup (Apollo 13 model), the connection with its physical counterpart is much more predominant and crucial.

Out of all these concepts and definitions, the choice relies on the context, in the context of an industrial transfert system, it is not relevant to go down to the micro-structure of the aluminum profiles used to build it, but the general concept of the real space, virtual space and a liking mechanism is the foundation upon which to build the structure of a Digital Twin in order to develop and apply it in a real industrial context.

The goal of this study is to validate what an industrial company wants from a Digital Twin, and then suggest and implement a method by which to develop and integrate a Digital Twin to their products.

## 1.2 Determining Elements

The Digital Twin may be seen as an intelligent database that helps the user to make decisions or directly manages the system it mirrors. The virtual space described by Dr. Grieves is a series of models describing the real world, the corollary to that is that the dimensions of the Digital Twin are defined by two elements; the precision of the models that are attached and if they allow analysis and its connection with its physical brother. We can represent those two factors in a chart:
<table><caption>**Table 1.** Classification of Digital Twins</caption><thead><tr><th>Connectivity</th><th></th><th></th></tr></thead><tbody><tr><td>Precision</td><td>No connection to field data</td><td>Field data available</td></tr><tr><td>The models aren't precise enough to make reliable analysis</td><td>NA / Not a Digital Twin</td><td>Supervision</td></tr><tr><td>The models allow for reliable analysis and projections</td><td>Apollo 13 like model</td><td>Complete Digital Twin</td></tr></tbody></table>

Deriving of that, there are three defining elements:

- **Field data**; they show the current state of the system, how it's evolving, up to in what environment it's evolving (speed, part's temperature, environment's temperature, power consumption, vibration,...) these are the data that will be run through the models to predict and project situations.

- **Configuration data**; they show the structure, the configuration, the program version, all the data that is relevant to show **what** the system **is**. It's on those data that the models will be based, if they aren't precise or reliable, the models won't be either.

- **Models** derived from the configuration data, that puts into equations the behavior of the system in order to analyze real time data and predict outcomes.

## 1.3 Definition of a Complete Digital Twin

In a more tangible way, a functional industrial complete Digital Twin is a set of coherently organized modules, each containing the models and configuration data necessary to address the chosen function. Those modules are made accessible through an interface that can vary depending on the stage at which the system is, that during the normal use of the system is also capable of giving an overview of the system and that is available throughout the life of the system from the first design steps to when parts are reused for other systems (from cradle to cradle).

Fig. 1 describes the way this Digital Twin is organized and how it interacts with the user and the physical system.
<figure><img src="image_3.png" /><figcaption>Fig.1 synoptic of the Digital Twin</figcaption></figure>

The user will set some values or feed the digital twin with parameters or scenarios via the interface. The interface will then interpret those inputs and send them to the appropriate modules. The modules will process the data and using the field data as well, construct the desired indicators, as well as participate in building the database representing the physical system; the heart of the digital twin.

Once the modules have the indicators, they will be able to send commands to the physical system to adapt its operation. They will also send back to the interface, the relevant indicators and visual cues to tell the user know the conclusions and either suggest actions or show the automated actions that have been taken.

The question that arises now is: how to develop and implement a Digital Twin in a real industrial context?

## 2 Industrial Context

The company in which this study is conducted is a group called Hellomoov' where these concepts are applied to integrate a digital twin to the product
## 2.1 Administrative Description of the Company

Hellomoov' is a French group dedicated to the support of the industry. It has 3 main components; Transept in vendee, Faber in the Ardennes and Elcom in Isère that all together represents around 250 employees. The group has 2 main activities; aluminum profiles and static structures made from them and in-house logistics systems. From conveyors to more complex transfert systems, as shown in Fig.2

<figure><img src="image_4.png" /><figcaption>Fig. 2 A transfert system</figcaption></figure>

There is another office in Isère called Hellomoov' Institute, where the R&D is conducted for the whole group. They oversee the development of new products, new systems by considering innovations and new technologies, for example all the innovations of Industry 4.0. The Institute launched a project that aims at integrating industry 4.0 to in-house logistics; Moovitique®.

Moovitique® "It's the conveying, the transfert and the handling of object, products and containers profiting of all the digital disruption advances, the connected objects and the smart mechatronic applications. This new high stakes discipline will allow to open a whole new field to optimize production lines, conditioning lines in today's and tomorrow"

The Digital Twin integration of the current study must answer this vision.

## 2.2 Specificities of the Transfert Activity

Our main job today for transfert systems, is to deliver functioning systems that will be able to handle objects and products throughout the factory. Once the systems are delivered, we intervene in case of malfunctions or for regular maintenance. But between maintenance operations, we have almost no contact with the clients or our systems. Besides that, there are other specificities to this type of activity:

The transfert systems are sub-systems of special purpose machines; machines that cannot be standardized, some functions can be, but every project is a new development in a way, which means gain in the design process would be a big gain.
Elcom/Hellomoov' is a supplier of the special purpose machine sector, therefor we are not the first contact with the final customer, which leads to a delay in information and reduces the time that we have.

Elcom/Hellomoov's part in the special purpose machine is to move the client's product along the manufacturing line, but it does not directly bring any added value to the product and therefor have more difficulties convincing the customer to invest in the transfert system.

Those factors are part of the reason why we engaged in the Moovitique® initiative; by that we seek to add functions to our systems that will be able to bring added value to our customers' products and by that we hope to grow in the value chain.

Elcom/Hellomoov' is a rather small company, it works mainly because the product is good and they master it really well, they have a practical and empirical knowledge of their systems, it is highly relying on the knowledge of people that have been in the company for a long time. That can have some impact on assembly quality for new employee that don't have the product background.

## 2.3 The Digital Twin of a Transfert Product

The Digital Twin is a general concept, it needs to be adapted and applied to the desired technical context, in this case, how to integrate it to Hellomoov's transfert systems.

For this application, there are a series of modules, whit each their specific functions, needing their own models, and data. Also keeping in mind that the Digital Twin needs to follow the digital continuity as a part of Industry 4.0. Every module needs to be able to communicate with rest of the digital environment of the Digital Twin.

The proposed modules are the following:

**The design Assistance** is the module that seeks to help design a transfert solution. There can be multiple levels of assistance, from designing with a configurator to self-generating algorithms, or from designing a single unit to a complete solution.

**The Simulator** insures the design is able to meet the requirements. After transferring the data from the design assistant, the simulator is capable of generating a 3D model of that design, and based on a data base of behavior models for each parts of the system, the simulator is then capable of displaying the motion of the relevant parts and generating a summary of the KPIs to validate the design that was proposed. Once the simulation confirms that the design is good, it can communicate with the ERP system to generate a bill of material, an order, ...

**The Assembly/Manufacturing Assistance** is the tool that based on the design, on the types of attachments is able to generate each parts and what operation they require
(cutting, drilling,...) as well as propose an order of assembly to help the technicians build the system; based on the bill of material, it can generate an animated 3D representation of the steps to manufacture an assemble the parts. Projected in Augmented reality glasses, it allows to technician to work while keeping in view the steps and how to perform them.

**An Industrial Control System;** since the Digital Twin is connected with field data from its physical twin, it also allows the monitoring of the system, to be able to know what is the current state of it, and other relevant parameters; such as, the temperature, the speed, the power consumption, ... And that even on the other side of the Earth.

**The predictive Maintenance Module** can, using sensor that are used for process and others specifically designed for maintenance, record, interpret weak signals and generate from them, failure models in order to predict and communicate on what part is going to fail and estimate the time that is left before failure. That will allow the users to anticipate maintenance in order to limit the consequences on production.

**The Maintenance Assistance Module** will similarly to the assembly/manufacturing assistance module, use assembly models and help the technician replace the required parts by showing him the easiest way to access them and what procedures to use through Augmented reality glasses

**The Reconfiguration Assistance** will be able to propose, based on the evolving needs of the user as well as the modularity of the product, an optimized redesign of the system, based not on the theoretical needs of the user, but on the recorded use of the current system.

**The End of Life Estimation module** will estimate the cumulative cost of foreseen maintenance, based on the predictive maintenance module and price data, and compare it with new systems in order to recommend keeping maintaining or to revamp or replace the system

**The Reuse Module** is corollary to the end of life module, once the system is set to be replaced, some parts might be considered not reusable, but for the others, this module will take them into account and targets to reuse them and optimize the design using them as much as possible

**Interfaces** that will regroup the most important data. These modules will be made accessible through multiple interfaces. The differences between interfaces will depend on their use, but regardless of the interface, they will all have the same goal; make the relevant models accessible, display a summary of the relevant data at the specific time and place for the specific system.
## 2.4 Integration and Perspectives

As we can see, the Digital Twin is major tool in the development and life of a system, it can bring numerous benefits, but it also is a complex system, with complex models describing almost everything about the system, which makes it complicated to implement.

As said previously, the company Elcom/Hellomoov' is a rather small company and has a mostly empirical management system, based on the experience of people that works there. The development of such a tool all at once represents a big task and a big paradigm shift that in the structure like this one seems risky. Whereas developing it step by step, function by function will allow to demonstrate the pertinence and the value of each module progressively.

After discussing the advantages and risks of both solutions, the company chose the ramp up approach.

In order to succeed in the deployment of a digital twin, there are global aspects that need to be addressed:

- A digital twin like this generates a lot of data coming from the physical system, all the field data collected can represent an important amount storage. A single source would not necessarily represent an important volume on its own, but multiplied by the number of potential sources on a transfert system, then further multiplied by the number of systems of each of the users will be [9]. The two solutions would be either buying or renting servers or store those data on a cloud. As of today, no decision has been taking yet by the company.

- The models used represents the real added value of a digital, they will help design, operate, integrate weak signals and in general operate the system. The qualifications needed to develop these models and algorithms are crucial and Elcom/Hellomoov' doesn't have them in-house as of today. It is crucial to define the working framework in order to develop them. Define if they will be developed in-house after recruiting or work with a subcontractor/partner. If the models are developed with a subcontractor/partner, it is important to define who will have the ownership of the models.

- Whether it is the models and algorithms or the field data from the client, those pieces of information are sensitive. They could be used in malicious ways and therefor need to be protected. The two main ways to protect them is either by isolating the networks or by encrypting the data flow. As of today the decision has not been taken on which option is chosen, based on the efficiency, the cost and the relevance.

As for a module, the simulator seems to be the ideal starting point because it's a module that can completely stand alone; since to start out with, it can run without any real time data, it is an element that can evolve tremendously; from only validating the design before manufacturing to potentially managing the actual line during its life (based on the ERP data regarding the placed orders and running multiple scenarios and selecting the most optimized: production order sequencing).
Furthermore, the simulator can also have benefits, both in-house and commercially, without the need to modify our products or connect them with IOT systems that can be seen as intrusive to the industrial user. The initial simulation can represent a gain by reducing the number of design iterations in-house and at the same time be used as a commercial tool for the client by visually representing the motion and the workflow of the line.

# 3 Focus on the Simulator

## 3.1 Expectations and Requirements

As said previously, the simulator validates the design of a transfert solution, the main target is to verify the flow, making sure that the mobiles don't stay blocked in a particular place, that they are able to complete the cycle in the desired time, that all the station have a sufficient activity, ... That would be a potential gain in conception time, by reducing the numbers of design iterations.

In order to obtain that goal the simulator requires a model for each of the elements of a transfert system (mobiles, units, simple cams, diversions, double cams, stoppers, ...) with a precision sufficient to analyze predict and thus validate that the system achieves the target.

The first step was to define the requirements specifications in order to see if a commercial solution was available or not.

The simulator on its own needed to allow a client or an in-house technician to design a transfert line and simulate the flow of mobiles in order to validate that the line could answer the need of the client. For that there are a few relevant indicators:

- Highest cycle time: highest time a mobile took to come back to its original position

- Average cycle time: the average of all the mobiles' cycle times

- Longest idle time for a mobile: the longest a mobile didn't move out of a workstation

- Average idle time for a mobile: the average of all the mobiles' idle times

- Longest idle time for a station (workstation and stoppers): the longest a station waited without a mobile to work on, including when a mobile was at the station but the work was done and the mobile couldn't leave

- Average idle time for a station: the average of the stations' idle times

But as a part of the Digital Twin, in the context of Industry 4.0 and digital continuity, the simulator also needs to be able to communicate and interact with other modules and databases representing the physical system thus excluding all commercial solutions that were found during the research; software like Arena Simulation or Visual Components are meant to simulate the flow but as a stand-alone solution, their
connectivity or integrability did not meet the requirements. It was consequently decided to develop an in-house simulator.

The company wanted a development solution that would allow them to retain control over the simulator, therefor an open-source development software was the optimal solution. Godot is open-source development software meant for videogames; it is on that software that the simulator was programmed.

## 3.2 Architecture and Development

<figure><img src="image_5.png" /><figcaption>Fig. 3 detailed synoptic of the simulator</figcaption></figure>

The simulator has two external sources of information, the user via the interface and the physical system and its environment. The main data coming from the user are the configuration (which elements and where they are) and the flow data (how long does a mobile need the stay at each stopping points). From the physical system, the simulator uses order data to simulate multiple scenarios and define the most effective way to schedule the production. The simulator can also use vibration data to gage the health status of the system's bearings and favor (if possible) a section over another.

The simulator uses those pieces of information and combines them with two databases; A behavior database, that holds the scripts that describe the way each individual transfert elements behaves and a 3D model database that holds a visual representa-
tion of all of these elements. Using the correct user parameters with the correct behav-
ior model and 3D representation, the simulator generates the desired element. After
repeating this process for each element of the system, the simulator uses interaction
models to describe how all these elements interact. At this point, the user can play the
simulation and the simulator will display the movements of the mobiles, and the key
indicators.

The behavior models in the database need to be accurate enough. There is a first threshold that represents the minimum accuracy needed to simulate, then, the more accurate they are the least errors there will be and the further in time they will be able to predict satisfactorily. Once the models are recorded in the simulator, and because in the first use the simulator is before the manufacture of the system, there are no field data, the data that is key is the configuration data; the architecture of the system that is up for testing.

Once the simulation has run, what we seek from it is to be able to confirm that the
architecture of the system meets the needs of the client, which in turn means that the
total cycle time is conform, that the number of mobiles allows the system to work
properly and that the system in general is used properly. That comes down to the Key
Performance Indicators mentioned previously.

Fig. 4 is a display of what the user sees when he uses the simulator. The red boxes
are the mobiles and the white squares are stopping points.

<figure><img src="image_6.png" /><figcaption>Fig. 4. Rendering of a simulation of a transfert system</figcaption></figure>
# 4 Conclusion and Perspectives

The perspective is to propose a complete methodology to deploy the digital twin concepts in an SME. Hellomoov's use case will be a validation experience for such a methodology.

For a medium size company, a ramp phase is crucial in order to ensure that the Digital Twin will be accepted and used. At Hellomoov', the choice for the first module to be developed fell on the simulator. It has the advantages to be able to grow relatively easily, it's a module that can stand on its own and it can be a base for a visual representation of the physical twin from the start to the end of the life of the product.

The next step in the development of the Digital Twin in a company is to apply it to a client system use case and make it evolve from there, adapting it along the way. A system that is relatively classic, so that it would represent well what will happen in the future, would be ideal, with a client that we know well in order to ensure a good and easy communication.

But in order to get a complete Digital Twin, it is important not to forget the critical issues that must be overcome; how do to protect the critical data, how to manage the storage of the important mass of data that will be generated by the twins and defining the framework of the interaction and the work with the subcontractor regarding the models that will be at the core of the Digital Twin.

# 5 References

1. Glaessgen EH, Stargel DS (2012) The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles. Proceedings of the 53rd AIAA Structures, Structural Dynamics and Materials Conference 2012, Paper no. 1818.

2. Grieves, M.W.: Product lifecycle management: the new paradigm for enterprises. International Journal of Product Development 2(1-2), 71{84 (2005)

3. Grieves, M.: Virtually perfect: Driving innovative and lean products through product lifecycle management. Space Coast Press (2011)

4. Grieves, M.: Digital twin: manufacturing excellence through virtual factory replication. White paper 1, 1{7 (2014)

5. Goodman, J. (2009). *Apollo 13 Guidance, Navigation, and Control Challenges. AIAA SPACE 2009 Conference & Exposition*. doi:10.2514/6.2009-6455

6. Tuegel, E. J., Ingraffea, A. R., Eason, T. G., & Spottswood, S. M. (2011). Reengineering aircraft structural life prediction using a digital twin. *International Journal of Aerospace Engineering*. https://doi.org/10.1155/2011/154798
7. The future reality of the digital twin as a cross-enterprise marine asset Morais D Goulanian G Danese N RINA, Royal Institution of Naval Architects - 19th International Conference on Computer Applications in Shipbuilding, ICCAS 2019

8. Hribernik, K. A., Rabe, L., Thoben, K. D., & Schumacher, J. (2006). The product avatar as a product-instance-centric information management concept. International Journal of Product Lifecycle Management, 1(4), 367–379.
https://doi.org/10.1504/IJPLM.2006.011055

9. Tao, F., Zhang, H., Liu, A., & Nee, A. Y. C. (2019). Digital Twin in Industry: State-of-the-Art. *IEEE Transactions on Industrial Informatics*, 15(4), 2405–2415.
https://doi.org/10.1109/TII.2018.2873186