Composable digital twins on Digital Twin as a Service platform

1.1. Contribution

Our main contributions are (1) a precise definition of DT assets and DT life cycle, (2) an architecture for DT design and operations based on these definitions, and (3) an implementation of this architecture with an evaluation on the incubator ⁹ DT and firefighter DT of the O5G-N-IoT project. ¹⁰

1.2. Prior work

This work is an extension of previous work from the co-authors which has introduced the foundations of DTaaS, ¹¹ its nomenclature and life cycle phases for DTs deployed in the platform.

This manuscript introduces the definition of a re-usable DT asset, an extended and adopted architecture to support this definition, and two realistic case studies as an evaluation. The current manuscript also expands on prior work by providing details about how two case studies have gained from establishing DTs using DTaaS. From those case studies, we describe the benefits of re-usable assets, the use of different life cycle phases, the realization of the DTs and their performance evaluation. Moreover, we provide a more detailed comparison with existing platforms, and introduce two new re-usable commonly used DT services (visualization and alerts).

1.3. Structure

The rest of this paper is structured as follows. We first introduce Background and Related Work in DT platforms. Afterwards, we introduce the two different Case Studies (a DT for food fermentation and a DT for rescue mission support in firefighting), which are consequently used as running examples for illustration. Then we give the definitions and illustrations for Re-usable Digital Twin Assets, Digital Twin Definition, and Phases in Digital Twin Life Cycle, before we give an overview of the system architecture and its platform implementation. We provide feature comparison of DTaaS with other DT platforms in platform implementation. Afterwards, we illustrate the implementation of case studies on the platform and describe the performance evaluation. The paper ends with discussion and future work and concluding remarks.

2.1. DT definition and realisation

In abstract, DT is a digital representation of a physical object (PO), which influences the future behavior of the PT. However, this definition hides the variants and possible interpretations.^9,12 In this manuscript, we refer to DT as a software running remotely in conjunction with cloud services that collectively add value to an existing PT through the use of models and simulations. ¹³ Some of the existing literature proposes three subcategories of DTs: ¹⁴ (1) Digital Model (DM), in which PO and DO have no automated exchange of data, (2) Digital Shadow, where PO emits data to the DO automatically, and finally (3) DT, in which case, there exist a two-way automated data exchange between the DO and PO. Only in this case, the PO is referred to as a PT. Nevertheless, a DT should be created to accomplish certain business goals, that is, in terms of optimisation or provision of insights, ¹⁵ and therefore, the inclusion of simulation models, inference and reasoning mechanisms, and data analysis become essential. ¹⁶ The orchestration for including these components toward achieving the business goals of DTs is called the DT constellation. ¹⁷

A five-level DT architecture has been proposed previously. ¹⁸ On the lowest level (1) Smart Connection, resides the data exchange between DT and PT; (2) Data-to-information conversion, concerns conversion and aggregation of data for monitoring and to make it useful for (3) Cyber, which is the central information hub and source of analysis across multiple data sources. At level (4) Cognition, the knowledge acquired from lower levels are made available for decision-making, and finally at level (5) Configuration, is where decisions or reconfiguration from the DT is fed back to the PT, to make it self-adaptable. Thus, to create a DT, infrastructure, tools, models, and configurations must address each level.

In the DT platforms discussed next, we focus on those that promote the implementation of the (3) Cyber and higher layers, choosing to leave out platforms whose goal is to enable the Smart Connection and Data-to-information conversion layers, as platforms falling in this category have been surveyed before.^16,19

2.2. Re-usability in DT implementations

Completely new development of a DT for each PT is not necessary if the DT or its parts are re-usable. ²⁰ DTs should therefore be engineered and operated by reusing the parts previously developed for other DTs. Toward this end, we highlight two approaches, detailed next: asset reuse and code generation.

2.3. Comparison with related work

DTaaS takes a complementary approach across different DT frameworks and platforms. Multiple prior surveys^16,43,44 compare existing DT frameworks based on system architecture, interoperability, scalability, reproduction of previous results, and composition. DTaaS intends to provide the infrastructure where complementary services can be orchestrated to run and maintain DTs with a well-defined DT asset configuration. Hence, there can be coexistence of existing DT platforms and DTaaS. ⁴⁵

DTaaS provides two additional features not available in comparable DT platforms, namely, (1) providing private workspaces for authoring and verification of re-usable assets and (2) enabling sharing of DT assets to foster collaboration and re-usability.

Some of the challenges in the theory-to-practice transition of DT platforms are the support for different operating phases of the DT and the orchestration of services.^16,46 DTaaS development process addresses these challenges by following successful software engineering practices such as microservices, DevOps, and GitOps, which have found their way into the development and operation of DT platforms.^47,48 In addition, it can include extended functionalities to perform verification of the published assets with DevOps ⁴⁹ and provisioning of DT execution infrastructure by using Git workflows. ⁵⁰

In DTaaS, the user is presented with two ways to work with a DT. In the simplest form, a pre-existing pre-packaged DT is made available on the platform. For example, a DT can be realized as a set of tightly coupled services that exchange messages and stream data to/from a PT. Some of these services can execute models to provide their services. This form of DT is consistent with the DT implemented for an incubator machine.^9,51 In this case, the DT as a whole is re-usable. However, the services and the embedded models are tightly coupled preventing their reuse. The need for more enhanced re-usability motivates the second realization of DTs which is the focus of this paper. In this paper, a DT is realized as a set of re-usable assets are categorized as Data assets, Model, Function, and Tools. A key innovation in our platform is that these four categories of assets, detailed later in Re-usable Digital Twin Assets, can be declared in the platform by the user and made available to be reused by other users wishing to build DTs.

2.4. Monitoring of DTs

Monitoring of DTs and there by their linked PTs is one of the use cases for DTs. Runtime monitoring tools are suitable for creating monitors especially from safety properties defined on either DTs or PTs. The Temporal Stream-based Specification Language (TeSSLa) ⁵² has been used to integrate monitoring into the described firefighter DT. TeSSLa refers to both a specification language and an associated tool-chain developed within a community-driven open-source initiative. ⁵³

The fundamental principle of TeSSLa lies in its ability to describe transformations of data streams from inputs to outputs. It can be used within DTs to monitor (1) data from PT and (2) predictions of DT. In both cases, the deviations can be reported to either users or to decision-making software.

TeSSLa specifications are constituted by a set of input stream declarations. The specification defines derived streams created by applying specific operators to the input and previously defined streams. Some of these derived streams are designated as the specification’s output streams. TeSSLa provides libraries and supports the creation of macros. Macros are user-defined stream operations constructed from the core operations or other macros, thereby aiding the specification of complex properties. TeSSLa specifications allow for the creation of advanced output streams, including statistical data, with timestamps for events and support compiling into monitors binary, executable monitors that may be integrated into DTs.

3.1. Incubator

The incubator PT is a box containing a heater and a fan connected to a controller that can turn on and off the heater/fan. The controller is supported by temperature sensors placed inside the box. The incubator has a single requirement which is to save energy if the user forgets to close the lid, or simply misplaces it. The incubator PT is used to produce tempeh, ⁵⁴ which is a food produced by growing mold around soybeans. The original method for producing tempeh, discovered in Indonesia, consists of: (1) Hydration of soybeans: Soybeans are soaked either overnight in cool water or for a shorter period in hot water. (2) Removal of skins: The hydrated beans are rubbed together with water, either before or after cooking, to remove skins. The loosened skins float away with the water. (3) Partial cooking: The beans are partially cooked by steaming or boiling, retaining firmness. (4) Inoculation: After cooking, all liquid is drained, and the beans are inoculated with scrapings from a previous fermentation. (5) Fermentation: The inoculated beans are wrapped in banana leaves and placed in a warm location to ferment. Mold mycelia bind the beans into a compact cake, and enzymic digestion softens individual beans. (6) Further processing: Raw tempeh can be sliced and dried, roasted, cooked in soup, or deep-fried before consumption.

The incubator is designed to support the fermentation process, where the user is expected to open the box lid to inspect its contents and determine whether the fermentation has been concluded. Figure 1 shows an example tempeh production process at the beginning (left), halfway through (middle), and finished (right). As can be seen, the mold mycelia in white grows around the soybeans, consuming them and becoming a compact cake. What makes this case study deceivingly simple is the fact that at its highest growth rate the tempeh switches from being a heat sink into a heat source, ⁵⁴ effectively changing the dynamics of the system. This effect varies substantially from batch to batch because it is a biological system and depends on the number of factors such as the amount of starter mold as well as its genetics. Detecting the open lid is just a simplified use case of the DT used in this paper to illustrate the DTaaS platform.

OPEN IN VIEWER

Figure 1.

Example fermentation of tempeh using the incubator PT at the beginning (left), halfway through (middle), and finished (right).

3.2. Firefighter

The firefighting scenario, part of the O5G-N-IoT project, ¹⁰ aims to enhance decision-making and operational safety in emergency response situations. Firefighters equipped with self-contained breathing apparatuses (SCBAs), including oxygen tanks, operate in hazardous, rapidly changing environments. This scenario presents various challenges that necessitate quick, informed decisions based on accurate, real-time information.

Current firefighting practices involve firefighters periodically reporting their oxygen tank pressure to a mission commander. This method suffers from delays in information updates and the potential for human error, hindering real-time situational awareness. In contrast, a firefighter DT offers continuous, real-time monitoring and automatically updating crucial data like oxygen levels and firefighter locations. Using a firefighter DT significantly improves response strategies, adapting quickly to changes in the operation.

The primary requirements ⁵⁵ for the firefighter DT are continuous monitoring of firefighters’ oxygen levels and locations within the building, providing actionable insights to the mission commander based on real-time data, and ensuring the safety of firefighters by predicting oxygen depletion and recommending safe exit routes. The primary challenge is ensuring firefighter safety while maximizing operational efficiency, which involves continuously monitoring SCBA oxygen levels and navigating through the building using real-time data. The firefighter DT and the coupled PT can also be used to simulate emergency missions.

The firefighter DT described in this paper requires the existence of localization services and the continued validity of the building model. The building under fire likely undergoes structural deterioration and transformation. If the changes in the building significantly deviate from the building model used in the firefighter DT, then the predictions made by the DT become invalid. Another limitation could be the over-reliance on a robust localization service in a very dynamic environment (building under fire). The current version of firefighter DT is not capable of handling intermittency in localization service. Further explanation on the limitations of the firefighter DT in terms of data collection, necessary prerequisites, and scope are available in a previous publication. ⁵⁵

4.1. Incubator

Let us now investigate the assets used in the incubator case study. Figure 3 provides an overview, and we detail the different kinds of assets next.

OPEN IN VIEWER

Figure 3.

Summary of the assets used in the incubator running example.

The incubator DT therefore has the single requirement: to save energy if the user forgets to close the lid, or simply misplaces it. This requirement is implemented by the following DT services:

The above services work together to fulfill the energy saving requirement as follows:

We refrain from giving more details about how these different services coordinate, which is explored in prior work, ⁹ and focus on the assets used in the incubator DT.

The data assets are an InfluxDB time-series database and a RabbitMQ broker. The InfluxDB time-series database acts both as data store and visualization service. The RabbitMQ endpoint acts as bidirectional communication broker between PT and DT.

An example function is the calculation of the average between the two temperature sensors installed inside the box. If analogue temperature sensors were to be used, one would also need smoothing functions to eliminate the noise from the temperature measurements.

The models are:

4.2. Firefighter

The firefighter DT continuously monitors self-contained breathing apparatuses (SCBA) pressure levels and firefighter locations. If the oxygen level is deemed too low in relation to the fastest escape route, the DT alerts the individual firefighter. It also recommends the quickest and safest exit route based on the current location of the firefighter and building layout. DTaaS user in this scenario is a firefighter sub-contractor or mission controller, who deploys and adapts the system before firefighting missions take place.

Figure 4 provides an overview of re-usable DT assets used in the firefighter DT. The data used in this DT are provided by a mock PT (mock firefighter). Simulated SCBA pressure data and location data from inside of the building are sent to a MQTT broker to be ultimately used by the DT. The communication between PT and DT is based entirely on MQTT topics. Thus the DT case study outlined in this paper works for a real firefighter PT as long as the location and oxygen level data are sent to the DT. It then produces a prediction on mission time and raises an alarm if the oxygen level is deemed too low. The remaining mission time is also stored in InfluxDB—a time-series database. The InfluxDB acts as data storage. Real-time data visualization using InfluxDB and Grafana dashboards displays crucial information such as oxygen levels and remaining mission time for the usage by the mission controller.

OPEN IN VIEWER

Figure 4.

Re-usable assets included in the firefighter DT.

The 3D-building data specified as an Industry Foundation Classes (IFC)-file serve the role of model to the DT. Three tools are included in this DT.

In certain cases, the models are integrated tightly into the tools and are published as one re-usable asset. Such integrations can be considered as model-tool pairs. There are two tools with integrated human physiological models in the firefighter DT. They are:

Every asset in this list is reused for serving multiple firefighters with one DT for each firefighter. Multiple firefighters DTs can coexist at the same time on the platform, and their collected data can be shown in the same dashboard.

5.1. DT design

A DT design D t describes the possible sets of assets that a concrete DT instance can have. Here, P ( · ) denotes the power set and P > ( · ) = P ( · ) ∖ { ∅ } . The possibilities of asset combinations used in a DT are expressed below (Definition 1), where a DT design D t is a tuple of the possible data assets (denoted D ), model assets (denoted M ), function assets (denoted F ), and tool assets (denoted T ).

D t ∈ P ( D ) × P ( M ) × P ( F ) × P > ( T )

(1)

We demand that a DT design has at least one tool.

5.2. DT configuration

The interconnections between assets, parameters (configurable runtime variables) of the assets need to be specified for each DT. This information becomes a part of the DT asset configuration ( C a ). The information encoded in C a is not sufficient to truly manifest a closed-loop communication between a DT and a PT. Thus, each DT requires a complete configuration ( C dt ) that is sufficient to execute a DT in the presence of supporting services and execution environment.

The C pt denotes configuration information required by a DT to communicate with a PT. Each DT may have constraints on the kind of execution environments it is capable of using, that is tools that can only run either on a specific operating system or on a server with specific hardware capabilities. The C i denotes the infrastructure configuration required by a DT. The C e denotes configuration for integration of a DT with external software systems and services, for example third-party visual dashboards.

C dt ∈ C a × C i × C e × C pt

(2)

Among all the configurations shown in Definition 2, C a and C pt are very specific to one DT design D t . Thus, generalization of these two configurations into a configuration specification standard is a challenging task. The other two configurations— C i and C e —are more general and a configuration specification standard for these two is a manageable challenge. A sanity check is required on validity of any given C dt .

We denote an instance that stems from a design D t configured with a configuration C dt with D t C dt .

Three situations demand adjustments to C dt . First is a user-driven change in C a , C pt , C i , C e , or C dt of included DTs. In this case, a validity check is required before a transition to new a configuration can be made. Second is a requirement to perform what-if analysis. What-if analysis requires minor variations on C dt to plan and optimize future steps to be undertaken either on a PT or a DT. Actual implementation of what-if analysis can be resource intensive with the resource requirements scaling up in proportion to algorithmic bounds on the (sub)-systems being used by a DT. Third is the reuse of a DT by one or more users. Reuse at minimum requires reconfiguration of credentials to external services. In addition, users might want to change parameters in C a before using a DT.

A DT can also use external tools such as planning and optimisation. This is especially true in what-if analysis. If these tools are used exclusively within a DT, then, they can be considered as tools in the asset library. Otherwise, they are part of the infrastructure/external world.

5.3. Case studies

A mapping of C dt to the incubator and firefighter case studies is shown in Table 1. There are many models suitable for use in incubator DT, and some of these are parameterised models. The model selection and their configuration is expressed in C a . The models and tools used for firefighter are expressed in C a . Both these case studies run inside docker containers. Each of them use platform services for communication with real/mock PTs. The incubator uses RabbitMQ for PT-DT bidirectional communication. Both the case studies use InfluxDB for storing the PT data and analysis results. In addition, the firefighter case study uses MQTT for data transmission from PT to DT and Grafana for visualization.

OPEN IN VIEWER

Table 1.

DT configuration for the incubator and firefighter case studies.

Configuration for	Case Studies
	Incubator	Firefighter
Assets ( C a )	Asset selection; configuration for models, ex: four-parameter model	Asset selection
Infrastructure ( C i )	Docker	Docker
Services ( C e )	RabbitMQ, InfluxDB	MQTT, InfluxDB, Grafana
Physical Twin ( C pt )	Plant controller parameters	Not Applicable

6.1. Create and execute phases

The create phase involves asset selection and specifying DT configuration. There is no creation phase at the time of DT reuse. The execute phase involves an automated execution of a DT based on its configuration.

6.2. Analyze and evolve phases

The analyze and evolve phases are concerned with monitoring and potential reconfiguration of a DT. Monitoring, at its most basic level, requires data gathering and storage, of the interaction between the PT and its environment, and among the PT’s assets. However, even for a simple system, such as the incubator, ⁶⁶ monitoring requires that hidden quantities (that is, quantities for which we cannot obtain a sensor measurement directly) be estimated. This activity corresponds to analyze life cycle phase. Often these hidden quantities are represented by variables in various models used by the DT. The consequence is that estimates of these hidden quantities need to be stored in database, becoming then input to decision-making simulations, where all variables of the models need to be properly initialized. For more details, we refer the reader prior work. ⁵¹

Monitoring also informs the next life cycle stage of DT: the evolve stage. The evolve phase involves user/event-triggered reconfiguration of an instantiated DT. Note that the monitoring and planning steps make use of the other DT services.

6.3. Reconfiguration and consistency

The evolve phase requires reconfiguration of DTs. The aim of reconfiguration is to ensure consistency between DT and its PT, that is, the adequacy of the DT to mirror its PT, access its data, and enable the required analyses.

Reconfiguration may be triggered by different kinds of events, three of which we discussed above, they are specific to the system and, thus, reconfiguration procedures must be provided by the user. These procedures are highly application specific. The reconfiguration procedures must be able to access the current DT configuration and its assets. As the configuration is highly heterogeneous, the platform should offer a way for uniform access to it, that is, a representation mapping μ that is defined on C dt and all its assets as well as provide an interface for the user to program re-configurations in terms of the uniform access, that is, define transitions μ ( C dt l ) → μ μ ( C dt l + 1 ) . Knowledge graphs are a suitable technology to implement such mappings. The approaches to express consistency between DT and PT in terms of queries on knowledge graphs have been shown to be useful. ⁶⁷

6.4. Save and terminate phases

The save phase involves saving the state of DT to enable future recovery. If a DT is reused, there will be a temporal gap between creation and execution times of a DT. Thus, a need might arise for just-in-time (JIT) DT reconfiguration at the point of execution.

The terminate phase involves stopping the execution of the DT and releasing all the resources and connections mentioned in the DT configuration. It is also responsible for cleanup and correct shutdown of the PT (via its components), for example, for hardware-in-the-loop testing.

The create life cycle phase of DTaaS corresponds to creation of first prototype DT perhaps during the design phase. This create phase also corresponds to preparation of DT platform environment for DT execution. This DT will have to be executed to glean insights; such DT execution corresponds to execute life cycle phase via dedicated life cycle script/program. Depending on the results of execute life cycle phase, transition to other phases can happen. The save life cycle phase can be used to save DTs for reuse, that is future execution. The analyze and evolve phases together can help with DT management during the complete PT product life cycle. The terminate phase corresponds to termination of execution for a DT. This phase is specific to DT platforms and does not correspond to any PT life cycle phase.

6.5. Incubator

Figure 6 contains a mapping of different activities done for the incubator DT and the conceptual description of DT life cycle phases.

OPEN IN VIEWER

Figure 6.

Mapping of the DT life cycle phases to the incubator use case. ⁶⁶ The ODE acronym stands for ordinary differential equation.

In the create phase, state estimation and anomaly detection are combined into a single model. Data input from the physical incubator is processed, and the output is sent back to the incubator. Visualization functions are handled using InfluxDB queries.

During the execute phase, the DT runs, detecting and addressing anomalies, such as when the incubator lid is opened.

Transitioning to the save phase, the DT is paused. No new temperature measurements are recorded or predicted, but the PT continues to function independently of the DT.

In the analyze phase, users require an estimate of tempeh density. A model correlating tempeh density with temperature is created, along with a new state estimator and visualization for the new data.

In the evolve phase, new state estimation and visualization services are deployed, replacing the previous versions.

Finally, in the terminate phase, communication with the physical incubator ceases, the connection to InfluxDB is terminated, and the incubator DT process is concluded.

6.6. Firefighter

DTaaS platform’s management of firefighter DT is facilitated through a series of life cycle phases, detailed in the overview graphic in Figure 7.

OPEN IN VIEWER

Figure 7.

Mapping of the DT life cycle phases to the firefighter use case. ⁵⁵

The DT assets are configured in create phase to create firefighter DT and to prepare the execution environment. The TeSSLa is configured, links between PT and DT are created using MQTT, InfluxDB, and Grafana dashboard is setup. Execute phase activates mock PT and DT. DT now employs MQTT for data transmission, InfluxDB for storing data, Grafana for displaying real-time information. Save and analyze phases are run concurrently to execute phase. The system’s design ensures that the most recent data from mock PT is always available, with historical data primarily used for human decision-making. In analyze phase, the TeSSLa monitor continuously checks for oxygen levels and sends an alert when the level is too low. In essence, the possibilities for firefighters to escape are continuously analyzed using monitor. The results are streamed in real-time to Grafana dashboard. This concurrent activation of execution, save, and analysis phases makes DT responsive and effective. The process concludes with terminate phase in which all the executing DT assets are terminated, connections to MQTT, InfluxDB, and Grafana are closed, ensuring an orderly shutdown of DT operation.

Through these life cycle phases, DTaaS manages the complex operations involved in the firefighting scenario, ensuring efficient data handling and real-time analysis for decision-making.

7.1. Requirements

The HUBCAP project ⁶⁸ promoted the collaborative model-based engineering. One of the outcomes of the project is a collaborative sandbox platform in which the providers of the model authoring tools save their tools pre-packaged in VMs. The models are published as either public or private packages inside their workspaces. The users of tools instantiate VMs and work with their models. This experience has brought forth the need to support on-platform creation of DT assets. With the advances in virtualisation, it is now possible to support software tools inside containerised environments (Docker, Kubernetes etc.). In addition, there are cases where the generation of DT assets can be done impromptu. For instance, the safety monitoring use cases use runtime monitors like NuRV ⁶⁹ which can generate the required model(s) for JIT execution of DTs.

The large-scale collaboration among partners creating DTs requires the ability to share re-usable assets and then help users discover the availability of existing assets. For example, the co-simulation-based DTs reuse Maestro tool. In addition, there is also significant reuse of functional mockup units (FMUs). Some of these FMUs are confidential. So there is a need to facilitate both the private and common spaces for DT assets. The DIGITbrain project ²² promoted the use of structured metadata for facilitating the discoverability of DT assets. It is important to note that the consolidation here refers more toward discoverability and less toward centralisation. As long as the assets are discoverable and integrable into DTs at execution time, their storage location is irrelevant. Such a decentralized storage of DT assets respects commercial advantages of asset owners and is not an impediment to DT execution. ⁷⁰

The value of DTs is realized at execution time. This execution can either be manual or automated. It can also happen in centralized or distributed fashion. All these are possibilities DTs may take advantage of. For instance, incubator DT can be executed by users in their workspaces, or it can be executed as an automated service. It is also possible to package incubator DT into Helm Chart and execute the same on a Kubernetes cluster. Thus DT platforms need to support diverse execution environments for DTs.

The previous sections explain the advantage of re-usable DT assets and creation of DT from these assets using configuration. Thus support for configuration and reconfiguration is a vital feature on any DT platform. Some widely used DT platforms like Azure DT, Eclipse Ditto promote configurability as a means of managing DTs.

Monitoring and predictive maintenance are two prominent use cases for DTs. Monitoring of civil infrastructure such as bridges and power infrastructure such as wind turbine farms require DTs which are either 24 × 7 available or executable on-demand (CP-SENS project) ⁷¹ . For instance, a safety monitoring team might perform audit on the wind turbine farm and schedule the next audit after 12 months. If it is not desirable for the DT (as relevant to the audit scenario) to be run in the interim it is advantageous to save and re-instantiate the DT at the time of next audit. One of the key activities of a safety audit is to perform what-if scenario analysis to gauge the safety of the wind turbine farm under alternative weather conditions. The DT platforms must facilitate such a use case. One of the exemplar case studies developed on DTaaS is a fault injection based co-simulation. In this use case, faults are provided as DT configuration for a what-if scenario analysis.

Finally, users do have either direct or indirect interaction with DTs. The direct interaction needs to be facilitated via DT platform while the indirect interaction happens via services running on top of DTs. For example, the incubator DT integrates with InfluxDB on which pre-configured dashboards are loaded. The users can interact with these dashboards instead of directly interacting with incubator DT.

Summarized, the discussed user requirements are:

7.2. System components

Despite diverse requirements for different users, DTaaS presents a unified interface to the users. This unification is achieved by providing a gateway to consolidate the functionality provided by internal system components. Figure 8 shows the C4 system architecture ⁷² of DTaaS software platform. Users interact with the software via a web application. The gateway is a single point of entry for direct access to the platform services and is responsible for controlling user access to the containers. Each container contains a set of microservices. The term microservices shall be used henceforth to explain the system functionality implemented in C4 containers. The swapping of terms is to align with the architectural description of DT platforms in the existing literature. ⁷³ The microservices are complementary and composable; they fulfill core requirements of the system. There are microservices for catering to store, explore, configure, execute, and scenario analysis requirements. Dedicated user workspaces enable authoring of DT assets. The microservices are packaged and deployed on Kubernetes cluster to take advantage of virtualisation, scalability, and service discovery.

OPEN IN VIEWER

Figure 8.

The software architecture of DTaaS platform. It is based on microservices architecture.

7.3. Microservices

The microservices illustrated in Figure 8 provide the bulk of the platform functionality. The security microservice implements role-based access control (RBAC) in the platform. The accounting microservice is responsible for keeping track of the platform, DT asset, and infrastructure usage. Any licensing, usage restrictions need to be enforced by the accounting microservice. Accounting is a pre-requisite to commercialisation of the platform. Owing to significant use of external infrastructure and resources via the platform, the accounting microservice needs to interface with accounting systems of the external services.

The data microservice is a front-end to all the databases integrated into the platform. A time-series database and a graph database are essential, from multiple reported cases in the state of the art. ¹ These two databases store time-series data from PT, events on PT/DT, commands sent by DT to PT. It is possible to integrate dedicated Internet of Things (IoT) frameworks such as Eclipse Hono ³⁷ into the data microservices. The PTs uses these databases even when their respective DTs are not in the execute phase.

The visualization microservice is again a front-end to visualization software that are supported inside the platform. Any visualization software running either on external systems or on client browsers do not need to interact with this microservice. They can directly use the data provided by the data microservice.

DTaaS is a collaborative platform. Users are able to have private and shared storage space to enable controlled sharing of either DT assets or DTs. The re-usable assets microservice (Asset MS) provides search, explore, and select functions over DT assets. Thus Asset MS should aid users in performing create-read-update-delete operations on the private and shared re-usable assets. Any ready to use DTs are also made available via the Asset MS.

The DT life cycle microservice assists users during all life phases of a DT. This microservice extensively uses other microservices to provide atomic operations at the level of DTs. This microservice acts as a controller to both the Asset MS and execution manager microservice (Exec MS).

The Exec MS is responsible for on-demand provisioning of virtual compute infrastructure. To make the platform scalable, the Exec MS must be capable of integrating with private and public cloud providers. Users operate with these isolated workspaces. The Exec MS receives DT configuration from DT life cycle MS and executes DT in isolated compute environment (ex: containers, VMs etc.). The Exec MS must interpret DT configuration specified in Definition 2. The required compute environment shall be provisioned as specified in C i . The C e and C pt are connections to external software and PT respectively. These connections are to be managed as network access control policies. Finally, C a helps with gathering of required DT assets. The data assets managed by Asset MS are linked to the DT using access credentials provided in C a . The Exec MS also downloads the required model, function, and tool assets and then places them in the compute environment. If all the above steps are successful, DT becomes available for use. The DT life cycle MS takes over the management of all the DTs provisioned by Exec MS and takes them through life cycle phases as per the events triggered on the respective DTs. The Exec MS comes back into reckoning during the termination life cycle phase of a DT.

8.1. Model management

It is important for DTs and DT platforms to support a combination of models produced using different mathematical paradigms. ⁸⁵ DTs are heterogeneous of nature and thus when DTs are established for CPSs this support is paramount. In order to accommodate such integration, we make use of the FMI ⁸⁶ standard but naturally there are other alternatives as well. The DTaaS already supports such diverse modeling paradigms. This support is made possible in four ways.

First is the availability of user workspaces in which models can be created and managed. Users are at liberty to use programming languages, engineering tools, and frameworks of their choice for model creation and management. The model generation tools such as Modelica, Gmsh ⁸⁷ and Matlab can be installed and used for creation of models. Such tools can also help with the simulation of DTs in which these models are included. Thus models of different formats and representations are already supported inside the DTaaS. The exemplar case studies presented in Table 3 already have finite-element method (FEM), physics, ODE-based models published in FMUs, Modelica, and Python package representations. Other commercial partners have demonstrated proprietary System of Systems and FEM models as Matlab and Geo (by the Gmsh tool) files. These proprietary models could not be described in this paper due to commercial considerations.

Second is the JIT compilation of models. Sometimes users create models in one format (say in Modelica format) and compile them to another format (say FMUs) before the model is used inside a DT. Model compilation scripts used in the create DT life cycle phase (explained in Phases in DT Life Cycle) perform this kind of JIT compilation. The firefighter case study takes advantage of this technique to compile a Modelica representation into an FMU.

Third is the ability to use complementary and replaceable models for a single DT. The Re-usable Digital Twin Assets details different models in the incubator and the firefighter case studies. The selection of the available models for a DT is specified in the DT configuration.

Fourth is the dynamic, runtime integration of models into DTs. In this case, model integration and/or swapping happens during the evolve phase of a DT. This runtime change of DT models is controlled by DT configuration and data received by the DT at runtime. The Water tank model swap example (in Table 3) demonstrates dynamic swapping of FMUs.

While DTaaS allows the technical combination of different kind of models, it is in the responsibility of the DT creator to assure a semantically meaningful combination. Simulation granularity, especially notion of time, but also to the physical units, and so on has to be ensured when building a DT instance.

8.2. Comparison with existing platforms

Prior work^5,16 provides qualitative comparison of DT platforms based on Structured data, Language specification, Co-simulation, Domain-specific, and Geospatial data DT frameworks and platforms. In order to objectively assess DTaaS proposed in this work, we take similar criteria to compare DTaaS with some existing frameworks and platforms that are used to realize DTs in the categories of Structured data, Language specification, and Co-simulation. The other two categories, namely, Domain-specific, and Geospatial data, are not considered since they are out of the scope of DTaaS platform.

Since some of the frameworks presented in previous surveys^5,16 share similar characteristics, for example, AAS-based implementations (Eclipse BaSyX, SAP I4.0 AAS, NOVAAS, PYI40AAS, and AASX Package Explorer), IoT-based implementations (Eclipse Ditto, Azure DTs, and AWS IoT Greengrass), languages (DTDL, Eclipse Vorto, and Twined), and model-based implementations (INTO-CPS Co-simulation Framework and CPS-Twinning), a representative sample is taken with the most complete framework(s) per group based on the authors’ knowledge and experience with the tools and frameworks. Thus, the comparison considers Eclipse BaSyX and Eclipse Ditto in the Structured DT category, DTDL and Eclipse Vorto in the Language specification category, and INTO-CPS Co-simulation framework in the Co-simulation category. We compare the capabilities of DTaaS with the selected frameworks in a range of features, such as its capabilities regarding configuration files, which is relevant in frameworks like DTDL, ³⁵ Eclipse Vorto, ⁸⁸ and the AAS schema; its platform capabilities, which is relevant in frameworks like Eclipse BaSyX ⁴⁰ and Eclipse Ditto; ³⁸ its modeling and simulation capabilities, which is relevant in frameworks like the ones in the Structured DT and Co-simulation categories; and finally, its capabilities to integrate services both infrastructure- and DT optimisation-wise in comparison with the three categories mentioned above. Table 2 provides an overview of the comparison for the criteria Description of DTs and structures, Composition, DT-to-DT (DT-DT) relationships, Default bidirectional synchronization, Running simulators, Binding to infrastructure services, Binding to DT (optimisation) services, and Re-usability, inspired by the existing surveys on DT platforms/frameworks.^5,16,90

OPEN IN VIEWER

Table 2.

Summary of comparison of existing platforms. The qualitative criterion has been adopted from prior work.^5,16,45

Criterion	Structured DT		Language specification		Co-simulation	DTaaS approach
	Eclipse BaSyX (AAS)	Eclipse Ditto	DTDL	Eclipse Vorto	INTO-CPS Co-simulation framework
Description of DTs and structures	By AAS Sub-models, mainly defined by Properties and Operations	By JSON structures, defined by Attributes, Features, and Definitions	By DTDL-based JSON structures, defined by Commands, Components, Properties, Relationships, and Telemetries	By Vorto Information Models, composed of object-oriented Function Blocks, including Properties, Events, and Operations	By the Maestro Multi-model configuration file, mainly defined by FMUs, Connections, and Parameters	By the DT configuration, defined by Assets— which can contain Data, Models, Functions, Tools and Digital Twins—Infrastructure, Physical Twins, and Services
Composition	By aggregation of Sub-models	By aggregation of Features	By composing Interfaces via Components -and composition via Relationships-	By aggregation of Function Blocks	By aggregation of hierarchical FMU simulators	By aggregation of Assets
DT-DT relationships	Implicitly by semantic identifiers via References	N.A.	Explicitly by the Relationships field	Implicitly by Model References	N.A.	Only applicable for DT composition
Default bidirectional synchronization	As a DT	As a DT	As a Digital Model (requires a back-end to set up a DT via Telemetries and Commands)	As a Digital Model (requires a back-end to set up a DT via Properties, Operations, and Events)	As a Digital Model (requires RabbitMQ FMU 89 to set up a DT)	As a DT
Running simulators	No	No	No	No	Yes (via FMUs and Maestro)	Yes (multiple simulators included as re-usable tools)
Binding to infrastructure services	Provides APIs to support OPC UA, MongoDB, PostgreSQL, Docker, HTTP REST, AutomationML, and IEC 61360 product dictionaries (e.g. ECLASS)	Provides APIs to support Apache Kakfa, MongoDB, nginx, HTTP REST, AMQP, MQTT, and WebSocket	Compatible with Microsoft Azure DTs	Compatible with Eclipse Ditto and Eclipse Hono	Dependent on services wrapped as FMUs or accessible via the FMI interface	Provides a set of infrastructure services that are initialized from the Infrastructure field in the DT configuration
Binding to DT (optimisation) services	Exposes APIs that can be used by external services	Exposes APIs that can be used by external services	N.A.	N.A.	Dependent on pre-defined FMUs that include such services (not necessarily generalisable to multiple case studies)	Can be done through (1) internal or external infrastructure services and (2) a combination of Functions and Tools and the business logic in the corresponding life cycle phase
Re-usability	Of Sub-models and infrastructure	Of Features and infrastructure	Of Components and Interfaces	Of Function Blocks	Of FMUs	Of Data, Models, Functions, Tools, and infrastructure

DTaaS: Digital Twin as a Service platform; DTDL: Digital Twin Description Language; JSON: Java Script Object Notation; FMU: functional mockup units; NA: not applicable; FMI: functional mockup interface.

In comparison to the selected platforms, as detailed in Table 2, DTaaS approach performs well in terms of the bidirectional communication capabilities, DT description, re-usability, binding to infrastructure services, and more importantly, integrating running simulators. Yet, it struggles with incorporating DT-to-DT relationships, especially for a more semantically accurate way to compose DTs, and with defining a more straightforward mechanism to set up and modularly attach DT (optimisation-wise) services. In addition, DTaaS supports hosting external third-party DT frameworks, such as the DT Manager, ⁴⁵ where such an approach becomes a Tool in DTaaS context. This way, DTaaS can be used as a hub converging the realization of DTs where multiple tools, frameworks, and design paradigms co-exist.

9.1. Incubator

The incubator was originally developed independently from DTaaS platform. This DT is an example of developing DTs outside of DTaaS and deploying them on it. The DT itself is re-usable in other DTs but does not have re-usable DT assets included in it.

Figure 11 shows the implementation of the incubator DT inside DTaaS. User instantiates an already available DT in the workspace as per the configuration. The DT connects with PT via RabbitMQ service and publishes time-series data to InfluxDB. A dashboard has been setup on InfluxDB to showcase analytical results produced by the DT. Please see prior work ⁹¹ for more explanation of the analytical results.

OPEN IN VIEWER

Figure 11.

Incubator DT in DTaaS platform.

9.2. Firefighter

The firefighter DT case study implementation takes advantage of the DT concepts supported in DTaaS. The firefighter DT is put together from data, model, function, and tool assets as described in the Firefighter subsection. The DT uses MQTT, a lightweight messaging protocol, to handle data transmission. This broker acts as the central point for data exchange, ensuring soft real-time, and reliable communication among various system elements without the need for synchronization. The DT also uses data storage (InfluxDB) and visualization (Grafana) services integrated into the platform. Grafana provides a GUI for decision-making by the mission commander. A TeSSLa monitor is implemented for real-time monitoring of both the time needed to leave the building and breathing time left in the SCBA. It alerts when pre-defined thresholds are reached. The Telegraf-TeSSLa-connector ⁹² integrates TeSSLa into the system.

Figure 12 provides an overview of the sequence of events, facilitating efficient data exchange, and integration of different components. There are two sequences, each of which calculates a time. A graph is generated once in IFC2Graph with the 3D building file, in which navigation then takes place. The Graph2Path uses the position of the mock firefighter to calculate the path to the next exit. This path is used in Path2Time to approximate the time required to leave the building along a given path. The reported pressure values of the mock firefighters SCBA are used in Pressure2Time to approximate the time for which oxygen is available. These two times are monitored continuously. If there is a risk of insufficient oxygen available to leave the building, the firefighter is warned.

OPEN IN VIEWER

Figure 12.

Sequence diagram of the DT for the rescue mission scenario.

The firefighter DT has been validated through simulations and feedback from firefighter technology providers involved in the O5G-N-IoT project as well as a few firefighters. These stakeholders have provided valuable insights into practical requirements and potential improvements for the system.

The firefighter DT is run in user workspace. DTaaS supports multiple firefighters DTs for each user while still maintaining the required isolation between all the active firefighter DTs. A collective monitoring results for different firefighter DTs can also be shown as one single visualization dashboard.

9.3. Other exemplar case studies

The existing users of DTaaS have developed multiple Digital Shadows and DTs to support their case studies. They have also generously contributed non-proprietary versions of their case studies as exemplars to other users of DTaaS. ⁸¹ Seven of these exemplars are summarized in Table 3. The exemplars come from diverse applications domains including Physics, Robotics, Food industry, and Water systems. The Desktop Robotti is a DT created for an autonomous agricultural vehicle; ⁹³ the Flex-Cell Robots is a DT for flex-cell workstation. ⁹⁴ The mass spring damper with runtime monitor demonstrates the use of NuRV ⁶⁹ as a runtime verification (RV) and monitoring tool. This RV tool is integrated into the mass spring damper co-simulation DM. ⁹⁵ There is no PT for this DM. However, this exemplar demonstrates use of two tools, namely NuRV and Maestro ⁵⁸ for creating a DM. Such use of multiple models and tools ín one DT has been demonstrated again in other exemplars.

OPEN IN VIEWER

Table 3.

The implementation of seven more DT exemplar case studies inside DTaaS.

Exemplar Name	Application Domain	Physical Twin—Real/Mock/Both	Reuse of:	Life cycle phases
Desktop Robotti	Robotics	Both	Model, Tool and Service	Create, execute, terminate
Flex-Cell Robots	Robotics	Both	Models, Tool and Services	Create, prepare (configures all assets from one DT configuration), execute, save, analyze, terminate
Incubator with NuRV runtime monitor service	Food Safety	Both	Models and Services	Create, execute, analyze, terminate
Mass Spring Damper with runtime monitor	Physics	None	Models and Tool	Create, execute, analyze, terminate
Water tank fault injection	Water	Mock	Models and Tools	Create, execute, analyze, terminate
Water tank model swap	Water	Mock	Models and Tool	Create, execute, evolve (auto), analyze, save, terminate
Waste water treatment	Water	Both	Functions, Services, Tool	Create, execute, terminate

DT: digital twins.

The Water tank fault injection ⁹⁶ and model swap ⁹⁷ demonstrate the advantages of runtime fault injections and dynamic model swapping in DT.

There is a significant reuse of DT assets among the DTs created in different application domains. For example, the DT Robotti, Flex-Cell Robots, and Water tank model swap case studies use Maestro co-simulation engine as a DT tool asset. There is even reuse of models among the water tank model swap and water tank fault injection case studies. The incubator with NuRV runtime monitor service is a DT of incubator with integrated runtime monitoring service. This DT is an example of reusing one DT inside another DT. The Flex-Cell Robots is a pair of robots each of which have a unique DT which in turn are included in the Flex-Cell Robots DT. Thus it is possible to use more than one DT inside one DT and DTaaS supports such use cases as well.

Quite a few of these exemplars use the platform services integrated into DTaaS. The Desktop Robotti, Flex-Cell Robots, and incubator with NuRV monitor service use RabbitMQ service. The Flex-Cell Robots also uses MQTT service. The waste water treatment exemplar uses OPC-UA communication service. Thus the advantages of integrated platform services are evident in supporting the diverse case studies within DTaaS.

The Figure 13 illustrates the potential for re-usability of assets in DTs constructed using composition technique. The composition can be applied at either model/tool/service-level or at the DT level. There are two instances of a DT being composed in another DT. Such reuse is completely supported in DTaaS. Another advantage of this approach is to tailor the platform usability to the expertise of users. The expert users can create and manage all re-usable assets including DTs. Each DT is specified using one DT configuration stored in YAML format. The users of DT can create multiple instances of DT by having multiple configurations one for each DT instance. Thus users of DT need not concern themselves with the internal details of DT; they can just modify the DT configuration and instantiate a live DT which can then support the services built on top of it. These services can either be platform services or external services. The non-expert and decision makers can utilize the analytical results produced by the services. They do not need to even manage the DT itself; access to DT-supported services is sufficient.

OPEN IN VIEWER

Figure 13.

A dependency graph of all re-usable assets included in the case studies quoted in this paper. The dependency arrow goes from composing asset to composed asset.

10.1. Incubator

Multiple incubator DTs can be run by one user. Multiple users can run many incubators concurrently. The only limitation is on the capabilities of the underlying hardware to support the number of live incubators DTs. The incubator has a sensor that samples temperature values every 3 seconds. Thus the network delays and packet losses below 3 seconds are not observable.

10.2. Firefighter

In our performance evaluation, we conducted two experiments related to the firefighter use case to assess the system’s efficiency and robustness.

The first experiment involved comparing the performance of platform-hosted and remote MQTT servers. To compare, the system was configured to use either the integrated MQTT server or remote MQTT server and the communication times to and from a mock PT were measured with an additional MQTT subscriber. For each experiment 500 measurements were taken. The results are summarized in Table 4. The findings indicate that the integrated MQTT service significantly improves the system’s performance compared to the remote MQTT server.

OPEN IN VIEWER

Table 4.

Communication times for local and remote MQTT servers with and without network stress averaged over 500 measures each.

Performance evaluation
Configuration	Avg. time	Std. deviation
Local MQTT (no iPerf)	1047 ms	278 ms
Remote MQTT (no iPerf)	1732 ms	465 ms
Local MQTT (with iPerf)	1795 ms	269 ms

The second experiment focused on the impact of network stress on DTs running inside DTaaS. The network stack on the server hosting DTaaS has been kept busy by iPerf ⁹⁸ throughput testing tool. The TCP client and server of the throughput test are on the same server. Thus the effective network bandwidth available to the DTs becomes reduced. The results are shown in Table 4. Despite the network stress, both the DT and DTaaS continued to perform as per the requirements, demonstrating its robustness under adverse conditions. The firefighter DT does not have safety and reliability system in place yet. We are currently working on a Fault Detection Identification and Recovery (FDIR) solution for some properties of the system. We intend to monitor the 5G configuration, possibly with some mesh network between the User Equipment (mobile devices) and the data rate usage of different data streams to detect faults, try to identify their causes and recover from them.