Safety-by-Wire® — Safety You Can Verify

The Safety Case Behind Safety-by-Wire®: From the Initial Requirement to Live Operation

At some point in every safety project, there comes a moment when someone from outside picks a random safety objective and says three words: “Show me.” Three parts of this series have described what needs to be shown—the standards strategy, the catalog of objectives with the most stringent requirement, and the fully fail-operational architecture. This fourth and final part deals with that moment itself. And it addresses a unique feature that mitigates this moment in Safety-by-Wire®: The answer was prepared before the system even existed—and it continues to be refined long after others have closed their files.

At a Glance

• The safety case is a structured argument, not a stack of papers: a traceable chain from the safety objective to the test result—and back.
• The verification of Safety-by-Wire® has two unusual endpoints: It begins before the first line of production code—and it does not end with the start of production.
• Requirements-in-the-Loop puts the requirements themselves through simulation testing—unusual in the automotive industry, but inspired by other highly safety-critical industries.
• In between lies the complete chain of evidence: FMEDA and fault tree analysis during design, software-, hardware-, and vehicle-in-the-loop testing on the path to actual operation.
• And running through all phases is a fifth track: independent review—accompanying the process, not merely rubber-stamping it.

“Show me”: The Safety Case as a Framework

The Safety Case is the structured answer to these three words. It links every safety objective to the requirements derived from it, to the architectural decisions that implement them, and to the analyses and tests that demonstrate their effectiveness. What matters here is not the scope of the documentation, but its consistency: Anyone who looks up any given objective must be able to trace the path all the way to the test result—and from every test result back to the question of why that objective exists in the first place.

In Part 2, there was a sentence that might have seemed like a side note at the time: Traceability is unspectacular until someone asks for it—then it’s everything. This fourth part is the part in where that question is asked. And what sets the Safety-by-Wire® framework apart from most others is its construction timeline: The proof has two ends, which is rarely seen in the automotive industry.

Proving it before anything exists: Requirements-in-the-Loop

The most costly class of errors in system development is not programming errors—it is requirements errors. A contradictory, incomplete, or simply unfulfillable requirement is passed down to every subsequent stage: into the architecture, into the code, and into tests that then conscientiously verify the wrong thing. When discovered in the text, a requirements error is a change. When discovered in the field, it is a recall.

That is why the Safety-by-Wire® chain of evidence begins before the first line of production code is written: even the requirements themselves undergo simulation. Requirements-in-the-Loop is not a separate, upstream process, but is embedded within the early system phases themselves—specifically, requirements gathering and analysis, or, in the terminology of Automotive SPICE: SYS.1 and SYS.2. It runs through scenarios before there is a system that could experience them—and thus uncovers contradictions, gaps, and unfulfillable combinations, as long as correcting them involves a text change rather than a redesign. This approach is uncommon in the automotive industry. It is inspired by other highly safety-critical industries—by disciplines in which there is no second chance and proof therefore never begins with the finished system.

Calculate Before Building: FMEDA and Fault Tree Analysis

Analytics, too, does not wait for the right branch of the V-model: FMEDA and fault tree analysis run concurrently with the design during requirements analysis and system architecture—SYS.2 and SYS.3—and they demand more than plausible arguments; they demand numbers. Two analytical tools bear the brunt of this work:

• FMEDA (Failure Modes, Effects, and Diagnostics Analysis) examines the hardware from the bottom up: What types of failures does each component have, which of these are dangerous—and what proportion is detected by diagnostics? This bottom-up approach yields the hardware metrics of the leading standard: proof that single faults are controlled and latent faults are detected.
• Fault Tree Analysis (FTA) takes a top-down approach: It breaks down every undesirable top-level event—such as the loss of steering function—into the combinations of individual events that could lead to it, and quantifies their probability. Only this perspective reveals whether the redundancy architecture delivers on its promise: that no single failure and no plausible combination of failures will compromise the safety objective.

Together, both analyses answer the question that actually lies behind the highest safety rating: not “does it work?” but “how unlikely is it that it will fail in a dangerous way?”—verified against the quantitative thresholds of the standard, not against one’s own gut feeling.

Testing on the Path to Reality: The In-the-Loop Chain

What begins as a requirements simulation continues as a tiered system verification. Software-in-the-Loop tests the functional logic against simulated hardware—electronics, motors, sensors, and ultimately the entire vehicle dynamics. Hardware-in-the-Loop then brings the real control system into the same simulated world, with deliberately injected faults: reproducible, automatable, even for cases that no one would want to provoke on the road. It is precisely here— —that the challenging scenarios from Part 3 are systematically generated: the double fault, the transition in the middle of a maneuver, the communication failure. Vehicle-in-the-Loop connects the real vehicle with the simulated environment. Finally, real-world operation delivers what no simulation can replace: proving its worth under conditions that no one could have imagined.

The Never-Ending Validation

The other unusual end of the figure is on the right. Anyone who has read the two July articles in this series already suspects as much: UN R185 and UN GTR 26 define safety as a property spanning the entire lifecycle. The safety case is thus no longer a final document, but a living one: In-service monitoring observes behavior in the field, software updates follow controlled processes rather than good intentions, and field experience feeds back into development. For a platform, this means specifically: The verification structures must be designed for ongoing updates, not for completion—every observation from operation must be able to find its place in the argumentative framework without having to rebuild it.

The fifth track: the independent perspective

Self-assessment has its limits; the regulatory landscape therefore requires independent verification measures. The crucial question, however, is not whether an independent review is conducted—but when and for how long. An assessment at the end of a project can only evaluate what already exists. An ongoing review identifies weaknesses while they are still correctable.

With Safety-by-Wire®, this track spans all four phases: The independent assessors mentioned in Part 3 do not merely review architectural decisions—they accompany the verification process throughout its entire course—from the initial requirement through to operation, in accordance with the documented development and verification status. For customer projects, this means: The platform does not enter the project with a promise, but with a verification basis that has already withstood critical external scrutiny.

“We started proving our case before there was anything to show—and we don’t stop where others are done.” Kevin Arnold, CEO of Arnold NextG GmbH

What OEMs, integrators, and operators should clarify now

• When does the verification process begin at the supplier—with the finished system or as early as the requirements phase?
• Is the safety case consistently traceable—from the safety objective to the test results and back—or is it a collection of individual documents?
• What quantitative evidence is available (FMEDA, FTA)—and do its assumptions align with the real-world operating environment and mission duration?
• Which failure scenarios were actually injected into the in-the-loop chain—and which were merely analyzed?
• Who conducted the independent verification, and at what stage—concurrently with development or only at the end?
• How is safety continued to be demonstrated after production begins—through monitoring, update processes, or field experience?

Anyone who answers these questions only during the approval phase is negotiating with the regulatory authority about the past—and the past cannot be corrected. Arnold NextG has therefore made verification a core feature of the platform, not an afterthought to the project: It begins before the first line of code is written and does not end with the start of production. The target baseline, architecture, analyses, and guided review form a pre-developed foundation upon which the vehicle- and application-specific reasoning is built. This does not replace either the overall vehicle safety case or the manufacturer’s type approval—but it shortens the path to achieving them, because every project begins with verified answers rather than open questions.

Conclusion of the Series

Four parts, one arc: Regulatory requirements demand end-to-end verification (July articles). The standards provide the language for this (Part 1). Consolidation transforms this into a catalog of objectives with the most stringent requirement as the benchmark (Part 2). The architecture implements it in a fully fail-operational manner (Part 3). And the safety case makes the whole process verifiable—all the way through to ongoing operation (Part 4).

This is the functional safety strategy behind Safety-by-Wire®: not a collection of individual measures, but a chain with no weak links—from the standard to the motion. Ultimately, safety is not a state that is achieved. It is a property that must be demonstrated. Every day, in every domain, throughout the entire lifecycle.