Keywords

1 Introduction

Highly competitive markets and short product lifecycle push current production systems to adapt more proactive production plans. Computer-aided planning provides analysis capabilities for production systems in real-time and perform on-site optimization to meet production demands [11]. Moreover, customer-centric production lines need to schedule assembly-line operations for personalized products manufacturing. This need for real-time modification and resource allocation of production plans raises up the concept of cyber-physical production systems (CPPS) [3]. Digital Twin (DT) has been a highly active research topic lately because of its real-time analysis and managing capabilities. The emergence of information and communication technologies (ICT), and internet-of-things (IoT) in industrial manufacturing domain created potential economic value for the DT technology [11]. The role of DT in CPPS is to provide the real-time status of the physical system. This enables it to perform scheduling, simulation, and optimization to manage the production proactively.

DT term is usually used to define three different concepts [10]; product twin for product lifecycle management (PLM), production twin for customer-centric production systems, and system twin for CPPS.

1.1 Production Systems

Despite the massive focus on Industry4.0 topics in the academic domain, the industry is still studying the needed changes in their infrastructure to adopt the Industry4.0 technologies. In-service manufacturing systems still utilize the Purdue automation pyramid [1, 8]. These businesses are lagging behind due to the high cost of upgrading the manufacturing lines. The upgrading costs include installation cost, production plan interruptions, and production line stoppages.

Large investments have been specified for DT technology. Newly constructed production facilities are best suited for Industry4.0 concepts as they utilize state-of-the-art equipment. However, small and medium-sized enterprises (SME) are more adaptive than standard large enterprises and complex businesses because of governmental initiatives [4].

Current production systems depend on central supervisory control and data acquisition (SCADA) server to collect information from shop-floor machines and send control commands to these machines. As production systems currently use industrial Ethernet, most equipment communicate with the SCADA server through OPC Unied Architecture (OPC-UA) protocol [6]. The central server stores the collected data into Historian database. Human operators interact with the machines via on-site terminals, or off-site connection to the SCADA server. System analysis is usually performed offline on the data collected and extracted from the historian database. Figure 1 shows the system architecture of data gathering, management, and planning in traditional production systems.

Fig. 1.
figure 1

Traditional approach for data gathering, management, and planning

Full size image

1.2 Related Work

The number of publications are increasing in the field of Digital Twin. Most of the publications concentrated on DT applications [1]. While, some publications focused on the development of the DT framework [5, 6, 9, 12].

The differentiation between DT and Digital Shadow (DS) terms is still an ongoing discussion. Two main groups of thoughts exist; The first opinion differentiate between the two terms according to the data-flow direction between the virtual and physical worlds [1, 10]. In Digital Shadow, the physical world sends data to its corresponding virtual model. While in Digital Twin, the data-flow is bidirectional, from/to the physical world. This definition tends to describe DT as an upgraded version of DS. The second opinion uses Digital Twin term as a high-fidelity model, compared to the low-fidelity of Digital Shadow [1].

There is no clear separation between the roles of DS and DT in literature. Schuh et al. [7] defined DS a digitalization of the real manufacturing process, where a virtual copy of the factory is created using simulation models. However, they did not discuss the difference between DS and DT. Stark et al. [8] proposed an intersected functionality of DS and DT, for which DS term is used as the change in the digital model of the physical system over time. DT term refers to an instance of the digital model and its shadow, in which DT instance is used in system analysis and simulation.

1.3 Contribution

In this paper, we differentiate between DS and DT in terms of objectives and components. Digital shadow is defined as a model-based virtual state of the physical world collected in real-time. While digital twin is defined as real-time decision-support sandbox based on digital shadow. We use DS as a component of DT, which provides real-time state for DT functionalities. DS is connected to the physical world using current communication technologies. The main goal of using currently utilized communication technologies is to reduce the DT installation cost and encourage complex production systems to adapt Industry4.0 paradigm.

The rest of the paper is organized as follows; The proposed framework for DS and DT is presented in Sects. 2 and 3 respectively. The framework integration with the production system’s components is discussed in Sect. 4. Finally, the conclusion is presented in Sect. 5.

2 Digital Shadow

Digital Shadow (DS) is defined as a digital replica of a physical component, system, or system of systems. This digital replica matches its physical counterpart’s state in real-time. Digital Model (DM) describes the physical world’s behavior in response to internal and external factors through time. Hence, we can define a DM as a mathematical model, behavioral model, data-driven model, or even a collection of data. The goal is to mirror the physical world in a digital form. We can summarize the objectives of a DS as follows;

  1. 1.

    Create an abstract model for the physical system.

  2. 2.

    Provide the state of the physical system in real-time.

  3. 3.

    Visualize the virtual state of the system.

  4. 4.

    Compare the virtual state to the physical state.

  5. 5.

    Update the physical system’s configuration in the abstract model.

  6. 6.

    Update the abstract model to match the physical system’s behavior.

DS is divided into components according to functionality. The DS architecture is developed as a service as shown in Fig. 2. Each component is a service that interacts with other components through a publish/subscribe messaging system.

Fig. 2.
figure 2

A Digital Shadow architecture

Full size image

Factory Gateway is an OPC-UA client application, which is installed on a small board. The gateway is connected to the SCADA server through a bus network topology. Upon receiving an OPC-UA message, the gateway converts the message into a set of <key, value> messages that is sent to the DS coordinator.

The use of passive data collecting technique allows the DS to read OPC-UA messages that the SCADA server receives. Accordingly, the SCADA server is not interrupted or requested to send data to the DS all the time. This approach reduces the overhead communication of passing all the manufacturing facility’s information from the SCADA server to higher layers in real-time [2].

DS Coordinator manages the communication between the different DS components. The coordinator’s message broker works as a middleware that relays messages from publishing components to subscribing DMs. The factory gateway publishes all received data onto the message broker, while DMs publish their virtual states. Each DM subscribes for the physical and virtual data that it needs. Moreover, the coordinator maintains a global state of the physical and virtual system from all the models in the DS pool. The global state is synchronized across all DMs using logical time synchronization. The DMs system time is synchronized by the coordinator using network time protocol.

DS Pool is a collection of all DM objects that are running in the DS framework. A DM object is initiated by the DM pool manager. On construction, the DM object subscribes to a list of required keys. Then, it sends a synchronization request to the coordinator. Upon synchronization, the DM runs the model in a real-time mode.

DM library is a database of all the DMs source models. A DM object is created from one of the models provided by the library. Moreover, the library tracks the version of each DM source model. This enables the modification of an initiated DM during runtime.

DS Gateway provides access to the global physical and virtual states. DT and user interface send data requests to the DS gateway using HTTP request protocols as a query for list of keys. The gateway then responds by the requested data from the global state provided by the coordinator. The requested data keys can refer to values published by the physical system or DMs.

3 Digital Twin

Digital Twin (DT) is defined as a real-time decision-support sandbox, which uses real-time digital representation of the physical component, system, or system of systems. By this definition, DS is used by DT to represent the physical world in real-time. While, DT provides a higher-level intelligence. We define intelligence in this context as any knowledge-based application that uses simulation, scheduling, searching, optimization, diagnosis, prognosis, and/or performance evaluation to help the decision maker in improving the efficiency of the production system. Intelligence applications can range from basic pre-programmed calculations, to artificial intelligence (AI) and machine learning (ML).

The separation between the virtual model in DS and intelligence in DT, eases the adaptability of the DT framework for new applications. DT applications read the state and model through a systematic approach. However, this generalization requires DMs to provide both real-time and simulation-time capabilities. This simulation-time speed differs from DS speed, which is required to match the physical world’s pace. DT uses the DS real-time state to apply one or more of the following objectives:

  1. 1.

    Analyze the physical/virtual system’s performance

  2. 2.

    Initialize simulation tools with the current virtual state.

  3. 3.

    Evaluate production policies.

  4. 4.

    Optimize shop-floor schedules.

  5. 5.

    Optimize maintenance plan.

  6. 6.

    Estimate an order price and delivery date.

  7. 7.

    virtual commissioning (VC) of equipment and/or product.

The DT framework is divided into components as shown in Fig. 3. Each component is an object that interacts with other components in a form of request/response messages.

Fig. 3.
figure 3

A Digital Twin architecture

Full size image

DT Manager coordinates between the different components of the DT’s framework. The manager provides the needed data to the DT sandbox and passes its results to the user. The manager loads DMs from the DM library with their DS-configuration, in order to create a real representation instance for intelligence tasks.

DT Sandbox is a workspace for intelligence tasks. The sandbox provides necessary tools for these tasks as behavioral simulators, physics simulators, optimizers, and schedulers. Each tool is integrated into the sandbox using an API interface, which enables loading the tool with models and initial states. The sandbox initiates independent process for each task upon user request. Then, the tasks are initialized by real representation instances. Finally, task results are provided to the user through the DT manager.

Task Library is a set of intelligence scripts and procedures that use simulation, optimization, and machine learning to perform one of the intended objectives of the DT. A task script is executed by the DT sandbox. However, the task script is called from the DT manager. The task script specifies the tool to be used from the DT sandbox, the tool settings, and the DMs to be used in the run. Historical data can be used by the DT sandbox tools.

DT Gateway provides a user interface for the DT functionalities. Users access DT manager through a web interface using HTTP requests. This interface provides the user with the capability to view the real-time state, run intelligent tasks, review task results, and modify the DM library and task library.

4 Integration in Automation Process

In this section, we discuss two main aspects of the DT framework and its interaction with the other components of the automation pyramid; the feedback to the physical world, and the integration with MES/ERP.

4.1 Feedback to Physical World

The proposed DT framework does not explicitly define a way to control the physical system. However, the addition of a feedback connection to the SCADA server can be done through the DT gateway. In that sense, a DT system can be categorized as controlling or non-controlling. Non-controlling DT generates data insights and recommendations only. While, controlling DT uses a decision-maker module that controls the physical world through the SCADA server, as shown in Fig. 4.

Fig. 4.
figure 4

A controlling Digital Twin

Full size image

4.2 Integration with MES/ERP

DT differs from MES and ERP. It uses the real representation of the physical system with its current state. While MES/ERP uses nominal representation of the system, which induces higher abstraction error. The DT framework extends the MES/ERP by providing multiple operations as order dispatching, scheduling, virtual commissioning, maintenance planning, resource management, performance prediction, and estimation of price and delivery time. A MES/ERP module can directly command the DT framework through the DT gateway. The common scope between all DT applications is the use of the current state of the manufacturing facility as an initial state of the intelligence tool. Moreover, real representation of each component is used instead of nominal ones.

5 Conclusion

In this paper, we proposed the separation of functionalities between Digital Shadow and Digital Twin to describe a framework for DT deployment. Determination of roles provides a clearer view of the DT concept. Additionally, the separation of digital models from the higher intelligence allows wide range of DT applications to be applied on the same framework. We proposed a DT framework based on message-oriented communication between its components. The proposed framework provides real-time representation for users and high-level applications. Moreover, it provides a generic approach to extend the DT given new applications.