End-To-End Protection Must Meet Freedom From Interference


End-to-end (E2E) protection is a critical aspect of automotive safety, as it ensures that all systems and components work together to prevent accidents and protect passengers and other road users. It refers to the process of ensuring that the entire system, from the sensor input to the actuator output, is designed and tested to meet the safety requirements set forth in the standard. This includes not only the software and hardware components of the system but also the interfaces between them, as well as the overall system architecture. E2E ISO 26262 is an extension of the ISO 26262 standard which covers only the functional safety aspect of the product development process.

This blog post will shed light on the complexities of achieving E2E protection, Freedom from Interference (FFI) requirements, Quality Management medium in E2E Systems, meeting ASIL (Automotive Safety Integrity Level) requirements in E2E software and hardware, and finally, ensuring FFI in E2E software and hardware interfaces.

The Complexities of Achieving E2E Protection

E2E protection can be complex due to several factors, including:
  1. Communication Errors: Errors in the transmission of data can cause interruption, buffer overflow, or underrun leading to failure of communication.
  2. Software Faults: Systematic faults in software (e.g. RTE, communication stack modules) can occur at any stage and always occur under the same circumstances. To prevent failures, technical measures such as program flow monitoring must be considered.
  3. Hardware Faults: Random hardware faults such as electrical overload and aging can’t be avoided, but their probability can be evaluated and measures implemented (e.g. diagnostics).
  4. Avoiding Undetected Faults: To ensure E2E protection, infrastructure for data transmission must not interfere with protected data, and all faults must be detected and handled appropriately.
  5. Legal and Regulatory Compliance: Adoption of ISO 26262, a regulation required by manufacturers in the EU to ensure safety, may pose challenges for organizations in complying with legal and regulatory requirements.
  6. Usability: The adoption of E2E encryption systems may be hindered if the hardware and software being used do not meet the ISO26262 certification standard, even if they meet the functional needs, which can lead to complexity for end-users.
Overall, achieving E2E protection requires balancing the need for security with the practical considerations of implementation and maintenance.

Freedom From Interference (FFI) Requirements in E2E Protection

One of the key challenges in achieving E2E protection is the need to meet freedom from interference (FFI) requirements. FFI is a measure of how well a system can detect and respond to faults, and it is a critical aspect of E2E protection. Types of interference include timing, execution, memory, and exchange of information. All must be met in E2E implementation.

To achieve FFI, it is necessary to decompose the system into its component parts and to analyze each component for both hardware and software faults. This type of decomposition is different from the ISO26262 ASIL decomposition, which addresses only systematic faults.
To meet FFI requirements, it is necessary to analyze both random and systematic hardware faults, as well as systematic software faults. This requires a more comprehensive approach to safety analysis, and it is one of the reasons why achieving E2E protection is challenging as unidentified faults can go undetected and cause serious consequences. The random hardware faults are related to the physical behavior of the system, such as temperature variations or electromagnetic interference. Systematic faults are related to the design or manufacturing of the system, such as a software bug or a wiring error.

Quality Management (QM) Medium in E2E Systems

Another important aspect that must be considered when designing an E2E system is the quality management (QM) medium. To meet random-fault metrics for hardware, the QM medium does not need to meet ASIL requirements. This is because any random faults that occur will be captured by the E2E system, assuming the correct mechanisms are used (such as the correct profile as per AUTOSAR, the Automotive Open System Architecture). The QM medium is the layer that communicates with external devices, such as sensors and actuators, and it is responsible for the correct transmission of the data.

Meeting ASIL Requirements in E2E Software and Hardware

The software component where E2E is implemented must be developed to the ASIL required for the component. This is because the software and hardware that run the E2E system must also meet ASIL requirements per ISO26262. The ASIL (Automotive Safety Integrity Level) is a standard that defines the safety level of the system, and it is related to the severity of the potential accident that the system may cause. The higher the ASIL level, the higher the safety requirements.
In addition, the E2E software component must have the necessary safety analysis to ensure FFI from the QM software driver it interfaces safety data with. This analysis is necessary to ensure that the software component can detect and respond to the faults and that it does not introduce new faults to the system. The software component is responsible for the processing of the data and for the decision-making of the system.
Furthermore, the ASIL hardware hosting the ASIL application and E2E component must also ensure FFI with the QM communication hardware. This is a critical aspect of achieving E2E protection, as it ensures that all systems and components work together to prevent accidents and protect passengers and other road users.
It is important to note that the responsibility for this analysis falls on the product design owner, and cannot be assumed to be provided by any suppliers. This is because the product design owner is responsible for ensuring that the system meets all safety requirements and that it is safe for use on the road.

Safety With E2E Protection

Achieving E2E protection is a complex task that requires a combination of hardware and software systems to be designed and tested to meet stringent safety requirements. This requires a comprehensive approach to safety analysis, and it is necessary to decompose the system into its component parts and to analyze each component for both hardware and software faults. Additionally, E2E protection requires the implementation of FFI, the QM medium, and the ASIL requirements to be met by the software and hardware component that runs the E2E system. The responsibility of this analysis falls on the product design owner, and it is important to ensure that the system meets all safety requirements and that it is safe for use on the road.

Other Articles

The Growing Need for Reliable, Adaptive, Fault-Tolerant Systems

In a rapidly evolving technological landscape, the demand for systems that can not only withstand errors but also adapt to them is paramount. This article delves into the world of Fault-Tolerant (FT) systems, emphasizing their significance in maintaining the functionality and safety of critical operations across various sectors. It explores the latest advancements in FT technology, underscoring the importance of resilience and adaptability in ensuring uninterrupted service and safeguarding against potential failures.

Read More »

Fuelling the Value of Multicast Addressing

Discover the transformative impact of Software-Defined Networking (SDN) and Multicast Addressing on automotive embedded systems. Explore how these technologies enhance communication efficiency, safety, and performance in the automotive industry, leading to cost-effective, scalable, and eco-friendly solutions. Dive into the technical advantages and practical applications for modern vehicles and infrastructure.

Read More »