Timed-Altarica-To-Fiacre-Translator/doc/Rapport post-doc/etgts.tex

\section{Method and translation}\label{sec:sect3}

\subsection{Temporal Petri Nets}


\subsection{From AltaRica to Tina}
The underlying mathematical model of the AltaRica language is a Guarded Transition System (GTS), an automaton that generalises Reliability Block Diagrams, Markov chains and Stochastic Petri nets~\cite{rau08}. In GTS, states are represented by value assignment to variables, while the states transitions are triggered by events, that change the variables value. Synchronisation between events (habitually asynchronous) is produced by introducing a new event.

Given that it is always possible to obtain a flattened model from a
composition of interconnected AltaRica nodes, it is then possible to
interpret a (general) AltaRica model by using the GTS model encoding.
Our translation approach relies on Extended Timed Guarded Transition system, an extension of the GTS of AltaRica opportunely enriched to include timed guards.


\begin{definition}[ETGTS]\label{def:ETGTS}
  An Extended  Timed Guarded Transition System is a tuple $\langle S, s_0, E, T, \tau \rangle $ where:
  \begin{itemize}
  \item $S$ is a set of states;
    \item $s_0 \in S$ is the initial state;
  \item $E$ is a set of event symbols;
    \item $T$ is  a set of transitions s.t. $T \subseteq S \times E \times S$. 
    \item $\tau$ is the delay relation, $\tau: E \to \mathbb{R}^+ \times \mathbb{R}^+$, assigning a minimal and a maximal delay to the transitions bound to event $e$.
  \end{itemize}
  A transition $t \in T: (s, e, s')$ associates a state $s'$, to a state $s$ by executing the event $e$ in $s$, after a delay in the interval $[\delta_{min}, \delta_{max}]$ given by $\tau(e)$.
    An ETGTS defines an oriented graph, where delays can be seen as labels attached to the edges.
    
    A \emph{run}  $\rho$ of a timed Transition System is a sequence of pairs event-time from the initial state $s_0$:
    \begin{align*}
      \rho &= \{ (e_1,\delta_1), \ldots, (e_n,\delta_n)  \} \; 
      \text{s.t. } \forall i \;\delta_i \in \tau(e_i), \text{ and }\\
      &s_0 \xrightarrow{t_1} s_1 \xrightarrow{t_2}\cdots \xrightarrow{t_n} s_n, \text{ with }  \forall i \;t_i = (s_{i-1}, e_i, s_i) \in T
      \end{align*}
  \end{definition}


\begin{comment}
  %%%%start comment
\TODO{TGTS for us, as delta can be used, but not necessary}

\begin{definition}[GTS]\label{def:GTS}
  A GTS is a tuple $\langle V,E,T, A, \nu \rangle $ where:
  \begin{itemize}
  \item $V$ is a set of variables, divided in two sets of variables: the set $S$ of \emph{state variables}, and $F$ of \emph{flow variables} s.t. $V = S \cup F.$
  \item $E$ is a set of event symbols
    \item $T$ is  a set of transitions, s.t. $t \equiv (\gamma, e, \varphi) \in T$ with $e \in E$, $\gamma$ and $\varphi$ are Boolean  expressions built over $V$ called \emph{guard} and \emph{post-condition} resp. A transition $t$ applies in a state $s \in 2^{|V|}$ s.t. $s \models \gamma$, resulting in a state $s' \models \varphi$.
    \item $A$ is the set of \emph{assertions}, i.e.  Boolean expressions built over $V$. Assertions are concatenated to each transition, in order to update flow variables, \TODO{modelling the failure propagation. }
    \item $\nu$ is the initial assignment of variables of $V$.
  \end{itemize}
  \end{definition}

\TODO{1) define the semantics of a transition, i.e. how to pass from a state $\sigma$ to a state $\rho$. 2) define a trace in the timed graph, with events labelled by the firing time, i.e. a plan for Tina}

A GTS is a (possibly infinite) graph $\Gamma = (\Sigma, \Theta)$, where $\Sigma$ is a set of nodes given by all the possible variable assignments in $V$, and $\Theta$ is a set of guarded transitions $(\sigma, e, \rho)$, where $\sigma, \rho \in \Sigma$ and $e \in E$.

blocks and processes, from the GTS to the Petri Net (states, places, tokens).

\begin{definition}[Temporal GTS]\label{TTGTS}
\TODO{Timed GTS already exist, we can use another name to avoid confusion}
A Temporal Guarded Transition System is a tuple $\langle V,E,T, A,\nu, \Delta \rangle$ where
  \begin{itemize}
  \item $\langle V,E,T, A, \nu \rangle $ is a GTS defined as in Def.~\ref{def:GTS}
  \item $\Delta$ is a delay function s.t. $\Delta: E \to \mathbb{R}^+ \times \mathbb{R}^+$, assigning an initial and a final firing time to the transitions bound to event $e$.
  \end{itemize}
\end{definition}


\TODO{Next paragraph is possibly untrue, as TGTS can be modified such to include delay \emph{functions} as we did with Fiacre and Petri Nets. We can say that these delays are instantaneous, when we aim at timed guards}
However, the limitation of the GTS formalism resides in the lack of expressivity wrt the delays in failure propagation.
In timed Guarded Transition Systems -- an extension of GTSs -- a delay function is associated to each event, indicating the date when the event occurs. However,  the propagation of messages, as failures, dealt by assertions, are not included in the (state) transitions that are delayed.

in the case of flow variables, they are updated in AltaRica simultaneously, as they represent the instantaneous propagation of a message in a system. Here, adding delays in such transitions, cannot be directly done within the AltaRica models, so we had to hack it.
We introduced \say{delay buffers}, which, in the AltaRica modelling, have a flow variable as input, a delayed state transition, and an output, which value depends on the state variable, which has been updated only after a delay. See Fig.~\ref{fig:delay-buffer}


\end{comment}
%%%%%% end comment}
Thus, a Temporal Extended GTS models a graph with transitions labelled by events and by time.



It is easy to see from Def.~\ref{def:ETGTS} and Def.~\ref{def:PN} that any Petri Net can be modelled as a GTS~\cite{rau08}. % Any GTS in Petri Net?

The extension to temporal guards on the transitions expressed by the ETGTS falls out of the AltaRica expressiveness, so cannot be captured nor analysed by its associated tool, which can treat time as a set of delay assignment, i.e. with a fixed delay associated to each transition.
Thus, the aforedefined Extended Temporal GTS is obtained from the AltaRica DataFlow model, by enriching it the syntax for temporal guarded transitions, i.e. by adding delays as defined in Def.~\ref{def:ETGTS} to the transitions in a new event law.

AltaRica separates flow variables and state variables.
% State variables are modified by transitions, i.e. explicit changes of system configuration.
%
Delayed transitions affecting state variables are trivially extended to include a temporal interval in the guard matching the non-deterministic delay we plan to add. Flow variables are updated by assertions in AltaRica models, but this distinction between variables  does not appear in the associated  GTS; thus, in order to assign delays assertions, a auxiliary state variables and transitions are used to create a (delayed) state transition.


%%%% Comment on how do we create a buffered block to transmit faults
\begin{comment}
While transitions affecting the state variables updates support a direct expression of the delay in AltaRica (and hence in ETGTS as well), flow variables are updated by assertions, that natively do not support delays. To express a delayed failure affecting an input/output variable (a flow variable) auxiliary state variables and transitions have to be used to model the delay and the failure buffer. Thus, a delay element will depend on three parameters $(k, \delta_1, \delta_2)$, where $\delta_1$ and $\delta_2$ are indicate the minimal and the maximal delay (resp.), and $k$ indicates the maximal buffer for the element.

\TODO{Following example is useless, as it has been explained clearly in the former sentence}
\subsubsection{Example}
Given a failure propagation represented by a flow variable $v$ as input $v_i$ of an element, the assertion $a$ updating these values would be such that $v_i = v$. To introduce a  delay between $d_e$ and $d_e'$, we add to the AltaRica model two auxiliary state variables $w, w'$, and two new events $e$ and $e'$.
The event $e$ is instantaneous s.t. $\Delta(e_d) = (d_e, d_e')$, and the resulting transition assigns $w = v$.
The event $e_d$ is delayed s.t. $\Delta(e_d) = (d_e, d_e')$, and the resulting transition assigns $w' = w$.
The following assignments are added as assertions: $a': w' = w$, $a'': v_i = w'$. The result is delay of a value comprised in the interval $[d_e, d_e']$ between the assignment $w = v$, and the propagation to change the value of $v_i$.

In OCAS, to produce such a model, N delay elements has to be created, with N the size of the buffer. This is automatised in our tool-chain, as the code corresponding to the delay element for $(k, \delta_1, \delta_2)$ is generated in Fiacre from the AltaRica code (where only the delay is indicated, while the buffer size $k$ is calculated from the elements uphill.
% NB: We can say that if the value v is new, THEN we update w. but can be more confusing.
\end{comment}
%%% end comment



\subsection{From Timed GTS to Timed Petri Nets}
\TODO{1) Get definition of timed Petri Nets, 2) define the translation\\}
We build a state $s_0$, s.t. for each transition $t \in T$ in the TGTS, a transition $t \circ a$ from $s_0$ to $s_0$ is added in the TPN. Eventual delays are maintained.
It is easy to see that such transitions affect state variables only, while flow variables are updated simultaneously only if are kept, possibly adding them a delay. (dessin de la fleur)


For each delayed transition affecting a flow variable, e.g. a delay in the failure propagation in our example, we add a new element working as a buffer delaying the input messages.


Introducing the delay, synchronisation, and new states
1) first in OCAS;
2) AltaRica code generated with timed transitions;
3) Fiacre code, with temporal guards (from the timed transitions expressed before).

Equivalence between the AltaRica models with no stochastic information, i.e. in Fiacre probabilities are abstracted away. Trivial to see that, when guards on transitions are conserved. Then, the time information is not part of the AltaRica models, and has there been artificially introduced for our purpose of taking trace of it during the translation. (taking trace of the transition names, for traceability purpose).





%%  LocalWords:  TGTS Fiacre DataFlow OCAS ETGTS