Digital Twin Development Framework
Digital Twin (DT) was first introduced in aerospace field by NASA as “an integrated multi-physics, multiscale simulaion of a vehicle or system that uses the best available physical models, sensor updates, fleet history, ect., to mirror the life of its correspondin flying twin”.
The attributes of DT that allow real-time field data management, bi-directional communication between physical and virtual representation, and integration with data analytics and the advanced visualisation techniques make DT becomes one of the most promising enabling technologies for realising ‘Industrie 4.0’.
Funded by EPSRC research grant, DigiTOP (Digital toolkit for optimisation of operators and technology in manufacturing partnerships) project develops a guideline for DT implementation to enable industries in different sectors harnessing the power of digitalisation to their own business benefits.
This repository is structured as follows:
1.The figure below is an overview of the DT building steps
2. The example of how this guideline is applied to create a DT is provided in Digital twin step by step and for more detail information please refer to the Digital Twin development: A step by step guideline paper.
4. Please see below for further development in the design of an adaptive DT data framework (e.g. to sustain the change of DT when its physical counterpart evolves). Please refer to A Design Framework for Adaptive Digital Twins paper for further details.
Ontology Based Design Framework for Adaptive Digital Twin's
The design framework determines the steps to generate or update ontologies, so that diverse DT software can communicate with each other using a common language. Such language should describe every KD to be considered in an asset’s life-cycle. Besides, it should also include unique references for every object to be part of an asset.
These are why this design framework consists of two main stages. The first one, only to be conducted once, enables to uniquely declare any possible asset’s part, including those to be modified over the asset’s life-cycle. The second stage enables to generate interfaces for each new DT software to be incorporated. These may include new information regarding existing or new assets’ life-cycle KD. This stage is where the design change requirements are captured, and a suitable DT data architecture is developed. In order to quantitatively evaluate modifications of ontology-based data architectures, the following definitions are used: (1) variety (number of attributes and/or relationships to modify/update), (2) volume (number of individuals to modify or update when assigning new attributes/relations), and (3)
velocity (number of interfaces to update due to asset’s evolution).
Stage 1: asset description for adaptive DT
In order for diverse DT software to exchange data consistently, it is necessary to declare unique references for every possible object (e.g. component or sensor) that is part of an asset. So, the changes experienced (e.g. replacement) over the asset’s life-cycle can be tracked.
This stage includes the following steps:
Step 1: Identify all possible hierarchical levels the asset can consist of and declare these as classes.
Step 2: Declare all necessary hierarchical relationships to correlate these classes.
Step 3: Declare all necessary attributes to identify assets’ parts temporality (e.g. disposal).
Step 4: Determine a standard to name every object, so they can have unique references (e.g. spare part). Although, the ontology elements may be subject to change, the number of attributes and relationships assigned for each class should not vary. If so, every time an asset’s part is modified, any existing or new DT software can keep track of it. Consequently, additional information regarding an asset and its parts should be allocated in separate ontologies as described in Stage 2.
Please refer to A Design Framework for Adaptive Digital Twins paper for further details.