Abstract

This article presents and illustrates a functional modeling-based representation of digital twinning (DT) architectures. We provide a detailed review of the existing architectures and frameworks intended for use on product digital twins. We identified gaps in the prior work on architectures and frameworks for DT of products, product families, and systems. We identified a need for robust representation schemes that enable product-specific synthesis and analysis of DTs, which the existing DT architecture representations do not offer. We integrated the efforts of the researchers on DT architectures in our functional modeling-based architecture representation approach. We included selected attributes of each reviewed framework and addressed the identified gaps through our functional modeling-based DT architecture representation. The proposed architecture representation approach opens up new avenues of research and can potentially help improve the design process for product DT. This paper illustrates our approach through an instructional example of a COVID-19 testing breathalyzer kiosk designed as a rapid response to the COVID-19 pandemic.

1 Introduction

The first industrial revolution is considered to be mechanization, and water and steam-based power; the second is related to electric power, assembly line, and mass production; and the third industrial revolution is the inclusion of a computer, internet, and automation. The fourth industrial revolution that consists of deeply interconnected physical, cyber–physical, and software components is now coined as Industry 4.0 [1]. Industry 4.0 is an all-encompassing term representing the ongoing industrial revolution. A key new capability available in Industry 4.0 is the creation of digital twins. A digital twin (DT) is the virtualization of a physical system. It involves replicating (or twinning) the physical components, and environmental conditions coupled with real-time bidirectional information exchange. In the context of digital twinning (DT), the physical product is referred to as a physical twin (PT). DTs offer advantages over the previous state of the art of conventional graphic models and their simulations. DTs are virtual representations of the physical systems and not merely simulations. One of the main differences between a simulation and a DT of any system is the real-time bidirectional data exchange. Simulations are typically used to verify system performance under predefined conditions. DTs, on the other hand, provide real-time information on the system’s behavior and parameters. Another difference is that the digital twins represent specific instances of products or systems, whereas the simulations are general to all instances. For example, a simulation of a particular make and model of automobile is reasonably helpful to demonstrate and predict the behavior of vehicles that fall within that specific model. Digital twinning, for this case, is the process of creating a virtual replica of vehicles. Storing the digital twins on the cloud-servers provides an additional advantage of ubiquitous access. The real-time data from the sensors on physical machines are synchronized with their respective digital twin. The real-time data can then be used as one of the inputs in the simulation to gain real-time insights into each vehicle, and personalized decision-based treatment could be applied. One of the key benefits of having a digital twin for any system, product, or component is predicting and optimizing its performance in real-time, especially under varied or unexpected situations. We clarify that the term “real-time” should be contextualized with appropriate frequency and fidelity associated with it.

Based on how one defines the term digital twin and how one plans to use it, a digital twin can be envisioned to benefit different stages of engineering design [26]. For example, Tao et al. [7] proposed a DT-driven product design process for existing products. Their framework includes the use of DT for task clarification, performance prediction, verification of manufacturing processes, and verification of functions. Apart from the popular characteristics that define a digital twin, Tuegel et al. [8] add that digital twins can update data in real-time. Virtual models can undergo continuous improvement through parallel comparison of virtual space with physical space.

DT developments are fueled by smartly managed big data, cloud computing, intelligent sensors, cyber–physical systems, and other related technologies. In this article, we provide a brief review of the state of the art in digital twinning and related technologies in the context of the potential impact on new product design and redesign of the existing products. We also review a few case studies of DT implementations and highlight challenges that the researchers face during DT implementations. A central challenge that we identified for product DT is the contrasting reference architectures and standards and a lack of generalized approach to design product DT. A systematic approach is needed to observe the product architecture in both DTs and PTs and their commonalities and distinctions. Functional modeling is one such potential approach through which the modularity of product architectures can be identified heuristically [9,10]. Stone et al. [9] utilized functional modeling for engineered product architecture and proposed a heuristic method to identify functional modules in the products. Bhasin et al. [10] used functional modeling in biologically inspired product architecture and explored function sharing across modules. In this paper, we propose using the functional basis to create functional models of digital twins. The functional modeling-based approach provides a more generalized way to represent architectures of products and their DTs. Functional modeling is one of the important parts of the design process, which uses the functional basis to represent the product design and architecture. The functional basis reduces ambiguity at the modeling level and increases information uniformity [11]. The functional basis also enables design automation of some tasks through organized storage and function information retrieval.

To illustrate our approach, we present an instructional example of a breathalyzer kiosk that could potentially be used as a COVID-19 screening device using the patient’s exhaled breath. The example provides a thorough instructional explanation of a function-based representation for the DTs of products. Through the example of function-based representation, we also gain insights into the process of developing a product digital twin and how the current state of the art in various technologies could help DT implementation for products.

2 Review of State of the Art in Digital Twins: A Product Design Perspective

This section reviews and summarizes the critically relevant research on digital twins and related technologies such as cyber–physical systems, intelligent sensors, big data management & communication, and digital design & optimization. As we mentioned earlier, DT encompasses a broad range of dimensions and aspects such as smart cities, smart factories, human resource management, and business strategies. However, we primarily adhere to reviewing papers related to DT and allied technologies from a product and system design perspective. The aim of the literature review is to observe the DT process followed by the researchers.

2.1 Digital Twins in Design.

The concept of accurately modeling the physical domain was pioneered at NASA, where they initiated digital twins for remote monitoring of the simulations of their spacecraft from the ground. According to Rosen et al. [12], the digital twin approach is the next wave in modeling, simulation, and optimization technology. In the context of digital twins, they redefine the role of simulation as the core functionality of systems using seamless assistance throughout its lifecycle. There are several commercially available digital twin solution platforms for different purposes such as those developed by General Electric (GE), PTC, Dassault Systems, DXC, Bosch, Siemens, Microsoft Azure, to name a few. GE developed the DT of a jet engine that enables the configuration of individual machines, prior to their manufacturing and commencement [13]. GE’s DT is based on the PREDIX platform that offers asset connectivity, edge technologies, machine learning (ML), big data processing, asset performance management (APM), and implements asset-centric digital twins. Microsoft Azure Digital Twin is a cloud-based service used to create comprehensive models of the physical environment, which also predicts the maintenance needs of the factories [14]. PTC developed a DT platform that provides real-time failure analysis and corrective actions [15]. Siemens developed a platform named Simcenter 3D [16], which provides DT services for products, production floors, and smart-plants. DXC Technology built a DT for the hybrid car manufacturing process for the performance prediction of the car before committing the changes in the manufacturing process [17]. Damjanovic-Behrendt and Behrendt [18] provided a list of open-source technology resources that could lead to a full-fledged open-source digital twin modeler such as data exchange and connectivity, middleware software deployment, data representation and visualization, streaming data processing tools, open data formats and ontologies for smart manufacturing, machine learning, and analytics. Lu et al. [3] reviewed representative applications of digital twin in alignment with their proposed reference model. They further discuss issues such as communication latency requirements, standardization requirements, architecture patterns, and version management for digital twin. In their paper on digital twin-driven product design, Tao et al. [19] detail the application of a new digital twin framework and the management of the generated data toward efficient product lifecycle management (PLM). They highlighted a few issues in the conventional PLM such as duplicity of the data, and the lack of connectivity and context of data generated at various stages of product lifecycle. They also pointed out that the DT can be advantageous for a systematic analysis of the data generated from simulations and virtual models. They advocate the use of DT for design, where DT can play an important role in conceptual design, detailed design, and virtual verification of the design. Digital twin-driven virtual verification could potentially use the full data of equipment, environment, material, customers’ physical characteristics, and historical data on prior decision and provide an improved and sophisticated way of designing and decision-making.

Owing to the Industry 4.0 revolution, the industry is becoming more and more complex. Such complex manufacturing systems require sophisticated methods for short-term and long-term fault prognoses. Artificial intelligence (AI) and ML in combination with sophisticated sensor networks can be very helpful in long-term fault prognosis in automated manufacturing facilities [20]. Digital twin-driven product design and product lifecycle management, which provides data interconnectivity at each phase of design and product lifecycle, reduces data redundancy and offers relevance to a physical product rather than simulated data [3,5,7,19,21].

2.2 Enabler Technologies for Digital Twin.

In the present era of data deluge, the collection, storage, extraction, and analytics of big data play a vital role in developing the Internet of Things (IoT) and intelligent sensors, which ultimately contribute to Industry 4.0. Cyber security of the IoT network has played a critical role in fostering a widespread acceptance of IoT and other cyber–physical systems. We present a broad-level overview of the enabler technologies that play a significant role in DT developments as shown in Fig. 1. We categorize the enabler technologies into four categories according to their role in different implementation stages of DT: (1) physical domain, (2) virtual domain, (3) data domain, and (4) connectivity. The physical domain category includes technologies necessary to be implemented in the physical twin of the product. Although the technologies in this category are external to DT, they are crucial for successful DT implementation.

Fig. 1
A broad depiction of the enabler technologies of DT is shown here. The enabler technologies are categorized into (1) physical domain, (2) virtual domain, (3) data domain, and (4) connectivity.
Fig. 1
A broad depiction of the enabler technologies of DT is shown here. The enabler technologies are categorized into (1) physical domain, (2) virtual domain, (3) data domain, and (4) connectivity.
Close modal

The physical domain includes data-acquisition devices, measurement techniques, sensors, actuators, and smart devices and products. The technologies in the virtual domain are modeling (e.g., geometry, material, physics, statistical, semantic, machine learning models, and so on), simulations (e.g., finite element analysis, finite volume analysis, computational fluid dynamics, and so on), visualization, and augmented and virtual reality (AR and VR). The virtual domain technologies can be considered a core of the digital twin since the domain knowledge is incorporated in this domain. The data domain includes hardware, software, and algorithms for data acquisition, storage, extraction, manipulation, data fusion, and analytics. The fourth domain is related to the connectivity of the physical, virtual, and data domains. Internet, cloud computing, cybersecurity, and various communication protocols are part of the connectivity domain. These broad-level technology enablers include various technologies that influence the performance of the enabler technologies and DT in general. For example, internet includes Wi-Fi and cellular networks; and cloud computing includes edge computing that handles low latency computing requirements [22,23]. Edge computing is a type of distributed computing, which facilitates local data storage and computing. There are several protocols that enable the communication between different devices. Message queuing telemetry transport (MQTT) is one such protocol, which uses a lightweight publish/subscribe messaging transport. MQTT is ideal for connecting remote devices with a small code footprint and minimal network bandwidth [24]. Such protocols along with edge computing are used in a wide variety of industries, such as automotive, telecommunications, and manufacturing.

A central challenge for all digital transformation technologies is the secure and standardized exchange of data and information across technologies. There exist several semantic standards across the world, and different manufacturers follow different standards, which can further complicate the issue of data integration. The OPC foundation came up with a framework named OPC unified architecture (OPC UA) to address the standardization issue. OPC UA provides information modeling standards that enable semantic interoperability for industrial applications. In an online article, Hoppe [25] writes that the secure data and information exchange between devices, machines, and services is a primary challenge with the Industrial Internet of Things (IIoT). He stated that the Reference Architecture Model for Industrie 4.0 (RAMI 4.0 [26]) recommends the IEC standard 62541 OPC UA for implementing the communication layer. OPC UA claims to be protocol independent as in, both client–server models and publisher–subscriber models can be implemented within the framework. Furthermore, he also mentioned that any product marketed as “Industry 4.0 enabled” must be OPC UA-capable. Thus, OPC UA is on its path to becoming a global standard for guiding Industry 4.0 implementations.

Some of the common data sources in the production facilities include machine tools, production equipment, sensors, controllers, and other hardware devices. The translation and interpretation of the machine data from different equipment usually consume developers’ and integrators’ time. However, well-defined semantic standards offer data uniformity, which could save the users and integrators a lot of time and effort. The MTConnect standard (ANSI/MTC1.4-2018) provides a semantic vocabulary for manufacturing equipment. Through MTConnect, structured and contextualized data can be delivered to equipment without any proprietary format. MTConnect can accommodate manufacturing equipment, devices, and software and offers a common language for these systems to communicate. The common semantic language makes it possible to monitor various machine and software parameters easily.

Apart from the standardization issues in implementation, DT has several challenges that need attention. The primary challenge is the lack of interpretable models with reasonable accuracy. Both physics-based and data-driven models are necessary to sufficiently represent the system’s physics and environment conditions. The computer simulations for virtualizations need to be modeled accurately for the physics entailed in the product, process, and environmental conditions depending on the scope of the digital twin. Although simulation in engineering has progressed extraordinarily in the past few decades, the digital twin is yet to be interwoven in engineering design. Physics-informed data-driven modeling approaches [27,28] and reduced-order modeling [29] are potential solutions to speed up the development of digital twins. Since the human interactions with the digital twins are primarily via visual mode, better and accurate visualization of the virtual space is crucial. DT faces a few other challenges: the computing times for simulations, the processing times for data storage and retrieval, and issues with time synchronization between multiple devices.

3 Digital Twin Frameworks and Architectures

A general architecture for DT models was first described in a whitepaper by Grieves [30]. In this architecture, the DT is modeled in three dimensions—the physical entity (PE), the virtual model, and the physical–virtual connection. Further extending Grieves’ architecture, Tao et al. [31] proposed a five-dimensional DT model. The five dimensions include PE, virtual entity (VE), DT data entity (DD), services entity (Ss), and connections (CN). The first four dimensions are connected to each other. Tao et al. represented the entities as coupled functions in their framework. The virtual entity is a function of the geometry model, physics model, behavior model, and rule model. The function of services entity (Ss) is to calibrate and ensure the performance of VE with respect to the PE data. Ss is a function of product function, input, output, quality, and state. The DT data entity is a function of domain knowledge and the fusion of the data from PE and VE. The connection entity is defined as a function of CN_SD, CN_PD, CN_VD, CN_PS, CN_VS, and CN_PV, which denote the bidirectional connections between Ss and DD, PE and DD, VE and DD, PE and Ss, VE and Ss, PE and VE, respectively. The five-dimensional framework proposed by Tao et al. [31] suggests that all domains—physical, virtual, data, and services—are connected. However, in this framework, there is no scope for indicating the type of information and data that flows across different components and throughout the product lifecycle (e.g., status signal, control signal, sensor data, measurement data, and so on). Also, the specific variations in the DT architecture with respect to different twinning purposes are also not feasible. There is no specific detail related to the storage (e.g., local or cloud) and communication protocols of data. Also, the visualization of the DT architecture in relation with its PT product architecture is cumbersome for this framework.

The National Institute of Standards and Technology (NIST) published the International Organization for Standardization (ISO)/Draft International Standard (DIS) 23247—Digital Twin Framework for Manufacturing [32]. ISO 23247-2 provides a reference architecture for DTs in manufacturing. The NIST DT reference architecture has four domains—observable manufacturing domain, data collection and device control domain, core domain, and user domain. The observable manufacturing domain is external to the DT framework and provides context to the DT. The data collection and device control domain connects observable systems and corresponding DT through sensor data collection and actuation. The core domain facilitates the operations within the DT, such as data manipulations, simulations, modeling, and synchronization. The user domain provides user interactions, where the user can be human or machine. All four domains operate via their respective functional entities. An additional functional entity called the cross-system entity connects all four domains. The above-described DT framework can be modified to suit the twinning purposes such as machine health monitoring, fault prognosis, and remote operations. Thus, the reference architecture provided by NIST can accommodate different twinning purposes and includes the flow of data and information across different DT components. However, relating the DT architecture with the corresponding PT product architecture and the accommodation of communication protocol-related details are still not accommodated here.

As an extension to the five-level architecture for cyber–physical manufacturing systems by Lee et al. [33], Redelinghuys et al. [34] proposed a six-layer architecture for DT implementation. The first two layers include the physical twin-related information and their connectivity (e.g., sensors, actuators, controllers, data-acquisition devices). The third layer is the local data repository. The local data repository communicates with the IoT gateway (layer-4), and the simulation entity (layer-6) via OPC UA data exchange protocol; and with the cloud-based data repositories (layer-5) via the sql queries. The IoT gateway (layer-4) plays an important role of converting data to useful information, and transferring it to local and cloud-based repositories, and to the simulation entity via OPC UA. The fifth layer is the cloud-based information storage for information that does not require low latency. The sixth layer is the emulation and simulation layer, where the models are stored, and the computing is performed. The human or other machines interact with the sixth layer. In this six-layer architecture, the communication protocol and data storage-related details can be accommodated. The visualization of the data and information flow across different DT components can be clearly indicated. The parts of the architecture where human–machine interaction takes place are also clearly indicated. Although the relevance to the PT product architecture is not clearly indicative from this six-layer architecture, the information related to the type of data and signal flow is not clarified in this architecture.

Researchers have proposed several similar architectures in their approach to those described in detail above. For example, Damjanovic-Behrendt and Behrendt [18] presented an open-source approach for a digital twin demonstrator in the context of smart manufacturing. They provided a conceptual model and a micro-service architecture for their model. They proposed three building blocks: the management of data, models, and services in their technology in their conceptual model for digital twin.

Fig. 2
An illustrative black-box model to represent the PT functional model
Fig. 2
An illustrative black-box model to represent the PT functional model
Close modal
Fig. 3
An illustrative black-box model to represent the PT/DT functional model
Fig. 3
An illustrative black-box model to represent the PT/DT functional model
Close modal

4 Functional Modeling-Based Approach

Functional modeling is an abstraction technique that involves decomposing a system’s overall function into smaller and solvable functions [35]. It is a form-independent conceptual model of a product, where the product is represented as a set of functions and flows between the functions. Functional modeling provides a framework to decompose design problems, offers visual organization, and facilitates analysis. The functional basis offers a clear and consistent lexicon of functions and flows in a verb–object format, which comprehensively describes the mechanical design space. The functional modeling and functional basis enable design automation through organized storage and function information retrieval [11,36]. Functional modeling enables designers to make critical design decisions about the product architectures at the conceptual design stages. Therefore, we selected the functional modeling approach to represent the PT/DT architectures. We describe the stepwise procedure to generate the functional models of the products as first proposed by Stone and Wood [37].

As a first step (Step-1) of the functional modeling-based representation PT/DT architecture, we create a functional model of the PT. The stepwise process for generating functional models is as follows:

  • Step-1.1: Generate a black-box model of the product based on the primary functionality of the product. The black-box model shows the high-level functions performed by a system and the associated input/output flows. The overall function of the product is presented in the verb–object form. Figure 2 shows an illustrative black-box model of the PT of a product. Here, we distinctly indicate data, information, and status signals, due to the widespread use of these signal flows in DTs. Data signals can be used to represent the collection of raw observations in a structured or unstructured manner. The data collected using various sensors are a good example of such signals. Information signals contain organized, structured, and actionable data. For example, values of parameters, weights, decision variables, and so on can be represented using information signals. Status signals can be used to indicate the state of devices, instruments, or components.

  • Step-1.2: The next step in the functional modeling exercise is to develop the functional chains for each input/output flow. A functional chain consists of a sequence of functions that operate on each flow, from entry to exit. We identify the functions by interpreting the actions performed by the components on their associated functional flows. We use the functional basis to standardize the representation of functions in the form of a verb–noun pair [11]. The functional basis provides three levels of increasing refinement to choose standardized functional verbs: primary level, secondary level, and tertiary level. Sen et al. [38] indicate the secondary level as the most informative level in terms of information content and information density. The use of a tertiary functional basis further reduces the ambiguity due to abstraction. So, we recommend the use of secondary or tertiary level of abstractions in the functional representations. To ensure better repeatability of the functional models, we recommend that uniformity in the abstraction levels be maintained [39].

  • Step-1.3: Furthermore, we develop the functional chains based on the sequence of operations that act on a flow. We do not model the operations that do not directly contribute to the flows. When a component or subassembly performs multiple functions on the same flow, we arrange the functions according to the spatial and/or temporal dependency of the functions.

    Similarly, as the next step (Step-2) in our functional modeling-based representation, a functional model is created for the DT of the product, and the exchange of data and information signals across PT/DT are connected via appropriate flows.

  • Step-2.1: First, we create a black-box model to represent the primary functions of the PT/DT pair as shown in Fig. 3. The functional flows associated with DT, and the flows representing exchanges between PT and DT comprise different types of signals (i.e., data, information, and status). Signal1, signal2, and signal3 are functional flows associated with data, information, and status in PT. Similarly, signal4, signal5, and signal6 are functional flows associated with data, information, and status in DT. Data (signal1) and status signals (signal3) are transferred from PT to DT. On the other hand, signal7, signal8, and signal9 represent the data, information, and status signals generated in DT and transferred back to the PT. Signal10, signal11, and signal12 are the output signals representing data, information, and status, which are specific outputs of DTs. For example, the model parameter updates, machine health status, or data generated via simulations can be considered as outputs of DTs.

  • Step-2.2: After defining the high-level function of PT/DT pair, we proceed to represent subfunctions of DT and generate function chains. Depending on the predetermined scope and fidelity of the DT, we identify the functions from the PT to be twinned. We indicate such functions in the DT functional model, which is represented as an extension to the PT functional model. Next, we refer to the PT functional model, seeking the data and status signal flows that could be connected to the DT functions. We follow the same process for creating function chains as described for PT functional modeling. We note that the DT functional flows primarily consist of signal flows.

5 An Instructional Example: A Breathalyzer Kiosk As a Complementary COVID-19 Screening Method

A few research articles provide scenario-based case studies that apply Industry 4.0 and DT principles, frameworks, or guidelines to the existing system [31,34,4048]. Schroeder et al. proposed using AutomationML to model attributes related to the digital twin for manufacturing and product-service systems [48]. They presented their approach in the context of cyber–physical systems and illustrated their proposed method through a case study of a component (an industrial valve). The physical part of the valve has an actuator that is intended to operate continuously. There are sensors such as a temperature sensor, battery level, and voltage sensor to monitor the operations. They used AutomationML because it provides mechanisms to map automation system components. They modeled each physical component attribute. To make data available to external systems, they chose to use an IoT middleware named FIWARE because this tool provides an abstraction of the complexity of the communication between systems, allowing developers to target their efforts on the problem being solved rather than dealing with technical complexities. Through the middleware, the external tools can communicate in the form of JSON files containing real-time physical attributes and sensor data. To illustrate our architecture representation approach, we carried out an illustrative case study. We built a case study with a moderately complex product involving multiple components and technologies that require multidisciplinary engineering effort. We used a functional model-based representation of the DT architecture and explained its implementation via a case study.

In handling the unprecedented COVID-19 pandemic, testing the patients for SARS-CoV-2 played a critical role [49,50]. Availability and accessibility of rapid testing could significantly impact how the pandemic situation is predicted and controlled. As a rapid response to the pandemic situation, Texas A&M System collaborated with Worlds Enterprises Inc. and developed a solution in the form of a rapid screening device for COVID-19 [51]. The screening device is a breathalyzer, which collects patient’s breath as input. Sophisticated pretrained machine learning algorithms predict the probability of corona virus (SARS-CoV-2) presence in the collected breath. The breathalyzer device provides a complementary screening approach for COVID-19 testing. The breathalyzer has multiple subassemblies, equipment, and components on-board, making it a moderately complex product. The multidisciplinary nature of the design problem, rapid design and manufacturing approach, and relevance to the current trends in engineering design makes it a suitable example to illustrate for our DT architecture representation approach.

We organize the illustration in this section as follows. First, we describe the product in detail and justify the choice of the product as a working example. Then, we assess our product to the available standards and expectations on digital twinning. We describe the sensors available on the device and their connectivity with one another and to the on-board computer. We also describe a planned outline of what the digital twin implementation would be in a final case study.

5.1 Product Description.

The COVID-19 breathalyzer is a mobile device that takes a human breath as input and is intended to display COVID-19 infection through correlation to COVID-19 positive or negative biomarkers [52,53]. The breathalyzer leverages mass spectrometry technology to analyze and identify different compounds and molecules present in a breath sample. The breath is injected into a specifically designed breath receptor, which goes through a heated air-flow path, a compressed breath injection system, and a membrane filtration system. The pressurized breath flow passes through the membrane, filters extraneous components, and lets molecules and compounds of interest into the vacuum chamber. A mass spectrometer (residual gas analyzer or RGA) is located inside the vacuum chamber, identifying the compounds of interest. In mass spectrometry, molecules are bombarded with electrons; then, the mass-to-charge ratio is measured to determine the mass of the volatile organic compounds (VOCs). Once the mass numbers of the VOCs are known, machine learning identifies the specific molecule and determines if it matches known biomarkers for SARS-CoV-2.

The breathalyzer may need to collect one full breath (>0.5 L) of the subject to sufficiently identify the presence of the biomarkers if any. The breathalyzer is expected to ensure sanitization and purging after each breath analysis to ensure an accurate analysis. The breathalyzer may also need to provide a safe discharge of the collected breath sample. A certain level of vacuum and a range of temperatures for various components is also one of the process requirements. The breathalyzer is designed to use the ambient air to purge the system after each breath collection to make the machine ready for the next breath collection.

5.2 Functional Model of the Breathalyzer Kiosk.

The design team translated the above needs to engineering requirements (not detailed here) and created a functional model of the breathalyzer following the procedure described in Sec. 4. The functional modeling of the physical twin of the breathalyzer kiosk is shown in Fig. 4. Here, there are three primary function chains. The first one is associated with breath capturing and analysis. This function chain starts with receiving the breath of the patient, which is indicated by the function import gas performed by module M6 (in Fig. 5). Then, the breath is transferred and heated along the way in the air-flow system (M7). The functions of the air-flow system are described by transport gas and transmit thermal energy (TE). Next, the breath proceeds to the breath compression system (M4), where the breath is collected (collect gas and contain gas) and transferred further after compressing the gas (shape gas). The breath is then filtered through a heated silicone (polydimethylsiloxane (PDMS)) membrane (M5) and is collected in the vacuum chamber (M2) to be analyzed by an RGA. The functions extract gas, collect gas, and sense gas represent the operations of the membrane, vacuum chamber, and RGA. After analyzing the breath, it is filtered by an N95 respirator filter (extract gas) and then exhausted in the environment (export gas). Similarly, the second function chain performs broad functions of cooling the equipment, and the third one controls and supplies the electricity. The vacuum chamber, inlet module, membrane, breath capture system (BCS), and air-flow system have temperature sensors, which provide a feedback signal to control their temperatures.

Fig. 4
A simplified functional model of the breathalyzer kiosk (the identified modules are from the physical twin and are listed in Table 1)
Fig. 4
A simplified functional model of the breathalyzer kiosk (the identified modules are from the physical twin and are listed in Table 1)
Close modal
Fig. 5
An exploded view showing the subassemblies of a breathalyzer kiosk for COVID-19 detection. Description of each subassembly is detailed in Table 1.
Fig. 5
An exploded view showing the subassemblies of a breathalyzer kiosk for COVID-19 detection. Description of each subassembly is detailed in Table 1.
Close modal

Multiple functions can be combined to represent a structure. For example, the air-flow system in the breathalyzer kiosk is associated with the transport and heating of the breath. Therefore, the functions transport gas and transmit TE were two of the multiple identified functions that act on the input gas. Multiple functions associated with a structure are arranged in a way that indicates the temporal dependencies of the functions. For example, the BCSsubassembly performs the functions collect gas and transfer gas, but the fact that the function collect gas should be completed before completing transfer gas shows a temporal dependency. The individual functional chains are then aggregated to create a complete functional model for the breathalyzer kiosk.

We divided the product into multiple modules based on the functionalities and assembly sequence. We identified and highlighted the form-based modules in the functional model in Fig. 4. In Fig. 5, we show 13 different subassemblies (M1–M13) of the breathalyzer kiosk. We list the subassemblies and their high-level function descriptions in Table 1. We briefly describe the functions of subassemblies below.

Table 1

List of subassemblies in the breathalyzer kiosk and brief descriptions of their functions

Module numberSubassemblyDescription
M1Frame subassemblyProvides structural support to other subassemblies
M2Mass spectrometer and vacuum chamber subassemblyIncludes a vacuum chamber, a turbo pump, a mass spectrometer (RGA), and a Pirani gauge. The detection of chemicals in the breath is carried out in the vacuum chamber using the mass spectrometer
M3Roughing pump assemblyThe roughing pump is a diaphragm pump that helps generate an initial vacuum (up to 1 Torr) inside the vacuum chamber
M4Breath compression system (BCS)BCS is a piston-cylinder arrangement operated by a linear actuator. The purpose of BCS is to pressurize the breath air before filtering through the membrane
M5Membrane subassemblyThe membrane assembly mainly supports a PDMS membrane that filters out unnecessary compounds from the breath sample before sending it to the vacuum chamber
M6Inlet subassemblyIt consists of a copper receptor that collects breath air sample and transfers to the air-flow system
M7Air-flow subassemblyThe air-flow assembly consists of a bypass valve, a three-way solenoid valve, two check valves, a sampling pump, and copper piping. The function of this subassembly is to facilitate and direct the flow of the breath sample and clean air during sampling and purging cycles
M8Electronics control subassemblyIt accommodates relay switches, controllers, GPIO board, cooling fans, an on-board computer, and other electronic components
M9Monitoring panel subassemblyIt consists of temperature controllers that control temperatures of five components (BCS, inlet, membrane, vacuum chamber, air-flow system)
M10Power supply subassemblyConverts 110 V AC into 24 V and 12 V DC power
M11Display subassemblyIt consists of an LCD screen that facilitates human–machine interactions
M12Shell subassemblyIt provides a protective and aesthetic cover to the kiosk
M13Leg subassemblyIt helps adjust the height of the kiosk while sampling
Module numberSubassemblyDescription
M1Frame subassemblyProvides structural support to other subassemblies
M2Mass spectrometer and vacuum chamber subassemblyIncludes a vacuum chamber, a turbo pump, a mass spectrometer (RGA), and a Pirani gauge. The detection of chemicals in the breath is carried out in the vacuum chamber using the mass spectrometer
M3Roughing pump assemblyThe roughing pump is a diaphragm pump that helps generate an initial vacuum (up to 1 Torr) inside the vacuum chamber
M4Breath compression system (BCS)BCS is a piston-cylinder arrangement operated by a linear actuator. The purpose of BCS is to pressurize the breath air before filtering through the membrane
M5Membrane subassemblyThe membrane assembly mainly supports a PDMS membrane that filters out unnecessary compounds from the breath sample before sending it to the vacuum chamber
M6Inlet subassemblyIt consists of a copper receptor that collects breath air sample and transfers to the air-flow system
M7Air-flow subassemblyThe air-flow assembly consists of a bypass valve, a three-way solenoid valve, two check valves, a sampling pump, and copper piping. The function of this subassembly is to facilitate and direct the flow of the breath sample and clean air during sampling and purging cycles
M8Electronics control subassemblyIt accommodates relay switches, controllers, GPIO board, cooling fans, an on-board computer, and other electronic components
M9Monitoring panel subassemblyIt consists of temperature controllers that control temperatures of five components (BCS, inlet, membrane, vacuum chamber, air-flow system)
M10Power supply subassemblyConverts 110 V AC into 24 V and 12 V DC power
M11Display subassemblyIt consists of an LCD screen that facilitates human–machine interactions
M12Shell subassemblyIt provides a protective and aesthetic cover to the kiosk
M13Leg subassemblyIt helps adjust the height of the kiosk while sampling

Each subassembly could be assembled in parallel and sequentially put together to build the whole assembly of the kiosk. Some simpler subassemblies in the kiosk are a frame structure (M1), a shell (M12), and a leg subassembly (M13), which provides structural support, a protective cover, and an up-down movement to the kiosk, respectively. The breath is collected via an inlet subassembly (M6). The inlet module is made from copper, which helps sanitize the exposed surfaces. The breath (or clean air during the purging cycle) then travels through an air-flow system to reach the breath compression system (BCS). The BCS (M4) consists of a piston-cylinder mechanism actuated by a linear actuator. BCS helps capture a large volume of breath air from the patient and provides a pressurized injection of the breath into the vacuum chamber (M2). The breath gets filtered through a PDMS membrane (M5) before entering the vacuum chamber. The electrical board subassembly (M8) consists of the necessary electrical connections to the actuators, temperature controllers, heaters, pumps, mass spectrometer, and other accessories. It also accommodates an on-board computing unit, cooling fans, GPIO boards, and relays.

5.3 Current Status of the Digital Twin of the Kiosk.

In this subsection, we assess the status of the current design and development of the breathalyzer kiosk in the context of digital twinning. We note the system’s current capabilities and provide suggestions on the steps to move the product to a digital twin platform. The present kiosk consists of a 3D model of the kiosk, a functioning physical prototype, and a remotely operable graphical user interface (GUI) for real-time information exchange and electrical component operation. Thus, according to the levels of digital twin mentioned in the Gemini principles [54,55], the present design of the kiosk has characteristics of the level-2 digital twin.

Figure 6 showcases the operation flow and the flow of data and information for the current status of the kiosk. The user interacts with the user interface (UI), through which the user can change the states of different components such as pumps, RGA, and heaters. The RGA analysis data and status information is recorded locally on the on-board storage devices in the form of “.csv” files. The user then manually extracts the data from the local storage and transfers it to the analysis software (matlab®, in our case). The picture used here to represent the data analysis is from a calibration sample and does not represent the data collected from the patients. The user is also involved in the data analysis process, where the data are converted into actionable information. In our case, the user would extract the data relevant to the breath of the subjects and transfer it further in the data pipeline to be analyzed further for COVID-19 detection.

Fig. 6
Flow of data, information, and operations status of the breathalyzer kiosk (without the DT)
Fig. 6
Flow of data, information, and operations status of the breathalyzer kiosk (without the DT)
Close modal

Following the steps detailed in Sec. 4 and using the information from Fig. 5 and Table 1, we generated a functional model for the PT/DT of the breathalyzer kiosk. Figure 7 shows the functional modeling representation of the breathalyzer PT/DT system.

Fig. 7
Functional model of the PT and DT of the breathalyzer kiosk
Fig. 7
Functional model of the PT and DT of the breathalyzer kiosk
Close modal

5.4 Sensor Network for Breathalyzer Kiosk.

This subsection provides details on different sensors used in the kiosk and describes how they are connected with each other and with the on-board computing unit. We include the information related to the parts in observation, the location of sensors, the type of information that the sensor records, and their connectivity with the other sensors or the on-board CPU as listed in Table 2.

Table 2

Information on sensor locations and connectivity for the COVID-19 breathalyzer kiosk

SensorObserved parts and modulesSensor locationSensor dataConnectivity
Present status of the kiosk
ThermocoupleBCS cylinder (M4), vacuum chamber (M2), inlet (M6), membrane assembly (M5), air-flow system (M7)In contact with partsTemperatureTemperature controller
Planned sensors for the DT implementation
Infrared sensorBCS cylinder (M4), vacuum chamber (M2), inlet (M6), membrane assembly (M5), air-flow system (M7), turbopump (M2), RGA (M2), inlet and outlet fans (M8)NoncontactTemperatureCPU
Position sensorBCS actuator (M4), BCS cylinder (M4), RGA (M2), membrane assembly (M5), cover shell (M12)In contact with parts/noncontactco-ordinatesCPU
AccelerometerKiosk base (M13), BCS actuator (M4)In contact with partsAccelerationCPU, position sensor
Strain gauge vibration sensorBCS cylinder (M4), turbopump (M2), roughing pump (M3), kiosk base (M13)In contact with partsVibrationCPU
RFID tagsBCS system (M4), RGA (M2), membrane assembly (M5)In contact with partsComponent identificationCPU
Flow sensorInlet pipe (M6), BCS outlet pipe (M4), exhaust pipe (M7)In-line with pipesFlowCPU
SensorObserved parts and modulesSensor locationSensor dataConnectivity
Present status of the kiosk
ThermocoupleBCS cylinder (M4), vacuum chamber (M2), inlet (M6), membrane assembly (M5), air-flow system (M7)In contact with partsTemperatureTemperature controller
Planned sensors for the DT implementation
Infrared sensorBCS cylinder (M4), vacuum chamber (M2), inlet (M6), membrane assembly (M5), air-flow system (M7), turbopump (M2), RGA (M2), inlet and outlet fans (M8)NoncontactTemperatureCPU
Position sensorBCS actuator (M4), BCS cylinder (M4), RGA (M2), membrane assembly (M5), cover shell (M12)In contact with parts/noncontactco-ordinatesCPU
AccelerometerKiosk base (M13), BCS actuator (M4)In contact with partsAccelerationCPU, position sensor
Strain gauge vibration sensorBCS cylinder (M4), turbopump (M2), roughing pump (M3), kiosk base (M13)In contact with partsVibrationCPU
RFID tagsBCS system (M4), RGA (M2), membrane assembly (M5)In contact with partsComponent identificationCPU
Flow sensorInlet pipe (M6), BCS outlet pipe (M4), exhaust pipe (M7)In-line with pipesFlowCPU

5.5 Steps Towards Digital Twinning of the Breathalyzer Kiosk.

The digital platform consists of sensing logics, control models, simulation models, remote access platforms, GUI, and AR/VR software. For our kiosks, we have a GUI that can be accessed locally and remotely, the sensing logics, control models, data acquisition and storage-related codes, stored in the on-board computing device, and on the cloud to be accessed and controlled remotely.

With continuously recorded breath data, breath identification rules, NIST Chem webbook, knowledge related to COVID-19 biomarkers, and pretrained ML models, the DT predicts the COVID-19 positive or negative results for subjects. The user can obtain the results on the globally accessible user interface.

We provide a few suggestions on the design and operation of the kiosk to move up in levels of DT according to the Gemini Principles on DT [54]. The existing 3D model can be enriched with the material properties of each component. A real-time structural behavior (i.e., static and dynamic) sensing could be incorporated using position sensors implemented on various parts. Lifecycle analysis and uncertainty quantification can be performed via real-time condition monitoring of major components (membrane, RGA, TC, pumps, respirators, leg, BCS actuator, and so on). In the GUI, the temperature and heat transfer data can be integrated for the condition monitoring of the kiosk. A real-time air-flow operation sequence and the membrane gas injection can also be represented in the GUI. To move further to the level-5 digital twin, we need bidirectional real-time information and data exchange for all the functions of the breathalyzer. For the real-time system performance indication, a calibration signal analysis can be incorporated. The calibration signal analysis may require a design change, including in-built gas canisters of the calibrants.

5.6 A Modified Functional Model Representation.

The functional model of the PT/DT product pair (Fig. 7) includes a large amount of information. Specifically, the DT functional model consists of various types of signal flows, which need distinct representations to convey a more meaningful identity of the flows. Therefore, in addition to the commonly used functional flows (i.e., material, energy, and signal), we include models (e.g., physics models, geometric models, statistical models, and so on), rules (e.g., operation sequence, flow logics, Boolean rules, and so on), and knowledge databases (e.g., taxonomies, ontologies, design repositories, reference tables, and so on) as functional flows in the DT functional representation. Furthermore, we divided the signal flow into data, information, and status signals. Here, data refers to the raw data generated in the PT by sensors and onboard devices. We specified the model, the rules, the knowledge, and specific signal representations as functional flows to represent the standard functions observed in the existing DT architectures [19,32,56]. An example of such a signal is machine health status signals. Similarly, data signals and information signals also establish interactions between PT and DT. Note that the function and flows used here to represent the PT/DT architecture are an extension of the functional basis.

In the representation, we extend the previously described functional model of the physical twin of the kiosk (Fig. 4) and append the operations of the digital twin within the functional modeling framework as shown in Fig. 8. We differentiate various signals such as data signal, information signal, control signal, and component health signal using different line types. We import models, rules, and knowledge databases in the functional model. Specifically, we import (1) the rule-based models for controlling various devices, and identification criteria for detecting breath signals; (2) NIST Chem webbook [57] for the chemical information, COVID-19 biomarker information [52,53]; (3) the machine learning models that compare the breath signals with the biomarkers, and predictive models for machine health monitoring. We have a detailed geometric model (3D) for the kiosk; however, we have not performed one-to-one mapping of the digital twin functions (i.e., animations, real-time structural and kinematic simulations, and so on) with the 3D model. For this reason, we have not included the geometrical models in the functional model representation of the DT.

Fig. 8
A modified functional model representation for PT/DT architecture of a breathalyzer kiosk
Fig. 8
A modified functional model representation for PT/DT architecture of a breathalyzer kiosk
Close modal

The status of the devices and equipment (e.g., heaters, RGA, Turbopump, and so on) is stored locally. In our case, the local storage and computing are performed on an on-board computing unit. The RGA continuously records the mass spectroscopy data. The status data are transferred to a cloud (global) storage. The user can interact with the global data via a remotely accessible interface. The user can observe the real-time health and equipment status information and feed decisions via the interface. The user inputs are first stored globally and transferred to the local device at regular intervals. The device control logic, the current health of the equipment, user inputs, and sensor data are transferred to the local computing unit that generates control signals and relays them to the respective equipment or devices.

We emphasize that we are not proposing any novel architecture for the digital twins in this paper. We compiled the attributes of existing DT architectures and moved toward a standardized representation of DT architectures using functional modeling. For example, from the ISO 23247-2 reference architecture for DTs, we got the inspiration to differentiate between different types of signal flows (e.g., data signal, information signal, and status signal). We also introduced additional flows to represent models, knowledge databases, and rules in addition to the standard flows used in the functional basis. This exercise provides designers and the engineering design research community a familiar way to understand and explore new avenues in DTs. Through the new functional modeling-based representation, we can potentially identify similarities in product architectures of DT with sophisticated metrics for product functional similarity [58,59]. The identification of multiple similar architectures may enable the applicability of rules, knowledge, and models across different product ranges. The transfer of design knowledge across the products and product families will reduce the research efforts and implementation time for developing novel prediction and optimization algorithms for various twinning purposes.

6 Discussions and Future Directions

In this paper, we reviewed the existing architectures and frameworks for product DT. We identified gaps in the prior work carried out by researchers and engineers on developing architectures and frameworks for DT of products, product families, and systems. The existing frameworks and architecture representations do not provide a comprehensive way to include the various types of information and data, information exchange protocols, twinning purpose, and human interaction with DTs. More importantly, the product-specific details of the PT/DT bidirectional information exchanges, the decision rules, the models, and the knowledge-based information were not clearly represented. These gaps in the existing frameworks seem to provide an opportunity for incorporating genuinely new approaches to the study of problems that may result in better products, systems, and workflows. We integrated the attributes of existing DT architectures and presented a functional modeling-based approach for PT/DT architecture representation. The functional modeling-based approach presented in this paper could potentially offer insights into the development of product DT, differentiate the flow of various types of data and information, and facilitate the similarity identification across products and product families. We illustrated our approach with an instructional example of a breathalyzer kiosk designed as a rapid response to the COVID-19 pandemic.

For our future work, we plan to complete the sensors and prediction algorithm implementation to upgrade the DT levels of the breathalyzer kiosk as planned and detailed in the paper. Our proposed architecture representation approach could provide a rational basis for developing outlines of product design process flows for many other problems in engineering design related to DT. With sophisticated metrics for product functional similarity [58,59], we could potentially identify similarities in product architectures of DT. The identification of multiple similar architectures will enable us to carry out further research on the applicability of rules, knowledge, and models across different product ranges. To this end, some of our future works involve collecting several case studies from the literature consisting of PT/DT of products and developing functional models for the collected examples. We plan to check the feasibility of applying available modularity metrics and product similarity measures to the functional models. We would also like to explore various feasible architectures for a product at hand and identify the best amongst them. Repeating the exercise of identifying better architectures for several products may provide us with better insights on deciding the components of the system and their architectures. We may also explore the application of bio-inspired product architectures to the PT/DT systems and study their implications [60].

Acknowledgment

This work was supported in part by the Uniformed Services University of the Health Sciences (DOD) under cooperative agreement number HU00012120093. The US Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright notation thereon. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect those of the sponsors.

Conflict of Interest

There are no conflicts of interest.

Data Availability Statement

The datasets generated and supporting the findings of this article are obtainable from the corresponding author upon reasonable request.

References

1.
Lasi
,
H.
,
Fettke
,
P.
,
Kemper
,
H. G.
,
Feld
,
T.
, and
Hoffmann
,
M.
,
2014
, “
Industry 4.0
,”
Bus. Inf. Syst. Eng
,
6
(
4
), pp.
239
242
.
2.
Kritzinger
,
W.
,
Karner
,
M.
,
Traar
,
G.
,
Henjes
,
J.
, and
Sihn
,
W.
,
2018
, “
Digital Twin in Manufacturing: A Categorical Literature Review and Classification
,”
IFAC-PapersOnLine
,
51
(
11
), pp.
1016
1022
.
3.
Lu
,
Y.
,
Liu
,
C.
,
Kai Wang
,
K. I.
,
Huang
,
H.
, and
Xu
,
X.
,
2020
, “
Digital Twin-Driven Smart Manufacturing: Connotation, Reference Model, Applications and Research Issues
,”
Robot. Comput. Integr. Manuf.
,
61
, p.
101837
.
4.
Negri
,
E.
,
Fumagalli
,
L.
, and
Macchi
,
M.
,
2017
, “
A Review of the Roles of Digital Twin in CPS-Based Production Systems
,”
Procedia Manuf.
,
11
, pp.
939
948
.
5.
Zhuang
,
C.
,
Liu
,
J.
, and
Xiong
,
H.
,
2018
, “
Digital Twin-Based Smart Production Management and Control Framework for the Complex Product Assembly Shop-Floor
,”
Int. J. Adv. Manuf. Technol.
,
96
(
1–4
), pp.
1149
1163
.
6.
Singh
,
V.
, and
Willcox
,
K. E.
,
2018
, “
Engineering Design With Digital Thread
,”
AIAA J.
,
56
(
11
), pp.
4515
4528
.
7.
Tao
,
F.
,
Sui
,
F.
,
Liu
,
A.
,
Qi
,
Q.
,
Zhang
,
M.
,
Song
,
B.
,
Guo
,
Z.
,
Lu
,
S. C. Y.
, and
Nee
,
A. Y. C.
,
2019
, “
Digital Twin-Driven Product Design Framework
,”
Int. J. Prod. Res.
,
57
(
12
), pp.
3935
3953
.
8.
Tuegel
,
E. J.
,
Ingraffea
,
A. R.
,
Eason
,
T. G.
, and
Michael Spottswood
,
S.
,
2011
, “
Reengineering Aircraft Structural Life Prediction Using a Digital Twin
,”
Int. J. Aerosp. Eng.
,
2011
, pp.
1
14
.
9.
Stone
,
R. B.
,
Wood
,
K. L.
, and
Crawford
,
R. H.
,
2000
, “
A Heuristic Method for Identifying Modules for Product Architectures
,”
Des. Stud.
,
21
(
1
), pp.
5
31
.
10.
Bhasin
,
D.
,
Behmer
,
S. T.
, and
McAdams
,
D. A.
,
2021
, “
Fostering Function-Sharing Using Bioinspired Product Architecture
,”
ASME J. Mech. Des.
,
143
(
6
), p.
061401
.
11.
Hirtz
,
J.
,
Stone
,
R. B.
,
McAdams
,
D. A.
,
Szykman
,
S.
, and
Wood
,
K. L.
,
2002
, “
A Functional Basis for Engineering Design: Reconciling and Evolving Previous Efforts
,”
Res. Eng. Des.
,
13
(
2
), pp.
65
82
.
12.
Rosen
,
R.
,
Von Wichert
,
G.
,
Lo
,
G.
, and
Bettenhausen
,
K. D.
,
2015
, “
About the Importance of Autonomy and Digital Twins for the Future of Manufacturing
,”
IFAC-PapersOnLine
,
48
(
3
), pp.
567
572
.
13.
General Electric Predix Platform
, https://www.ge.com/digital/iiot-platform, Accessed April 25, 2022.
14.
Microsoft Azure Digital Twins
, https://azure.microsoft.com, Accessed April 25, 2022.
15.
Windchill, PTC
, https://www.ptc.com/en/products/windchill, Accessed April 25, 2022.
17.
Overton
,
J.
, and
Brigham
,
J.-C.
,
2017
, “The Digital Twin: Data Driven Simulations Innovate the Manufacturing Process,” White paper, May 26, 2017.
18.
Damjanovic-Behrendt
,
V.
, and
Behrendt
,
W.
,
2019
, “
An Open Source Approach to the Design and Implementation of Digital Twins for Smart Manufacturing
,”
Int. J. Comput. Integr. Manuf.
,
32
(
4–5
), pp.
366
384
.
19.
Tao
,
F.
,
Cheng
,
J.
,
Qi
,
Q.
,
Zhang
,
M.
,
Zhang
,
H.
, and
Sui
,
F.
,
2018
, “
Digital Twin-Driven Product Design, Manufacturing and Service With Big Data
,”
Int. J. Adv. Manuf. Technol.
,
94
(
9–12
), pp.
3563
3576
.
20.
Bukkapatnam
,
S. T. S.
,
Afrin
,
K.
,
Dave
,
D.
, and
Kumara
,
S. R. T.
,
2019
, “
Machine Learning and AI for Long-Term Fault Prognosis in Complex Manufacturing Systems
,”
CIRP Ann.
,
68
(
1
), pp.
459
462
.
21.
Dong
,
Y.
,
Tan
,
R.
,
Zhang
,
P.
,
Peng
,
Q.
, and
Shao
,
P.
,
2021
, “
Product Redesign Using Functional Backtrack With Digital Twin
,”
Adv. Eng. Inform.
,
49
, pp.
101361
101361
.
22.
Shi
,
W.
,
Cao
,
J.
,
Zhang
,
Q.
,
Li
,
Y.
, and
Xu
,
L.
,
2016
, “
Edge Computing: Vision and Challenges
,”
IEEE Internet Things J.
,
3
(
5
), pp.
637
646
.
23.
Satyanarayanan
,
M.
,
2017
, “
The Emergence of Edge Computing
,”
Computer
,
50
(
1
), pp.
30
39
.
24.
Yassein
,
M. B.
,
Shatnawi
,
M. Q.
,
Aljwarneh
,
S.
, and
Al-Hatmi
,
R.
,
2017
, “
Internet of Things: Survey and Open Issues of MQTT Protocol
,”
2017 International Conference on Engineering & MIS (ICEMIS)
,
University of Monastir, Monastir, Tunisia
,
May 8–10
.
25.
Hoppe
,
S.
,
2014
, “
Forerunner to Industry 4.0 and the Internet of Things
,”
Control Eng.
,
61
(
11
), pp.
48
51
.
26.
Hankel
,
M.
, and
Rexroth
,
B.
,
2015
, “
The Reference Architectural Model Industrie 4.0 (RAMI 4.0)
,”
ZVEI
,
2
(
2
), pp.
4
9
. https://www.zvei.org/fileadmin/user_upload/Themen/Industrie_4.0/Das_Referenzarchitekturmodell_RAMI_4.0_und_die_Industrie_4.0-Komponente/pdf/ZVEI-Industrie-40-RAMI-40-English.pdf
27.
Pokharel
,
R.
,
Pandey
,
A.
, and
Scheinker
,
A.
,
2021
, “
Physics-Informed Data-Driven Surrogate Modeling for Full-Field 3D Microstructure and Micromechanical Field Evolution of Polycrystalline Materials
,”
JOM
,
73
(
11
), pp.
3371
3382
.
28.
Raissi
,
M.
,
Perdikaris
,
P.
, and
Karniadakis
,
G. E.
,
2019
, “
Physics-Informed Neural Networks: A Deep Learning Framework for Solving Forward and Inverse Problems Involving Nonlinear Partial Differential Equations
,”
J. Comput. Phys.
,
378
, pp.
686
707
.
29.
Benner
,
P.
,
Ohlberger
,
M.
,
Cohen
,
A.
, and
Willcox
,
K.
,
2017
,
Model Reduction and Approximation: Theory and Algorithms
,
SIAM
,
Philadelphia, PA
.
30.
Grieves
,
M.
,
2014
, “
Digital Twin: Manufacturing Excellence Through Virtual Factory Replication
,”
White Paper
, vol.
1
, pp.
1
7
.
31.
Tao
,
F.
,
Zhang
,
M.
,
Liu
,
Y.
, and
Nee
,
A. Y. C.
,
2018
, “
Digital Twin Driven Prognostics and Health Management for Complex Equipment
,”
CIRP Ann.
,
67
(
1
), pp.
169
172
.
32.
Shao
,
G.
,
2021
, “
Use Case Scenarios for Digital Twin Implementation Based on ISO 23247
.” Advanced Manufacturing Series (NIST AMS),
National Institute of Standards
.
33.
Lee
,
J.
,
Bagheri
,
B.
, and
Kao
,
H.-A.
,
2015
, “
A Cyber–Physical Systems Architecture for Industry 4.0-Based Manufacturing Systems
,”
Manuf. Lett.
,
3
, pp.
18
23
.
34.
Redelinghuys
,
A. J. H.
,
Basson
,
A. H.
, and
Kruger
,
K.
,
2019
, “
A Six-Layer Architecture for the Digital Twin: A Manufacturing Case Study Implementation
,”
J. Intell. Manuf.
,
31
(
6
), pp.
1383
1402
.
35.
Beitz
,
W.
,
Pahl
,
G.
,
Feldhusen
,
J.
, and
Grote
,
K.
,
2007
,
Engineering Design: A Systematic Approach
, 3rd ed.,
Springer
,
London
, pp.
XXI
617
.
36.
Little
,
A. D.
,
Wood
,
K. L.
, and
McAdams
,
D. A.
,
1997
, “
Functional Analysis: A Fundamental Empirical Study for Reverse Engineering, Benchmarking and Redesign
,”
ASME 1997 Design Engineering Technical Conferences
,
Sacramento, CA
,
Sept. 14–17
.
37.
Stone
,
R. B.
, and
Wood
,
K. L.
,
2000
, “
Development of a Functional Basis for Design
,”
ASME J. Mech. Des.
,
122
(
4
), pp.
359
370
.
38.
Sen
,
C.
,
Caldwell
,
B. W.
,
Summers
,
J. D.
, and
Mocko
,
G. M.
,
2010
, “
Evaluation of the Functional Basis Using an Information Theoretic Approach
,”
Artif. Intell. Eng. Des. Anal. Manuf.
,
24
(
1
), pp.
87
105
.
39.
Kurfman
,
M. A.
,
Stock
,
M. E.
,
Stone
,
R. B.
,
Rajan
,
J.
, and
Wood
,
K. L.
,
2003
, “
Experimental Studies Assessing the Repeatability of a Functional Modeling Derivation Method
,”
ASME J. Mech. Des.
,
125
(
4
), pp.
682
693
.
40.
Hermann
,
M.
,
Pentek
,
T.
, and
Otto
,
B.
,
2016
, “
Design Principles for Industrie 4.0 Scenarios
,”
2016 49th Hawaii International Conference on System Sciences (HICSS)
,
Koloa, HI
,
Jan. 5–8
.
41.
Margherita
,
E. G.
, and
Braccini
,
A. M.
,
2020
, “
Industry 4.0 Technologies in Flexible Manufacturing for Sustainable Organizational Value: Reflections From a Multiple Case Study of Italian Manufacturers
,”
Inf. Syst. Front.
, pp.
1
22
.
42.
Strandhagen
,
J. W.
,
Alfnes
,
E.
,
Strandhagen
,
J. O.
, and
Vallandingham
,
L. R.
,
2017
, “
The fit of Industry 4.0 Applications in Manufacturing Logistics: A Multiple Case Study
,”
Adv. Manuf.
,
5
(
4
), pp.
344
358
.
43.
D'Emilia
,
G.
,
Gaspari
,
A.
, and
Natale
,
E.
,
2018
, “
Measurements for Smart Manufacturing in an Industry 4.0 Scenario A Case-Study on a Mechatronic System
,”
2018 Workshop on Metrology for Industry 4.0 and IoT
,
Brescia, Italy
,
Apr. 16–18
.
44.
Guerra-Zubiaga
,
D.
,
Kuts
,
V.
,
Mahmood
,
K.
,
Bondar
,
A.
,
Nasajpour-Esfahani
,
N.
, and
Otto
,
T.
,
2021
, “
An Approach to Develop a Digital Twin for Industry 4.0 Systems: Manufacturing Automation Case Studies
,”
Int. J. Comput. Integr. Manuf.
,
34
(
9
), pp.
933
949
.
45.
Roy
,
R. B.
,
Mishra
,
D.
,
Pal
,
S. K.
,
Chakravarty
,
T.
,
Panda
,
S.
,
Girish Chandra
,
M.
,
Pal
,
A.
,
Misra
,
P.
,
Chakravarty
,
D.
, and
Misra
,
S.
,
2020
, “
Digital Twin: Current Scenario and a Case Study on a Manufacturing Process
,”
Int. J. Adv. Manuf. Technol.
,
107
(
9–10
), pp.
3691
3714
.
46.
Luo
,
W.
,
Hu
,
T.
,
Zhang
,
C.
, and
Wei
,
Y.
,
2018
, “
Digital Twin for CNC Machine Tool: Modeling and Using Strategy
,”
J. Ambient Intell. Humaniz. Comput.
,
10
(
3
), pp.
1129
1140
.
47.
Zheng
,
Y.
,
Yang
,
S.
, and
Cheng
,
H.
,
2018
, “
An Application Framework of Digital Twin and Its Case Study
,”
J. Ambient Intell. Humaniz. Comput.
,
10
(
3
), pp.
1141
1153
.
48.
Schroeder
,
G. N.
,
Steinmetz
,
C.
,
Pereira
,
C. E.
, and
Espindola
,
D. B.
,
2016
, “
Digital Twin Data Modeling With AutomationML and a Communication Methodology for Data Exchange
,”
IFAC-PapersOnLine
,
49
(
30
), pp.
12
17
.
49.
López Seguí
,
F.
,
Navarrete Duran
,
J. M.
,
Tuldrà
,
A.
,
Sarquella
,
M.
,
Revollo
,
B.
,
Llibre
,
J. M.
,
Ara Del Rey
,
J.
, et al
,
2021
, “
Impact of Mass Workplace COVID-19 Rapid Testing on Health and Healthcare Resource Savings
,”
Int. J. Environ. Res. Public Health
,
18
(
13
), p.
7129
.
50.
Peeling
,
R. W.
,
Olliaro
,
P. L.
,
Boeras
,
D. I.
, and
Fongwen
,
N.
,
2021
, “
Scaling Up COVID-19 Rapid Antigen Tests: Promises and Challenges
,”
Lancet Infect. Dis.
,
21
(
9
), pp.
e290
e295
.
51.
Reilly
,
M.
,
2020
, “
Texas A&M System, Worlds Inc. Collaborate on COVID-19 Breathalyzer
,” Texas A&M Today, November 19, 2020, https://today.tamu.edu/2020/11/19/texas-am-system-worlds-inc-collaborate-on-covid-19-breathalyzer/?msclkid=a9487560cfdb11ecb0b259bd8a6f2304
52.
Kermali
,
M.
,
Khalsa
,
R. K.
,
Pillai
,
K.
,
Ismail
,
Z.
, and
Harky
,
A.
,
2020
, “
The Role of Biomarkers in Diagnosis of COVID—A Systematic Review
,”
Life Sci.
,
254
, p.
117788
.
53.
Patel
,
D.
,
Kher
,
V.
,
Desai
,
B.
,
Lei
,
X.
,
Cen
,
S.
,
Nanda
,
N.
,
Gholamrezanezhad
,
A.
,
Duddalwar
,
V.
,
Varghese
,
B.
, and
Oberai
,
A. A.
,
2021
, “
Machine Learning Based Predictors for COVID-19 Disease Severity
,”
Sci. Rep.
,
11
(
1
), p.
4673
.
54.
Bolton
,
A.
,
Butler
,
L.
,
Dabson
,
I.
,
Enzer
,
M.
,
Evans
,
M.
,
Fenemore
,
T.
,
Harradence
,
F.
,
Keaney
,
E.
,
Kemp
,
A.
, and
Luck
,
A.
,
2018
, “Gemini Principles,” https://www.cdbb.cam.ac.uk/system/files/documents/TheGeminiPrinciples.pdf.
55.
Lamb
,
K.
,
2019
, “Principle-Based Digital Twins: A Scoping Review,” https://www.cdbb.cam.ac.uk/news/principle-based-digital-twins-scoping-review.
56.
Pang
,
T. Y.
,
Pelaez Restrepo
,
J. D.
,
Cheng
,
C.-T.
,
Yasin
,
A.
,
Lim
,
H.
, and
Miletic
,
M.
,
2021
, “
Developing a Digital Twin and Digital Thread Framework for an ‘Industry 4.0’ Shipyard
,”
Appl. Sci.
,
11
(
3
),
1097
.
57.
Linstrom
,
P. J.
, and
Mallard
,
W. G.
,
2001
, “
The NIST Chemistry WebBook: A Chemical Data Resource on the Internet
,”
J. Chem. Eng. Data
,
46
(
5
), pp.
1059
1063
.
58.
McAdams
,
D. A.
,
Stone
,
R. B.
, and
Wood
,
K. L.
,
1999
, “
Functional Interdependence and Product Similarity Based on Customer Needs
,”
Res. Eng. Des.
,
11
(
1
), pp.
1
19
.
59.
Zhao
,
G.
, and
Huang
,
J.
,
2018
, “
Deepsim: Deep Learning Code Functional Similarity
,”
Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering
,
Lake Buena Vista, FL
,
Nov. 4–9
.
60.
Bhasin
,
D.
,
Staack
,
D.
, and
McAdams
,
D. A.
,
2021
, “
Designing Robust Systems Using Bioinspired Product Architecture
,”
International Design Engineering Technical Conferences and Computers and Information in Engineering Conference
,
Virtual, Online
,
Aug. 17–19
.