ISO 26262 or ISO 13849? What happens when automotive meets machinery

There is a growing class of systems that neither standard was written for: machines that drive. Autonomous haulers, agricultural and construction autonomy, and — my daily work — test equipment that physically simulates an automated driving system on a proving ground. Automotive engineers reach for ISO 26262 and discover its scope is series-production road vehicles. Machinery engineers reach for ISO 13849 and discover it says nothing about vehicle dynamics, ODDs, or ASILs. Both camps are half right.

Working on a Test Robot that validates SAE L3-L4 autonomous trucks, I sit on this boundary permanently. Here is the sorting logic I use.

Start from the legal question, not the technical one

The first question is not “which standard is better” — it is “which framework applies to this product in this market.” A machine placed on the EU market falls under the Machinery Directive (and its successor regulation), which makes harmonized standards like ISO 13849 the presumption-of-conformity route. A road vehicle falls under type approval. Test equipment operating on a closed track is, legally, usually a machine — even if everything about its behavior is automotive.

This matters because it decides who your assessor is and what evidence structure they expect. A notified body reads Performance Levels and Categories. An automotive assessor reads ASILs and safety goals. Handing either one the other’s paperwork does not go well.

The standards disagree in instructive ways

Once you work in both, the differences stop being trivia and start driving design decisions:

• Risk parameters. ISO 26262’s HARA rates severity, exposure, and controllability of vehicle-level hazards. ISO 13849 rates severity, frequency of exposure, and possibility of avoidance for persons near the machine. The same hazardous event can land at ASIL B in one framework and PL d in the other — and the mapping between ASIL and PL is a convenience, not an equivalence.
• Architecture thinking. ISO 13849 reasons in Categories — designated architectures with defined channel structures and diagnostic expectations. ISO 26262 reasons in safety mechanisms and metrics with no prescribed architecture. Category 3 forces structural decisions (redundant channels, cross-monitoring) that a metrics-only mindset might argue its way around.
• The human in the loop. Machinery safety leans heavily on safeguarding — zones, fences, enabling devices, emergency stop per ISO 13850. Automotive safety leans on controllability by the driver. A driverless machine on a track has neither a fence nor a driver, which is precisely why neither standard alone is sufficient.

One system, one argument

The failure mode I see in mixed programs is running two parallel safety efforts — an “automotive” one and a “machinery” one — that meet only in a compliance matrix at the end. That produces double work and, worse, gaps at the interface: the E-stop path analyzed under ISO 13849 while the vehicle-dynamics behavior it triggers is analyzed under ISO 26262, with nobody owning the timing budget across the boundary.

What works instead: one hazard analysis covering the whole operational situation, one safety concept, one argument — with each claim assigned to the framework that governs it. The braking chain of a test robot can carry a Performance Level while its interaction with the truck under test is argued through the ADS-level case under ISO/TS 5083. The structure is layered, but it is a single proof, and every requirement knows which claim it serves.

When to sort this out

Before the architecture freezes. Category 3 dual-channel decisions, safe-state definitions, and stop-category choices are structural — retrofitting them into a single-channel design is a redesign, not a paperwork exercise. If your product drives and is also a machine, the cheapest week you will ever spend is the one where you decide, per hazard, which framework owns it.