Für autonome und teleoperierte Systeme greift diese Sichtweise zu kurz. Sobald Fahrzeugkontrolle vollständig digital erfolgt, verändert sich die Rolle der Rückmeldung grundlegend. Sie ist nicht mehr Ausdruck eines Fahrgefühls, sondern Teil der Systemfunktion.

Rückmeldung ist Information

Force Feedback wird häufig aus der Perspektive des Menschen betrachtet. Tatsächlich ist es jedoch in erster Linie eine physikalische Rückkopplung.

Es entsteht aus den Kräften zwischen Reifen, Fahrbahn und Fahrzeug und bildet Zustände ab, die sich nicht vollständig aus externer Sensorik ableiten lassen. Dazu gehören unter anderem:

• Haftungsgrenzen
  • Reibwertänderungen
  • Schlupfzustände
  • Übergänge von stabiler zu instabiler Fahrzeugdynamik

Diese Effekte treten häufig früher und subtiler auf, als sie von kamerabasierten Systemen oder klassischen Umfeldsensoren zuverlässig erkannt werden können.

Was dem AD-Stack ohne physische Rückkopplung fehlt

Autonome Fahrsysteme basieren auf Modellen, die Annahmen über Fahrzeugverhalten, Reibwerte und Umgebungsbedingungen treffen. In der Realität sind diese Annahmen jedoch immer mit Unsicherheit behaftet. Ohne physische Rückkopplung bleibt dem System häufig nur die indirekte Beobachtung der Auswirkungen seiner eigenen Befehle. Erst wenn das Fahrzeug bereits beginnt, von der geplanten Trajektorie abzuweichen, wird sichtbar, dass die zugrunde liegenden Annahmen nicht mehr gültig sind.

Gerade bei wechselnden Fahrbahnzuständen – etwa bei Nässe, Eis oder losem Untergrund – kann dies dazu führen, dass Manöver angefordert werden, die physikalisch nicht mehr sicher umsetzbar sind. Physikalisch korrektes Force Feedback schließt diese Lücke, indem es unmittelbar sichtbar macht, wie viel physische Reserve tatsächlich vorhanden ist.

Force Feedback als Teil der Regelung

Wird Force Feedback systemisch gedacht, ist es kein nachgelagerter Effekt, sondern Teil des Regelkreises. Die Rückführung realer Kräfte ermöglicht es, kritische Zustände frühzeitig zu erkennen und in die Entscheidungslogik einzubeziehen.

Autonome Systeme reagieren damit nicht erst, wenn Abweichungen sichtbar werden, sondern können Entwicklungen antizipieren, bevor sie kritisch werden. Force Feedback wird so zu einem zusätzlichen sensorischen Kanal für den AD-Stack – physisch statt visuell oder akustisch.

Einfluss auf die Fahrstrategie

Die Integration physischer Rückkopplung hat direkte Auswirkungen auf die Fahrstrategie autonomer Systeme. Geschwindigkeit, Lenkwinkel und Beschleunigung lassen sich nicht ausschließlich aus Umgebung und Geometrie ableiten, sondern müssen kontinuierlich mit der realen Fahrdynamik abgeglichen werden.

Ohne diese Rückkopplung bleibt Autonomie zwangsläufig entweder konservativ oder riskant: Entweder werden große Sicherheitsreserven eingeplant, oder es entstehen Situationen, in denen physikalische Grenzen unerwartet überschritten werden. Physikalisch korrektes Force Feedback ermöglicht hingegen eine adaptive Fahrstrategie, die sich an den tatsächlichen physikalischen Bedingungen orientiert.

Mensch und System im selben Regelkreis

In teleoperierten oder überwachten Szenarien wird der Mensch wieder Teil des Systems. Force Feedback übernimmt hier eine doppelte Funktion: Es vermittelt physische Zustände an den Operator und ermöglicht gleichzeitig eine konsistente Übergabe zwischen autonomer Regelung und menschlicher Kontrolle.

Entscheidend ist dabei, dass beide auf dieselbe physische Realität zugreifen. Rückmeldung wird nicht interpretiert oder simuliert, sondern basiert auf realen Kräften. Das erhöht die Vorhersagbarkeit und reduziert Diskontinuitäten im Systemverhalten.

Warum physikalisch korrektes Force Feedback selten ist

Die Umsetzung physikalisch korrekter Rückkopplung ist technisch anspruchsvoll. Sie erfordert eine enge Kopplung von Aktorik und Sensorik, eine deterministische Regelung, eine konsistente Systemarchitektur sowie funktionale Sicherheit auch im Fehlerfall.

Normen wie ISO 26262 zur funktionalen Sicherheit definieren grundlegende Anforderungen an sicherheitskritische Systeme, adressieren jedoch nicht automatisch die Qualität physischer Rückkopplung im Regelkreis. In vielen Architekturen wird Force Feedback daher weiterhin als Komfortfunktion behandelt und nicht als integraler Bestandteil der Fahrzeugkontrolle.

Ein Reifeindikator für Drive-by-Wire-Systeme

Ob ein Drive-by-Wire-System physikalisch korrektes Feedback bereitstellt, ist ein verlässlicher Indikator für seinen Reifegrad. Es zeigt, ob Fahrzeugkontrolle als isolierte Ausführung verstanden wird oder als geschlossener Regelkreis zwischen digitaler Entscheidung und physischer Realität.

Plattformen wie NX NextMotion von Arnold NextG verfolgen einen solchen systemischen Ansatz, indem sie Fahrzeugkontrolle als integrierten Regelkreis ausführen und physische Rückkopplung als Teil der Gesamtarchitektur berücksichtigen.

Rückkopplung als Grundlage für Kontrolle

Autonome Systeme müssen nicht nur Entscheidungen treffen, sondern auch ihre eigenen Grenzen verstehen. Physikalisch korrektes Force Feedback macht diese Grenzen sichtbar und nutzbar – für Mensch und Maschine gleichermaßen.

Es verbindet digitale Entscheidungslogik mit realer Physik und macht Fahrzeugkontrolle zu einem adaptiven Prozess. Force Feedback ist damit kein Komfortmerkmal. Es ist ein physischer Sensor für Systemgrenzen.

Ausblick

Im nächsten Beitrag dieser Serie betrachten wir, woher echte Drive-by-Wire-Reife stammt – und warum sie selten aus reinen Autonomieprojekten entsteht, sondern aus Anwendungen, in denen physische Rückkopplung und elektronische Fahrzeugkontrolle seit Jahren unter realen Bedingungen eingesetzt werden.

We control what moves!

weitere Informationen unter: www.arnoldnextg.de/blog

Many discussions about autonomous driving start with an idealized baseline: new vehicle platforms, clean architectures, and fully controlled development environments. In this context, autonomy appears as something that can be designed from the ground up.

This perspective is understandable, but it does not reflect the reality of industrial applications. In practice, autonomy rarely starts from scratch. It emerges in existing vehicles, in operating fleets, and under real-world economic and regulatory constraints. It is precisely there that it is determined whether a technology is not only developable but also deployable.

Existing vehicles are the norm

In industries such as logistics, agriculture, mining, or public transportation, vehicles are already in use. They perform defined tasks, are integrated into processes, and are subject to clear requirements regarding availability, safety, and cost-effectiveness. In these contexts, autonomy is not introduced by replacing existing vehicles, but by further developing them.

This means: New systems must be able to integrate into existing platforms without altering their fundamental structure. Vehicle control thus becomes a matter of adaptability—not of new development.

Platform dependency as a structural obstacle

Many drive-by-wire solutions are closely tied to specific vehicle platforms. They are designed for specific electrical architectures, interfaces, and system logics. This may make sense for new vehicles. For existing platforms, however, it poses a significant hurdle.

Platform-dependent systems can only be transferred with great effort. Any deviation from the original application context requires adjustments, new safety assessments, and additional integration work. Regulatory frameworks such as ISO 26262 for functional safety highlight just how complex such adjustments are. For applications intended to scale beyond individual vehicle platforms, this dependency is not sustainable.

Retrofittability as an Architectural Criterion

Retrofittability is often viewed as a peripheral issue. In fact, it is a key indicator of system maturity. A drive-by-wire system that is retrofittable must function independently of specific vehicle platforms. It must be able to adapt to different mechanical, electrical, and functional constraints without redefining its safety logic.

This capability does not arise during the integration project, but through architectural decisions. Retrofittability is thus not an add-on, but an expression of platform independence.

Platform independence as a system principle

Platform independence does not mean that a system can be deployed unchanged in any environment. It means that the core logic of vehicle control remains stable while the system adapts to different vehicle platforms. This is crucial for autonomous applications.

While perception and decision-making logic are often software-portable, vehicle control is directly tied to physical systems. Only if this control is designed as a standalone, consistent system architecture can it be reliably transferred. Platform independence reduces integration effort, increases transparency, and improves regulatory traceability.

Scaling begins in operation

For operators of autonomous systems, platform independence is not a technical detail but an operational necessity. Fleets rarely consist of homogeneous vehicles. They grow, change, and comprise different generations and types. A system that functions only on a specific platform ties autonomy to individual vehicle projects.

A platform-independent system, on the other hand, ties autonomy to operations. This distinction determines whether autonomous functions remain isolated applications or can be transformed into scalable processes.

Autonomy as an evolutionary process

Autonomy does not arise from a complete fresh start, but through gradual integration into existing systems. Drive-by-wire plays a central role in this: it connects digital decision-making logic with physical vehicle movement. Platform approaches such as NX NextMotion from Arnold NextG follow precisely this approach by designing vehicle control as a standalone, platform-independent, and retrofittable system architecture. This ensures that autonomy is not tied to individual vehicle platforms but is made transferable and scalable.

A benchmark for real-world deployability

The suitability of a drive-by-wire system for autonomous applications is not determined solely by its performance. The decisive factor is whether it can be integrated into existing vehicles without compromising its safety and system logic. Autonomy does not begin with the ideal vehicle, but with the reality of existing fleets. Systems that take this reality into account lay the foundation for the actual introduction of autonomous applications.

Outlook

In the next installment of this series, we will examine an aspect that is often understood as a comfort feature but actually plays a central role in safe vehicle control: physically accurate force feedback and its significance for autonomous and teleoperated systems.

We control what moves!

more information: www.arnoldnextg.com/blog

Viele Diskussionen über autonomes Fahren beginnen mit einer idealisierten Ausgangssituation: neue Fahrzeugplattformen, saubere Architekturen und vollständig kontrollierte Entwicklungsumgebungen. Autonomie erscheint dabei als etwas, das von Grund auf neu entworfen werden kann.

Diese Perspektive ist nachvollziehbar, beschreibt jedoch nicht die Realität industrieller Anwendungen. In der Praxis beginnt Autonomie selten auf der grünen Wiese. Sie entsteht in bestehenden Fahrzeugen, in laufenden Flotten und unter realen wirtschaftlichen und regulatorischen Randbedingungen. Genau dort entscheidet sich, ob eine Technologie nicht nur entwickelbar, sondern auch einsetzbar ist.

Bestehende Fahrzeuge sind der Regelfall

In Branchen wie Logistik, Landwirtschaft, Bergbau oder öffentlichem Verkehr sind Fahrzeuge bereits im Einsatz. Sie erfüllen definierte Aufgaben, sind in Prozesse integriert und unterliegen klaren Anforderungen an Verfügbarkeit, Sicherheit und Wirtschaftlichkeit. Autonomie wird in diesen Kontexten nicht durch den Ersatz bestehender Fahrzeuge eingeführt, sondern durch deren Weiterentwicklung.

Das bedeutet: Neue Systeme müssen sich in bestehende Plattformen integrieren lassen, ohne deren grundlegende Struktur zu verändern. Fahrzeugkontrolle wird damit zu einer Frage der Anpassungsfähigkeit – nicht der Neuentwicklung.

Plattformabhängigkeit als strukturelles Hindernis

Viele Drive-by-Wire-Lösungen sind eng an spezifische Fahrzeugplattformen gebunden. Sie sind auf bestimmte elektrische Architekturen, Schnittstellen und Systemlogiken ausgelegt. Für Neufahrzeuge kann das sinnvoll sein. Für bestehende Plattformen stellt es jedoch eine erhebliche Hürde dar.

Plattformabhängige Systeme lassen sich nur mit hohem Aufwand übertragen. Jede Abweichung vom ursprünglichen Einsatzkontext erfordert Anpassungen, neue Sicherheitsbewertungen und zusätzliche Integrationsarbeit. Normative Rahmenwerke wie ISO 26262 zur funktionalen Sicherheit verdeutlichen, wie aufwendig solche Anpassungen sind. Für Anwendungen, die über einzelne Fahrzeugplattformen hinaus skalieren sollen, ist diese Abhängigkeit nicht tragfähig.

Nachrüstbarkeit als architektonisches Kriterium

Nachrüstbarkeit wird häufig als Randthema betrachtet. Tatsächlich ist sie ein zentraler Indikator für systemische Reife. Ein Drive-by-Wire-System, das nachrüstbar ist, muss unabhängig von spezifischen Fahrzeugplattformen funktionieren. Es muss sich an unterschiedliche mechanische, elektrische und funktionale Randbedingungen anpassen können, ohne seine Sicherheitslogik neu zu definieren.

Diese Fähigkeit entsteht nicht im Integrationsprojekt, sondern durch Architekturentscheidungen. Nachrüstbarkeit ist damit kein Zusatz, sondern Ausdruck von Plattformunabhängigkeit.

Plattformunabhängigkeit als Systemprinzip

Plattformunabhängigkeit bedeutet nicht, dass ein System unverändert in jeder Umgebung eingesetzt werden kann. Sie bedeutet, dass die Kernlogik der Fahrzeugkontrolle stabil bleibt, während sich das System an unterschiedliche Fahrzeugplattformen anpasst. Für autonome Anwendungen ist das entscheidend.

Während Wahrnehmung und Entscheidungslogik häufig softwareseitig portierbar sind, ist Fahrzeugkontrolle unmittelbar an physische Systeme gebunden. Nur wenn diese Kontrolle als eigenständige, konsistente Systemarchitektur ausgelegt ist, lässt sie sich zuverlässig übertragen. Plattformunabhängigkeit reduziert Integrationsaufwand, erhöht Transparenz und verbessert die regulatorische Nachvollziehbarkeit.

Skalierung beginnt im Betrieb

Für Betreiber autonomer Systeme ist Plattformunabhängigkeit keine technische Detailfrage, sondern eine betriebliche Notwendigkeit. Flotten bestehen selten aus homogenen Fahrzeugen. Sie wachsen, verändern sich und bestehen aus unterschiedlichen Generationen und Typen. Ein System, das nur auf einer spezifischen Plattform funktioniert, bindet Autonomie an einzelne Fahrzeugprojekte.

Ein plattformunabhängiges System hingegen bindet Autonomie an den Betrieb. Diese Unterscheidung entscheidet darüber, ob autonome Funktionen isolierte Anwendungen bleiben oder in skalierbare Prozesse überführt werden können.

Autonomie als evolutionärer Prozess

Autonomie entsteht nicht durch einen vollständigen Neubeginn, sondern durch schrittweise Integration in bestehende Systeme. Drive-by-Wire übernimmt dabei eine zentrale Rolle: Es verbindet digitale Entscheidungslogik mit physischer Fahrzeugbewegung. Plattformansätze wie NX NextMotion von Arnold NextG verfolgen genau diesen Ansatz, indem sie Fahrzeugkontrolle als eigenständige, plattformunabhängige und nachrüstbare Systemarchitektur auslegen. Damit wird Autonomie nicht an einzelne Fahrzeugplattformen gebunden, sondern übertragbar und skalierbar gemacht.

Ein Maßstab für reale Einsatzfähigkeit

Die Eignung eines Drive-by-Wire-Systems für autonome Anwendungen zeigt sich nicht nur in seiner Leistungsfähigkeit. Entscheidend ist, ob es sich in bestehende Fahrzeuge integrieren lässt, ohne seine Sicherheits- und Systemlogik zu verlieren. Autonomie beginnt nicht mit dem idealen Fahrzeug, sondern mit der Realität bestehender Flotten. Systeme, die diese Realität berücksichtigen, schaffen die Grundlage für eine tatsächliche Einführung autonomer Anwendungen.

Ausblick

Im nächsten Beitrag dieser Serie betrachten wir einen Aspekt, der häufig als Komfortfunktion verstanden wird, tatsächlich aber eine zentrale Rolle für sichere Fahrzeugkontrolle spielt: physikalisch korrektes Force Feedback und seine Bedeutung für autonome und teleoperierte Systeme.

We control what moves!

Mehr informationen unter www.arnoldnextg.de/blog

In traditional vehicle architectures, safety was closely linked to the concept of coming to a stop. Systems were designed to shut down or transition to a passive state in the event of a fault. The driver served as the higher authority capable of intervening. With increasing automation, this fallback level is no longer available.

An autonomous vehicle operates independently, often in dynamic environments and under real-world operating conditions. In this context, coming to a standstill can create new risks—for example, in moving traffic, in logistics processes, or in safety-critical applications. This shifts the central question: no longer how a system shuts down safely—but how it remains controllable under constraints.

Fail-operational as an operational requirement

Fail-operational is not an additional technical feature, but an operational prerequisite for autonomous systems. A vehicle that comes to a stop in the event of a fault may comply with traditional safety logic, but it is not economically viable in autonomous operation. Autonomous systems must be able to complete tasks in a controlled manner, reach defined states, or safely navigate out of complex situations. This means that the system must not only detect faults but also actively manage them.

It must be able to assess

• which functions are still available
• at what level of performance they are operating
• what priorities apply
• what options for action exist

Such decisions are part of the system architecture—not just the runtime logic. Fail-operational behavior is therefore not an exceptional state, but an intended operating mode.

Why fail-operational cannot be retrofitted

A common misconception is to view fail-operational as an extension of existing safety concepts. In practice, this is not possible.

Fail-operational requires an architecture in which redundancy, monitoring, decision logic, and actuators are coordinated from the outset. It is not merely a matter of having multiple components available, but rather how the system handles degraded states. A system that merely detects that a function has failed is not fail-operational. Only when it can continue to operate in a targeted manner under these conditions does it meet this requirement.

Normative standards such as ISO 26262 on functional safety address safety requirements at the system level but do not automatically define fail-operational behavior during operation.

The difference becomes apparent during operation

In early development phases, it is often difficult to distinguish between fail-safe and fail-operational. Both approaches can be plausibly specified and documented in accordance with standards.

The difference only becomes apparent during actual operation. It is then that it becomes clear

• whether systems can stably manage transitions between states
• whether degraded operating modes can be maintained in a controlled manner
• whether the vehicle reacts predictably even under restricted conditions

This capability is particularly crucial in autonomous applications. Uncontrolled state transitions or abrupt shutdowns can themselves become safety risks. Fail-operational is thus less a question of certification than a question of system maturity.

Why fail-operational is often underestimated

In many autonomous driving programs, the focus is on perception systems and decision-making algorithms. Vehicle control is often viewed as an infrastructural prerequisite, not as a limiting factor. It is only during the transition from test operations to real-world applications that it becomes clear that without fail-operational control, many functions are theoretically possible but cannot be operated in practice.

Fail-operational design determines whether a system merely functions—or can actually be operated. At this point, fundamental architectural decisions can no longer be corrected.

Vehicle control as a prerequisite for autonomy

For autonomous vehicle architectures, this represents a fundamental shift in perspective. Safety no longer arises from shutdown, but from the controlled continuation of motion. The ability to remain capable of action even under restricted conditions becomes a prerequisite for operation, scaling, and acceptance.

Platform approaches such as NX NextMotion from Arnold NextG address precisely this requirement by integrating steering, braking, and propulsion into a shared, multi-redundant, and fail-operational drive-by-wire architecture. This means that vehicle control is no longer understood as a reaction to errors, but as a continuously secured system function.

A new benchmark for vehicle control

For developers, integrators, and operators of autonomous systems, this shifts the key evaluation criterion. The question is no longer: Is a system safe in the event of a failure? But rather: Can it continue to operate safely in the event of a failure? This capability defines the transition from assisted to autonomous systems—and places new demands on the underlying vehicle architecture.

Outlook

In the next article in this series, we will examine why platform independence and retrofitability are not peripheral issues, but rather central prerequisites for the real-world introduction of autonomous systems.

WE CONTROL WHAT MOVES

Further information: www.arnoldnextg.com/blog

In klassischen Fahrzeugarchitekturen war Sicherheit eng mit dem Konzept des Stillstands verknüpft. Systeme wurden so ausgelegt, dass sie im Fehlerfall abschalten oder in einen passiven Zustand übergehen. Der Fahrer fungierte dabei als übergeordnete Instanz, die eingreifen konnte. Mit zunehmender Automatisierung entfällt diese Rückfallebene.

Ein autonomes Fahrzeug operiert eigenständig, häufig in dynamischen Umgebungen und unter realen Einsatzbedingungen. In diesem Kontext kann Stillstand neue Risiken erzeugen – etwa im fließenden Verkehr, in logistischen Prozessen oder bei sicherheitskritischen Anwendungen. Damit verschiebt sich die zentrale Fragestellung: Nicht mehr, wie ein System sicher abschaltet – sondern wie es unter Einschränkungen kontrollierbar bleibt.

Fail-operational als betriebliche Anforderung

Fail-operational ist kein technisches Zusatzfeature, sondern eine betriebliche Voraussetzung für autonome Systeme. Ein Fahrzeug, das im Fehlerfall stehen bleibt, erfüllt zwar klassische Sicherheitslogiken, ist jedoch im autonomen Betrieb nicht wirtschaftlich nutzbar. Autonome Systeme müssen in der Lage sein, Aufgaben kontrolliert zu Ende zu führen, definierte Zustände zu erreichen oder sich aus komplexen Situationen sicher herauszubewegen. Das bedeutet: Das System muss Fehler nicht nur erkennen, sondern aktiv mit ihnen umgehen.

Es muss bewerten können,

• welche Funktionen noch verfügbar sind
• in welcher Qualität sie arbeiten
• welche Prioritäten gelten
• welche Handlungsoptionen bestehen

Solche Entscheidungen sind Teil der Systemarchitektur – nicht der Laufzeitlogik allein. Fail-operationales Verhalten ist damit kein Ausnahmezustand, sondern ein vorgesehener Betriebsmodus.

Warum fail-operational nicht nachrüstbar ist

Ein häufiges Missverständnis besteht darin, fail-operational als Erweiterung bestehender Sicherheitskonzepte zu betrachten. In der Praxis ist das nicht möglich.

Fail-operational erfordert eine Architektur, in der Redundanz, Überwachung, Entscheidungslogik und Aktorik von Beginn an aufeinander abgestimmt sind. Es geht nicht nur darum, mehrere Komponenten vorzuhalten, sondern darum, wie das System mit degradierten Zuständen umgeht. Ein System, das lediglich erkennt, dass eine Funktion ausgefallen ist, ist nicht fail-operational. Erst wenn es unter diesen Bedingungen gezielt weiterarbeiten kann, erfüllt es diese Anforderung.

Normative Grundlagen wie ISO 26262 zur funktionalen Sicherheit adressieren Sicherheitsanforderungen auf Systemebene, definieren jedoch nicht automatisch fail-operationales Verhalten im Betrieb.

Der Unterschied zeigt sich im Betrieb

In frühen Entwicklungsphasen lassen sich fail-safe und fail-operational oft nur schwer unterscheiden. Beide Ansätze können plausibel spezifiziert und normgerecht dokumentiert werden.

Der Unterschied zeigt sich erst im realen Betrieb. Dann wird sichtbar,

• ob Systeme Übergänge zwischen Zuständen stabil beherrschen
• ob degradierte Betriebsmodi kontrolliert gehalten werden können
• ob das Fahrzeug auch unter eingeschränkten Bedingungen vorhersehbar reagiert

Gerade in autonomen Anwendungen ist diese Fähigkeit entscheidend. Unkontrollierte Zustandswechsel oder abrupte Abschaltungen können selbst zu Sicherheitsrisiken werden. Fail-operational ist damit weniger eine Frage der Zertifizierung als eine Frage der Systemreife.

Warum fail-operational oft unterschätzt wird

In vielen Autonomieprogrammen liegt der Fokus auf Wahrnehmungssystemen und Entscheidungsalgorithmen. Fahrzeugkontrolle wird häufig als infrastrukturelle Voraussetzung betrachtet, nicht als limitierender Faktor. Erst im Übergang vom Testbetrieb in reale Anwendungen wird deutlich, dass ohne fail-operationale Steuerung viele Funktionen zwar theoretisch möglich sind, praktisch jedoch nicht betrieben werden können.

Fail-operationales Design entscheidet darüber, ob ein System lediglich funktioniert – oder tatsächlich betrieben werden kann. Zu diesem Zeitpunkt lassen sich grundlegende Architekturentscheidungen nicht mehr korrigieren.

Fahrzeugkontrolle als Voraussetzung für Autonomie

Für autonome Fahrzeugarchitekturen bedeutet dies einen grundlegenden Perspektivwechsel. Sicherheit entsteht nicht mehr durch Abschaltung, sondern durch kontrollierte Fortsetzung von Bewegung. Die Fähigkeit, auch unter eingeschränkten Bedingungen handlungsfähig zu bleiben, wird zur Voraussetzung für Betrieb, Skalierung und Akzeptanz.

Plattformansätze wie NX NextMotion von Arnold NextG adressieren genau diese Anforderung, indem sie Lenkung, Bremse und Antrieb in einer gemeinsamen, multi-redundanten und fail-operationalen Drive-by-Wire-Architektur zusammenführen. Damit wird Fahrzeugkontrolle nicht als Reaktion auf Fehler verstanden, sondern als kontinuierlich abgesicherte Systemfunktion.

Ein neuer Maßstab für Fahrzeugkontrolle

Für Entwickler, Integratoren und Betreiber autonomer Systeme verschiebt sich damit die zentrale Bewertungsgröße. Nicht mehr: Ist ein System im Fehlerfall sicher? Sondern: Kann es im Fehlerfall weiterhin sicher handeln? Diese Fähigkeit definiert den Übergang von assistierten zu autonomen Systemen – und stellt neue Anforderungen an die zugrunde liegende Fahrzeugarchitektur.

Ausblick

Im nächsten Beitrag dieser Serie betrachten wir, warum Plattformunabhängigkeit und Nachrüstbarkeit keine Randthemen sind, sondern zentrale Voraussetzungen für die reale Einführung autonomer Systeme.

WE CONTROL WHAT MOVES

weiterführende Informationen unter: www.arnoldnextg.de/blog

In the discussion surrounding electronic vehicle control, it is often implicitly assumed that a functioning overall system can be assembled from high-quality individual components. Steer-by-wire steering, brake-by-wire braking, redundant control units—all these technologies exist and, in many cases, are already safety-certified.

The conclusion seems obvious: if every single component is safe on its own, the overall system must also be safe. From a technical perspective, however, this assumption falls short. This is because the safety, availability, and controllability of autonomous vehicles do not result from the sum of individual functions—but rather from the behavior of the overall system.

Why Safety Is Not Additive

In traditional vehicle architectures, it was long acceptable to view safety primarily at the component level. The driver served as the overarching authority who could intervene in case of doubt. Systems were therefore often designed to transition to a safe state in the event of a failure—for example, by shutting down or reverting to mechanical functions. Autonomous vehicles fundamentally change this logic.

When there is no longer a driver present, the system itself becomes the final decision-maker. Safety then no longer arises from isolated functions, but from the coordinated interaction of all subsystems—including their interfaces, dependencies, and failure modes. For example, a brake-by-wire module can be ASIL-D compliant, as can a steer-by-wire system in accordance with the functional safety requirements of ISO 26262.

But what matters is how both systems behave when working together:
What happens if multiple functions are operating in degraded mode simultaneously?
How do systems react when communication paths are limited?
What priorities apply in borderline cases? Such questions cannot be answered at the component level. They must be decided at the system level.

The integration gap in practice

This is precisely where a structural challenge in the market becomes apparent. Many OEMs, system integrators, or operators of autonomous fleets receive highly developed drive-by-wire modules from suppliers. These components are powerful, certified, and technically mature. What they often fail to provide, however, is a definitive statement regarding the behavior of the overall system.

The consequence: Responsibility for integration, safety justification, and fail-operational strategies shifts to the vehicle manufacturer or integrator. They must decide how components are combined, how redundancies interact, and how the vehicle remains controllable in the event of a failure. Thus, integration itself becomes a safety-critical system task.

Drive-by-Wire as an Architectural Issue

A true drive-by-wire system therefore does not begin with the selection of individual components, but with the architecture. Key elements include, among others:

• clear separation and redundancy of safety-critical functions
• deterministic communication paths in the vehicle network
• coordinated control and monitoring mechanisms
• consistent energy management
• a system-wide safety concept

What matters here is not only that redundancy is present, but how it is utilized. Redundancy without systemic logic leads, at best, to a standstill—and, at worst, to unpredictable behavior. Systemic thinking therefore means integrating these aspects from the very beginning, rather than only during integration.

Platform independence as a system criterion

Another hallmark of systemic maturity is platform independence. Many drive-by-wire solutions are tightly tied to specific vehicle platforms. This facilitates series integration but complicates portability to other vehicle types or existing fleets. However, autonomous applications rarely emerge exclusively on new platforms. Often, existing vehicles are automated or teleoperated.

For such scenarios, drive-by-wire architectures are required that can be adapted to different vehicle platforms without redefining their safety logic. This capability, too, is not a property of individual components, but rather the result of a systemic architectural decision.

When Vehicle Control Becomes System Responsibility

System responsibility means more than just supplying individual components. It also encompasses the ability to make statements about a vehicle’s overall behavior—technically, regulatorily, and operationally.

Platform approaches such as NX NextMotion from Arnold NextG pursue precisely this systemic approach. The drive-by-wire control platform integrates steering, braking, propulsion, and other vehicle functions into a shared, multi-redundant, and fail-operational architecture. The goal of such architectures is to view vehicle control not as a collection of individual functions, but as a coherent overall system.

A Necessary Shift in Perspective

For developers, integrators, and operators of autonomous systems, this raises a central question. No longer: Which components are available? But rather:
Who takes responsibility for the system? As long as drive-by-wire is primarily viewed as a modular system, autonomous driving remains an integration project. Only when vehicle control is conceived as an integrated overall system does the foundation for scalable and safe operation of autonomous vehicles emerge.

Outlook

In the next post in this series, we’ll examine a frequently misunderstood core concept of modern vehicle architectures: the difference between fail-safe and fail-operational—and why this distinction is not merely theoretical but practically crucial for autonomous systems.

WE CONTROL WHAT MOVES

more information: www.arnoldnextg.com/blog

In der Diskussion um elektronische Fahrzeugsteuerung wird häufig implizit angenommen, dass sich ein funktionierendes Gesamtsystem aus hochwertigen Einzelkomponenten zusammensetzen lässt. Steer-by-Wire-Lenkung, Brake-by-Wire-Bremsen, redundante Steuergeräte – all diese Technologien existieren und sind in vielen Fällen bereits sicherheitszertifiziert.

Die Schlussfolgerung scheint naheliegend: Wenn jede einzelne Komponente für sich sicher ist, muss das Gesamtsystem ebenfalls sicher sein. Technisch betrachtet greift diese Annahme jedoch zu kurz. Denn Sicherheit, Verfügbarkeit und Kontrollierbarkeit autonomer Fahrzeuge entstehen nicht durch die Addition einzelner Funktionen – sondern durch das Verhalten des Gesamtsystems.

Warum Safety nicht additiv ist

In klassischen Fahrzeugarchitekturen war es lange zulässig, Sicherheit primär auf Komponentenebene zu betrachten. Der Fahrer fungierte als übergeordnete Instanz, die im Zweifel eingreifen konnte. Systeme wurden daher häufig so ausgelegt, dass sie im Fehlerfall in einen sicheren Zustand übergehen – beispielsweise durch Abschaltung oder durch Rückfall auf mechanische Funktionen. Autonome Fahrzeuge verändern diese Logik grundlegend.

Wenn kein Fahrer mehr vorhanden ist, wird das System selbst zum letzten Entscheidungsträger. Sicherheit entsteht dann nicht mehr durch isolierte Funktionen, sondern durch das koordinierte Zusammenspiel aller Subsysteme – einschließlich ihrer Übergänge, Abhängigkeiten und Fehlermodi. Ein Brake-by-Wire-Modul kann beispielsweise ASIL-D-konform sein, ebenso ein Steer-by-Wire-System gemäß den Anforderungen der funktionalen Sicherheit nach ISO 26262.

Doch entscheidend ist, wie sich beide Systeme im Zusammenspiel verhalten:
Was passiert, wenn mehrere Funktionen gleichzeitig degradiert arbeiten?
Wie reagieren Systeme bei eingeschränkten Kommunikationspfaden?
Welche Prioritäten gelten im Grenzfall? Solche Fragen lassen sich nicht auf Komponentenebene beantworten. Sie müssen auf Systemebene entschieden werden.

Die Integrationslücke in der Praxis

Genau hier zeigt sich eine strukturelle Herausforderung im Markt. Viele OEMs, Systemintegratoren oder Betreiber autonomer Flotten erhalten von Zulieferern hochentwickelte Drive-by-Wire-Bausteine. Diese Komponenten sind leistungsfähig, zertifiziert und technisch ausgereift. Was sie jedoch häufig nicht liefern, ist eine verbindliche Aussage über das Verhalten des Gesamtsystems.

Die Konsequenz: Die Verantwortung für Integration, Safety-Argumentation und fail-operationale Betriebsstrategien verschiebt sich zum Fahrzeughersteller oder Integrator. Dieser muss entscheiden, wie Komponenten kombiniert werden, wie Redundanzen zusammenspielen und wie das Fahrzeug im Fehlerfall weiterhin kontrollierbar bleibt. Damit wird Integration selbst zu einer sicherheitskritischen Systemaufgabe.

Drive-by-Wire als Architekturfrage

Ein echtes Drive-by-Wire-System beginnt daher nicht bei der Auswahl einzelner Komponenten, sondern bei der Architektur. Zu den zentralen Elementen gehören unter anderem:

• klare Trennung und Redundanz sicherheitskritischer Funktionen
• deterministische Kommunikationspfade im Fahrzeugnetzwerk
• abgestimmte Regelungs- und Überwachungsmechanismen
• konsistentes Energiemanagement
• ein systemweites Safety-Konzept

Entscheidend ist dabei nicht nur, dass Redundanz vorhanden ist, sondern wie sie genutzt wird. Redundanz ohne systemische Logik führt im besten Fall zu Stillstand – im ungünstigsten Fall zu unvorhersehbarem Verhalten. Systemdenken bedeutet daher, diese Aspekte von Beginn an zusammenzuführen und nicht erst während der Integration.

Plattformunabhängigkeit als Systemkriterium

Ein weiteres Merkmal systemischer Reife ist Plattformunabhängigkeit. Viele Drive-by-Wire-Lösungen sind eng an spezifische Fahrzeugplattformen gebunden. Das erleichtert Serienintegration, erschwert jedoch die Übertragbarkeit auf andere Fahrzeugtypen oder bestehende Flotten. Autonome Anwendungen entstehen jedoch selten ausschließlich auf neuen Plattformen. Häufig werden bestehende Fahrzeuge automatisiert oder teleoperiert.

Für solche Szenarien sind Drive-by-Wire-Architekturen erforderlich, die sich an unterschiedliche Fahrzeugplattformen anpassen lassen, ohne ihre Sicherheitslogik neu zu definieren. Auch diese Fähigkeit ist keine Eigenschaft einzelner Komponenten, sondern das Ergebnis einer systemischen Architekturentscheidung.

Wenn Fahrzeugkontrolle zur Systemverantwortung wird

Systemverantwortung bedeutet mehr als die Lieferung einzelner Bauteile. Sie umfasst auch die Fähigkeit, Aussagen über das Gesamtverhalten eines Fahrzeugs zu treffen – technisch, regulatorisch und betrieblich.

Plattformansätze wie NX NextMotion von Arnold NextG verfolgen genau diesen systemischen Ansatz. Die Drive-by-Wire-Steuerungsplattform integriert Lenkung, Bremse, Antrieb und weitere Fahrzeugfunktionen in einer gemeinsamen, multi-redundanten und fail-operationalen Architektur. Ziel solcher Architekturen ist es, Fahrzeugkontrolle nicht als Sammlung einzelner Funktionen zu betrachten, sondern als kohärentes Gesamtsystem.

Ein notwendiger Perspektivwechsel

Für Entwickler, Integratoren und Betreiber autonomer Systeme ergibt sich daraus eine zentrale Frage. Nicht mehr: Welche Komponenten stehen zur Verfügung? Sondern:
Wer übernimmt Verantwortung für das System? Solange Drive-by-Wire primär als Baukasten verstanden wird, bleibt autonomes Fahren ein Integrationsprojekt. Erst wenn Fahrzeugkontrolle als integriertes Gesamtsystem gedacht wird, entsteht die Grundlage für skalierbaren und sicheren Betrieb autonomer Fahrzeuge.

Ausblick

Im nächsten Beitrag dieser Serie betrachten wir einen oft missverstandenen Kernbegriff moderner Fahrzeugarchitekturen: den Unterschied zwischen fail-safe und fail-operational – und warum diese Unterscheidung für autonome Systeme nicht theoretisch, sondern praktisch entscheidend ist.

WE CONTROL WHAT MOVES

weiterführende Informationen unter www.arnoldnextg.de/Blog

Autonomous driving is usually discussed in terms of sensor technology, AI, and computing power. However, one key prerequisite often remains in the background: the safe control of vehicle movement. Electronic steering, braking, and drive systems have been part of modern vehicle architectures for years. Accordingly, many consider X-by-wire to be a mature technology. Established supply chains, well-known industry players, and numerous series applications give the impression of a largely decided market.

However, a closer look reveals a different picture – especially where drive-by-wire is not understood as a comfort or assistance function, but as the basis for autonomous driving or teleoperation. This is because what is often referred to as drive-by-wire today is usually individual solutions or subsystems in practice. Fully integrated, fail-operational vehicle control at the system level remains the exception.

Components are not the same as systems

From a technical point of view, drive-by-wire is not a single product, but an architectural issue. A true drive-by-wire system does not just replace mechanical connections with electrical signals. It must ensure that a vehicle remains controllable under all operating conditions – even if individual components fail.

This includes, among other things:

• an integrated combination of actuators, sensors, and control units
• Redundant communication and power supply
• a consistent software and control architecture
• A system-wide safety concept
• clear responsibility for the overall behavior of the vehicle

The safety requirements for such systems are based, among other things, on standards such as ISO 26262 for functional safety. In practice, however, OEMs or system integrators often do not receive complete systems, but rather individual components – such as steer-by-wire or brake-by-wire modules, each with its own certification.

The integration into the overall system, the definition of fail-operational behavior, and the overall safety argumentation therefore often remain with the vehicle manufacturer. This is not a quality defect of individual components, but the result of a market that has historically grown along product lines rather than along system responsibility.

Why large suppliers rarely deliver complete systems

In retrospect, this situation is understandable. Many drive-by-wire solutions have evolved from existing mechanical vehicle architectures. They were developed for vehicles in which a human being is available as a last resort. Accordingly, fail-safe concepts dominate, in which a system switches to a safe state in the event of a fault – for example, by shutting down or handing over control to the driver.

However, autonomous vehicles have different requirements. If there is no driver, the system cannot simply shut down. It must be able to continue operating in a controlled manner. This requires fail-operational system architectures in which redundancy, fault detection, and continued operation are considered systemically from the outset.

This topic is also becoming increasingly important from a regulatory perspective. International regulations such as UNECE Regulation R79 for electronic steering systems define requirements for safety-critical vehicle control.

A market at the system level – and that’s exactly why it’s open

At the component level, the drive-by-wire market is well developed. At the system level, however, this is not the case. Worldwide, there are only a limited number of companies that can actually supply a complete drive-by-wire system – including hardware, software, redundancy concept, and system-wide safety argumentation from a single source.

Even rarer are solutions that work independently of the platform and are suitable for both new vehicle platforms and retrofitting existing fleets. Especially in areas such as logistics, agriculture, mining, construction, defense, or public transportation, autonomy rarely starts on a completely new platform. Existing vehicles are often automated or teleoperated. This means that the retrofitability of drive-by-wire systems is becoming more central to architectural decisions.

Platform approaches such as Arnold NextG’s NX NextMotion drive-by-wire control platform target precisely this system level: they integrate steering, brakes, drive, and other vehicle functions into a common, multi-redundant, and fail-operational control architecture—regardless of the vehicle platform.

Vehicle control as the foundation of autonomous systems

The discussion about autonomous mobility is often dominated by perception systems and artificial intelligence. But even the most powerful AI can only move a vehicle as safely as the underlying control architecture allows. Only when vehicle control is understood as an integrated system – and not as a collection of individual components – can autonomy be reliably transferred into real-world applications.

Against this backdrop, new platform approaches for fully electronic vehicle control are emerging. Platforms such as NX NextMotion, for example, aim to combine steering, brakes, drive, and other vehicle functions in a common, multi-redundant drive-by-wire architecture. The market for true drive-by-wire is therefore far from decided. Not because of a lack of technology, but because systems thinking, architectural responsibility, and operational experience rarely come together.

Outlook

In the next article in this series, we will look at a key architectural decision in modern vehicle control: the difference between fail-safe and fail-operational – and why this distinction is practically crucial for autonomous systems.

WE CONTROL WHAT MOVES!

Further information is available at: www.arnoldnextg.com/blog

Autonomes Fahren wird meist über Sensorik, KI und Rechenleistung diskutiert. Eine zentrale Voraussetzung bleibt dabei oft im Hintergrund: die sichere Kontrolle von Fahrzeugbewegung. Elektronische Lenkung, Bremsen und Antriebssysteme sind seit Jahren Bestandteil moderner Fahrzeugarchitekturen. Entsprechend gilt X-by-Wire vielen als ausgereifte Technologie. Etablierte Lieferketten, bekannte Industrieakteure und zahlreiche Serienanwendungen vermitteln den Eindruck eines weitgehend entschiedenen Marktes.

Bei genauerer Betrachtung zeigt sich jedoch ein anderes Bild – insbesondere dort, wo Drive-by-Wire nicht als Komfort- oder Assistenzfunktion verstanden wird, sondern als Grundlage für autonomes Fahren oder Teleoperation. Denn was heute häufig als Drive-by-Wire bezeichnet wird, sind in der Praxis meist Einzellösungen oder Teilsysteme. Eine vollständig integrierte, fail-operationale Fahrzeugsteuerung auf Systemebene ist weiterhin die Ausnahme.

Komponenten sind nicht gleich Systeme

Technisch betrachtet ist Drive-by-Wire kein einzelnes Produkt, sondern eine Architekturfrage. Ein echtes Drive-by-Wire-System ersetzt nicht nur mechanische Verbindungen durch elektrische Signale. Es muss sicherstellen, dass ein Fahrzeug unter allen Betriebsbedingungen steuerungsfähig bleibt – auch dann, wenn einzelne Komponenten ausfallen.

Dazu gehören unter anderem:

• eine integrierte Kombination aus Aktorik, Sensorik und Steuergeräten
• redundante Kommunikations- und Energieversorgung
• eine konsistente Software- und Regelungsarchitektur
• ein systemweites Safety-Konzept
• eine klare Verantwortung für das Gesamtverhalten des Fahrzeugs

Sicherheitsanforderungen solcher Systeme orientieren sich unter anderem an Normen wie ISO 26262 zur funktionalen Sicherheit. In der Praxis erhalten OEMs oder Systemintegratoren jedoch häufig keine vollständigen Systeme, sondern einzelne Komponenten – etwa Steer-by-Wire- oder Brake-by-Wire-Module mit jeweils eigener Zertifizierung.

Die Integration zum Gesamtsystem, die Definition des fail-operationalen Verhaltens und die sicherheitstechnische Gesamtargumentation verbleiben damit häufig beim Fahrzeughersteller. Das ist kein Qualitätsmangel einzelner Komponenten, sondern die Folge eines Marktes, der historisch entlang von Produktlinien und nicht entlang von Systemverantwortung gewachsen ist.

Warum große Anbieter selten komplette Systeme liefern

Rückblickend ist diese Situation nachvollziehbar. Viele Drive-by-Wire-Lösungen sind aus bestehenden mechanischen Fahrzeugarchitekturen heraus entstanden. Sie wurden für Fahrzeuge entwickelt, in denen ein Mensch als letzte Rückfallebene verfügbar ist. Entsprechend dominieren fail-safe-Konzepte, bei denen ein System im Fehlerfall in einen sicheren Zustand übergeht – etwa durch Abschaltung oder Übergabe an den Fahrer.

Autonome Fahrzeuge stellen jedoch andere Anforderungen. Wenn kein Fahrer vorhanden ist, darf das System nicht einfach abschalten. Es muss kontrolliert weiterarbeiten können. Das erfordert fail-operationale Systemarchitekturen, bei denen Redundanz, Fehlererkennung und Weiterbetrieb von Beginn an systemisch gedacht sind.

Auch regulatorisch gewinnt dieses Thema zunehmend an Bedeutung. Internationale Regelwerke wie die UNECE-Regulierung R79 für elektronische Lenksysteme definieren Anforderungen an sicherheitskritische Fahrzeugsteuerung.

Ein Markt auf Systemebene – und genau deshalb offen

Auf Komponentenebene ist der Drive-by-Wire-Markt weit entwickelt. Auf Systemebene hingegen nicht. Weltweit gibt es nur eine begrenzte Anzahl von Unternehmen, die tatsächlich ein vollständiges Drive-by-Wire-System liefern können – inklusive Hardware, Software, Redundanzkonzept und systemweiter Safety-Argumentation aus einer Hand.

Noch seltener sind Lösungen, die plattformunabhängig funktionieren und sowohl für neue Fahrzeugplattformen als auch für die Nachrüstung bestehender Flotten geeignet sind. Gerade in Bereichen wie Logistik, Landwirtschaft, Bergbau, Bauwesen, Verteidigung oder öffentlichem Verkehr beginnt Autonomie selten auf einer komplett neuen Plattform. Häufig werden bestehende Fahrzeuge automatisiert oder teleoperiert. Damit rückt die Nachrüstfähigkeit von Drive-by-Wire-Systemen stärker in den Mittelpunkt architektonischer Entscheidungen.

Plattformansätze wie die Drive-by-Wire-Steuerungsplattform NX NextMotion von Arnold NextG zielen genau auf diese Systemebene ab: Sie integrieren Lenkung, Bremse, Antrieb und weitere Fahrzeugfunktionen in einer gemeinsamen, multi-redundanten und fail-operationalen Steuerungsarchitektur – unabhängig von der jeweiligen Fahrzeugplattform.

Fahrzeugkontrolle als Fundament autonomer Systeme

Die Diskussion über autonome Mobilität wird häufig von Wahrnehmungssystemen und künstlicher Intelligenz geprägt. Doch selbst die leistungsfähigste KI kann ein Fahrzeug nur so sicher bewegen, wie es die zugrunde liegende Steuerungsarchitektur erlaubt. Erst wenn Fahrzeugkontrolle als integriertes System verstanden wird – und nicht als Sammlung einzelner Komponenten – lässt sich Autonomie zuverlässig in reale Anwendungen überführen.

Vor diesem Hintergrund entstehen neue Plattformansätze für vollständig elektronische Fahrzeugsteuerung. Plattformen wie NX NextMotion verfolgen beispielsweise das Ziel, Lenkung, Bremse, Antrieb und weitere Fahrzeugfunktionen in einer gemeinsamen, multi-redundanten Drive-by-Wire-Architektur zusammenzuführen. Der Markt für echtes Drive-by-Wire ist deshalb noch lange nicht entschieden. Nicht weil es an Technologie fehlt – sondern weil Systemdenken, Architekturverantwortung und Betriebserfahrung selten zusammenkommen.

Ausblick

Im nächsten Beitrag dieser Serie betrachten wir eine zentrale Architekturentscheidung moderner Fahrzeugsteuerung: den Unterschied zwischen fail-safe und fail-operational – und warum diese Unterscheidung für autonome Systeme praktisch entscheidend ist.

WE CONTROL WHAT MOVES!

Weiterführende informationen unter: www.arnoldnextg/Blog