Steuerrechte werden Teil der E/E-Architektur

In klassischen Fahrzeugarchitekturen ist die Zuordnung häufig eindeutig: Der Fahrer betätigt Lenkrad und Pedale, die Fahrzeugfunktionen reagieren entsprechend. Mit zunehmender Automatisierung und externen Steuerquellen wird diese Zuordnung dynamisch. Ein automatisiertes Fahrsystem kann beispielsweise Lenkung, Bremse und Antrieb anfordern. Gleichzeitig kann ein Remote Operator Zugriff auf dieselben Funktionen benötigen. Darüber hinaus kann der Fahrer im Fahrzeug weiterhin Teil der Architektur bleiben.

Für Entwickler entsteht daraus eine zusätzliche Systemebene: Control Authority muss technisch abgebildet werden. Die von Arnold NextG entwickelte Drive-by-Wire-Plattform NX NextMotion enthält dafür eine Arbitrierungsschicht zwischen den verschiedenen Steuerquellen und den realen Bewegungsfunktionen des Fahrzeugs. Sie prüft Anforderungen kontinuierlich hinsichtlich Plausibilität und Konsistenz und setzt sie in Beziehung zu Systemzustand, Verfügbarkeit und Zeitverhalten. Das System entscheidet damit nicht lediglich nach einer statischen Prioritätenliste, sondern innerhalb eines definierten Zustandsmodells.

Ein Moduswechsel ist ein Wechsel des Steuerungspfads

Aus Engineering-Sicht ist insbesondere der Übergang zwischen Steuerquellen relevant. Ein Wechsel von automatisiertem Betrieb zu Teleoperation oder vom Remote Operator zurück zum Fahrer ist nicht lediglich ein Wechsel eines Betriebsmodus in einer Benutzeroberfläche. Er verändert den aktiven Steuerungspfad für sicherheitsrelevante Fahrzeugfunktionen.

Dabei müssen mindestens drei Fragen eindeutig beantwortet sein:

• Welche Quelle gibt das Steuerrecht ab?
• Welche Quelle übernimmt es?
• Wie werden Steueranforderungen während des Übergangs behandelt?

Im NX-NextMotion-Systemkonzept werden solche Wechsel deshalb als definierte Systemzustände behandelt. Nichtdeterministische Zustandswechsel werden ausgeschlossen. Für die beschriebenen Übergänge weist das zugrunde liegende Systemkonzept Fehlerreaktionszeiten von unter fünf Millisekunden aus. Jeder Übergang wird dabei selbst als sicherheitsrelevante Funktion betrachtet.

Für OEMs und Integratoren ist das ein wichtiger Unterschied: Die sichere Integration mehrerer Steuerquellen ist nicht allein eine Schnittstellenfrage. Auch die Übergabelogik selbst gehört zum Safety-Konzept.

Steuerrechte müssen nicht für das gesamte Fahrzeug gleichzeitig wechseln

Eine weitere Herausforderung entsteht dadurch, dass Fahrzeugzustände nicht immer eindeutig „manuell“ oder „automatisiert“ sind. Gemischte Betriebszustände können ausdrücklich Teil einer Fahrzeugarchitektur sein. Der ATZ-Fachbeitrag zu NX NextMotion beschreibt beispielsweise einen Zustand, in dem der Fahrer in die Lenkung eingreift, während das automatisierte Fahrsystem weiterhin die Bremsfunktion regelt. Technisch entstehen dadurch sogenannte virtuelle Sollkanäle innerhalb der Arbitrierungsarchitektur.  Damit wird eine entscheidende Engineering-Anforderung sichtbar:

Control Authority muss funktionsbezogen betrachtet werden.

Lenkung, Bremse und Antrieb müssen nicht zwangsläufig gleichzeitig von derselben Steuerquelle geführt werden. Für die Architektur bedeutet das, dass Steuerrechte nicht nur pro Betriebsmodus, sondern abhängig von Funktion und Systemzustand eindeutig beschrieben werden müssen. Gerade für Manned-Unmanned Teaming, assistierte Betriebsarten oder schrittweise automatisierte Plattformen ist diese Fähigkeit relevant. Ein Fahrzeug kann dadurch zwischen unterschiedlichen Automatisierungsgraden wechseln, ohne dass dafür vollständig getrennte Steuerungsarchitekturen notwendig werden.

Warum statische Prioritäten allein nicht ausreichen

Eine einfache Hierarchie nach dem Prinzip „Fahrer hat Priorität vor Teleoperation, Teleoperation vor Autonomie“ bildet diese Realität nur unvollständig ab. Denn die Zulässigkeit einer Steueranforderung hängt nicht ausschließlich von ihrer Quelle ab. Relevant sind unter anderem:

·       Systemzustand: Ist die betreffende Betriebsart aktuell zulässig?

·       Verfügbarkeit: Ist der zugehörige Steuerungspfad funktionsfähig?

·       Plausibilität: Ist die angeforderte Funktion mit dem aktuellen Zustand konsistent?

·       Zeitverhalten: Erfolgt die Anforderung und gegebenenfalls der Übergang innerhalb des spezifizierten Zeitrahmens?

NX NextMotion verknüpft diese Informationen innerhalb der Arbitrierung. Dadurch werden Steuerrechte und Übergänge deterministisch behandelt. Für eine Safety-orientierte Entwicklung ist diese Eindeutigkeit entscheidend: Zu jedem Zeitpunkt muss nachvollziehbar sein, welche Quelle auf welche Funktion wirkt.

Was OEMs und Tier 1 bei Defence-Plattformen früh definieren sollten

Für Unternehmen, die bestehende Automotive- oder Nutzfahrzeugkompetenz auf Defence-Anwendungen übertragen, entsteht damit eine zusätzliche Ebene der Systementwicklung. Die Frage lautet nicht nur, welche Schnittstelle ein AD-Stack oder Remote-Control-System benötigt.

Frühzeitig geklärt werden muss vielmehr:

·        Welche Steuerquellen soll die Plattform während ihres Lebenszyklus unterstützen?

·         Welche Fahrzeugfunktionen dürfen von welcher Quelle angefordert werden?

·         Welche Prioritäten und Übergabebedingungen gelten pro Funktion?

·         Welche gemischten Zustände sind zulässig?

·         Wie werden Konflikte zwischen Anforderungen erkannt?

·         Welche Zustände und Übergänge müssen im Safety Case betrachtet werden?

·         Wie wird sichergestellt, dass Erweiterungen um neue Steuerquellen die bestehende Architektur nicht unkontrolliert verändern?

Damit verschiebt sich die Integrationsfrage von der reinen Signalübertragung zur Definition und Beherrschung von Control Authority.

Eine gemeinsame Control Layer statt paralleler Steuerungssysteme

Für Hersteller und Systemintegratoren liegt darin ein wesentlicher Architekturvorteil. Bemannte, teleoperierte und automatisierte Betriebsarten müssen nicht zwangsläufig als voneinander getrennte Fahrzeugsteuerungen realisiert werden. Sie können auf einer gemeinsamen Drive-by-Wire Control Layer aufsetzen, die ihre Anforderungen koordiniert. Das ist insbesondere für Plattformen relevant, deren Funktionsumfang während ihres Lebenszyklus weiterentwickelt werden soll.

Eine ursprünglich bemannte Plattform kann später Teleoperation erhalten. Automatisierte Funktionen können schrittweise ergänzt werden. Für einzelne Anwendungen kann unbemannter Betrieb hinzukommen. Wenn Control Arbitration bereits Bestandteil der darunterliegenden Fahrzeugarchitektur ist, muss nicht mit jeder neuen Betriebsart auch die grundlegende Logik der Bewegungssteuerung neu aufgebaut werden.

Defence als besonders anspruchsvoller Integrationsfall

Im Defence Engineering verdichten sich viele dieser Anforderungen. Plattformen können über lange Zeiträume betrieben und mehrfach modernisiert werden. Unterschiedliche Automatisierungsgrade können parallel existieren. Je nach Einsatzkonzept können Fahrer, Remote Operator und automatisierte Systeme innerhalb derselben Fahrzeugarchitektur relevant sein. Damit wird die Trennung zwischen Steuerquelle und Fahrzeugfunktion besonders wichtig.

Die Frage lautet nicht: Wer steuert das Fahrzeug?
Sondern: Welche Quelle darf in diesem Zustand welche Funktion führen?

NX NextMotion bildet diese Zuordnung innerhalb einer gemeinsamen Control Layer ab. Für Unternehmen, die sich aus klassischen Automotive- und Nutzfahrzeugsegmenten in Defence-Anwendungen diversifizieren, ist das ein wesentlicher Perspektivwechsel: Bestehende Kompetenz in E/E-Architektur, Functional Safety, Aktuatorik und Systemintegration bleibt relevant – sie muss jedoch um die kontrollierte Integration mehrerer Steuerquellen erweitert werden.

Die Grenze der Arbitrierung

Control Arbitration beantwortet dabei eine klar umrissene Architekturfrage: Wer besitzt für eine bestimmte Funktion das Steuerrecht? Sie beantwortet nicht automatisch, ob jede formal gültige und eindeutig zugeordnete Bewegungsanforderung unter den realen physikalischen und technischen Bedingungen einer Plattform tatsächlich kontrolliert ausführbar ist. Eine angeforderte Bewegung trifft immer auf ein reales Fahrzeug – mit konkretem Fahrzeugzustand und konkreten Randbedingungen.

An dieser Systemgrenze beginnt eine weitere Entwicklungsaufgabe. Für die Arbitrierungsarchitektur ist zunächst entscheidend, dass davor eine eindeutige Voraussetzung geschaffen wurde: Es muss jederzeit definiert sein, welche Quelle welche Bewegungsfunktion führen darf.

Vom Zugang zur Fahrzeugfunktion zur kontrollierten Control Authority

Drive-by-Wire macht Fahrzeugfunktionen elektronisch zugänglich. Erst eine definierte Arbitrierungsarchitektur macht diesen Zugang jedoch bei mehreren Steuerquellen technisch beherrschbar. Für moderne Defence-Plattformen bedeutet das: Nicht die Anzahl möglicher Steuerquellen bestimmt die Integrationsfähigkeit einer Plattform.

Entscheidend ist, ob ihre Architektur Steuerrechte funktionsbezogen vergeben, Konflikte deterministisch behandeln und Übergänge kontrolliert ausführen kann. NX NextMotion bildet dafür die Drive-by-Wire Control Layer von Arnold NextG.

WE CONTROL WHAT MOVES

Mehr Informationen: www.arnoldnextg.de

Quellen und technische Einordnung

ATZheavy duty 02/2026 – „Drei Steuerquellen, eine Architektur – Eine fail-operational Drive-by-Wire-Plattform zur integrierten Steuerung für Autonomie, Teleoperation und Fahrereingriff“. Technische Grundlage zu Steuerquellenintegration, Arbitrierung, Übergängen, virtuellen Sollkanälen und Failover-Verhalten.

ISO 26262 – funktionale Sicherheit elektrischer und elektronischer Systeme in Straßenfahrzeugen; relevant als Entwicklungsrahmen von NX NextMotion. Die konkrete Bewertung einer Defence-Anwendung bleibt abhängig von Funktion, Zielplattform und Anwendungskontext.

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

Gerade bei autonomen Konvois oder unbemannten Logistikplattformen wird diese Herausforderung deutlich: Eine identische Trajektorie kann je nach Beladung, Untergrund oder verfügbarer Brems- und Antriebsreserve für zwei Fahrzeuge unterschiedlich kritisch sein. Zwischen dem, was ein übergeordnetes Autonomie- oder Missionssystem anfordert, und dem, was die reale Fahrzeugplattform unter ihren aktuellen Bedingungen kontrolliert ausführen kann, entsteht damit eine entscheidende Systemgrenze: der Control Gap.

Arnold NextG adressiert den Control Gap mit einem neuen Produkt, das Anfang November vorgestellt wird. Im Zentrum der Entwicklung steht Vehicle Motion Assurance – eine zusätzliche fahrzeugseitige Funktion zwischen digitaler Bewegungsanforderung und Drive-by-Wire-Ausführung.

Die Entwicklung baut auf mehr als 25 Jahren Produktentwicklungskompetenz von Arnold NextG in der digitalen Fahrzeugsteuerung und Systemintegration auf. Dieses Know-how bildet die technologische Basis für die nächste Entwicklungsstufe der Fahrzeugarchitektur.

Eine neue Ebene zwischen Bewegungsanforderung und Ausführung

Mit NX NextMotion hat Arnold NextG bereits den Drive-by-Wire Control Layer für die fahrzeugseitige Ausführung geschaffen. Lenkung, Bremse, Antrieb und relevante Sekundärfunktionen werden darüber digital angesteuert. Die Systemarchitektur wird nun um eine vorgelagerte Ebene ergänzt. Ihre Aufgabe ist Vehicle Motion Assurance: Sie prüft, ob und wie eine angeforderte Bewegung unter den aktuellen Bedingungen der Plattform kontrolliert ausgeführt werden kann.

Bewegungsanforderungen werden dafür in den Kontext der realen Plattform gesetzt, bewertet, begrenzt und während der Ausführung überwacht. So entsteht eine klare Bewegungskette: Ein Autonomie-, Missions- oder Remote-System definiert die gewünschte Bewegung. Die neue Produktebene übernimmt Vehicle Motion Assurance. NX NextMotion setzt die freigegebene Bewegung als Drive-by-Wire Control Layer am Fahrzeug um.

„Autonome Systeme können heute sehen, analysieren und entscheiden. Die entscheidende Frage ist, ob ihre Bewegungsanforderungen auch unter realen Einsatzbedingungen kontrolliert umgesetzt werden können“, sagt Kevin Arnold, Geschäftsführer von Arnold NextG. „Genau an dieser Schnittstelle entwickeln wir unsere Fahrzeugarchitektur weiter.“

Die neue Lösung richtet sich insbesondere an Hersteller, Systemintegratoren und Betreiber automatisierter, teleoperierter und unbemannter Defence-Plattformen. Sie erweitert die bestehende Arnold-NextG-Architektur genau an der Stelle, an der der Control Gap entsteht: zwischen digitaler Bewegungsanforderung und realer Fahrzeugausführung.

In den kommenden Wochen wird Arnold NextG diese zusätzliche Ebene technisch weiter sichtbar machen. Anfang November folgt die vollständige Produktvorstellung – mit der konkreten Systemarchitektur, dem Produktnamen und der technischen Antwort auf den Control Gap – Command to Controlled Motion.

WE CONTROL WHAT MOVES.

Mehr Informationen unter: www.arnoldnextg.de

Für Entwickler, OEMs, Tier-1-Zulieferer und Systemintegratoren wird Teleoperation damit zu einer Frage der Fahrzeug- und Steuerungsarchitektur. Eine Kommunikationsverbindung kann Steueranforderungen übertragen. Sie garantiert jedoch weder deren kontrollierte Umsetzung in Lenkung, Bremse und Antrieb noch eine belastbare Rückmeldung darüber, wie die reale Plattform tatsächlich reagiert.

Teleoperation ist mehr als eine Kommunikationsstrecke

Eine teleoperierte Plattform benötigt einen durchgängigen Steuerungspfad vom externen Bedienplatz bis zu den Bewegungsfunktionen des Fahrzeugs – und einen Rückkanal zurück zum Operator. Damit entsteht ein geschlossener Regelkreis:

Steueranforderung → elektronische Verarbeitung → Aktuatorik → Fahrzeugbewegung → Rückmeldung an den Operator.

Wie relevant diese Gesamtsystembetrachtung ist, zeigt auch der zivile regulatorische Rahmen. Die deutsche Straßenverkehr-Fernlenk-Verordnung betrachtet Fahrzeug und technische Fernlenkausrüstung ausdrücklich als Gesamtsystem und verlangt, Übertragungslatenzen im Sicherheitskonzept zu berücksichtigen. Für bestimmte Signale, die den Operator unmittelbar bei der dynamischen Fahraufgabe unterstützen, sieht die Verordnung eine maximale Signallatenz von 0,2 Sekunden vor. Das ist keine Defence-Vorgabe, verdeutlicht aber die enge technische Kopplung zwischen Kommunikation, Verarbeitung und Fahrzeugreaktion.

Für Defence-Anwendungen bleibt die konkrete Auslegung vom jeweiligen Einsatz- und Systemkontext abhängig. Die grundlegende Engineering-Frage ist jedoch dieselbe: Wie wird aus einer extern übertragenen Anforderung eine kontrollierte Fahrzeugbewegung?

Drive-by-Wire schließt die Lücke zwischen Leitstand und Fahrzeugbewegung

Genau hier setzt Drive-by-Wire an. Lenkung, Bremse und Antrieb werden elektronisch ansprechbar und können in eine übergeordnete digitale Steuerungsarchitektur eingebunden werden. Mit NX NextMotion bildet Arnold NextG dafür eine sicherheitsgerichtete Control Layer. Externe Steueranforderungen werden verarbeitet, auf Plausibilität geprüft und über die jeweilige Aktuatorik in reale Fahrzeugbewegung umgesetzt. Gleichzeitig überwacht die Architektur die beteiligten Funktionen und kann auf erkannte Fehler mit definierten Reaktionen antworten.

Teleoperation ist damit keine separate Fernsteuerung, die neben der eigentlichen Fahrzeugsteuerung arbeitet. Sie wird zu einer Steuerquelle innerhalb der Bewegungsarchitektur. Der technische Aufbau von NX NextMotion und die Integration unterschiedlicher Steuerquellen sind auch im ATZheavy-duty-Fachbeitrag zur Drive-by-Wire-Plattform dokumentiert.

Der Rückkanal entscheidet mit über die Qualität der Teleoperation

Je weiter der Operator vom Fahrzeug entfernt ist, desto wichtiger wird die Frage, welche Informationen aus der realen Plattform zurückgeführt werden. Kamerabilder bilden einen Teil dieser Rückmeldung ab. Hinzu kommen je nach Systemauslegung Zustandsdaten sowie Informationen zu Fahrzeugreaktion, Lenkkräften, Schlupf oder Untergrund. Diese können über visuelle, digitale oder haptische Rückkanäle bereitgestellt werden. Besonders deutlich wird die Bedeutung der Rückkopplung beim Force Feedback.

Bei NX NextMotion ist die haptische Rückmeldung Bestandteil des sicherheitsrelevanten Lenkpfads. Im zugrunde liegenden Sicherheitskonzept wird sie auf Basis der Fehlerbaumanalyse entsprechend sicherheitskritisch behandelt. Das Feedback wird dabei nicht ausschließlich künstlich im Bediengerät erzeugt, sondern aus plausibilisierten physikalischen und fahrdynamischen Größen abgeleitet. Damit wird Force Feedback vom reinen Bedienmerkmal zu einem Bestandteil des geschlossenen Bewegungsregelkreises.

Für diese Verarbeitung gelten Echtzeit-, Redundanz- und Fehlerreaktionsanforderungen wie für die übrige Steer-by-Wire-Funktion. Der Steuerungs- und Diagnosezyklus von NX NextMotion liegt bei zwei Millisekunden. Der zugrunde liegende technische Ansatz ist im ATZheavy-duty-Fachbeitrag dokumentiert.

Ohne Fahrer verändert sich die Sicherheitsarchitektur

Bei einer bemannten Plattform kann ein Fahrer unter bestimmten Bedingungen als Rückfallebene zur Verfügung stehen. Bei einem unbemannten oder vollständig teleoperierten Fahrzeug entfällt diese Annahme. Kommunikation, Sensorik, Aktuatorik, Steuerung und Energieversorgung müssen deshalb als zusammenhängender sicherheitsgerichteter Steuerungspfad betrachtet werden. Ein Kommunikationsabbruch oder der Verlust eines Signalpfads darf nicht zu einer unkontrollierten Fahrzeugbewegung führen.

Für Drive-by-Wire bedeutet das: Die Architektur muss Fehler erkennen, den verbleibenden Funktionsumfang bewerten und eine definierte Reaktion ermöglichen. NX NextMotion ist dafür multi-redundant und fail-operational ausgelegt. Entscheidend ist dabei nicht allein die Redundanz eines Steuergeräts, sondern die Betrachtung der gesamten sicherheitsrelevanten Wirkungskette. Arnold NextG beschreibt diesen Architekturansatz auch im Zusammenhang mit der kontrollierten Fahrzeugbewegung ohne Fahrer als permanente Rückfallebene. Hintergrund: fail-operational Drive-by-Wire bei NX NextMotion (https://www.pressebox.de/…)

Teleoperation wird zur integrierten Fahrzeugfunktion

Für Defence-Plattformen liegt die technische Herausforderung nicht allein in der Übertragung von Steueranforderungen. Entscheidend ist, wie externe Bedienung, Fahrzeugsteuerung und Aktuatorik zu einer durchgängigen Architektur verbunden werden. Der Remote Operator, die Kommunikationsstrecke und die Drive-by-Wire Control Layer übernehmen dabei unterschiedliche Aufgaben. Während der Bedienplatz Steueranforderungen erzeugt und Fahrzeuginformationen visualisiert, verbindet NX NextMotion diese Anforderungen mit den realen Bewegungsfunktionen des Fahrzeugs.

Damit bleiben die Systemebenen klar voneinander getrennt: Teleoperation stellt die Steuerquelle bereit, Drive-by-Wire übernimmt die kontrollierte Umsetzung in Lenkung, Bremse und Antrieb.

Für OEMs, Tier-1-Zulieferer und Systemintegratoren ist diese Trennung besonders relevant. Neue Bedien- oder Automatisierungsfunktionen können über definierte Schnittstellen in die Fahrzeugarchitektur integriert werden, während die Anbindung an Aktuatorik, Bordnetz und Kommunikationssysteme plattformspezifisch bleibt.

Was OEMs und Integratoren bei Defence Teleoperation betrachten müssen

Für die technische Bewertung einer teleoperierten Plattform sind deshalb nicht nur Reichweite oder Bandbreite der Kommunikationsverbindung relevant. Entscheidend sind insbesondere:

• Steuerungspfad: Wie gelangen externe Steueranforderungen sicherheitsgerichtet bis zu Lenkung, Bremse und Antrieb?
• Rückkopplung: Welche Informationen über die reale Fahrzeugreaktion stehen dem Operator zur Verfügung?
• Zeitverhalten: Wie werden Latenzen, Übertragungsunterbrechungen und Reaktionszeiten erkannt und behandelt?
• Fehlerverhalten: Welche Fahrzeugfunktionen bleiben kontrollierbar, wenn kein Fahrer im Fahrzeug als unmittelbare Rückfallebene zur Verfügung steht?

Damit verschiebt sich die zentrale Entwicklungsfrage von „Wie übertragen wir einen Fahrbefehl?“ zu „Wie erhalten wir einen geschlossenen und kontrollierbaren Fahrzeugregelkreis?“

Teleoperation wird zur Systemeigenschaft der Plattform

Gerade im Defence-Umfeld kann Teleoperation unterschiedliche Plattformtypen und Nutzungskonzepte betreffen – von neu entwickelten unbemannten Fahrzeugen bis zu digitalisierten Bestandsplattformen. Für eine skalierbare Integration ist deshalb entscheidend, Teleoperation nicht als isolierte Zusatzfunktion zu behandeln. Die externe Bedienung muss Bestandteil einer Fahrzeugarchitektur werden, die elektronische Steuerung, Rückmeldung, Diagnose und Fehlerreaktion gemeinsam betrachtet.

NX NextMotion bildet dafür die Drive-by-Wire Control Layer zwischen externer Steueranforderung und realer Fahrzeugbewegung. Der technologische Kern ist damit einfach formuliert: Teleoperation überträgt nicht nur Kontrolle über Distanz. Sie muss die Kontrolle über Bewegung auch über diese Distanz erhalten.

WE CONTROL WHAT MOVES

weitere Information: www.arnoldnextg.de

Quellen und technische Einordnung

Straßenverkehr-Fernlenk-Verordnung (StVFernLV), Anlage 1 – Technische Anforderungen
Regulatorischer Referenzrahmen für Fernlenkung im zivilen Straßenverkehr; im Beitrag ausschließlich zur technischen Einordnung der Signallatenz verwendet, nicht als Defence-Vorgabe.
https://www.gesetze-im-internet.de/stvfernlv/anlage_1.html

ATZheavy duty 02/2026 – „Drive-by-Wire-Plattform zur Integration verschiedener Steuerquellen“
Technische Grundlage unter anderem für NX NextMotion, Teleoperation, Force Feedback sowie den Steuerungs- und Diagnosezyklus.
https://link.springer.com/article/10.1007/s35746-026-1416-1

Für OEMs, Tier-1-Zulieferer, Systemintegratoren und Betreiber wird Retrofit deshalb zunehmend zu einer Architekturaufgabe. Es reicht nicht mehr aus, zusätzliche Sensoren, Kommunikationssysteme oder elektronische Komponenten in eine bestehende Plattform zu integrieren. Sobald neue Formen der Fahrzeugführung hinzukommen, müssen auch Lenkung, Bremse und Antrieb elektronisch, sicherheitsgerichtet und zuverlässig ansprechbar sein.

Genau hier erweitert Drive-by-Wire die Möglichkeiten der Modernisierung. Die Technologie schafft die elektronische Verbindung zwischen digitalen Fahrfunktionen und den realen Bewegungsfunktionen des Fahrzeugs. So können auch bestehende Plattformen für neue Fähigkeiten geöffnet werden, ohne dass dafür zwingend eine vollständig neue Fahrzeuggeneration entwickelt werden muss. Damit wird Drive-by-Wire vom einzelnen Retrofit-Projekt zur technologischen Grundlage für die schrittweise Digitalisierung heterogener Defence-Flotten.

Bestandsplattformen stellen andere Anforderungen als Neuentwicklungen

Bei einem neu entwickelten Fahrzeug können Bordnetz, Kommunikationssysteme, Steuergeräte, Sensorik und Aktuatorik von Beginn an gemeinsam ausgelegt werden. Die digitale Steuerbarkeit ist Teil der Fahrzeugarchitektur. Bei einer Bestandsplattform ist die Ausgangslage grundlegend anders.

Die Integration trifft auf vorhandene elektrische Systeme, bestehende Bussysteme sowie mechanische oder hydraulische Betätigungen für Lenkung, Bremse und Antrieb. Abhängig vom Fahrzeug müssen deshalb Aktuatoren, Sensoren, elektronische Signalpfade und Kommunikationsschnittstellen in eine bereits existierende Architektur eingebunden werden.

Für Entwickler und Integratoren entsteht daraus eine komplexe Systemaufgabe: Die neue elektronische Steuerung muss mit der vorhandenen Fahrzeugtechnik zusammenarbeiten und gleichzeitig ein definiertes Verhalten auch bei Fehlern ermöglichen. Retrofit ist deshalb weit mehr als die nachträgliche Installation einzelner Komponenten. Es ist die Integration einer sicherheitsgerichteten Steuerungsarchitektur unter den realen Randbedingungen der jeweiligen Plattform.

Skalierbare Architektur statt Einzellösung

Gerade Defence-Flotten sind technisch heterogen. Rad- und Kettenfahrzeuge, unterschiedliche Gewichtsklassen, verschiedene Plattformgenerationen sowie Diesel-, Hybrid- und Elektroantriebe müssen parallel betrieben und weiterentwickelt werden. Eine wirtschaftlich skalierbare Modernisierung kann deshalb kaum darauf basieren, für jeden Fahrzeugtyp eine vollständig neue Drive-by-Wire-Lösung zu entwickeln.

Der technische Ansatz von Arnold NextG besteht darin, einen wiederverwendbaren sicherheitsgerichteten Steuerungskern von der plattformspezifischen Integration zu trennen. NX NextMotion ist als offene, herstellerunabhängige Drive-by-Wire-Plattform ausgelegt. Die Architektur kann in unterschiedliche Rad- und Kettenfahrzeuge sowie verschiedene Antriebskonzepte integriert werden. Über elektronische Schnittstellen werden Lenkung, Bremse und Antrieb in eine digitale Steuerungsarchitektur eingebunden.

Damit entsteht die Grundlage für unterschiedliche Formen der Fahrzeugführung – vom Fahrer über Teleoperation und autonome Funktionen bis hin zu gekoppelten Anwendungen wie Platooning. Entscheidend ist dabei die Abgrenzung: Wiederverwendbarkeit bedeutet nicht Plug-and-play. Jede Zielplattform benötigt eine eigene technische Anbindung, Parametrierung und Bewertung. Fahrzeugkommunikation, Aktuatorik, Bordnetz und mechanische Voraussetzungen unterscheiden sich von Plattform zu Plattform. Die Integration kann beispielsweise bestehende Kommunikationsstrukturen wie CAN nutzen, muss aber immer auf das konkrete Fahrzeug abgestimmt werden.

Safety muss über den gesamten Steuerungspfad betrachtet werden

Mit der elektronischen Kontrolle von Lenkung, Bremse und Antrieb werden Funktionen digitalisiert, die unmittelbar für die Beherrschbarkeit des Fahrzeugs relevant sind. Entsprechend reicht es nicht aus, lediglich ein Steuergerät redundant auszulegen. Signalübertragung, Aktuatorik, Sensorik, Kommunikation und Energieversorgung müssen als zusammenhängendes System betrachtet werden.

Ziel ist, dass ein einzelner Fehler nicht zu einem unkontrollierten Verlust der Fahrzeugführung führt. NX NextMotion bringt dafür eine Architekturgrundlage in die Integration ein, die unter Berücksichtigung einschlägiger Anforderungen an funktionale Sicherheit und Cybersecurity entwickelt wurde. Für OEMs und Integratoren liegt darin ein wesentlicher Unterschied zu einer projektspezifischen Einzellösung: Grundlegende Mechanismen für sichere elektronische Fahrzeugsteuerung müssen nicht für jede neue Plattform vollständig neu entwickelt werden.

Die konkrete Gesamtfahrzeugbewertung bleibt dennoch immer abhängig von Zielplattform, Integrationsumfang und vorgesehenem Einsatz. Nachrüstbarkeit ist damit eine Eigenschaft der Architektur – keine pauschal übertragbare Fahrzeugzulassung.

Von der digitalen Anbindung zur neuen Fahrzeugfähigkeit

Der eigentliche Mehrwert einer solchen Retrofit-Architektur liegt deshalb nicht allein in der Digitalisierung eines einzelnen Fahrzeugs. Wird derselbe sicherheitsgerichtete Steuerungsansatz über mehrere Plattformen hinweg eingesetzt, entsteht eine technische Grundlage für die schrittweise Modernisierung heterogener Flotten. Das verändert auch die Perspektive auf zukünftige Fähigkeiten.

Teleoperation, autonome Fahrfunktionen oder Platooning müssen dann nicht zwangsläufig an eine neue Fahrzeuggeneration gekoppelt sein. Sie können dort integriert werden, wo die erforderlichen technischen Voraussetzungen geschaffen werden – auch auf bereits vorhandenen Plattformen. Für Betreiber bedeutet das, bestehende Fahrzeuge über ihre verbleibende Nutzungsdauer funktional weiterentwickeln zu können. Für OEMs und Tier-1-Zulieferer entsteht eine Architekturgrundlage, auf der sich neue digitale Funktionen aufbauen lassen. Systemintegratoren können die Anpassung stärker auf die konkrete Fahrzeuganbindung konzentrieren, statt bei jeder Plattform die grundlegende Steuerungsarchitektur neu zu entwickeln.

Retrofit wird damit zur strategischen Architekturentscheidung

Der weltweite Markt für Upgrades und Retrofit gepanzerter Fahrzeuge lag 2025 bei rund 6,46 Milliarden US-Dollar. Für 2026 wurde ein Wachstum von etwa 4,5 Prozent erwartet. Hinter dieser Entwicklung steht eine langfristige Aufgabe: Bestehende Flotten sollen länger genutzt werden und gleichzeitig neue digitale Fähigkeiten erhalten. Für die technische Umsetzung wird deshalb nicht allein entscheidend sein, welche neue Funktion auf einem Fahrzeug demonstriert werden kann. Entscheidend ist, ob die zugrunde liegende Architektur skalierbar ist.

Eine nachrüstbare Drive-by-Wire-Plattform schafft dafür die Verbindung zwischen bestehender Fahrzeugtechnik und neuen Formen digitaler Fahrzeugführung. Damit wird aus einem einzelnen Retrofit-Projekt perspektivisch eine Grundlage für die Modernisierung ganzer Fahrzeugfamilien und Flotten.

NX NextMotion schafft die Voraussetzung, bestehende Plattformen digital steuerbar zu machen – mit einem wiederverwendbaren sicherheitsgerichteten Steuerungskern und einer plattformspezifischen Integration.

WE CONTROL WHAT MOVES

Quelle zur Markteinordnung:
Armored Vehicle Upgrade and Retrofit Market Report 2026, Research and Markets.

Genau diese Ebenen verbindet der Safety Case zu einer durchgängigen Argumentations- und Nachweiskette. Von jedem Sicherheitsziel muss der Weg über Requirements und Architektur bis zum Testergebnis nachvollziehbar sein – und zurück.

Für NX NextMotion als Drive-by-Wire-basierte Control Layer für autonome und teleoperierte Fahrzeuge ist diese Rückverfolgbarkeit ein wesentlicher Bestandteil der Systementwicklung. Denn wenn Lenken, Bremsen und Antrieb vollständig elektronisch kontrolliert werden, muss nicht nur die Sicherheitsarchitektur belastbar sein. Auch der Nachweis ihrer Wirksamkeit muss es sein.

Der Safety Case ist kein Papierstapel

Ein Safety Case entsteht nicht dadurch, dass am Projektende möglichst viele Nachweisdokumente zusammengetragen werden. Entscheidend ist die Rückverfolgbarkeit. Von jedem Sicherheitsziel muss sich der Weg über Requirements und Architektur bis zu Analysen und Testergebnissen verfolgen lassen – und von jedem Testergebnis zurück zu der Frage, welche Sicherheitsanforderung damit nachgewiesen wird. Bei Safety-by-Wire^® beginnt diese Beweiskette deshalb bereits in den frühen Entwicklungsphasen und begleitet NX NextMotion über den gesamten Lebenszyklus.

Requirements-in-the-Loop: prüfen, bevor implementiert wird

Eine der teuersten Fehlerquellen in der Systementwicklung liegt nicht zwangsläufig im Code. Bereits unvollständige, widersprüchliche oder nicht erfüllbare Anforderungen können sich durch Architektur, Implementierung und Test fortsetzen. Arnold NextG setzt deshalb bereits bei den Requirements an.

Mit Requirements-in-the-Loop werden Anforderungen und Szenarien in den frühen Systemphasen simulativ überprüft – bevor die erste Zeile Seriencode entsteht. Ziel ist es, Widersprüche, Lücken oder nicht erfüllbare Kombinationen zu erkennen, solange ihre Korrektur noch auf Requirement-Ebene erfolgen kann. Der Ansatz ist in die Anforderungserhebung und -analyse eingebunden – in der Automotive-SPICE-Systematik in SYS.1 und SYS.2. Damit beginnt der Sicherheitsnachweis nicht erst auf der Verifikationsseite des Entwicklungsmodells, sondern bereits während der Spezifikation.

FMEDA und FTA: Architektur quantitativ bewerten

Parallel zur Entwicklung der Systemarchitektur kommen quantitative Sicherheitsanalysen zum Einsatz.

Die FMEDA – Failure Modes, Effects and Diagnostics Analysis – betrachtet mögliche Ausfallarten von Hardwarekomponenten, deren Auswirkungen und die Wirksamkeit der Diagnose. Sie liefert damit eine Grundlage für die Bewertung, ob gefährliche Einzelfehler erkannt und latente Fehler ausreichend beherrscht werden.

Die Fault Tree Analysis (FTA) nimmt die entgegengesetzte Perspektive ein. Ausgehend von einem unerwünschten Top-Ereignis – beispielsweise dem Verlust der Lenkfunktion – untersucht sie, welche Einzelereignisse oder Kombinationen dazu führen können.

Für eine multi-redundante, Fully Fail-Operational Drive-by-Wire-Architektur ist gerade dieses Zusammenspiel entscheidend. Es muss nicht nur plausibel sein, dass Redundanz vorhanden ist. Der Safety Case muss nachvollziehbar belegen, dass die Architektur die zugrunde liegenden Sicherheitsziele erfüllt.

Von der Simulation ins reale Fahrzeug

Mit zunehmender Systemreife verlagert sich der Nachweis schrittweise von der virtuellen in die reale Welt. Software-in-the-Loop (SiL) prüft Funktionslogik in einer simulierten Umgebung. Hardware-in-the-Loop (HiL) integriert reale Steuerungshardware und ermöglicht gezielte Fehlerinjektionen unter reproduzierbaren Bedingungen. Vehicle-in-the-Loop (ViL) verbindet schließlich das reale Fahrzeug mit einer simulierten Umgebung.

Gerade für sicherheitskritische Drive-by-Wire-Funktionen ist diese Kette wesentlich. Fehler in Kommunikation, Energieversorgung oder Steuerung sowie definierte Mehrfachfehler und Übergänge zwischen Betriebszuständen lassen sich gezielt untersuchen, ohne entsprechende Situationen erst im Straßen- oder Maschinenbetrieb erzeugen zu müssen. Der reale Fahrzeugbetrieb bleibt dennoch unverzichtbar. Er ergänzt die Simulation um Bedingungen und Wechselwirkungen, die sich nicht vollständig vorwegnehmen lassen.

Der Nachweis endet nicht mit SOP

Mit dem Produktionsstart ist ein Safety Case nicht abgeschlossen. Software-Updates verändern Systeme über ihre Lebensdauer. Felddaten liefern neue Erkenntnisse über reale Betriebsbedingungen. Monitoring kann Abweichungen sichtbar machen, die während der Entwicklung nicht aufgetreten sind.

Für eine Plattform wie NX NextMotion muss die Nachweisstruktur deshalb fortschreibbar sein. Erkenntnisse aus dem Betrieb müssen in die Sicherheitsargumentation zurückgeführt und Änderungen kontrolliert bewertet werden können. Safety-by-Wire® versteht den Safety Case damit als lebende Nachweisstruktur über den gesamten Lebenszyklus – von den ersten Anforderungen über Entwicklung und Validierung bis zu Betrieb und Updates.

Unabhängige Begutachtung als Teil des Prozesses

Ein weiterer Faktor ist der Zeitpunkt der unabhängigen Begutachtung. Findet ein Assessment erst am Ende eines Projekts statt, können Schwächen zwar erkannt werden – ihre Behebung ist dann jedoch häufig mit erheblichem Aufwand verbunden. Bei Safety-by-Wire® begleitet die unabhängige Begutachtung deshalb die Nachweisführung über die Entwicklungsphasen hinweg. Ziel ist, Architektur- und Nachweisentscheidungen zu einem Zeitpunkt kritisch zu prüfen, an dem sie noch effizient angepasst werden können.

Für Kundenprojekte entsteht damit eine vorentwickelte Nachweisbasis. Sie ersetzt weder den Safety Case des Gesamtfahrzeugs noch die Verantwortung des Herstellers für Typgenehmigung und Anwendung – schafft aber ein Fundament, auf dem die projektspezifische Sicherheitsargumentation aufsetzen kann.

Was OEMs und Integratoren prüfen sollten

Für die Bewertung einer sicherheitskritischen Drive-by-Wire-Plattform reicht deshalb die Frage nach ASIL D oder einer fail-operational Architektur allein nicht aus. Relevant ist ebenso, wann die Nachweisführung beginnt, ob Sicherheitsziele durchgängig bis zu Testergebnissen rückverfolgbar sind und welche quantitativen Analysen der Architektur zugrunde liegen. Ebenso sollte geklärt werden, welche Fehlerfälle tatsächlich in SiL, HiL oder ViL injiziert wurden, wie unabhängig die Begutachtung erfolgt und wie der Safety Case nach dem Produktionsstart fortgeschrieben wird.

Denn die Qualität einer Sicherheitsarchitektur zeigt sich nicht nur darin, was sie technisch kann, sondern auch darin, wie belastbar sich diese Fähigkeit nachweisen lässt.

Fazit: Sicherheit ist eine nachweisbare Eigenschaft

Mit dem Safety Case schließt sich die Functional-Safety-Kette von Safety-by-Wire®. Die Normen definieren den Rahmen. Die Gefährdungsanalyse führt zu Sicherheitszielen. Das Prinzip der strengsten Anforderung konsolidiert sie für unterschiedliche Fahrzeugdomänen. Die Fully Fail-Operational Architektur setzt diese Ziele technisch um. Und der Safety Case verbindet Requirements, Architektur, Analysen und Tests zu einer nachvollziehbaren Beweiskette.

Für NX NextMotion beginnt diese Kette vor der ersten Zeile Seriencode und reicht über den Produktionsstart hinaus in den laufenden Betrieb. Denn sichere Kontrolle über Lenken, Bremsen und Antrieb muss nicht nur technisch gewährleistet sein. Sie muss auch nachweisbar bleiben.

WE CONTROL WHAT MOVES

Für autonome und teleoperierte Fahrzeuge verändert sich damit eine grundlegende Annahme der Sicherheitsarchitektur: Der sichere Zustand kann nicht mehr grundsätzlich „aus“ bedeuten. Die Kontrolle über die Fahrzeugbewegung muss auch nach einem Fehler erhalten bleiben – mindestens so lange, bis ein sicherer Zustand erreicht werden kann. Für die Drive-by-Wire-basierte Control Layer bedeutet das: Lenken, Bremsen und Antrieb müssen auch im Störfall kontrollierbar bleiben. Genau hier beginnt die Architektur hinter Safety-by-Wire®.

Vom Sicherheitsziel zur technischen Architektur

Im Mittelpunkt funktionaler Sicherheit stehen zunächst Sicherheitsziele. Sie beschreiben, welche gefährlichen Zustände verhindert werden müssen – beispielsweise unbeabsichtigte Lenkbewegungen, den Verlust der Bremsfunktion oder ungewollten Vortrieb.

Damit daraus ein reales System entsteht, sind zwei Übersetzungsschritte notwendig. Das funktionale Sicherheitskonzept definiert, welche Funktionen und Sicherheitsmechanismen erforderlich sind. Das technische Sicherheitskonzept überführt diese anschließend in konkrete Hardware- und Softwarearchitekturen: Sensorik, Rechenpfade, Kommunikation, Energieversorgung, Diagnose und Aktuatorik.

Damit wird aus dem Sicherheitsziel eine zentrale Architekturfrage: Was muss redundant vorhanden sein, damit ein einzelner Fehler nicht zum Verlust der Fahrzeugkontrolle führt?

Redundanz muss durchgängig sein

Zwei Steuergeräte allein machen ein System noch nicht fail-operational. Teilen beide beispielsweise dieselbe Energieversorgung, einen kritischen Kommunikationspfad oder andere gemeinsame Ressourcen, bleibt ein gemeinsamer Ausfallpfad bestehen.

NX NextMotion setzt deshalb auf eine durchgängige, multi-redundante Architektur. Die physische Trennung umfasst zwei Kanäle über die gesamte Wirkungskette – von Rechen- und Kommunikationspfaden bis zur Leistungsansteuerung und Aktuatorik. Beide Seiten sind auf ASIL D ausgelegt. Hinzu kommen mehrfach ausgelegte Sensorik, kontinuierliche Diagnose sowie redundante Energiepfade. Das Ziel ist nicht lediglich, einen Fehler zu erkennen. Das System muss ihn beherrschen und die sicherheitsrelevanten Funktionen innerhalb definierter Leistungsgrenzen und Reaktionszeiten weiterführen können.

Degradation statt Abschaltung

Fail-operational bedeutet dabei nicht, dass ein Fahrzeug nach jedem Fehler unbegrenzt und unverändert weiterfährt. Entscheidend ist ein definiertes Degradationskonzept. Je nach Fehlerzustand kann die Architektur von voller Performance in einen eingeschränkten Betriebszustand wechseln oder ein risikominimales Manöver einleiten. Jeder Übergang muss spezifiziert und innerhalb der vorgesehenen Fehlertoleranzzeit abgeschlossen sein.

Der wesentliche Unterschied zum klassischen Abschaltprinzip: Die Kontrolle über die Fahrzeugbewegung bleibt erhalten. Gerade bei autonomen und teleoperierten Fahrzeugen ist das entscheidend. Ein abruptes Abschalten einer sicherheitskritischen Bewegungsfunktion kann selbst eine Gefährdung erzeugen.

Fully Fail-Operational: Redundanz auf vier Achsen

Doch auch der Begriff „fail-operational“ lässt Spielraum. Welche Funktion bleibt nach welchem Fehler wie lange und mit welcher Leistungsfähigkeit verfügbar? Arnold NextG verwendet deshalb für NX NextMotion den Begriff Fully Fail-Operational als bewusst engere Arbeitsdefinition. Dabei handelt es sich nicht um eine neue normative Kategorie, sondern um eine technisch prüfbare Beschreibung des Architekturanspruchs.

Fully Fail-Operational betrachtet Redundanz entlang von vier Vollständigkeitsachsen:

• Funktion: Die primären sicherheitsrelevanten Bewegungsfunktionen Lenken, Bremsen und Antrieb werden fail-operational ausgelegt.
• Kanal: Zwei physisch getrennte ASIL-D-Kanäle bilden die sicherheitsrelevante Wirkungskette ab. Der Verlust einer Seite darf nicht zum Verlust der Funktion führen.
• Steuerquelle: Autonomes Fahrsystem, Teleoperation und menschlicher Eingriff können innerhalb derselben Architektur berücksichtigt werden. Eine deterministische Arbitrierung entscheidet, welcher Steuerpfad gültig ist.
• Energie: Auch die Energieversorgung wird redundant betrachtet und um eine Pufferquelle für definierte Degradationsfenster ergänzt.

Erst das Zusammenspiel dieser vier Ebenen beschreibt den Anspruch, den Arnold NextG mit Fully Fail-Operational verbindet.

Warum das für OEMs und Integratoren relevant ist

Für OEMs und Systemintegratoren lohnt deshalb ein genauer Blick hinter den Begriff „fail-operational“. Ist nur eine einzelne Funktion redundant – oder die vollständige Bewegungssteuerung? Sind zwei Kanäle tatsächlich unabhängig oder teilen sie kritische Komponenten? Was passiert beim Ausfall einer Energieversorgung? Welche Steuerquelle übernimmt bei einem Fehler? Und welche Funktionalität steht während des Degradationszustands tatsächlich noch zur Verfügung?

Diese Fragen entscheiden darüber, ob Redundanz lediglich auf Komponentenebene vorhanden ist oder die gesamte sicherheitskritische Wirkungskette trägt. Für eine Drive-by-Wire-Plattform, die autonome, teleoperierte und manuelle Fahrzeugführung unterstützen soll, wird diese Durchgängigkeit zum entscheidenden Architekturmerkmal.

Fazit: Der sichere Zustand ist Kontrolle

Mit dem Wegfall des Fahrers als permanenter Rückfallebene verändert sich die Sicherheitsarchitektur grundlegend. Ein sicherheitskritisches System darf nach einem Fehler nicht einfach aufhören zu funktionieren, wenn genau dadurch die Kontrolle über das Fahrzeug verloren geht.

Drive-by-Wire muss deshalb mehr leisten als elektronische Befehle für Lenken, Bremsen und Antrieb umzusetzen. Die Control Layer muss darauf ausgelegt sein, diese Funktionen auch im Störfall kontrollierbar zu halten.

Fully Fail-Operational beschreibt bei Arnold NextG diesen Anspruch: Redundanz wird nicht punktuell, sondern über Funktion, Kanal, Steuerquelle und Energie gedacht. NX NextMotion überführt damit die Sicherheitsziele von Safety-by-Wire® in eine konkrete multi-redundante, fail-operational Systemarchitektur. Denn für autonome und teleoperierte Mobilität bedeutet Sicherheit nicht einfach Stillstand.

Sicherheit bedeutet, die Kontrolle zu behalten.

WE CONTROL WHAT MOVES

Für NX NextMotion folgt Arnold NextG dabei einem klaren Prinzip: Bewerten unterschiedliche Normen dasselbe Sicherheitsziel unterschiedlich streng, setzt die strengste Anforderung den Maßstab. Das ist ein zentraler Baustein von Safety-by-Wire®.

Am Anfang steht die Gefährdung

Bevor über ASIL D, SIL oder andere Sicherheitslevel gesprochen werden kann, muss zunächst geklärt werden, welches Risiko eine Fehlfunktion überhaupt verursacht. In der Automotive-Welt erfolgt dies über die Gefährdungsanalyse und Risikobewertung – die Hazard Analysis and Risk Assessment, kurz HARA. Dabei werden konkrete Betriebssituationen mit möglichen Fehlfunktionen kombiniert.

Was bedeutet beispielsweise ein unbeabsichtigter Lenkeingriff bei hoher Geschwindigkeit? Welche Folgen hat der Verlust der Bremsfunktion im Gefälle? Was passiert bei ungewolltem Vortrieb während eines Rangiervorgangs? Bewertet werden mögliche Schadensschwere, Exposition und – je nach Normenwelt – die Möglichkeit, die Situation noch zu kontrollieren. Aus der Risikobewertung werden schließlich Sicherheitsziele abgeleitet. Für Drive-by-Wire ist dieser Schritt besonders relevant. Denn Lenken, Bremsen und Antrieb bilden die primären Funktionen, über die Fahrzeugbewegung unmittelbar kontrolliert wird.

Dasselbe Grundrisiko – unterschiedliche Sprachen

Die grundlegende Logik funktionaler Sicherheit findet sich über verschiedene Fahrzeug- und Maschinendomänen hinweg. Die jeweiligen Risikomodelle unterscheiden sich jedoch. Die ISO 26262 verwendet für Straßenfahrzeuge Automotive Safety Integrity Levels (ASIL). Die IEC 61508 arbeitet mit Safety Integrity Levels (SIL). In der Land- und Forstwirtschaft kommen über die ISO 25119 Agricultural Performance Levels (AgPL) zum Einsatz, für Erdbaumaschinen Machine Performance Levels (MPL) nach ISO 19014 und in der Maschinensicherheit Performance Levels (PL) nach ISO 13849. Diese Einstufungen lassen sich nicht einfach gleichsetzen.

Ein ASIL D ist nicht automatisch ein SIL 4, ebenso wenig sind PL e und AgPL e trotz gleicher Buchstaben identisch. Jede Skala enthält Annahmen aus ihrer jeweiligen Anwendungswelt – beispielsweise zu Geschwindigkeit, Umgebung, Exposition oder Bedienerrolle. Für eine Plattform, die über Domänengrenzen hinweg eingesetzt werden soll, entsteht daraus eine zentrale Entwicklungsaufgabe: Die Anforderungen müssen vergleichbar gemacht werden, ohne ihre jeweilige normative Bedeutung zu verlieren.

Von fünf Bewertungen zu einem Zielkatalog

Genau hier setzt die Safety-by-Wire®-Strategie von Arnold NextG an. Die Sicherheitsziele aus den relevanten Analysen werden normübergreifend konsolidiert. Wo die jeweiligen Normen entsprechende Zuordnungen vorsehen, werden unterschiedliche Risikometriken auf eine gemeinsame Bewertungsbasis abgebildet. Für NX NextMotion bildet die ISO 26262 dabei die Leitnorm der Entwicklung.

Taucht dasselbe Sicherheitsziel in mehreren Einsatzdomänen auf, kann seine Bewertung unterschiedlich ausfallen. Für diesen Fall gilt das Prinzip der strengsten Anforderung. Kein Mittelwert, keine Auswahl nach Anwendung: Die höchste relevante Anforderung wird zum Maßstab für die Plattform. Für die primären Bewegungsfunktionen führt dieser Ansatz bis zur höchsten Einstufung der Leitnorm: ASIL D.

Auf Systemebene entstehen daraus Sicherheitsziele wie die Vermeidung unbeabsichtigter Lenkbewegungen, des Verlusts der Bremsfunktion oder ungewollten Vortriebs. Hinzu kommen Sicherheitsziele für flankierende Funktionen, beispielsweise für die Absicherung des Fahrzeugstillstands oder die Signalisierung. Das Ergebnis ist kein Nebeneinander verschiedener Safety-Kataloge, sondern eine gemeinsame Basis für die weitere Systementwicklung.

Safety-Ziele müssen Architektur bestimmen – nicht umgekehrt

Für OEMs, Tier-1-Zulieferer und Systemintegratoren ist dabei vor allem der Zeitpunkt entscheidend. Ein Sicherheitszielkatalog entfaltet seinen Wert nicht, wenn er nach einer bereits entwickelten Architektur zusammengestellt wird. Er muss vor wesentlichen Architekturentscheidungen stehen. Denn aus den Sicherheitszielen werden technische Anforderungen an Hardware und Software abgeleitet: Welche Funktionen müssen redundant vorhanden sein? Welche Fehler müssen diagnostiziert werden? Welche Reaktionszeiten gelten? Wie muss sich das System nach einem Fehler verhalten?

Bei NX NextMotion stand der konsolidierte Sicherheitszielkatalog deshalb am Anfang der Plattformentwicklung. Entscheidungen zu Redundanz, Diagnose und Degradationsverhalten lassen sich damit auf definierte Sicherheitsziele zurückführen. Gerade für eine Drive-by-Wire-basierte Control Layer ist diese Rückverfolgbarkeit entscheidend: Sie verbindet die ursprüngliche Gefährdungsanalyse mit der technischen Umsetzung und schließlich mit dem Safety Case.

Was OEMs und Integratoren prüfen sollten

Ein ASIL- oder SIL-Claim allein sagt deshalb noch wenig darüber aus, ob ein System zur konkreten Anwendung passt. Entscheidend ist unter anderem, auf welchen Betriebssituationen und Annahmen die zugrunde liegende Gefährdungsanalyse basiert. Decken diese Szenarien den tatsächlichen Einsatz des Fahrzeugs ab? Welche Annahmen wurden zur Kontrollierbarkeit getroffen? Gelten diese auch noch, wenn kein Fahrer im Fahrzeug sitzt?

Ebenso relevant ist die Frage, ob die Sicherheitsziele ausschließlich für eine Fahrzeugdomäne formuliert wurden oder bereits weitere Einsatzfelder berücksichtigen. Für eine skalierbare Drive-by-Wire-Plattform wird Functional Safety damit nicht nur zur Frage des erreichten Sicherheitslevels. Entscheidend ist die Sicherheitsargumentation dahinter.

Fazit: Ein Zielkatalog statt fünf Parallelwelten

Unterschiedliche Fahrzeugdomänen sprechen unterschiedliche Sprachen der funktionalen Sicherheit. Für eine Drive-by-Wire-Plattform, die mehrere dieser Domänen adressiert, müssen daraus jedoch eindeutige technische Anforderungen entstehen. Safety-by-Wire® führt die relevanten Sicherheitsziele deshalb in einer gemeinsamen Sicherheitszielkatalog zusammen. Wo unterschiedliche Bewertungen aufeinandertreffen, setzt die strengste Anforderung den Maßstab.

Damit entsteht die Grundlage für eine multi-redundante, fail-operational Drive-by-Wire-Architektur, deren Sicherheitsanforderungen nicht erst für das nächste Fahrzeugprojekt definiert werden, sondern bereits in der Plattform verankert sind. Denn sichere Fahrzeugbewegung beginnt nicht beim Aktuator. Sie beginnt bei der Frage, welche Gefahr beherrscht werden muss – und welche Architektur dafür notwendig ist.

WE CONTROL WHAT MOVES