E2E Protocol and APIs
E2E is a crucial part of functional safety, as it protects communication. Learn in this article the E2E profiles, state machine and APIs
Validating the messages received from other parts of the vehicle and ensuring the messages your Autosar ECU sends are valid is crucial for functional safety. The last thing you want is to react to faulty inputs, and you probably have heard the saying "garbage in, garbage out". Therefore, E2E is crucial to process the received signals and validate them, in order to proceed further.
We already went through the most common communication faults and what E2E does (on a higher level) to increase communication robustness, in E2E Protection Overview (opens in a new tab). So, today we'll take it a step further and dive into how the communication protection is done, with the E2E profiles, the E2E state machine and the APIs available for you to use in Autosar applications.
E2E prides itself in being a good fit for a wide range of application needs, by providing us with a variety of E2E profiles, which are variations on the E2E standard and define different protection mechanisms, message formats and a set of configuration parameters. There are also some E2E profiles which define a set of standard parameters of a specific E2E profile, making your life even easier, by not having to worry about the "what goes where?" in your protected messages. As a side note, you can also build your own safety protocols (which can be required specifically by your OEM or customer), through a set of APIs provided by E2E.
E2E protection will, in essence, add an E2E header to the messages you are trying to send, embedding mechanisms such as a CRC and sequence counter and parse those fields in the opposite direction, when you receive a message, comparing those fields to their expected counterparts and therefore confirming if a message was valid or if something went wrong in the reception. Aside from the profiles, some of the aforementioned mechanisms are also embedded on the RTE and COM, but they are not considered, in order to avoid the allocation of safety requirements to them.
The specific protection mechanisms and and E2E header are defined by the chosen E2E profile. Each of them provides a different means of protection, using different algorithms, although, the interfaces and behavior are similar throughout all profiles. But how do you choose one? Well, each profile was designed with the intent of a specific communication protocol, such as CAN (if you want to learn more about CAN, please check our article CAN Protocol Overview (opens in a new tab)), CAN-FD, Ethernet of FlexRay (if you need a refresher or you want to learn about this protocol for the first time, you can read What is FlexRay (opens in a new tab)). E2E can also be used in intra or inter-ECU communication. Another thing to keep in mind, is that the E2E Supervision implementation is not required to implement all E2E profiles, but only a subset of them. This will narrow down your choices.
Now, we will not go through each individual E2E profile in this article. We'll cover that in a different article, as there are a lot of them. We will go into detail of the E2E profile one, so you get a glimpse of what you have at your disposal.
So, when it comes to the E2E profile 1, the mechanisms are: 4-bit sequence and alive counters (incremented on every request), timeout monitoring, 16-bit unique data identifier (covered by the CRC calculation) and CRC (with a different polynomial than the ones used by the underlying protocols)
With the mechanisms selected, one covers repetition, incorrect sequence (counters), loss, blocking (counters and timeout monitoring), insertion (counters and Data ID + CRC), delay (timeout monitoring), masquerade and incorrect addressing (Data ID + CRC), corruption and asymmetric information (CRC).
There is more to this, but again, we'll cover it in another article, as this can become quite an extensive topic.
Now, to the E2E state machine. Its main purpose is to evaluate the protection state and decide if the data received can be used, based on a bigger picture, by evaluating a wide number of results of the E2E profile checking functions, within a defined window (called reception window), with the result being provided to the other modules in the Autosar Stack (RTE, Software Components and COM). The state machine is applicable to all E2E profiles. Using the E2E state machine together with an E2E profile will provide different and more reliable results than using the E2E profile alone. You can see the E2E state machine below:
E2E state machine
The API specification is quite simple, as there are only four APIs, which are divided into middleware, the APIs provided to the rest of the application (such as the RTE), where E2E provides an extra output, the E2E checking results. On the other hand, there are the APIs used between the middleware and E2E, one for each communication direction. Let's look at these for API's:
-
middleware_send(in dataRecord) - Message used by the middleware to send E2E protected messages. The only necessary parameter is the dataRecord to be protected
-
middleware_receive(out dataRecord, out e2eResult) - provides you the received data and the result of the E2E evaluation. The e2eResult contains two pieces of information: the e2eStatus, which is the profile-independent status of this dataRecord (OK, REPEATED, WRONGSEQUENCE, NOTAVAILABLE or NONEWDATA) and e2eState, which is the status of the communication channel that exchanges the data (VALID, DEINIT, NODATA, INIT or INVALID)
-
E2E_check(in dataID, inout serializedData) - evaluates the received E2E header of the data
-
E2E_protect(in dataID, inout serializedData): e2eResult - protects the input data, by addind the E2E header to the message to be sent
Alright, that's all we have for today, regarding E2E. We covered quite a lot, so you should be able to start protecting the communication and trust the messages you received a bit better. See you next time, when we cover the E2E profiles further!
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn