A six-layer architecture for the digital twin: a manufacturing case study implementation

Abstract

Industry 4.0, cyber-physical production systems (CPPS) and the Internet of Things (IoT) are current focusses in automation and data exchange in manufacturing, arising from the rapid increase in capabilities in information and communication technologies and the ubiquitous internet. A key enabler for the advances promised by CPPSs is the concept of a digital twin, which is the virtual representation of a real-world entity, or the physical twin. An important step towards the success of Industry 4.0 is the establishment of practical reference architectures. This paper presents an architecture for such a digital twin, which enables the exchange of data and information between a remote emulation or simulation and the physical twin. The architecture comprises different layers, including a local data layer, an IoT Gateway layer, cloud-based databases and a layer containing emulations and simulations. The architecture can be implemented in new and legacy production facilities, with a minimal disruption of current installations. This architecture provides a service-based and real-time enabled infrastructure for vertical and horizontal integration. To evaluate the architecture, it was implemented for a small, but typical, physical manufacturing system component.

Introduction

Cyber-physical systems (CPSs), the Industrial Internet of Things (IIoT) and cloud computing contribute to establishing the fourth industrial revolution, also known as Industry 4.0 (Industrie 4.0 in Germany). Industry 4.0, also associated with the term “smart factory”, introduces the monitoring of physical entities in a digital environment or cyberspace (Monostori et al. 2016). Industry 4.0 is defined as the next phase in the digitization of the manufacturing sector, driven by four disruptions: the astonishing rise in data volumes, computational power and connectivity; the emergence of analytics and business-intelligence capabilities; a growing need for human–machine interaction and integration; and improvement in transferring digital information to the physical world (Baur and Wee 2015). Industry 4.0, as the new digital age of manufacturing, aims at creating the next generation of innovative intelligent machines (Morgan and O’Donnell 2018).

Industry 4.0 is focused on creating a smart, networked world with smart products, procedures and processes. The future under Industry 4.0 strives to deliver greater flexibility, robustness and high-quality standards in engineering, manufacturing, planning, operational and logistics processes. It promises to deliver dynamic and real-time self-organizing value chains that can be optimized based on a variety of criteria such as cost, availability and resource consumption (Kagermann et al. 2013). Oztemel and Gursev (2018) mentions that future manufacturing, in the context of Industry 4.0, will comprise of intelligence, communications and information networks.

CPSs can be defined as a set of embedded physical devices, objects and equipment that interacts with the cyberspace through a communication network (Baheti and Gill 2011; Schroeder et al. 2016). Embedded systems and sensors are increasingly being wirelessly connected with each other and the internet. This results in convergence of the physical and cyberspace in the form of CPSs (Kagermann et al. 2013). This reflects a vision to integrate the physical world with the digital information world. Industry 4.0 can also be characterized by CPPSs, which is the integration of CPSs into manufacturing systems (Lee and Seshia 2017; Lee et al. 2015; Leitão et al. 2016; Monostori et al. 2016).

CPSs are characterized by two main functional components: firstly, advanced connectivity that ensures real-time data acquisition from embedded components and feedback from the virtual world; and, secondly, intelligent data management, analytics and computational capability that forms part of the virtual space (Bagheri and Lee 2015; Lee et al. 2015). Lee and Seshia (2017) mention that the communication between physical and cyber elements is of great concern: “As an intellectual challenge, CPS is about the intersection, not the union, of the physical and the cyber. It is not sufficient to separately understand the physical components and the computational components. We must instead understand their interaction”.

CPSs involve a high degree of complexity and highly-networked communication integration between physical and cyber elements. CPSs are rapidly increasing and changing businesses’ and companies’ perspectives to a more adaptable and flexible environment. CPSs already have a major impact in transportation, health and medical equipment, telecommunications, manufacturing, user electronics, smart grids and intelligent buildings. Systems will rely less on human decision-making and more on computational intelligence as they continue to evolve. A major challenge will be to design systems that are dependable, reliable, safe and secure (National Institute of Standards and Technology 2013).

A key enabler for the advances promised by CPPSs and Industry 4.0 is the concept of a digital twin, which is the virtual representation of a real-world entity, or physical twin. The digital twin is an emerging technology and a key consideration for interaction between the virtual and physical worlds, in the context of Industry 4.0. Kagermann et al. (2013) mention that a key to the success of Industry 4.0 is the establishment of practical reference architectures. This aspect includes the need to develop service-based and real-time enabled infrastructures for vertical and horizontal integration. They also mention that these infrastructures need to be standardized to be used by different companies and disciplines.

The paper presents a six-layer architecture for a digital twin that enables data and information exchange between cyberspace and the physical twin. The next sections present CPSs and digital twins as enabling technologies for Industry 4.0, and provide an overview of related research. Thereafter, the paper presents a case study implementation and evaluation of the digital twin architecture. The digital twin architecture proposed in this paper is aimed at a variety of applications, but is evaluated for a manufacturing case study. Finally, a discussion about extending the architecture and conclusions are presented.

Industry 4.0 enabling technologies

This section discusses CPSs, digital twins and Open Platform Communications Unified Architecture (OPC UA) as enabling technologies for Industry 4.0. While this discussion does not cover all the enabling technologies for Industry 4.0, the selected technologies are considered the most relevant to the context of this paper.

CPSs can be described as multi-dimensional and complex systems that integrate the physical (real) world with the virtual (cyber) space. CPSs represent the integration of multi-disciplinary systems to perform feedback control on widely distributed embedded computing systems by the tight integration and combination of the “3C” technologies—computation, communication and control (Liu et al. 2017).

The 5–level CPS structure, also known as the 5-C architecture, is presented in Fig. 1. This structure provides the guidelines for developing and implementing CPSs for manufacturing applications (Bagheri and Lee 2015; Lee et al. 2015). A shown in Fig. 1, the structure consists of elements that reside in both the real space and cyberspace. The “Smart Connection Level” (Level 1) can be characterized as the physical twin. As seen in the figure, Levels 2 to 4 can then reside in the virtual space. The virtual space or more specifically, the digital twin, will be discussed further in this section.

Fig. 1

The 5-C Architecture for Implementation of Cyber-Physical Systems (adapted from Lee et al. (2015))

As with a CPS, the digital twin concept is also associated with the integration of the physical and virtual worlds. According to a NASA report, a digital twin is “an integrated multi-physics, multi-scale, probabilistic simulation of a system that uses the best available physical models, sensor updates, fleet history, etc. to mirror the life of its flying twin” (Shafto et al. 2010). Forbes mentioned that a digital twin trends at number five in “Gartner’s Top 10 Strategic Technology Trends For 2017” and that a digital twin can be used to analyze and simulate real world conditions, respond to changes, improve operations and add value (Cearley 2016).

In the context of designing, setting up and configuring the automation system for manufacturing, a digital twin is a set of computer models that provide the means to design, validate and optimize a part, product, manufacturing process or production facility in the cyberspace (Feuer and Weissman 2017). A digital twin concept model consists of three main parts, as mentioned by Grieves (2015), namely: a physical system in real space (physical twin); a virtual system in cyberspace (digital twin); and the connection between the cyber space and real space for transferring data and information using the Internet of Things (IoT).

A digital twin creates a highly accurate digital model of the physical system in cyberspace. Through the quality and fidelity of information, the digital twin can accurately replicate and simulate the behavior of the physical system (Grieves 2014; Vachalek et al. 2017). According to Tao et al. (2018), a digital twin can also provide a digital footprint of products by integrating geometry, structure, behavior, rules and functional properties. Salvador Palau et al. (2019) mentions that a digital twin can also be considered as intelligent agents with prognostics, communication, and data preprocessing capabilities.

Kritzinger et al. (2018) distinguishes between the various digital forms and categorized them as digital model, digital shadow and digital twin. A digital model, in essence, represents a simulation of the physical process and is characterized by manual data flow between the real and digital entities. A digital shadow is equipped with one-way automated data flow from the real entity to the digital entity and is typically defined as an emulation of the physical asset or process. A change in the physical state of the process will automatically update the state of the digital representation. A digital twin is equipped with automated bi-directional data flow between the physical and digital entities. The digital entity possesses intelligence and decision-making capabilities, which enables the automated feedback loop to the physical entity.

The combination of the physical production system and its corresponding digital twin are the fundamental building blocks of fully connected and flexible systems that are able to learn and adapt to new demands. Ideas about the value and role of the digital twin are still developing at this stage. Some of the roles of digital twins postulated in recent literature are (Feuer and Weissman 2017; Marr 2017; Martin 2017; Oracle 2017; Patel and Chotai 2011):

• Remote monitoring—The digital twin allows remote visibility of the operations of large interconnected systems, such as manufacturing systems, which allows for virtual monitoring systems and validation of the current status of production systems (i.e. energy monitoring and fault monitoring).

• Predictive analytics—Prediction of the future state of the physical twin can be used to predict errors and problems in manufacturing facilities before they occur; preventing downtime, failures and more.

• Simulating future behavior—The digital twin can be used to plan for future reconfiguration of the system and system processes, in response to external changes.

• Optimization and validation—Validate and optimize the system’s operation using simulation and real-time sensor feedback (i.e. batch mix optimization).

• Documentation and communication—The digital twin provides a mechanism to understand and explain behaviors, and can be used as communication and documentation mechanism to describe the behavior of equipment.

• Connection of disparate systems, such as backend business applications—The digital twin can be used to connect to backend business applications to achieve business outcomes in the context of supply chain operations.

• Global Digital Twin Control—Planning the batch, such as establishing the order in which physical twins are introduced in the manufacturing environment, scheduling product operations and allocating resources to operations.

• Per Batch Records—Documentation of batch records builds a picture of the state of the physical twin and the particular manufacturing process when each product was made.

To fulfil the respective roles, the digital twin will rely on certain capabilities that extend across the roles. These capabilities of the digital twin that are required can be summarized as:

• Acquire physical twin state—The digital twin must be able to obtain data from various types of sensors (e.g. vibration sensors, temperature sensors, counters or PLC registers) from the physical twin. The sensor data collected from the physical twin will be refined and enriched (e.g. through combination and adding context) into information sets that describe the state of the physical twin.

• Maintain information repository—The state information obtained from the sensors of the physical twin has to be stored where it can easily be accessed through the internet. Since large volumes of data may be stored, the repository should be highly scalable. Cloud-based storage is therefore an attractive choice. Previously stored information will also have to be retrieved for use by the other capabilities of the digital twin.

• Simulate operation—Simulation of the physical twin’s operation, i.e. predicting its future behavior from a given starting state and selected set of conditions, is required for some of the envisaged roles of the digital twin. For example, the simulation should allow for the evaluation of new processes, different production schedules, etc.

• Emulate operation—Emulation is the imitation of the behavior of a hardware system, i.e. to visually represent or reproduce the action or function of the physical twin. The emulation can represent the status of the physical twin in soft real-time using feedback from embedded sensors. The emulation can typically be a graphical display of the soft real-time status of the physical twin.

CPSs and digital twins are similar in their description of the cyber-physical integration. Both are also comprised of the physical and cyber/digital parts (Tao et al. 2019). Although CPSs and digital twins share similarities, there are also differences. According to Lee (2015), CPSs are more foundational as they do not directly reference implementation strategies or particular applications. Therefore, CPSs are related to a scientific category (Monostori et al. 2016; Tao et al. 2019), whereas the digital twin is related to an engineering category (Tao et al. 2019).

Tao et al. (2019) also mention that changes in the physical process will affect the digital world through feedback of real-time embedded actuators and sensors. The core elements of CPSs are therefore considered to be sensors and actuators. However, through the feedback of data from sensors and actuators, digital models can be used to interpret the behavior of machines or systems, and predict future state from real-time and historical data, as well as experience and knowledge. The core elements of a digital twin are then considered to be models and data. CPSs, and the technologies required for developing CPSs, can be considered as a necessary foundation for implementing digital twins.

Major challenges for adopting the Industry 4.0 initiative includes: global connectivity, integration and interoperability; data security and integrity; real-time performance and reliability; and centralization, simplification and standardization (M.A.C. Solutions. 2017). These challenges play a fundamental role in the development of digital twins, as the connections between the physical twin and its corresponding digital twin may rely on internet enabled connections. OPC UA is considered a functional tool to address these challenges. In manufacturing and automation, OPC UA is striving towards becoming the international standard for horizontal and vertical communication, providing semantic interoperability for the world of connected systems. OPC UA provides the foundation for connectivity for the Internet of Things (IoT) and for Industry 4.0 (OPC Foundation 2015).

Hoppe (2017) mentioned that a main challenge with Industry 4.0 and the Industrial Internet of Things (IIoT) is the secure data and information exchange between devices, machines and services. He reported that the IEC standard 62,541 OPC UA was recommended by the Reference Architecture Model for Industrie 4.0 (RAMI 4.0) for implementing the communication layer, and concluded that any product being advertised as “Industry 4.0 enabled” must be OPC UA-capable.

Related work

In this section, some of the published research related to digital twin conceptual architectures are discussed in more detail. However, it should be noted that this section mainly focusses on conceptual architectures, as little evidence of architecture evaluations could be found.

Initiatives such as FIWARE for Smart Industry and Manufacturing Industry Digital Innovation Hubs (MIDIH) are already working towards developing implementation strategies for data-driven smart connected factories (Soldatos et al. 2019). These initiatives are dedicated to software-defined platforms to integrate factories into smart adapting factories.

The MIDIH Reference Architecture for Smart Factory and Smart Product connects the industrial shop floor with the digital smart factory using an IoT Middleware as Data-in-Motion layer and Analytics Middleware as Data-at-Rest layer. Here, Data-in-Motion refers to data generated by different real-world assets and Data-at-Rest refers to data that needs processing to feed Artificial Intelligence based advanced applications (Manufacturing Industry Digital Innovation Hubs (MIDIH) 2018).

The MAYA H2020 project also aims at developing simulation methodologies and multidisciplinary tools for the design, engineering and management of CPS based factories. Some of the key challenges that this project initiates include: digital continuity; synchronization of the digital and real factory; and multi-disciplinary, integrated simulation and modelling (H2020—MAYA Project 2019).

A centralized support infrastructure (CSI) is a middleware developed by Rovere et al. (2019) and incorporates Big Data with the digital twin for processing shop floor data. This platform is characterized as a microservice architecture in which the application consists of a collection of small services, each devoted to its own activity. Each microservice runs in its own process and communicates with other services. This architecture makes use of various technologies and software that are already available to fulfil the roles of the microservices. These services are managed through suitable API (application programming interface) endpoints. In this architecture, it is clear that each service is encapsulated with its own functionality—e.g. the Big Data sub-architecture service is responsible for handling and processing of large volumes of data. The microservice approach provides many benefits, such as: agility, where businesses can start small and expand by adding more microservices; isolation and resilience, where each service can fail and heal independently and therefore provides the ability to self-recover; and elasticity, as services can be scaled according to workload changes and can be accomplished through the use of pay-per-use cloud computing services. This architecture also has some limitations, such as the distribution of data over multiple services making it difficult to maintain data consistency over multiple database platforms, and also high complexity of the resulting system as the communication between the microservices can become complicated (Rovere et al. 2019).

In a literature review, Kritzinger et al. (2018) mention that the development of the digital twin is still at its infancy, as literature mainly presents conceptual ideas without concrete case studies. Although there exist many papers on the digital twin for a manufacturing system, there is little concrete evidence of digital twin implementation and evaluation. Kritzinger et al. (2018) mention a case study, by Bottani et al. (2017), concerning a digital twin implementation within a laboratory environment. A CPS-AGV (cyber-physical system—automated guided vehicle) or CGV (cyber guided vehicle) with self-adapting behavior was developed for solving a material handling problem (Bottani et al. 2017).

However, the digital shadow and digital model (as defined by Kritzinger et al. (2018)) has been implemented and evaluated in recent literature, such as the work from Schroeder et al. (2016), where an industrial component was modelled and simulated through data exchange using the FIWARE middleware. They used Automation Markup Language as a modeling tool to map the components of an automation system. They evaluated this digital shadow through a case study where a valve was modelled. Attributes such as position, voltage, temperature and battery level were extracted and sent to external systems.

A digital shadow was developed by Vachalek et al. (2017) and focused mainly on production, planning and control. They used Tecnomatix Plant Simulation (PS) for the digital part of the case study and also OPC for data transfer to the PS model. They used a genetic algorithm to optimize the production according to the production plan in a case study implementation. The data (transferred through OPC) was used to map the values from the actual process to the simulation model.

Răileanu et al. (2020) developed an architecture for bidirectional data flow between the physical space and the digital space. The architecture consists of four layers, where the first layer is dedicated to the physical space where the data are collected and processed. The second layer is responsible for communication to the third layer. Layers three and four resides in the cloud and are responsible for data update and aggregation (layer three) and analysis and decision making (layer four). This architecture was demonstrated for a shop floor conveyor, where RFID technology were used to identify and locate the pallets on the conveyor. They also propose OPC as a communication protocol, which resides on layer two of the architecture.

A four layer architecture has also been developed by Borangiu et al. (2020), where each layer on-top of the physical system is classified as a digital twin layer. The first layer is characterized as the data acquisition and transmission digital twin. The second layer comprises of the virtual twins of sub processes. This layer offers secure bidirectional communication between the world of business applications and the equipment. The third layer, called predictive twins, is devoted to data analysis and is responsible for the process of device data and machine learning techniques to predict equipment status and the detection of anomalies. The fourth layer is comprised of decision making and is subsequently referred to as the decision making twins.

Schleich et al. (2017) also proposes a reference model for the digital twin, which is a theoretical and conceptual framework for digital twin implementations for specific applications while ensuring model properties such as model scalability, interoperability, expansibility and fidelity. Their focus is to develop a digital twin for geometrical variation management throughout the product lifecycle.

A six-layer architecture for the digital twin

The six-layer digital twin architecture, presented in Fig. 2, was developed by Redelinghuys et al. (2019a) and provides communication between the physical twin and the digital twin, as well as between the digital twin and the outside world. The architecture is aimed at situations where the products of various vendors are used in the physical twin, as well as in the remainder of the digital twin. Proprietary and custom developed elements are kept to a minimum to reduce development and support cost. Open or vendor-neutral formats are used for communication between the layers.

Fig. 2

Connection architecture for a digital twin (adapted from Redelinghuys et al. (2019a))

Figure 2 indicates the data/information flows between the layers indicated. The figure illustrates that data/information flows from the physical system or physical twin (Layer 1) to the cloud (Layer 5), where it is stored in an information repository accessible in cyberspace. This architecture takes inspiration from the 5-C architecture for Cyber-Physical Systems (Lee et al. 2015) and relates it to the development of digital twins. Layers 1 and 2 comprises of the physical twin. Layer 3 consists of a local data repository that is used to obtain sensor value from the controllers in Layer 2. Layer 4 is a custom developed IoT Gateway or data-to-information converter. Layers 5 and 6 consist of cloud repository and emulation and simulation tools, respectively. An overview of each layer will be discussed further in this section.

Layers 1 and 2: physical twin

Embedded physical devices, objects and equipment form part of the “Smart Connection Level” in the 5-C architecture model. This can also be characterized as the physical twin, which is presented in Fig. 2 by Layers 1 and 2.

Layer 1 includes various physical devices, such as actuators and sensors, which can provide or consume signals exchanged with the local controller or data acquisition device, which is located at Layer 2. Layer 2 then represents the data source for the physical twin.

Layer 3: local data repositories

Layer 3 provides a vendor-neutral communication interface between the physical twin and the other layers, as shown in Fig. 2. In general, Layer 3 primarily communicates with Layer 4, but it can also log data directly to the cloud in Layer 5 (if the data in Layer 3 is suitable) and even communicate with Layer 6 (e.g. where low communication latencies are important). Here OPC UA is considered a valuable tool to exchange data with various controllers and data acquisition devices. OPC UA also provides the necessary security to protect data/information leaks.

Some OPC UA servers provide access to more than 150 device drivers and therefore makes it a functional tool to use for communication between various devices and also between the real space and cyberspace. This is also functional as some companies or manufacturing industries make use of equipment that are provided by various companies or suppliers.

Layer 4: IoT gateway

A “Data-to-Information Conversion Level”, or IoT Gateway, is added as Layer 4. This layer corresponds with Level 2 of the 5-C architecture of Lee et al. (2015). This layer adds context to the data received from Layer 3 and/or processes the data to forms more useful for the higher layers. This layer connects Layer 3 to Layer 5 by converting data, received from Layer 2, to information to be sent to the cloud repository in Layer 5.

Here, a custom-developed application can be used to interface with an OPC UA server on Layer 3 using a client connection to the server. The application can then subscribe to the tags on the OPC UA server that are of value to the higher levels of the six-layer architecture.

Layer 5: cloud-based information repositories

Layer 5 represents the cloud-based information repository, as shown in Fig. 2. Layer 5 consists of cloud services that store historical information received from Layer 4. This information can then be accessed from Layer 6 and can be beneficial for decision making by evaluating the current state of the physical twin.

Multiple repositories are envisaged, since different stakeholders are likely to have different information needs and access rights. For example, the developer of the physical twin may require access to critical performance parameters, but may want to control access to that information, while the manufacturing plant may require that quality assurance information is stored, but would want to keep that information confidential.

Hosting these repositories in the cloud enhances the availability, accessibility and connectedness of the digital twin. The specialized expertise required to manage such a database server, taking into account scalability, reliability and security, is usually not readily available in manufacturing enterprises.

Layer 6: emulation and simulation

While Layers 1 to 5 provide the required infrastructure, the intelligence of a digital twin is added in Layer 6 (Fig. 2). Layer 6 forms part of the “Cognition Level” of the 5-C architecture for developing CPSs.

As seen in Fig. 2, Layer 6 connects to Layers 3, 4 and 5, and can thus provide the functionality of a user interface (or dashboard) that connects the user to soft real-time and historical information about the physical twin. Therefore, Layer 6 should be equipped with emulation and simulation software that allows a user to interface with this layer. This layer, depending on the emulation and simulation software, may also provide the user with a graphical 3D representation of the physical twin.

Emulation and simulation tools such as Siemens Tecnomatix Plant Simulation (PS) exhibits valuable functionality, such as OPC UA communication and connections to online cloud repositories through an open database connectivity (ODBC) driver.

Architecture review

Before evaluating the proposed architecture through a case study implementation (presented in the next chapter), this section considers some of the architecture’s capabilities.

Firstly, the architecture is independent of the application-specific details and, although presented in a manufacturing context, it is expected to allow for wider application. The architecture provides a local data layer (e.g. OPC UA or databases local to the plant), an IoT Gateway layer that relays information between the physical world and cyberspace, a layer with cloud-based data repositories and, finally, a layer with emulation and simulation software.

The architecture clarifies the different roles required to pass the data and information between the physical twin and the part of the digital twin that hosts its intelligence. Using readily available technologies and services, such as OPC UA servers and cloud-based database services, it provides reliability and security, and reduces the developers’ expertise requirements and development risks. The custom development work is focused on one layer, i.e. in the IoT Gateway. The IoT Gateway also provides for conflict resolution, safety functions and a GUI.

The architecture is suited to creating digital twins for legacy systems (i.e. where Layers 1 and 2 already exist). However, in some situations, the data in Layer 3 will reflect the details of the physical twin, but additional processing may be added to Layer 2—specifically to provide data for the sake of the digital twin. In general, if the physical twin already exists, it is recommended to add the custom functionality required for the digital twin in Layer 4, rather than changing Layer 2—taking into account the downtime and risks involved in modifying a system in operation. Also, if the digital twin is aimed at a variety of architectures of the physical twin, it is likely to be better to account for the differences in Layer 4.

The aspect of high-fidelity visualization to interpret the behavior of machines or systems is integrated into the six-layer architecture. A major focus of the six-layer architecture is to have a near real-time replica of the physical process with access to historical information to monitor and analyze the current state of the machine or system. The segmentation of the various layers in the six-layer architecture contributes to encapsulating each layer with its own functionality and can therefore contribute to the separation of concerns.

As also mentioned previously, the architecture is aimed at situations where the products of various vendors are used in the physical twin—especially on Layer 2, which is dedicated to data acquisition devices. Open or vendor-neutral formats are also used for communication between the layers and here OPC UA is used for providing that functionality. The architecture supports the use of a variety of software and tools in the different layers. Therefore, clients interested in developing digital twins of physical systems and processes can use their preferred tools and software. An example is where different simulation tools can be used for equipment from various/different suppliers. In Redelinghuys et al. (2020), it can be seen how this architecture can be used to accommodate different tools and software (Layers 3-6) for different devices (Layer 2).

Although there may be some similarities between the six-layer architecture and the related work by Redelinghuys et al. (2020) and Borangiu et al. (2020), such as the data transmission layers and the use of OPC to transmit this data, it is also evident that there are also some differences. The six-layer architecture consist of a layer dedicated to converting data to information and connecting to the online cloud repository using custom developed software. Layer 6 of the six-layer architecture is also dedicated to emulating and simulating the behavior of the physical twin and also for analysis and decision-making based on historical information, that are obtained from Layer 5. Borangiu et al. (2020), in their four-layer architecture, separated the data analysis and decision making into layers 3 and 4, respectively.

A main function of the CSI architecture, by Rovere et al. (2019), is to explicitly incorporate Big Data to process shop floor data at a lower level in the architecture, whereas that functionality is only provided for on Layer 5 and 6 of the six-layer architecture. The CSI architecture can grow as more microservices can be added/created to add functionality to the architecture, which can increase the amount of connections and communication between the services. However, a major limitation mentioned by Rovere et al. (2019) is the complexity that may arise in communication between the various microservices. There is thus a major difference between the CSI and the six-layer architecture in the interconnectedness of the various services, as the six-layer architecture strives to minimize the connections between the various layers in order to reduce complexity. Furthermore, the two architectures are similar in terms of incorporating pre-existing services and limiting the proprietary and custom developed elements.

In the following chapters, the implementation and evaluation of the six-layer architecture are explored in more detail. From this implementation and evaluation, it is shown that the six-layer architecture provides a solid foundation for developing digital twins with high-fidelity visualization of pre-existing physical twins.

The six-layer architecture is focused on implementing digital twins for existing and new manufacturing systems, with bidirectional data-exchange between the physical twin and the digital twin. It should be noted that in the remainder of the paper, the digital twin implementation for a component within a manufacturing cell is evaluated. The expansion of the six-layer architecture to accommodate a variety of components in a manufacturing cell is discussed after the evaluation section.

Case study implementation

A digital twin implementation case study is presented in this section. The case study is based on a robotic gripper which an industry partner uses in assembly lines. The gripper has known failure modes; therefore, this case study was developed to evaluate the ability of a digital twin to detect anomalies in the operation of the physical twin. Some security measures that were implemented in Layer 4 of the six-layer digital twin architecture are also discussed in this section.

Implementation overview

A manufacturing process from an industrial partner specializing in the design and development of catalytic converter assembly lines was used as case study for the digital twin implementation. The company uses a pneumatic belt-driven robotic gripper as part of the process where it grips and holds onto a catalytic cylinder. A prototype of the robotic gripper revealed certain failure modes in a test-to-failure evaluation. The failures that occurred include: leaks on the pneumatic cylinder; disintegration of ball bearings; and a linear carriage that loosened over time. Therefore, the development of a digital twin of such a system may contribute to detecting certain anomalies before failure. This robotic gripper served to be the physical twin of the case study implementation.

The robotic gripper, equipped with sensors for data feedback, constituted Layer 1 of the architecture. The setup of the robotic gripper and test cylinder, the functioning of the gripper and the placement of sensors on the physical twin Layer 1 are described in further detail in this section. The controller, which resides in Layer 2, and the interaction between the system and sensors (Layer 1) and the controller (Layer 2), are also further described in this section.

For the local information repository, an OPC UA server was used as Layer 3 to connect to Layer 2 of the architecture. A C# application was developed as the IoT Gateway, which is situated at Layer 4 of the architecture. Layer 4 connects to Layer 3 through an OPC UA client–server connection and is described further in this section. Google Cloud Platform was selected as the cloud-based information repository in Layer 5. In Layer 6 of the architecture, Tecnomatix PS was used as the emulation and simulation tool to connect to Layers 3, 4 and 5 of the six-layer architecture and to interact with the user.

Layer 6 of the architecture is evaluated in more detail by implementing certain roles of a digital twin in this layer. Although all the layers are required to fulfil certain roles of a digital twin, Layer 6 was considered as a practical layer to visualize and demonstrate these roles. The roles that were evaluated include remote monitoring, fault detection and diagnosis, and virtual commissioning.

Each layer in the six-layer architecture is not limited to the chosen configurations, but it rather presents a mere example to evaluate the functionality of the six-layer architecture as a reference architecture for Industry 4.0, as mentioned by Kagermann et al. (2013). However, the evaluation is limited to the case study and the chosen configurations of each layer.

The physical twin

In this section, the physical twin setup is discussed in more detail. Layer 1 of the physical twin consists of the robotic gripper and the various sensors that are coupled to the robotic gripper. Layer 2 comprises the controller layer, which is connected to Layer 3 in the six-layer digital twin architecture.

Layer 1 of the physical twin

The physical twin assembly of the manufacturing system component is presented in Fig. 3. The main subsystem (labelled A in Fig. 3a) is a gripper designed to operate under demanding conditions. A 100 mm stroke, compact Festo cylinder, connected to a 6 bar supply, is used as actuation mechanism. The gripper actuates using a belt-and-pulley design. The pulleys are fitted as idlers for actuation. The belt, with actuation from the cylinder, moves the linear carriages. The gripper jaws are connected to the linear carriages and move over the linear rails, which are connected to the base plate.

Fig. 3

Physical Twin Assembly a CAD Model b Real World System

The gripper is equipped with limit switches to detect the opening and closing status of the gripper. Figure 3b shows the positioning of the limit switches on the robotic gripper. Limit switch (1) is triggered if the gripper is in the open position; (2) is a Festo pneumatic cylinder position sensor that is triggered if the gripper is in the closed position (when there is no object between the jaws); and (3) is triggered if the gripper jaws are gripped/locked on to the test cylinder.

For testing the gripper, a second subsystem was added (labelled B in Fig. 3a). This comprised a round steel cylinder that the gripper could grip and a pneumatic cylinder that pushes the steel cylinder towards the jaws of the gripper while the jaws are clamping it. The clamping procedure is required for the cylinder to be filled with a honeycomb structure that is used in catalytic converters. The test setup therefore simulates the filling process of the honeycomb structure into the catalytic cylinder.

In Fig. 3a, the movements of the robotic gripper and test cylinder are illustrated. The setup and functioning of the gripper are aligned with the procedure to test the robotic gripper. The test cylinder extends for 25 mm when the gripper jaws are closed on to the test cylinder. The gripper jaws then open and close again to grip on to the test cylinder. The test cylinder then retracts 25 mm while the gripper jaws are locked on to the test cylinder. The gripper jaws are always in contact with the test cylinder when the test cylinder extends or retracts.

The robotic gripper and test cylinder setup are mounted to a platform, as presented in Fig. 4. The open position is presented in Fig. 4a and the closed position in Fig. 4b.

Fig. 4

Experiment setup of the robotic gripper a Open position b Closed position

For the case study investigation presented here, additional sensors were added to the gripper to detect developing failures. These sensors are a cylinder position sensor, pressure sensor and airflow sensor.

Layer 2 of the physical twin

Layer 2 of the six-layer architecture is the controller level of the physical twin. For this case study, a Siemens S7-1200 PLC was used for the controller. The limit switches and pneumatic position sensor were connected to digital inputs on the controller. The pressure and airflow sensors were connected to analogue inputs on the controller. Three digital outputs were connected to the pneumatic control valves of the gripper and the test cylinder. The inputs and outputs, as mentioned, were used in the control algorithm of the PLC controller to control the process of the physical twin.

The control sequence of the gripper was programmed using ladder logic control in the Siemens TIA portal. The sequence is started from a home or start position. This position of the gripper is where the gripper arms are open (limit switch for open position is triggered) and the test cylinder retracted (in the position where the cylinder is between the grippers). The process starts by closing the gripper arms to grip onto the test cylinder as shown in Fig. 4b. When the limit switch for the closed position is triggered, the test cylinder extends and after a two second wait, the gripper opens and releases the test cylinder, as shown in Fig. 4a. If the limit switch for the open position is triggered, the gripper closes again after a two second wait and grips/locks onto the test cylinder. The test cylinder then retracts, while the gripper is still closed and gripped on to the test cylinder. After a two second wait, the gripper opens again to the home position and the process is then repeated.

A safety stop was implemented in the ladder logic that is triggered when the gripper remains in a certain state for too long. This failure may occur as a result of limit switch failure, low supply pressure or pneumatic control valve failure. Failure detection from the digital twin aims to restore equipment to an operational safe state. However, it is necessary to implement emergency stops on a low-level controller in the case of network failures, where the digital twin will not be able to respond to failures.

During the setup of the OPC UA tags, it was observed that the pressure and flow sensor values continuously updated on the server as a result of small decimal changes. The raw pressure and flow measurements on the analogue inputs of the PLC were scaled according to the resolution of 0.678 V/bit. The pressure sensor calibration is 1 V corresponding to 1 bar, while for the flow sensor 1 V corresponds to 60 l/min. The sensitivity of the flow and pressure sensors could cause the OPC UA server to update on small decimal changes even when the gripper is not in motion. To prevent the OPC UA server from updating continuously, the pressure and flow values were rounded to one decimal digit on the PLC.

The digital twin

In this section, Layers 3 to 6 of the six-layer digital twin architecture that constitutes the digital twin, are discussed in further detail. Security considerations for the implementation of Layer 4 are also discussed.

Local data repositories

As shown in Fig. 2, Layer 3 must be able to communicate with local automation controllers (Layer 2), the IoT Gateway (Layer 4) and, in some cases, with cloud-based databases (Layer 5) and the plant simulation (Layer 6). Various OPC servers available from reputable vendors have the potential to be used in Layer 3. For the case study, KEPServerEX from Kepware Technologies was selected, with access to more than 150 data source drivers. The server was configured on a PC and connected to a Siemens SIMATIC S7-1200 PLC controller (Layer 2) using Siemens TCP/IP driver communication.

KEPServerEX is also easy to interface directly with Layer 5, through its Datalogger advanced plug-in. The Datalogger supports any Open Database Connectivity (ODBC) compliant database management system. The Datalogger detects any change in value within a user-defined “log group” on the OPC UA server and sends the new data value, a timestamp and a quality measure to the database (PTC Inc. 2017). Data can also be transmitted from Layer 5 to the OPC UA server (Layer 3), triggered by a data change in Layer 5. The connection is made possible on the OPC UA server with a Kepware ODBC client driver and the “advanced plug-in” in KEPServerEX.

IoT gateway

The IoT Gateway in Layer 4 interfaces with the local data sources on Layer 3 and with the databases on Layer 5. For the case study, a custom C# program was developed as the IoT Gateway. C# offers a number of relevant features, as discussed below. Other programming languages can also be used, but the language’s compatibility with OPC drivers and database interfaces should be considered.

The IoT Gateway acts as an OPC UA client to exchange data with Layer 3. In the case study, this was accomplished through the ClientAce OPC Client Toolkit. The client drivers provide convenient access to OPC UA and other OPC server applications. The ClientAce toolkit is available for.NET applications, which is inherently suited to C#. The ClientAce driver continuously monitors the OPC UA server for changes to the values associated with a user-selected set of tags. If a change is detected, the driver activates a call-back function which allows the IoT Gateway to interpret and process the changes.

In the case study, the IoT Gateway connects to a SQL database on Layer 5 using MySQL communication protocol. C#, through the.NET library, provides various components that simplify the interfacing with the database. The IoT Gateway periodically polls the database to detect any changes initiated by Layer 6, i.e. by the PS or other applications interacting with the database.

An aspect that was not initially considered arose during the testing: the date and time of the various layers may have to be precisely synchronized and, at least, the IoT Gateway should be aware that the hosts of the different layers may be in different time zones. The default time they use could be their local time or Coordinated Universal Time (UTC).

In this layer of the six-layer architecture, a Graphical User Interface (GUI) is a convenient mechanism to connect the OPC UA server with the online cloud server. Figure 5 presents the GUI used for the IoT Gateway. This GUI also displays the connection to Tecnomatix PS. Also shown in this figure is the connection made to the online cloud server to store historical information about the physical process.

Fig. 5

IoT gateway graphical user interface

The IoT Gateway, which is also the data-to-information conversion layer in the six-layer architecture, converts sensor data to information before sending it to the cloud server. In the case study, stroke times and stroke speeds were calculated in this layer using Eqs. (1) to (5). The limit switches for the open and close position and the cylinder position sensor were used to detect the position of the gripper jaws. The StrokeLength, as used in Eqs. (4) and (5), was measured to be 77.4 mm.

$$ GrippingTime \left[ s \right] = CloseSwitchTime - CylinderSwitchTime $$

(1)

$$ ClosingTime \left[ s \right] = CylinderSwitchTime - OpenSwitchTime $$

(2)

$$ OpeningTime \left[ s \right] = OpenSwitchTime - CloseSwitchTime $$

(3)

$$ OpeningSpeed \left[ {\frac{m}{s}} \right] = \frac{StrokeLength}{OpeningTime } $$

(4)

$$ ClosingSpeed \left[ {\frac{m}{s}} \right] = \frac{StrokeLength}{ClosingTime} $$

(5)

The closing time, opening time and gripping time are calculated during each cycle of the process and pushed to the cloud to be analyzed by the digital twin. These times can be used in Layer 6 to detect anomalies in the stroke times. The pressure and airflow were also measured for each cycle. The sample mean, minimum and maximum of both the pressure and airflow measurements are calculated for each cycle by the IoT Gateway (Layer 4). These calculations are then pushed to the cloud (Layer 5) after each cycle. Layer 6 can then request information from Layer 5 regarding the performance of the physical twin.

Cloud-based information repository

The information repository in cyberspace is shown as Layer 5 of the six-layer architecture in Fig. 2. Cloud storage and ODBC platforms were not extensively evaluated for the case study, since the choice of platform will be highly dependent on the context. The architecture presented here assumes that the developers of a digital twin, being closely associated with the developers of the physical twin, will not be interested or have the expertise in developing their own cloud platform and will buy this service from one of the many available providers. The cloud server is also used to build up a reference model to compare future events and detect anomalies of future behavior.

For the case study, as a matter of convenience, Google Cloud Platform was chosen as the information repository. In practice, security and reliability considerations will probably lead to the use of a platform that is paid for.

Emulation and simulation

Siemens Tecnomatix PS was selected as Layer 6 of the architecture for the case study. It is suitable for visualizing the physical twin in soft real-time and allows the integration of a physical system with the virtual environment. Tecnomatix PS enables the simulation, visualization, analysis and optimization of production systems and logistics processes (Siemens 2014).

Tecnomatix PS has an ODBC interface that is able to retrieve data of events from the physical twin via the cloud-based database. Tecnomatix PS is also able to obtain soft real-time data directly from the OPC UA server. Data can therefore be transferred from Layer 2 to Layer 3 to Layer 6 via an OPC UA interface.

In the remainder of this section, the configuration of Layer 6 to fulfil certain roles of a digital twin is discussed. These roles were used to demonstrate and evaluate the emulation and simulation capabilities of the digital twin. Although all the layers are required to fulfil certain roles of a digital twin, Layer 6 was considered as a practical layer to visualize and demonstrate these roles.

Setup for remote monitoring

One of the roles of a digital twin is to emulate or mimic the physical process in cyberspace. The digital twin should emulate the soft real-time status of the physical twin, with the aid of sensor feedback via Layer 3 (if shorter latencies are essential) or Layer 5 (if longer latencies are acceptable).

The visualization of the model in Tecnomatix PS allows the user to closely monitor the status of the physical twin. Visualization can also be aesthetically pleasing to the user interfacing with the digital twin in Tecnomatix PS. The CAD assembly of the physical twin was converted to a JT (Open CAD file) file and imported into Tecnomatix PS. A 3D animatable object was then created of the physical twin, from the JT file that was imported. The various parts of the physical twin that function and move together were grouped together in Tecnomatix PS. Each group of parts forms an object that can be controlled. All stationary parts were kept as one object and each group of parts moving together was assigned as an object that can be controlled. Figure 6a presents the physical twin in the real world and Fig. 6b presents the digital twin visualization developed in Tecnomatix PS. With the aid of importing files from CAD software into Tecnomatix, exact representations can be visualized.

Fig. 6

Robotic gripper assembly of a the Physical twin in the real world, and b the digital twin in Tecnomatix plant simulation

Tecnomatix PS connects to the OPC UA server using a client subscription for data change events. A SimTalk 2.0 method was implemented in Tecnomatix PS and this method is called every time a data change occurs on the OPC UA server. The Tecnomatix PS scheduleTranslation command animates the movement or process of the model. The command translates the object from a starting position to the destination position at a calculated speed. The gripper jaws of the PS model translate with the opening and closing commands. The test cylinder also translates to an extended and retracted position using the same scheduleTranslation command.

The model continuously adopts changes from the physical twin (e.g. stroke speeds for the opening and closing operations) to closely mirror the status of the physical twin. The digital twin updates the current status based on sensor changes that occur on the OPC UA server. An emulation method is called in Tecnomatix PS upon data change by the OPC UA server. Therefore, the 3D Tecnomatix PS model only updates or changes state when the physical twin changes its state. With the aid of the cloud, the digital twin can examine historical information stored from the IoT Gateway into the cloud server. As each cycle progresses, the digital twin reads the new updated information from the cloud and displays it for the user.

Setup for fault detection and diagnosis

In this setup, the digital twin continuously monitored the status of the physical twin to diagnose a fault, should it occur while the system is running. If a process takes longer than prescribed, the digital twin is able to stop the process and attempt to diagnose the possible fault. Multiple faults may occur at different states of the physical process and, with the addition of more sensors, the digital twin can more accurately diagnose the fault by eliminating uncertainty. The digital twin can then display the diagnosis to the user in the Tecnomatix PS main window.

An example of fault detection is when the gripper is in the home position (as explained previously) and the process of closing takes too long. With the aid of a pressure sensor, the uncertainty of too low pressure can be eliminated by detecting if the pressure is below 3 bar. The state of the physical twin can be compared to the reference model to detect possible faults or errors.

Fault detection and diagnosis can be extended to predictive maintenance or predicting future failures by simulating future behavior, based on historic data collected by continuously monitoring the physical twin. The simulated behavior can then be compared to a reference model to predict maintenance or diagnose future failures.

Setup for virtual commissioning

In some events, where rapid prototyping and testing are needed, the digital twin should be able to control the sequence of the process events. This functionality may form part of virtual commissioning. The six-layer architecture is able to supply this optional functionality. The control is shifted from Layer 2 to Layer 6 in the six-layer architecture. Therefore, the digital twin can control the physical twin using Tecnomatix PS and OPC UA communication in this case study. The OPC UA server manipulates register values on the Siemens PLC, instead of a predefined program running on the PLC.

Using SimTalk 2.0 in Tecnomatix PS, OPC UA tag values can be manipulated with the setItemValue command and values are read from OPC UA using the getItemValue command. Therefore, the control algorithm implemented on the PLC is also implemented at a higher level in the architecture using SimTalk 2.0 in Tecnomatix PS.

Security

Cybersecurity is considered as a major concern and challenge when adopting the Industry 4.0 initiative. Therefore, IT security and privacy protection need to be considered during the design phase of production plants to protect systems from downtimes and attacks (Redelinghuys et al. 2019b). Therefore, this section presents methods that were used for secure software design of the IoT Gateway that was developed in C#.

The IoT Gateway connects to the cloud server using a connection string that consists of sensitive information, such as username and password. A malicious attacker that gains access to the source code of the IoT Gateway will have access to the connection string. The Protected Configuration feature of.NET 2.0 enables encryption of application configuration information and configuring the application to automatically decrypt at runtime.

The connection string was created in the Application Settings, which is stored in app.exe.config upon installation of the main application. An Installer Class was added to the project to override the main Install Method, which contains an encryption configuration using a machine-specific secret key. After the application has been compiled and installed, the application configuration file, which contains the connection string, will be encrypted.

An existing cryptography, Password-Based Key Derivation Function 2 (PBKDF2), using Secure Hash Algorithm 1 (SHA1) as underlying hash function, was implemented. This allows for secure user login and authentication, to prevent unauthorized access to the application (Defuse Security 2017). A random string, called a salt, is generated using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) and hashed with the password using the PBKDF2 algorithm (Defuse Security 2017). The username and encrypted password are stored in the database of the cloud server when a user is registered. Upon login, the password is validated by retrieving the user’s salt and hash from the database. The salt is prepended to the given password and hashed using the encryption algorithm previously mentioned. The hash of the given password and the hash from the database are then compared to validate authentication. The user will have access to the GUI controls if authentication was successful.

Case study evaluation

In this section, the case study implementation as described previously is evaluated. The main objective of the case study was to implement the six-layer architecture by mimicking the physical process in cyberspace through interconnected sensors using the IoT. Various capabilities and roles of a digital twin are evaluated in this section. Acquiring the physical state of the twin, maintaining an information repository, and emulating and simulating, are the capabilities that are evaluated. The roles that are evaluated are remote monitoring, fault detection and diagnosis, and virtual commissioning. Emulation through the cloud is also evaluated in this section.

Capabilities

This section covers the evaluation of the capabilities of the digital twin. The capabilities of the digital twin are evaluated according to the case study implementation.

Acquiring physical twin state

The physical twin, which comprises Layer 1 and Layer 2 of the six-layer architecture, is equipped with multiple sensors to obtain accurate measurements of its state. The status of the physical twin is obtained through a TCP/IP connection between the Siemens PLC in Layer 2 and the OPC UA server in Layer 3.

The OPC UA server subscribes to specified registers on the Siemens PLC. The OPC UA server can be configured to only subscribe to useful data to build a digital state of the process. For example, the value changes obtained from the limit switches are used to identify the change in state of the physical twin. The data obtained from the pressure and airflow sensors may also contribute to the performance monitoring of the physical twin.

As mentioned previously, the analogue pressure and airflow sensors are sensitive to small changes, which causes their outputs to continually update on the PLC. This would result in the OPC UA server to continually update on the data change of these sensors and these changes are then transmitted to the IoT Gateway on Layer 4. This may affect the execution time of the IoT Gateway as a large number of messages will be on the TCP/IP stack. This situation was avoided by rounding the analogue sensor values to one decimal place on the PLC, to prevent data change on very small decimal values.

A limiting factor that was discovered during the case study evaluation was latencies that occurred between Layers 2, 3 and 4. The latencies between these layers have a substantial effect on the ability of the digital twin to sample sensor values at higher levels in the architecture. It may therefore be beneficial to sample sensor values using a high-speed data acquisition device on a lower layer in the architecture (Layer 1 or 2) than to sample at higher levels in the architecture. For example, if the time history of a rapidly changing parameter has to be tracked by the digital twin, Layer 2 will have to sample the sensor values with timestamps for the entire sampling profile, and subsequently pass the whole profile as a data structure to the higher layers. The latency effect of OPC UA has however been previously investigated by Cavalieri and Cutuli (2010), Cavalieri and Chiacchio (2013), and Nakutis et al. (2016).

Besides the limiting factor of latency, the six-layer architecture was able to obtain the physical twin state through sensor feedback from Layer 1 to Layer 2. OPC UA, which resides at Layer 3, fulfilled its purpose by linking Layer 2 with Layer 4. In Layer 4, through some processing, the data was converted to information. For this evaluation, the C# application had fulfilled its role as an IoT Gateway.

Maintaining information repository

The state information of the physical twin is stored in the database of the online cloud server. In the evaluation of this case study, Google Cloud Platform was used to store historical data. Layer 5 of the six-layer architecture (Fig. 2) may typically be set up with multiple platforms or cloud instances. Data privacy is a key issue in cybersecurity, and companies or industries would want to protect data and prevent data leakage. In this case study evaluation, one database with multiple tables was implemented to demonstrate the structure of data being separated for data privacy. However, a more reliable implementation might be necessary, with password protected database tables and instances.

The processing time, process speeds, errors, airflow and pressure information were each kept in their own database tables in the cloud repository. Specific information can then be requested by Layer 6, from the cloud, instead of requesting everything at once.

A motivation for information to reside in the cloud may be that hosting data or information locally can be expensive; in terms of building, running and maintaining database servers. Security is also a major concern for local data repositories. Cloud servers have become more affordable and also more reliable with regards to security. There is always a possibility of downtime with local servers. Cloud servers are equipped with multiple servers to prevent downtime.

The capability of the digital twin to store information in an online information or cloud repository was realized during this evaluation. The IoT Gateway (Layer 4) was able to send information to the cloud server, but some limiting factors were revealed during the case study evaluation of the connection between Layer 4 and Layer 5—these factors include the latencies and slow connection to the online cloud server. Layer 6 was also able to connect to the cloud repository to obtain information about the status of the physical twin. Layer 6 can then be effectively used to analyze the information that resides in the cloud.

Emulating and simulating operation

The emulation and simulation capabilities are evaluated in this section. These capabilities are further demonstrated where the roles of a digital twin are considered.

Emulating operation

Emulation is to imitate the behavior of a hardware system, e.g. to visually represent or reproduce the action or function of the physical twin. In Fig. 6b, a detailed model of the physical twin in Tecnomatix PS is presented. This model is able to reproduce, in soft real-time, the action of the physical twin using feedback from embedded sensors. This role is further demonstrated where the remote monitoring role is considered.

Emulating operation through the cloud

According to Oracle (2017), a digital twin should reside in the cloud. This section is therefore focused on evaluating the ability for a digital twin to reside in the cloud. The six-layer architecture as presented in this paper, indicates that information flows from Layer 4 to Layer 5 with a connection from Layer 5 to Layer 6. The emulation and simulation tools should therefore be equipped with the functionality to connect to online cloud servers.

In the case study, when the IoT Gateway (Layer 4) detects a change in the physical twin, it updates a status table on the cloud server (Layer 5). The IoT Gateway, which links the OPC UA server with the cloud server, autonomously updates the status on the cloud server if the status of the physical twin has changed. Tecnomatix PS was used as tool for the emulation in Layer 6 and Tecnomatix PS is able to connect to an online cloud server using an ODBC connection.

In the case study, an important observation was made when the IoT Gateway updates the table in the cloud server through a MySQL update command. The time differences between the OPC UA timestamp and the database timestamp are presented in Table 1. The database updated its timestamp the moment the value was received and placed in the online table. As seen in Table 1, the differences between the OPC UA timestamp and the database timestamp are significant and also have large variation.

Table 1 Timestamp differences for OPC UA and the cloud server

The table indicates the lag that exists when updating values in the cloud server database from the moment the value changed on the OPC UA server. The table presents only the lag between Layer 4 and Layer 5. The communication between Layer 5 and Layer 6 will also have significant lag, as the emulation platform (in this case Tecnomatix PS) still needs to request data/information from the database to update the status of the digital twin.

For a process parameter with updating intervals in the order of milliseconds, such a significant lag and variation will result in a notable lag on the emulation of the process. Also, since the lag is not consistent, the lag will impact the digital twin’s ability to compare changes in two different fast-changing parameters (e.g. pneumatic pressure and pneumatic cylinder speed).

In the evaluation of the digital twin, the emulation framework in Tecnomatix PS was able to read information, such as flow and pressure information, from the cloud server at the end of each cycle. This information is then presented in tables and charts as the process continues. However, the digital twin’s ability to visually emulate in real-time, with information from the online cloud server, is not yet realized.

Simulating operation

In the case study, the algorithm of the controller on Layer 2 was also implemented in Tecnomatix PS in Layer 6, as mentioned in the discussion of the virtual commissioning role. A digital model of the physical twin was also implemented in Tecnomatix PS and this model could be controlled by the virtual controller in Tecnomatix PS, without data flow between the physical and the digital objects.

The behavior of the digital model is simulated in Tecnomatix PS with the use of delays and estimated stroke speeds. The triggering of limit switches was simulated with delays. The opening, closing and gripping times of the physical twin were also simulated using delays and a speed constant was used to simulate the movement of the 3D model. The speeds and delays could be set in Layer 6 if the simulation is intended to reflect changes to the current physical twin, or Layer 6 could use some recent values from Layer 5 to reflect aspects of the physical twin’s current operation.

The case study has therefore shown that the six-layer architecture presented here can fulfil the role of simulation, which forms part of the “Cognition Level” of the 5-C architecture (Lee et al. 2015). This role is primarily provided in Layer 6 of the six-layer architecture.

Roles

The extent to which the case study implementation demonstrates the roles of a digital twin are discussed here. Remote monitoring, fault detection and diagnosis, and virtual commissioning are the roles that are evaluated in this section. The evaluation of these roles provided a functional means to evaluate the capabilities of the emulation and simulation tool used in Layer 6 of the six-layer architecture.

Remote monitoring

Remote monitoring entails the remote (i.e. in cyberspace) visualization, monitoring and supervision of the physical twin. In the case study, this role was accomplished through sensor feedback from the physical twin in Layers 1 and 2.

The IoT Gateway (Layer 4 in the six-layer architecture), measures the time of the opening and closing operations and then calculates the opening and closing speed. The IoT Gateway sends these values to Layer 6, to update the status of the digital representation. The digital twin also monitors the pressure and airflow, with the aid of the added sensors. The soft real-time airflow and pressure values are presented in the Tecnomatix PS (Layer 6) main window as seen in Fig. 7. An airflow and pressure profile can also be viewed in the display window of the digital twin, by reading from the database of the online cloud server.

Fig. 7

Tecnomatix plant simulation digital twin model

Figure 7 displays a digital representation of the physical twin (the robotic gripper) using Tecnomatix PS, as implemented in Layer 6. With the addition of a pneumatic cylinder position sensor, pressure sensor and airflow sensor, more information was obtained from the physical twin to more accurately mirror the soft real-time status of the physical twin. A pressure sensor was added to monitor if the pressure is maintained between 3 and 6 bar. The airflow sensor was added to detect if an air leakage occurred on the pneumatic cylinder or the pneumatic tubes.

The main window in Tecnomatix PS (Fig. 7) shows how the digital twin monitored the current state of the physical twin, in terms of the closing and opening times, closing and opening speed, and also the pressure and airflow measurements. The panel also displays the time history of some key parameters to monitor the behavior of the system.

This evaluation showed that a user is able to remotely monitor the status of a physical twin using the six-layer architecture to link the physical twin to its corresponding digital twin. With the aid of the IoT Gateway (data-to-information conversion layer) and the online cloud repository (Layer 5), valuable information about the status of the physical twin can be monitored. Tecnomatix PS also proved to be a valuable emulation and simulation tool for the purpose of remotely monitoring the physical twin. The detailed Tecnomatix PS model is aesthetically pleasing and contributes to the visualization of the action or function of the physical twin. A benefit that was discovered through the evaluation is that the main window is customizable, in that only the information of the physical twin that is of value can be displayed to the user.

Fault detection and diagnosis

In the case study, fault detection was tested and evaluated by intentionally inducing failures, such as sensor failures, the failure of a pneumatic control valve, leaks in the pneumatic system, and failure caused by insufficient pressure. If a fault is detected, the fault is recorded and stored in the online information repository with the corresponding information of the process cycle. A record of each cycle and corresponding information are then kept in the repository of the online cloud server. An online historical record of each cycle may contribute to detecting future failures and anomalies.

Sensor failure and the failure of a pneumatic valve was induced by disconnecting a limit switch and a pneumatic control valve, respectively. The safety stop implemented in the control program of the physical twin then stops the process. Thereafter, the digital twin detects the last status of the physical twin to diagnose the fault that occurred. It is necessary for safety stops to be implemented on a low-level controller (on the physical twin) in the case of network connection failure, which can cause the digital twin to momentarily disconnect from the physical twin.

By continually monitoring the pressure and airflow, faults such as leaks can be diagnosed. If the pressure of the main supply were to drop below 3 bar (a threshold selected for this case study), the digital twin will immediately stop the process and display the error on the main digital twin window. The digital twin is also able to detect whether the airflow sensor malfunctions, since the minimum reading on the sensor should vary between 4.6 l/min and 4.8 l/min in the case study. If the airflow reading reads values substantially below this range, it could be because the sensor is faulty or disconnected.

By monitoring the close to real-time airflow measurements (measured by an airflow sensor connected to Layer 2), the IoT Gateway (Layer 4) is able to record the maximum airflow via the OPC UA server (Layer 3). The measuring of the maximum airflow provides sufficient information to assess if leakage has occurred. If the maximum airflow measurement is above the expected range, it can indicate that a leak has occurred in the pneumatic system. This was tested by simulating a leak on the input side of the pneumatic cylinder, causing air to be lost through the tube. This showed that the six-layer architecture is able to detect anomalies in the airflow measurement of the system by monitoring the trend of the maximum airflow.

This evaluation showed that by monitoring the status of the physical twin, with sensor feedback from the physical twin using the six-layer architecture, the digital twin was able to detect simulated failures. Although the implementation of fault detection is limited to the case study, the six-layer architecture proved to be a functional framework to be used for fault detection and diagnosis. Through the contribution of Layer 4 and 6, the digital twin would be able to make intelligent decisions based on the current status of the physical twin.

Virtual commissioning

Control development through virtual commissioning can be used to test algorithms before being implemented in controllers. In the case study implementation of the six-layer architecture, this functionality is provided by a combination of Tecnomatix PS in Layer 6, OPC UA in Layer 3 and the PLC in Layer 2.

A SimTalk 2.0 method was implemented in Tecnomatix PS by using a generator object to call the method at every user selected time interval. The control method used OPC UA as communication mechanism between Tecnomatix PS and the register values of the PLC. The data flow connection was made from Layer 6 to Layer 1, via Layers 3 and 2 (Fig. 2). However, high CPU usage of the used computer occurred when the digital twin controlled and emulated the process in 3D visualization, at the same time.

This evaluation showed that control algorithms can be tested on a higher level (Layer 6) in the six-layer architecture, before being implemented in controllers. This evaluation also proved that with a SimTalk 2.0 method in Tecnomatix PS, through the OPC UA server (Layer 3), the controller (Layer 2) can be manipulated without using a controller specific programming language. This functionality allows for rapid prototyping and testing of control algorithms, should it be desired. Although this evaluation is limited to the case study implementation, it is expected that the six-layer architecture is customizable to fit the developer’s need.

Extension of the six-layer architecture

The functionality of the six-layer architecture was evaluated for a single component of a manufacturing cell. Through the evaluation it was proved that the architecture is viable in terms of replicating the behavior of the physical system in close to real-time in cyberspace. This evaluation was dedicated to proving the functionality of an architecture as a digital twin concept for modern manufacturing. As a first implementation and evaluation this architecture indicated major potential for developing digital twins and therefore motivates for further research into expanding this architecture to accommodate a more complex manufacturing environment. The expansion of this architecture leads to the concept of the digital twin of twins.

One idea on extending the six-layer architecture is to develop a hierarchy, or aggregation, of digital twins. Each component will be equipped with its own digital twin and combined to form aggregated digital twins of entire manufacturing cells. Higher-level digital twins form an aggregation of lower-level digital twins. Aggregating the information, through communication between multiple digital twins, reduces complexity by encapsulating the functionality of related information for each digital twin. This is also known as the concept of separation of concerns by reducing complexity and breaking a large digital twin into smaller digital twins of encapsulated functionality.

Further development of the six-layer architecture will focus primarily on the communication between digital twins and the aggregation of information to higher-level digital twins. This concept of an aggregation of digital twins is presented in Redelinghuys et al. (2020), and will be implemented and tested for a laboratory scale manufacturing cell.

Conclusion

The paper presents a multi-layer architecture that provides the infrastructure required for a digital twin within the CPPS paradigm. Even though the paper specifically considers a manufacturing case study, the architecture is independent of the application-specific details and facilitates wider application. The architecture provides a local data layer (e.g. OPC UA or databases local to the plant), an IoT Gateway layer that relays information between the physical world and cyberspace, a layer with cloud-based data repositories and, finally, a layer with emulation and simulation software.

The architecture clarifies the different capabilities required to pass the data and information between the physical twin and the part of the digital twin that hosts its intelligence. Using readily available technologies and services, such as OPC UA servers and cloud-based database services, it provides reliability and security, and reduces the digital twin developers’ expertise requirements and development risks. The custom development work is mostly focused on one layer—the IoT Gateway. The IoT Gateway also provides for conflict resolution, safety functions and a GUI.

The functionality of the six-layer architecture is proved through a case study implementation. Sensor data are captured in Layer 1 and Layer 2 of the six-layer architecture and collected, using a vendor-neutral OPC UA server in Layer 3, as part of the “Smart Connection Level” (Lee et al. 2015). In Layer 4, an IoT Gateway was implemented as the “Data-to-Information Conversion Level” (Lee et al. 2015). The IoT Gateway was developed in the C# programming language and links Layer 3 with Layer 5 in the six-layer architecture. Remote monitoring, fault detection and diagnosis, and virtual commissioning are some of the roles that were tested with the case study. These roles are aligned with the “Cognition Level” of the 5-C architecture for developing CPSs (Lee et al. 2015). Tecnomatix PS provided the necessary tools to implement and evaluate some of these roles in Layer 6.

Some limiting factors that were revealed during the case study evaluation include the detrimental effect of latency and slow connection to the online cloud server.

Future work

For future work, this research project will extend the six-layer architecture for twin-to-twin communication. This investigation will include the extension of the six-layer architecture to accommodate aggregations of digital twins, i.e. provide for vertical and horizontal integration. An example scenario would be for a manufacturing cell that consists of several stations. Each component or station can then be set up as a digital twin to form part of the cell-level digital twin. In this concept, as discussed in Redelinghuys et al. (2020), each digital twin makes use of the six-layer architecture and aggregates information to higher-level digital twins using OPC UA.