# Toward a Practical Digital Twin Platform Tailored to the Requirements of Industrial Energy Systems
## 3 The Digital Twin Platform
### Data Dimension  
Generally, the data dimension holds information about five data categories according to [PERSON] et al. [72; 80] and as illustrated in Figure 2. In addition to sensor data from the physical entity (D\({}_{\text{p}}\)), model and simulation data from the virtual entity (D\({}_{\text{v}}\)), and data from the Service dimension (D\({}_{\text{s}}\)), it contains semantic data about the system and all the relationships within the DT, i.e., domain knowledge (D\({}_{\text{k}}\)), and fused data (D\({}_{\text{f}}\)) of D\({}_{\text{p}}\), D\({}_{\text{v}}\), D\({}_{\text{s}}\) and D\({}_{\text{k}}\). However, the data dimension must not only store these data but also provide semantics to it. Therefore, in our DT platform, we use a so-called knowledge graph, which is a knowledge-based system, consisting of an ontology and a built-in reasoner that is capable of acquiring and integrating external information sources [99]. This knowledge graph consists of several ontologies that hold information about plant equipment, topology, instrumentation, etc. The runtime data from the IES, which is usually stored in relational databases, is integrated into the knowledge graph via ontology-based data access (OBDA). By defining mappings between the relational database structure and the ontologies, the implicit knowledge about the data models is made explicit. Thus, the knowledge graph acts as a semantic abstraction layer [100] where data can stay in the original local database, e.g., within an SQL database of the SCADA system. Data are only loaded when accessed,which also enhances performance [101]. For more detailed information about the data access, we refer to our previous work in references [22, 63]. As a crucial methodical foundation, domain-specific ontologies have to be applied for IES. However, knowledge engineers do not need to build ontologies from scratch, but they can use and integrate existing standards that were developed in collaborative efforts among industry and academia and be conveniently created via open source tools (e.g., [102]). For our DT platform for IES, relevant ontologies include PETIont (Plant, Equipment, Topology and Instrumentation Ontology) [103], Sensor, Observation, Sample, and Actuator (SOSA) ontology [104], PQOnt (Electrical Power Quality Ontology) [105], OntoPowSys (Power System Ontology) [106], OpenEnergy [107], OntoCAPE (Ontology for Computer-aided Process Engineering) [108], and OntoEIP (Ontology for Eco-Industrial Park) [109]. Furthermore, for including information on services and virtual entity models in the knowledge graph, existing semantic web ontologies such as OWL-S (Web Ontology Language for Service) [110] and OWL-Time (Web Ontology Language of Temporal Concepts) [111], extended with Quality of Service (QoS), are considered as foundation. Domain ontologies, e.g., FMUont (Functional Mock-up Ontology) [112] and ML-Schema [113] for simulation services, are built on top, inheriting all classes and properties of the base service ontology [63]. The creation of a single generic ontology for IES is beyond the scope of this contribution. However, it has already been successfully demonstrated, e.g., by [PERSON] et al. [114], that the highly reusable terminological components of such ontologies can be (semi-)automatically merged to fit the requirements of specific applications. For the practical use of the ontology, hence instancing the concepts of it and creating the relations between them, a triplestore provides the means to store the ontology similar to a database. A semantic triple consists of three entities, namely subject, predicate and object, and represents a relation between them. This way, knowledge can be structured in a machine-readable and standardized way.