Skip to main content
Tag

iso-26262

23 articles

ISO 26262 is not learned in one shot: a loop of learn, practice and evaluate, with the domains the standard touches around itMiscellaneous

ISO 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
Technical illustration showing a generic functional-safety lifecycle being adapted into the electronic architecture of a modern road vehicle.Technical

IEC 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
AI-generated illustration of an open automotive ECU, wiring harness and oscilloscope on a vehicle development bench.

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.

8 min
Real photograph of cars travelling on multilane roads in Dubai, photographed by Roman Logov.Miscellaneous

Proven 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
Driver's view down a wet motorway. Heavy spray from the traffic ahead hangs over the carriageway in a low backlit sun, and the painted lane markings fade out well before the cars do.Technical

The 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
A line of commit dots labelled as the mainline runs off the right edge. One dot is ringed in red, and a dashed line drops from it into a card holding five chips: source revision, patch list, configuration, toolchain, build recipe.Technical

Qualifying 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
Plan view of a road. In the next lane an overtaking vehicle is drawn twice: a dashed grey outline where the mirror panel still shows it, and a solid red one further ahead where it actually is, with the gap between them marked.Technical

Interior 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
Car bodies on a factory assembly line, a dark hatchback with its doors and bonnet open in the foreground and a row of white and blue bodies receding down the line behind it, under overhead conveyor gantries.Technical

ASPICE 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
Close-up of a densely populated circuit board, with a square multi-pin integrated circuit in sharp focus among capacitors and smaller packages.Technical

Multi-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
Comparison table showing differences between automotive ISO 26262 and railway EN 5012x functional safety standards, highlighting production volume, risk metrics, safe states, and lifecycles.Miscellaneous

Automotive 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
A comparison table showing the differences between automotive functional safety standard ISO 26262 and machinery standards ISO 13849 and IEC 62061.Technical

Automotive vs Machinery Functional Safety: An ISO 26262 Comparison

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.

8 min
Comparison table showing aerospace functional safety standards like DO-178C and ARP4754A next to their automotive ISO 26262 equivalents for system, software, and hardware development.Technical

Functional Safety in Aerospace vs Automotive: An ISO 26262 Guide

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.

7 min

We use cookies to measure how this site is used. Essential cookies stay on. Cookie Policy