Dependent Failure Analysis: Three Checks Beyond Redundancy
Two channels can still share one vulnerability. Learn three practical DFA checks for examining common causes, hidden dependencies and the evidence behind independence claims.
3 min
Tag
iso-26262
37 articles
Why FMEDA Matters for ISO 26262: Five Practical Reasons
Hardware can fail systematically, through errors made during development, or randomly, as parts wear or break in service. FMEDA addresses the random failures, connecting failure analysis with stronger evidence and better engineering decisions. Explore five reasons it matters for ISO 26262 projects, from revealing diagnostic gaps and examining supplier assumptions to guiding improvements and keeping the safety argument aligned with a changing design.
6 min
Architecting the Technical Safety Concept in ISO 26262
A safety goal needs an architecture that can deliver it. How do timing budgets, ASIL decomposition and E2E checks turn functional requirements into a technical safety concept? A practical look at the decisions that connect ISO 26262 safety intent to hardware and software.
9 min
MiscellaneousProven in Use Under ISO 26262: What Field History Can Support
Years on the road do not automatically make a component proven in use. What makes field history credible under ISO 26262, and when can it support reuse? A practical introduction to the evidence, limits and common misconceptions.
6 min
MiscellaneousISO 26262 Is Not Learned in One Shot
A training week, a certificate, and six months later a blank hazard analysis template. Nothing went wrong with the course. ISO 26262 is used in slices, months apart, and every slice borrows knowledge the standard does not teach: vehicle dynamics, reliability data, software verification, supplier contracts, SOTIF, cybersecurity. It is not learned in one shot. It is learned, applied and repeated, one cycle at a time. New article on how a team keeps that loop running, and what evidence it leaves behind.
5 min
TechnicalThe Automotive Safety Standards Map: Beyond ISO 26262
A modern car can cause the same accident four different ways. Only one of them is a malfunction. Lane centering steers into the next lane. Same severity, same exposure, same controllability. One hazard. Now ask why. A solder joint opened. Or the camera worked perfectly and lost the markings in low sun. Or someone forged a steering frame on the bus. Or the model met a road marking that was never in its training data. ISO 26262 owns the first one, and it says so itself. The other three each got a document: ISO 21448, ISO/SAE 21434, ISO/PAS 8800. The hard part is not learning four standards. It is that one item definition and one hazard list have to feed four arguments that must not contradict each other. New article on where the backbone ends.
7 min
TechnicalQualifying Linux for ISO 26262: Pinning the Open-Source Element
You cannot qualify Linux. You can qualify one build of it. ISO 26262 allocates requirements to elements, and an element has to hold still. A mainline kernel does the opposite. Open source gives you more visibility than any commercial supplier will. What it does not give you is traceability from a safety requirement to the test that shows it is met. So the first work product is not a gap analysis. It is a definition: exact source revision, vendor patches, reviewed configuration, toolchain, build recipe. Hand those to an engineer who was not in the room. If they cannot arrive at your binary, or explain every difference, you do not have an element. New article on the prerequisites, and why no qualification route can be chosen before the element exists.
9 min
TechnicalInterior and Mirror Cameras: The Stale Frame Problem
A mirror-replacement camera rarely fails by going blank. It fails by showing you a well-formed picture of a road that has moved on. Most of the chain answers a different question. A link CRC proves the pixels arrived intact. A register readback proves the sensor is configured. A watchdog proves the imaging task is scheduled, and a task republishing its last buffer is scheduled perfectly. So teams add a frame counter, usually in the software that receives frames. That proves only that this software is running: it keeps counting while the sensor sits dark. Even minted at the sensor, a counter is metadata: it travels next to the pixels, not inside them. A stage that re-stamps on publication can attach a fresh number to old pixels, and a header-only check waves it through. Placement earns you sequence coverage. Claiming the picture is current is a bigger claim than most safety cases support. New article on what that costs in detection budget and where the ISO 21448 boundary falls.
8 min
TechnicalASPICE and ISO 26262: What Each One Actually Grades
ASPICE rates how capable your development process is. ISO 26262 asks whether the product it produced is acceptably safe. Neither verdict substitutes for the other. Where the two read the same artifacts, where they diverge, and the safety work that has no ASPICE process behind it.
7 min
TechnicalMulti-Core Safety Architectures: An ISO 26262 Overview
Multi-core automotive SoCs add shared hardware, mixed criticality, and timing interference to every safety argument. This article maps the families of multi-core safety architecture, the three interference concerns underneath them, and what actually decides which one fits.
6 min
TechnicalIEC 61508 vs ISO 26262: What Automotive Engineers Need to Know
Can an element assessed at IEC 61508 SIL 3 support an ISO 26262 ASIL D safety goal? Often yes, but the label proves nothing on its own: a SIL belongs to a safety function, not to a part. Why the two risk models look alike and still cannot be converted, and what an integrity level is attached to.
9 min
MiscellaneousAutomotive vs Railway Functional Safety: An ISO 26262 Comparison
While both automotive and railway safety standards originate from IEC 61508, they have evolved into distinct methodologies. Discover how ISO 26262 principles compare to CENELEC railway standards regarding risk assessment, system response, and lifecycle management.
8 min
Keep learning
Go from article to full guide.
Each guide is a full course with diagrams and worked examples. Open one to see what it covers.
- Safety analysesDependent Failure Analysis (DFA)Learn how ISO 26262-9 Clause 7 verifies that redundant channels and ASIL decomposition are genuinely independent, by hunting dependent failure initiators and coupling factors that let one root cause defeat several safety elements at once.
- HardwareFMEDA: Quantitative Hardware Safety AnalysisLearn how Failure Modes, Effects and Diagnostic Analysis turns component failure rates in FIT, failure-mode distributions, and diagnostic coverage into the SPFM, LFM, and PMHF metrics that ISO 26262-5 requires for safety-related hardware.
- System levelTechnical Safety ConceptLearn how to translate safety goals and FSC into technical safety requirements (TSRs), system architecture, and HW/SW allocation. Covers safety mechanisms, diagnostic coverage, FMEA integration, and a complete worked example with templates.