FuSa Autosar E2E: What's your recovery strategy ?
Every time you introduce a new mechanism, you shall define a strategy for exiting the condition gracefully.
Autosar E2E Protocol Specification defines mechanisms to detect faults related to communication, covering lower communication layers and hardware. This help to standardize safety mechanism for faults.
The specification provides multiple profiles that could be used. Profiles would be based on your system (e.g. based on Safety Concept). Between profiles Counter, DataId and CRC checksum are common. Some profiles have added or timeout detections. One subtle difference is, although the fields are the same, the field size varies.
Field Size Impact
To understand the impact of field size, let understand what CRC is. Cyclic Redundancy Check (CRC) is an error-detecting code used to detect accidental changes to raw data during transmission or storage.
CRC in general improves error detection, but how does its size matters ?
To detect an error in a message, a CRC value is provided along with the message. The receiver shall calculate the CRC again and compare the CRC received. The critical factor is the value of CRC shall be always unique for all possible combinations of the message. If you consider the CRC is of 8bit and message is of 4 bytes long, you have very high probability that CRC no will not repeat for combinations. Extending this further, if 8-Bit CRC is used to calculate a message of 1000 bytes, you now have very high probability the CRC value will get repeated, low probability and low error detection.
You shall select sufficient length of CRC to ensure high detection capability, hence we choose the field size appropriately.
Counters
Counter field in profiles provide a ways to detect - Repetition, Ok and Error states. Once the counter is filled, its rollovers. Different profiles give you the option to select the size of counter. Example, in profile 1 the counter size is 0xF whereas profile 4m will roll over at 0xFFFF.
To understand how rollover effects, consider some CAN message fault scenarios.
Signal lost - Once
Sender and Receiver, both at counter 4
Receiver missed the one message due to some issue on the bus
Receiver is expecting msg with counter value as 5.
Till value 5, all messages would be categorized as Error for receiver.
Receiver will be in Ok state once rollover happens and next message with 5 value is received.
If we assume the cyclic message is with 10mSec. Resync will happen after 0xF*10msec.
For profile 4m this will be 0xFFFF * 10mSec.
The above example considers only 1 scenario of CAN fault and a functional requirement to wait till valid counter value is received.
Expand this further to consider all the CAN fault scenarios: No first message, random drops, multiple disconnects, total disconnect.
Summary
E2E provides a way to detect fault, further analysis in your system is required to ensure the system can always recover on its own when the condition is cleared. To build a robust system you will need to map all the communication bus faults with recovery strategies like, resync with each message, resync up to certain count (also defined in some profiles) and further…
It is very easy to put conditions to enter fault state, getting out is harder. This is often closely associated with race conditions, which are hard to debug.
In case of functional safety, you need to additionally consider from FTTI perspective. E.g. if recovery is happening at rollover, does it comply with FTTI timing. If not change recovery strategy or enter directly into safe state (system very sensitive) or exit after stabilization/debounce period.
TLDR;
Choose E2E profile based on data/error detection requirement.
Analyze all the faults, and define exit criteria
In transition, consider the impact on modules when faults are detection. What should be their state and/or reaction.