Exploratory Integration of a Digital Twin with a Data Space: Case Study with the Asset Administration Shell

Abstract

In the context of Industry 4.0, technologies such as Digital Twin (DT) and Data Space (DS) have emerged as a revolution in the way physical assets are represented in simulation models and how their information and data are represented in cloud repositories. The aim of this work was to investigate the technologies of DTs and DSs, with a focus on their application in an industrial context, delving into the approaches and difficulties of the integration of both technologies, so that it can be explored and answered the respective challenges. To this end, literature reviews on these topics were explored by reading various sources, as well as analyzing different methodologies for implementing and integrating the two technologies. The result was a description of the main methodologies for integrating DTs with DSs, with the addition of a practical application using AASX Package Explorer, this being a platform enabling the virtual representations of industrial equipment in the molds of DT technologies, containing the association with server tools from other developers and specifications.

1. Introduction

With the advent of the fourth industrial revolution, new terms have emerged in the industry to describe the rapid evolution of the means and processes of digital transformation. According to Batty [1], in the last 10 years, expressions such as cloud computing, big data, smart cities, machine learning, artificial intelligence (AI), among others, have been coined to describe recent trends in computerization and communication, advancing automation in society. “Digital Twin” (DT) is one of the latest tools to be added to this group and, with the integration of the Data Space (DS) concept, will make it possible to advance the total digitalization of processes and companies.

Typically, a Digital Twin is generally defined as a virtual replica of physical processes, namely in products, systems, organic beings, social communities, and even cities, which are continually being updated with data and information from their real “twin”. This data can be stored and arranged on Data Spaces platforms. These platforms offer a data management approach, with a series of services for users to interact with.

Despite the rising interest in the areas of DT and DS, the integration of both technologies remains a challenge due to the high requirements of know-how and the lack of skilled personnel for the application of such technologies. This paper addresses this problem by aiming to study the technology of DTs, analyzing their characteristics and key elements for their application in business and industry. It also aims to explore, based on literature reviews, the different organizations that encourage the use of DTs, analyzing the methodologies for their implementation, as well as the analysis of organizations that promote DTs through methodologies for integrating the two technologies. Finally, the use of a tool that makes it possible to create DTs and store them in DSs will be demonstrated.

To clarify the novel aspects of this work, the main contributions of this article are as follows. First, it presents a comprehensive integration of the concepts of Digital Twin (DT) and Data Space (DS), offering a unified perspective on how these technologies complement each other within the framework of Industry 4.0. Additionally, it provides a detailed mapping and comparison of relevant standards and specifications, with a particular focus on the Asset Administration Shell (AAS) and its role as a reference model for implementing DTs in DS-compliant architectures. Furthermore, the article includes an original case study based on real industrial data, where the AASX Package Explorer is used to model a Transformer Monitoring Unit (TMU), combining multiple physical assets, namely a DGA monitor and a TRF G2 transformer, into a hierarchical digital representation. The study also explores and implements the AASX Server as a local repository simulating a Data Space, allowing the exposure of DTs via a network using open-source tools. Finally, a critical analysis is conducted on the limitations and future directions of DT and DS integration, highlighting the challenges encountered and situating the discussion within the context of evolving standards, such as the Eclipse Dataspace Components and Gaia-X initiatives.

This article is structured in such a way that, after the introduction, Section 2 gives a brief overview of the state of the art of DT and DS technology. Section 3 explores the methodologies for integrating DTs and DSs, with an analysis of various organizations and tools that promote these technologies. In Section 4, a tool for representing DTs in an industrial context will be implemented, in addition to the integration of the DS tool. Finally, this article will end with a proper discussion of the results and difficulties encountered in Section 5, and with conclusions about this integration in Section 6.

2. State of the Art of DT and DS Technology

2.1. Digital Twins

The origin of the Digital Twin comes from work by Grieves [2] with NASA engineer John Vickers, where it was shown that a DT was made up of three main parts: the physical components in a real space; the digital components in a virtual space; and the data and information connections that link both components. Here, the authors show that the circulation of data from the physical environment to the virtual representation, and the circulation of information and processes from the virtual representation to the physical environment, consists of a constant cycle between both entities.

In a subsequent article, Grieves and Vickers [3] deepen the concept of DT in the product life cycle approach by introducing new concepts such as Digital Twin Prototype (DTP), Digital Twin Instance (DTI), Digital Twin Aggregate (DTA), and Digital Twin Environment (DTE). Using Stark’s methodology [4], in the context of a product’s life cycle, a Digital Twin, when it begins to be developed, takes on the DTP phase, i.e., the design phase. A DTI is created during the project realization phase, and the accumulation of these instances gives rise to the DTA. Both the instances and the aggregate exist in the DTE, consisting of the total representation of the virtual environment, where the physical product exists, and techniques such as simulation, modeling, and evaluation can be applied. DTIs or DTAs and DTEs last well beyond the lifetime of the real product, only ending when the DT moves on to the phase where it is discontinued.

This fundamental concept of the Digital Twin, for Jones et al. [5], envisioned a system that groups physical entities with their virtual counterparts, amplifying the benefits of both environments, with the aim of benefiting the entire system. Product information is captured, stored, evaluated, and the learning is applied to the current product as well as future products. As envisioned by Grieves, this process, in essence, enables a knowledge- and data-driven approach to monitoring, managing, and improving a product throughout its lifecycle.

2.1.1. Digital Twins Features

To this day, many academic publications have been published on the emergence of the digital twin. Naturally, the definition and understanding of this new methodology have changed, with each author adding or deepening topics related to this technology. In the early years, most articles defined DT as a high-fidelity model or as a multidisciplinary simulation, without considering the real-time connection to the physical object. As academic work has deepened, many researchers, such as Liu et al. [6], have begun to value the dynamic and bidirectional mapping between objects, pointing out that, despite the different explanations, it is still difficult to define the concept of model architecture. Many conceptual and reference models of DTs have been proposed.

Schluse and Rossmann [7] proposed the new concept of “Experimentable Digital Twins” (EDTs) and described how these experimental digital twins can represent the most relevant of simulation-based processes, enabling detailed system-level simulations and the implementation of intelligent systems. In the area of integration with other technologies, Madni et al. [8] discussed the advantages of combining DTs with IoT (Internet of Things) and systems simulation to support model-based systems engineering, defining four levels of virtual representation: the pre-Digital Twin, the Digital Twin, the adaptive Digital Twin, and the intelligent Digital Twin. Bao et al. [9] define three types of DT models from the perspective of the manufacturing process on the shop floor: the Product Digital Twin, the Process Digital Twin, and the Operation Digital Twin. In his article, Ullah [10] also proposed three types of DTs: twin objects, twin processes, and twin phenomena.

Stark et al. [11] developed the “Digital Twin 8-dimension model” to plan the boundaries and type of DT. Four dimensions of this model represented the details of the behavioral capabilities of the DT, while the other four represented the environment and context of the DT area. The conceptual model of the digital twin presented by Grieves [2] contained the three main parts: the physical products, the virtual products, and their data and information connections. The DT capabilities supported three of the most robust tools: conceptualization, comparison, and collaboration. In their article, Schleich et al. [12] addressed the capabilities of the DT reference model, such as interoperability, expandability, scalability, and fidelity. They also addressed different operations in this reference model throughout the product lifecycle, such as conversion, evaluation, composition, and decomposition. Also, Tao [13], in his article, presented a five-dimensional DT model, containing physical and virtual entities, services, digital twin data, and connections.

Through an in-depth analysis, the conclusion drawn is that a digital twin is a virtual entity that reflects the behavior of a physical entity, in a way that captures the actions and processes of these entities, and subsequent reactions or consequences of these actions in the controlled environment, continuing to be updated throughout its life cycle. This conclusion is as general as it is ambiguous; however, to the authors of this work, it is the best definition that exists today of the concept of DT. The authors conclude that Digital Twin is not a specific tool, but rather an idea that can be implemented with various other advanced tools.

2.1.2. Digital Twin in the Operation of Companies and Industries

After characterizing and listing the types of digital twins and their elements, it is relevant to analyze how this new methodology actually works in a real context. As stated by Jiang et al. [14], in the areas where digital twins are used, efforts have been made to develop key technologies that can contribute to one of the three main capabilities of a DT, these being mirroring, shadowing, and threading.

“Mirroring” refers to the ability to create a virtual representation. The focus is on projecting, or “mirroring”, the physical entity onto an offline model [14]. For Rios et al. [15], this digital mirror, which may or may not be accurate, serves as a repository of all the knowledge related to the physical entity in the digital environment. In terms of manual work, many computer-aided design (CAD) tools can be used for the digital representation process.

“Shadowing” consists of the ability to load the data of what is happening in the physical environment and achieve synchronization between the physical entity and its virtual twin [14]. According to Saracco [16], this feature emphasizes that any change in the physical entity can be quickly reflected in the virtual model, i.e., with an adequate duplication rate. In this sense, shadowing is what confers the online state of the DT, through instantaneous updating when interacting with its physical twin.

“Threading” represents the ability to interconnect different levels of operation and to connect DT instances [14]. For Barricelli et al. [17], by establishing these digital connections, islands of information and data can be linked. From a microscopic point of view, subsystems are informed of the conditions of upstream and downstream processes. A machine can learn about the operating conditions of other machines by filtering DTs, so all contextual data can be transmitted from this digital link. From a macroscopic point of view, this feature allows monitoring of the entire shop floor, and even a control center to gather more information in real time.

2.1.3. Construction and Application of a Digital Replica

When a Digital Twin is to be applied, it is necessary to take into account the relevant characteristics of the physical environment in which it will be applied, and the amount of work required to build a DT. The existence of numerous physical entities, with their dimensions, dynamics, functionalities, and behaviors, and limitations such as computing power and storage capacity, creates challenges for the application of DTs. Because of these challenges, at the start of implementation, investment in the DT should go towards core functionalities that gain instant practical benefits, and towards universal, core tools that are less likely to become obsolete in an ever-changing market [14].

As a first step, Yin et al. [18] state that an analysis of practical needs and the implementation of reforms and long-term strategic plans must be carried out in order to answer the question of where and in which entity to urgently apply a DT. For major market competitors, the development and application of a virtual twin not only entails high costs but also has a profound impact on the reform of the internal structure of the value chain and the industry.

In a second phase, as Qi and Tao [19] write, the focus is on determining the system specifications and identifying the design targets for the virtual twin, in order to match the level of detail required. More specifically, this phase determines the level of modeling accuracy that is required to be consistent with other modules or DTs, the maximum tolerances in synchronization delay and measurement and monitoring errors, and also the number of heterogeneous models that are required to characterize the object of interest, and how they interact with each other.

In the third stage, the most appropriate modeling techniques are determined to meet the aforementioned needs and requirements. Melesse et al. [20] set out how the various elements of a physical entity are represented so that, with regard to geometric elements, their virtualization can be carried out through mechanical drawings (CAD), digitization in three dimensions, or measurements. Regarding physical characteristics, these are described using knowledge of first principles, system identification, and data-based modeling. The result is a virtual replica equipped with executable functionalities.

In addition, it is necessary to build a digital link, or “thread”, to connect individuals with the entire set of entities, which is related to the domains of communication networks [17]. As mentioned earlier, the purpose is to improve connectivity between separate workflows by developing new services. In their article, Deuter and Imort [21] mention that the performance of a DT is dependent on data transmission protocols and contextual information sharing solutions. In addition, storage capacity and computing power can be optimized through the varied use of information infrastructures such as cloud servers and edge boxes.

2.1.4. Digital Twins Key Technologies

Many technical challenges remain to be addressed when it comes to implementing Digital Twins. These challenges are solved by a set of technologies that have been applied in a range of scenarios and explored in various academic publications. These technologies are divided into three perspectives [6]:

• Data-related technologies: Sensors, pressure gauges, radio frequency identification (RFID) cards, cameras, scanners, and other equipment can be chosen and integrated to collect information from the physical entity to its virtual twin.
• High-fidelity modeling technologies: DT models consist of semantic data models and physical models. The first type is trained by known inputs and outputs. Physical models require a comprehensive understanding of physical properties and mutual interactions.
• Model-based simulation technologies: Simulation is an especially important aspect of DT. Simulating the physical entities’ behavior in a DT allows the virtual model to reflect the physical entities’ status and responses.

2.1.5. Benefits and Contributions of Digital Twins

The main value of the DT technique is that it provides a crucial structure and viable results for connecting and accessing the abstract information of physical entities with their digital counterparts in the virtual environment. In this way, the entities of the physical environment are enabled to learn from the virtual twins, and to interact with them and with themselves, beyond the limits of time and geographical space [14].

According to Dittrich et al. [22], from a value chain perspective, DT is a catalyst that creates additional value from various stakeholders. From the point of view of technological advancement, this methodology not only creates new possibilities for optimizing design and operations in an integrated structure but also establishes a new industrial ecosystem.

Three examples of value-added services were aligned in the literature review by Melesse et al. [20], whose review aims to identify the role and benefits of DTs in industrial production, predictive maintenance, and after-sales services:

• Factory-wide process monitoring: Process monitoring serves to detect abnormalities in industrial processes, effectively identifying and locating faults in hundreds of thousands of components, and how to report them to an operator. In addition, the impact that a local breakdown will have on the economic and performance indicators of the entire plant is also a key issue [14].
• Predicting Remaining Useful Life: Predicting remaining useful life (RUL) has been a pertinent problem in academic research when it comes to the viability of components and devices [23]. VUR provides an essential reference for maintenance and logistics planning, enabling asset safety and reducing costs caused by breakdowns.
• Asset management: Asset management is concerned with maximizing the capacity rate of physical components over a predefined time interval, considering dynamic demands, resource limitations, and possible failures [24].

2.2. Data Spaces

A Database Management System (DBMS) is a general-purpose repository for storing and querying structured data. A DBMS offers a set of interrelated services that allow developers to focus on the specific challenges of their applications rather than recurring challenges related to managing and accessing large amounts of data in a consistent and efficient manner. Unfortunately, in today’s data management scenarios, it is rare for all information to be stored in a conventional DBMS. As a result, developers often work with a set of disaggregated data sources, thus facing challenges in managing data across these various heterogeneous collections [25].

To meet these challenges, Franklin et al. [25] introduce dataspaces (DSs) as a new abstraction for data management through the development of DataSpace Support Platforms (DSSPs). Dataspaces are not a data integration approach, but rather a data coexistence approach. The goal of a DSSP is to provide baseline functionality to all information sources, regardless of their level of integration. In this sense, the properties that distinguish dataspaces from DBMSs can be summarized as follows:

• The possibility of dealing with data and applications in a wide variety of formats, accessible by different systems and interfaces, in order to support all the data in the DS;
• Despite offering integrated means of searching, selecting, updating, and administering the DS, the same data can often be accessed and modified via a native interface of the system hosting the data, so the system is in full control of the data;
• DS queries can offer different levels of service, and in some cases return appropriate and approximate answers;
• The offer of tools that enable more selective data integration, as required by the user.

The European Union (EU) funded dataspace project, Open DEI (Digitizing European Industry), defines this type of platform as a federated data ecosystem within certain application domains, based on shared policies and rules [26]. Access and usage rights on this platform are granted to those who have the right to publish this data. In the Open DEI, the structure consists of building blocks, which are divided into technical and administration blocks. These blocks enable interoperability, trust, value creation, and data administration within the dataspace.

Integration of Digital Twins in Data Spaces

The standardization of Digital Twins (DTs) plays a decisive role in Industry 4.0, enabling the seamless integration of different components within a factory or industrial plant. By providing a standardized information model, DTs allow machines and software systems to communicate with each other using a common language or model, regardless of manufacturer or technology [27].

Developed by the German government through the Plattform Industrie 4.0 initiative, the Asset Administration Shell (AAS) was introduced as a dataspace solution for standardized DTs [28]. However, the core specification of the AAS information model does not yet address the issue of data sharing according to data sovereignty policies [27].

The International Data Spaces Association (IDSA) defines the International Data Spaces Reference Architecture Model (IDS-RAM) as the reference architecture for DSs. It describes the principles of data sharing, including usage policies, and provides an information model for entity descriptions as well as standardized API (Application Programming Interface) sharing. Additionally, the IDS community provides several open-source reference implementations of the IDS-RAM [29].

While data sharing can be achieved using only DTs—such as communication between the AAS and the AAS API—most DT specifications do not handle sovereign data sharing to the same extent as IDS. Therefore, since DSs and DTs are two fundamentally different concepts, they can complement each other to enable interoperability, security, and standardized data exchange within industrial ecosystems [27].

DTs and DSs can thus be deeply interconnected, requiring a systems-based approach to bridge both concepts. Assuming that the concept of DTs originated in product lifecycle management, and that the data collected for DTs can be used in later stages of that lifecycle (such as maintenance and recycling), one can conclude that platforms in Industry 4.0 need DTs just as much as they need the capabilities of DSs [30].

3. Methodologies for Integrating a DT with a DS

In recent years, Digital Twins technology has become increasingly important in various domains and applications. Although this concept was coined by Michael Grieves at the beginning of the century, the basic concepts of DT were developed in the 1990s, where dynamic models of real components and processes were used to make diagnoses of technical systems. The models used were connected to sensors present in the physical systems in order to monitor the real world and simulate future behavior. If discrepancies were detected in the real environment and the simulated behavior, a diagnosis was initiated on the technical system based on these discrepancies [31].

Over time, the concept of DT has been discussed by various groups of researchers and companies, but the recent literature reviews analyzed in the previous chapter show that these groups do not agree on a single exact definition for this concept. Furthermore, with the emergence of the Internet-of-Things and, more recently, Data Spaces, DTs have begun to serve purposes other than simulation, becoming essential conceptual and architectural elements in various environments to meet the numerous demands of use cases [30]. These developments maintain the slight differences in the definition of DTs between the main organizations that promote the dissemination and establishment of standards for this technology.

3.1. Organizations That Promote DT

The first of these organizations is the Industry IoT Consortium (IIC) which, in its whitepaper [32], defines a DT as a digital and formal representation of an asset, process or system, which captures the attributes and behaviors of that entity, and can be used for communication, storage, interpretation or processing, in a given context. Another organization is the Digital Twin Consortium (DTC), which, in its glossary [33], defines a DT as a virtual representation of real-world entities and processes, synchronized with a certain frequency and fidelity, which uses historical or real-time data to represent the past, present, and simulate predictable future states. Beyond this definition, this consortium provides a broader exposition of the subject by exploring the services, applications, and platforms of a DT. At the beginning of 2024, the incorporation of the IIC into the DTC was announced, with the aim of harnessing the best knowledge of both, expanding their collaboration with industry, academia, and governments. From this collaboration, it will be possible to increase the adoption of DTs and digital transformation [34].

The Industrial Digital Twin Association (IDTA) gives the most general definition of this technology, where in its glossary [35], it describes a DT as a digital representation, which is sufficient to meet the requirements of a set of use cases. The IDTA also states that the entity represented in the virtual environment generally consists of an asset. This association, founded in 2021 from the Plattform Industrie 4.0 project, was developed by the association of the largest European network of the mechanical engineering industry (VDMA), the German association of electrical and electronic producers (ZVEI), the digital association of Germany (Bitkom), and 20 other companies, with the support of the German ministries of economic affairs and climate action, and education and research, with the main objective of promoting the Digital Twin.

IDTA’s principle is that a DT connects physical industrial assets with a digital world, providing a standard for the development of DTs that connect these assets with their virtual replicas. These assets consist of products, processes, or resources, but for the successful implementation and dissemination of this technology of the fourth industrial revolution, there needs to be a general understanding among all the stakeholders in the industry sectors. In this way, this association acts as a central point between all stakeholders, providing the necessary specifications for its most important tool, the Asset Administration Shell (AAS).

The AAS was one of the main results of the work carried out as part of the Plattform Industrie 4.0 project. From the first IDTA working group, with the theme of “Reference Architectures, Standards and Norms”, an AAS is defined as a standardized digital representation of an asset, and a pillar of interoperability between the applications that manage manufacturing systems. As can be seen in Figure 1, this representation identifies the management shell and the assets it represents, stores digital models of various aspects (submodels), and describes the technical functionalities exposed by the management shell and the respective assets [28]. In this way, the main function of an AAS is to implement DTs in the context of Industry 4.0.

It can, therefore, be concluded that IDTA’s main and primary objective is to consolidate and promote the concepts and models that result from the Industrie 4.0 Plattform, especially the AAS, its metamodel, and the application programming interface (API) specifications. For the association, the term DT is understood as a synonym for AAS, in the sense that an AAS is a Digital Twin for industrial applications, although in this case, a DT instance is itself interoperable with other DT instances if they follow the same AAS specifications. However, IDTA does not take a systemic approach to the need for a platform to support interactions between AAS/DT instances, especially in an operational phase. Some requirements for platforms, especially security ones, are provided. However, IDTA does not currently specify the characteristics and services of such a platform. Apart from the contributions of AAS instances in repositories, IDTA is still active within its structures in the areas of modeling at the API and AAS level [30].

Comparison of Standards and Specifications for DTs

In addition to the AAS digital representation standard, there are several competing standards and specifications, which can be mapped and compared with each other [36]. The most prominent of these are

• The Digital Twins Definition Language (DTDL) was developed by Microsoft for its Azure platform. The DTDL specification is available on GitHub [37] and defines the structure and design of the model components, as well as the identification and semantics of the DT data in DTDL format.
• Next Generation Services Interface-Linked Data (NGSI-LD) is a standard that was published by the Context Information Management (CIM) of the European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG). It is based on NGSI 9 and 10 from the Open Mobile Alliance (OMA) and NGSIv2 from FIWARE [38].
• Eclipse Vorto is a specification that has been developed by the Eclipse Foundation. This specification addresses the problem of different IoT devices sending and receiving different types of data. Vorto models are then intended to provide a standardized API for IoT devices in order to facilitate the integration of software solutions [39].
• Web of Things (WoT) Thing Description (TD) was developed by the WoT Working Group of the World Wide Web Consortium (W3C). This model is a logical description of the interface and possible interactions with the properties, actions, and events of the “thing” [40].

3.2. Organizations Promoting Data Spaces

Nowadays, with a strong increase in interest in digitalization, data represents an important resource that must be protected. For this reason, the European Data Strategy (EDS) has evolved considerably with the aim of offering a single data market in the European area, subject to European legal and security guidelines, and recognizing that it is important to maintain the competitiveness of European countries while guaranteeing the highest level of data sovereignty for their producers and consumers [41].

The increased use of data opens up completely new perspectives, both for individuals and for global economic development. In the future, these developments will enable the emergence of better decision-making capabilities for many use cases. According to the European Data Strategy [42], objectives have been set such as the transfer of data within the EU and between its industries, respect for the values and rights of the Union, in particular the General Data Protection Regulation, and the use of data in a fair, practical, and clear manner.

To achieve these goals, DSs must enable access to and privacy-compliant use of data by creating suitable ecosystems. An ecosystem infrastructure should facilitate the integration of data from multiple sources, and should support data federation, data analytics, and machine learning processes, all of which comply with data protection requirements. The partners who provide the data should be given access to larger volumes of data and, if necessary, be able to take advantage of the analysis results of others. This idea allows new data-based business models to emerge [30].

3.2.1. Open DEI Project

Funded by the European Union, the Open DEI project published a position paper defining the design principles for Data Spaces and their building blocks [43]. According to this project, a DS is made up of blocks that enable interoperability, trust, value creation, and administration. These blocks are divided into two groups: the technical blocks and the administration blocks. The first group consists of nine building blocks, and a DS can range from a minimal DS [44], which only carries out basic operations such as secure data transfer, to a vast network in Data Spaces, housing market services, and additional platform services.

3.2.2. International Data Space

IDS (International Data Spaces) aims to create international standards for DSs, as well as encourage technologies and business models that foster the data economy [45]. IDSA is a non-profit organization with the intention of promoting IDS architecture for different domains, such as mobility, value chains, and health, among others. One of the main pillars of IDSA is data sovereignty, through the possibility for people, organizations, and governments to have control over their data, including collection, storage, sharing, and use processes. This requires the creation of rules for the sharing and use of data through contracts and policies. IDSA offers guidelines and a framework to ensure data sovereignty in Data Spaces. Standardization efforts are carried out by IDSA members, who develop these DSs. Fundamental to these efforts is the IDS-Reference Architecture Model (IDS-RAM), the IDSA rulebook, and the DS protocol.

3.2.3. Gaia-X

The Gaia-X ecosystem is made up of two ecosystems: an infrastructure ecosystem and a data ecosystem. These are connected by federation services, while the entire ecosystem is supported by policies and standards architecture. Both share the idea of a sharing economy, where an entity can provide its data and services, while applying rules and maintaining sovereignty over them. These two ecosystems cannot be seen separately. Within the infrastructure ecosystem, services are made available, connected, and consumed, while in the second ecosystem, data is used as the main business asset. Similarly to the IDS, participants are classified by the roles of supplier and consumer. However, depending on the activity, an entity can have both roles at the same time. To realize this structure, the initiative intends to take advantage of existing standards, as well as various technologies and concepts. By combining existing solutions, Gaia-X acts as an orchestrator and integrator. It is neither a hyperscaler nor does it consist of a central data store [46].

3.2.4. FIWARE

FIWARE was created with the main objective of creating an open and sustainable ecosystem around public software platform standards, with a focus on data sovereignty and implementation-oriented, facilitating the development of intelligent solutions and supporting organizations in their transition to intelligent organizations. From a technical perspective, FIWARE brings a fine-tuned structure of open source software components that can be integrated and combined with other third-party platform components to build platforms that facilitate the development of smart solutions and organizations in multiple application domains, such as the agri-food, energy, industrial, water, and smart cities sectors, among others [47]. As FIWARE is a European project, it is also governed by the three principles of DS architecture defined by the Open DEI, which are data interoperability, data sovereignty, trust, and the creation of value from data.

3.3. Data Spaces Based on Digital Twins

As has been explored, several organizations have tackled the challenge of virtual representation of a real entity by developing specifications or standards for it, while others have tackled the development of a DS. The concepts of Data Spaces defined by IDS and Gaia-X support interoperability and secure data exchange through integration with existing identity and trust management services [48]. In the Gaia-X ecosystem, the Eclipse Data Space Connector adopts both IDS specifications and Gaia-X-relevant protocols. Likewise, various implementations of the IDS connector are available and documented through the IDSA repository [49]. Naturally, some of these specifications or standards are more compatible with certain DS architectures. For this reason, the integration of the AAS standard with IDS elements is chosen, which is studied in the following chapters.

Based on the schema of the building blocks of a DS, drawn up by the Open DEI project, Volz et al. [27] state that DTs are part of the group of data interoperability blocks, more specifically, the block of data models and formats. DTs enable the interoperable exchange of data between participants by defining a subset of suitable data formats and integrating data models. In addition, DTs must be taken into account when describing the metadata and catalogs of a DS, since its participants could have difficulty locating the correct DT. In this way, the block of metadata and discovery services enables participants to find the right data sources (DTs). DTs can also be reflected in the market and publishing services block, making it possible to transform, for example, manufacturing processes into a service where machine functionalities and features are made available to all participants in a DS.

As mentioned earlier, within the framework of Plattform Industrie 4.0, the use of AAS has been suggested as a standard for realizing DTs. If an AAS is used as a data source, it provides a uniform API as well as a set of well-defined communication protocols and can itself synchronize various other data sources into a logical unit such as a digital product passport (DPP). In this case, the DT of a product can provide a DPP. However, the two concepts are not synonymous, as a DT can offer additional functionalities such as simulation or data-based services [27].

DTs and IDS connectors form the first pair of elements that enable the inter-connection of these technologies, and can be employed within an organization or in a cloud infrastructure, and used independently. However, DTs generally represent a physical asset of the organization, while IDS connectors are the portals to DSs across organizational boundaries [27]. In this way, Figure 2 simplifies the schematic of this interconnection.

In most cases, IDS connectors initiate data transfers with other connectors via Hyper Text Transfer Protocol Secure (HTTPS) [50]. However, there are dataspace-specific protocols available or under development, such as the IDS Communication Protocol 2 (IDSCP2) [51] and the Dataspace Protocol [52]. In the case of HTTPS, both metadata and content are exchanged between the connectors. The AAS specification selects two communication protocols—HTTPS and OPC UA (Open Platform Communications–Unified Architecture)—for its API [36], which can be leveraged by connectors for data integration. When HTTPS endpoints in the AAS are described in the metadata of the connectors, data is requested from the AAS via HTTPS (AAS API) and sent to the other participant via HTTPS (IDS API). If the data source is not an HTTPS endpoint, such as an OPC UA machine server or an AAS without HTTPS support, the connector must support this communication protocol through its data services. When using the AAS as a data source in IDS connectors, integration into a DS is simplified by focusing on the subset of protocols specified by the AAS. In this case, the AAS is responsible for synchronizing itself with the physical asset, physical process, or human [27].

In a DS, the connector provides a catalog of available data sources to other connectors. These data sources may include databases, ERP (Enterprise Resource Planning) systems, or even files for web services. In all cases, integrating these sources into the connectors is a technical challenge that generally requires manual effort. On the other hand, DTs can be implemented at the edge to synchronize a physical and virtual entity within a company. However, they can also be deployed in a centralized cloud infrastructure to collect public data sources and process data [27].

It is important to highlight that the primary focus of DTs is not on data sovereignty sharing. As a result, the specification of security in the AAS is still not fully defined. A connection has, therefore, been established between Plattform Industrie 4.0 and the IDSA to address this gap. In this context, the IDSA Industrial Community was created to coordinate efforts and combine the expertise of both entities [45].

The second pair of elements that connect DTs and DSs are the DT Registry and the IDS Broker. In both domains, there are software components that make it possible to discover and publish data sources. In the case of IDS, a Broker provides a list of IDS connectors with available data offerings [29]. However, this Broker only understands the IDS information model and does not resolve DT requests, such as the queries found in the AAS registry API. It is vital that participants register their connector with a broker, as participants in a DS may not know each other before the data is exchanged. Likewise, it is important to register the DT in a registry, so that other DTs can find it and interact with it [27].

In the AAS specification, the Registry component is used to keep track of all registered AAS instances [28]. Similarly to the IDS Broker, the AAS Registry provides a list of available AASs and their submodels. The data transfer API building block also includes registration mechanisms in its specification. It is also vital that DS participants can search for specific DT offerings, such as a DT that describes a particular aspect of an asset. The need for a combination of Registry and Broker in Industry 4.0 use cases depends on the requirements, more specifically, whether the AAS client is responsible for identifying the appropriate data providers [27].

The last interconnection between the elements of the AAS and the IDS has to do with the semantics of the DT and the vocabulary provider of the IDS. In DTs, semantics refers to the way information is structured, communicated, and understood within a DT and the application domain. It involves defining a standardized way of representing and communicating information related to the asset. This standardization is key to ensuring interoperability between different devices, systems, and services [27].

In the context of the AAS, there are several concepts for establishing syntactic and semantic interoperability. Semantic IDs are used to link a semantic specification to a submodel or a submodel element. This specification gives meaning to the element, such as an ontology or a formal specification that describes the element in detail [28]. In an AAS, it is possible to define custom dictionaries, provided that they contain the semantic definitions of the submodel elements. These semantic definitions are called concept descriptions and are mostly used as attributes and data types within the AAS [53].

While the AAS metamodel creates a rough syntactic structure, the aspects of an asset can be divided among different submodels and elements as deemed appropriate by the organization. The structures of the submodels define the aspects of the asset that will be represented in a specific structure with specific elements. These structures, created and standardized by the working groups of Plattform Industrie 4.0, enable better interoperability between different systems and devices if companies implement them [54].

In DSs, semantics can also be described in the metadata of available data resources. To determine the semantic description, the IDS vocabulary provider acts as a specialized connector that can be queried for the required semantic descriptions. This provider can host various vocabularies and ontologies used in data annotations and descriptions. Once semantic IDs are used to reference ontologies, the ontology should be made available to all participants in order to clarify semantic meanings. This is achieved by referencing a publicly accessible URI (Universal Resource Identifier) or one hosted by a vocabulary provider [55].

4. Practical Application of Integrating an AAS with IDS

After studying the methodologies for applying Digital Twins with Data Spaces, these technologies will be implemented in practice in the reality of a company focused on industrial equipment. To this end, among the various tool options analyzed above, the most suitable one will be chosen to build the DT of this company’s assets, followed by the development of a strategy for the integration of a DS.

4.1. DT Construction

The tool chosen to create the DTs was AAS. This standard is implemented using a platform called AASX Package Explorer (AASX PE). The reason for choosing this platform was that it is almost generally used by the scientific and industrial community for the application of DTs [56], so that, as well as being developed by Platform Industrie 4.0, it is continuously supported and updated by the IDTA community [57].

It should also be noted that in April 2024, as a result of this project, AASX was integrated into a project of the Eclipse Foundation organization, and is now part of the Eclipse AASX Package Explorer and Server. This project aims to accelerate the development of DT technologies through the AAS standard, encouraging their adoption in the market. Its developers claim that these objectives can be achieved due to the ease of use and application of these technologies in existing solutions and processes with a low investment in IT infrastructure [56].

4.1.1. Data Made Available to the Project

The asset of greatest interest for the application of this technology was a TMU (Transformer Monitoring Unit). This equipment is an advanced solution for aggregating and correlating information from different sources. With a wide variety of physical inputs, as well as numerous communication protocols between client and supplier, a TMU can collect information from various sensors. This unit is made up of two different pieces of equipment that will be used for this study: the transformer itself (TRF G2) and the DGA (Dissolved Gas Analysis) monitor.

The data, which was provided from an Excel file, is part of a set of historical data from a customer’s TMU, with the values of the different variables depending on the date and time they were collected. After obtaining the data, we proceeded to analyze each of the variables. At this stage, redundant columns and columns of data that had no value for the proposed challenge were eliminated. At the end of this treatment, a table was obtained with seven columns (Date of Collection; Equipment; Variable; Value; Unit; Cause; Typology; Mode of Acquisition) and more than 250,000 records, representing a period of nine months of historical data.

By analyzing this data, some conclusions can be drawn: This data set consists of 30 variables, of which 13 correspond exclusively to the DGA monitor, and the other 17 correspond exclusively to the TRF G2. Within the variables of the DGA monitor, the concentrations of the ten gases resulting from the TMU operations are quantified, and three rates of these gaseous compounds are also calculated. The TRF G2 variables quantify the power, humidity, ambient temperature, seven temperatures at different points in the transformer, its capacity, the level of polymerization of the paper, the consumption and inactivity of the two pumps, and also the VUR of the equipment. Although this set of data corresponds to the recording of nine months, not all the variables show values in every month or with acceptable variability. This was often due to periods when the TMU or some of its sensors were out of service.

4.1.2. Structure of the Project AAS

According to the data provided, and based on the application of AAS PE, each AAS was built in such a way as to obtain the most reliable representation possible of the assets under study. This representation is shown in Figure 3, depicting the composition of the equipment that will be implemented in the application. As you can see from the asset hierarchy, the TMU represents the parent component, with the other two pieces of equipment being the sub-components.

AAS for the DGA Monitor

Figure 4 shows an overview of the AAS file that was created for the DGA monitor. This file consists of a single asset, a set of submodels, a set of dozens of concept descriptions derived from the submodels, and a supplementary file. This AAS, called “DGAmonitor”, is entirely made up of submodels provided by the application itself and by the IDTA repository because, as mentioned earlier, there is no need to develop new submodels from scratch when there are already standards for them that are suitable for the nature of the project.

This AAS is, therefore, made up of five sub-models. The “Nameplate” contains a set of elements representing the equipment’s identification data (name, serial number, batch number, year of construction, etc.). The “HandoverDocumentation” serves as an internal repository for the equipment’s documentation, making various files available to users of this AAS. “TimeSeries” is the submodel that will describe, in an interoperable way, the data sets of an asset’s operational period, integrating the data from the AAS itself with external data sources. The “TechnicalData” is intended to store the technical data that describes the asset in the context of operability, i.e., in the case of the DGA monitor, the appropriate levels of the gases are exposed. The last sub-model, “SimulationModels”, enables the AAS to make projections and forecasts through a series of simulation models, using the data and information that is made available.

AAS for Transformer G2

This file consists of a single asset, a set of submodels, a set of dozens of concept descriptions derived from the submodels, and a supplementary file. This AAS, in terms of elements, is practically the same as the previous one, since the typology of the values and characteristics of this equipment is very similar to those of the DGA monitor.

Both are the same because they are both industrial assets, with each one having a technical file of its production information and files with technical documentation, and also because each one stores operating data, which is recorded over time, and from which projections and forecasts can be made using simulation models. In this way, with the exception of the elements and properties of the submodels, the TRF G2 AAS will be identical to the previous AAS.

AAS for the TMU System

This file consists of a single asset, a set of submodels, a set of dozens of concept descriptions derived from the submodels, and a supplementary file. This AAS comprises three of the submodels mentioned above, which are used to identify the system (“Nameplate”), as a repository for documents and files on the operation of the equipment (“HandoverDocumentation”), and as a store for the system’s technical data (“TechnicalData”). In addition to these three submodels, in the construction of this AAS, a fourth was added from AASX PE’s own plugins, called “ElectricAndFluidPlan”, which has the capacity to represent a BOM-type schema of the hierarchy between various entities.

Figure 5 shows the BOM structure built in AASX PE in greater detail. From this last submodel, by referencing the first two AASs, relationships are created between them and the system’s AAS, enabling hierarchical representation when the “Bill of Material-Graph display” element is selected within the submodel. This representation in the application is in line with the scheme shown in Figure 3.

Having completed the construction of the DTs/AASs, it is important to note that, in general, all the sub-models have a specification document detailing the characteristics of their nature and the ways in which they can be applied. It should also be noted that, as a result of the AASs represented in Figure 6, interfaces are built for the KPIs of the equipment analyzed.

4.2. Integration of DT with DS

As mentioned earlier, the Eclipse Foundation recently integrated the two components of AASX into one project, the DT construction application (AASX PE) and the DS platform application (AASX Server). However, what is the role of this organization, and what interest do they have in AASX?

This foundation began as a project, the Eclipse Project, created by IBM in November 2001 and supported by a consortium of software vendors. Later, in January 2004, the Eclipse Foundation, a non-profit organization, was created to act as the administrator of the entire Eclipse community, enabling the establishment of a vendor-neutral, open, and transparent community. Today, this foundation provides a global market of individuals and organizations with an environment conducive to the development of open source software. With more than 400 projects developed, including runtimes, tools, specifications, and architectures, hundreds of its members contribute to its support in areas such as automation, cloud, IoT, edge, AI, systems engineering, and many others [58].

In addition to the Eclipse AASX Package Explorer and Server, which facilitates the integration of DTs with DSs and is also part of its large repertoire of projects, the Eclipse Foundation is developing a project for DSs called Eclipse Dataspace Components (EDCs). These components represent a comprehensive conceptual, architectural, and code structure, providing a set of functional and non-functional features for the use and customization of DS implementations, taking advantage of the APIs defined by the structure, thus guaranteeing interoperability [59]. An important aspect to mention is that EDCs are developed based on the specifications of the Gaia-X Trust Framework and the IDSA Dataspace Protocol, ensuring that these DS structures conform to documentation that is valued by the majority of the scientific and industrial community.

The EDC structure consists of a set of components that correspond to the mandatory capabilities for implementing a DS. These function through the existence of a Connector, Federation Catalog, Identity Center, Registration Service, and Data Panel. All these components were mentioned above, with the same or similar nomenclatures, during the chapter on exploring the methodologies for integrating the two technologies. Together with all the information that has been presented so far on the subject of DSs, we have a vast array of initiatives, projects, and tools. In order to clarify the current state of this area, Figure 7 shows how the most relevant entities mentioned above relate to each other.

According to the figure above, it is clear that all these elements mentioned so far are, in a way, interconnected, contributing to the development of an ecosystem that connects customers and suppliers in the various industrial and business sectors. For example, as shown in the figure, two Data Spaces that take advantage of the EDC structure are Catena-X, in the automotive industry, and Eona-X, which focuses on mobility, transport, and tourism. Now, with the AASX PE and Server project, the Eclipse Foundation aims to enable the development of new DSs.

It is important to note that both projects (AASX PE and Server and EDC) are in an incubation phase, i.e., for the Eclipse Foundation, they are still under development, and with scarce or incomplete materials available, both on the website and on GitHub for the new versions of each project. Therefore, with regard to AASX Server, as the process of practical implementation in this new phase (integration under the tutelage of the Eclipse Foundation) was not fully available during the course of this project, the following section will explore and simulate the implementation of this application in a previous version.

AASX Server is a complementary application to AASX PE. This application provides a local service for hosting and supporting AAS file packages, making them accessible to all clients that connect to the server. This component has two variations: a Core version that contains only the server with a CLI (Command Line Interface) that, using the NET Core tool, exposes endpoints for REST (Representational State Transfer), OPC UA and MQTT protocols; and the Blazor version that contains a GUI (Graphical User Interface) that offers the same functionalities and, in addition, uses the Blazor architecture to provide a website GUI for exploring AASX packages [60]. The main functionality of this tool is the delivery of a repository of AAS packages. In the Core version, this process is carried out from the Command Prompt on the computer where AASX is being used.

Although the Core version does not offer such an accessible way of consulting AAS data and information for a mere user, there are two alternative AASX interfaces for displaying AAS information in an accessible way. These are the AASX Blazor interface and the AASX PE interface. The Blazor interface consists of a website that visualizes AAS data through a simple configuration. This interface can be opened by entering the address “http://*:5001” in the browser, where the * represents the IP address of the host, in this case, a localhost.

Figure 8 shows a Blazor interface of an example demonstration of the AASX Server itself, with a set of AASs. From this figure, you can see that, in an interface like this, the left-hand side shows all the assets that have been uploaded to the server. On this side, it is possible to expand each of them, analyzing their components, such as submodels and elements, as well as their values and information. This interface, via a URL (Uniform Resource Locator) above the “QRCODE”, makes it possible to install the asset’s .aasx package on the computer where the interface is being used. It should be noted that the Blazor interface also shows changes in asset data in real time.

In addition to creating AASs, AASX PE can also be used to connect to AAS servers, allowing you to view and edit the AASs uploaded to the server. After opening the application, a connection to the Blazor server can be established from the “File” tab by going to “AASX File Repository” and selecting “Connect HTTP/REST repository” to enter the server address.

These two formats (Blazor and AASX PE) for viewing an AAS repository have some advantages when used simultaneously. Although it is possible to work directly on the assets via the AASX PE application, with the Blazor server, the AASs can be accessed by everyone with a web browser. In addition, the server displays changes in asset values in real time, whereas in the application, the AASs have to be manually reloaded.

5. Results and Discussion

This project had two fundamental components for analyzing the topics covered. As part of the exploration of the state of the art, the methodologies for integrating DTs with DSs were studied in great depth. The result of this research process is a complete analysis of the main topics studied by the scientific community in the field of these two technologies.

The second stage of this work involves practical implementation. In this phase, three DTs were built using the AASX PE application, creating an AAS for each device. Another significant result of the DT construction process was the exposure of existing mechanisms, such as the AASX Server tools, for integrating the AASs created in a localhost repository, and an analysis of how these tools would work in a situation similar to the one explored.

During the practical application of the tools selected to represent the DTs and DSs, it was possible to draw some conclusions from the work being performed. Throughout the process of implementing these technologies, a comparison was made between the theoretical part studied and the challenges that arose during the course of the activities. When building the DTs, it was decided to choose submodels from the community, rather than developing their own, and when integrating them with the DSs, some challenges were encountered in the process of connecting the servers with the data and information from the AASs.

In the end, the overall contribution of this work was the comparison of these two components, i.e., the confrontation between the two realities, with one being the studies and articles carried out in the areas of DTs and DSs, and the other being the realization of a practical implementation of these technologies. Bearing in mind that these topics are increasingly relevant in the academic and industrial world, this work represents a step towards enlightening an increasingly interested public about the characteristics, methodologies, and advantages of applying DTs in the industrial environment, and how integration with DSs can enrich this potential.

5.1. Challenges Found in the Construction of DTs

At the beginning of the Digital Twin (DT) development process, when the Asset Administration Shell (AAS) model was chosen to represent a company’s assets, it was assumed from the outset that it would not be possible to create a DT with real-time access to the data from the equipment under study. This constraint did not pose any issues because, as discussed in previous chapters, a virtual representation of an asset can be implemented throughout its entire life cycle, relying either on a continuous data source or on a set of historical data. With this in mind, a data set containing different parameters from the equipment was made available for processing.

During the initial steps of DT construction, the key characteristics deemed desirable to analyze and represent through the AAS were first evaluated. This step was essential, as the type of information to be analyzed would influence the type of components (submodels and their elements) to be integrated into the AAS. Once the most relevant data parameters were identified, the submodel developer communities were consulted to obtain the most suitable packages for asset representation. Developing custom submodels proved to be time-consuming and unproductive, since it was very likely that the required components already existed. It quickly became clear that these communities play a vital role by offering, on open-source platforms, a wide variety and versatility of components and elements for DT representation.

A highly important aspect in the application of DTs is how data is represented. When constructing a virtualization of an object in AASX Package Explorer (AASX PE), this tool (at least at the time of this thesis) is entirely focused on the representation of real-time data, which presented a major challenge since the only available data consisted of historical records. This limitation made it impossible for the “Time Series” submodel to display graphs showing changes in values over time. In fact, considerable effort was put into finding solutions for this issue; however, it appears that methods for representing historical data in the AASX PE tool have not yet been developed. Despite this, other submodels using static data, such as those related to documentation and technical specifications of the equipment, worked perfectly well.

Regarding the capabilities of the DTs developed using this application, AASX PE, when compared to the potential and characteristics of the various DT architectures previously analyzed, offers a relatively limited range of features. As an open-source tool, this application depends on the ongoing contributions of a global community, particularly regarding submodels and the core capabilities of the platform itself. As mentioned above, there is still no way to visualize historical data in AASX PE using Excel files. This and many other features—such as the simulation of more complex variables or 3D representation models—may be added to the application in future versions, helping it reach the potential envisioned by many authors for DT technology. So far, despite their limitations, these representations of industrial equipment mark a step forward in the progress toward fully implementing virtual representations of assets.

5.2. Challenges Found in the Integration of DTs with DSs

This second stage of the project has always been the most ambiguous and challenging part of the entire work. In addition to the complexity of the engineering field in which Data Spaces (DSs) are situated—often involving steep learning curves and considerable technical barriers—the existence of numerous organizations, initiatives, projects, and tools, all undergoing frequent changes and updates due to the novelty of the topic, makes most of the existing documentation prior to 2023 outdated or incomplete. Thus, the first major difficulty in integrating Digital Twins (DTs) with DSs was separating reliable information from unreliable sources.

Fortunately, after building the AASs using the AASX Package Explorer (AASX PE), the decision regarding the tool for representing DSs was quickly resolved upon discovering that the application used for representing DTs had been integrated with the AASX Server under the EDC (European Data Strategy) project. This project aims to combine the functionalities of the original application with the ability to host AAS repositories on servers, thereby enabling the creation of DSs. Additionally, another positive point was the impact of the Gaia-X initiative’s specifications on the architecture of EDCs, ensuring data sovereignty, transparency, and trust in data exchanges. Despite the advantages of integrating these two technologies under a single project, this integration did not lead to significant progress, as the EDC project is still in its incubation phase, with limited tools and support available.

On the other hand, one application that has gained some prominence in representing servers with AAS repositories is the AASX Server. This application, in its versions predating its inclusion in the EDC project, already allows for the representation of aasx file package repositories using three different approaches. Tests conducted with the AASX Server Core and the AASX PE interface encountered some issues: the server would not launch via Command Prompt, and access was denied, or certain public servers could not be found. Regardless, a demonstration of all these components was provided.

Although the implementation of a repository server with the three developed AASs stored there fell short of expectations, it was still possible to demonstrate the operation of these tools, resulting in the development of an almost step-by-step user guide for them. The ultimate goal for the AASX Server, as envisioned by its developers, is the evolution of these repositories into fully functional DSs. With the current configuration of these tools, additional building blocks—such as marketplace services or registry components—are necessary to enable compliance with IDSA architecture specifications. This may be the next step to be taken by the developer community in the near future. Until then, the current capabilities of the existing tools will be demonstrated.

6. Conclusions and Future Work

This dissertation consisted of studying and applying the concepts of Digital Twins and Data Spaces in a real context by applying these technologies to industrial equipment. As these are relatively recent concepts, a thorough and comprehensive exploration was carried out in order to obtain an overview of these technologies. After compiling the state of the art, we moved on to an in-depth analysis of the application of these tools through the methodologies developed and studied by the scientific and industrial community. At this stage, the methodologies for integrating a DT with a DS were studied, and the organizations that currently promote DTs and DSs, and the tools that integrate them, were identified.

In the practical application section, we started with the process of building the DTs. Before choosing the specification to use, we analyzed the data from the equipment that makes up a TMU. Historical data from a DGA monitor and a G2 Transformer were processed. Subsequently, with the choice of the AAS standard and AASX PE as the respective applications to represent the assets, three DTs were built: one for each individual asset, and a third for the TMU system. Moving on to building the AASs, we took advantage of the submodels and elements created by the developer communities. In the next phase, we studied how to create a repository server for the assets represented, using AASX Server. Despite some challenges and difficulties, recent Eclipse Foundation projects, such as EDC and Eclipse AASX Package Explorer and Server, have allowed us to define a roadmap for future work on integrating AASX PE DTs with DSs created from AASX Server.

During the course of the project development, several complications and limitations emerged that may have affected the quality of the results. The initial proposal of this project may have been overly ambitious, as the need to explore the proposed topics, combined with a lack of technical knowledge regarding many of the technologies addressed, resulted in significant time being spent studying these methodologies in order to achieve a proper implementation. In addition, the barriers encountered while using the applications (AASX PE and AASX Server), such as the transfer of historical data from Excel files and failures in accessing the Blazor server, further delayed and limited the achievement of better results.

As has been mentioned, the areas of DTs and DSs have seen an increase in interest from the scientific and industrial communities, so that during the internship, repositories of specifications, articles, and documents were constantly being updated. Therefore, considering that this evolution in the means and methodologies for representing assets on digital platforms will continue, future work and research could focus on further and better realizing this potential.

This potential could come from the development and application, not only of applications such as AASX PE, but of better and more detailed sub-models, making it possible to represent more complex asset data and information. Regarding the DS component, developing these platforms through more initiatives and projects, being more accessible to the average user, could lead to greater use of these tools, generating more platforms and initiatives for integrating these two technologies.