Safety-by-Wire® — One Platform, Five Worlds of Standards

Why one standard is not enough: the standards behind Arnold NextG's functional safety strategy

In the two previous articles, we showed why UN R185 and UN GTR 26 treat the safety of automated driving systems as continuous evidence across the entire chain of effect — and why the Control Layer and Drive-by-Wire move to the center of that picture. This is where the real work begins: a safety case does not emerge from test kilometers alone; it additionally requires a structured argument against recognized standards. In this new four-part series, we open up the code behind Safety-by-Wire®: the functional safety strategy of NX NextMotion. Part 1 starts where every safety argument starts — with the question of which standards a system actually has to be safe against.

At a glance

• Functional safety is evidence-based: what matters is not only that a system works, but that its safety can be argued in a structured way against recognized standards.
• NX NextMotion is designed as a Drive-by-Wire-based Control Layer for very different vehicle worlds — from road vehicles to agricultural and forestry machinery, earth-moving machinery, and industrial trucks. Each of these domains brings its own safety standard with its own risk metric.
• Five worlds of standards shape the platform's functional safety: ISO 26262 (ASIL), IEC 61508 (SIL), ISO 25119 (AgPL), ISO 19014 (MPL), and EN 1175 in conjunction with ISO 13849 (PL).
• They are complemented by ISO 21448 (SOTIF), ISO/SAE 21434 (cybersecurity), and the homologation level of the UNECE regulations — from R79, R13, and R10 to the new ADS framework of UN R185 and UN GTR 26.
• Arnold NextG's strategic answer is called Safety-by-Wire®: not a choice of standard, but a standards strategy. The requirements of all relevant standards are consolidated, and the strictest one sets the benchmark — with ISO 26262 as the lead standard for development.

Why standards? The difference between "it works" and "demonstrably safe"

The team behind NX NextMotion has previously developed by-wire systems that have covered more than a billion kilometers on public roads — and therefore knows: a vehicle that drives thousands of kilometers without failure is impressive, but it is not yet a demonstrably safe system. Functional safety asks a different question: What happens when something goes wrong? Which faults can occur, how likely are they, how severe would their consequences be — and which mechanisms detect them, control them, or transfer the system into a controlled state?

Standards codify the answers to these questions. They bundle decades of experience in how hazards are systematically identified, risks are classified, safety requirements are derived, and evidence is produced. In doing so, they define what counts as the state of the art in development, approval, and audit. For a Control Layer that translates digital driving decisions into real vehicle motion, standards are therefore not a formality. They are the grammar of the safety case that the new ADS regulations explicitly demand.

One parent standard, many dialects

IEC 61508 is regarded as the generic base standard for the functional safety of electrical, electronic, and programmable electronic systems. Domain-specific standards have emerged from it or have been aligned with it — each tailored to the risk profiles of its application world. A tractor in the field, a forklift in the warehouse, and a shuttle in urban traffic differ fundamentally in speed, environment, exposure, and the question of who can still control a malfunction. That is exactly why different risk metrics exist.

The five worlds of standards in brief:

• ISO 26262 — road vehicles. The central standard for the functional safety of E/E systems in series-production vehicles. Risks are classified via the Automotive Safety Integrity Levels ASIL A through ASIL D, derived from severity, probability of occurrence, and controllability. For NX NextMotion, ISO 26262 is the lead standard for development — with ASIL D as the highest level for the primary functions of steering, braking, and propulsion.
• IEC 61508 — the generic base. It classifies risks via Safety Integrity Levels SIL 1 through SIL 4 and remains the reference wherever no domain standard applies. Evidence up to SIL 3 opens up applications for the platform beyond the classic vehicle domains — on land, on water, and in special applications.
• ISO 25119 — agricultural and forestry machinery. Tractors and self-propelled agricultural machines assess safety-related control functions via Agricultural Performance Levels (AgPL a through e) — with their own assumptions about environment, speed, and the operator's role.
• ISO 19014 — earth-moving machinery. Excavators, wheel loaders, and related machines classify via Machine Performance Levels (MPL). The construction site brings its own hazard patterns: changing personnel in close proximity, working and driving operation within the same system.
• EN 1175 / ISO 13849 — industrial trucks and machine control systems. For the electrical equipment of industrial trucks, EN 1175 draws on the Performance Levels (PL a through e) of the machinery safety standard ISO 13849 — the world of intralogistics, where humans and machines share the tightest spaces.

The application context decides — why one standard is not enough

The same platform that translates steering commands into controlled motion in an autonomous shuttle also controls terminal tractors in factory traffic, tractors in the field, construction machinery in earthworks, and vehicles in intralogistics. Each of these applications triggers its own world of standards with its own conformity logic, its own analyses, and its own approval practice.

A system supplier who develops for only one domain faces a structural problem when stepping into the next: functional safety is, to a large extent, process evidence. Hazard analyses, development processes, verification, and documentation cannot be created retroactively. A second standard "slipped over" a finished system afterwards is therefore, in practice, often equivalent to a new development — with corresponding consequences for time, cost, and the safety case.

More than functional safety: SOTIF, security, and homologation

Functional safety in the narrow sense addresses malfunctions — the behavior of the system when hardware or software fails. A complete safety case requires three complementary perspectives:

• ISO 21448 (SOTIF) looks at the safety of the intended functionality: hazards that arise without a technical fault — for example, through functional insufficiencies or reasonably foreseeable misuse. SOTIF primarily addresses the level of the automated driving system. The Control Layer provides the preconditions for it: defined system states, clear limits, and deterministic degradation behavior.
• ISO/SAE 21434 anchors cybersecurity as a precondition of safety: a system that can be manipulated is not safe — regardless of how good its fault handling is. On the regulatory side, this is flanked by UN R155 (cybersecurity management) and UN R156 (software updates).
• The UNECE regulations form the homologation level. An important distinction applies here: standards describe the how of the state of the art — regulations decide the whether of market access. For motion control, this means in particular UN R79 (steering equipment), UN R13 (braking), and UN R10 (EMC); with UN R185 and UN GTR 26, the new international framework for automated driving systems is added — the framework we put into context in the two previous articles. In practice, this level is complemented by OEM-specific requirement sets such as VW 81000.

The strategic decision: one requirements base instead of five parallel worlds

The most obvious path would be to run a separate safety project for each domain — one after the other, depending on market opportunity. Arnold NextG decided differently early on: the hazard analyses and safety requirements of the relevant worlds of standards are consolidated into one common requirements base. Where standards use different risk metrics, these are mapped onto each other via the mapping tables provided in the standards themselves — and in case of doubt, the strictest requirement always applies. Development follows ISO 26262 as the lead standard throughout; generic evidence according to IEC 61508 up to SIL 3 additionally opens the doors beyond the classic vehicle standards.

The result of this strategy can be summed up in one sentence: develop once against the strictest requirement — and thereby make the platform deployable across domain boundaries. What matters is the timing. This consolidation stood at the beginning of the platform's development, not at its end. It is the reason why NX NextMotion can use the same safety architecture today in road vehicles, in the field, on the construction site, and in the warehouse.

"We never chose a single market — so we could never choose a single standard. Our answer was to make the strictest requirement the benchmark for all of them." Kevin Arnold, CEO of Arnold NextG GmbH (draft quote, approval pending)

What OEMs, integrators, and operators should clarify now

• Which worlds of standards does your application actually trigger — road, machinery, or both? And which applies in borderline cases, such as factory traffic with a public road connection?
• Does a supplier's ASIL or SIL statement refer to an individual component — or to the system function in the vehicle, including sensors, communication, and actuators?
• How is a second application domain supposed to be opened up if development and process evidence have so far been produced against one standard only?
• How do functional safety, SOTIF, and cybersecurity interlock in your safety argument — and who owns the interfaces?
• Which evidence does a platform already bring with it — and which is only created in the project?

Anyone who answers these questions only in the middle of a running project pays for the answers twice — in time and in the safety case. That is why Arnold NextG put them at the beginning: the consolidated requirements base across all five worlds of standards already exists as the pre-developed foundation of NX NextMotion. It does not replace the manufacturer's responsibility for the complete vehicle — but it ensures that customer projects build on answered questions instead of starting from scratch in every domain.

Conclusion

Standards are not bureaucracy. They are the language in which safety becomes demonstrable — towards approval authorities, auditors, operators, and ultimately towards the people who are expected to trust autonomous systems. Anyone building a Control Layer for multiple domains therefore needs not a choice of standard, but a standards strategy: a consolidated requirements base in which the strictest requirement sets the benchmark.

In the second part of this series, we show how five worlds of standards become one common set of safety goals: from hazard analysis and risk assessment via ASIL, AgPL, MPL, and PL to the principle of the strictest requirement.