# Error Recovery in the Time-Triggered Paradigm with FTT-CAN
## 7 Implementation Issues and Extension  
In our proposal, the achievement of high reliability imposes that the Master node must be capable of detecting all bus errors to reschedule messages affected by errors. Due to the error signaling mechanisms of CAN, this is true most of the times, but can fail in rare scenarios, causing Inconsistent Message Omission, as described by [PERSON] [37], where some nodes receive correctly a message, while others do not. As in the synchronous window the native CAN's automatic retransmission mechanism is disabled, the probability of encountering this scenario becomes significantly higher [19], thus decreasing the global reliability level.  
To solve this problem, a possible solution is to scan individually the last bits of the CAN frame (last bit of EOF and following three bits of the IFS field) and, if a dominant value is read there, the master node considers that an error, changing this way the CAN rule in interpreting these bit values. This new error detection mechanism can only fail if four errors hit these last four bits. When considering single bit errors, even in an aggressive environment, this scenario has a probability much lower than the \(10^{-9}\) incidents per hour ultra-reliability number. This feature is relatively simple to implement using, for example, a small FPGA and it would have to reside in the Master node, only.  
In the proposed mechanism, when an error occurs, the Master needs to request the transmission of multiple replicas. However, the protocol defines that the _TM_ message encodes the transmission request of each message in only one bit (see Figure 1) and due to the limited payload of CAN messages (maximum of 8 bytes) there is not enough space in the _TM_ to add information on the number of replicas to transmit. Thus, the FTT-CAN protocol must be adapted to deal with this situation. We propose adding another message, called _TM_Ret_, that is transmitted only in ECs in which there are replicated messages. The _TM_Ret_ payload is coded as follows:  
* 1 byte per message to retransmit; and,
* each byte is composed of two segments--2 bits to encode the number of replicas (00, 01, 10, 11 for two, three, four, or five replicas, respectively) and 6 bits to encode the message ID.  
The use of _TM_Ret_ with the referred transmission rules and coding scheme minimizes the extra traffic transmitted by the Master. This mechanism also has the advantage of being fully compatible with legacy nodes that do not transmit critical messages. To take advantage of the proposed error recovery mechanism, slave nodes have to adjust the FTT-CAN stack to receive and interpret the _TM_Ret_ and act accordingly. Also, this message has an impact on the maximum LSW available and on the timeliness of aperiodic messages.  
Finally, our mechanism is also compatible with the recent CAN-FD [7] protocol that is increasingly gaining acceptance. In this case, since the payload can be longer, up to 64 bytes, the referred _TM_Ret_ is not needed and its information can be transmitted in additional bytes of a normal TM message, being this is a more bandwidth efficient approach.  
Figure 12: Bandwidth required by each method (with LEC = 2.5 ms and \(\lambda\) = 0.26).