Pfronstetten-Aichelau, 06.11.2026 (PresseBox) – Für OEMs, Tier-1-Zulieferer und Systemintegratoren gehört Functional Safety seit Jahren zum Entwicklungsalltag. Mit teleoperierten, automatisierten und unbemannten Fahrzeugplattformen verändert sich jedoch die Fragestellung. Ein Fehler muss weiterhin sicher erkannt und beherrscht werden. Gleichzeitig gewinnt eine zweite Größe an Bedeutung: die technische Verfügbarkeit der verbleibenden Fahrzeugfunktionen.
Gerade im Defence Engineering kann nicht in jedem Betriebszustand vorausgesetzt werden, dass ein Fahrer unmittelbar als Rückfallebene zur Verfügung steht. Für die Systementwicklung reicht es deshalb nicht, lediglich einen sicheren Zustand zu definieren. Bereits auf Architekturebene muss festgelegt werden, welche Funktionen nach unterschiedlichen Fehlerbildern weiterhin zur Verfügung stehen, wie lange dieser Zustand aufrechterhalten werden kann und welcher Zielzustand anschließend erreicht werden soll. Damit wird Operational Availability zur Engineering-Aufgabe.
Verfügbarkeit muss als Systemanforderung definiert werden
Bei klassischen Safety-Betrachtungen steht zunächst im Vordergrund, dass ein Fehler nicht zu einem unkontrollierten Fahrzeugzustand führt. Für automatisierte, teleoperierte oder unbemannte Plattformen kommt eine weitere Frage hinzu: Was muss nach einem Fehler weiterhin funktionieren?
Diese Frage lässt sich nicht pauschal beantworten. Sie hängt von der betrachteten Funktion, dem Fehlerbild, der verbleibenden Systemintegrität und dem vorgesehenen Betriebszustand ab.
Für Entwickler ergeben sich daraus drei zentrale Größen:
- Funktionsumfang: Welche sicherheitsrelevanten Fahrzeugfunktionen müssen weiterhin verfügbar sein?
- Zeit: Für welchen Zeitraum muss dieser Zustand innerhalb der spezifizierten Grenzen aufrechterhalten werden?
- Zielzustand: Welcher definierte Systemzustand soll anschließend kontrolliert erreicht werden?
Erst die Kombination dieser Größen beschreibt technisch, was Verfügbarkeit nach einem Fehler tatsächlich bedeutet.
Failover ist nicht automatisch Degradation
Ein wichtiger Architekturpunkt ist dabei die Trennung zwischen Failover und Funktionsdegradation. Der Verlust eines redundanten Pfads bedeutet nicht zwangsläufig, dass auch eine sicherheitsrelevante Fahrzeugfunktion verloren geht. NX NextMotion ist dafür fully fail-operational ausgelegt. Arnold NextG verwendet den Begriff als bewusst engere Arbeitsdefinition und nicht als eigenständige normative Sicherheitsklasse.
Nach jedem zu betrachtenden Einzelfehler bleiben alle sicherheitsrelevanten Steuerfunktionen uneingeschränkt verfügbar – innerhalb der spezifizierten Ausfallraten, Leistungsgrenzen und Reaktionszeiten. Die Architektur erkennt und isoliert den betroffenen Pfad und führt die Funktion über verbleibende fehlerfreie Ressourcen weiter. Damit lautet die Engineering-Frage nach einem Einzelfehler nicht automatisch: Welche Funktion müssen wir abschalten?
Zunächst muss vielmehr geklärt werden: Welche redundanten Ressourcen stehen weiterhin zur Verfügung und kann der spezifizierte Funktionsumfang vollständig erhalten bleiben? Erst bei weitergehenden Fehlerbildern werden definierte Degradationsstrategien relevant.
Fehlererkennung allein reicht nicht
Operational Availability setzt voraus, dass ein Fehler zuverlässig erkannt, bewertet und einem definierten Systemzustand zugeordnet wird. Im zugrunde liegenden Systemkonzept erkennt NX NextMotion kritische Fehler in weniger als zwei Millisekunden. Über Plausibilitätsprüfungen und Safety-Logik wird der betroffene Pfad identifiziert und gegebenenfalls deaktiviert. Die Umschaltung erfolgt deterministisch und ohne wahrnehmbare Unterbrechung der Kontrolle.
Für die Systementwicklung ist die reine Fehlererkennungszeit jedoch nur ein Parameter. Entscheidend ist die daran anschließende Reaktionslogik: Welche Funktion wird über welchen Pfad weitergeführt? Welche Leistungsgrenzen gelten? Wann muss ein anderer Systemzustand aktiviert werden? Und wie lange darf beziehungsweise muss dieser Zustand verfügbar bleiben? Damit wird aus Fehlererkennung eine definierte Verfügbarkeitsstrategie.
Unterschiedliche Fehlerbilder benötigen unterschiedliche Reaktionen
Eine robuste Fahrzeugarchitektur sollte Fehlerzustände nicht mit einer einzigen pauschalen Reaktion behandeln. Wie differenziert solche Strategien ausgelegt werden können, zeigt das zivile Systemkonzept von NX NextMotion. Bei Ausfall einer kompletten Seite bei ansonsten intaktem Pfad bleiben die sicherheitsrelevanten Steuerfunktionen innerhalb eines definierten Limp-Home-Fensters vollständig verfügbar.
Für den zugrunde liegenden zivilen Demonstratorkontext wurde dieses Zeitfenster auf 37 Minuten ausgelegt. Die Auslegung basiert auf einem Worst-Case-Szenario, in dem die vorhandene Pufferkapazität ausreichen muss, um einen Streckenabschnitt ohne sichere Haltemöglichkeit kontrolliert zu passieren. Bei kombinierten Mehrfachfehlern greift dagegen ein deutlich engeres Limp-Aside-Konzept. Im zivilen Demonstrator wurde hierfür ein Zeitfenster von zwei Minuten betrachtet. Lenk- und Bremsfunktion bleiben über den intakten Pfad verfügbar, während die Plattform kontrolliert in Richtung Stillstand geführt wird.
Die Werte von 37 beziehungsweise zwei Minuten sind ausdrücklich keine Defence-Spezifikation. Sie veranschaulichen ein Engineering-Prinzip: Verfügbarkeit lässt sich für definierte Fehlerbilder über Funktionsumfang, Zeitfenster und Zielzustand quantitativ beschreiben, anstatt sie lediglich als allgemeine Systemeigenschaft zu behaupten. Für eine Defence-Plattform müssten entsprechende Ziele aus der jeweiligen Fahrzeugarchitektur, dem Betriebsmodell und dem Anwendungskontext abgeleitet werden.
Redundanz ist Mittel zum Zweck
Gerade für Unternehmen, die Kompetenzen aus Automotive, Commercial Vehicle oder Off-Highway in Defence-Anwendungen übertragen, ist diese Unterscheidung relevant. Redundanz allein beschreibt noch keine Operational Availability. Eine doppelte Recheneinheit oder ein redundanter Kommunikationspfad beantwortet noch nicht, welche Fahrzeugfunktion nach einem konkreten Fehler weiterhin mit welcher Leistungsfähigkeit zur Verfügung steht.
Operational Availability entsteht erst aus dem Zusammenspiel des gesamten sicherheitsrelevanten Steuerungspfads: Verarbeitung, Kommunikation, Sensorik, Aktuatorik und Energieversorgung müssen gemeinsam betrachtet werden. Redundanz ist damit kein Selbstzweck. Sie stellt die Ressourcen bereit, auf denen eine definierte Fehlertoleranz- und Verfügbarkeitsstrategie aufbauen kann.
Was OEMs und Tier 1 früh festlegen sollten
Für Entwicklungsprogramme bedeutet das, Verfügbarkeit nicht erst in der Validierungsphase zu betrachten. Bereits bei der Systemarchitektur müssen Fehlerbilder, benötigte Restfunktionen und zulässige Betriebszustände miteinander verknüpft werden. Besonders relevant ist dies bei Plattformen, deren Automatisierungsgrad über den Lebenszyklus verändert werden soll. Ein ursprünglich bemanntes Fahrzeug kann später Teleoperation erhalten, um automatisierte Funktionen ergänzt oder für unbemannte Betriebsarten weiterentwickelt werden.
Mit jeder dieser Betriebsarten verändert sich auch die Frage nach der Rückfallebene. Eine Architektur, die grundsätzlich auf die unmittelbare Übergabe an einen Fahrer angewiesen ist, lässt sich nicht ohne Weiteres auf einen unbemannten Betriebszustand übertragen. Für OEMs und Systemintegratoren muss daher früh nachvollziehbar sein, welche Funktionen unabhängig von Fahrerpräsenz erhalten bleiben müssen und welche technischen Ressourcen dafür erforderlich sind.
Operational Availability als Architekturentscheidung
NX NextMotion verbindet Fehlererkennung, Fehlertoleranz und definierte Reaktionsstrategien innerhalb einer gemeinsamen Drive-by-Wire Control Layer. Die Plattform prüft Steueranforderungen und übernimmt deren Ausführung über Lenkung, Bremse, Antrieb und relevante Sekundärfunktionen. Auch unter definierten Fehlerzuständen bleibt damit nachvollziehbar, welche Steuerfunktionen verfügbar sind und welcher Systemzustand vorgesehen ist. Operational Availability bedeutet dabei ausdrücklich nicht, dass eine Plattform trotz beliebiger Fehler unbegrenzt weiterarbeitet. Sie bedeutet, dass für definierte Fehlerbilder technisch beschrieben und nachgewiesen werden kann: Was bleibt verfügbar? Für wie lange? Und mit welchem Zielzustand?
Gerade für Defence Engineering ist das eine zentrale Architekturfrage, weil automatisierte, teleoperierte und unbemannte Betriebsarten die klassische Annahme eines jederzeit verfügbaren Fahrers als Rückfallebene zunehmend auflösen.
Die nächste Systemgrenze
Mit einer definierten Verfügbarkeitsstrategie lässt sich festlegen, welche Fahrzeugfunktionen nach Fehlern weiterhin ausgeführt werden können. Eine andere Frage liegt jedoch noch davor: Ist eine angeforderte Bewegung unter den aktuellen Bedingungen der realen Plattform überhaupt in dieser Form ausführbar? Damit verschiebt sich der Blick von der Verfügbarkeit der Fahrzeugsteuerung auf die Bewertung der Bewegungsanforderung selbst.
WE CONTROL WHAT MOVES
weitere Informationen: www.arnoldnextg.de/blog
Quellen und technische Einordnung
ATZheavy duty 02/2026, Fachartikel
„Drive-by-Wire-Plattform zur Integration verschiedener Steuerquellen“
https://www.arnoldnextg.de/storage/assets/Content-Main_Navigation/Unternehmen/Presse/Presse_ATZ/Sonderdruck_Arnold_NextG_ATZhd_deutsch_KORR2.pdf einfügen)
Der Begriff fully fail-operational bezeichnet in diesem Kontext eine Arbeitsdefinition von Arnold NextG und keine eigenständige normative Sicherheitsklasse. Die genannten Zeitfenster von 37 und zwei Minuten stammen aus dem zivilen Entwicklungs- und Demonstratorkontext von NX NextMotion und stellen keine Defence-Spezifikation dar.