ECU Inter-processor data communication End to End

verification in Autosar for achieving Functional Safety

Goals

Jagadish Narayan Gowda

General Motors Technical Centre India
3rd Floor Creator Building, ITPL, Whitefield-5600066
+919900211251
jagadish.gowda@gm.com

Copyright © 2019 by Jagadish Narayan Gowda. Permission granted to INCOSE to publish and use.

Abstract
Safety is absence of unreasonable risk. Functional safety emphasis to handle unintended behavior of
the system. ISO26262 recommends the process and development of electrical components in auto-
motive vehicle weighing less than 3000kg. Features are assigned with Automotive safety integrate
levels (ASIL) A,B,C and D by performing Hazard Analysis and Risk Assignment(HARA). ISO
26262 recommends integrity of data communicated between sender and receiver components which
handles data associated with ASIL features. This is achieved by developing each software or
hardware components in compliance with ISO26262 ASIL recommended process and implementa-
tion. The process requires lot of effort to develop and validate each software component as per
ISO26262 recommendations. This is more challenging when data integrity needs to be maintained
between sender and receiver components which resides on two different microprocessors in the ECU.
Also, it is more challenging to achieve freedom from interference between QM (quality managed)
and ASIL feature software with in the software or hardware components. This paper detailed the
decomposition of ASIL as per ISO- 26262 and exploring the end to end verification methods in
AUTOSAR (Automotive Open System Architecture) to achieve safety goals. This paper considers
achieving data integrity between two microprocessors in infotainment. This paper highlights the
software components on sender and receiver that must comply to ISO26262 and recommendations,
instead of developing all software and hardware components as per ISO 26262.

Introduction
Advanced automotive systems provide enhanced vehicle functionality, fuel efficiency, safety, driver
assistance, comfort, ride/handling and performance. It can be comprised of electrical/electronic
sensors, embedded controllers, actuators and communication devices. Many of these systems are
software intensive. Some of these systems can autonomously activate independent of the driver.
Unintended behaviors in some of these systems can be a potential safety concern under certain
conditions. Such systems are considered safety critical systems. Safety-critical systems require dis-
ciplined and comprehensive engineering effort to identify safety related risks and eliminate or control
them. Need to address both systematic and random issues in the design. ISO 26262 recommends the
process, implementation and best practices to address safety analysis to avoid unreasonable risk.
ISO 26262 recommends integrity between lower ASIL level features do not interfere with higher
ASIL level features. AUTOSAR OS (Operating System) allows creation of multiple OS applications
that can operate in their own memory space. One application cannot access the memory partition
allocated to another application. This is known as memory partitioning which is one of the faults
addressed by freedom from interference below.

Reference to ISO/FDIS 26262-6:2018(E) Annex D to ensure “Freedom from Interference”, faults

must be addressed in the following areas:
▪ Timing and Execution
▪ Memory
▪ Exchange of Information

ASIL rating for Display or Infotainment system

Driver information ECU which displays safety critical information are instrument panel cluster,
Head’s up display and Rear-view camera is assigned with highest ASIL level B features. In VCS
(Virtual Cockpit System) where multiple displays including center stack are controlled from single
ECU considered for ASIL level B.

Freedom from Interference – Exchange of Information

In Advanced infotainment system, the ECU consists of two microprocessors.

• Vehicle Processor (VP)which is connected to system bus like CAN , LIN etc to process and
compute vehicle information like fuel, Engine speed etc for display for driver information.
• Graphical Processor (GP) which handles one or more displays, decoding display information
and rendering the graphics.
Safety critical information like PRNDL, ABS etc, the data is received from CAN by vehicle pro-
cessor and sent to graphical processor using inter processor protocol on UART or SPI channel.
In a detailed end-to-end path analysis for safety data, two communication paths are identified
• CAN network through which vehicle information is exchanged between ECUs
• Communication channel between VP and GP where data exchanged between two processor
In this paper will address to achieve the secure data exchange between two microprocessors using
Autosar tool.

Functional safety and communication

With respect to the exchange of information in safety-related systems, the mechanisms for the
in-time detection of causes for faults, or effects of faults as listed below, can be used to design
suitable safety concepts, e.g. to achieve freedom from interference between system elements sharing
a common communication infrastructure.
• repetition of information;
• loss of information;
• delay of information;
• insertion of information;
• masquerade or incorrect addressing of information;
• incorrect sequence of information;
• corruption of information;
• asymmetric information sent from a sender to multiple receivers
• information from a sender received by only a subset of the receivers
• blocking access to a communication channel
 Decomposition of ASIL B concept

As per section 5.4.9 of ISO/FDIS 26262-9:2018(E), ASIL B can be decomposed as QM(B) and ASIL
B. Component which handles the communication of data between vehicle processor (VP) and
graphical processor (GP) to develop as QM(B). And autosar E2E (End to End) component which
diagnoses the communication fault to develop as ASIL B. Below is the architectural view of the data
communication between VP and GP for functional safety data.

Vehicle Processor Graphical Processor

ASIL B

QM

Figure 1.0 : ASIL B decomposition

• A diagnostic component is an AUTOSAR E2E component at application level manages error

detection and error handling related to message transmission and reception (detection of
message loss/corruption, retransmission etc).
• Diagnostic component is developed as per ASIL integrity level process.
• ECC (Error Correction Code) and RAM (Random Access Memory) tests, memory protec-
tion and program sequence monitoring applicable to diagnostic component.
• Communication stack (Com Layer2 and 3) and physical layer is developed as QM.

Autosar E2E Functional Overview

The concept of E2E communication protection assumes that safety-related data exchange shall be
protected at runtime against the effects of faults on the communication link. Faults detected between
sender and a receiver using E2E communication protection include systematic software faults, such
as faults that are introduced on the lower communication layers of sender or receiver, and random
hardware faults introduced by the MCU hardware, communication peripherals, transceivers, com-
munication lines or other communication infrastructure.

The algorithms of protection mechanisms are implemented in the E2E Library. The E2E Profiles can
be used for both inter and intra ECU communication. The E2E profiles were specified for specific
communication infrastructure, such as CAN, CAN FD, FlexRay, LIN, Ethernet.

Sources of faults in E2E communication

E2E communication protection aims to detect and mitigate the causes for or effects of communica-
tion faults arising from:
• (systematic) software faults,
• (random) hardware faults,
 • transient faults due to external influences.

E2E communication protection works as follows

• Sender: addition of control fields like CRC or counter to the transmitted data;
• Receiver: evaluation of the control fields from the received data, calculation of
control fields (e.g. CRC calculation on the received data), comparison of calculated
control fields with an expected/received content.

Figure 1.1: Safety protocol concept (with exemplary location of the E2E header)

Each E2E Profile has a specific set of control fields with a specific functional behavior
and with specific properties for the detection of communication faults.

Mechanisms:

The E2E profiles provide a consistent set of data protection mechanisms, designed to
protecting against the faults considered in the fault model. Each E2E profile provides an alternative
way to protect the communication, by means of different algorithms. However, E2E profile have
similar interfaces and behavior. Each E2E Profile shall use a subset of the following data protection
mechanisms:
• A CRC provided by CRC Supervision;
• A Sequence Counter incremented at every transmission request, the value is
checked at receiver for correct incrementation;
• An Alive Counter incremented at every transmission request, the value checked
at the receiver side if it changes at all, but correct incrementation is not checked;
• A specific ID for every port data element sent over a port or a specific ID for every
I-PDU group (global to system, where the system may contain potentially several
ECUs);
• Timeout detection:
▪ Receiver communication timeout.
▪ Sender acknowledgement timeout.

Depending on the system and application, E2E Profile can be used. Autosar document “E2E Protocol
Specification” defines different profiles, control field and mechanism.

Functional overview of E2E component

The E2E component provides mechanisms for E2E protection, adequate for safety-related commu-
nication having requirements up to ASIL D.
The algorithms of protection mechanisms are implemented in the E2E Component. The callers of the
E2E Component are responsible for the correct usage of the component, in particular for providing
correct parameters the E2E Component routines.

The E2E protection allows the following:

• It protects the safety-related data elements to be sent over the RTE by attaching control data
• It verifies the safety-related data elements received from the RTE using this control data, and
• It indicates that received safety-related data elements faulty, which then has to be handled by
the receiver SW-C.

Autosar specifies flexible E2E profiles that implementation appropriate combination of E2E pro-
tection mechanisms. Each specified E2E profile has a fixed behavior, but it has some configuration
options by function parameters (e.g. the location of CRC in relation to the data, which are to be
protected).

The E2E component is invoked from:

• E2E Transformer
• E2E Protection Wrapper
• COM E2E Callout.

Use Case to use E2E transformer:

The use case describes of selecting the profiles and configuration using Autosar Tool for data
communication between VP and GP. Maximum of 4bytes of 20 safety data is sent from VP to GP.
Profile 6 can be configured to address ASIL B data integrity and support Safety data.

Profile 6 format:
Table 1.0: Profile 6 format

Control Description Maximum data

field
Length 16 bits, support dynamic-size data. 5bytes < Length <= 4K
bytes
(explicitly sent)
Counter 8 256
CRC 16 65535
Data ID 16 65535
Mechanism Provided:

Table 1.1: Mechanism

Autosar architecture:

E2E component is integrated with E2E transformer as part of Autosar Stack. E2E transformer
(E2EXf ) is invoked from the RTE when Application software writes and reads in to and from RTE
respectively . E2E transformer using E2E component adds control field for data sent from VP to GP
and removes control field for data received from GP to VP. Data is written in to RTE. Fault detected
by E2E is reported to application using RTE.

LIB Application
RTE
E2E
E2EXf
CDD
Serial
IPC COM Layer 1 Communication

BSW IPC COM Layer 2

Physical Layer

Figure 1.4: E2E Block diagram in Autosar

Sequence diagram:

Protect -E2E Xf_Transformed<transformer ID>: This interface as shown in sequence diagram is

invoked in to E2E transformer by RTE when application software writes in to RTE for signals needs
to be protected.

Figure 1.5: Sequence Diagram: Signal Protection

Check -E2EXf_Inv<transformer ID>: This interface as shown in sequence diagram E2E trans-
former is called for Check interface by application periodically

Figure 1.6: Sequence Diagram: Signal Verification

Configuration:

ARTOP tool is used to configure the profiles, parameter and to create arxml. Arxml is imported in to
autosar configuration tool to generate E2E functionality. The configuration can also be done in au-
tosar available developer tool.

Figure 1.7: E2E profile configuration

Signal level configuration:

Map the E2E transformer to the data element/Signal which needs to be protected. The data ID is
configured for every signal or element. Signal data element of size 9 bytes and maximum of 4kbytes.

Figure 1.8: E2E Signal configuration

Ex : Signals IntAntilckBkgSysIndnSolidOn is tagged with E2E in the transformed tab.

 Figure 1.9: E2E Signal associated

Autosar stack configuration:

• Add E2E components to perform the E2E functionality

• Serialization of packing and unpacking signals can be configured before adding E2E protec-
tion

Figure 2.0: E2E BSW including E2E stack configuration

Transformer Configuration:

• Configure the transformation technology

• Transformer BSW Module Entry to be configured on the Transmitter side
• Transformer Inverse BSW Module Entry to be configured on the Receiver side
• Map the signal/ signal group for which the transformation is applied
 Figure 2.1: E2E including E2E stack configuration

Summary/ Conclusion:

ASIL features assigned to an ECU shall be met as per ISO 26262 recommendation. In this paper, it
describes the recommendation for ASIL B development of software and hardware component to
have data integrity between two processors. It lists the serial communication faults and mechanism to
handle as per ISO 26262. It explains the decomposition of ASIL level in different level and the same
can be applied on serial communication strategy to meet safety goal. This avoids Safety qualification
of tools, hardware, software and process need to achieve for all the components in the transport layer.
This methodology doesn’t require ASIL B qualification for software and hardware component below
application layer.
This paper detailed the usage of autosar E2E component and transformer to meet the decomposition
requirement of diagnosing. The E2E component diagnose and report the fault to application software
to take system to safe state or to retry for system to recover.
Functional safety shall be built with component. It’s challenging to develop functional safety for
already existing ECU’s and this approach can also be applied. It minimizes the effort in redesign the
software and hardware to meet safety goals.
 References
ISO/FDIS 26262-6:2018(E), ‘Road vehicles — Functional safety — Part 6: Product development at
the software level
ISO/FDIS 26262-9:2018(E), ‘Road vehicles — Functional safety —Part 9: Automotive safety
integrity level (ASIL)-oriented and safety-oriented analyses
Autosar E2E Library 4.3.1
https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_E2
ELibrary.pdf
Autosar E2E transformer 4.3.1 V
https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_E2
ETransformer.pdf

Biography

Jagadish Narayan Gowda is Group Lead Engineer in General

Motors Technical Centre India Pvt. Ltd. Bengaluru. He holds
Master of Science in Software Sytem and graduation in Elec-
tronics and Communication Engineering and have been working
with General Motors for 11 years. Jagadish has technical expertise
in display Human Machine Interface engine and functional safety
software development. Currently focused on Development of
Cockpit unit for General Motors Global Electrical Architecture.
His core competencies are requirement/system design for Info-
tainment Display functionality, Functional Safety Development
and Autosar development for application software.