ISO 26262-5:2018: Product development at the hardware level

Explore general topics for hardware-level development within the V model, define hardware safety requirements, plan integration with software teams, and assess robustness against random failures per clauses eight and nine.

Refine hardware safety requirements and establish hardware–software interface traceability from signal acquisition to software variables. Define timing and key signal attributes such as name, identifiers, interface type, direction, and range.

Derive hardware design from system architecture and safety requirements; develop hardware and software in parallel, exchange on the technical safety concept, and apply dependent failure analysis to validate safety.

Explore how a wiring diagram depicts circuit components with simplified shapes, maps power and signal connections, shows pin assignments, ADC or PWM sensors, and redundancies like accelerator pedal position.

Explore the circuit diagram as a representation of electrical circuits, showing connections and components, and illustrate how the inverter control unit supplies current to the e-motor from torque requests.

Analyze the coexistence of elements in hardware design to ensure freedom from interference between sub elements with asset ratings, using dependent failure analysis to prevent cascading and common cause failures.

Evaluate hardware architecture with the architecture matrix to verify safety goals and diagnostic coverage, including single point faults and detected, perceived, latent, and residual multiple point faults per ISO 26262.

Explain how safe faults are classified to avoid safety goal violations. Distinguish single point faults from independent multiple point faults and illustrate with a power transistor short example.

A residual fault occurs when a hardware fracture isn't covered by safety mechanisms, and diagnostic coverage falls short; parity checks add a parity bit to detect bit errors.

Define dual point and multiple point faults, where safety goals fail only with a second independent fault. Illustrate with redundant sensors, start up test, and detected or perceived fault classifications.

Identify latent faults as undetectable, hidden multiple point faults that combine with an independent fault and may threaten safety goals; standard tests can transform them to detected faults.

Explore a decision tree from ISO 26262 for classifying faults, including safe fault, single point fault, residual fault, and multiple point fault, with driver detectability and latent fault considerations.

Assess hardware robustness against random faults by calculating the hardware matrix with the single point fault metric and latent fault metric, guided by ASL targets and ISO 26262 recommendations.

Evaluate safety goal violations caused by random hardware failures and determine p values, fit and f values, and target thresholds for Ace and Sec in device hours.

Explain pf value calculation under ISO 26262, combining failure rates of single-point, residual, and detected faults with latent dual-point faults, multiplied by vehicle-type lifetime (1 hour/day passenger, 10 hours/day commercial).

Distribute the PMHF target value across components, allocating budgets such as 10%, 40%, and 30%, and ensure each HF value stays under budget, adjusting PM values if total exceeds target.

Explore methods to derive test cases for hardware-level development under ISO 26262-5:2018, guided by ACE rating, and include requirements analysis, interfaces, equivalence classes, boundary value analysis, and error guessing.

Explore three test methods for hardware level development: functional testing, fault injection testing, and electrical testing, including defining inputs, observing outputs, and verifying compliance with hardware safety requirements.

Master hardware matrix calculations and key ISO 26262-5 aspects for functional safety, and explore related courses with promo code ISO 2626 two.