# IoT-Driven Resilience Monitoring: Case Study of a Cyber-Physical System
## 5 Cyber-Physical System
### Energy Digital Twin: Virtual World Interactive Model
#### 5.3.5 Service Deployment  
The framework services of the SPVS architecture (see Figure 13a) were organized and distributed by following the principles of the edge cloud continuum [82] and according to the European Scope of the Cloud-Edge computing [90]. In particular, the CP infrastructure was developed in the works of [82; 91] as a testbed and features the physical asset, an on-premise edge node, and a desktop data center (as illustrated in the simplified logical schema in Figure 13b).  
By following the original approach, data monitored by the SPVS are upstreamed to the on-premise edge node, which acts as a proxy between upstream data consumers and downstream physical entities. The role of such node is to perform the preliminary data preparation pipelines, enhancing the data quality and making data available in the right format. Upstream, the desktop data center models a far edge (near-premise) data center, as presented in [90]. Offering more computational resources, this data center can perform heavy and complex analyses and predictions on relatively limited batches of data streamed by on-premise edge nodes. Following this approach, it becomes possible to implement a local-level policy decision tool, whose purpose is to perform informed decisions based on analyses, other than implementing fine-grained strategic actions. The results obtained by these strategic actions can be then translated to commands for the managed downstream physical devices.  
When required, heavier analyses can be delegated to the cloud infrastructures and eventually using the corresponding results to provide global insights and assess optimization policies on an aggregated level-scale.  
Furthermore, the high flexibility and scalability of such a distributed design fosters the development and deployment of resilient cyber-physical systems, encouraging the implementation of efficient resilience boost techniques tailored to the requirements of the specific edge-to-cloud layer that they are applied to.  
The R-KPIs encompass three key metrics, as reported in Table 3.  
\begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**R-KPI** & **Definition** & **Significance** \\ \hline
**Recovery (T)** & **Time** & **Represents the duration required for the system to recover from a disturbance occurrence.** & **Provides a quantitative measure, shedding light on the system’s ability to rebound following an event.** \\ \hline
**Functionality Loss (FL)** & **Illustrates the extent of functionality loss in the system, irrespective of the system’s behavior during degradation and recovery.** & **Offers insights into the overall impact on system functionality, encompassing both observable and latent effects.** \\ \hline \hline \end{tabular}
\end{table}
Table 3: Selected R-KPIs.  
Figure 13: Mapping of the Edge-cloud architectural framework. (**a**) Scope of the European Industrial cloud and edge Roadmap [90]. (**b**) Edge-cloud architecture of the system [82].  
The justification for employing the Minimum Performance Index underscores the challenges associated with fitting resilience curves to IoT sensor data and the intricate behavior of the system post-disturbance. This index serves as a vital reference point for decision-makers, allowing them to factor in the minimum performance crucial for the resilience of CI.