How to Approach Designs Targeting Automotive ISO 26262 Functional Safety Compliance: Part One

Safety as a Quality Feature in Automobile Industry

Safety is a key design consideration for all automotive manufacturers. The complexity of modern automobiles is on the rise, and as a result, they contain thousands of electronic parts. As a consequence, it is difficult to ensure that they all perform well individually and collectively to provide the desired functionality safely. The current development of partially or fully autonomous vehicles and their ongoing evolution has elevated the need for tackling safety with a contemporary and methodical strategy.

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

When safety is critical to the success of your design, you can count 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 dsPIC33 Digital Signal Controllers (DSCs) offers 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. Using development tools that meet the requirements of safety standards when designing functional safety applications can make it easier for system integrators to create compliant systems.

Microchip has received TÜV SÜD certification for the MPLAB^® XC16 C compiler for the ISO 26262 functional safety standard to assist system integrators in implementing system-level functional safety in their applications and we provide complete certification packages for the MPLAB development tools ecosystem to help qualify the development tool chain.

The following section refers to standard terms that are defined in the ISO 26262. For the definitions of these standard terms, please refer to the addendum.

When developing a safety-critical application, the logical flow diagram of an item¹ implementation as specified by the standard must be followed. The complete procedure must be used on an item at the vehicle level, as specified by the standard (to the entire vehicle or at a substantial part of it). The following are the key steps in the implementation flow that must be followed at the item level:

• Definition of the Item: The description of the system being developed
  
• Hazard Analysis and Risk Assessment (HARA): Defines all the hazards and the risks that the user of the Item could possibly encounter
  
• Safety goals: The goals that the design targets to address the hazards
  
• Requirements: A set of high-level functional requirements, technical requirements and detailed hardware and software requirements to accomplish safety goals
  
• Safety mechanisms: Hardware and/or software techniques used to improve the performance of technical requirements in addressing the hazards
  

Flow Diagram:

Automotive Safety Integrity Level (ASIL)

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

Severity: Seriousness or intensity of the damage to the life of people

Exposure: The measure of probability of the vehicle being in hazardous situation

Controllability: The measure of how likely the driver can control the hazardous situation

ASIL = Severity × (Exposure × Controllability)                  

The ASIL levels—ASIL A, B, C and D—are assigned based on an allocation table defined by the ISO 26262 standard, where level 1 is low and level 4 is high under each class as shown:

S3, E4 and C3 (the extremes of the three parameters) together denote a condition that is extremely dangerous. As a result, the component under evaluation is classified as ASIL D, which denotes that it requires the highest possible level of safety precautions.

The diagram below shows typical ASIL classification applications and safety levels for automotive applications:

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

To manage the safety requirements of components such as microcontrollers that are used as elements of a system/item, the introduction of a new concept, the Safety Element out of Context (SEooC), is needed. In the automotive world, the SEooC defined in ISO 26262 is the method for using components in a vehicle that were not originally designed for that specific project:

• The safety element (e.g., microcontroller) has not been designed on purpose for the Item
  
• It is available on the market (off the shelf)
• It can implement the requested function(s)

The implementation process described partially deviates from the content of the implementation flow shown above because the design covered refers not to an Item, but to an Element.

• Assumption specifications: In general, four sets of assumptions are considered and are then tailored according to the specific element. In certain application contexts, a microcontroller can be assumed to be the safety element. The following are the specifications:
• Intended use: Describes the target of the SEooC, the reason why it has been designed and how it can be used
• Intended functionality: Describes what the SEooC is designed for and what exactly it is supposed to do
• Use context: Describes how the SEooC can be used in the overall system/item to perform required functionalities
• External interfaces: Describes how the SEooC interacts with the rest of the system in terms of hardware and software
• Requirement specifications: Assumptions described above allow the defining of the requirements that the SEooC must be compliant with
• Development: Involves the effective design of SEooC
• Verifications: If the system/item design includes a SEooC during the hardware design, the SEooC assumptions are verified against the system/item hardware safety requirements and design specifications
• The second verification of assumptions is performed during the integration and testing phase of SEooC

Microcontroller as a Safety System (SEooC)

The following are the key steps in the implementation flow:   

At the item level, hazard analysis, risk assessment and definition of the safety goals are also carried out.

The Functional Safety Manual provides details on the fault detection methods named in the FMEDA report. It includes a description of dependent failures and hardware features for detecting systematic failures, which can be used for developing diagnostic libraries. Based on the allowable unsafety failure rates, the risk levels can be assessed as shown below:

Failure In Time (FIT) is a unit that represents failure rates and how many failures occur every 10⁹ hours.

Visit our website to find out more about featured controllers and automotive safety solutions. For more information on jumpstarting safety-critical designs, look out for part two of this discussion to learn more about our ISO 26262 automotive functional safety ecosystem that consists of the functional safety data monitoring reference application, safety collateral and functional safety packages.

Addendum

Terminologies

Numerous terminologies are used in the ISO 26262 standard with highly detailed definitions that occasionally may not line up with their typical usage. To ensure that there is a clear knowledge of the meaning and scope of the term, preventing uncertain interpretations, it is crucial to get familiar with the most used words.

Part 1 Clause 3, “Terms and Definitions” in the ISO 26262 Standard is a good reference source for the terminologies. The following are a few keywords:

The top-level target of the Standard is an Item. An Item is described as a “System or combination of Systems, to which ISO 26262 is applied, that implements a function or part of a function at the vehicle level” ([1], Part 1-3.84).

A System is a “set of components or subsystems that relates at least a sensor, a controller and an actuator with one another” ([1], Part 1-3.163).

A Component is a “non-system level Element that is logically or technically separable and is comprised of more than one Hardware part or one or more software units” ([1], Part 1-3.21).

An Element is a generic term to refer to a “System, components (hardware or software), hardware parts or software units” ([1], Part 1-3.41)

A SEooC (Safety Element out of Context) is a “Safety-related Element that is not developed in the context of a specific Item. A SEooC can be a System, a combination of Systems, a software component, a software unit, a hardware component or a hardware part” ([1], Part 1-3.138).

Functional Safety is defined as the “absence of unreasonable risk due to hazards caused by malfunctioning behavior of electric/electronic Systems”