Architecture,application and implementation of a digital twin of the RFID-enabled material flow in real-time for automotive intralogistics

Abstract

RFID is used in logistics in the automotive industry to automate processes and optimise material flow. However, the data generated by RFID installations during operation offer more potential for further analyses to collect even more benefits from the technology. Therefore, in this paper, RFID data will be used to create a digital twin of the RFID-enabled material flow (DTRMF) in real-time and to programme various big data analyses. The architecture of the DTRMF must meet various qualitative requirements. Since the big data and digital twin architectures available in the literature either do not optimally fulfil all these requirements, or they are not described in enough detail to support real applications, this paper presents a new digital twin architecture for RFID-enabled material flow. This architecture consists of the data ingestion layer, data processing and analyses layer, data storage layer, visualisation layer, and the optional semantic layer. In addition, suitable technologies for the implementation of the architecture are described, and the feasibility of the architecture is demonstrated and verified by means of a case study.

Keywords

Digital twin RFID logistics case study automotive industry

1 Introduction

Radio frequency identification (RFID) is one of the automatic identification (Auto-ID) procedures (Finkenzeller, 2015) and is one of the central technologies for the Internet of Things (IoT) (Uckelmann et al., 2011), because it allows objects to be identified automatically. RFID is a versatile technology and is therefore used in various areas, such as production and logistics (Franke & Dangelmaier, 2006; Kirch et al., 2017), fashion and apparel retail (Esposito et al., 2015; Richter, 2013) or healthcare (Tu et al., 2019). The use of RFID for product tracking and tracing has been steadily increasing in the supply chains of these diverse sectors due to the numerous benefits that this technology offers (Cilloni et al., 2019; Uckelmann & Romagnoli, 2016). In automotive industry logistics, RFID is used at various points to automate individual processes and, thus, to optimise material flow (Richter, 2013). RFID gates are used at goods receipt, for example, as the load carriers containing the materials for the vehicles might be equipped with RFID tags (see, for example, Knapp & Romagnoli, 2021). When a forklift truck drives through the RFID gate with these load carriers, the RFID tags are read, and the goods are automatically identified and processed. During operations, the individual RFID installations constantly generate data. In practice, however, the data generated by an RFID installation are mostly used for the automation and optimisation of one or more processes, without being linked to other data or used for additional analyses to optimise the material flow. The choice of connecting RFID reads with other data, however, could be a way to mitigate (or even solve) the commonly known problem of low cost efficiency of RFID (Abugabah et al., 2020; Costa et al., 2017; Moretti et al., 2019). The use of big data analytics offers enormous potential, for example big data analytics can be used to reduce inventory costs (Amerland, 2015; Klein et al., 2013). In order to use data from individual RFID installations for new insights, the so-called digital twin concept is suitable, as the provision of data from different sources can be streamlined with a digital twin (Lietaert et al., 2021). A digital twin is the virtual representation of a real object or a process that can be used in different areas, such as supply chain and logistics, production, or health management (Abideen et al., 2021; Niaki & Shafaghat, 2021; Tao et al., 2019). Digital twins bring several benefits to the industry, such as higher reliability, greater robustness, more predictable production processes, and the ability to proactively manage supply chain risks (Greis et al., 2021; Jamwal et al., 2021; Lietaert et al., 2021; Tao et al., 2019). The digital twin concept can be used in the automotive industry for real-time material flow optimisation, as load carriers equipped with RFID tags and intralogistics processes of an automotive manufacturer can be represented by a digital twin. We note that the term real-time is described in DIN 44300 (Deutsche Industrienorm) as a type of processing in which the processing results are available within a defined (and typically very short) period of time (DIN, 1988; Scholz, 2005). In this paper, real-time is understood as soft real-time, since the digital twin is currently not a production-critical system, but rather an addition to the existing logistics backend system. Soft real-time means that occasional exceeding of the defined time span can be tolerated (Scholz, 2005). The goals of the digital twin are to create transparency of the material flow, optimise processes, save costs, and simplify and optimise planning. However, it is a challenge to meet the various qualitative requirements of the digital twin, such as the ability to perform big data analyses, a short development time, and easy maintenance. Therefore, a suitable architecture is needed to take these diverse qualitative requirements into account. As the literature review that we provide in Section 5 shows that existing big data and digital twin architectures are not optimally suited for the real-time digital twin of the RFID-enabled material flow (DTRMF), because they are either too complex to implement and to operate, they are not described in concrete terms, or they do not optimally support the execution of batch jobs for big data analyses. Therefore, the aim of this paper is to develop a suitable architecture for DTRMF in real-time and to answer to the following research question RQ1 “Which architecture is suitable for DTRMF in real-time and meets its qualitative requirements?”. Another challenge is the choice of appropriate technologies for the architecture, as our literature review reveals that more than half of the architectures do not mention the needed technologies for the implementation of all components. Therefore, the second research question RQ2 is “Which technologies are suitable to implement the DTRMF architecture in real-time?”. Eventually, since the architectures or their implementation we found in the literature are often not described in detail, the third research question RQ3 is “How can the architecture for the DTRMF be applied and implemented in practice?”.

2 Methodology and structure of the work

The methodology used in this paper is based on the Design Science Research Methodology according to Hevner ( Hevner et al., 2004; Hevner et al., 2010). Figure 1 shows the three design cycles from this methodology, namely the (i) relevance cycle, (ii) design cycle, and (iii) rigour cycle, which have been used to develop the DTRMF. The structure of the present work is shown in Fig. 2. In Section 3 the use of RFID in automotive industry logistics is explained. Section 4 then defines the DTRMF, describes the target image and data of the DTRMF as well as the target groups, and determines the requirements of the DTRMF based on expert discussions (relevance cycle). Section 5 describes the state-of-the-art of digital twin and big data architectures, which were identified through a systematic literature review and thus form the knowledge base (rigour cycle). Based on this knowledge base, the architecture of the DTRMF is developed and described in Section 6 (design cycle). Subsequently, the appropriate technologies for the implementation of the architecture are selected in Section 7, where a database comparison is performed. The selected technologies expand the knowledge base (rigour cycle). Afterwards, Section 8 reports a case study for the implementation of the DTRMF in the body shop of an automotive manufacturer, whose evaluation and achieved benefits are reported in Section 9 to also contribute on the knowledge base (design and rigour cycle). Lastly, Section 10 draws conclusions and suggests possible future research lines.

Fig. 1

Design science research cycles according to Hevner et al. (2010).

Fig. 2

Structure of the remainder of the paper.

3 Overview on the use of RFID in automotive industry logistics

RFID technology might be used at various points in the logistics of the automotive industry to optimise material flows (Richter, 2013). The advantage of RFID compared to barcode is that line-of-sight contact is not required and manual barcode scanning is no longer necessary (Finkenzeller, 2015). In addition, many RFID tags can be read automatically in bulk, thus saving time (Fleisch & Mattern, 2005). In the following, the use of RFID in logistics is explained using the example of the body shop of an automotive manufacturer. The material flow is shown in the simplified scheme reported in Fig. 3. The supplier or the press shop delivers the components for the vehicle in load carriers. These load carriers are usually stored for a given time in a warehouse, and then henceforth transported to the body shop. A distinction is often made between universal load carriers and special load carriers. Universal load carriers are standardised, such as in VDA 4500 (VDA, 2018) and VDA 4520 (VDA, 2011). Universal load carriers may be used by various companies in so-called pool-systems and are managed by pool-operators. Special load carriers are made for components that are not suitable for transport in universal load carriers, and they only circulate between individual suppliers and the car manufacturer. In the examined use-case, special load carriers are equipped with permanent multi-use RFID tags and universal load carriers are affixed with a single-use RFID label. A Unique Item Identifier (UII), also known as Electronic Product Code (EPC) when using the EPC Tag Data Standard (GS1, 2019), is written on the passive RFID tags, and all other information about the UII is stored in the logistics backend system.

Fig. 3

Overview of the simplified material flow of the body shop.

In the suggested scenario, RFID tags are currently read in two different applications: automatic goods receipt and plausibility check. The aim of the automatic goods receipt with RFID gate is that not every barcode of the load carriers has to be scanned individually, and thus time is saved during the goods receipt. For this purpose, RFID antennas are mounted on the sides of the goods receiving gate, which automatically read the RFID tags of the load carriers when a forklift truck drives through. The read UIIs are sent from the reader to the logistics backend system together with further information such as gate ID and timestamp. In the logistics backend system, this information is compared with the delivery notified by the supplier. If the information matches, the goods are booked, and this is displayed to the employee on the forklift terminal. If one or more RFID tags cannot be read, e.g. due to a hardware defect or interferences, the emergency process requires for these RFID tags to be scanned manually with a handheld. After passing through the gate, the load carriers are first placed on a transfer area and from there they are normally transported to the various warehouses of the body shop. As soon as the material is needed for production, the logistics backend system generates a transport order, and the load carriers are driven from the warehouse to the production supply area.

In the body shop, there are different check points where it must be ensured that the right load carriers, and thus the right materials, are supplied. To ensure this, an RFID reader is present at these stations, to automatically read the RFID tag of the load carrier. The UII of the load carrier is transmitted to the logistics backend system, which then performs a plausibility check. If this plausibility check is successful, the open transport order is automatically acknowledged and the robot begins to remove parts from the load carrier. When the material has been removed from all load carriers, the empty load carriers are transported to a transfer area. From there, they are transported directly or via a dedicated warehouse to the suppliers or the press shop. There are other places in the material flow where RFID could be used to track the movements of the load carriers and thus increase transparency, for example, at the incoming and outgoing goods of the supplier / press shop, the warehouse, and the warehouse dedicated to empty load carriers. RFID gates are suitable for this because they read the RFID tags automatically (Fleisch & Mattern, 2005), and thus no additional manual work is required.

4 Objectives and requirements of the DTRMF

There are many different definitions of the term digital twin in the literature ( Al-Sehrawy & Kumar, 2021). In general, a digital twin is a virtual image of products, systems, or processes (Jamwal et al., 2021; Klostermeier et al., 2020). In Grieves (2014) the concept of the digital twin is described, which consists of the following components: “a) physical products in Real Space, b) virtual products in Virtual Space, and c) the connections of data and information that ties the virtual and real products together” (Grieves, 2014). Since there are different definitions, characteristics and possible applications of digital twins (Niaki & Shafaghat, 2021), the DTRMF in real-time is described below for this paper. This digital twin maps the special load carriers with multi-use RFID tags, as well as the various logistics processes, which the load carriers undergo. In this DTRMF, the data exchange only goes in one direction, i.e. from the real space of the product / process (material flow) to the virtual space (digital twin). Information from the DTRMF is made available to production supply and logistics planning, whose staff can intervene to optimise the material flow, if necessary.

The goals of the DTRMF are to create transparency of material flow, optimise processes, save time, reduce costs, and simplify and optimise planning. In practice, these goals shall be achieved by means of various big data analyses, such as by automatically evaluating process and supply times for a timely detection of anomalies, for example in the case of late material delivery. Another big data analysis would be the RFID-enabled automated inventory of the special load carriers, where the actual stock can be compared with the purchased stock. This analysis could make it easier to estimate how many special load carriers must be purchased for reliable operations, thus saving costs and warehouse space. Lastly, the trend of warehouse occupation rate can be evaluated with respect to given targets, to produce comparisons and use the historical data for sound future planning.

For these big data analyses and the creation of the digital twin, data from various sources are needed, as can be seen in Fig. 4. The DTRMF will be developed based on data generated automatically by RFID readers, by handhelds (by scanning barcodes or RFID tags), or by manual input via the forklift terminals or via notebooks. These data are then sent to the logistics backend system via various interfaces. The logistics backend system contains additional information, for example, on transport orders, materials stock, and notified deliveries from suppliers. Data from the logistics backend system are stored in a database and will be linked in the DTRMF with data from other sources, such as those from the load carrier management system. In addition, the DTRMF could also store historical data for big data analyses. The material flow data accumulated over time have a timestamp and form a time series. Finally, other relatively static data are available with basic information about load carriers, warehouses, production supply areas, goods receipts, et cetera.

Fig. 4

Data sources for the digital twin.

To achieve the goals of the digital twin, certain qualitative requirements must be met. The most important qualitative requirements for the DTRMF were determined on the basis of expert discussions with some future users of the DTRMF from the production supply and logistics planning from a German OEM and were defined as follows in accordance with Goll (2014) and ISO/IEC (2011):

R1 –Big data analyses: It should be possible to perform big data analyses and forecasts on historical data using batch jobs.

R2 –Development time: The development time should be as short as possible, thus the used systems should not be too complex.

R3 –Maintainability: The system should be as easy to operate and to maintain as possible.

R4 –Data interoperability: Because “the introduction of digital twins faces difficulties due to a lack of semantic interoperability between architectures, standards and ontologies” (Haße et al., 2019) data interoperability should not be neglected. However, since a semantic data layer is not necessarily required for the DTRMF to function on its own, this is considered an optional requirement.

R5 –Real-time capability: The architecture of the DTRMF should make it possible to visualise the data and information for the users in real-time. The time span for this is defined depending on the information, but the architecture should allow a maximum time span of 5 minutes when processing selected information.

R6 –Time series data: As the DTRMF contains time series data, the database should support the storage, analysis, and retrieval of time series data.

R7 –Expandability: The DTRMF should be expandable so that, for example, further data sources or big data analyses can be added in the future.

R8 –Performance and scalability: The DTRMF should be scalable in order to ensure the performance of the system in case of a roll-out to other shells or plants.

R9 –Availability: As the DTRMF is not a production-critical system, occasional non-availabilities are tolerable.

R10 –Company requirements: Internal company standards, guidelines, or best practices should be taken into account when choosing the technology.

5 State of the art of digital twin and big data architectures

This section describes the state of the art of digital twin and big data architectures. For this purpose, a systematic literature review was conducted. This started from a Google Scholar search (freely available as opposed to commercial offerings such as Scopus) with the terms “digital twin” AND architecture AND logistics and “digital twin” AND architecture. Only references published after 2017, and other interesting papers were added to the list according to their technical relevance. Table 1 shows the results of the literature review, the properties of the architectures, and the assessment regarding the fulfilment of the requirements R1 - R4 for the DTRMF. The requirements R5 - R10 are not considered in this evaluation because they should be fulfilled through the choice of appropriate technologies or environments.

Table 1
Overview of the properties of the architectures and the fulfilment of the requirements

Architecture Application area Goals and key points of the architecture Structure of the architecture Type of data sources and data Technologies forimplementation Implementation of architecture Level of the description R1: Big data analyses R2: Development time R3: Maintainability R4: Data interoperability

Lambda architecture (Marz, 2011) Big Data - Architecture “beats the CAP theorem” (Marz, 2011) Three layers: batch, serving and speed layer No specific data sources / type of data

- “Highly general and can be applied to any data system” (Marz, 2011)

Kappa Architecture (Kreps, 2014) Big Data - Contains no batch layer Two layers: speed layer (messaging system, stream processing), serving layer No specific data sources / type of data

- Only stream processing

Lambda architecture for real-time IoT analytics in logistics (Haße et al., 2019) Logistics, forklift control system - Integrates KPIs into the digital twin Four layers: data acquisition, data processing, data visualisation, semantic layer Microcontroller, sensors (e.g. position, acceleration, localisation, motion)

- Analysis and processing of real-time IoT data

- Architecture with reference to concrete application

- Based on lambda architecture

- Contains a semantic layer

Architecture for simulation-ready digital twin for real-time management of logistics systems (Korth et al., 2018) Logistics, decision support system - Architecture “combines a realtime digital twin of logistics systems with simulation” (Korth et al., 2018) Six components: event-controller, simulation, logbook, model, reporting, persistence Scanners (barcode / RFID), sensors, and bookings in a warehouse management system – – –

- “Efficient integration of event-discrete simulation into a digital twin architecture” (Korth et al., 2018)

Cloud-fog-edge-based digital twin control framework (Pan et al., 2021) Logistics - “Multi-level cloud computing enabled digital twin system for the real-time monitor, decision and control of a synchronized production logistics system” (Pan et al., 2021) Two layers: physical layer (entity &IoT, control strategy, computing, local optimiser dimension) and virtual layer (model center, data center, synchronisation control center) “real-time data of production elements (personnel, machine tool, vehicles and cargo)“ (Pan et al., 2021)

- Edge computing, fog computing, and cloud computing for different dynamics

- Synchronisation mechanism

Digital twin architecture for enabling digital services (Merkle et al., 2019) Automotive battery systems - Reference architecture for a digital twin of manufacturing and product life cycle of a battery system to enable digital services Three layers: hardware + connectivity, twin level, service level Sensors, machinery, data loggers, manufacturing execution system, enterprise resource planning system – –

- Contains a UML (Unified Modeling Language) meta model

Digital twin reference architecture model in industry 4.0 (Aheleroff et al., 2021) Industry 4.0, wetland schedule maintenance - Reference architecture consists of three axis: digital twin layers, agile process and digital twin integration levels Five digital twin layers: physical, communication, digital, cyber, application layer Sensor data – –

- “first attempts to build Digital Twin toward mass individualization” (Aheleroff et al., 2021)

- Digital twin as a service

Intelligent digital twin architecture (Talkhestani et al., 2019) Production, assistence system / smart warehouse with climate control / field of metal forming - Intelligent Digital Twin in cyber-physical production system (CPPS) Data-acquisiton interface, synchronisation interface, operation data, relations, DT version management, modell, ID, organisational / technical specification, feedback interface, intelligent algorithm, service, DT model comprehension, co-simulation interface Programmable logic controller (PLC) code of the PLC-controlled system, XML – –

- Ancher-point-method for synchronisation

- Integration and processing of the real operation data

- Enabling co-simulation between digital twins

- Automated control of physical assets via the digital twin

Architecture for a digital twin for intra-logistics process planning (Guerreiro et al., 2019) Logistics, process planning - Provides a technology stack for the architecture Five layers: data collection and ingestion, data storage, data processing engines, query-analytics-visualisation, others (APIs, reverse proxy coordination, deployment) Sources: services, files, RDBMS, data: manufacturing data, engineering data, product &process data, automated storage, retrieval of parts, supply chain data – –

- Contains information on the deployment with docker and docker swarm orchestration

- Contains 3D visualisation of the digital twin

Six-layer digital twin architecture (Redelinghuys et al., 2019) Manufacturing cell - Architecture takes into account emulation and simulation Six layers: physical devices, local controllers, local data repositories, IoT gateway, cloud based information repositories, emulation and simulation Sensors, PLCs –

- Open Platform Communications Unified Architecture (OPC UA) servers are used

- IoT gateway (layer 4) is optional

Digital twin architecture based on the industrial internet of things technologies (Souza et al., 2019) IIoT - Uses OPC UA Three components: physical twin, IIoT gateway, and internal server (digital twin) Sensors, PLCs – –

- Based on industrial internet of things technologies

- Provides two views: one inside the workplace for critical processes and one outside the workplace

Generic digital twin architecture (Steindl et al., 2020) Industrial energy systems, thermal energy storage system - Technology-independent architecture Six layers: asset, integration, communication, information, functional, business Sensors, events – –

- Reference Architecture Model Industry 4.0 (RAMI4.0) was used

- Focus on shared knowledge base and ontology concepts

- Service oriented architecture

ISO 23247-2 –Digital twin framework for manufacturing –reference architecture (ISO, 2021) Manufacturing - “Reference architecture provides guidance for implementing digital twins in manufacturing” (ISO, 2021) Four domains: observable manufacturing, device communication, digital twin, user domain Sensors – –

- The communication entity contains a device control subentity to control the OMEs (Observable Manufacturing Element)

Legend: = described in detail / requirement completely fulfilled; = described superficially or partially / partially fulfilled, = not described / not fulfilled.

The lambda architecture was developed by Marz, and the approach was introduced in 2011 in the blog post “How to beat the CAP theorem” (Lin, 2017; Marz, 2011). It describes an architecture (at that time still called batch/real-time architecture) “that beats the CAP theorem by preventing the complexity it normally causes” (Lin, 2017; Marz, 2011). The CAP theorem (Consistency, Availability, Partition Tolerance) states that the three properties consistency, availability, and partition tolerance cannot be fulfilled simultaneously in massively distributed computer systems, but only two properties at most (Meier, 2018). The resulting lambda architecture consists of three layers: speed layer, serving layer, and batch layer, and it has been implemented in later studies, e.g., in Sanla and Numnonda (2019). Since the Lambda architecture requires two systems to be implemented for the same tasks (i.e., batch and speed layer), it has the disadvantage of requiring double effort for the programming and maintenance (Kreps, 2014), and therefore it does not fulfil the two requirements R2 (development time) and R3 (maintainability) for the digital twin.

The kappa architecture has been implemented, for example, in Sanla and Numnonda (2019) and the problem of double effort is solved in the kappa architecture (Kreps, 2014), because this architecture contains no batch layer but a messaging system, stream processing system (speed layer) and a serving database (serving layer). Therefore, the kappa architecture fulfils the requirements R2 (development time) and R3 (maintainability), but the entire processing logic must be realised as stream processing. This can be impractical for analyses where data are processed far from the past (Berle, 2017) and therefore the kappa architecture does not fulfil requirement R1 (big data analyses).

In Haße et al. (2019) the lambda architecture for real-time IoT analytics in logistics is described, which consists of the layers: data visualisation, data processing, and semantic layer, and the optional data acquisition layer. Because this architecture is based on the lambda architecture, it does not fulfil requirements R2 (development time) and R3 (maintainability). The semantic layer is not included in the lambda architecture and serves to overcome the “difficulties due to a lack of semantic interoperability between architectures, standards and ontologies” (Haße et al., 2019) in digital twins, and therefore the requirement R4 (data interoperability) is fulfilled.

In Korth et al. (2018) the architecture for simulation-ready digital twin for real-time management of logistics systems is presented, which consists of the six components event controller, simulation, logbook, model, reporting, and persistence. This architecture is not described in enough detail to adopt it, for example, it is unclear whether the model includes stream processing or batch processing, or both, and it is not mentioned which technologies can be used to implement this architecture. Therefore, the fulfilment of the requirements R2 (development time), R3 (maintainability) and R4 (data interoperability) cannot be assessed.

The cloud-fog-edge-based digital twin control framework is presented in Pan et al. (2021). The framework distinguishes between a physical and a virtual layer. The physical layer contains the entity & IoT, control strategy, computing, local optimiser dimension, and the virtual layer includes model centre, data centre, synchronisation control centre. In Pan et al. (2021) “a case is simulated as an example to prove the feasibility and effectiveness of the synchronization mechanism“ (Pan et al., 2021) where MATLAB is used, however, the entire framework is not implemented and no concrete technologies for implementation are mentioned. Furthermore, the framework is very complex, and therefore, it is assumed that it does not meet requirements R2 (development time) and R3 (maintainability). Requirement R4 (data interoperability) is met because the model centre contains an ontology model.

The digital twin architecture for enabling digital services described in Merkle et al. (2019) consists of the three layers hardware including connectivity, twin level and service level. The architecture has not been implemented, and no concrete technologies for an implementation are named. As a result, concrete information for the realisation of this architecture is missing, and the fulfilment of the requirements R2 (development time) and R3 (maintainability) cannot be assessed. This architecture does not contain a separate semantic layer, but the “one general purpose of the service level is the generic access to the digital twin data” (Merkle et al., 2019) and therefore the requirement R4 (data interoperability) is partially met.

The digital twin reference architecture model in industry 4.0 described in Aheleroff et al. (2021) comprises the three axes digital twin layers, iterative / incremental approach, and level of integration. The digital twin layers are the physical layer, communication layer, digital layer, cyber layer, and application layer. In Aheleroff et al. (2021), the concept of Digital Twin as a Service (DTaaS) aims to solve the problem of individualisation which is not possible with other reference architectures. The architecture is implemented in an example use case, but details for the implementation are missing, such as information on data storage. Therefore, the achievement of the requirements R2 development time and R3 maintainability cannot be assessed. The requirement of data interoperability (R4) is partially fulfilled, as the architecture contains no explicit semantic layer, but it is written that “adopting scalable and autonomous capabilities in Industry 4.0, along with the digital representation of unique physical assets, create an opportunity to address some challenges concerning semantics” (Aheleroff et al., 2021).

In Talkhestani et al. (2019) the intelligent digital twin architecture is presented, because “there lacks, however, a clear, encompassing architecture covering necessary components of a Digital Twin to realize various use cases in an intelligent automation system“ (Talkhestani et al., 2019). This architecture contains the components data-acquisition interface, synchronisation interface, operation data, relations, DT version management, model, ID, organisational / technical specification, feedback interface, intelligent algorithm, DT model comprehension, service, and co-simulation interface. This architecture was only partially realised, and not for all components, a concrete technology was proposed for implementation, such as intelligent algorithm. Due to a lack of information on technical implementation, requirements R2 (development time) and R3 (maintainability) cannot be assessed. The requirement R4 (data interoperability) is fulfilled because the architecture contains the components model and relations.

In Guerreiro et al. (2019) the architecture for a digital twin for intra-logistics process planning is presented. The architecture consists of five layers: (i) data collection and ingestion, (ii) data storage, (iii) data processing engines, (iv) querying-analytics-visualisation, and (v) others (e.g. APIs, reverse proxy coordination, deployment). The implementation of this is not described in detail; for example, it is unclear which and how many technologies or systems are needed to realise the querying-analytics-visualisation layer. Furthermore, it is unclear whether the data processing is batch, stream, or batch and stream processing, and how many systems are required as a minimum. Therefore, the fulfilment of requirements R2 (development time) and R3 (maintainability) cannot be assessed. Furthermore, this architecture does not contain a semantic layer for data interoperability and therefore requirement R4 is not fulfilled.

In Redelinghuys et al. (2019) the six-layer digital twin architecture is presented. The architecture consists of (1) physical devices, (2) local controllers, (3) local data repositories, (4) IoT gateway, (5) cloud-based information repositories, and (6) emulation and simulation. The architecture was verified using a case study. However, concrete technologies are not proposed for all layers; for example, for layer 5 it is only mentioned that the Google Cloud Platform was used, but not which database or service was used. Furthermore, nothing is specifically described for big data analyses, but it is assumed that these can be carried out in layer 6, where simulations are also located. Because a “custom C# program was developed as the IoT Gateway” (Redelinghuys et al., 2019) for layer 4 and the “complex installation of some OPC UA drivers required for the development of the IoT Gateway” (Redelinghuys et al., 2019) is mentioned as a limiting factor, it is assumed that the requirement R2 (development time) is not met. As it is not specifically described how layer 5 (cloud-based information repositories) is implemented, requirement R3 (maintainability) cannot be assessed. The paper does not describe a semantic layer for data interoperability and, therefore, the optional requirement R4 is not fulfilled.

The digital twin architecture based on the industrial internet of things technologies is described by Souza et al. (2019) and contains the three components: physical twin, IIoT gateway, and internal server (digital twin). The architecture is verified using an experimental application, but not for all components a specific technology is mentioned, for example, for the internal server. This architecture contains no component for big data analyses or data processing and no semantic data layer and therefore requirements R1 (big data analyses) and R4 (data interoperability) are not fulfilled. Requirements R2 (development time) and R3 (maintainability) cannot be assessed due to a lack of technical information on the implementation.

The generic digital twin architecture proposed by Steindl et al. (2020) contains the six layers including (1) asset, (2) integration, (3) communication, (4) information, (5) functional and (6) business. The generic digital twin architecture has been implemented as a prototype, but not for all layers specific technologies for implementation are mentioned. In this architecture, big data analyses could be implemented as services in the functional layer. Requirements R2 (development time) and R3 (maintainability) cannot be assessed due to the lack of technical implementation details. Requirement R4 (data interoperability) is fulfilled by the shared knowledge base included in this architecture.

The reference architecture described in ISO 2347-2 (ISO, 2021) “provides guidance for implementing digital twins in manufacturing” (ISO, 2021). The standard ”does not prescribe specific data formats and communication protocols” (ISO, 2021) and no concrete technologies are mentioned for implementation. Furthermore, the architecture is not implemented as an example. Since no details are given on the technical implementation, the fulfilment of requirements R2 (development time) and R3 (maintainability) cannot be assessed. Requirement R4 (data interoperability) is fulfilled because the architecture contains a component for ”interfaces to other digital twins in conjunction with the interoperability“ (ISO, 2021).

This literature review shows that no existing architecture is described in sufficient details to be applicable to, and to fulfil all the requirements of the DTRMF. Thus, the following section will provide details of a suggested architecture that aims to fulfil all DTRMF requirements.

6 Proposed architecture for the DTRMF

As previously mentioned, a new architecture is developed in this section, by starting from the architectures proposed by Haße et al. (2019) and Guerreiro et al. (2019), which were used as a basis and adapted, as they fulfil several of the requirements of Section 4, and they pursue goals that are similar to those of the DTRMF, as they were developed specifically for the logistics sector. However, unlike in Haße et al. (2019), no lambda architecture is used, but only one layer and one system to process the data with the aim of keeping low both development time and maintenance needs. Furthermore, the kind of processing is described and every layer only communicates with the upper or the lower one, to reduce complexity, this also differs from Guerreiro et al. (2019). The only exception is the semantic layer, which communicates directly with the database. The architecture of the DTRMF and the data flow between the individual layers can be seen in Fig. 5. To keep the architecture general, no concrete technologies are specified here.

Fig. 5

Layers and data flow of the DTRMF architecture.

The data ingestion layer is about connecting the data sources and making them usable. Data sources could be, for example, databases, sensors, PLCs, or files.

As soon as the data are available, they are processed in the data processing and analyses layer. First, pre-processing is carried out, where, for example, the data are filtered or changed in its format. This part can be realised either as stream processing or in batch jobs, which are executed periodically to ensure real-time capability. The pre-processed data are then stored. The second part of this layer are the big data analyses, which are realised as batch processing and use the pre-processed and stored data. The results of big data analyses are also stored in the database. Simulations or machine learning algorithms could also be carried out in this component.

The data storage layer consists of the database, which stores all relevant real-time data but also the historical data for the DTRMF.

The visualisation layer, represents the graphical interface between the users and the digital twin.

The semantic layer serves to describe the data prepared and newly generated by the DTRMF in a uniform format, and thus make the data accessible to other users and systems. Therefore, this layer has an interface to the database of the digital twin.

7 Technologies to implement the architecture

7.1 Environment of the digital twin

To develop and deploy the DTRMF in the optimal environment, the advantages and disadvantages of a cloud environment and on-premises are compared (cf. Table 2). One advantage of the cloud over on-premises servers is greater simplicity, and better scalability, because with an on-premises server, for example, the hardware would first have to be installed for a storage expansion (Apostu et al., 2013; Morefield Communications, 2022). Better scalability also leads to higher flexibility (Morefield Communications, 2022). Another advantage is that the purchase costs of the hardware are eliminated, and often only the actually used resources must be paid for, as it is the case with Azure Databricks, for example (Apostu et al., 2013; Databricks, n.d.; Morefield Communications, 2022). Furthermore, creating backups is easier and there is no need for in-house IT staff to maintain the hardware and infrastructure. Cloud-based offerings also enable data access and services from anywhere (Apostu et al., 2013; Morefield Communications, 2022). However, accessing the cloud via the internet can also be a disadvantage, because it requires a stable and fast internet connection, and a failure of the internet leads to a failure of the application running in the cloud from the user’s point of view (Morefield Communications, 2022). Moreover, fast scalability can also be costly if costs are not adequately monitored. Another disadvantage is security and data protection, as data are managed by a cloud provider and using a cloud can lead to more attacks on an organisation (Apostu et al., 2013; Morefield Communications, 2022). With on-premises servers, on the other hand, security and data protection are easier to ensure as the servers are only accessible within a network, and therefore no internet connection is required for access. This can lead to cost savings if a slower and therefore cheaper internet connection is used. Another advantage can be the sovereignty over the hardware and data, whereby customised changes can be made, and thus flexibility is achieved. A disadvantage of on-premises servers, however, is that the servers themselves have to be maintained, and thus additional staff is required and costs are incurred. In addition, the required hardware has to be ordered and purchased, and therefore scalability is also worse than with the cloud (Morefield Communications, 2022).

Table 2
Advantages and disadvantages of cloud and on-premises

Cloud On-premises

Advantages - Better scalability - Security and privacy are easier to ensure

- More flexibility -No internet connection required

- No hardware acquisition costs - Control over hardware and data

- Payment by usage - Flexibility and customisation

- Easy creation of backups

- No infrastructure maintenance

- Access from anywhere

Disadvantages -Availability depends on the internet connection -Server maintenance

-It can be costly over time -Hardware acquisition costs

-Security and data protection must be ensured -Less scalable

	Cloud	On-premises
Advantages	- Better scalability	- Security and privacy are easier to ensure
	- More flexibility	-No internet connection required
	- No hardware acquisition costs	- Control over hardware and data
	- Payment by usage	- Flexibility and customisation
	- Easy creation of backups
	- No infrastructure maintenance
	- Access from anywhere
Disadvantages	-Availability depends on the internet connection	-Server maintenance
	-It can be costly over time	-Hardware acquisition costs
	-Security and data protection must be ensured	-Less scalable

The advantages of the cloud environment clearly outweigh the disadvantages, and the cloud meets the requirements of easy maintenance (R3) and scalability (R8) of the digital twin. In addition, a high-availability environment is not required as the system is not production-critical (requirement R9). For these reasons, the cloud is considered as the optimal environment for the DTRMF.

7.2 Data ingestion layer

The DTRMF in this paper is based on the database of the logistics backend system, which is an Oracle database. The Qlik Replicate software should be used for data connection because it supports many different source and target endpoints (QlikTech, n.d.–a, n.d.–b), ”minimizes impact on [ . . . ] source production operations” (QlikTech, 2020) and the software is also already used in the company, so that the requirement R10 is fulfilled.

7.3 Data storage layer

In order to find a suitable database, a comparison of the four databases PostgreSQL, TimescaleDB, InfluxDB, and MongoDB was done, which can be seen in Table 3. The comparison of the four databases PostgreSQL, TimescaleDB, InfluxDB, and MongoDB showed that TimescaleDB meets the requirements best, as TimescaleDB has the primary database model Time Series DBMS (Database Management System) (DB-Engines, n.d.–d), is open source (DB-Engines, n.d.–d), is horizontally scalable through the chunking method (Freedman & Nordström, 2019), uses the query language SQL (Structured Query Language), which means that no specific query language has to be learned (TimescaleDocs, n.d.–a) and provides the features continuous aggregates and real-time aggregation (Klemm & Freedman, 2020) for real-time applications. Furthermore, benchmarks show that TimescaleDB achieves “20x higher inserts, 2000x faster deletes, 1.2x-14,000x faster queries” (Kiefer, 2017) than PostgreSQL, “higher insert performance, up to 53x faster queries” (Kiefer et al., 2020) than MongoDB and “for workloads with high cardinality, TimescaleDB has 3.5x the insert performance as InfluxDB” (Freedman & Sewrathan, 2020) for time-series data. The other databases do not optimally fulfil the requirements for the DTRMF, as PostgreSQL is not a Time Series DBMS (DB-Engines, n.d.–c), InfluxDB does not support horizontal scalability in the open source edition (Influxdata, n.d.–b) and does not support ACID (Atomicity, Consistency, Isolation, Durability) transactions (GeeksforGeeks, 2020), and MongoDB has the Time Series DBMS only as a secondary database model (DB-Engines, n.d.–b) and the specific MongoDB query language must be used (Jayaram, 2020).

Table 3
Comparison of databases

PostgreSQL TimescaleDB InfluxDB MongoDB

Relational DBMS Yes (DB-Engines, n.d.–c) Yes (DB-Engines, n.d.–d) No (DB-Engines, n.d.–a) No (DB-Engines, n.d.–b)

Document store Yes (DB-Engines, n.d.–c) No (DB-Engines, n.d.–d) No (DB-Engines, n.d.–a) Yes (DB-Engines, n.d.–b)

Time Series DBMS No (DB-Engines, n.d.–c) Yes (DB-Engines, n.d.–d) Yes (DB-Engines, n.d.–a) Yes (DB-Engines, n.d.–b)

Open Source Yes (DB-Engines, n.d.–c) Yes (DB-Engines, n.d.–d) Yes¹ (Influxdata, n.d.–b) Yes (DB-Engines, n.d.–b)

Replication Yes (Insausti, 2019; McCulloch, 2020; Rehman, 2021) Yes (TimescaleDocs, n.d.–b) Yes² (Influxdata, n.d.–b) Yes (MongoDB, n.d.–b)

Horizontal sharding / Chunking Yes (PostgreSQL, n.d.–; b; Rehman, 2021) Yes³ (Freedman &Nordström, 2019) Yes⁴ (Influxdata, n.d.–b) Yes (MongoDB, n.d.–b)

ACID Transactions Yes (DB-Engines, n.d.–c) Yes (Hsieh &Perry, 2019) No (GeeksforGeeks, 2020) Yes⁵ (MongoDB, n.d.–d)

Consistency Immediate (DB-Engines, n.d.–c) Immediate (DB-Engines, n.d.–d) Eventual (Farmer, 2018) Immediate, Eventual⁶ (DB-Engines, n.d.–b; MongoDB, n.d.–c)

Query Language SQL ( PostgreSQL, n.d.–a) SQL (TimescaleDocs, n.d.–a) InfluxQL⁷, Flux(Influxdata, n.d.–a) MongoDB Query Language⁸ (Jayaram, 2020)

Features for real-time capability Materialised views (PostgreSQLTutorial, n.d.), change notifications (Wingerath, 2017) Continuous aggregates, real-time aggregation (Klemm &Freedman, 2020) Continuous queries (Influxdata, n.d.–c), InfluxDB tasks (Influxdata, n.d.–d), stream tasks (Schaedel, 2018) Change streams (MongoDB, n.d.–a)

	PostgreSQL	TimescaleDB	InfluxDB	MongoDB
Relational DBMS	Yes (DB-Engines, n.d.–c)	Yes (DB-Engines, n.d.–d)	No (DB-Engines, n.d.–a)	No (DB-Engines, n.d.–b)
Document store	Yes (DB-Engines, n.d.–c)	No (DB-Engines, n.d.–d)	No (DB-Engines, n.d.–a)	Yes (DB-Engines, n.d.–b)
Time Series DBMS	No (DB-Engines, n.d.–c)	Yes (DB-Engines, n.d.–d)	Yes (DB-Engines, n.d.–a)	Yes (DB-Engines, n.d.–b)
Open Source	Yes (DB-Engines, n.d.–c)	Yes (DB-Engines, n.d.–d)	Yes¹ (Influxdata, n.d.–b)	Yes (DB-Engines, n.d.–b)
Replication	Yes (Insausti, 2019; McCulloch, 2020; Rehman, 2021)	Yes (TimescaleDocs, n.d.–b)	Yes² (Influxdata, n.d.–b)	Yes (MongoDB, n.d.–b)
Horizontal sharding / Chunking	Yes (PostgreSQL, n.d.–; b; Rehman, 2021)	Yes³ (Freedman &Nordström, 2019)	Yes⁴ (Influxdata, n.d.–b)	Yes (MongoDB, n.d.–b)
ACID Transactions	Yes (DB-Engines, n.d.–c)	Yes (Hsieh &Perry, 2019)	No (GeeksforGeeks, 2020)	Yes⁵ (MongoDB, n.d.–d)
Consistency	Immediate (DB-Engines, n.d.–c)	Immediate (DB-Engines, n.d.–d)	Eventual (Farmer, 2018)	Immediate, Eventual⁶ (DB-Engines, n.d.–b; MongoDB, n.d.–c)
Query Language	SQL ( PostgreSQL, n.d.–a)	SQL (TimescaleDocs, n.d.–a)	InfluxQL⁷, Flux(Influxdata, n.d.–a)	MongoDB Query Language⁸ (Jayaram, 2020)
Features for real-time capability	Materialised views (PostgreSQLTutorial, n.d.), change notifications (Wingerath, 2017)	Continuous aggregates, real-time aggregation (Klemm &Freedman, 2020)	Continuous queries (Influxdata, n.d.–c), InfluxDB tasks (Influxdata, n.d.–d), stream tasks (Schaedel, 2018)	Change streams (MongoDB, n.d.–a)

¹In addition to the Open Source Edition, there are also the InfluxDB Cloud and InfluxDB Enterprise editions (Influxdata, n.d.–b). ²The high availability feature, which belongs to replication in this paper, is only available in the InfluxDB Cloud and InfluxDB Enterprise editions (Influxdata, n.d.–b). ³TimescaleDB, unlike PostgreSQL for example, relies on chunking instead of sharding. The difference is that chunks are created automatically whereas shards are typically created manually. Furthermore, chunking can also be used for scale-up and offers advantages such as elasticity and partitioning flexibility. (Freedman & Nordström, 2019). ⁴Horizontal scalability (clustering) is only available in the Cloud and Enterprise editions, but not in the Open Source edition (Influxdata, n.d.–b). ⁵On the MongoDB website it is described that “single-document updates have always been atomic” (MongoDB, n.d.–d). However, if related data is stored in multiple documents and these are modified, MongoDB has so-called multi-document ACID transactions, which have the ACID properties and thus ensure data integrity (MongoDB, n.d.–d). ⁶Since in MongoDB the write and read operations are performed via the primary replica set, MongoDB is consistent. There is a possibility that secondary replicas are read from and in this case, the data are eventual consistent (MongoDB, n.d.–c). ⁷InfluxQL is a SQL-like query language (DB-Engines, n.d.–a; Influxdata, n.d.–a). ⁸“Read-only SQL queries via the MongoDB Connector for BI” (DB-Engines, n.d.–b).

7.4 Data processing and analyses layer

The Python programming language and analysis platform Databricks, which is based on Apache Spark, are used for processing (Etaati, 2019). Apache Spark is also listed by Guerreiro et al. (2019) and Haße et al. (2019) as a technology for data analysis and for the data processing engine. Furthermore, Databricks supports both stream and batch processing and is scalable because “it is possible to resize automatically and autoscale the size of the cluster” (Etaati, 2019). Furthermore, Databricks is already being used in the company. For these reasons, Databricks is ideally suited for data processing for the DTRMF.

7.5 Visualisation layer

To keep both development time and complexity low, Databricks dashboards are initially used for visualisation. However, due to the loose coupling, this technology could also be replaced at a later date.

7.6 Semantic layer

The semantic layer could be realised by using the Resource Description Framework (RDF) or Web Ontology Language (OWL), for example, as described by Steindl et al. (2020) and Haße et al. (2019). The GS1 Core Business Vocabulary (CBV) 2.0 standard could also be considered in the implementation of a semantic layer (GS1, 2022). Since the semantic layer is only an optional layer, it will not be considered further in this paper. However, it would be conceivable to automatically generate the semantic layer from the database of the digital twin.

8 A case study for the implementation of the DTRMF in the body shop of an automotive manufacturer

For the application and verification of the new architecture and the proposed technologies described in Sections 6 and 7, these are used to implement the DTRMF in the body shop of an automotive manufacturer. In this case study the analysis of the expiration date for adhesive parts after a production break is implemented by using the digital twin. The details of the case study are described in Table 4.

Table 4
Case Study: Analysis of the expiration date for adhesive parts after a production break

Goal The aim of this case study is to ensure production supply by determining at an early stage whether new adhesive parts are needed or existing adhesive parts need to be sent to the re-drying after a production break because the existing ones are no longer durable.

Target group Production supply of the body shop

Description Adhesive parts have an expiration date. If this is exceeded, the adhesive becomes too moist, and the component must either be scrapped or sent for re-drying, which, however, is time-consuming and associated with costs, and is therefore only profitable for expensive components. If there are production breaks due to delivery bottlenecks or block breaks, it is time-consuming to determine whether the adhesive parts can still be used afterwards, whether new material must be ordered shortly before production starts up again, or whether existing adhesive parts must be sent to re-drying early enough. For this purpose, there should be an input mask where the end of the production break is entered and an algorithm then automatically determines whether the adhesive parts can still be used afterwards or whether they have to be ordered again or have to be dried. In this way, it can be ensured that the required material is available and can be used when production starts after the production break.

Required systems This case study requires data from the logistics backend system (SAP solution AmSupply), which is stored in an Oracle database.

KPI (Key Performance Indicator) The KPIs that have to be calculated in this case study are the expiration date without remaining time and the number of days after the end of production for each load carrier.

8.1 Environment of the digital twin

The big data platform eXtollo from Mercedes-Benz Group AG ( Mercedes-Benz Group AG, n.d.), which is based on Microsoft Azure, is used as the environment for the digital twin. The platform is suitable for use cases in the field of analytics and artificial intelligence and provides Azure Databricks, for example. One advantage of this platform is that the data are stored in encrypted form (Mercedes-Benz Group AG, n.d.). Therefore, this platform is used for the development of the DTRMF.

8.2 Data ingestion layer

First, the data required for the case study of the DTRMF must be determined, and the systems, tables, and columns where these data are stored must be identified. For the case study described here, only data from the logistics backend system are required, which are stored in an Oracle database (SAP AmSupply). Table 5 shows the four required tables, their table names and data types. Master data rarely change, whereas transaction data often change (SAP, n.d.). Since the real-time data connection via Qlik Replicate does not yet exist for organisational reasons at this point in time (October 2022), manual CSV (Comma-separated values) exports of these tables from the logistics backend system were created and uploaded to Databricks manually.

Table 5
Required tables from the logistics backend system

Table Table name Data type

MAKTX Material short texts Master data

MARA General material data Master data

LQUA Storage quants Transaction data

VEKP Handling unit header table Transaction data

LTAP Transport order positions Transaction data

LTAK Transport order header Transaction data

Table	Table name	Data type
MAKTX	Material short texts	Master data
MARA	General material data	Master data
LQUA	Storage quants	Transaction data
VEKP	Handling unit header table	Transaction data
LTAP	Transport order positions	Transaction data
LTAK	Transport order header	Transaction data

8.3 Data storage layer

The TimescaleDB database is run in a Docker container in an Azure VM, and pgAdmin is used as the administration interface for the database. To run and configure the two containers TimescaleDB and pgAdmin, Docker Compose is used. To store the data in the database permanently, a permanent disk is attached to the virtual machine. In the Docker Compose file (see Listing 1), the volume where the data should be stored is specified.

version: ’3.3’

services:

timescaledb-docker:

image: timescale/timescaledb:latest-pg14

container_name: db

ports:

- “5432 : 5432"

environment:

- POSTGRES_USER = postgres

- POSTGRES_PASSWORD = password

- POSTGRES_DB = DigitalTwinDB

volumes:

-./data:/var/lib/postgresql/data

pgadmin:

image: dpage/pgadmin4

container_name: pg-admin

depends_on:

- timescaledb-docker

ports:

- 5555:80

environment:

- PGADMIN_DEFAULT_EMAIL = email

- PGADMIN_DEFAULT_PASSWORD = password

Listing 1 Docker compose YAML file

Before the data can be stored in the database, a data model must be developed, and then the tables must be created. Figure 6 shows the entity relationship diagram of the DTRMF for the case study described here using the Unified Modelling Language (UML). This data model consists of the entities material, storage quant and handling unit.

Fig. 6

Entity relationship diagram of the digital twin

8.4 Data processing and analyses layer

The processing is programmed and executed in Python in Azure Databricks. Since no big data analyses are required for the implementation of this case study, only pre-processing is described here. In pre-processing, the data are prepared so that they can be used later in big data analyses and visualisation. The pre-processing can be seen in the flow chart in Fig. 7. The first flow chart shows the general pre-processing procedure for the tables of the digital twin, but not all steps have to be performed for all tables. Before the pre-processing begins, a current timestamp is generated and stored in a variable, which is needed for versioning of the data.

The first step is to read the required tables from the manually uploaded CSV files and store them in a dataframe. When reading the tables, columns that are not needed are filtered out directly to reduce the amount of data.

In the second step the format and the data type of the columns, which contain quantity data, are changed, because the data come from a German-language system and here the dot is not the decimal separator but only marks visual thousandths, and the comma is the decimal separator. Therefore, all dots are removed by means of a regex, then all commas are replaced by a dot, and finally the data type string is converted into the data type double. For example, such a column contains before the value “6.628,000” and after the pre-processing “6628.000".

Afterwards, the data type of all other columns that do not contain text will be converted into the correct format. For example, columns with a date are casted into the data type date, timestamps are converted into the data type timestamp or numbers are converted into the data type int.

In the fourth step, if necessary, new columns are added which contain calculated values or transformed data. For example, the spaces are removed from the material number and this is added as a new column in order to simplify the input later when filtering by material number for the users. Here is an example of a material number with blanks “A 223 682 79 02“ and the same without blanks “A2236827902“.

If there are several source tables, and thus dataframes, these are linked together in the fifth step. Here it is important to ensure that the correct JOIN type, e.g. “LEFT JOIN” is used.

As the columns contain the technical names of the tables in the logistics backend, they are renamed to English and more readable names. For example, the MATNR column is renamed to material_number.

For the versioning and history of the digital twin, the timestamp generated at the beginning is now added to each row.

Finally, the dataframes are saved to the TimescaleDB database of the digital twin. Here, the ‘append’ mode is used so that the existing data are not overwritten.

Fig. 7

Data pre-processing.

To execute the pre-processing, a job is created that runs the code every minute to keep the DTRMF updated in real-time.

8.5 Visualisation layer

To make the data from the DTRMF database available to users, it must be visualised. For this purpose, Databricks Dashboards are used for this case study.

For the visualisation of the case study, an SQL query is sent to the TimescaleDB of the digital twin, which links the tables storage_quants, material, handling_units and selects, based on the timestamp, only the most current data. When considering the expiration date, the remaining time of each material must be taken into account because if this is exceeded, the material may no longer be used by logistics. The remaining time is stored in the system for each material number. For this reason, a new column is first added that contains the expiration date without the remaining time, which is calculated as follows: $\begin{matrix} {expiration date}_{without remainining time} \\ = expiration date - remaining time \end{matrix}$

Subsequently, it is calculated whether the end of the production break precedes (or is equal to) the expiration date without remaining time, i.e., whether the material can still be used after the end of the production break or not. If it can no longer be used, an “X” is displayed in a new column. To be able to show how many days after the production break the material can be stored and used, the expiration date without remaining time is subtracted from the date of the end of the production break. $\begin{matrix} {number of days}_{after production end} \\ = {date}_{end of production break} - exp iration {date}_{without remaining time} \end{matrix}$

To also visualise the last transport orders to the stations (target storage location), an SQL query is executed on the database table transport_order.

Finally, the columns are renamed so that they are understandable for the users. The date of the end of the production break can be entered via a text widget. Furthermore, there is the option to filter whether all storage quants or materials should be displayed or only those whose expiration date will be expired after the production break and a filter to enter a specific storage location. The resulting dashboard can be seen in Fig. 8.

Fig. 8

Dashboard of the case study.

9 Evaluation of the DTRMF architecture and benefits achieved by its application

This section describes how the qualitative requirements for the DTRMF were implemented and fulfilled.

R1 –Big data analyses: The data processing and analyses layer includes a component for big data analyses. Even though no big data analyses or forecasts on historical data were performed in this case study, this requirement is considered fulfilled as Databricks supports batch processing and has proven to be a well-suited platform for data pre-processing (Etaati, 2019).

R2 –Development time: The architecture, the use of the Microsoft Azure Cloud environment and the technologies TimescaleDB and Databricks, as well as Databricks Dashboards, enabled the implementation of the case study within a few months, and thus the requirement for a short development time was met.

R3 –Maintainability: The virtual machine in the Azure cloud environment and the Azure Databricks service do not need to be maintained, but the TimescaleDB database running on the virtual machine still has to be maintained as it is no database as a service. Nevertheless, maintenance is limited as it is only one component and the code and therefore this requirement was also met.

R4 –Data interoperability: As data interoperability is not necessary for the pure functionality of the DTRMF, it was not implemented at the time being. However, the architecture includes the optional semantic layer.

R5 –Real-time capability: Real-time capability is primarily dependent on the data connection, which due to organisational reasons could not yet be realised in real-time for this case study. However, the Qlik Replicate software is suitable for this, as it “ensures real-time data availability“ (QlikTech, 2020). Databricks is also suitable for real-time processing and the TimescaleDB database has the functions continuous aggregates and real-time aggregation for real-time capability (Etaati, 2019; Klemm & Freedman, 2020).

R6 –Time series data: The database comparison in Section 7 shows that TimescaleDB optimally fulfils the requirement to store, analyse, and retrieve time series data.

R7 –Expandability: Through the Qlik Replicate software, additional data sources can also be connected in the future. In addition, the processing can be extended for further data and additional dashboards can be created for visualisation.

R8 –Performance and scalability: The chosen cloud environment eXtollo ensures performance and scalability, and thereby this requirement is fulfilled.

R9 –Availability: As the DTRMF is not a production-critical system, the chosen environment and technologies are sufficient.

R10 –Company requirements: The internal company standards were taken into account in the choice of technology as well as cloud environment, and thus this requirement was met.

All qualitative requirements for the DTRMF have been met, with exception of the real-time data connection, which is currently not yet available, due to organisational processes. Therefore, the architecture and the technologies chosen have proven to be well suited.

Also, to demonstrate the advantages of application of the DTRMF, we performed a comparison between the current state of the logistics backend system and its expected future state enabled by the DTRMF. The comparison is reported in Table 6, and it shows that the DTRMF provides enormous advantages, because production supply and quality can be ensured more easily, time is saved in the analysis of expired material and greater transparency is provided in all areas of the RFID-enabled material flow.

Table 6
Comparison of logistics backend system and DTRMF

Logistics backend system DTRMF

Production supply At present, it is difficult to ensure the production supply after a production break because either the expired material has to be analysed manually at an early stage, or the material with an exceeded expiration date must be tested or brought to re-drying, or new material must be reordered at short notice. Reordering at short notice with a high priority usually causes additional costs in relation to normal material orders. By using the DTRMF, it is easier to ensure the production supply after a production break, because the information provided can be used to decide at an early stage, which existing adhesive parts should be brought to the test, or which adhesive parts have to be reordered at an early stage. This ensures that no material is missing when production is restarted and has the particular advantage that there are no bottlenecks when testing the adhesive parts for a possible extension of the expiration date shortly before a restart.

Time Using the logistics backend system, the following steps must be carried out to determine which materials have an exceeded expiration date after a production break: When using the DTRMF, only the dashboard has to be opened in a browser and the end of the production break has to be entered. This process takes about 3 minutes and therefore saves a lot of time and increases the user experience.

1. Start logistics backend system

2. Open tables

3. Filter tables by material numbers

4. Export data to Excel

5. Link data of tables in Excel with each other

6. Add columns with formulas to calculate whether the material will remain durable after the production break

It is estimated that these steps will take approximately 3 hours to complete, and these steps will need to be repeated each time the data is updated. In addition, these steps must be carried out several times since it is not possible to export the data for all material numbers at once.

Quality Adhesive parts can only be placed at the station as long as the expiration date minus the remaining time is not exceeded to guarantee the quality of the vehicles. When there is a production break, it is difficult to manually check which adhesive parts are at the station and cannot be used afterwards, as there is no transaction in the logistics backend system that shows which material is placed at the stations. The DTRMF visualises the last transport orders to the stations (target storage locations), and those contain the information which material is likely to be still at the station after the production break. This allows the adhesive parts to be checked quickly and ensures that there is no material with an exceeded expiration date at the station when production resumes.

Transparency In the logistics backend system, only the existing transactions and tables can be used, which offer only limited functionalities regarding the transparency of the material flow, such as no evaluation of which adhesive parts will have expired after a production break. The DTRMF creates transparency in all areas of the entire RFID-based material flow by performing and visualising additional evaluations, such as determining the adhesive parts, which will no longer be durable after the production break. This allows the production supply to be significantly optimised.

	Logistics backend system	DTRMF
Production supply	At present, it is difficult to ensure the production supply after a production break because either the expired material has to be analysed manually at an early stage, or the material with an exceeded expiration date must be tested or brought to re-drying, or new material must be reordered at short notice. Reordering at short notice with a high priority usually causes additional costs in relation to normal material orders.	By using the DTRMF, it is easier to ensure the production supply after a production break, because the information provided can be used to decide at an early stage, which existing adhesive parts should be brought to the test, or which adhesive parts have to be reordered at an early stage. This ensures that no material is missing when production is restarted and has the particular advantage that there are no bottlenecks when testing the adhesive parts for a possible extension of the expiration date shortly before a restart.
Time	Using the logistics backend system, the following steps must be carried out to determine which materials have an exceeded expiration date after a production break:	When using the DTRMF, only the dashboard has to be opened in a browser and the end of the production break has to be entered. This process takes about 3 minutes and therefore saves a lot of time and increases the user experience.
	1. Start logistics backend system
	2. Open tables
	3. Filter tables by material numbers
	4. Export data to Excel
	5. Link data of tables in Excel with each other
	6. Add columns with formulas to calculate whether the material will remain durable after the production break
	It is estimated that these steps will take approximately 3 hours to complete, and these steps will need to be repeated each time the data is updated. In addition, these steps must be carried out several times since it is not possible to export the data for all material numbers at once.
Quality	Adhesive parts can only be placed at the station as long as the expiration date minus the remaining time is not exceeded to guarantee the quality of the vehicles. When there is a production break, it is difficult to manually check which adhesive parts are at the station and cannot be used afterwards, as there is no transaction in the logistics backend system that shows which material is placed at the stations.	The DTRMF visualises the last transport orders to the stations (target storage locations), and those contain the information which material is likely to be still at the station after the production break. This allows the adhesive parts to be checked quickly and ensures that there is no material with an exceeded expiration date at the station when production resumes.
Transparency	In the logistics backend system, only the existing transactions and tables can be used, which offer only limited functionalities regarding the transparency of the material flow, such as no evaluation of which adhesive parts will have expired after a production break.	The DTRMF creates transparency in all areas of the entire RFID-based material flow by performing and visualising additional evaluations, such as determining the adhesive parts, which will no longer be durable after the production break. This allows the production supply to be significantly optimised.

10 Conclusions and outlook

In this paper we investigate the potential of RFID data in the automotive industry logistics to automate processes and optimise material flow, by means of a DTRMF, that is a digital twin of the RFID-enabled material flow in real-time. We started by listing the different qualitative requirements that must be met by a big data and digital twin architecture in the automotive industry logistics. We then performed an extensive literature review, and we noted there is no available architecture in the literature that do optimally fulfil the requirements we listed and, at the same time, it is detailed enough to support a real application. Therefore, we propose in this paper a new architecture that consists of different layers, namely the data ingestion layer, data processing and analyses layer, data storage layer, visualisation layer, and the optional semantic layer. The suitability of this architecture was demonstrated by the implementation of a practical case study as an answer to RQ1. The case study showed that the qualitative requirements for the architecture were met, making it possible for the first time to calculate, store, and visualise the required KPIs, and to fulfil the business requirements. Additionally, the results of the case study were presented to future users of the target group of the digital twin, who confirmed that the business requirements had been met. Also, RQ2 was answered in Section 7, where suitable technologies are presented for the implementation of the DTRMF. The comparison between the cloud and the on-premises environment has shown that the cloud better meets the requirements of the DTRMF. In addition, the conducted literature review and the comparison of four databases has shown that TimescaleDB is the most suitable database for the DTRMF in real-time. The suitability of the cloud environment, as well as technologies TimescaleDB as a database and Databricks for data processing and visualisation, was proved by the implementation of the case study. Finally, the reported case study was also used to describe in detail how the DTRMF can be implemented, thus answering RQ3. For this purpose, the Docker Compose file was described for the configuration and running of the database, the steps of data pre-processing were generalised, and the creation of a dashboard using an SQL query was presented. The architecture and technologies presented here can be utilised for digital twins with similar requirements.

The next step is to realise and demonstrate the real-time data connection and to implement further case studies with big data analyses to further verify the architecture and the suitability of the proposed technologies. Once the real-time data connection exists, a detailed field test and user evaluation should be conducted to verify if all requirements for the DTRMF have been met or, conversely, if another iteration should be conducted in the design cycle. Furthermore, a semantic layer for the DTRMF could be investigated and implemented to show how data interoperability can be realised and make the data accessible to other applications. Additionally, a versioning method could be developed to update master data only in the database when changes were made to reduce the amount of data that must be stored. Furthermore, a method to compress and delete older transaction data could be developed to save storage space and improve the performance of the database by reducing the amount of data. In addition, an economic evaluation of the DTRMF in real-time could be carried out to better understand the expected costs and revenues of its full implementation.

Footnotes

Acknowledgments

We thank all those who made the success of this paper possible. Especially we thank Mercedes-Benz AG for the funding of the Ph.D. position of one of the authors.

References

Abideen,

A. Z.

, Sundram,

V. P. K.

, Pyeman,

, Othman,

A. K.

, Sorooshian,

(2021) Digital Twin Integrated Reinforced Learning in Supply Chain and Logistics. Logistics, 5(4), 84https://doi.org/10.3390/logistics5040084

Abugabah,

, Nizamuddin,

, Abuqabbeh,

(2020) A review of challenges and barriers implementing RFID technology in the Healthcare sector. Procedia Computer Science, 170, 1003–1010. https://doi.org/10.1016/j.procs.2020.03.094

Aheleroff,

, Xu,

, Zhong,

R. Y.

, Lu,

(2021) Digital Twin as a Service (DTaaS) in Industry.: An Architecture Reference Model. Advanced Engineering Informatics, 47, 101225https://doi.org/10.1016/j.aei.2020.101225

Al-Sehrawy,

, Kumar,

(2021) Digital Twins in Architecture, Engineering, Construction and Operations. A Brief Review and Analysis. In E. Toledo Santos&S. Scheer (Eds.), Proceedings of the 18th International Conference on Computing in Civil and Building Engineering (Vol. 714 98, pp. 924–939). Springer International Publishing.https://doi.org/10.1007/978-3-030-51295-8_64

Amerland,

(2015). Die Potenziale von Big-Data-Analysen sind enorm. https://www.springerprofessional.de/marktforschung/die-potenziale-von-big-data-analysen-sind-enorm/6597426

Apostu,

, Puican,

, Ulaur,

, Suciu,

, Todoran,

(2013). Study on advantages and disadvantages of Cloud Computing –the advantages of Telemetry Applications in the Cloud. Recent Advances in Applied Computer Science and Digital Services.

Berle,

(2017) Lambda vs. Kappa. https://entwickler.de/software-architektur/lambda-vs-kappa

Cilloni,

, Leporati,

, Rizzi,

, Romagnoli,

(2019) State of the art of item-level RFID deployments in fashion and apparel retail. International Journal of RF Technologies, 10(3-4), 65–88. https://doi.org/10.3233/RFT-190174

Costa,

, do Sameiro Carvalho,

, Fernandes,

J. M.

, Alves,

A. C.

, Silva,

(2017) Improving visibility using RFID –the case of a company in the automotive sector. Procedia Manufacturing, 13, 1261–1268. https://doi.org/10.1016/j.promfg.2017.09.048

10.

Databricks. (n.d.). Azure Databricks Pricing. Retrieved June 9, 2022, from https://databricks.com/de/product/azure-pricing

11.

DB-Engines. (n.d.–a). InfluxDB System Properties. Retrieved December 3, 2021, from https://dbengines.com/en/system/InfluxDB

12.

DB-Engines. (n.d.–b). MongoDB System Properties. Retrieved December 4, 2021, from https://dbengines.com/en/system/MongoDB

13.

DB-Engines. (n.d.–c). PostgreSQL System Properties. Retrieved November 15, 2021, from https://dbengines.com/en/system/PostgreSQL

14.

DB-Engines. (n.d.–d). TimescaleDB System Properties. Retrieved November 15, 2021, from https://dbengines.com/en/system/TimescaleDB

15.

DIN (1988). Informationsverarbeitung - Begriffe - Verarbeitungsablaufe (DIN 44300-9:1988-11). Deutsches Institut fur Normung e. V.

16.

Esposito,

, Romagnoli,

, Sandri,

, Villani,

(2015). Deploying RFID in the fashion and apparel sector: an “in the field” analysis to understand where the technology is going to. XX Summer School “F. Turco”, Industrial Mechanical Plants. http://summerschool-aidi.it/edition-2015/images/Naples2015/proceed/02romagnoli02.pdf

17.

Etaati,

(2019). Machine Learning with Microsoft Technologies. Apress. https://doi.org/10.1007/978-1-4842-3658-1

18.

Farmer,

(2018). Eventual Consistency: The Hinted Handoff Queue. https://www.influxdata.com/blog/eventual-consistency-hhq/

19.

Finkenzeller,

(2015). RFID-Handbuch: Grundlagen und praktische Anwendungen von Transpondern, kontaktlosen Chipkarten und NFC (7., aktualisierte und erweiterte Auflage). Carl Hanser Verlag GmbHCo KG.

20.

Fleisch,

, Mattern,

(Eds.). (2005). Das Internet der Dinge: Ubiquitous Computing und RFID in der Praxis: Visionen, Technologien, Anwendungen, Handlungsanleitungen. Springer-Verlag.

21.

Franke,

, Dangelmaier,

(Eds.). (2006). RFID-Leitfaden fur die Logistik: Anwendungsgebiete, Einsatzmoglichkeiten, Integration, Praxisbeispiele. Gabler Verlag.

22.

Freedman,

, Nordström,

(2019). Building a distributed time-series database on PostgreSQL. https://blog.timescale.com/blog/building-a-distributed-time-series-database-on-postgresql/

23.

Freedman,

, Sewrathan,

(2020). TimescaleDB vs. InfluxDB: Purpose built differently for time-series data.

24.

GeeksforGeeks. (2020). Difference between InfluxDB and PostgreSQL. https://www.geeksforgeeks.org/difference-between-influxdb-and-postgresql/

25.

Goll,

(2014). Architektur- und Entwurfsmuster der Softwaretechnik. Springer Fachmedien Wiesbaden. https://doi.org/10.1007/978-3-658-05532-5

26.

Greis,

N. P.

, Nogueira,

M. L.

, Rohde,

(2021). Digital Twin Framework for Machine Learning- Enabled Integrated Production and Logistics Processes. In A. Dolgui (Ed.), IFIP advances in information and communication technology: 630-634, Advances in production management systems: Artificial intelligence for sustainable and resilient production systems : IFIP WG 5.7 International Conference, APMS 2021, Nantes, France, September 5-9, 2021, proceedings 767 (pp. 218–227). Springer.

27.

Grieves,

(2014). Digital Twin: Manufacturing Excellence through Virtual Factory Replication. https://www.3ds.com/fileadmin/PRODUCTS-SERVICES/DELMIA/PDF/Whitepaper/DELMIAAPRISO-Digital-Twin-Whitepaper.pdf

28.

GS1 (November 2019). EPC Tag Data Standard (1.13).

29.

GS1 (2022). Core Business Vocabulary (CBV) Standard (Release 2.0). https://ref.gs1.org/standards/cbv/

30.

Guerreiro,

, Figueiras,

, Costa,

, Marques,

, Graca

, Garcia,

, Jardim-Goncalves,

(2019). A Digital Twin for Intra-Logistics Process Planning for the Automotive Sector Supported by Big Data Analytics. In ASME International Mechanical Engineering Congress and Exposition (Volume 2B: Advanced Manufacturing). https://doi.org/10.1115/IMECE2019-11362

31.

Haße,

, Li,

, Weißenberg,

, Cirullies,

, Otto,

(2019). Digital twin for real-time data processing in logistics. InW. Kersten, T. Blecker, & C.M. Ringle (Eds.), Proceedings of the Hamburg International Conference of Logistics (HICL): Vol. 27. Proceedings of the Hamburg International Conference of Logistics (HICL)/ Artificial Intelligence and Digital Transformation in Supply Chain Management: Innovative Approaches for Supply Chains (10th ed.). epubli. https://doi.org/https://doi.org/10.15480/882.2462

32.

Hevner,

, Chatterjee,

, Keine Angabe (2010). Design research in information systems: Theory and practice. Integrated series in information systems: Vol. 22. Springer.

33.

Hevner,

, March,

S. T.

, Park,

, Ram,

(2004) Design Science in Information Systems Research. MIS Quarterly, 28(1), 75–105. https://doi.org/10.2307/25148625.

34.

Hsieh,

, Perry,

(2019). Why you should use a relational database instead of NoSQL for your IoT application. https://blog.timescale.com/blog/use-relational-database-instead-of-nosql-for-iot-application/

35.

Influxdata. (n.d.–a). Glossary. Retrieved December 3, 2021, from https://docs.influxdata.com/influxdb/v2.0/reference/glossary/#influxql

36.

Influxdata. (n.d.–b). InfluxDB Editions. Retrieved December 4, 2021, from https://www.influxdata.com/products/editions/

37.

Influxdata. (n.d.–c). InfluxQL Continuous Queries. Retrieved January 11, 2022, from https://docs.influxdata.com/influxdb/v1.8/querylanguage/continuousqueries/

38.

Influxdata. (n.d.–d). Process data with InfluxDB tasks. Retrieved January 11, 2022, from https://docs.influxdata.com/influxdb/v2.1/process-data/

39.

Insausti,

(2019). Scaling PostgreSQL for Large Amounts of Data. https://severalnines.com/databaseblog/scaling-postgresql-large-amounts-data

40.

ISO (2021). Automation systems and integration - Digital twin framework - Part 2: Reference architecture for manufacturing (ISO 23247-2:2021(E)).

41.

ISO/IEC (2011). Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models (ISO/IEC 25010:2011).

42.

Jamwal,

, Agrawal,

, Sharma,

, Pratap,

(2021) Industry 4.0: An Indian Perspective. In A. Dolgui (Ed.), IFIP advances in information and communication technology: 630-634, Advances in production management systems: Artificial intelligence for sustainable and resilient production systems : IFIP WG 5.7 International Conference, APMS 2021, Nantes, France, September 5-9, 2021, proceedings (pp. 113–123.). Springer.

43.

Jayaram,

(2020). How to work with data using MongoDB Query Language. https://blog.quest.com/howto-work-with-data-using-mongodb-query-language/

44.

Kiefer,

(2017). TimescaleDB vs. PostgreSQL for time-series: 20x higher inserts, 2000x faster deletes, 1.2x-14,000x faster queries. https://blog.timescale.com/blog/timescaledb-vs-6a696248104e/

45.

Kiefer,

, Sewrathan,

, Toth,

(2020). How to store time-series data in MongoDB, and why that’s a bad idea. https://blog.timescale.com/blog/how-to-store-time-series-data-mongodb-vs-timescaledbpostgresql-a73939734016/

46.

Kirch,

, Poenicke,

, Richter,

(2017) RFID in Logistics and Production –Applications, Research and Visions for Smart Logistics Zones. Procedia Engineering, 178, 526–533. https://doi.org/10.1016/j.proeng.2017.01.101

47.

Klein,

, Tran-Gia,

, Hartmann,

(2013) Big Data. Informatik-Spektrum, 36(3), 319–323. https://doi.org/10.1007/s00287-013-0702-3

48.

Klemm,

, Freedman,

(2020). Achieving the best-of-both worlds: Ensuring up-to-date 820 results with Real-Time Aggregation. https://blog.timescale.com/blog/achieving-the-best-of-both-worlds-ensuringup-to-date-results-with-real-time-aggregation/

49.

Klostermeier,

, Haag,

, Benlian,

(2020). Geschaftsmodelle Digitaler Zwillinge: HMD Best Paper Award 2018. Springer Fachmedien Wiesbaden GmbH.

50.

Knapp,

, Romagnoli,

(2021) RFID systems optimisation through the use of a new RFID network planning algorithm to support the design of receiving gates.Advance online publication. Journal of Intelligent Manufacturing.https://doi.org/10.1007/s10845-021-01858-0

51.

Korth,

, Schwede,

, Zajac,

(2018). Simulation-ready digital twin for realtime management of logistics systems. In 2018 IEEE international conference on big data (big data) (pp. 4194–4201). https://doi.org/10.1109/BigData.2018.8622160

52.

Kreps,

(2014). Questioning the Lambda Architecture: The Lambda Architecture has its merits, but alternatives are worth exploring. https://www.oreilly.com/radar/questioning-the-lambda-architecture/

53.

Lietaert,

, Meyers,

, van Noten,

, Sips,

, Gadeyne,

(2021). Knowledge Graphs in Digital Twins for AI in Production. In A. Dolgui (Ed.), IFIP advances in information and communication technology: 630-634, Advances in production management systems: Artificial intelligence for sustainable and resilient production systems : IFIP WG 5.7 International Conference, APMS 2021, Nantes, France, September 5-9, 2021, proceedings (pp. 249–257). Springer.

54.

Lin,

(2017) The lambda and the kappa. IEEE INTERNET COMPUTING, 21(05), 60–66.

55.

Marz,

(2011). How to beat the CAP theorem. http://nathanmarz.com/blog/how-to-beat-the-captheorem.html

56.

McCulloch,

(2020). How To Set Up Physical Streaming Replication with PostgreSQL 12 on Ubuntu 20.04. https://www.digitalocean.com/community/tutorials/how-to-set-up-physical-streamingreplication-with-postgresql-12-on-ubuntu-20-04.

57.

Meier,

(2018). Konsistenzsicherung mit ACID oder BASE. In Werkzeuge der digitalen Wirtschaft: Big Data, NoSQL&Co.: Eine Einfuhrung in relationale und nicht-relationale Datenbanken (pp. 29–36). Springer Fachmedien Wiesbaden.https://doi.org/10.1007/978-3-658-20337-5_6

58.

Mercedes-Benz Group AG. (n.d.). eXtollo Our Big Data Platform. Retrieved June 7, 2022, from https://group.mercedes-benz.com/careers/about-us/artificial-intelligence/community-andtools/extollo.html

59.

Merkle,

, Segura,

A. S.

, Grummel,

J. T.

, Lienkamp,

(2019). Architecture of a Digital Twin for Enabling Digital Services for Battery Systems. In 2019 IEEE International Conference on Industrial Cyber Physical Systems (ICPS) (pp. 155–160). IEEE.https://doi.org/10.1109/ICPHYS.2019.8780347

60.

MongoDB. (n.d.–a). Change Streams. Retrieved January 10, 2022, from https://docs.mongodb.com/manual/changeStreams/

61.

MongoDB. (n.d.–b). How to Scale MongoDB. Retrieved December 4, 2021, from https://www.mongodb.com/basics/scaling

62.

MongoDB. (n.d.–c). MongoDB – FAQ. Retrieved January 10, 2022, from https://www.mongodb.com/dede/faq

63.

MongoDB. (n.d.–d). What are ACID Transactions? Retrieved January 10, 2022, from https://www.mongodb.com/basics/acid-transactions

64.

Morefield Communications. (2022). ON-PREMISES VS. CLOUD. https://www.morefield.com/blog/onpremises-vs-cloud/

65.

Moretti,

E. d. A.

, Anholon,

, Rampasso,

I. S.

, Silva,

, Santa-Eulalia,

L. A.

, Ignácio,

P. S. d. A.

(2019) Main difficulties during RFID implementation: an exploratory factor analysis approach. Technology Analysis & Strategic Management, 31(8), 943–956. https://doi.org/10.1080/09537325.2019.1575351.

66.

Niaki,

S. V. D.

, Shafaghat,

(2021) A Review of The Concept of ‘Supply Chain Digital Twin’ in The Era of Industry. Journal of Applied Intelligent Systems and Information Sciences, 2(2), 47–57. https://doi.org/10.22034/jaisis.2021.317742.1038

67.

Pan,

Y. H.

, Qu,

, Wu,

N. Q.

, Khalgui,

, Huang,

G. Q.

(2021) Digital Twin Based Real-time Production Logistics Synchronization System in a Multi-level Computing Architecture. Journal of Manufacturing Systems, 58, 246–260. https://doi.org/10.1016/j.jmsy.2020.10.015

68.

PostgreSQL. (n.d.–a). About. Retrieved December 2, 2021, from https://www.postgresql.org/about/

69.

PostgreSQL. (n.d.–b). Table Partitioning. Retrieved December 873 15, 2021, from https://www.postgresql.org/docs/10/ddl-partitioning.html

70.

PostgreSQLTutorial. (n.d.). PostgreSQL Materialized Views. Retrieved January 5, 2022, from https://www.postgresqltutorial.com/postgresql-materialized-views/

71.

QlikTech. (n.d.–a). Supported source endpoints. Retrieved June 9, 2022, from https://help.qlik.com/en-US/replicate/November2021/Content/Replicate/Main/Support%20Matrix/supported_source_endpoints.htm

72.

QlikTech. (n.d.–b). Supported target endpoints. Retrieved June 9, 2022, from https://help.qlik.com/en-US/replicate/November2021/Content/Replicate/Main/Support%20Matrix/supported_target_endpoints.htm

73.

QlikTech. (2020). More Data, Analytics-Ready: White paper. https://www.qlik.com/us/-/media/files/resource-library/global-us/direct/datasheets/ds-qlik-accelerate-your-data-pipeline-en.pdf

74.

Redelinghuys,

, Basson,

, Kruger,

(2019) A Six-Layer Digital Twin Architecture for a Manufacturing Cell. In T. Borangiu, D. Trentesaux, A. Thomas,&S. Cavalieri (Eds.), Service Orientation in Holonic and Multi-Agent Manufacturing (Vol. 803, pp. 412–423). Springer International Publishing.https://doi.org/10.1007/978-3-030-03003-2_32

75.

Rehman,

(2021). Horizontal Scalability Options in PostgreSQL. https://www.highgo.ca/2021/08/09/horizontal-scalability-options-in-postgresql/

76.

Richter,

(2013). Nutzenoptimierter RFID-Einsatz in der Logistik: Eine Handlungsempfehlung zur Lokalisierung und Bewertung der Nutzenpotenziale von RFID-Anwendungen. Schriftenreihe Logistik der Technischen Universitat Berlin: Vol. 23. Universitatsverlag der TU Berlin.

77.

Sanla,

, Numnonda,

(2019). A Comparative Performance of Real-time Big Data Analytic Architectures. In 2019 IEEE 9th International Conference on Electronics Information and Emergency Communication (ICEIEC) (pp. 1–5). IEEE. https://doi.org/10.1109/ICEIEC.2019.8784580

78.

SAP. (n.d.). Datenart von Datenbanktabellen. Retrieved June 7, 2022, from https://help.sap.com/doc/abapdocu_750_index_htm/7.50/de-de/abenddic_database_tables_dat_type.htm

79.

Schaedel,

(2018). Batch Processing vs. Stream Processing: What’s the Difference? https://www.influxdata.com/blog/batch-processing-vs-stream-processing/

80.

Scholz,

(2005). Softwareentwicklung eingebetteter Systeme. Springer Berlin Heidelberg. https://doi.org/10.1007/3-540-27522-3

81.

Souza,

, Cruz,

, Silva,

, Lins,

, Lucena,

(2019). A Digital Twin Architecture Based on the Industrial Internet of Things Technologies. In 2019 IEEE International Conference on Consumer Electronics (ICCE) (pp. 1–2). IEEE.https://doi.org/10.1109/ICCE.2019.8662081

82.

Steindl,

, Stagl,

, Kasper,

, Kastner,

, Hofmann,

(2020) Generic Digital Twin Architecture for Industrial Energy Systems. Applied Sciences, 10(24), 8903https://doi.org/10.3390/app10248903

83.

Talkhestani,

B. A.

, Jung,

, Lindemann,

, Sahlab,

, Jazdi,

, Schloegl,

, Weyrich,

(2019) An architecture of an Intelligent Digital Twin in a Cyber-Physical Production System. At - Automatisierungstechnik, 67(9), 762–782. https://doi.org/10.1515/auto-2019-0039

84.

Tao,

, Zhang,

, Liu,

, 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

85.

TimescaleDocs. (n.d.–a). Query your data. Retrieved December 17, 2021, from https://docs.timescale.com/timescaledb/latest/getting-started/query-data/#advanced-sql-functionsfor-time-series-data

86.

TimescaleDocs. (n.d.–b). Replication. Retrieved January 5, 2022, from https://docs.timescale.com/timescaledb/latest/how-to-guides/replication-and-ha/replication/#configurethe-primary-database

87.

Tu,

Y.-J.

, Chi,

, Zhou,

, Kapoor,

, Eryarsoy,

, Piramuthu,

(2019). Critical Evaluation of RFID Applications in Healthcare. In R. Doss, S. Piramuthu, & W. Zhou (Eds.), Future Network Systems and Security (pp. 240–248). Springer International Publishing.

88.

Uckelmann,

, Harrison,

, Michahelles,

(2011) An Architectural Approach towards the Future Internet of Things. In D. Uckelmann, M. Harrison,&F. Michahelles (Eds.), Architecting the Internet of Things (pp. 1–24). Berlin: Springer.

89.

Uckelmann,

, Romagnoli,

(2016). RF-based Locating of Mobile Objects. In A. Schmidt, F. Michahelles, S. Schneegass, M. Kritzler, A. Ilic,&K. Kunze (Eds.), Proceedings of the 6th International Conference on the Internet of Things (pp. 147–154). ACM. https://doi.org/10.1145/2991561.2991565

90.

VDA (2011). Großladungstrager (GLT-) System (VDA 4520, Version 2.0). Verband der Automobilindustrie.

91.

VDA (2018). Kleinladungstrager (KLT-) System (VDA 4500, Teil 1, Version 2.0). Verband der Automo bilindustrie.

92.

Wingerath,

(2017). A Real-Time Database Survey: The Architecture of Meteor, RethinkDB, Parse & Firebase. https://medium.baqend.com/real-time-databases-explained-why-meteor-rethinkdb-parse-and-firebase-dont-scale-822ff87d2f87

Architecture	Application area	Goals and key points of the architecture	Structure of the architecture	Type of data sources and data	Technologies forimplementation	Implementation of architecture	Level of the description	R1: Big data analyses	R2: Development time	R3: Maintainability	R4: Data interoperability
Lambda architecture (Marz, 2011)	Big Data	- Architecture “beats the CAP theorem” (Marz, 2011)	Three layers: batch, serving and speed layer	No specific data sources / type of data
		- “Highly general and can be applied to any data system” (Marz, 2011)
Kappa Architecture (Kreps, 2014)	Big Data	- Contains no batch layer	Two layers: speed layer (messaging system, stream processing), serving layer	No specific data sources / type of data
		- Only stream processing
Lambda architecture for real-time IoT analytics in logistics (Haße et al., 2019)	Logistics, forklift control system	- Integrates KPIs into the digital twin	Four layers: data acquisition, data processing, data visualisation, semantic layer	Microcontroller, sensors (e.g. position, acceleration, localisation, motion)
		- Analysis and processing of real-time IoT data
		- Architecture with reference to concrete application
		- Based on lambda architecture
		- Contains a semantic layer
Architecture for simulation-ready digital twin for real-time management of logistics systems (Korth et al., 2018)	Logistics, decision support system	- Architecture “combines a realtime digital twin of logistics systems with simulation” (Korth et al., 2018)	Six components: event-controller, simulation, logbook, model, reporting, persistence	Scanners (barcode / RFID), sensors, and bookings in a warehouse management system					–	–	–
		- “Efficient integration of event-discrete simulation into a digital twin architecture” (Korth et al., 2018)
Cloud-fog-edge-based digital twin control framework (Pan et al., 2021)	Logistics	- “Multi-level cloud computing enabled digital twin system for the real-time monitor, decision and control of a synchronized production logistics system” (Pan et al., 2021)	Two layers: physical layer (entity &IoT, control strategy, computing, local optimiser dimension) and virtual layer (model center, data center, synchronisation control center)	“real-time data of production elements (personnel, machine tool, vehicles and cargo)“ (Pan et al., 2021)
		- Edge computing, fog computing, and cloud computing for different dynamics
		- Synchronisation mechanism
Digital twin architecture for enabling digital services (Merkle et al., 2019)	Automotive battery systems	- Reference architecture for a digital twin of manufacturing and product life cycle of a battery system to enable digital services	Three layers: hardware + connectivity, twin level, service level	Sensors, machinery, data loggers, manufacturing execution system, enterprise resource planning system					–	–
		- Contains a UML (Unified Modeling Language) meta model
Digital twin reference architecture model in industry 4.0 (Aheleroff et al., 2021)	Industry 4.0, wetland schedule maintenance	- Reference architecture consists of three axis: digital twin layers, agile process and digital twin integration levels	Five digital twin layers: physical, communication, digital, cyber, application layer	Sensor data					–	–
		- “first attempts to build Digital Twin toward mass individualization” (Aheleroff et al., 2021)
		- Digital twin as a service
Intelligent digital twin architecture (Talkhestani et al., 2019)	Production, assistence system / smart warehouse with climate control / field of metal forming	- Intelligent Digital Twin in cyber-physical production system (CPPS)	Data-acquisiton interface, synchronisation interface, operation data, relations, DT version management, modell, ID, organisational / technical specification, feedback interface, intelligent algorithm, service, DT model comprehension, co-simulation interface	Programmable logic controller (PLC) code of the PLC-controlled system, XML					–	–
		- Ancher-point-method for synchronisation
		- Integration and processing of the real operation data
		- Enabling co-simulation between digital twins
		- Automated control of physical assets via the digital twin
Architecture for a digital twin for intra-logistics process planning (Guerreiro et al., 2019)	Logistics, process planning	- Provides a technology stack for the architecture	Five layers: data collection and ingestion, data storage, data processing engines, query-analytics-visualisation, others (APIs, reverse proxy coordination, deployment)	Sources: services, files, RDBMS, data: manufacturing data, engineering data, product &process data, automated storage, retrieval of parts, supply chain data					–	–
		- Contains information on the deployment with docker and docker swarm orchestration
		- Contains 3D visualisation of the digital twin
Six-layer digital twin architecture (Redelinghuys et al., 2019)	Manufacturing cell	- Architecture takes into account emulation and simulation	Six layers: physical devices, local controllers, local data repositories, IoT gateway, cloud based information repositories, emulation and simulation	Sensors, PLCs						–
		- Open Platform Communications Unified Architecture (OPC UA) servers are used
		- IoT gateway (layer 4) is optional
Digital twin architecture based on the industrial internet of things technologies (Souza et al., 2019)	IIoT	- Uses OPC UA	Three components: physical twin, IIoT gateway, and internal server (digital twin)	Sensors, PLCs					–	–
		- Based on industrial internet of things technologies
		- Provides two views: one inside the workplace for critical processes and one outside the workplace
Generic digital twin architecture (Steindl et al., 2020)	Industrial energy systems, thermal energy storage system	- Technology-independent architecture	Six layers: asset, integration, communication, information, functional, business	Sensors, events					–	–
		- Reference Architecture Model Industry 4.0 (RAMI4.0) was used
		- Focus on shared knowledge base and ontology concepts
		- Service oriented architecture
ISO 23247-2 –Digital twin framework for manufacturing –reference architecture (ISO, 2021)	Manufacturing	- “Reference architecture provides guidance for implementing digital twins in manufacturing” (ISO, 2021)	Four domains: observable manufacturing, device communication, digital twin, user domain	Sensors					–	–
		- The communication entity contains a device control subentity to control the OMEs (Observable Manufacturing Element)

Goal	The aim of this case study is to ensure production supply by determining at an early stage whether new adhesive parts are needed or existing adhesive parts need to be sent to the re-drying after a production break because the existing ones are no longer durable.
Target group	Production supply of the body shop
Description	Adhesive parts have an expiration date. If this is exceeded, the adhesive becomes too moist, and the component must either be scrapped or sent for re-drying, which, however, is time-consuming and associated with costs, and is therefore only profitable for expensive components. If there are production breaks due to delivery bottlenecks or block breaks, it is time-consuming to determine whether the adhesive parts can still be used afterwards, whether new material must be ordered shortly before production starts up again, or whether existing adhesive parts must be sent to re-drying early enough. For this purpose, there should be an input mask where the end of the production break is entered and an algorithm then automatically determines whether the adhesive parts can still be used afterwards or whether they have to be ordered again or have to be dried. In this way, it can be ensured that the required material is available and can be used when production starts after the production break.
Required systems	This case study requires data from the logistics backend system (SAP solution AmSupply), which is stored in an Oracle database.
KPI (Key Performance Indicator)	The KPIs that have to be calculated in this case study are the expiration date without remaining time and the number of days after the end of production for each load carrier.