# Geo-Spatial Context Provision for Digital Twin Generation
## 3 A Digital Twin Architecture Linking CPS Behavior and Produced Operational Data
### Stakeholder-Centered Structuring of Environmental Context Data
It is assumed that states across the different SBDs of a process model have unique identifiers. Looking at the particularities of subject-oriented modeling, a few topics need to be considered for uniquely relating recorded events to states of SBDs. The same subject behavior can, e.g., be instantiated multiple times as part of process execution (Multi-Subjects, see [https://i2 pm.net/wp-content/uploads/2020/04/20200223-Standardbuch-PASS.pdf#page=22](https://i2 pm.net/wp-content/uploads/2020/04/20200223-Standardbuch-PASS.pdf#page=22), retrieved 4 July 2022). In cases, where multiple instances of behavior modeled in a SBD are executed in parallel, this leads to potentially multiple event tuples with the same values for \(a,c\), and \(t\). The addition of a SBD instance identifier allows to still uniquely relate events in such a case. It also supports the generation of traces not only on the level of whole process instances, but also on the level of instances of individual subject behavior part of the process instance. This way, the sequence of states that were performed (documented through events in a trace) can be showcased in relation to the options permitted in the models (one state in a SBD can occur multiple times as part of execution in case of a loop and certain modeled states might not occur in case of exclusive paths). A graphical representation of current or completed process model instances with their performed states is still required for a stakeholder-centric use of event data. Considering the digital twin thread concept outlined in Section 3.1, during each state instance (i.e., a state in the behavioral model that is currently being executed by a CPS component as part of a process instance), data can be provided by the system (component). So each state instance can potentially have associated data entries, as visualized in Figure 7 in the form of a simple UML class diagram. In this diagram, the data entry class is not further specified and left abstract, to reflect that different data can come from the system based on the scenario. For a CPS this can be sensor data (or other relevant data produced during the behavior of the system component), either captured or utilized during the respective state instance. Utilizing the general concepts for documenting process executions outlined above, a state instance can be documented through an event, with the attributes \((d_{1},v_{1}),\ldots,(d_{m},v_{m})\) of the event tuple holding the various data entries (with \(d\) denoting the data entry and \(v\) storing the data within the entry). A very basic data entry containing a description of the data entry type, a timestamp, and the associated data needs to be put into relevant context, to depict data in a specific structure. This can be realized through inheriting and specifying the abstract class, with Figure 8 showcasing a few possible data entry types concerning sensor data from the illustration case (here depicted in UML through extending the abstract data entry class). Concerning the enrichment of the behavioral model instances and their documentations with LiDAR-provided geo-spatial context information, we distinguish between different possibilities based on how much other context information concerning the CPS is directly integrated with the geo-spatial representation. The data structure highlighted in Figure 8 shows the lowest level of integration, where the raw 3D point cloud data is stored as part of one specific data entry type, and different types of context data have their own separate entry types. A higher level of semantic richness of geo-spatial context information can be achieved by storing a semantically segmented point cloud as part of a data entry. On higher levels of integration, data from previously separate data entry types is incorporated directly into a 3D representation of the operational environment, such as sensor readings being displayed next to the digital model of the physical sensor producing the data. Creating such a representation would require more computational effort.