ISO 26262 Functional Safety Masterclass: Build a project!

Define the brake light system function, inputs, outputs, and interfaces, and outline driving mode conditions, performance targets, safety shortfalls, and dependencies to create a solid functional safety concept.

Define how the function behaves and interacts with the driver and traffic participants, detailing inputs, outputs, boundaries, interfaces, operating modes, functional shortfalls, performance, legal requirements, and dependencies.

Identify functional failures and hazards, and determine their effects to perform hazard analysis and risk assessment. Score hazards to calculate the ASIL and assign safety goals for brake light behavior.

Perform HARA by evaluating severity, controllability, and exposure to determine ASIL or QM levels. Apply duration or frequency and the VDA 702 catalogue, using the sum method.

Assess hazards by scoring severity, exposure, and controllability to determine ASIL, then define specific safety goals to mitigate identified risks, such as ensuring brake lights do not fail during braking.

Define the safe state and the FTTI for the brake light function, ensuring 500 ms detection and a total within the two-second rule.

ASIL decomposition halves the safety concept into ASIL A components to cut development costs and speed up development, while still meeting the ASIL B safety goal with two independent bodies.

Explain the relationship between FTTI and FHTI, showing FHTI (diagnostic test interval plus fault reaction time) must be shorter than FTTI to prevent hazard.

Explore the diagnostic time interval in functional safety, showing how dual brake lamp failures trigger a safety goal and how ASIL levels shape diagnostic frequency and hardware requirements.

Explains how to refine the technical safety concept for a brake light system, allocating functional safety requirements to BCM hardware and software, defining interfaces, and outlining diagnostic and testing steps.

Define the technical safety concept by detailing the architecture blocks and their requirements, refine system elements to hardware and software, and specify the hardware–software interface and communication, preparing for review.

Verify the technical safety concept against gaps and logical errors, and improve it by revealing weak links through failure modes and effects analysis, fault tree analysis, and dependent failure analysis.

Apply seven-step failure modes and effects analysis (fmea) to identify failure modes in brake pedal switch, body control module, and brake lamps, assess risk, and design mitigation and diagnostic actions.

Identify dependencies and interfaces between safety elements and other system elements to prevent cascading failures and common-cause failures, and assess whether interfaces mingle with the safety concept.

Explore three system safety analyses—FMEA, FTA, and DFA—and how they identify failure modes, verify findings, and reveal dependencies to improve concepts and uncover gaps.

Define a system integration test strategy aligned with the ISO 2662 standard, selecting test methods by AZ level, and plan in-house or external execution with back-to-back comparisons for higher levels.

Define test specs from safety requirements with V-model, perform fault injection on brake switch voltage to verify brake lights respond within 300 milliseconds and document results in a test report.

Differentiate integration testing from validation testing to prove vehicle level safety goals are achieved and that the functional safety concepts and technical safety concepts mitigate identified risks.

Assemble the vehicle-level safety validation report by compiling test reports and expert judgments; justify the fault tolerance time interval and safe state to prove goals are implemented and risks mitigated.

Validate that safety goals mitigate risks by confirming fault tolerance intervals and safe state, validating safety trigger values for brake lights and battery management systems, with specifications and a report.

Define the technical safety concept and assign technical safety requirements to hardware and software elements, including their interfaces; apply FMEA, FDA, DFA, and validate vehicle-level safety goals.

Explore hardware development by aligning hardware requirements with safety goals and refining the hardware software interface. Review hardware design specifications, architecture, safety metrics, integration specs, testing, and documentation.

Learn how hardware safety requirements are derived from technical safety requirements and allocated to the body control module, detailing brake light diagnostics, voltage checks, and fault reporting.

Refined hardware-software interface uses a one-byte memory register with a name, address, and size to let software request and hardware report idle, active, or fault states for brake-light status.

Define hardware design specifications for a body control module, detailing a controller, analog front end, lamp driver, power source, and communication driver to interface with the vehicle bus.

Review hardware safety requirements and hardware architectural design specs using inspection, walkthrough, or simulation to identify faults and validate with Matlab Simulink.

Explore hardware safety analyses for ISO 26262, detailing FMEA and FMEDA with diagnostics, and metrics like single point, latent, and probabilistic failure rates across ASIL B, C, D.

Define hardware safety requirements and architectural design specs, and design tests for every functional requirement across the hardware chain, including voltage boundary checks for components like the brake lamp.

Refine hardware safety requirements into architectural specs and element interfaces, enabling parallel hardware and software development while applying FMEA/FMEDA, FTA, DFA, testing, and independent reviews for ASIL C/D.

Explore software development environment, processes and tools, and define software safety requirements, hardware software interfaces, and software architectural design specifications for module and unit development, reviews, safety analyses, and testing.

Select and configure a qualified toolchain to write, test, and integrate code, followed by coding and modeling guidelines, configuration management, verification infrastructure, and a traceability system.

Define software safety requirements that refine functional and technical safety needs for the body control module, detailing software architecture, unit design, and diagnostic routines for brake lamps.

Learn the refined hardware–software interface that enables brake-lamp diagnostics via a memory register with idle, request, active, fault states, a four-to-six-volt band, vehicle bus messages, and light control.

Define software architectural design specifications by splitting the system into modules: base software, QM application, and AZLB safety software, with interfaces and a diagnostic routine every second for brake lights.

Explore the third discretization layer by defining unit requirements that trigger base software calls, e.g., Get_Bulb1_Voltage_Status() to retrieve lamp states within ten milliseconds.

Perform software reviews across software requirements, architectural specifications, unit design, and code to ensure ISO 26262 compliance through static verification, walkthroughs, inspections, and automated checks.

Assess software safety through software FMEA and software FDA, using inductive and deductive analyses for AZ levels and QM module interactions, and mitigate failures with tests.

Apply the v-model to guide testing across software safety requirements, architectural specifications, and unit design specifications, writing corresponding test specifications with MCDC and branch coverage for embedded software.

Document software development environment, establish processes, toolchain, guidelines, traceability, then apply ISO 26262 stages—from requirements to design to unit and integration tests—supported by independent reviews and safety analyses.

Perform a quick recap of ISO 26262 twelve parts, covering part three to six on concept, system, hardware, and software development, and preview bonus content and remaining parts.

Explore ISO 26262 safety management by establishing processes, managing competences, handling safety anomalies, performing impact analysis, and delivering a safety plan with a safety case for release.

Integrate ISO 26262 functional safety into the development process from the start, align with company culture, and assign a functional safety manager to oversee safety activities.

Coordinate functional safety competence management by tracking resources, people, and project involvement, identifying experience gaps, and securing training or external support to adapt to dynamic staffing.

Identify and document safety anomalies within ISO 26262 functional safety masterclass, exploring hardware or software remedies and external measures when a brake light switch cannot be diagnosed.

Trigger anomalies to guide impact analysis for safety projects and system reuse. Analyze change, identify impacted safety work products such as requirements and tests, and plan activities.

Create a safety plan that lists work products, assigns responsibilities, defines tailoring, and synchronizes concept, system, hardware, and software activities with ISO 26262 and ASIL requirements.

Create and manage a safety case that stores all safety work products as artifacts, updates with every change, and supports the functional safety release by documenting maturity and street readiness.

Explore ISO 26262 safety management: integrate safety into processes from start to finish, supported by a safety manager, competence management, impact analysis, safety plan, and safety case for release.

Explore the final chapter of the ISO 26262 masterclass, covering production, service and decommissioning, supporting processes, EASIL and safety-oriented analysis, and guidelines for motorcycles.

Define and enforce production, service, and decommissioning requirements for functional safety, including end-of-line tests, temperature, humidity, electromagnetic fields, tier 2 supplier chips, and hazard prevention during servicing of high-voltage systems.

Explore ISO 26262 distributed development, including a development interface agreement with suppliers detailing products, and cover configuration management, change management, documentation and traceability, verification, tool qualification, and proven in use.

Explore ASEAL decomposition, dependent failure analysis, and safety analysis techniques, including inductive and deductive methods, FMEA, and fault tree analysis, to ensure safety with two independent paths and robust interfaces.

Guidelines part 10 and 11 of ISO 26262 cover fault tolerance time interval, hazard analysis, safety assessments, external measures, and safety elements out of context.

Adaptations for motorcycles introduce AMSIL-based HARA scoring and allow development with ASIL one step lower than the safety goal, while emphasizing driver controllability and reaction in validation tests.

Explore ISO 26262 safety topics, including production, service and decommissioning (part 7), easel decomposition and safety oriented analysis such as FMEA, FTA, FMEDA and DFA (part 9).

Review ISO 26262 modules from concept to production. Explore hazard analysis, risk assessment, and safety concepts across system, hardware, and software development, with ASIL analyses and guidance on finding information.