Zum Inhalt springen
Gewerbe

Die Verfügbarkeitsgleichung: Die Entscheidung zwischen Hardware und Software, die hinter jeder Entscheidung zur Edge- AI steht

3. November 2026

Dies ist Teil 2 von „Die Verfügbarkeitsgleichung“. In Teil 1 hat gezeigt, warum Fahrzeugdaten direkt im Fahrzeug erfasst werden müssen. In diesem Teil geht es darum, welche Kosten damit verbunden sind.

Ein Plattformteam verfügt über ein Modell, das Ausfälle im Nachbehandlungssystem (Abgasreinigungssystem) eines Lkw bereits Wochen im Voraus vorhersagt. Die technische Frage ist geklärt. Die Frage nach der Plattform ist es jedoch nicht: Wo wird dieses Modell ausgeführt? Wenn es auf das Gateway oder den Telematik-Controller passt, die bereits im Lkw verbaut sind, kann es im Rahmen der aktuellen Programme ausgeliefert werden. Wenn es einen leistungsfähigeren Controller benötigt, muss es auf die nächste elektrische/elektronische (E/E-)Architektur warten und wird niemals in den Lkws zum Einsatz kommen, die bereits auf der Straße sind.

Diese Frage stellt sich bei jedem neuen Anwendungsfall für Daten, und im Bereich der Nutzfahrzeuge unterscheiden sich die wirtschaftlichen Aspekte, die hinter der Antwort stehen, in dreierlei Hinsicht von denen bei Personenkraftwagen.

Warum bei Lkw andere Berechnungen gelten

Absatz. Der Absatz von Lkw der Klasse 8 im US-Einzelhandel belief sich im Jahr 2025 bei 208.386. Die Verkäufe neuer Leichtfahrzeuge in den USA beliefen sich auf 16,2 Millionen, also etwa 78-mal so viele. Rechnet man mittelschwere Lkw und Spezialfahrzeuge hinzu, verringert sich der Abstand zwar, wird aber nicht ganz aufgeholt. Jeder Dollar, der für zusätzliche Rechenhardware ausgegeben wird, und jeder Dollar, der für die Integration und Validierung eines neuen Steuergeräts aufgewendet wird, verteilt sich auf einen Bruchteil der Einheiten.

Lebensdauer. Schwerlast-Lkw in den USA haben eine durchschnittliche 12,1 Jahre im Einsatz. Auch die Fuhrparks behalten ihre Lkw länger: Daten von ACT Research , die von FleetOwner veröffentlicht wurden , besagen, dass die durchschnittliche Betriebsdauer eines Lkw der Klasse 8 in Flotten bei 6,3 Jahren liegt – der höchste Wert seit 2013. Neue Computerhardware wie leistungsfähigere Gateways, Telematikgeräte oder Steuergeräte (ECU) kommt nur Neufahrzeugen zugute. Die bestehende Fahrzeugflotte behält die bei Auslieferung verbaute Hardware ein Jahrzehnt oder länger, und ein Großteil des Betriebszeitwert , der in Teil 1 beschrieben wurde, entfällt auf diese installierte Basis.

Architekturzyklen.  E/E-Architekturen in Nutzfahrzeugen werden in mehrjährigen Zyklen aktualisiert, und viele Steuergeräte stammen von Zulieferern, über die der OEM keine vollständige Kontrolle hat. Ein Anwendungsfall, der mit neuer Rechenhardware verbunden ist, richtet sich nach diesem Zeitplan.

Zusammengenommen machen diese drei Faktoren eine Frage umso dringlicher: Wie viel der Intelligenz, die ein Lkw benötigt, muss von neuer Hardware stammen, und wie viel kann durch eine bessere Nutzung der bereits vorhandenen Hardware erreicht werden? Es gibt zwei Möglichkeiten, die Kosten für die fahrzeugintegrierte „ AI “ zu decken. Die eine besteht darin, Funktionen zu kaufen. Die andere darin, Effizienz zu steigern. 

Weg 1: Kapazitäten einkaufen

Die Argumente für Hardware sind stichhaltig. Zentralisierte und zonengestützte Architekturen bündeln Workloads auf weniger, dafür aber leistungsstärkere Controller und reduzieren den Verkabelungsaufwand. McKinsey weist darauf hin, dass diese Controller mehr Rechenleistung benötigen, können sie zusätzliche Kosten verursachen. Auch die Erstausrüster von Nutzfahrzeugen schlagen diesen Weg ein. Coretura, das 2025 gegründete Joint Venture von Daimler Truck und der Volvo Group, entwickelt eine gemeinsame, softwaredefinierte Fahrzeugplattform. Das Unternehmen wird zudem zentralisierte Hochleistungs-Controller für Nutzfahrzeuge spezifizieren und beschaffen, wobei der Einsatz der ersten Produkte in Fahrzeugen bis zum Ende des Jahrzehnts angestrebt wird.

Leistungsfähigere Rechenhardware, wie beispielsweise ein hochleistungsfähiger Zentral- oder Zonen-Controller oder ein dedizierter „ AI “-Beschleuniger, ist die richtige Lösung, wenn eine Arbeitslast dies wirklich erfordert: Kamerawahrnehmung, ADAS, Autonomie oder jeder andere Fall, in dem der Mehrwert pro Fahrzeug über dessen gesamte Lebensdauer hinweg die zusätzlichen Kosten bei Ihrem Produktionsvolumen deutlich überwiegt. Dies ist auch dann sinnvoll, wenn ohnehin eine neue Plattform entwickelt wird.

Allerdings gibt es dabei Grenzen. Das Konzept gilt nur für neue Fahrzeuge, die in den Zeitplan der Plattform passen. Und ein größerer Controller macht effiziente Software nicht überflüssig, da jede Arbeitslast auf einem gemeinsam genutzten Computer um dieselben Ressourcen konkurriert. In der McKinsey-Studie zum Thema Edge- AI n im Automobilbereichnannten 46 % der Befragten begrenzte System-on-Chip-Ressourcen als Hindernis.

Weg 2: Effizienzsteigerung

Der Software-Ansatz holt mehr aus der bereits vorhandenen Hardware heraus. Mehrere Techniken sind mittlerweile ausgereift:

  • Modellkomprimierung. Durch die Ganzzahlquantisierung werden Modelle etwa viermal kleiner und dreimal schneller bei geringem Genauigkeitsverlust. Durch die Kombination von Pruning und Quantisierung lässt sich der Speicherbedarf des Modells um das 35- bis 49-Fache, ohne die Genauigkeit zu beeinträchtigen. McKinsey stellt fest, dass Mikrocontroller zunehmend in der Lage sind, schlanke „ AI “-Modelle am Edge auszuführen.
  • Ausführung auf Abruf. Ein Modell kann im Fahrzeug installiert werden, ohne ständig zu laufen. Wie in „Always-On- AI -Modelle belasten die Ressourcen von Nutzfahrzeugen“kann eine gemeinsam genutzte fahrzeuginterne Laufzeitumgebung kontinuierliche oder sicherheitskritische Modelle am Laufen halten und andere Modelle – wie beispielsweise eine Batteriezustandsprüfung während eines Depotaufenthalts – nur dann aktivieren, wenn die Fahrzeugbedingungen dies erfordern.
  • Ereignisgesteuerte Datenerfassung und Komprimierung im Fahrzeug. Das Fahrzeug speichert und überträgt nur die für ein Ereignis relevanten Daten, anstatt alles zu streamen.
  • Virtuelle Sensoren. Software kann einen Wert anhand von Signalen schätzen, die bereits im Fahrzeugnetzwerk vorhanden sind, anstatt einen physischen Sensor hinzuzufügen. In einer Fallstudie eines Partnerssank durch einen rein softwarebasierten Scheinwerfer-Nivellierungssensor, der auf CAN-Signalen aufbaut, die Hardwarekosten um bis zu 20 US-Dollar pro Fahrzeug. Hier vermeidet der Softwareansatz nicht nur zusätzliche Materialkosten, sondern eliminiert sie gänzlich.

Der größte Vorteil des Software-Ansatzes bei Lkw ist seine Reichweite. Er lässt sich per Over-the-Air auf bereits im Einsatz befindliche Fahrzeuge übertragen – im Rahmen ihrer Rechenkapazitäten und auf Basis aktueller Programme, ohne auf die nächste Architektur warten zu müssen. Das ist die Prämisse hinter Fastlane™ Edge, das „ AI “-Modelle, virtuelle Sensoren und prädiktive Diagnostik auf den Rechenressourcen ausführt, über die das Fahrzeug bereits verfügt – wie beispielsweise ein Hochleistungs-Gateway, eine Telematikeinheit oder einen Zentralcomputer –, ohne dass ein dedizierter „ AI “-Beschleuniger erforderlich ist. Bei Lkw, die noch nicht über diese Rechenleistung verfügen, Fastlane™ Copilot wird bei Prototypen und Testflotten ein Hochleistungs-Gateway in bestehende Fahrzeuge integriert, ohne deren Serienarchitektur zu verändern.

Doch auch dies hat seine Grenzen. Software kann ein Gateway nicht in einen „Perception-Computer“ verwandeln. Sie unterliegt Einschränkungen hinsichtlich Rechenleistung, Speicherplatz und Validierungsaufwand und verursacht eigene Kosten in den Bereichen Sicherheit, Cybersicherheit und Lebenszyklusmanagement. 

Betrachte es als eine einzige Entscheidung

Der Fehler besteht darin, Hardware und Software als getrennte Budgets zu behandeln. Wie effizient die Software ist, bestimmt, wie viel Hardware Sie benötigen. Ein praktischer Ablauf für Plattformteams:

  1. Zuerst optimieren, dann die Hardware dimensionieren. Ermitteln Sie erst nach der Komprimierung und dem ereignisgesteuerten Design, welche Anforderungen die Arbeitslast stellt – nicht vorher.
  2. Fragen Sie, wo der Wert liegt. Wenn der größte Teil davon in der installierten Basis liegt, kann der Hardware-Weg ihn nicht erreichen.
  3. Vergleichen Sie den Wert mit den Kosten bei Ihrem Produktionsvolumen. Wägen Sie den Wert pro Fahrzeug über dessen gesamte Lebensdauer gegen die zusätzlichen Kosten für Hardware und Integration ab, verteilt auf Ihre tatsächlichen Produktionszahlen.
  4. Planen Sie Spielraum ein, falls bereits eine neue Architektur in Vorbereitung ist. Gehen Sie bei der Planung davon aus, dass effiziente Software diesen Spielraum ausfüllen wird.

Software verursacht eigene Kosten. Jedes Modell, das einem Lkw hinzugefügt wird, erfordert Rechenleistung, Speicherplatz, Integrationsarbeit und Validierung und muss über die gesamte Lebensdauer des Fahrzeugs hinweg gewartet werden. Indem Modelle nur bei Bedarf ausgeführt werden und eine gemeinsame Laufzeitumgebung genutzt wird, wird verhindert, dass diese Kosten mit jedem neuen Anwendungsfall steigen.

Sobald eine Arbeitslast auf das Fahrzeug passt, stellt sich als Nächstes die Frage, welche Aufgaben überhaupt dort verlegt werden sollten und welche in die Cloud gehören. Das erfahren Sie in Teil 3.

Fazit: Die Erfassung umfangreicher Fahrzeugkontextdaten und die Ausführung von „ AI “ im Fahrzeug verursachen Kosten, und Nutzfahrzeug-OEMs müssen diese Kosten auf eine wesentlich kleinere Produktionsbasis umlegen als Pkw-Hersteller. Sie können dies auf zwei Arten finanzieren: entweder durch den Einbau leistungsfähigerer Hardware, deren Anschaffungskosten durch den Wert der Daten gerechtfertigt werden, oder indem sie die Software so effizient gestalten, dass sie auf der bereits im Fahrzeug vorhandenen Rechenleistung läuft. Die meisten werden beide Ansätze verfolgen. Doch geringe Stückzahlen, eine Lebensdauer von 12 Jahren und lange Architekturzyklen bedeuten, dass Hersteller Software zum Standard machen sollten: Neue Workloads sollten auf der Rechenleistung laufen, über die Lkw bereits verfügen, und Rechenhardware sollte nur dort hinzugefügt werden, wo eine Workload wie die Kamerawahrnehmung dies erfordert oder wo bereits eine neue E/E-Architektur entworfen wird.

Zurück zum Seitenanfang