# Model-Based Virtual Components in Event-Based Controls: Linking the FMI and IEC 61499
## 3 Generic Virtual Components
### Periodic Event Mapping  
One commonly used approach for implementing the abstract representational mapping of Figure 1 is periodic synchronization. Thereby, data are periodically exchanged at discrete points in simulation time, \(t_{i}=i\cdot T_{\text{a}}\) with \(T_{\text{a}}\in\mathbb{R}^{+}\) and \(i\in\mathbb{N}_{0}\), only. For each synchronization point, an event \(e_{i}\), \(t(e_{i})=t_{i}\), which covers the model outputs, is sent to the automation system. Between two consecutive synchronization points, the model is solved independently, and no data are exchanged. In case an event \(e_{j}\) with \(t_{i}<t(e_{j})<t_{i+1}\) is triggered by the automation system, it has to be delayed until the next synchronization point \(t_{i+1}\). Likewise, any FMI event between synchronization points indicating a possible discontinuity cannot be directly transmitted because outputs are only sampled at the next synchronization point. Figure 2 illustrates the basic operation of the periodic approach.  
Although a controller may maintain its own notion of time differently from real time (e.g., in the case of a purely virtual simulation), often the virtual component needs to run according to real time. To study the timing of virtual components in more detail, the progress function \(p_{k}:\mathbb{R}\rightarrow\mathbb{R}\) is introduced, which maps the current instant of real time \(t\) to the current notion of (simulation) time of component \(k\). For the automation system AS, simply a continuous clock is assumed and \(p_{\text{AS}}(t)=t\). For an FMU, \(p_{\text{FMU}}(t)\) is controlled by the solver and may differ from the current instant of real time. Notably, \(p_{\text{FMU}}(t)\) may not be continuous because the equations are solved in discrete steps. In order to allow a timely operation, all synchronization events \(e=e_{i}\) have to be triggered in time, and the progress of every component \(k\) has to converge to:  
\[t(e)=\lim_{t\to t(e)^{-}}p_{k}(t). \tag{1}\]  
To guarantee a hard real-time operation with the idealized real-time condition (1), the Worst Case Execution Time (WCET) \(W_{\text{sol}}\) of solving one step of size \(T_{\text{a}}\) needs to be bound, and in conjunction with the communication WCET \(W_{\text{co}}\), the constraint \(W_{\text{sol}}+W_{\text{co}}<T_{\text{a}}\) has to hold. \(W_{\text{sol}}\) highly depends on the WCETs of the FMI functions, as well as the ODE solver and may not even exist. Additionally, an FMU may indicate an arbitrary number of FMI events \(n_{i}\) at step \(i\). When assuming that solving one continuous step is bound by \(W_{\text{step}}\), an event update by \(W_{\text{upd}}\), and managing the model in- and out-puts by \(W_{\text{io}}\), one can estimate \(W_{\text{sol}}\) by:  
\[W_{\text{sol}}=(n_{i}+1)\cdot W_{\text{step}}+(n_{i}+2)\cdot W_{\text{upd}}+W_ {\text{io}}. \tag{2}\]  
Note that the event update function has to be executed at the end of each continuous step and after external inputs are applied. Even if the solver and all FMI functions provide a bound WCET, the number of events \(n_{i}\) within a single step needs to be bound as well.  
Figure 2: Periodic event mapping.