Das Gefechtsfeld wird software-definiert
Moderne Wehrtechnik gewinnt ihre Wirksamkeit zunehmend aus Software, Sensorik und Vernetzung – nicht mehr primär aus Mechanik, Panzerung und Ballistik. Was ein System leistet, entscheidet sich immer häufiger im Code, nicht im Stahl. Ob Drohne, Effektor oder Führungssystem: Ihr Wert liegt darin, wie schnell sie Informationen verarbeiten, sich an neue Bedrohungen anpassen und mit anderen Systemen zusammenwirken.
Die Automobilindustrie hat eine ähnliche Verschiebung bereits durchlebt. Das Fahrzeug ist vom mechanischen Produkt zum Smartphone auf Rädern geworden – mit allen Wachstumsschmerzen. Der Begriff „Software-defined Vehicle“ beschreibt genau diese Verlagerung: Die zentrale Fähigkeit eines Produkts wird über Software definiert, nicht über die darunterliegende Hardware. Das prägt den Produktentstehungsprozess maßgeblich.
Der Vergleich hat Grenzen, und diese benennen wir offen. Wehrtechnik wird in kleineren Stückzahlen, projektgetrieben und unter Zertifizierungs-, Geheimschutz-, Single-Source- und Exportauflagen entwickelt, die der zivilen Serienfertigung fremd sind. Zudem ist die Lernrichtung keine Einbahnstraße: Wo es um Zuverlässigkeit unter Extrembedingungen und um lückenlose Sicherheitsnachweise geht, ist die Rüstungsindustrie der Automobilbranche in mancher Hinsicht voraus.
Es geht hier daher nicht um ein Reifegefälle zwischen den Branchen, sondern um einen klar umrissenen Übergang, den Automotive früher durchlaufen hat: die Verlagerung zentraler Fähigkeiten in Software. Auf die wichtigsten Unterschiede kommen wir zurück. Der zugrunde liegende Befund gilt jedoch branchenübergreifend: Wer Fähigkeiten in Software verlagert, muss Software beherrschen – Architektur, Test und Freigabe über den gesamten Lebenszyklus hinweg. Genau hier hat Automotive teuer vorausgelernt.
E/E-Komplexität: Wenn die Architektur zum eigentlichen Produkt wird
In der Automobilindustrie wuchsen elektronische Funktionen über Jahre hinweg Steuergerät für Steuergerät. Jeder Zulieferer brachte seine eigene Box mit, jede Funktion ihre eigene Software. Am Ende steckten in einem Oberklassefahrzeug mehr als hundert verteilte Steuergeräte, deren Zusammenspiel kaum noch jemand vollständig überblickte. Die Branche musste umsteuern und ihre Elektrik-/Elektronik-Architektur von dezentralen Strukturen hin zu zentraleren Architekturen umbauen – ein Kraftakt, der bis heute andauert.
Der Auslöser für den Begriff „software-defined“ war genau diese Konsolidierung: Erst als verteilte Funktionen zentralisiert wurden, ließ sich das Produkt tatsächlich über Software steuern – statt über ein Geflecht einzelner Boxen. Komplexität entsteht nicht durch mehr Funktionen allein. Sie entsteht vor allem durch schlecht strukturierte Funktionen.
Vor einer ähnlichen Weggabelung steht heute, wer Wehrtechnik software-definiert entwickelt. Werden neue Fähigkeiten in verteilte, lieferantenspezifische Steuergeräte gepackt, entsteht dieselbe Komplexität, die die Automobilindustrie nun mühsam zurückbaut. Die Versuchung ist branchenunabhängig groß, denn der schnelle Weg besteht oft darin, jedem Subsystem seine eigene Elektronik mitzugeben. Der teure Weg zeigt sich erst später: wenn niemand mehr zuverlässig sagen kann, welche Änderung an einer Stelle welche Wirkung an anderer Stelle hat.
-
In unseren Automotive-Projekten sehen wir regelmäßig, dass die Beherrschbarkeit einer E/E-Architektur nicht von der Anzahl der Funktionen abhängt, sondern von klaren Schnittstellen und einer durchdachten Struktur. Wir arbeiten dabei an den Wirkketten selbst: Welche Funktion liegt auf welchem Steuergerät? Wo erzeugt eine lokale Änderung Fernwirkung? Diese Zusammenhänge machen wir über eigene Analysen messbar.
Wer die Architektur früh als eigenes Produkt begreift – und nicht als Summe von Zulieferteilen –, spart sich den späteren Rückbau.
Software-defined heißt: anders entwickeln, testen und freigeben
Der häufigste Denkfehler lautet: Software-defined sei dasselbe Produkt mit mehr Code. Das ist es nicht. Es ist ein anderer Entwicklungs- und Freigabezyklus. Software wird nicht einmal entwickelt und anschließend eingefroren, sondern kontinuierlich integriert, durchgängig getestet und über den Lebenszyklus aktualisiert. Die Automobilindustrie hat dafür gelernt, Software-Releasezyklen vom Fahrzeug-Launch zu entkoppeln. Ein Produkt verlässt das Werk – und entwickelt sich danach weiter.
Hier zeigt sich eine der angekündigten Grenzen des Vergleichs. Im Defense-Kontext unterliegen wirkungsrelevante Software-Änderungen Freigabe-, Prüf- und teils Zertifizierungspflichten, die ziviler Software in dieser Form fremd sind. Das gilt nicht für jede Funktion: Unkritische Anwendungen lassen sich auch hier schneller anpassen, ähnlich wie das Infotainment im Fahrzeug. Für die Funktionen, auf die es ankommt, gibt es jedoch keine App-Store-Logik. Kontinuierliche Releases müssen sich in einen geregelten Freigaberahmen fügen. Das macht sie nicht überflüssig, sondern anspruchsvoller.
Genau hier schließt sich der Kreis zum vorangegangenen Befund über Prozessarchitektur, den wir im Einblick Skalierung braucht Disziplin – nicht nur Nachfrage beschrieben haben. Ein durchgängiger, disziplinierter Produktentstehungsprozess ist nicht das Gegenteil von Software-Agilität. Er ist ihre Voraussetzung. Ohne saubere Architektur, definierte Schnittstellen und belastbare Freigabelogik wird kontinuierliche Software-Entwicklung nicht schneller, sondern nur unkontrollierter.
Und hier liegt die eigentliche, unbequeme Lektion: Automotive ist bei diesem Übergang selbst nicht am Ziel. Hersteller haben Fahrzeuge mit unfertiger Software ausgeliefert – in der Hoffnung, später nachzubessern. Ganze Software-Einheiten wurden aufgebaut, gerieten in Verzug und mussten wieder verkleinert werden. Programme scheiterten. Die Ursache war dabei selten allein die Technik. Sie lag häufig in organisatorischer Fehlausrichtung: unklaren Rollen, ungeklärter Verantwortung zwischen Architektur, Software und Zulieferern, wachsendem Testaufwand bei jeder Änderung und fehlender Governance.
Für die Rüstungsindustrie heißt das: Das Modell ist richtig, aber die Umsetzung entscheidet. Eine eigene Software-Organisation zu gründen, löst noch nichts, solange nicht geklärt ist, wer die Architektur verantwortet und wer Freigaben erteilt. Gerade unter den geregelten Freigabebedingungen des Defense-Umfelds ist der Reflex „Wir patchen das später“ besonders gefährlich. Was nicht von Anfang an sauber strukturiert ist, lässt sich später nicht schnell nachziehen.
-
Unserer Erfahrung nach gelingt der Übergang dort, wo die Freigabearchitektur von Anfang an auf Veränderung ausgelegt ist. Software-Anpassungen werden dann nicht als Sonderfälle behandelt, sondern als geplanter Normalbetrieb über den Lebenszyklus. Genau hier setzen wir an: Wir prüfen den Produktentstehungsprozess nicht als Organigramm, sondern als realen Durchlauf. Wo bleibt Problemlösung hängen? Wo ist Verantwortung ungeklärt? Wo wird der Test zum Nadelöhr? Aus dieser engineering-nahen Diagnose leiten wir ab, wo die Freigabelogik unter kontinuierlichen Releases bricht. Wer das nachträglich einziehen will, zahlt doppelt.
Und die KI?
Künstliche Intelligenz verschärft diese Logik. Ein KI-gestütztes System ist kein festes Produkt mehr, sondern verändert sein Verhalten mit den Daten, aus denen es lernt. Validierung wird damit vom einmaligen Meilenstein zur Daueraufgabe – eine Herausforderung, mit der auch die Automobilindustrie beim autonomen Fahren noch ringt.
Wie man etwas freigibt, das sich selbst weiterentwickelt, ist branchenübergreifend offen. Klar ist nur: Die Disziplin bei Architektur, Test und Freigabe, um die es hier geht, wird durch KI nicht weniger wichtig, sondern wichtiger.
Fazit: Beherrschbarkeit schlägt Funktionsfülle
Die Rüstungsindustrie kann ihre Systeme nicht allein dadurch leistungsfähiger machen, dass sie mehr Software, Sensorik und KI hinzufügt. Der eigentliche Engpass liegt in der Frage, ob Architektur, Test und Freigabe über den gesamten Lebenszyklus beherrschbar bleiben. Genau das hat Automotive gelernt – nicht fehlerfrei, sondern durch teure Fehler, die sich nicht wiederholen müssen.
Wer eine saubere E/E-Architektur beherrscht und Software-Entwicklung als kontinuierlichen, freigabefähigen Prozess organisiert, kann aus mehr Code echte Fähigkeit machen. Genau diese Beherrschbarkeit machen wir bei Ideacon zur messbaren Größe: mit einer quantitativen Prozesslogik aus dem Engineering, übertragen auf E/E-Architektur, Test und Freigabe.
Wer dagegen Funktionsfülle über Beherrschbarkeit stellt, bekommt nicht mehr Fähigkeit, sondern mehr Risiko.
Die eigentliche Frage lautet deshalb nicht, wie viel Software in einem System steckt. Sie lautet, ob die Organisation diese Software beherrscht. Denn ein software-definiertes System, dessen Software man nicht beherrscht, ist kein Fortschritt. Es ist ein verlagertes Risiko.
