# 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  
In the described use case, the robot uses the scanner periodically as part of its tasks to assess its surroundings. The data provided by the scanner is used as a source for deriving  
Figure 5: Vaccine logistics illustration case - Interaction between different components during transport preparation. Figure 6: Vaccine logistics illustration case - Robot behavior during step 4 of transport preparation process (selection of a sensor). contextual information to dynamically adjust the robot's behavior to its environment. In the proposed digital twin architecture, another core purpose of these data are to save and integrate it with other information to create a representation of the CPS in a way that it supports process stakeholders. The results of scans can be periodically saved to create a timeline of how the operational environment of the CPS has changed, with the different objects (the robot, vaccine packages, sensors, transport boxes) moving/being moved and leaving/entering the area. From this information, a digital twin of the CPS environment is created that can be used to document and assess these environmental states and changes for different purposes (monitoring, auditing,...). We have already described situations in Section 2.2 where process participants may need to access this information. There exist other information sources as well. The room outlined as part of our proposed set-up is equipped with different sensors, with the integration of the produced information promising to create an even more complete picture of the operational environment at certain points in time. We propose the use of the behavioral twins of the CPS components outlined above (i.e., the executable, synchronized process models) to structure both the captured geo-spatial context and the information produced by other components. This integration is realized through associating the information provided by certain scans with the concrete steps in the process model during which these scans occur (or during which they are used) as an instance of the behavior model is executed synchronously with the system component showcasing the behavior. We describe the envisioned structure of information for process model instances independently from details of concrete execution engines. The focus is on the basic elements of subject-oriented process models (specifically considering behavior diagrams) and using generic concepts for documenting the execution of processes. In the context of process monitoring (see [32] for the formal definitions of the terms used in this paragraph), various information regarding the execution of a process instance is generally recorded in the form of an event. An event was defined in [32] as a tuple \((a,c,t,(a_{1},v_{1}),\ldots,(a_{m},v_{m}))\), with \(a\) being the activity name (in the case of subject-oriented models this would refer to a state of a SBD), \(c\) is the case identifier (i.e., referring to a process instance), \(t\) is the timestamp (in [33] both start and end timestamps are listed) and \((d_{1},v_{1}),\ldots,(d_{m},v_{m})\) (where \(m\geq~{}0\)) denote event attributes, with their names and values. The events that are generated by a process instance are referred to as a trace, with a so-called event log storing all completed traces pertaining to a process model. These concepts already provide a framework for documenting relevant process data, such as timestamps for start and end times (cf. [33], where end times from event logs are used for remaining time prediction). The event attributes allow for the storage of various data produced during a process. Completed traces stored in the form of an event log document previous process instance executions. Furthermore, traces that are in the process of being recorded document an ongoing process instance execution. By the activity name stored with an event, event data is set in relation to the model from which the process instance was created.