Drive-by-Wire für heterogene Defence-Plattformen: Wie sichere Fahrzeugsteuerung über Plattformgrenzen skaliert

Die entscheidende Frage lautet vielmehr: Welche Teile einer sicherheitsgerichteten Steuerungsarchitektur können wiederverwendet werden – und welche müssen für jede Zielplattform spezifisch ausgelegt und validiert werden?

Skalierung beginnt an der richtigen Systemgrenze

Ein Radfahrzeug, eine Kettenplattform, ein schweres Nutzfahrzeug oder eine elektrifizierte Sonderplattform unterscheiden sich nicht nur in Abmessungen und Antriebskonzept. Bordnetz, Fahrzeugkommunikation, Aktuatorik, Einbauverhältnisse und dynamische Eigenschaften können grundlegend verschieden sein. Wer Skalierbarkeit deshalb mit Plug-and-play gleichsetzt, greift zu kurz. Technisch sinnvoll wird Plattformskalierung erst, wenn wiederverwendbare Systemfunktionen und fahrzeugspezifische Integration sauber voneinander getrennt werden.

Mit NX NextMotion verfolgt Arnold NextG genau diesen Ansatz. Die Drive-by-Wire-Plattform bildet eine Control Layer zwischen den anfordernden Systemen und den realen Bewegungsfunktionen des Fahrzeugs. Auf der einen Seite stehen Steueranforderungen – beispielsweise von Fahrer, Teleoperation oder automatisierten Fahrsystemen. Auf der anderen Seite werden Lenkung, Bremse und Antrieb an die konkrete Zielplattform angebunden. Damit entsteht eine klare Architekturgrenze: Die grundlegende Steuerungs- und Sicherheitslogik kann wiederverwendbar ausgelegt werden; ihre physische und kommunikative Anbindung bleibt plattformspezifisch.

Was über Plattformgrenzen hinweg wiederverwendbar bleibt

Für OEMs und Integratoren liegt der relevante Skalierungseffekt nicht darin, dieselbe Hardwarekonfiguration unverändert in verschiedene Fahrzeuge einzubauen.

Wiederverwendbar sind vielmehr zentrale Architekturprinzipien und Funktionen wie:

• deterministische Echtzeitverarbeitung,
• Plausibilisierung von Steueranforderungen,
• Diagnose und Fehlererkennung,
• definierte Fehlerreaktionen,
• sicherheitsgerichtete Steuerungslogik.

NX NextMotion schafft hierfür eine gemeinsame Architekturgrundlage. Dadurch müssen zentrale Mechanismen der elektronischen Fahrzeugsteuerung nicht für jede neue Zielplattform vollständig neu konzipiert werden. Für Entwicklungsorganisationen ist diese Trennung wesentlich: Sie verschiebt den Fokus von der wiederholten Entwicklung grundlegender Safety- und Control-Mechanismen hin zur gezielten Integration der konkreten Plattform.

Was plattformspezifisch bleiben muss

Die Wiederverwendbarkeit des Steuerungskerns hebt die fahrzeugspezifische Entwicklungsarbeit nicht auf. Unterschiedliche Plattformen erfordern unterschiedliche Schnittstellen zur Aktuatorik, Kommunikation und Energieversorgung. Auch Aktuatorkennwerte, Fahrzeugparameter, Einbaukonfigurationen und die konkrete Parametrierung unterscheiden sich.

Die Anbindung kann bestehende Fahrzeugnetzwerke und Kommunikationsschnittstellen nutzen. Welche Technologien zum Einsatz kommen und wie einzelne Funktionen angebunden werden, hängt von der jeweiligen Zielplattform, ihrer E/E-Architektur und der konkreten Funktion ab und muss entsprechend ausgelegt und validiert werden. Eine skalierbare Architektur muss Unterschiede aufnehmen können, ohne dass für jedes Fahrzeug der gesamte sicherheitsgerichtete Steuerungskern neu entwickelt werden muss.

Fully fail-operational als Architekturprinzip

Besonders relevant wird diese Trennung, wenn Fahrzeugsteuerung nicht nur skalierbar, sondern auch bei Fehlern kontrollierbar bleiben soll. Für diesen erweiterten Fehlertoleranzansatz verwendet Arnold NextG bei NX NextMotion den Begriff fully fail-operational. Er beschreibt die technische Auslegung der Architektur und keine eigenständige normative Sicherheitsklasse.

Der Ansatz betrachtet vier Vollständigkeitsachsen gleichzeitig: Funktion, Kanal, Steuerquelle und Energiepfad. Nach jedem zu betrachtenden Einzelfehler führt die Plattform alle sicherheitsrelevanten Steuerfunktionen uneingeschränkt weiter – innerhalb der spezifizierten Ausfallraten, Leistungsgrenzen und Reaktionszeiten. Für Teleoperation und autonome Fahrfunktionen ist insbesondere die Steuerquellenachse relevant: Die Architektur setzt den Fahrer nicht grundsätzlich als Rückfallebene voraus.

Damit wird Fehlertoleranz nicht auf die Redundanz eines einzelnen Steuergeräts reduziert. Sie wird zur Eigenschaft der gesamten Wirkungskette von Steueranforderung, Verarbeitung, Kommunikation, Aktuatorik und Energieversorgung.

Domänenneutralität heißt nicht pauschale Zertifizierung

Für OEMs und Entwicklungsdienstleister ist ein weiterer Punkt entscheidend: Eine wiederverwendbare Architektur kann für unterschiedliche Anwendungsdomänen relevant sein, ohne deshalb automatisch für jede Domäne zertifiziert zu sein. NX NextMotion wurde nach ISO 26262 für Anwendungen im öffentlichen Straßenverkehr entwickelt. Die fully fail-operational Eigenschaft wurde darüber hinaus gegenüber funktionalen Sicherheitsanforderungen angrenzender Domänen analysiert – darunter ISO 25119 für Land- und Forstmaschinen, ISO 13849-1 für Maschinen sowie IEC 61508 als generischer Rahmen für sicherheitsbezogene E/E/PE-Systeme.

ISO 26262 adressiert funktionale Sicherheit sicherheitsrelevanter E/E-Systeme in Serien-Straßenfahrzeugen. ISO 13849-1 beschreibt Anforderungen und Methoden für sicherheitsbezogene Teile von Maschinensteuerungen; ISO 25119 adressiert entsprechende Steuerungssysteme in Land- und Forstmaschinen.

Für eine konkrete Defence-, Automotive- oder Off-Highway-Anwendung bleibt die Bewertung deshalb immer abhängig von Zielplattform, Funktion, Integrationsumfang und Einsatzkontext. Domänenneutralität bedeutet also nicht, normative Anforderungen zu vereinheitlichen. Sie bedeutet, dass grundlegende Architektur- und Safety-Prinzipien so angelegt sind, dass sie über unterschiedliche Anwendungen hinweg weiterverwendet und gegen die jeweils relevanten Anforderungen bewertet werden können.

Was OEMs, Tier 1 und Integratoren früh klären sollten

Für die Entwicklung einer skalierbaren Drive-by-Wire-Architektur ergeben sich damit fünf zentrale Fragen:

• Control Core: Welche Steuerungs-, Diagnose- und Fehlerreaktionsfunktionen sollen über mehrere Plattformen hinweg unverändert bleiben?
• Schnittstellen: Welche fahrzeugspezifischen Kommunikations- und Aktuatorpfade müssen pro Zielplattform entwickelt werden?
• Parametrierung: Welche Kennwerte und Systemparameter hängen unmittelbar vom konkreten Fahrzeug ab?
• Safety Case: Welche Sicherheitsanforderungen gelten für Funktion, Plattform und Einsatzdomäne – und welche Nachweise müssen projektspezifisch geführt werden?
• Validierung: Welche Teile einer bestehenden Architektur können übernommen werden und welche müssen auf der jeweiligen Zielplattform neu verifiziert und validiert werden?

Diese Fragen sind nicht auf Defence beschränkt. Auch klassische OEM-Programme, Nutzfahrzeuge, Off-Highway-Maschinen oder neue softwaredefinierte Fahrzeugkonzepte stehen vor derselben Grundentscheidung: Wie lässt sich technologische Wiederverwendung erhöhen, ohne notwendige Fahrzeugspezifik zu verlieren?

Defence verdichtet die Anforderungen an Plattformskalierung

Im Defence-Umfeld tritt diese Herausforderung besonders deutlich hervor. Unterschiedliche Plattformgenerationen, Rad- und Kettenfahrzeuge, verschiedene Antriebssysteme und unterschiedliche Nutzungskonzepte können innerhalb einer Flotte parallel bestehen. Gleichzeitig entstehen neue Anforderungen durch Teleoperation, automatisierte Fahrfunktionen und unbemannte Anwendungen.

Die Architektur muss deshalb zwei scheinbar gegensätzliche Anforderungen zusammenführen: Standardisierung dort, wo sie technisch sinnvoll ist – Spezialisierung dort, wo sie für die konkrete Plattform notwendig bleibt. Für OEMs und Integratoren entsteht daraus ein anderer Blick auf Drive-by-Wire. Entscheidend ist nicht nur, ob Lenkung, Bremse und Antrieb elektronisch steuerbar sind. Entscheidend ist, ob die zugrunde liegende Control Layer über verschiedene Fahrzeugprogramme hinweg konsistent weiterentwickelt werden kann.

Vom Einzelprojekt zur wiederholbaren Integrationsarchitektur

Eine skalierbare Drive-by-Wire-Plattform ersetzt keine plattformspezifische Entwicklung. Sie verändert jedoch, wo diese Entwicklung beginnt. Statt grundlegende Steuerungs-, Diagnose- und Safety-Mechanismen mit jeder Plattform erneut aufzubauen, kann die Entwicklungsarbeit auf einer bestehenden Architekturgrundlage aufsetzen und sich auf die konkrete Fahrzeuganbindung, Parametrierung und Validierung konzentrieren.

NX NextMotion verfolgt damit einen Plattformansatz, bei dem nicht das Fahrzeug vereinheitlicht wird, sondern die Control Layer für Fahrzeugbewegung. Der entscheidende Unterschied lautet:

Skalierbarkeit entsteht nicht dadurch, dass jede Plattform gleich behandelt wird. Sie entsteht dadurch, dass klar definiert ist, was gleich bleiben kann – und was spezifisch bleiben muss.

WE CONTROL WHAT MOVES 

Weitere Informationen: www.arnoldnextg.de

Quellen und technische Einordnung

• ATZheavy duty 02/2026 – „Drive-by-Wire-Plattform zur Integration verschiedener Steuerquellen“ – technischer Hintergrund zu NX NextMotion, zur Integration unterschiedlicher Steuerquellen sowie zum fully fail-operational Architekturansatz.
• ISO 26262 – Road vehicles – Functional safety
• ISO 25119 – Tractors and machinery for agriculture and forestry – Safety-related parts of control systems
• ISO 13849-1 – Safety of machinery – Safety-related parts of control systems
• IEC 61508-1:2010 – Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 1: General requirements