Automotive Safety Integrity Level Requirements and Design Implementation Process

Safety is a quality feature in the automotive industry

Safety is a key design consideration for all car manufacturers. The complexity of modern cars is rising and, as a result, they contain thousands of electronic components. It is therefore difficult to ensure that they all perform well both individually and collectively to safely provide the required functionality. The current development of partially or fully autonomous vehicles and their continued development raises the need to address safety issues with a modern and methodical strategy.

To meet the need for functional safety, the International Organization for Standardization (ISO) introduced the ISO 26262 standard for functional safety of electrical and/or electronic systems in road vehicles. ISO 61508 is an adaptation of the IEC 26262 industrial safety standard, focusing on reducing risks to acceptable levels, managing and tracking safety requirements, and ensuring standardized safety procedures in design, verification, testing, and validation.

When safety is critical to the success of your design, you can rely on our proven experience to help you meet functional safety requirements while minimizing cost and development time. Our broad portfolio of functional safety-ready and functional safety-compliant DSC33 digital signal controllers (DSCs) provides integrated hardware safety features, failure modes, effects and diagnostic analysis (FMEDA) reports, safety manuals and diagnostic software libraries to develop safety-critical applications that meet ISO 26262 requirements. When designing functional safety applications, using development tools that meet the requirements of safety standards can make it easier for system integrators to create compliant systems.

Microchip has received certification from TÜV SÜD for its MPLAB® XC16 C compiler as compliant with ISO 26262 functional safety standards to help system integrators implement system-level functional safety in their applications, and we offer a complete certification package for the MPLAB development tool ecosystem to help certify the development tool chain.

The following section refers to standard terms defined in ISO 26262. For definitions of these standard terms, see the appendix.

When developing a safety-critical application, the logical flow chart for the implementation of item 1 as specified in the standard must be followed. The complete procedure must be used for items at the vehicle level specified in the standard (for the entire vehicle or a large portion of the vehicle). The following are the key steps in the implementation flow that must be followed at the item level:

Project Definition: Description of the system being developed

Hazard Analysis and Risk Assessment (HARA): Defines all hazards and risks that users of an item may encounter

Safety goal: the goal of addressing hazards in the design

Requirements: A set of high-level functional requirements, technical requirements, and detailed hardware and software requirements to achieve security goals

Safety Mechanism: Hardware and/or software technology used to improve the performance of the technical requirements to address the hazard.

flow chart:

Automotive Safety Integrity Level (ASIL)

ASIL stands for Automotive Safety Integrity Level and is a risk classification scheme defined according to ISO 26262. A combination of three factors determines the ASIL requirement.

Severity: The severity or intensity of the damage to people's lives

Exposure: A measure of the probability that the vehicle is in a hazardous state

Controllability: A measure of how likely the driver is to control a hazardous situation

ASIL = Severity × (Exposure × Controllability)

ASIL levels (ASIL A, B, C, and D) are assigned according to the allocation table defined by the ISO 26262 standard, where level 1 is low and level 4 is high under each category, as shown below:

S3, E4, and C3 (extreme values ​​of the three parameters) together represent extremely hazardous conditions. Therefore, the evaluated component is classified as ASIL D, indicating that it requires the highest possible safety precautions.

Definition and Assumptions of Safety Element Out of Context (SEooC)

In order to manage the safety requirements of components such as microcontrollers used as system/project elements, a new concept needs to be introduced, the Safety Element Out of Context (SEooC). In the automotive field, SEooC defined in ISO 26262 is the method of using components in vehicles that were not originally designed for this specific project:

The security element (e.g. microcontroller) is not specifically designed for use with this product

It is available in the market (ready-made)

It can achieve the requested function

The described implementation process partially deviates from the content of the implementation flow shown above, because the designs covered do not refer to projects but to elements.

Assumptions Specifications: Generally, four sets of assumptions are considered and then tailored to the specific element. In certain application environments, a microcontroller can be assumed to be a secure element. Here are the specifications:

Intended Use: Describe the goals of the SEooC, why it was designed, and how it will be used

Intended Functionality: Describes what the SEooC is designed to do and what it should do

Usage context: describes how the SEooC is used throughout the system/project to perform the required functionality

External Interface: describes how the SEooC interacts with the rest of the system in terms of hardware and software

Requirements Specification: The above assumptions allow to define the requirements that the SEooC must meet

Development: Effective design involving SEooC

Verification: If the system/project design includes SEooC during hardware design, verify the SEooC assumptions against the system/project hardware safety requirements and design specifications

The second validation of the hypothesis is carried out during the integration and testing phase of the SEooC

Safety System as a Microcontroller (SEooC)

The following are the key steps in the implementation process:

At the project level, hazard analysis, risk assessment and definition of safety objectives are also performed.

The functional safety handbook provides detailed information on the fault detection methods specified in the FMEDA report. It includes a description of the relevant faults and the hardware features used to detect system faults, which can be used to develop diagnostic libraries. Based on the allowed unsafe failure rate, the risk level can be evaluated as follows:

Failure in Time (FIT) is a unit that represents the failure rate or the number of failures that occur per 109 hours.