Safety-by-Wire® — The Principle of the Strictest Requirement

From Five Standards Landscapes to a Single Catalog of Objectives: How Safety-by-Wire® Consolidates Safety Objectives

In the first part of this series, we laid out the standards landscape behind Safety-by-Wire®: five standards frameworks for functional safety, supplemented by SOTIF, cybersecurity, and homologation. But a map alone does not answer any questions. It merely shows where answers must be found. This second part focuses on the next step: How do five standards frameworks translate into concrete safety objectives—and how does this result in a single catalog that applies equally to on-road vehicles, in the field, on construction sites, and in warehouses? The short answer: through systematic analysis, cross-standard mapping—and a simple principle that always applies when in doubt.

At a Glance

• Safety goals don’t just fall from the sky: They arise from systematic hazard analysis and risk assessment (HARA)—driving situations multiplied by malfunctions, evaluated according to severity, exposure, and controllability.
• ASIL, SIL, AgPL, MPL, and PL measure the same underlying risk in different languages—with different assumptions regarding the environment, speed, and operator role. The letters are not interchangeable, but they can be translated.
• The standards themselves provide the translation: mapping tables map AgPL, MPL, and PL to the ASIL scale.
• With Safety-by-Wire®, a simple principle applies after consolidation: When in doubt, the most stringent requirement always sets the standard—up to ASIL D for primary motion functions.
• The result is a single set of objectives instead of five parallel sets: formulated once, valid across all domains, from the very start of platform development.

It all starts with the hazard: the HARA

Every safety case begins with an uncomfortable exercise: systematically thinking through what could go wrong. The hazard analysis and risk assessment—established as HARA in ISO 26262—combines two dimensions for this purpose: a vehicle’s operating situations and the possible malfunctions of its systems. An unintended steering input at highway speeds. A loss of braking power on a downhill slope. Unintended forward movement while maneuvering through a crowd.

Each of these combinations is evaluated—based on the severity of potential damage, the probability of encountering the situation, and whether a human could still control the situation. This evaluation yields a risk classification, and that classification determines the safety target. The logic is the same across all standards; the underlying assumptions are not: ISO 25119 focuses on field work and proximity to operators, ISO 19014 on construction site traffic with personnel in the immediate vicinity, and EN 1175 on narrow warehouse aisles. Anyone building a platform for all these scenarios therefore does not conduct a single analysis, but several—each with its own perspective. (Graph, see above)

What ASIL, SIL, AgPL, MPL, and PL Really Mean

At first glance, the risk metrics of these five standards seem like the same idea expressed in different alphabets—and at their core, that’s true. But a closer look reveals more:

• ASIL (ISO 26262) rates systems from A to D and explicitly factors in the driver’s ability to control the vehicle—an assumption that must be reevaluated in driverless operation. We’ll return to this in Part 3.
• SIL (IEC 61508) is the generic, highly probabilistic scale: It focuses on the failure probabilities of safety-related functions and serves as the reference point beyond the domain-specific standards.
• AgPL (ISO 25119) applies this logic to agricultural and forestry machinery—with its own assumptions regarding speeds, the work environment, and the role of the operator.
• MPL (ISO 19014) does the same for earth-moving machinery, whose risk profile is characterized by changing personnel in the immediate work area.
• PL (ISO 13849, via EN 1175) takes a more structural approach—focusing on control architecture, failure probabilities, and diagnostic coverage—and is the language of machine safety and intralogistics.

The most important insight here: An “ASIL D” is not a “SIL 4,” and a “PL e” is not an “AgPL e”—the scales embody their own domain assumptions. Anyone who equates them without translating is comparing terms rather than meanings.

Mapping: When Standards Translate Each Other

The good news: The standards community has recognized the translation problem—and solved it itself. The standards provide mapping tables that align the scales with one another, for example in the annexes of ISO 25119 and ISO 19014. This allows an AgPL- or PL-rated safety objective to be mapped to the ASIL scale—not as a rough analogy, but with normative support. The Machine Performance Levels of ISO 19014 are first mapped via the PL scale before the transition to the ASIL scale takes place.

This is precisely where the consolidation of Safety-by-Wire® comes into play: The safety objectives from all analyses conducted are mapped onto a common scale via these tables—the ASIL scale of the leading standard ISO 26262. Where the same objective appears in multiple domains but is assessed with varying levels of stringency, a simple principle applies: The most stringent requirement prevails. No negotiation, no averaging, no exceptions based on market opportunities. This principle is inconvenient during development—and that is precisely why it is valuable for verification.

A catalog that applies everywhere

At the end of this consolidation process stands a single catalog of safety objectives—formulated at the system level, valid across all application domains. At the principle level, the objectives for the primary motion functions are exactly as one would expect, and that is precisely their strength: Prevent unintended steering movements. Prevent loss of braking function. Prevent unintended propulsion. These objectives are subject to the highest classification under the governing standard—ASIL D. In addition, there are objectives for supporting functions, ranging from ensuring a safe stop to signaling, each with the classification required by the most stringent applicable standards.

What is crucial is what this catalog is not: it is not a retroactive compilation of individual projects, but rather the foundation that preceded the architecture. Every design decision for the platform—redundancies, diagnostics, degradation logic—can be traced back to an objective in this catalog. This traceability is unspectacular until a regulatory authority or assessor asks about it. Then it becomes everything.

What OEMs, integrators, and operators should clarify now

• On which HARA is a supplier’s ASIL claim based—and do their operating conditions actually cover their own deployment scenarios?
• Are the safety objectives formulated solely for road use—or do they also apply in the field, on construction sites, and in warehouse aisles?
• Are the assumptions documented, particularly regarding a driver’s ability to control the vehicle—and do they still apply during driverless operation?
• How are decisions made when the same objective is evaluated with varying levels of stringency—does the strictest requirement prevail, or the most favorable one?
• Is the list of objectives updated when a new application domain or country is added—and who is responsible for that?

Anyone who waits to answer these questions until the specifications have long since been written is trading safety for deadline pressure—and almost always loses both in the process. That’s why Arnold NextG has placed the consolidated catalog of objectives at the very beginning of platform development. It does not replace the application-specific analysis in a customer project—but it ensures that this analysis is built on a foundation that already accounts for the strictest requirements, rather than having to retrofit them later.

Conclusion

Five standards frameworks, one evaluation logic, one principle: The consolidation of safety objectives is the point at which a standards strategy becomes a robust foundation. Using the most stringent requirement as a benchmark demands discipline during development—and pays dividends in verification, scalability, and every new application domain.

In the third part of this series, we’ll show how the catalog of objectives is transformed into an architecture: why, in Safety-by-Wire®, the safe state means continuing to drive—and what end-to-end redundancy truly means.