# The Transformation Towards Smart(er) Factories:
## Integration Requirements of the Digital Twin

S. Waschull, J. C. Wortmann, J. Bokhorst

► To cite this version:

S. Waschull, J. C. Wortmann, J. Bokhorst. The Transformation Towards Smart(er) Factories: Integration Requirements of the Digital Twin. IFIP International Conference on Advances in Production Management Systems (APMS), Aug 2020, Novi Sad, Serbia. pp.187-194, 10.1007/978-3-030-57993-7_22. hal-03630929

HAL Id: hal-03630929

https://inria.hal.science/hal-03630929

Submitted on 5 Apr 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
# The transformation towards smart(er) factories: integration requirements of the digital twin

S. Waschull[0000-0001-8156-7073], J.C. Wortmann[0000-0002-8138-6931], J.A.C. Bokhorst[0000-0002-2420-6236]

University of Groningen, PO Box 800, 9700 AV Groningen, The Netherlands
s.waschull@rug.nl

**Abstract.** The vision of the smart factory with its interconnected systems is based on the seamless (real-time) integration of data across the information system (IS) landscape. Yet, due to the existence of many legacy systems, this task is far from trivial. In industrial practice, the IS landscape comprises systems of different application functionality which can be characterized as technologically heterogeneous, e.g. transaction processing versus real-time systems. Integrating such systems has always been a major challenge and constraining force for many organizations. This problem is receiving renewed attention in the context of the implementation of the digital twin in manufacturing. Due to its central role in the IS landscape, the digital twin needs to communicate with a number of heterogeneous applications to achieve its full potential, i.e. achieving a complete virtual representation of an asset, process or product. This research analyses the integration requirements from the perspective of the digital twins' application functionality. In particular, we provide an explicit mapping of the integrations needed between the digital twin and existing information systems (IS) in manufacturing, which serves as a basis to better understand integration issues. These findings provide an explanation for and a conceptualization of some of the challenges that emerge when transforming towards an interconnected smart factory.

**Keywords:** digital twin, integration requirements, smart factory, application functionality, information systems

## 1 Introduction

The application of digital twins (DT) in manufacturing presumably leads to better information transparency, which results in better planning, better quality control and improved productivity [1, 2]. The DT is the virtual and computerized counterpart of a physical system (a machine, a product or a whole process). It takes advantage of the real-time synchronization between the virtual and real system, enabled by sensed data and connected smart devices, mathematical models and real time data elaboration [3]. To achieve its full potential, the DT needs to take on a central role in the information system (IS) landscape at companies, yet its integration is certainly not an easy task. It therefore represents a constraining force for many organizations in their quest towards smart factories. New manufacturing systems are rarely planned on a green-field [4].
This means that in industrial practice, DT usually need to be integrated in existing
production system architectures to achieve a complete virtual and accurate
representation of the asset, process or product. Such architectures comprise various
different types of applications, distinguished by the functionality they exhibit (e.g.
transaction processing), the underlying technology (e.g. hardware and software), data
formats and addressing different time horizons (seconds versus weeks) [5]. As a result,
different types of integrations are presumably required in the context of the DT. For
example, integrations between real-time applications and transactional applications are
usually completely different from integrations between professional applications, e.g.
between different reporting systems. To understand the integration problem in light of
the DT better as a whole, and to synthesize the literature primarily addressing single
types of integration, in this research we assess different types of integration
systematically from the perspective of the application functionality of an information
system landscape. We first characterize the application functionality of the components
of the DT, thereby restricting ourselves to the DT of products or machines. We then
explicitly map the types of integration required between the components of the DT with
other information systems. The next section provides the theory, followed by the
identification of the data and integration requirements between the digital twin and
other IS (section 3). Section 4 concludes the research.

## 2 Theory

### 2.1 Concept of the Digital Twin

In the context of smart factories, the convergence of the physical world and the cyber
world, as promoted in the Cyber-Physical Systems (CPS) concept, is achieved with the
DT [6]. In most definitions, DT refer to virtual models or representations of the physical
object or the system [7], which can be a product, machine, or even a whole process or
system. Various purposes have been identified for DT, for example decision support,
simulation, prediction and optimization [3], applied in different disciplines, e.g.
production planning & control [2]. Since the data of the DT are not only from the
physical world but also from virtual models, it enables the fusion of data from both
worlds [8].

The DT consists of three components that are relevant to identify in this research, as proposed by [4]. First, the digital shadow is the actual data profile that couples with the corresponding physical entity throughout its lifecycle, a structured collection of data generated by operation and condition data, process data, etc. [9]. Second, there is the unique instance of the digital master model of a physical object, e.g. CAD or CAE models, that represent the physical description of the objects as designed, i.e. a set of linked data records [10]. Third, the DT contains the simulation, modeling and analytics part (algorithms, simulation models, correlations), linking the digital master and shadow, and generating meaningful information for various purposes. The models in the analytics and simulation part of the DT, from its individual models to the order structure of the entire production system, may be kept up-to-date by the information in the digital shadows.
## 2.2 Types of Applications in the IS Landscape

[5] characterized and distinguished information systems in manufacturing according to the application functionality, i.e. the main purpose of an application. In turn, each type of application is then characterized by the specific types of enabling technologies, viz. Software Technology, User-interaction (UI) Technology, Database Technology, etc. The following information systems are distinguished: (a) Systems based on workflow functionality (i.e. workflow-oriented systems) are aware of the sequential structure of a process and the role of actors in executing the processes. They assign and monitor the execution of tasks, while providing access and necessary resources to actors. (b) Transaction processing systems maintain actual states of objects which are relevant for an organization. This transactional data is stored in records centrally in relational databases which is shared among departments and systems, usually by standard software packages labeled as enterprise resource planning systems. (c) Interactive planning systems and (d) analytical systems both provide decision-support, yet they use different algorithms and underlying database technology to achieve their aim. Planning systems usually take a snapshot of objects' states from transactional systems before they start their calculations, whereas analytical systems maintain a series of snapshots in a so-called cube. Both types extract, transform and load (ETL) data from transactional systems. However analytical systems use varying sources to produce aggregated reports but also graphical presentations to users via customized visual user interfaces. (e) A different type of applications are document management systems, such as PDM/EDM systems, which manage and integrate complex product engineering data that originates from working with computer-aided-engineering (CAE) systems. Finally, (f) real-time systems on the shop-floor monitor and control different production parameters and variables in real-time, and conduct real-time manipulation of selected production variables through actuators, if necessary.

## 2.3 Types of Integration between IS

The exchange of information between different types of systems as classified in the previous section usually requires different types of integration concerning interface development and the development of communication mechanisms. The most common form of integration is data-oriented integration, distinguished into message-oriented integration, and integration based on data sharing [11]. The former can be achieved through various forms, e.g. point-to-point versus bus architectures, each with different triggering mechanisms (push vs. pull, clock- or event-driven) and nature of messages (complete files vs. structured XML messages). Data sharing is based on the development of a unified representation of all data in the enterprise, in which applications exchange information via the shared data schema.

A second form of integration is software-oriented integration on the application level, usually taking the form of a remote procedure call (RPC) for the app being called and the form of an application programming interface (API) for the calling application. An RPC refers to the fact that the app which is being called can be re-used. A typical
example is the reuse of a scheduling algorithm or a simulation program. A completely different example is a call to retrieve data from a transactional system via the business logic of that system. A special case of this is a web service, which is an RPC which follows certain standards.

A third form of integration is workflow-oriented integration between workflow functionality on the one hand and transactional, document management, or decisional systems on the other hand. In essence, workflow systems manage the flow of work of a business process [12]. The flow of work consists of activities (or tasks) which can either be a transaction in a session of a transactional system, an update of a document in a document management system (following the check-out and check-in rules and of a vault and the impact analysis of related documents) or a decision in a decisional system. Workflow functionality may be encountered in WfM software, but also in PDM software or on top of transactional software. It enables the (trans)actions needed, it has to be informed about the (trans)actions performed and it informs users that certain tasks are pending, waiting for their action.

Finally, real-time to transactional integration is relevant to mention in this context. The physical asset (either a tool or machine, or a product that is being manufactured) belongs to the real-time world. The transactional system belongs to the information world and is not necessarily strict real-time. Such integrations are in general characterized by sensors producing streaming data with high frequency (e.g. every millisecond), the need to transform these data into meaningful transactions and the choice to transform either at the source (physical asset) or at the target (the transactional part of the digital shadow), or somewhere in between. The transformations are either samples or averages, which lead to transactions. E.g. a temperature measurement is sampled every hour followed by an update in a transactional system, or rates that are summarized over time lead to a periodic volume of liquid or gas which has passed a particular gateway.

The majority of the literature on integration focuses on a specific type of integration in the context of an application functionality, e.g. data integration in the context of ERP and MES (i.e. data integration in transactional systems) [13], or integration between document management systems [14]. We currently lack a systematic analysis of integrations from the perspective of the underlying technology of the applications. We study this in the context of the DT in the next section.

# 3 Digital Twin – Data and Integration Requirements

## 3.1 Application Types within the Digital Twin

To better understand the types of integration required between the components of the DT and other IS, we first need to characterize the DT in terms of its own application functionality. To do so, we distinguish the digital master, the digital shadow and the simulation & analytics part, each with their individual purpose and data requirements: (1) The digital master is a document-oriented application. The digital master of a machine or tool consists of CAE models of the machine or tool, but also of maintenance guides, operating procedures, etcetera. The digital master of a product to be
manufactured consists of CAE models of the product, and also of manufacturing instructions on how to perform the manufacturing operations needed. These instructions may also refer to measurements and checks to be performed during manufacturing.

(2) The digital shadow has both a *document part* and a *transactional part*. The document part of the digital shadow is derived from the digital master, but now populated with the specific data for the specific asset involved. The transactional part describes the status changes of the physical asset. The digital shadow of a machine or tool consists in its document part of 3D models, maintenance guides, operating procedures, etcetera, for this specific machine or tool as far as these deviate from the digital master. It may have 'as built' documentation in contrast to 'as designed', it may have amendments to operating procedures and maintenance guidelines, and so on. It may use the documents of the digital master, as long as these are fully applicable to the asset concerned. The transactional part describes the status of the tool or machine in terms of number of hours in operation, need for change-overs, cleaning, small or large maintenance, etc. The digital shadow of a product to be manufactured consists in its *document part* mainly of the notes and remarks made during manufacturing, sometimes including non-conformance reports, repair instructions, pictures and videos, etc. The *transactional part* describes the status of the product being manufactured, in terms of actions performed and measurement values obtained.

(3) The simulation and analytics part of the digital twin are *professional* applications, comparable to advanced planning applications and analytical applications respectively, depending on the objective of the data analysis. For example, a program may relate the settings of earlier production parameters (temperature, pressure) on later tolerances achieved in a type of product. This can be based on a data warehouse with past measurements.

## 3.2 Integration Requirements between the Digital Twin and other IS

Next, we describe the types of integrations needed between the components of the DT (i.e. digital shadow, digital master and analytics & simulation part) and other types of applications usually found in the IS landscape of manufacturing organizations.

### *Integration from the physical asset (real-time systems) to the digital shadow*

The physical asset (either a tool, a machine, or a product which is being manufactured) belongs to the real-time world as outlined in section 2.2, with sensors producing streaming data with high frequency. The real-time data is critical to enable the accurate representation of a DT. Real-time data needs to be transformed into transactional data serving as input for the digital shadow, e.g. temperature measurement every hour, or rates which are summarized over time.

### *Integration from transactional systems to the digital shadow*

To create and update the DT, various data from legacy transaction processing systems must be downloaded to the digital shadow, e.g. the product type, quantity, specifications or routing. The data are on the one hand stored in the ERP system, such
as Bills-of-Material (BoMs) and operations (routings), but also releases of production orders. On the other hand, it includes data from quality management systems, specifying required measurements and controls required during manufacturing. Upon the release of an order to the shop floor, the data should be pushed from the transactional systems to the digital shadow. These integrations are usually one-way and can be achieved via event-driven data movement, using messages, and be supported by workflow-oriented integration.

*Integration from the digital shadow to the transaction processing system*

The digital shadow is required to regularly update relevant transactional systems. Examples can be given for an ERP system or a quality management system. The former shall be informed about e.g. materials used, hours spent on operations and on order progress, whereas the latter is interested in e.g. measurements, quality registrations, possible non-conformance reports or conducted repairs. This is achieved through a one-way integration between the transaction-processing databases of the digital shadow with the other systems' databases. The relevant data can be pushed, or pulled based on some pre-defined trigger, e.g. an event or a specific time interval. Events would have to be predefined in the process digital shadow, which could be, for example, the occurrence of a reject.

*Integration from document management systems to the digital master*

In this integration we assume that the digital master is implemented as a separate system, which means that the relevant documents need to be downloaded from their source. These systems are usually CAE systems linked to PDM systems, i.e. product development or work preparations systems used by manufacturing engineers. The digital master must be provided with means to read and display these documents. This can be achieved by a call to the original software, if such a call is enabled by a SaaS architecture, or the handling software can be made available at the digital twin platform.

*Integration from the digital twin (analytics & simulation part) to the physical asset*

A key characteristic of the digital twin is that a change in the state of the digital object also triggers a change in the state of the physical object and vice versa, yet in practice automating this is far from trivial. Its success heavily depends on the digitization of the process steps and the machines. The machine would need to be programmed in such way that it understands the message of the analytical application and is able to changes settings automatically based on a message. This solution would require customization, since different machines often are based on different technology and are controlled by different control systems. Also, contractual and legal restrictions should be taken into account when deciding whether this is an option. Therefore, in practice this integration would most likely be achieved manually by humans. Via the dashboard of the analytics software, feedback can be given to the operator at the machine, e.g. an alert to an operator or technical service when analytics software predicts a break down based on (transactional records of) sensor data.
In Figure 1, the described data flows and required integrations within the DT, and between the DT and other IS, are illustrated.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Integration requirements of the DT in an IS landscape [15]</figcaption></figure>

## 4 Conclusion

Considering that organizations want to protect their investment in existing legacy systems, a critical problem faced at the IT level is the integration of legacy systems with the components of the DT. In that light, a number of questions emerge and whose answer have a great impact upon technological features (e.g. databases, system architectures). For example, questions are related to the position of the data, the synchronization of systems (e.g. what triggers the creation of the DT) or the location of procedures (e.g. use DT optimization engines or legacy analytical systems). To increase our understanding, this paper contributes by systematically analyzing different types of integrations based on the intrinsic technological differences of the application. We studied the digital twin due its central position in the IS architecture, allowing us to assimilate and analyze different types of integrations required in this context. Therefore, we characterized the DT, and its individual components (i.e. digital shadow, digital master and analytics & simulations part) in terms of their main purpose (i.e. application functionality). For example, transaction processing functionality in the digital shadow is needed to describe and record the status changes in the physical object, document management functionality in the digital master enables the access to as-
designed document of the physical system, or functionality similar to analytical systems
is needed for optimization purposes. Due to differences in e.g. data formats, time
horizons (frequencies), or the type of analysis, integrations can become difficult on the
technological level. To further explore these technological issues, but also managerial
issues related to such integrations (e.g. allocation of various functions to different
systems and avoidance of redundancy), future research should be conducted to explore
the individual integrations in-depth, and in practice. The exploration of different use
cases for the digital twin and the impact on its integration with legacy systems is also
an interesting line of research to pursue.

5 References

1. Uhlemann THJ, Lehmann C, Steinhilper R (2017) The Digital Twin: Realizing the Cyber-Physical Production System for Industry 4.0. Procedia CIRP 61:335-340.

2. Rosen R, Von Wichert G, Lo G, Bettenhausen KD (2015) About the importance of autonomy and digital twins for the future of manufacturing. IFAC-PapersOnLine 28.

3. Negri E, Fumagalli L, Macchi M (2017) A Review of the Roles of Digital Twin in CPS-based Production Systems. Procedia Manuf 11:939-948.

4. Stark R, Kind S, Neumeyer S (2017) Innovations in digital modelling for next generation manufacturing system design. CIRP Ann - Manuf Technol 66:169-172.

5. Waschull S, Wortmann JC, Bokhorst JAC (2019) Identifying the Role of Manufacturing Execution Systems in the IS Landscape: A Convergence of Multiple Types of Application Functionalities. 502-510.

6. Qi Q, Tao F (2018) Digital Twin and Big Data Towards Smart Manufacturing and Industry 4.0: 360 Degree Comparison. IEEE Access 6:3585-3593.

7. Ríos J, Hernández JC, Oliva M, Mas F (2015) Product avatar as digital counterpart of a physical individual product: Literature review and implications in an aircraft. Adv Transdiscipl Eng 2:657-666.

8. Tao F, Cheng J, Qi Q, et al (2018) Digital twin-driven product design, manufacturing and service with big data. Int J Adv Manuf Technol 94:3563-3576.

9. Kritzinger W, Karner M, Traar G, et al (2018) Digital Twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine 51:1016-1022.

10. Hoffman CM, Joan-Arinyo R (1998) CAD and the product master model. CAD Comput Aided Des 30:905-918.

11. Giachetti RE (2004) A framework to review the information integration of the enterprise. Int J Prod Res 42:1147-1166.

12. Vernadat FB (2007) Interoperable enterprise systems: Principles, concepts, and methods. Annu Rev Control 31:137-145.

13. Moones E, Vosgien T, Kermad L, et al (2015) PLM standards modelling for enterprise interoperability: A manufacturing case study for erp and mes systems integration based on isa-95. In: International IFIP Working Conference on Enterprise Interoperability. Springer Berlin Heidelberg, pp 157-170.

14. Figay N, Ghodous P, Shariat B, et al (2015) Model Based Enterprise Modeling for Testing PLM Interoperability in Dynamic Manufacturing Network. In: 6th International IFIP Working Conference on Enterprise Interoperability (IWEI), pp 141-153.

15. Antonides L (2019) Integration requirements of a process digital twin within an existing information system landscape. University of Groningen.