E2EXf - How to Use E2E Transformers in Autosar

In the realm of Autosar, the E2E Transformer, known as E2EXf, plays a pivotal role as a safety guardian, ensuring the protected communication of I-Signals, adding elements to them to validate that reach their destination intact. These elements range from sequence counters, to CRCs, among other techniques. To grasp the intricacies of this transformer, a preliminary exploration of the E2E internals is recommended. Although not mandatory, it provides valuable context for understanding E2E profiles, which we will delve into shortly. Luckily, you have come to the right place! We advise you to start by reading our post E2E Protection Overview (opens in a new tab).

Serialization and E2E Protection

In the serialization process, E2E doesn't encapsulate entire I-PDUs; instead, it focuses on individual data elements within each signal or signal group. As part of its duty, the E2E transformer relies on the E2E library to apply protection measures, leveraging the configurations set in ARXML for the modeling of the I-Signals.

Configuration Properties

The E2E transformer's configuration resides in three key properties:

• E2ETransformationDescription: Defines E2E configuration profiles (variants) for multiple I-Signals.
• E2ETransformationISignalProps: Specifies E2E configuration for a specific I-Signal.
• E2ETransformationComSpecProps: Overrides configuration options for the port where the ReceiverComSpec belongs. This property holds precedence, allowing adjustments of tolerances for the state machine and the ability to disable the E2E check entirely for individual Software Components.

As these containers are a bit too large, we will follow this article with an in-depth overview of all the parameters required to configure an E2E profile and how it intertwines with the I-Signals. Based on these properties, the structures like E2EXf_ConfigStruct_<variant_name> are populated with references to E2E_<profile_name>ConfigType and E2E_SMConfigType.

Abstracted Functionality with RTE

The E2E functionality is intentionally abstracted from the user by the RTE. This abstraction ensures that the caller of the transformer doesn't need in-depth knowledge of E2E internals. The transformer, in turn, adeptly manages the coordination of E2E configuration and state variables with E2E library operations, including protect, check, forward, and state machine. In essence, this approach is more streamlined than having to develop source code in order to interact with the E2E library. Moreover, this approach is still pretty recent. Odds are if you have employed E2E protection in the past, you have done it the old-fashioned way, as described in our article E2E Protocol and APIs (opens in a new tab).

Moreover, the RTE can invoke the E2E transformer seamlessly in the context of various operations such as Rte_Write/Rte_Read, Rte_IWrite/Rte_IRead, Rte_Send/Rte_Receive, and Rte_Call/Rte_Result. However, it's essential to note a significant limitation: the E2E transformer mechanism lacks the ability to report to the DEM (Diagnostic Event Manager) in case of errors. If you do not know why this is important, you can check the usefulness of the DEM by reading our post DEM Overview (opens in a new tab).

Runtime Behavior and Initialization

The E2E transformer module is initialized via the E2EXf_Init function, which takes on the responsibility of initializing state data resources for protection and protection checking. This includes calls to E2E_<profile_name>ProtectInit, E2E_<profile_name>CheckInit, and E2E_<profile_name>SMCheckInit.

During initialization, the E2EXf_Init sets the transformer initialization state to true. Conversely, during deinitialization, it sets the state to false. If an E2EXf API is called when the initialization state is not true, the API will fail, returning E_SAFETY_HARD_RUNTIMEERROR.

In-Place or Out-of-Place Buffering

The remaining E2E transformer operations unfold through in-place or out-of-place buffering, dictated by the BufferProperties.inPlace property. For each data element and client-server operation requiring E2E protection, the E2EXf_<transformer_id> protect function is generated. This function, or macro through optimizations, internally calls E2E_Protect with the required parameters.

On the receiver side, the inverse transformation occurs with E2EXf_Inv<transformer_id>, internally invoking E2E library APIs for checking, mapping status to the state machine, and performing the necessary checks.

In essence, the E2E Transformer (E2EXf) stands as a guardian, ensuring the information conveyed by an I-Signal remains intact in its traversal throughout the communication mediums provied by Autosar, and it does so in such an elegant way that its preceding approach could not.

Author: Micael Coutinho (opens in a new tab)

References:

• Specification of Module E2E Transformer (opens in a new tab)