25 articles
Two redundant channels are not automatically independent. What a dependent failure is, the difference between common cause and cascading failures, the coupling factors that tie elements together, and why ISO 26262 asks for DFA.
Software has no failure rate, so ISO 26262 cannot count it. What the standard asks for instead, why software is both the safety net for hardware faults and a source of its own, and why Part 6 converges on the software architecture.
A familiar component can face a different safety requirement in a new design. Explore what hardware element evaluation establishes, where its evidence stops, and why integration still matters.
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.
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.
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.
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.
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.
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.
While automotive and machinery functional safety share common roots, their methodologies differ significantly. Explore how ISO 26262 compares to ISO 13849 and IEC 62061 in risk assessment and system architecture.
Discover how aerospace functional safety standards like DO-178C and ARP4754A compare to automotive ISO 26262. Learn what automotive engineers can adapt from aviation to build robust, fail-operational architectures for autonomous vehicles.
Automotive display systems are the final line of defense during vehicle failures. Learn how to engineer robust HMI warning strategies, manage arbitration chaos, and calculate strict timing budgets to achieve ISO 26262 compliance.