Organisations are intensely developing Digital Twins (DTs) to correctly and e ciently answer questions about the history and behaviour of physical systems. However, it is not clear how to construct these DTs starting from the data, information, knowledge, and wisdom available in the organisation. In this work, we present our approach to DT construction which involves a layered knowledge graph (KG) architecture communicating with the organisation's data repositories. We explain the components and timelines for using the KG to build both historical and streaming DTs, and what kinds of questions can be answered for our drivetrain use case.
The rise of the Internet of Things (IoT) and Industry 4.0 means that today's
industries are faced with a deluge of data. Multitudes of data points (sales, sensor
values, maintenance records, . . . ) are generated each second and poured into
various data repositories, each with implicit connections and relations between
organisational resources (processes, machines, environmental conditions, etc.).
The lack of semantics and explicit relations can hinder actionable insights [
For example, a simple query such as what experiment produced these results?
can often become an laborious endeavour to answer. As a rst step, one must nd
Copyright © 2021 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
the data and then understand the format and units, which may involve countless
emails to nd the one person in the organisation who understands the data. This
ine cient process can consume the time of multiple people on coordination,
which is further delayed if anyone involved has left the organisation.
Report Context This paper presents our current insights and vision developed
as part of a joint academic-industrial project led by Flanders Make, the
strategic research center for the Flemish manufacturing industry. The Framework for
Systematic Design of Digital Twins (DTDesign) project brings together three
universities and ve industrial partners to focus on determining the most e
ective technologies and methods for how to build a Digital Twin (see Section 3)
from a representation of an organisation's past and current data, information,
knowledge, and wisdom (DIKW) [
Approach In the DTDesign approach, the representation of an organisation's
DIKW is stored as a knowledge graph (KG) which \acquires and integrates
information into an ontology and applies a reasoner to derive new knowledge"[
While KGs and DTs are each relatively old concepts, only recently has there
been work on their interactions, such as [
Contributions and Structure This paper presents these speci c contributions: { Section 2: A high-level architecture relating a KG to DTs. { Section 3: De nition of historical and streaming DTs, and a connection to the answers they provide for an example drivetrain use case. { Section 4: A discussion of the structure and purpose of this KG including how to access, update, and compartmentalise the data/information/knowledge/wisdom within to serve large industrial organisations. { Section 5: A presentation of an example timeline for creating DTs and their relations from a KG. 2
This section provides a brief overview of our approach to using a knowledge graph (KG) to assist with the construction of digital twins (DTs). As discussed in Section 3, these DTs are a virtual representation of a physical system.
Figure 1 shows the conceptual architecture of our solution. Our approach relates four main components: 1) the KG containing information, which rests on the data repositories of the organisation and acts as a historical DT, 2) the users and applications who access information from the KG and DT, 3) a physical system under study or control, and 4) the (streaming) DT of that system.
Four relations are also speci ed: A) the relation between the physical system and the DT, B) information added to or retrieved from the KG, C) the connection between the KG, data repositories, and the digital twin, and D) the questions and answers between the user and the DT. Of course, the users may also manipulate the physical system, but we omit this interaction from our architecture.
The remaining sections of this paper describe these components and relations in detail. Also note that Figure 1 does not represent the time dimension of the creation of the historical and streaming DTs. This is discussed in Section 5. 3
This section provides background on digital twins (DTs) and introduces our notions of historical and streaming DTs. Our drivetrain use case is also brie y presented through a discussion of how these DTs can provide actionable answers about the drivetrain.
As sensors and computing power become ever cheaper each year, it becomes
easier to combine real-time data with high- delity models to create a virtual
representation of a system to answer questions about that system. The umbrella
term digital twin captures this relationship between a physical system and its
digital counterpart [
Kritzinger et al. classify the term digital twin into three categories depending
on the relation between the physical object and the digital object [
One of the use cases within the DTDesign project (see Section 1) is to represent and answer questions about an generic drivetrain representing drive-load interaction, which composes the components that deliver power from a motor to the wheels. In our conceptual architecture, these questions are answered by software/hardware components implementing a DT. Three question sets are presented here, as they showcase how the DTs built are at di erent scales and relate to the other components in Figure 1 di erently.
The rst question set is, \what is the correlation between motor current and the drivetrain torque, and which experiments have been conducted to investigate this?". The answer is therefore based on historical data, which implies that the DT is of the history of the drivetrain. We therefore term this a historical digital twin (Section 3.3).
The second question set is \What is the best sensor to add to my drivetrain to measure torque? Should this be a virtual sensor, or one relying on a non-intrusive sensor?". This question also relies on historical data for sensor validation as well as for physical modelling of the drivetrain components.
The third question set asks, \What is an algorithm to detect anomalies in the torque of the drivetrain, such that a warning signal can be raised?" This algorithm can be trained on historical data, but will be deployed into a streaming digital twin (Section 3.4) which is directly connected to the physical system. 3.3
In the historical DT case, the objective is to utilise the past knowledge of an organisation to determine which correlations are present in data, or to create and optimise algorithms to deploy in a streaming DT.
A traditional process may involve a data scientist mining experimental results and databases to locate such correlations. This can be a labour-intensive process if the information is not readily available, such as the data scientist having to contact a database owner to understand the meaning of the stored data.
In our approach, the historical DT created is a combination of software and hardware which is able to access the historical information available in the knowledge graph, or up-to-date information from the physical drivetrain system through the data lake. The data scientist can then ask relevant questions to the DT to obtain the required information in a structured and e ective manner.
The historical DT is also relevant for questions where the user wishes to model and simulate the drivetrain itself in high- delity. As discussed in Section 3.2, a relevant question is whether a sensor can be found that is not too physically intrusive to be mounted on the drivetrain, or whether a virtual sensor must be created through combination of readings from other sensors. This relies on an accurate three-dimensional representation of the drivetrain geometry and of the considered sensors, such that the models can be combined with expert knowledge to understand if a particular sensor can be physically inserted into the drivetrain.
Note that in the historical DT case, the physical system does not need to be directly connected to the DT. Instead, it is the historical data that is of interest to the data scientist, and the DT represents the history of the physical system or the product plus production instead of the current behaviour. 3.4
In contrast, the second DT type created for the drivetrain use case is focused on the actual \live" behaviour of the drivetrain itself. Data ows from the physical system to the streaming DT in near real-time. That is, the streaming DT is running alongside the physical system. For example, the drivetrain question about anomaly detection requires a constantly updated stream of data being fed as input into a device running alongside the drivetrain. This anomaly detection model must accurately represent the behaviour of the drivetrain such that all relevant anomalies are detected with few false positives. A future enhancement for this use case is also to directly control the motors on the drivetrain using the streaming DT, such that anomalies are handled appropriately in real-time.
This type of DT focuses more on the relationship between the digital twin
and the physical system. Thus the streaming DT is closer to those DT
envisioned for optimisation and control of a system, where the DT has an automatic
connection to the physical system (see [
Note there may not be a hard division between historical and streaming for a DT, as both relate to information about a physical system. However, we state that in a historical DT, the \twinning" of the DT focuses on the past data and organisation's knowledge about a product or process. In other words, the physical system being represented is the past history of the object in question, and the organisation's knowledge about it. In the drivetrain example, this historical DT focuses on the correlation between the current provided to the motors and the resulting drivetrain torque, o ering answers to questions about properties, correlations, and experiments. As such, more information from the KG may be accessed or present within the historical DT. Indeed, a portion of the KG may be deployed as the historical DT itself. In contrast, a streaming DT is more focused on the \live" information from the physical system itself in (semi-) real-time.
Section 5 also discusses how a DT may change classi cation between historical and streaming through its development, as the relevant questions change and data from the physical system becomes accessible.
Finally, we wish to emphasise that this classi cation of historical and
streaming DTs is (mostly) orthogonal to the classi cation of Kritzinger et al. [
Therefore, it is possible to have any combination of historical/streaming and digital model/shadow/twin, except for a streaming digital model.
That is, a DT could be created focusing on historical data which automatically (or not) receives data and automatically (or not) controls the physical system. For example, a historical DT may be constructed to periodically examine the experimental data collected and automatically perform new experiments on the physical system to better understand the behaviour of the system.
As a streaming DT is concerned with the current behaviour of the system, it
must be able to automatically access the state of the physical system. Thus, a
streaming DT must be a digital shadow or digital twin as de ned by Kritzinger
et al. [
This section will discuss the knowledge graph in our approach. The concepts of information hierarchy, heterogeneity, and compartmentalisation will be discussed. The relation between the user and the knowledge graph as displayed in Figure 1 is also detailed. 4.1
As mentioned in Section 1 there is a deluge of heterogeneous data present in
today's large organisations. There has been signi cant work in the past on
understanding data through the use of ontologies and semantic reasoning to provide
context to this data [
One approach to storing this DIKW is with a knowledge graph, which stores this information as typed and attributed nodes with typed and attributed edges between them. The regular structure is well-suited to query approaches, and a great deal of exibility is provided to the organisation to store DIKW their way.
In particular, the knowledge graph should conceptually support storage of all relevant DIKW from the organisation, and the connections between. For example, the knowledge graph may contain formalisation of the assets, experiments, and conclusions performed by an organisation. This allows for its reuse in current and future activities.
Once this knowledge graph is (partially) lled, then it can start to answer meaningful questions about the people, processes, and things present in the organisation. An connection to data lakes expands the DIKW and connections available. New DIKW must also be added over time to support new uses, in an incremental and consistent manner. 4.2
One challenge of combining a knowledge graph with industrial digital twins is
that the knowledge graph must handle DIKW which is highly heterogeneous.
For example, the Reference Architectural Model Industrie 4.0 (RAMI 4.0) [
The DIKW within or referred to by the knowledge graph is also highly heterogeneous. For example, there may be time series, relational information, graphbased networks, images, documents, and any other information found in a large organisation. Another industrially relevant division is whether a piece of DIKW details the structure of an object, or instead details the behaviour of that object. For example, an architectural decomposition of a drivetrain refers to the mechanical components, while the behaviour is given through simulations or experimental results. 4.3
Conceptually, the knowledge graph contains all DIKW and connections in an organisation. As this is not feasible, it must be possible for the knowledge graph to be easily modi ed and evolved, and for connections between concepts to be very exible. As the knowledge graph grows in richness, the number of concepts contained must also expand for exibility and increased expressiveness.
In our knowledge graph approach, we o er the user a typing system that de nes attributes and relationships for concepts. This allows the user to specify their own types and instances, and to form typing relationships within the knowledge graph. An example subset of a knowledge graph is pictured in Figure 2. The upper box of the gure shows the types, while the lower box displays the instances. Note the vertical typing relations between these two boxes which provide the typing information for the instances.
However, it is also important to ensure consistency within the knowledge graph and to promote reusability and inter-operation with other sources of information. Therefore, the use of standardised concepts is suggested wherever possible. Also present in Figure 2 is the use of standardised and user-created types. In our approach, we de ne these explicit type hierarchies to provide a consistent and uni ed way to access and reason about the information contained.
In our approach, the knowledge graph is divided into built-in/standardised types and instances, and user-de ned ones. This encourages levels of consensus, where the upper levels have (potentially) an international consensus, and the user can de ne organisation-wide types and instances as required.
For example, the current prototype de nes built-in types similar to those
de ned in the Sensor-Observation-Sampling-Actuator ontology (SOSA) [
Figure 3 shows an example of type hierarchies implemented within our prototype knowledge graph. The upper levels are type hierarchies which form the structural backbone of knowledge graphs. The lower levels are type hierarchies in the knowledge graph prototype representing useful formalisms. These hierarchies are not xed, but instead represent that layered approach needed to have a consensus-based yet exible type system. Of course, the user is able (and encouraged) to develop their own layers beneath (or above, or alongside...) those layers shown here to ensure exibility and relevance to the concepts required by the organisations.
For example, the ValidityFrames type hierarchy in Figure 3 includes types
relating to our previous research in de ning the conditions and degree in which
a model is valid with respect to a real-world system [
For practical reasons, in our approach the knowledge graph cannot contain all DIKW. This is due to the massive amounts of data incoming from assets in the organisation, which could quickly overwhelm the storage, reasoning, or querying capacities of the knowledge graph. Instead, our approach proposes a dedicated data layer between the knowledge graph and the underlying data stores. Thus this knowledge graph could be termed as a `virtual' knowledge graph.
Figure 4 shows our layered knowledge graph approach. At the bottom are the sources of raw data, such the sensors of machines and organisation databases. Unique identi ers stored in the knowledge graph point to these sources of information. For example, the location of a data series may be stored in the knowledge graph, but not the individual data points themselves. The adapter layer is then able to resolve both the element type and the unique identi er to determine how and where to access the underlying data.
The knowledge graph requires neutral access to these data sources through a data adapter layer. This layer is intended to shield the knowledge graph from knowing the particulars of the data storage, which is quite technical and subject to constant revision. Examples of this include the database API, SQL queries, or OPC-UA (https://opcfoundation.org) commands necessary to access information, or the login information for repositories. Separating these more technical details out from the knowledge graph allows for greater scalability through the removal of transitory information and better handling of heterogeneous machine con gurations. Thus, the data layer forms the abstracting barrier between the virtual knowledge graph (dealing with reasoning concerns) and the technical data sources (dealing with scalability and storage concerns).
For example, the knowledge graph may indicate that humidity information for a particular machine is stored as a HumidityMeasurement instance stored as a TimeSeries at a particular location. Typing this information allows for the knowledge graph to indicate constraints on the data, and precisely specify the type of information stored, while leaving the actual values to be stored in an appropriate way until explicitly requested by a user or application. This TimeSeries can be explicitly linked to the Humidity data type, allowing for a user to directly query, \where is humidity information for this machine?". Further information and knowledge can also be inferred with further connections, to indicate the experimental conditions a TimeSeries was produced from or the Observation procedure used. 4.5
In the overview shown in Figure 1, there is a component which represents the user accessing the knowledge graph, or an application on their behalf. This application could be a dashboard, reports, or any other visualisation. Once the information is placed in the knowledge graph, there must be an easy-to-use method for users and applications to extract this information. An example could be to ask for the set of all physical quantities in the knowledge graph, or which data stores contain temperature information.
As with any API, there are many challenges to provide a scalable,
expressive query interface to the knowledge graph. Currently, we consider the API
speci cation language GraphQL (https://graphql.org) to be a feasible approach.
This query language takes queries de ned in a JSON-like format, and evaluates
the elds requested using de ned resolvers [
This section will discuss the contribution of this paper concerning the construction of digital twins (DTs) using a knowledge graph (KG). In particular, an example timeline is shown noting how the historical and streaming DTs are created from the KG, and in connection with the KG.
Figure 1 relates the di erent components of our approach. However, the time dimension is not represented in that gure and will instead be discussed here. In particular, this section deals with relation C in Figure 1.
A portion of our current research is to create a work ow for how the KG, physical system, and DTs could be created either sequentially or in parallel. However, for brevity, this work will instead present an example timeline, showing one possible path for creation of all components. Figure 5 demonstrates this timeline as the construction of a KG, and then di erent types of DTs being built from it. In this gure, time increases to the right and the arrows between boxes represent a manual or automatic transfer of DIKW between the KG and the DTs.
Fig. 5: Example timeline for Digital Twin creation. 5.1
The rst step in the construction of the DTs is the building up of the KG itself. In Figure 5, this happens before any digital twins are built, where the user imports data, information, knowledge, and wisdom (DIKW) from existing repositories and creates types and instances. Conceptually, this KG exists throughout the lifetime of the organisation. As DTs are built, they are built using the knowledge in the KG, as well as connect to the KG to deposit new DIKW. 5.2
Once the KG is created, a few di erent paths exist for the creation of the DTs. In the lower-right of Figure 5, a historical DT is used to gather DIKW about the system, such as designing the most e ective sensor for the drivetrain use case. Then, a deployment occurs, where the models and sensors are deployed onto hardware and connected to the physical system.
On the top-left of Figure 5, a DM is created from the KG to gain insights about the system. Insights are then relayed back to the KG, with the communication interleaved with the creation of the DT on the bottom-right. This represents how the queries to the KG are \snapshots" in time, and how the KG evolves as information comes back from the DTs.
Finally, in the top-right of Figure 5, a DS is created which is in connection with the physical system, and is not reliant on information from the KG. It is then promoted to a DT which exports DIKW to the KG. 6
This paper has presented our insights on the issue of combining a knowledge graph (KG) layered upon an organisation's data repositories with the process of constructing Digital Twins (DTs). In particular, the components of this approach are seen in Figure 1, with an example timeline in Figure 5. These DTs, separated into historical and streaming, allow answering di erent types of queries such as about correlations, optimisations, and anomaly detection.
Our future research involves clarifying the possible work ows for creating these DTs, their possible architectures, and a classi cation of their features.
This research was supported by Flanders Make, the strategic research center for the Flemish manufacturing industry, and partially funded by the DTDesign ICON (Flanders Innovation & Entrepreneurship FM/ICON::HBC.2019.0079) project.