Introduction
Digital Twins are currently growing in relevance across a number of domains, e.g. construction or e-health. Because of the wide variety of applications in which Digital Twins are used, they need to be able to handle heterogeneous data from different domains; i.e., the physical layer. Digital Twins need to harmonise these data in order to make it interoperable so it can be transparently consumed by domain experts through the digital layer provided by the Digital Twins. As a result, the data flow between the physical and the digital layer becomes bi-directional, entailing that changes at the digital layer may produce effects in the physical layer.
In the construction domain, particularly in railway stations, a European project called COGITO1 (COnstruction-phase diGItal Twin mOdel) has been proposed. The COGITO approach is developing a Digital Twin for ingesting and man-aging data coming from a physical layer that consists on sensors, actuators, or static data files such as ifc, schedule or workers, and providing a digital layer containing the Digital Twin Platform and applications that use that data.
During the development of the COGITO project, three main challenges have been identified and addressed. I) Transparently consume the data coming from the physical layer due to the heterogeneity of the APIs within; to tackle this issue RDF generation services are used, which ingest data from a specific domain and produce semantic interoperable data that conforms the Digital Twin Knowledge Graph. II) Since the domains covered by COGITO are wide, the number of services generating RDF is numerous and, as result, given a specific piece of data choosing the correct service becomes challenging; to tackle this issue COGITO relies on the W3C standard Web of Things for generating a Knowledge Graph about the available Translation Services that is used for taking a suitable decision. III) The construction projects involve several sources from the physical layer and their related fragments in the Digital Twin Knowledge Graph. As a result, keeping track of all the data involved in a specific project from the layers physical and digital becomes a challenge; to tackle this issue COGITO relies on the W3C standard Web of Things for generating a Platform Knowledge Graph that relates for a given project all the sources from the physical layer and their corresponding RDF in the Digital Twin Knowledge Graph.
The fact that the physical layer contains data sources that provide heterogeneous data entails that the COGITO Digital Twin Platform is not able to transparently consume these data. Therefore, a semantic interoperable approach is required for providing a digital layer that is transparently consumed by domain experts. To this end, COGITO counts with an ontology and demands that all data be expressed according to it. The difficulty in orchestrating the data exchanged be-tween the advanced functions is another challenge, because the data belonging to different formats cannot be correctly translated into interoperable data, so the data to be translated have to be orchestrated to make the correct translation. Finally, the management of these data in the digital model is the last challenge due to its complexity, as it does not allow existing data within the platform to be referenced to other data belonging to the same particular process, making it impossible to differentiate between them.
In the following, the above-mentioned challenges will be solved in the section of “Our proposal”, later demonstrated by means of the examples made and the results obtained.
Our proposal
The COGITO project has been designed for ingesting numerous sources that belong to a wide range of domains, as shown in Figure 1; such as satellite images, 3D scans, devices and sensors, meteorological, spatial, task and cost data. For this scope in this project the COGITO Digital Twin Platform has been developed, which uses data from the physical layer, which is conformed by the heterogeneous sources, and provides a set of Knowledge Graphs at the digital layer. Thanks to this last layer that provides data expressed according to the COGITO ontology, third-party are able to transparently consume and develop applications for different domains, such as Health & Safety, Quality Control, Adaptative Workflow Management and GUI & support Apps.
Figure 1. COGITO General Architecture.
Challenge I - Dealing with data heterogeneity from the physical layer
Due to the large amount of data belonging to different domains and their heterogeneity in terms of format and model, DTP cannot transparently consume these data. The transformation of these data into an equivalent version that is semantically interoperable is the first challenge identified in the COGITO project. The solution to this challenge is provided by the component Knowledge Graph Generator1, as depicted in Figure 2. This component is a service defined for a specific data source that first pre-processes the heterogeneous data, then translates these data into RDF expressed according to the COGITO Ontology2, and finally validates the RDF. The data resulting from this process are stored in the COGITO Data Persistence Layer inside the Digital Twin Knowledge Graphs.
Figure 2. First challenge solution.
The Knowledge Graph Generator integrates the Helio tool2, which relies on Mappings that hold a set of ad-hoc trans-lation rules for a specific source of data. For instance if a construction has schedules in XML and another in CSV two mappings are required, respectively. In addition, the Knowledge Graph Generator validates the RDF data using the W3C standard SHACL shapes3 which are made using the Astrea tool4.
Challenge II - Orchestrate distributed semantic interoperable architecture
Since the Knowledge Graph Generator must be defined for a specific data source and the physical layer counts with numerous, more than one instance of this component is required. Also, consider that the Knowledge Graph Generator may consume considerable computational power, entailing that a unique instance could become a bottleneck.
To build an efficient architecture, the DTP counts with several Knowledge Graph Generator instances, one per each source. This architecture leverages the computational power and the parallel processing by distributing in different nodes the Knowledge Graph Generators. The second challenge is due to this architectural choice and consists of know-ing for a given source which service needs to be invoked.
The solution to this challenge is provided by the Thing Manager, as shown in Figure 3. The W3C Web of Things paradigm is adopted in the Digital Twin Platform, which demands that the services must be described by a Thing Description5. In the Digital Twin Platform these services are the Knowledge Graphs Generators and their Thing Descriptions are stored in the Translation Services Knowledge Graph. As a result, the Thing Manager is able to discover the suitable service that must be invoked for the data coming from a specific source that must be processed.
Figure 3. Second challenge solution.
Challenge III - Organize data provenance under construction project
The Digital Twin Platform provides the Digital Twin Knowledge Graph through its digital layer. However, these data must be organized by the construction projects to which they belong, so for a given project all its related data is retrievable. Furthermore, the Digital Twin Platform demands to know the sources from the physical layer related to the data provided in the Digital Twin Knowledge Graph. The third challenge consists on grouping into projects different fragments of the Digital Twin Knowledge Graph and, also, relating these fragments to the physical layer.
The solution to this challenge is provided by the Thing Manager, as shown in Figure 4. The DTP creates a Thing Description for each new project. These Thing Descriptions are enriched with pointers to the data sources from the physical layer that are involved in that project. Then, the Thing Manager updates the Thing Description of a project with pointers to the Digital Twin Knowledge Graph anytime a Knowledge Graph Generator related to one of the sources described in its Thing Description is invoked.
Figure 4. Third challenge solution.
As a result, the Thing Manager is able to discover the Thing Descriptions related to a specific project that contain the pointers to all the fragments in the Digital Twin Knowledge Graph related to it and, also, the pointers to the sources used to generate those fragments.
Experimental results
The COGITO project is implemented in pilots from different countries, namely: Austria, Denmark, and Spain. In these pilots, one of the most important data sources are those that provide data about the schedules. These contain a set of tasks that must be carried out in a construction project. These tasks must be assigned to the workers and associated with existing physical resources in the pilot. To showcase how the aforementioned challenges are addressed in COGITO, this section provides an insight of how the schedules are handled in the Digital Twin Platform.
On the one hand, in order to include schedule, workers, and resources data into the Digital Twin Knowledge Graph, three Knowledge Graph Generators must be deployed and used with their mapping. In order to find a suitable Knowledge Graph Generator for them the Thing Manager must perform a discovery over the existing ones in the Translation Services Knowledge Graph. Listing 1 shows the Thing Description that points to the three Knowledge Graph Generators, notice that each of them are deployed in different nodes.
1 {
2 "@context":"https://www.w3.org/2019/wot/td/v1",
3 "title":"Channel Thing Description",
4 "id":"123456789",
5 "description":"Channel Thing Description to retrieve channel for server sent events",
6 "properties":{
7 "Channels":{
8 "forms":[
9 {"href":"https://data.cogito.linkeddata.es/tm/stream?channel=file.workers","type":"workers"},
10 {"href":"https://data.cogito.linkeddata.es/tm/stream?channel=file.schedule","type":"schedule"},
11 {"href":"https://data.cogito.linkeddata.es/tm/stream?channel=file.res_types","type":"resource_types"}
12 ]
13 }
14 },
15 "security":"nosec_sc",
16 "securityDefinitions":{"nosec_sc":{"scheme":"nosec"}}
17 }Listing 1. Translation Services Knowledge Graph.
Once the suitable Knowledge Graph Generator is found, it must be invoked for generating the RDF. In this example, the schedule is an XML file3, Listing 2 shows an excerpt. This file contains information about tasks, but not about workers and resources that are provided by different sources as shown by the Thing Description. For the sake of the article, the RDF of these sources is already present in the Digital Twin Knowledge Graph and the Platform Knowledge Graph.
<?xml version="1.0"?>
<Project xmlns="http://schemas.microsoft.com/project">
<SaveVersion>14</SaveVersion>
<BuildNumber>16.0.5134.1000</BuildNumber>
<Name>rst_advanced_sample_project_MSP2010.xml</Name>
<GUID>FE090C7C−7AEC−42FE−9452−AD0AA8643D28</GUID>
<Title>msproj11</Title>
<Company>Microsoft</Company>
<Author>Frederic Bosche</Author>
<CreationDate>2009−10−12T08:00:00</CreationDate>
<LastSaved>2021−03−29T16:37:00</LastSaved>
<ScheduleFromStart>1</ScheduleFromStart>
<StartDate>2009−10−12T08:00:00</StartDate>
<FinishDate>2010−07−02T17:00:00</FinishDate>
<FYStartDate>1</FYStartDate>
<Tasks>
<Task>
<UID>0</UID>
<GUID>AD74C853−6199−4FE2−994B−9C5142AD8021</GUID>
<ID>0</ID>
<Name>msproj11</Name>
<Active>1</Active>
<Manual>0</Manual>
<Type>1</Type>
<IsNull>0</IsNull>
<CreateDate>2009−10−12T11:25:00</CreateDate>
<WBS>0</WBS>
<OutlineNumber>0</OutlineNumber>
<OutlineLevel>0</OutlineLevel>
<Priority>500</Priority>
<Start>2009−10−12T08:00:00</Start>
<Finish>2010−07−02T17:00:00</Finish>
<Duration>PT1520H0M0S</Duration>
<ManualStart>2009−10−12T08:00:00</ManualStart>
Listing 2. Schedule XML Data Example.
For this example, the result of running the mapping for the schedule, and the mapping itself, can be found here. Once the translation process has been carried out, the result is stored in the Digital Twin Knowledge Graph and shown by Listing 3.
@prefix owl:<http://www.w3.org/2002/07/owl#>.
@prefix facility:<https://cogito.iot.linkeddata.es/def/facility#>
@prefix process:<https://cogito.iot.linkeddata.es/def/process#>.
@prefix xsd:<http://www.w3.org/2001/XMLSchema#>.
@prefix project:<http://data.cogito.iot.linkeddata.es/resources/project/>.
@prefix process:<http://data.cogito.iot.linkeddata.es/resources/process/>.
@prefix task:<http://data.cogito.iot.linkeddata.es/resources/task/>.
@prefix resource:<http://data.cogito.iot.linkeddata.es/resources/resource/>.
project:079637bb−87d5−4fef−9704−d556364d90ba
a facility:Project;
facility:isRelatedToProcess
process:079637bb−87d5−4fef−9704−d556364d90ba_FE090C7C−7AEC−42FE−9452−AD0AA8643D28.
process:079637bb−87d5−4fef−9704−d556364d90ba_FE090C7C−7AEC−42FE−9452−AD0AA8643D28 a
process:Process;
process:hasCreationDate "2009−10−12T08:00:00"^^xsd:dateTime;
process:hasTask
task:079637bb−87d5−4fef−9704−d556364d90ba_FE090C7C−7AEC−42FE−9452−AD0AA8643D28_0,
task:079637bb−87d5−4fef−9704−d556364d90ba_FE090C7C−7AEC−42FE−9452−AD0AA8643D28_1
...
task:079637bb−87d5−4fef−9704−d556364d90ba_FE090C7C−7AEC−42FE−9452−AD0AA8643D28_0 a
process:Task;
process:hasCreationDate ""^^xsd:dateTime;
process:hasPriority 500;
process:hasProgress "PT0H0M0S";
process:hasStatus "PT0H0M0S";
process:taskId "AD74C853−6199−4FE2−994B−9C5142AD8021";
process:hasAssignedResource resource:079637bb−87d5−4fef−9704−d556364d90ba_Worker_28;
process:hasAssignedResource resource:079637bb−87d5−4fef−9704−d556364d90ba_Truck_4;
process:taskUid "0".
task:079637bb−87d5−4fef−9704−d556364d90ba_FE090C7C−7AEC−42FE−9452−AD0AA8643D28_1 a
process:Task;
process:hasCreationDate ""^^xsd:dateTime;
process:hasPriority 500;
process:hasProgress "PT0H0M0S";
process:hasSubTask "1.1","1.2";
process:taskId "64518854−E3AA−4FF7−B8BC−33DB2326571C";
process:hasAssignedResource resource:079637bb−87d5−4fef−9704−d556364d90ba_Worker_24;
process:hasAssignedResource resource:079637bb−87d5−4fef−9704−d556364d90ba_Truck_1;
process:taskUid "1".
...Listing 3. Schedule translation in interoperable data.
Notice that in Listing 3 the process of linking between workers (human resources) and resources are made by using the predicate “process:hasAssignedResource”.
Finally, to have all the information related to a project described in the Digital Twin in one place, a Thing Description is produced, as shown by Listing 4, in which the process is related to the endpoints of the previously translated information.
1 {
2 "@context":[
3 "https://www.w3.org/2019/wot/td/v1",
4 {
5 "facility":"https://cogito.iot.linkeddata.es/def/facility#"
6 },
7 "https://w3c.github.io/wot−discovery/context/discovery−context.jsonld"
8 ],
9 "security":[
10 "nosec_sc"
11 ],
12 "title":"test1",
13 "types":"https://cogito.iot.linkeddata.es/def/facility#Project",
14 "registration":{
15 "created":"2022−10−05T11:46:50.411Z",
16 "modified":"2022−10−05T11:47:10.587Z"
17 },
18 "id":"079637bb−87d5−4fef−9704−d556364d90ba",
19 "securityDefinitions":{
20 "nosec_sc":{
21 "scheme":"nosec"
22 }
23 },
24 "description":"Digital Twin process 079637bb−87d5−4fef−9704−d556364d90ba",
25 "properties":{
26 "hasKnowledgeGraph":{
27 "forms":[
28 {
29 "href":"https://data.cogito.linkeddata.es/resources/079637bb−87d5−4fef−9704−d556364d90ba",
30 "type":"text/turtle"
31 }
32 ]
33 },
34 "hasValueInGraph":{
35 "forms":[
36 {
37 "href":"https://data.cogito.linkeddata.es/resources/project/079637bb−87d5−4fef−9704−d556364d90ba",
38 "type":"text/turtle"
39 }
40 ]
41 }
42 },
43 "links":[
44 {
45 "href":"http://data.cogito.iot.linkeddata.es/api/things/9dbfc5ac71a0aeaa49d56b654cdb62e44b743b4abd5b6179f4979bebc1940afb",
46 "rel":"facility:hasSchedule",
47 "type":"application/td+json"
48 }
49 ]
50 }
Listing 4. Process Thing Description from Platform Knowledge Graph Example.
Conclusion and discussion
Digital Twins are a tool that is currently on the rise. They handle a large amount of data, that makes them sometimes unmanageable to obtain particular data. Due to this problem, three challenges have been identified. These were solved by means of semantic technologies such as translation tools to translate heterogeneous data into RDF expressed according to the ontology of COGITO, making such data semantically interoperable in the platform, or the use of Thing Descriptions with the aim of handling data scalability problems in the existing processes in the Digital Twin.
As explained earlier, a semantic interoperable based approach has been created, to handle the problem of describing and exchanging information between different systems. Also, to manage and orchestrate data between internal Digital Twins tools, the Thing Descriptions have been used, containing all the links that references to the translation tools, and the information belonging to the heterogeneous data stored at the filestorage and the semantic interoperable data stored at the triplestore.
Future work
As future work, it would be possible to create the linking of construction projects by means of Thing Descriptions by construction project type, in order to be able to acquire the information more efficiently if information pertaining to a set of processes is required.
