# Error Recovery in the Time-Triggered Paradigm with FTT-CAN
## 6 Results and Discussion
### Comparison with Other Methods  
The work in [19] presented another error recovery method for FTT-CAN, based on the native CAN automatic retransmission of messages affected by errors (named _Automatic Retransmission_ in Table 6). The mechanism reserves extra time in every SW for the recovery of eventual errors. However, this extra time is left unused in the absence of errors, and is thus less efficient than our proposal (named _Controlled Retransmission_ in Table 6). For instance, when considering the fault model presented in this paper and an Aggressive environment, the _Updated_SAE_ benchmark message set with the _Automatic Retransmission_ mechanism would require space for four retransmissions in every EC. This represents a constant bandwidth of 25.2% (or 12.6% for the other message sets, which have LEC equal to 5 ms). Conversely, our _Controlled Retransmission_ mechanism consumes an average bandwidth that is less than the bandwidth of the error server (thirty six maximum messages (3 \(\times\) 12) in the server period, configured, as described earlier with \(T_{S}=1/\lambda\)), which is only 0.108% in this case. The method presented by [PERSON] et al. [15] implies the use of a fixed number of replicas per message period, and is applied in a TDMA fashion (named _Static TT_ in Table 6). The number of replicas is found by applying Equation (1), for a defined mission reliability goal. For the three referred benchmarks and with a global reliability of 1-10\({}^{-9}\), we need to send always four copies of each message (more than 300% overhead accounting for error signaling). The three extra messages sent and their transmission time is always wasted when there are no errors (which is the most common scenario, for the considered BER). This happens because the scheduling is static and needs to cope with every error, without knowing when they will occur. Thus, enough message copies are sent to get a probabilistic assurance that the reliability goal is attained. This is clearly in opposition to our proposal where the bandwidth is only used when needed, i.e., when errors do occur. As shown in Table 6, this method requires a minimum LSW similar to our method for the lightest set (_VEIL_). However, for a set with medium bandwidth utilization (_PSA_), our method already requires a minimum LSW that is 32.4% less than required by [PERSON]'s method. For the set with higher utilization (_Updated_SAE_) [PERSON]'s method cannot even generate a schedulable solution. Comparing the bandwidth overhead of 15,1% and 29.5% for the two other sets (that corresponds always to more than 300% increase when referenced to each message set utilization bandwidth), with the reserved bandwidth of less than 0.11% used by our method is even more revealing. Further, using the results available in the statistic files of the performed simulations (view Section 6.1), the bandwidth that was used in the recovery process was also calculated. The average value found was very low, being 0.00047%, 0.00093%, and 0.0025% of the available bandwidth for the _VEIL_, _PSA_, and _Updated_SAE_ benchmarks, respectively. These values are much lower than the bandwidth configuration server values of 0.105% and 0.108%, as the full server capacity was never used. Nevertheless, our approach consists of detecting errors by the end of the EC and scheduling retransmissions in the following EC, which leads to an error recovery latency of one EC. Conversely, both the other methods allow error recovery in the EC in which they occur, thus being faster. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline  & \multicolumn{2}{c}{**Minimum LSW**} & \multicolumn{3}{c}{**Configuration BW**} \\ \hline
**Message set** & VEIL & PSA & Updated\_SAE & VEIL & PSA & Updated\_SAE \\ Controlled Retransmission & 23.8\% & 28.0\% & **55.1\%** & **0.105\%** & **0.105\%** & **0.108\%** \\ Automatic Retransmission & **19.8\%** & **24.5\%** & 60.0\% & 12.6\% & 12.6\% & 25.2\% \\ Static TT & 22.3\% & 41.4\% & X & 15.1\% & 29.5\% & X \\ \hline \hline \end{tabular}
\end{table}