ISO 26262 Interview Questions and Answers: Complete Functional Safety Preparation Guid

Hello, aspiring and experienced automotive functional safety engineers! Whether you are preparing for your first ISO 26262 role at a Tier-1 supplier, interviewing for a senior safety architect position at an OEM, or preparing for a functional safety certification exam, this comprehensive collection of interview questions will help you review and solidify your knowledge. These questions are drawn from real interview experiences at leading automotive companies including Bosch, Continental, ZF, Aptiv, Infineon, NXP, Qualcomm, Mercedes-Benz, BMW, Volvo, and major Tier-1 suppliers.

Each question includes a concise, technically accurate answer and a link to the relevant detailed article in our comprehensive ISO 26262 series at PiEmbSysTech for deeper study.

ISO 26262 Basics (Q1–Q10)

Q1: What is ISO 26262?

ISO 26262 “Road vehicles – Functional safety” is the international standard for functional safety of electrical and electronic systems in series production road vehicles. It is an adaptation of IEC 61508 specifically for the automotive domain. The current edition (2nd, published December 2018) consists of 12 parts covering the entire safety lifecycle from concept to decommissioning. → Full Guide

Q2: What is functional safety?

Functional safety is the absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems. It focuses on preventing harm from system malfunctions – not from inherent properties of the technology (electrical shock) or from external attacks (cybersecurity).

Q3: How many parts does ISO 26262 consist of? Name them.

ISO 26262:2018 has 12 parts: Part 1 (Vocabulary), Part 2 (Functional Safety Management), Part 3 (Concept Phase), Part 4 (System Level), Part 5 (Hardware Level), Part 6 (Software Level), Part 7 (Production/Operation/Service/Decommissioning), Part 8 (Supporting Processes), Part 9 (ASIL Decomposition & DFA), Part 10 (Guidelines), Part 11 (Semiconductors), Part 12 (Motorcycles).

Q4: What is the difference between a fault, an error, and a failure?

A fault is an abnormal condition that can cause a malfunction (e.g., a stuck-at transistor). An error is the manifestation of a fault in the system’s behavior (e.g., an incorrect register value). A failure is the inability of the system to perform its intended function due to an error (e.g., incorrect torque output). The chain is: Fault → Error → Failure.

Q5: What is a safety goal?

A safety goal is the top-level safety requirement for the item, derived from HARA. Each hazardous event identified in HARA leads to a safety goal with an assigned ASIL. Example: “The EPS system shall not provide unintended steering torque” – ASIL D.

Q6: What is the V-model in ISO 26262?

The V-model is the development approach where the left side represents specification and design activities (requirements → architecture → detailed design → implementation) and the right side represents verification and validation activities (unit testing → integration testing → system testing → validation). Each left-side activity has a corresponding right-side verification activity.

Q7: What is an item in ISO 26262?

An item is a system or combination of systems to which ISO 26262 is applied – it implements a function or part of a function at the vehicle level. Example: the Electric Power Steering (EPS) system is an item. The item is defined in Part 3 during the item definition phase.

Q8: What is the safety lifecycle?

The safety lifecycle encompasses all phases of the item’s life – from concept (item definition, HARA, safety concept) through product development (system, hardware, software), production, operation, service, to decommissioning. Part 2 defines the management of the safety lifecycle.

Q9: What is a safety plan?

The safety plan documents all planned safety activities for a project – including which Parts/Clauses of ISO 26262 apply, what work products will be produced, who is responsible, what methods and tools will be used, the schedule for safety activities, and the planned confirmation measures.

Q10: What is a safety case?

The safety case is the structured argument, supported by evidence, that the item achieves an acceptable level of functional safety. It includes the safety goals, the safety concept, all safety analyses, verification and validation results, and the FSA assessment report. It is evaluated during the functional safety assessment.

HARA and ASIL (Q11–Q18)

Q11: What is HARA?

Hazard Analysis and Risk Assessment – the process in Part 3 that identifies hazardous events and classifies their risk using three parameters: Severity (S0–S3), Exposure (E0–E4), and Controllability (C0–C3). The combination of S, E, and C determines the ASIL. → HARA Guide

Q12: What are the ASIL levels?

ASIL A (lowest rigor), ASIL B, ASIL C, and ASIL D (highest rigor). Plus QM (Quality Management – no specific ISO 26262 safety requirements). ASIL D requires the most stringent development methods, the highest hardware metrics, and the most independent confirmation measures. → ASIL Levels Explained

Q13: What do Severity, Exposure, and Controllability mean?

Severity (S): The potential injury to people – S0 (no injuries) to S3 (life-threatening/fatal). Exposure (E): The probability that the operational situation occurs – E0 (incredible) to E4 (high probability). Controllability (C): The driver’s ability to prevent the harm – C0 (controllable in general) to C3 (difficult to control or uncontrollable).

Q14: How is ASIL determined from S, E, C?

Using the ASIL determination table in Part 3 – a 3D lookup with S on one axis, E on another, and C on the third. For example: S3 + E4 + C3 = ASIL D. S1 + E2 + C2 = QM.

Q15: What is ASIL decomposition?

ASIL decomposition allows splitting a safety requirement into redundant requirements allocated to independent elements with lower ASILs. For example: ASIL D → ASIL B(D) + ASIL B(D), or ASIL D → ASIL A(D) + ASIL C(D). Requires demonstration of sufficient independence between the decomposed elements through DFA. → ASIL Decomposition Guide

Q16: What does the (D) in ASIL B(D) mean?

The (D) indicates the original ASIL before decomposition. ASIL B(D) means the element is developed to ASIL B methods, but its confirmation measures (reviews, audits, assessments) must still use ASIL D independence levels.

Q17: What is the difference between a hazard and a hazardous event?

A hazard is a potential source of harm caused by malfunctioning behavior (e.g., unintended steering torque). A hazardous event is the combination of a hazard with an operational situation (e.g., unintended steering torque during highway driving at high speed).

Q18: What is the FTTI?

The Fault Tolerant Time Interval – the maximum time from the occurrence of a fault to a potentially hazardous event, assuming the safety mechanism has not yet responded. The safety mechanism must detect and handle the fault within the FTTI to prevent the hazardous event.

Safety Concepts – FSC and TSC (Q19–Q24)

Q19: What is the Functional Safety Concept (FSC)?

The FSC (Part 3) defines the functional safety requirements (FSRs) derived from the safety goals and allocates them to preliminary architectural elements. The FSC specifies what the system must do for safety – including safe states, fault detection strategies, and degradation concepts — without specifying how it is implemented. → FSC vs TSC

Q20: What is the Technical Safety Concept (TSC)?

The TSC (Part 4) refines the FSC into technical safety requirements (TSRs) allocated to specific system components. The TSC specifies how the safety requirements are implemented – including specific safety mechanisms, diagnostic coverage, hardware architectural design, and FTTI-compliant reaction times.

Q21: What is a safety mechanism?

A safety mechanism is a technical implementation designed to detect, indicate, or mitigate faults, or to maintain a safe state. Examples: watchdog timer, CRC check on communication, MPU memory protection, dual-channel comparison, plausibility checks on sensor data.

Q22: What is a safe state?

A safe state is a defined operating mode of the item where no unreasonable risk exists. It may be the intended function (fail-operational) or a degraded mode (fail-safe). For EPS: the safe state might be “power assist disabled, manual steering available.”

Q23: What is diagnostic coverage (DC)?

Diagnostic coverage is the fraction of a failure category that is detected by a safety mechanism. DC = (failure rate detected by mechanism) / (total failure rate of the component). DC is classified as Low (60%), Medium (90%), or High (99%).

Q24: What is the difference between fail-safe and fail-operational?

Fail-safe: The system transitions to a safe state upon detecting a fault (e.g., disabling electric assist). Fail-operational: The system continues to provide a degraded level of functionality after detecting a fault (e.g., reduced-performance steering). Fail-operational is increasingly required for ADAS/AD functions where a safe stop may not be safe (e.g., highway automated driving).

Hardware Metrics – SPFM, LFM, PMHF (Q25–Q30)

Q25: What are the three hardware metrics in ISO 26262?

SPFM (Single Point Fault Metric), LFM (Latent Fault Metric), and PMHF (Probabilistic Metric for random Hardware Failures). They evaluate the hardware architecture’s effectiveness in addressing random hardware failures. → Calculation Guide

Q26: What is SPFM and what are the target values?

SPFM measures the fraction of single-point and residual faults that are covered by safety mechanisms. Target values: ASIL B ≥90%, ASIL C ≥97%, ASIL D ≥99%.

Q27: What is LFM and what are the target values?

LFM measures the fraction of latent faults that are detected by diagnostics or perceived by the driver. Target values: ASIL B ≥60%, ASIL C ≥80%, ASIL D ≥90%.

Q28: What is PMHF?

PMHF is the overall probability of a safety goal violation per hour due to random hardware failures – considering both single-point and residual faults plus multiple-point fault combinations. Target: ASIL D <10⁻⁸/h (10 FIT).

Q29: What is the difference between SPFM/LFM and SFF in IEC 61508?

ISO 26262 uses two separate metrics (SPFM and LFM) that provide more granular insight into single-point and latent fault coverage. IEC 61508 uses a single metric (SFF – Safe Failure Fraction) that combines all categories, potentially masking architectural weaknesses. → ISO 26262 vs IEC 61508

Q30: What is FMEDA?

Failure Modes, Effects, and Diagnostic Analysis – extends FMEA by adding the evaluation of diagnostic coverage for each failure mode. FMEDA is the primary method for calculating SPFM, LFM, and PMHF.

Software Development – Part 6 (Q31–Q36)

Q31: What coding standard does ISO 26262 require?

ISO 26262 requires the use of coding guidelines for safety-relevant software. MISRA C (for C language) and MISRA C++ or AUTOSAR C++14 (for C++ language) are the most widely referenced standards. → Part 6 Walkthrough

Q32: What structural coverage levels are required by ASIL?

ASIL A: Statement coverage (recommended). ASIL B: Branch coverage (highly recommended). ASIL C: Branch coverage (highly recommended) + MC/DC (recommended). ASIL D: MC/DC coverage (highly recommended).

Q33: What is MC/DC?

Modified Condition/Decision Coverage – requires that each condition in a decision has been shown to independently affect the outcome of the decision. It is the most rigorous structural coverage criterion and is highly recommended for ASIL D.

Q34: What are the software unit testing methods by ASIL?

ASIL A/B: Requirements-based testing (recommended/highly recommended). ASIL C/D: Requirements-based testing + interface testing + fault injection testing + resource usage measurement (all highly recommended).

Q35: What is back-to-back testing?

Back-to-back testing compares the behavior of the model (e.g., Simulink) against the generated code running on the target or a test environment. It verifies that the code generator produced code that behaves identically to the model.

Q36: What is the purpose of software safety analysis?

To identify potential weaknesses in the software architecture, verify the effectiveness of software safety mechanisms, and confirm that software faults cannot lead to safety goal violations. Methods include SW-FMEA and SW-FTA.

Safety Analysis – FMEA, FTA, DFA (Q37–Q42)

Q37: What is the difference between FMEA and FTA?

FMEA is an inductive (bottom-up) analysis – starting from component failure modes and evaluating their effects. FTA is a deductive (top-down) analysis – starting from an undesired top event and tracing back to identify the combination of basic events that could cause it. → FMEA and FTA Guide

Q38: What is DFA?

Dependent Failure Analysis identifies failures that are not statistically independent – where a single root cause can simultaneously affect multiple elements assumed to be independent. DFA identifies coupling factors and evaluates common cause failures (CCF) and cascading failures.

Q39: What is the difference between CCF and cascading failures?

CCF: Multiple elements fail simultaneously from a single external root cause (e.g., shared power supply failure). Cascading: Failure of element A directly causes failure of element B (e.g., memory corruption propagating from QM to ASIL software).

Q40: What is FFI and how is it achieved?

Freedom from Interference – the absence of cascading failures between elements that could violate a safety goal. Achieved through spatial protection (MPU), temporal protection (OS execution budgets), and communication protection (E2E, range checks).

Q41: What is the relationship between FFI and independence?

Independence = FFI + No Common Cause Failures. FFI addresses only cascading failures. Independence addresses both cascading and common cause failures. ASIL decomposition requires independence (not just FFI).

Q42: What is a coupling factor?

A physical, logical, or environmental characteristic that creates a dependency between elements – such as shared power supply, shared memory, shared CPU, same semiconductor technology, or common environmental exposure. Coupling factors are the root causes of dependent failures.

Advanced Topics – FFI, AUTOSAR, Tool Qualification (Q43–Q50)

Q43: How does AUTOSAR support ISO 26262?

AUTOSAR provides OS-Application partitioning (spatial FFI via MPU), timing protection (temporal FFI), E2E Protection Library (communication protection), WdgM (program flow monitoring), and DEM+FiM+BswM+EcuM (safe state management). AUTOSAR compliance does not equal ISO 26262 compliance – both are needed.

Q44: What is a SEooC?

A Safety Element out of Context – an element developed for safety reuse without the full system context. The developer makes assumptions about the target application, documents them in a safety manual, and the integrator validates these assumptions during integration. → SEooC Guide

Q45: What is tool qualification?

The process of demonstrating that software tools used in the safety lifecycle are suitable for their purpose. Tools are classified by TI (Tool Impact) and TD (Tool Error Detection) into TCL (Tool Confidence Level). TCL2/TCL3 tools require qualification using methods 1a–1d. → Tool Qualification Guide

Q46: What are the four tool qualification methods?

1a: Increased confidence from use. 1b: Evaluation of the tool development process. 1c: Validation of the software tool. 1d: Development in accordance with a safety standard. In practice, most qualifications use 1b + 1c or 1c alone.

Q47: What are the three types of confirmation measures?

Confirmation Review (evaluates work products), Functional Safety Audit (evaluates process compliance), and Functional Safety Assessment / FSA (evaluates overall safety achievement). Independence levels I0–I3 depend on ASIL. → Confirmation Measures Guide

Q48: What is the proven in use argument?

An alternative compliance path that uses field experience data to demonstrate a component’s safety – without full ISO 26262 development. Requires extensive field data (millions of units, years of operation) and effective field monitoring. → Proven in Use Guide

Q49: What is the WdgM in AUTOSAR?

The Watchdog Manager – provides alive supervision (periodic execution check), deadline supervision (execution time limit), and logical supervision (control flow sequence verification). Linked to the hardware watchdog for safe state enforcement.

Q50: Who is responsible for functional safety – the safety manager or the project manager?

The project manager is ultimately responsible for achieving functional safety. The safety manager is responsible for advising, monitoring, and reporting on functional safety activities, but the project manager has the accountability for delivering a functionally safe product.

Standards Comparison – IEC 61508, SOTIF, ISO 21434 (Q51–Q55)

Q51: What is the relationship between ISO 26262 and IEC 61508?

ISO 26262 is an adaptation of IEC 61508 for the automotive domain but does not claim IEC 61508 compliance. Key differences: ASIL (qualitative) vs SIL (quantitative), SPFM/LFM vs SFF, no MooN architectures in ISO 26262, more flexible ASIL decomposition. ASIL D ≈ SIL 3; no ASIL equivalent to SIL 4. → Full Comparison

Q52: What is SOTIF (ISO 21448)?

Safety of the Intended Functionality – addresses hazards that occur when the system works as designed but the design is insufficient for the real-world situation (sensor limitations, perception errors, algorithm insufficiencies). ISO 26262 = “what if it breaks?” SOTIF = “what if it works but isn’t good enough?” → ISO 26262 vs SOTIF

Q53: What is ISO/SAE 21434?

Road vehicles – Cybersecurity engineering. Addresses intentional attacks (as opposed to ISO 26262’s accidental failures). Uses TARA (Threat Analysis and Risk Assessment) instead of HARA. A cybersecurity breach can become a safety hazard – both standards must be applied for connected vehicles. → Safety Meets Cybersecurity

Q54: What is the “safety triangle” for modern vehicles?

ISO 26262 (functional safety – accidental malfunctions) + ISO 21448 / SOTIF (functional insufficiencies) + ISO/SAE 21434 (cybersecurity – intentional attacks). All three standards are needed for comprehensive safety of connected, autonomous vehicles.

Q55: What is ASPICE and how does it relate to ISO 26262?

Automotive SPICE (ASPICE) is a process maturity model for software development – it defines best practices for software engineering processes. ISO 26262 defines safety requirements for development processes. They are complementary: ASPICE ensures good engineering process quality, ISO 26262 ensures functional safety. Many OEMs require both ASPICE compliance and ISO 26262 compliance from their suppliers.

Interview Preparation Tips

For freshers: Focus on Q1–Q18 (basics, HARA, ASIL). Be prepared to explain the V-model, ASIL determination, and the difference between fault/error/failure. Know the 12 parts by name.

For 2–5 years experience: Add Q19–Q36 (safety concepts, hardware metrics, software development). Be ready to calculate SPFM/LFM from an FMEDA table. Know MC/DC, MISRA, and the software V-model.

For senior / expert level: Master all 55 questions, especially Q37–Q55 (DFA, FFI, AUTOSAR, tool qualification, standards comparison). Be prepared to discuss real project examples, argue for specific design decisions, and explain the trade-offs between ASIL decomposition approaches.

For all levels: Use a specific worked example (like EPS) to illustrate your answers. Interviewers value practical understanding over theoretical recitation.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech – explore the linked articles above for in-depth coverage of each topic.

Stay safe. Stay prepared. Keep engineering the future.

— The PiEmbSysTech Team