Frage: Connectivity wird in zivilen Off-Highway-Anwendungen intensiv genutzt – welche zusätzlichen Anforderungen ergeben sich im Defence-Umfeld?
Thomas Wambera: Moderne Off-Highway-Maschinen im Bergbau, in der Landtechnik oder Spezialfahrzeugen sind heutzutage hochgradig vernetzt. Verteilte Steuergeräte, Sensorik, Telematiksysteme sowie Ethernet-Backbones sind inzwischen Standard. Remote-Diagnose und Over-the-Air-Updates sind etabliert. Die zugrunde liegenden Architekturen sind jedoch in der Regel auf stabile Netze und klar definierte Einsatzbedingungen ausgelegt.
Im Defence-Kontext verschieben sich diese Randbedingungen jedoch grundlegend. Für autonome oder teilautonome Fahrzeuge müssen in dynamischen, Netzwerkszenarien instabile Netzwerksituationen berücksichtigt werden. Bandbreiten können schwanken, Netzwerkknoten können ihre Topologie verändern, Kommunikationsverbindungen können kurzfristig entfallen. Architekturen müssen daher mit mesh-artigen Netzwerkstrukturen umgehen können – ohne deterministische Laufzeiteigenschaften einzubüßen.
Hinzu kommen verschärfte Safety- und Security-Anforderungen. Bedienpersonal und Umfeld müssen vor Fehlverhalten geschützt werden. Sensible Lage- und Befehlsinformationen dürfen nicht kompromittiert werden. Vernetzung wird damit zur sicherheitskritischen Kernfunktion.
Ohne eine Architektur, die deterministische Ausführung ermöglicht, wird die Vernetzung zum Risiko.
Frage: Welche Bedeutung haben deterministische Software-Architekturen für vernetzte autonome Systeme und C2-Strukturen?
Thomas Wambera: Off-Highway- und Defence-Systeme integrieren Regelung, Sensorfusion, KI und Kommunikationsschnittstellen unter Echtzeitbedingungen. Dabei entstehen hochfrequente Sensordatenströme – etwa aus Bild-, Radar- oder anderen Lageerfassungssystemen – die parallel zu zustandsbehafteten Regelungs- und Kommunikationsprozessen verarbeitet werden müssen. Diese Funktionen laufen nicht isoliert, sondern in einer gemeinsamen Laufzeitumgebung.
Nicht-deterministische Scheduling-Mechanismen oder unkontrollierte dynamische Speicherallokation führen unter diesen Lastbedingungen zu schwer reproduzierbaren Systemzuständen. Bereits geringe Latenzschwankungen können Entscheidungszyklen beeinflussen und die sicherheitstechnische Argumentation erheblich erschweren. Entscheidend ist dabei nicht nur das Scheduling, sondern auch die Art, wie Daten zwischen Komponenten übertragen und verarbeitet werden.
Deterministische Laufzeitmodelle mit kontrollierter Thread-Zuweisung und begrenzter Speicherverwendung schaffen reproduzierbare Ausführungsbedingungen – auch bei konkurrierenden, datenintensiven Workloads. Record/Replay-Mechanismen mit definierter Abarbeitungsreihenfolge ermöglichen es, komplette Systemläufe unter identischen Randbedingungen zu wiederholen. Dieses Prinzip unterstützt funktionale Sicherheit, forensische Analyse und die nachvollziehbare Validierung KI-basierter Entscheidungslogik.
Gerade in vernetzten C2- und Edge-Architekturen zeigt sich, dass Beherrschbarkeit wichtiger ist als maximale Rechenleistung.
Determinismus ist Voraussetzung für Sicherheitsnachweis und Systembeherrschung.
Frage: Welche Herausforderungen entstehen bei Mixed-Criticality-Runtimes, wenn sicherheitskritische Funktionen und KI-Workloads koexistieren?
Thomas Wambera: Autonome Systeme im Off-Highway- und Defence-Bereich müssen sicherheitsrelevante Fahrzeugfunktionen und datenintensive KI-Anwendungen innerhalb derselben Systemplattform ausführen. Diese Komponenten unterscheiden sich in Kritikalität, Laufzeitverhalten und Fehlertoleranz grundlegend. Mixed-Criticality erfordert daher eine klar definierte Trennung von Ausführungskontexten, Ressourcen und Kommunikationspfaden.
Eine Safety-zertifizierbare Laufzeitumgebung bildet die Grundlage für sicherheitskritische Funktionen. Deterministische Scheduling-Strategien und kontrollierte Speicherverwaltung verhindern unvorhersehbare Wechselwirkungen zwischen sicherheitskritischen und „adaptiven“ Komponenten. Zero-Copy-Shared-Memory-Mechanismen reduzieren Speichertransfers bei großen Sensor- und Bilddatenströmen und minimieren damit systembedingte Latenzartefakte unter Last.
Gleichzeitig müssen die Informationsflüsse kontrollierbar bleiben. Geschützte Speichersegmente, autorisierte Kommunikationsendpunkte und klar definierte Zugriffsrechte begrenzen unkontrollierte Seiteneffekte und unterstützen den Schutz sensibler Daten. Hierbei spielen Edge-first-Architekturen eine zentrale Rolle : Sicherheitskritische Funktionen und Kernalgorithmen werden lokal ausgeführt und bleiben auch bei eingeschränkter oder unterbrochener externer Konnektivität deterministisch beherrschbar.
Mixed-Criticality ist kein Performanceproblem, sondern ein Architekturproblem.
Frage: Wie lässt sich Interoperabilität in vernetzten Systemlandschaften technisch beherrschbar umsetzen?
Thomas Wambera: Interoperabilität entsteht nicht durch zusätzliche Schnittstellen, sondern durch eine saubere Entkopplung von Applikationslogik, Datenmodell und Transportmechanismus. Funktionen dürfen nicht implizit an ein bestimmtes Protokoll, einen Bus oder eine Netzwerkstruktur gebunden sein. Schnittstellen sind klar definiert, um unabhängig vom darunterliegenden Übertragungsweg nutzbar zu bleiben.
Eine modulare Connector-Architektur ermöglicht die Anbindung heterogener Kommunikationspfade – von lokalen Interprozess-Mechanismen über IP-basierte Netze bis hin zu funkgestützten Systemen. IDL- oder schema-basierte Typdefinitionen stellen sicher, dass Daten konsistent beschrieben und systemübergreifend verarbeitet werden können. Dadurch bleibt die interne Implementierung eines Systems unabhängig von externen Kommunikationsanforderungen.
Solche Architekturprinzipien sind kompatibel mit interoperablen Rahmenwerken wie NATO Federated Mission Networking (FMN), bei denen Systeme unterschiedlicher Herkunft auf Basis standardisierter Datenmodelle und Dienste zusammenarbeiten müssen. Entscheidend ist dabei nicht das einzelne Protokoll, sondern die Stabilität des zugrunde liegenden Daten- und Schnittstellenmodells.
Für Software-Defined Defence bedeutet das: Erweiterungen erfolgen über klar definierte Datenmodelle und austauschbare Kommunikationsadapter – nicht über invasive Systemanpassungen.
Interoperabilität ist das Ergebnis von Entkopplung, nicht von tieferer Integration.
Frage: Inwiefern ermöglicht eine plattformagnostische, entwicklerfreundliche Architektur die praktische Umsetzung von Software-Defined Defence?
Thomas Wambera: Software-Defined Defence erfordert Wiederverwendbarkeit über Plattform- und Domänengrenzen hinweg. Eine hardware- und betriebssystemunabhängige Middleware erlaubt Deployment auf unterschiedlichen Prozessorarchitekturen und Echtzeitbetriebssystemen – vom autonomen Off-Highway-Fahrzeug über maritime Systeme bis hin zu luft- oder weltraumbasierten Plattformen. Funktionale Softwarekomponenten lassen sich portieren, ohne strukturelle Neuentwicklung.
Apex.OS – bestehend aus Apex.Grace und Apex.Ida – ist quelloffen unter kommerzieller Lizenz verfügbar und kompatibel zu etablierten Entwicklungsumgebungen wie ROS 2. Algorithmen und Prototypen aus Forschungs- und Demonstrationsphasen lassen sich damit ohne Architekturbruch in deterministische, sicherheitsfähige Laufzeitumgebungen überführen. Integrations- und Migrationsrisiken sinken, Iterationszyklen verkürzen sich.
Bestehende Legacy-Systeme bleiben über definierte Adapter- und Schnittstellenkonzepte integrierbar. Neue Funktionen können schrittweise eingeführt werden, ohne das Gesamtsystem neu aufzusetzen. Apex.Alan unterstützt als CI/CD- und Integrationsumgebung parallele Weiterentwicklung in verteilten Teams bei klarer Trennung proprietärer IP. Die zugrunde liegende Technologie entstammt serienerprobten, sicherheitskritischen Anwendungen und ist produktionsreif einsetzbar.
Ob Innovation im Labor verbleibt oder im Feld wirksam wird, entscheidet heute nicht mehr die Technologie – sondern die gewählte Architektur.
