A Methodology for Integrating Hierarchical VMAP-Data Structures into an Ontology Using Semantically Represented Analyses

Abstract

Integrating physical simulation data into data ecosystems challenges the compatibility and interoperability of data management tools. Semantic web technologies and relational databases mostly use other data types, such as measurement or manufacturing design data. Standardizing simulation data storage and harmonizing the data structures with other domains is still a challenge, as current standards such as the ISO standard STEP (ISO 10303 ”Standard for the Exchange of Product model data”) fail to bridge the gap between design and simulation data. This challenge requires new methods, such as ontologies, to rethink simulation results integration. This research describes a new software architecture and application methodology based on the industrial standard ”Virtual Material Modelling in Manufacturing” (VMAP). The architecture integrates large quantities of structured simulation data and their analyses into a semantic data structure. It is capable of providing data permeability from the global digital twin level to the detailed numerical values of data entries and even new key indicators in a three-step approach: It represents a file as an instance in a knowledge graph, queries the file’s metadata, and finds a semantically represented process that enables new metadata to be created and instantiated.

1. Introduction

Simulations are used in modern engineering to model physical effects and improve a product or machine. Simulation Process and Data Management (SPDM) requires (a) archiving the accruing data, (b) linking various simulation types implemented by different software vendors, and (c) transferring data between the simulation and design domains.

Standardized data formats, such as the ISO 10303 “Standard for the Exchange of Product model data” (STEP), play a major role in archiving [1]. To transfer data between different tools, most software is compatible with vendor-specific formats. However, this is not the case for all vendors and is tedious to implement for specialized software developed by Small and Medium Enterprises (SMEs) themselves. Therefore, the industrial standard “Virtual Material Modelling in Manufacturing” (VMAP) offers a vendor-neutral format and an I/O library to link simulation chains, including modeling information [2,3].

On the other hand, linking data between disciplines, particularly linking simulation data to design or measurement data, remains a challenge for SPDM due to the lack of data formats and integration methods. A proxy for this challenge is the simulation chain modeling a blow molding process. The process is shown in Figure 1 [2,4]. Here, VMAP data are successfully used for data transfer and archiving. However, data management capabilities and links to other disciplines are still lacking in this as well as other standardization approaches [2,5].

The solution we propose is realizing interoperability by harmonizing each data source’s metadata schema and data access methods. Here, metadata refer to data that are relevant outside of the simulation domain, such as core results, numerical parameters, and boundary conditions, or the engineer responsible. This is where an open framework, especially a semantic information model, comes into play.

This article introduces a software design for SPDM implementers based on a semantic information model. VMAP data are used as a proxy for semantic data management and automated knowledge graph population. During this research, the following were developed:

• a set of requirements for Ontology-Based Data Access (OBDA) of bulk data;
• mechanisms that upload metadata and automatically query additional information from the bulk data;
• queries for additional metadata using semantically representing routines that process the bulk data and produce metadata;
• semantic routine management that can be expanded from data processing to manufacturing and management processes.

To this end, current research approaches and their relation to this work are introduced (Section 2), the requirements imposed by handling simulation data in digital twins are clarified (Section 3), and a strategy for semantic definitions is developed (Section 4.1). The results include a method for information retrieval from the semantic framework (Section 4.2) and a prototype of the method (Section 4.3). Finally, the capabilities and limitations of the presented method and implications for future research are discussed (Section 5).

2. Standardization and Semantic Technologies for Simulation Data Management

This section introduces major efforts made in the simulation data standardization and explores its current shortcomings. The standardized data models contain a closed-world assumption (CWA). Their files are therefore implicit, i.e., require knowledge of the domain specifications, and have thus no reasoning capabilities. To alleviate these shortcomings, semantic technologies for SPDM are used in this work and are described in this section. Semantic technologies keep an open-world assumption (OWA) and their files do contain explicit knowledge, making them expandable and reasonable.

Table 1. The different methods considered for SPDM.

	Domain Knowledge	Data Access	Storage Logic
STEP	Application Protocol (AP) [8]	Part21 [9] or binary file [10]	ASCII file
VMAP	General Specifications [2]	Standard Specifications [3]	HDF5 file [11]
Data pipelines to knowledge graphs	Ontology	Mapping-based OBDA	Relational database or supported proprietary formats
This work	Ontology	Procedural knowledge in semantically represented access methods	Semantic knowledge graph and HDF5 data

compares additional aspects of the different methods introduced in this section.

2.1. Standardization of SPDM

2.1.1. The ISO Standard STEP

ISO 10303 “Standard for the Exchange of Product model data” (STEP) [12] was developed for the long-term archiving of product development data in safety-critical engineering disciplines such as aviation, the automotive industry, and defense. It offers a standardized software-independent description of product data throughout the product life cycle, providing data modeling and storage definitions for large portions of Product Lifecycle Management (PLM). In ISO 10303-209 [1,13], simulation data were included to allow SPDM to be integrated into PLM. However, it falls short in important aspects of data management:

• The data model requires tedious and lengthy standardization processes for new modules due to the CWA: only defined classes are accepted.
• The data definition varies fundamentally due to the different granularity of design and simulation data.
• Simulation data can either be referenced as a whole file or fully stored in a STEP file. Referencing, however, lacks the possibility of linking to key results within the model, while STEP file formats require large amounts of storage space as described in Section 3.

2.1.2. The VMAP CAE Data Interface Standard

Contrary to the strict ISO standardization process, a standardization community from different industry branches recently developed the industrial standard “Virtual Material Modelling in Manufacturing” (VMAP) to provide data transfer between simulation tools. VMAP offers a vendor-neutral data format and a library of I/O routines to link chains of various simulation data formats [2].

The VMAP standard is based on Hierarchical Data Format (HDF5), a widely accepted implementation platform for many I/O-related applications [11]. Data were aligned into groups defined in the VMAP standard specifications [3] and commonalities were identified among many software packages to create the standard. Keeping this in mind, the VMAP storage structure defines the four main groups that form the essence of any simulation. Computer Aided Engineering (CAE) data are sorted into datasets and attributes within four main groups [3]:

• GEOMETRY contains spatial information on nodes and elements.
• VARIABLES stores physical quantities referenced to the nodes and elements.
• In SYSTEM, the simulation parameters such as coordinate system and integration method are defined.
• MATERIAL contains material information stored in different tables, which can be imported or shared across files.

Generally, data formats for SPDM must be compatible with varying material assumptions, boundary conditions, and numerical parameters simulation tools [14]. As VMAP is capable of this, it has been well-accepted within and outside of the standardization community. However, alignment methods to other product data should be included for full SPDM capabilities, such as design data, measurement data, and subjective intent capturing [15,16].

As a consequence, semantics should be added to the VMAP standard. Currently, no similar research is known to the authors.

2.2. Semantic Technologies for SPDM

Ontologies structure concepts in terms of meaningful relations (semantics). Knowledge graphs with node–edge–node structures (triples) incorporate semantic definitions in data schemas called ontologies. These graphs enable additional information (inferences) to be derived (reasoned) from the explicitly stated (asserted) relations. Semantic technologies promise to provide the foundation for a flexible and expandable data management system [17,18].

A noteworthy alternative is the addition of links to the VMAP standard. Generally, the HDF5 format supports hard links (to a physical address within a file) and symbolic links (a string for links within and outside of the file) [11]. This would partially enable SPDM capabilities for simulation files. It would, however, remain restricted to HDF5 files and require a translation or reference method for the integration into PLM systems. Conversely, ontologies are already used for PLM system development [19,20].

Two main issues need to be addressed in order to make good use of ontologies for data management. First, the mapping and interrelation between all domain-specific schemas need to be defined in a common ontological core framework. Second, the semantic resolution and a corresponding method for using the ontology within and beyond this resolution are necessary to achieve data permeability in practice. In the following, we relate our work to other research results.

2.2.1. Ontological Core Framework

The first point of a common ontological core framework is provided by MpCCI Ontologies for Digital Twins (smartMpCCI), developed by two of this paper’s authors [21,22]. This ontology combines process-centered descriptions with data resources from various disciplines to align digital twin assets with simulation models and data analytics.

Other simulation ontologies are more restricted to a system-level perspective [23], which does not allow for the required integration of resolved physics. On the other hand, application-focused ontologies for digital twin systems often capture only the system or event-level [24]. Moreover, both generally struggle on a semantic level to reconcile simulation with the various Industry 4.0 standards (for plant planning and operation) [25].

Recently, Singh et al. [26] developed a central knowledge base in which databases have one-to-one mappings between the ontological relations and the data tables. However, this is only demonstrated for factory data acquisition, not simulation data, underlining that digital twin data management is an ongoing challenge in which simulation is seldom addressed.

The Physics-based Simulation Ontology (PSO) by Cheong and Butscher [27] extends the Basic Formal Ontology (BFO) [28] to simulation data. It explicitly models the physics and qualities of spatiotemporal assets in both the physical domain and the simulation domain. Underlying physical equations, discretization, and boundary conditions can be related to their physical equivalents. However, the PSO falls short of addressing how to store and handle the corresponding simulation data resources. The schema of smartMpCCI, on the other hand, is comparatively limited, focusing on the digital twin context. Therefore, harmonizing PSO and smartMpCCI seems recommendable for future studies.

2.2.2. Ontological Data Integration

This study is an original contribution to semantic resolution and corresponding integration methods. It presents a method for Ontology-Based Data Access (OBDA), which is novel to the authors’ best knowledge. Four key aspects of Ontology-Based Data Access (OBDA) are relevant to evaluate the state of the art:

• Bulk data must be stored in an efficient format. This may be propriety or semantic.
• To store data efficiently, it may be integrated to different extents.
• Data access must be defined if data are not fully imported into the database.
• An ontology, i.e., a domain model, is required for full reasoning capabilities and must be maintained.

OntoDB is a leading data integration system based on ontologies [29], in which data storage and schema are inseparable in the same database. The data are migrated into a performance-optimized “state table per class” structure, making the ontology the database schema. This does, however, not leave the resolved data in its optimal database (binary and distributed), which is a vital requirement of most digital twins.

The separation of the ontology and the database was later shown to work well on the NoSQL database MongoDB [30] and OntoP [31]. Here, an ontology describes the knowledge domain, while an access interface stores the semantic concepts in a form that can be translated into the database queries. The database and its contents themselves are not semantically described, but rather the queries that can be addressed to the database. This approach is similar to the non-ontological Representational State Transfer (REST) Application Programming Interfaces (APIs) [32]. For hierarchical data, this raises the question of how to separate database-structure-specific semantics from the knowledge domain. Additionally, the data interface must be easily adapted to knowledge domain updates. This paper proposes such a separation using a semantic representation of extraction routines.

The SPARQL Protocol And RDF Query Language [33] (SPARQL)-Anything project [34] separates the storage-specific semantics from the knowledge domain by parsing data formats to Resource Description Framework [35] (RDF) and accesses the actual data contents with property functions that are an extension to a SPARQL engine. While this approach does not contain domain-specific mappings, Steindl et al. [36] implemented an OBDA method for the machine operation data standard Open Platform Communications (OPC) Unified Architecture [37,38] (OPC-UA). Both methods vary from our study due to the complete translation of the data model to RDF-triples without semantic representation of the property functions themselves, thus keeping the data structure non-ontological and removing the OWA. However, reconciling the approaches could be a fruitful combination of two important types of assets for digital twins.

Each of these data access methods uses ontologies for mappings of some sort. Numerous possible mechanisms exist to create and update the joint knowledge base. With the separation between the ontology-structured metadata and the databases themselves, a knowledge graph needs to be maintained. RDF mapping languages such as the RDB to RDF Mapping Language (R2RML) [39] express custom mappings between relational databases. Furthermore, Leshcheva and Begler [40] developed an automated ontology population. As such, these methods are restricted to semi-structured data with additional semantics in data source ontologies, contrary to the hierarchical VMAP format. However, the HDF5 files may be translated to a relational format and thus imported into the knowledge graph. While this may be possible, it requires multiple mappings, creates large amounts of in the process, and still leaves the question of domain knowledge definitions in an ontology. Therefore, this approach was not applied in this work but should be investigated in future studies.

3. Software Requirements

Considering the described state of the art, we require the following key features of modern ontology-based data management:

• Semantic access to simulation data is necessary due to the described digital twin context. Simulation data, including all data values, must be found from a semantic access point.
• Simulation data are too large for a one-to-one mapping to a semantic framework, as is the current practice in OBDA [26,29]. Storage space is already a significant issue for SPDM, especially in dynamic simulations. Storing it in triples can be expected to take up a multiple amount of storage space, while the knowledge gained may be minimal. This is due to the clear-text nature of semantic formats and the inefficiency of RDF in storing ordered lists or even arrays, as structural relations would be repeatedly stated [18].
  The extra space is easily demonstrated when comparing the size of a use case example for STEP Application Protocol 209 “Multidisciplinary analysis and design” in ISO 10303-209:2014 (AP209) [41]. The recreated test case file in VMAP takes up only 176 kB of disk space, much less than the AP209 test file with 4278 kB. An Ontology Web Language [42] (OWL) instances file (translated using ExpressToOwl [43]) requires 43,652 kB. Therefore, the respective data must remain in its optimal storage format to minimize storage space while maximizing interoperability.
• Access methods must be easily available to create new metadata without manual labor. Currently, the post-processing of VMAP files requires mapping back and forth between vendor-specific formats. This is computationally intensive and unnecessary for well-defined post-processing steps and easily automatable tasks that can be bundled in a batch process. The requirement we impose is automating data processing to obtain the desired information. For this, very performative routines are available in open-source software packages for the binary HDF5 structure of VMAP.

To fulfill the requirements, the following actions must be executed by the software solution (see also the UML^® [44] activity diagram in Figure 2):

• providing a file and request metadata via a user interface;
• uploading vital information from the file to the ontology down to a certain depth;
• searching the requested metadata and returning it if it is available;
• finding the routine required to create the metadata if it is unavailable, executing the routine, and adding the metadata to the knowledge graph;
• returning the metadata to the user.

Additionally, a version control loop may be added to find out whether the metadata and its routine are up to date.

4. Software Architecture and Prototype

The software requirements are put into practice in a prototype software architecture with three significant characteristics:

• All data can be accessed via the knowledge graph (see Section 4.3). A GUI is implemented to show the current capabilities.
• The knowledge graph is populated only with such information required for new metadata to be queried and found or created with efficient methods (Section 4.1), thus significantly reducing the required storage space.
• Access methods are semantically available in the knowledge graph and can be easily managed (see the process ontology in Section 4.1 and the access layer in Section 4.3).

This section presents the characteristics of the developed prototype. First, the ontologies are introduced; second, the information access from the knowledge graphs is discussed; third, the method implementation is presented; finally, the method’s capabilities are shown. Figure 3 shows an abstract representation of the architecture.

4.1. Semantic Definitions

Two ontologies are used: one for knowledge graph population (storage ontology) and one for querying the database from within the ontology (process ontology). These are separated here, as both ontologies may be used independently for their respective purposes. While the storage ontology is intended to be format-specific, the process ontology uses generic classes and format-specific classes to organize data access across formats. Both ontologies are publicly available at https://gitlab.scai.fraunhofer.de/vmap-onto/vio-method/-/tree/main/vmapontologies (accessed on 26 December 2023). The RDF notations of both ontologies’ top-level classes are provided in Appendix B.

4.1.1. Storage Ontology

An ontology of the storage structure is required to find and reference the desired information. Recently, an ontology to represent the mereology (part-of structure or storage structure) of the VMAP standard specifications [3] was developed. It is aligned with the smartMpCCI ontology currently being developed at Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) [21,22]. It relates storage levels (groups, attributes, datasets, and dataset columns) to their parent directory and contents via an isStoredIn and an inverse stores object property restriction. The semantic integration is capped at the dataset column level, for which only value type and column number or column name are specified via data property restrictions. The top-level classes of the VMAP storage ontology are shown in Figure 4.

4.1.2. Process Ontology

A Routine is a subclass of a BFO:Process [28]. It can be any data processing routine, from a simple line of code to a batch process. An ontology of the metadata routines provides information on the inputs and results of the routines, such that a routine can be found based on the requested metadata. The routines can be generic for HDF5 files or datasets, specific for VMAP files or datasets, or tailored to any other specified file type. Hence, a VMAP_Routine class should be defined with a hasOutput object property restriction pointing to a VMAP_Metadata class and hasInput pointing to a VMAP_File or VMAP_Dataset class. The top-level definitions of the VMAP routines ontology are given in Figure 5.

This architecture forms the basis of querying semantically represented data. Additional semantics can be provided by general ontologies such as PSO, for example, understanding the stored quantity and thus including more profound knowledge of the metadata. Additionally, the schema can be integrated into a broader digital twin context by aligning it with the BFO or smartMpCCI by defining Routine subClassOf BFO:Process [28] or Routine subClassOf smartMpCCI:Simulation_Aspect [21]. Such linkages should be further explored in future research to fully exploit the advantages of ontological data management.

4.2. Querying Information in Three Steps

The core concept of information access is demonstrated here by querying basic storage relations. The knowledge graph is assumed to be instantiated, containing the explicit metadata of a given VMAP file, and the required processing routines have been indexed for automated execution. Three queries are executed to search the metadata and find the required routine. The code listings in RDF Schema [45] (RDFS), OWL, and SPARQL notations are given in Appendix C.

1.

Find the File

Instead of the user providing the file, some information about the file can be given to run a SPARQL query. This can, for example, be the data property stores_variable “temperature” of a column within a dataset. Figure 6 demonstrates the queried graph.

2.

Find the Metadata

Some metadata can be available within the file or dataset. The desired metadatum can easily be found via a data property, as shown above, or via its type (Figure 7 demonstrates the queried graph).

3.

Find the Metadata Routine

Individuals of Routine can have relations to Metadata, and File individuals and can be queried directly. Figure 8 demonstrates the knowledge graph and related SPARQL query.

However, instantiating a specific routine for each individual input and output may not be desirable, as it leads to new individuals for each metadata query. Instead, routine1 should be an instance of a Routine subclass, as shown in Figure 9. As class restrictions are implemented by making the class a subclass of the restriction, the routine must be queried via the inputrestriction and outputrestriction. As the hasInput and hasOutput object properties may be refined, any of their subproperties suffice. Therefore, the queried subgraph is more complex, as can be seen in Figure 10.

4.3. Software Design

The database queries and data processing routines are executed by a software framework described in this section. The working prototype is publicly available at https://gitlab.scai.fraunhofer.de/vmap-onto/vio-method/-/tree/main/vmapintegration (accessed on 26 December 2023), which provides the neighboring vmapontologies directory. Next to data (VMAP files for testing) and tests (scripts implementing the tests described in Section 4.4), src houses the implemented classes. They are divided into three layers: a presentation layer with the user interface, an application layer for the application-specific classes and methods, and a (data) access layer to load and access the files [46,47]. The UML^® diagram in Figure A1 in the Appendix A demonstrates the class relations.

4.3.1. Presentation Layer

The presentation layer handles user inputs and passes them to available methods. It is separated into a UserInterface class and a Control class, taking over the functions of View and Control in a Model–View–Control (MVC) architecture. The UserInterface class is loaded directly from the access point (main). Figure 11 shows the GUI implemented in this layer.

4.3.2. Application Layer

In the application layer, two classes are implemented.

The class VmapOwlConstructor populates the knowledge graph in the method vmap2owl. The method uses the sub-methods create_all_groups and create_all_attributes. The received and generated information is stored in fields such as vmap_file, vmap_ontology, vmap_instances, ID, and others.

The class MetaData calls the method metadata_search upon initialization, using a SPARQL query to check whether the requested metadata already exists in the knowledge graph. Here, the version control mentioned above can be added. If metadata_search is unsuccessful, it calls the routine_search method to find the relevant metadata routine and returns the information vital to importing and executing the routine. These two methods use the SPARQL queries suggested in Section 4.2.

MetaData has an exists_on_instance field pointing to the instance to which the metadatum applies. The field metadata_class is the class of which a metadatum is requested. During the metadata_search method, a routine_instance field is added. After executing the routine, the metadata instance and its value are added to the knowledge graph as a triple. Accordingly, the metadata_instance and the corresponding value fields are added to the class.

4.3.3. Access Layer

The routines found by routine_search are created as separate classes in the access layer. These can be housed by classes or created as independent methods. They are not imported unless required for the metadata_search method: for example, a method VmapDatasetMinimum inherits the minimum calculation method from its ancestor ArrayMinimum. This can be a simple NumPy function or a whole batch process.

4.3.4. Naming Conventions and Used Packages

The architecture requires naming conventions to be introduced throughout different development frameworks, as considerable amounts of information are stored as strings in OWL. In particular, the names of files or dataset paths, functions, and classes should be automatically linked or tested regularly.

Custom data types may be developed to achieve an integrated environment. For example, this would enable a data property of a Metadata or VMAP_Dataset_Column instance to be an HDF5 dataset, which otherwise cannot be stored efficiently in OWL. This can only be achieved using an integrated approach such as owlready2 in Python [48].

To realize the architecture in Python [49], four external packages are required for the user interface, ontologies, file access, and numeric calculations:

• The classes of the prototype’s presentation layer use the tkinter package, which provides functions for both the user interface and the control classes [50].
• To handle ontologies, owlready2 comes with SPARQL functionalities and the Pellet and HermiT reasoners [33,48].
• The h5py package can import HDF5 files, i.e., VMAP data [51].
• NumPy uses HDF5 for storage and computing and provides efficient numerical methods [52].

4.4. Test Functions

Several test functions for the basic required functionalities have been created. They are available at https://gitlab.scai.fraunhofer.de/vmap-onto/vio-method/-/tree/main/vmapintegration/tests (accessed on 26 December 2023) and briefly introduced here.

• Requesting metadata should require a minimal amount of information about its object. Finding the referred dataset instance has been implemented for an owlready2 entity, the datapath of a dataset, the required state variable, and the HDF5 dataset itself. This has been tested in test00existsoninstance.py, test01existsoninstancename.py, test02datapath.py, test03variable.py, and test04dataset.py, respectively.
• When instantiating a file to the knowledge graph, duplicates must be identified. This is tested in test05duplicatefile.py based on ID parameters.
• If a metadata instance is already available, it must be found in the knowledge graph and directly returned, rather than repeatedly searching and executing the data processing routines. In test06duplicatemetadata.py, metadata instances are found with the same existsOn and subClassOf specifications as requested.
• More complex metadata, i.e., the difference between two datasets, and translations of Cauchy stresses into a Von Mises criterion, are created in test08difference.py and test09cauchytomises.py, respectively.
• A more complex blow molding simulation result from an industrial use case for VMAP [2] was instantiated and processed in test07bsimresults.py. The data for this test case is currently not publicly available.

The prototype has successfully completed all test functions.

5. Discussion and Outlook

This paper presents an ontology-based data management method for physics-based simulation chains built on the VMAP standard. General strategic decisions are based on literature and concrete requirements for VMAP use cases. The proposed architecture can automatically populate a knowledge graph with storage and metadata information of a VMAP file, query some simple metadata semantically, generate new metadata directly from the VMAP file using efficient routines, and add the acquired data to the knowledge graph.

The results of this research indicate a significant improvement of two key issues of an SPDM for hierarchical simulation data by the architecture suggested in this paper:

• Without manual mapping, data can be directly analyzed on the binary VMAP file. Loading only vital information into the ontology minimizes the storage space footprint of the stored triples, and the bulk data remains in its optimal form.
• New numerical methods and data analyses can be imported into the process ontology for knowledge management of the available routines and automatic use in the semantic framework.

This is achieved by separating the knowledge base from the data sources, using the data storage definitions for automatic knowledge graph creation, and semantically representing data retrieval and processing. The architecture has been realized as a prototype in Python and is provided in the supplementary information of this article.

Some limitations remain and should be considered and investigated in future research:

• As outlined in Section 2, a widely accepted common ontological framework for OBDA of simulation data is yet to be developed. Harmonizing smartMpCCI and PSO appears to be a promising starting point.
• The ontology models have, thus far, been created manually. This should be automated for the storage ontology to allow scalability to more formats and version updates. Some progress has been made regarding ontology generation from source code [53] or raw text [54] and should be considered.
• The method is currently only implemented as a prototype and is not yet being used in an industrial context, which is a vital prerequisite for the method’s success [5,14]. Currently, PLM methods and particularly SPDM methods lack standardized benchmarks, restricting the evaluation to expert assessments for individual industry scenarios [15].

For the method presented in this paper, at least three points should be implemented in an integrated framework and benchmarked against other methods:

• The capabilities of OBDA can be fully exploited when aligning ontologies of different domains. This is an open field of research where progress has been made in recent years [55,56].
• The computational overhead of the method depends on the search along the knowledge graph. This can be minimized using efficient semantic search engines [57]. The method may be limited to the simple routines tested in this paper. However, APIs can be used to automate integrated workflows efficiently.
• The organizational overhead of SPDM methods typically remains dependent on the implementation of new routines and may limit the applicability [5,14].

Unfortunately, this extensive in-industry testing lies outside of the scope of this research paper.

In future work, we propose firstly refining and extending the semantics, secondly developing industry scenarios and benchmark cases for both SPDM and OBDA, and thirdly testing and validating them against traditional SPDM and OBDA methods. With further development, the architecture could form the basis of OBDA that can be extended to various data formats, processing routines, and application contexts when embedded in or mapped to a common semantic framework. It unites the advantages of binary data storage, knowledge management, and semantic inferences. SPDM development remains a significant challenge within digital twin technologies, for which this research offers a promising approach.