Pfronstetten-Aichelau, 27.10.2026 (PresseBox) – Für viele OEMs, Tier-1-Zulieferer und Entwicklungsdienstleister ist die elektronische Anbindung von Lenkung, Bremse und Antrieb längst Teil moderner Fahrzeugarchitekturen. Komplexer wird die Systemarchitektur, sobald mehrere Steuerquellen auf dieselben Bewegungsfunktionen zugreifen können. Gerade im Defence Engineering können auf einer Plattform unterschiedliche Betriebsarten zusammenkommen: manuelles Fahren, Remote Operations – einschließlich Teleoperation –, automatisierte Fahrfunktionen oder unbemannter Betrieb. Dann reicht es nicht mehr aus, Steueranforderungen elektronisch an Aktuatoren weiterzugeben. Die Fahrzeugarchitektur muss eindeutig festlegen, welche Steuerquelle in welchem Systemzustand welche Fahrzeugfunktion führen darf. Control Arbitration wird damit zur zentralen Architekturaufgabe.
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.