Eine gemeinsame Laufzeitumgebung im Fahrzeug kann steuern, welche Modelle aktiv bleiben und welche nur dann ausgeführt werden, wenn die Betriebsbedingungen dies erfordern
Nutzfahrzeuge stehen angesichts ihrer zunehmenden Fähigkeiten im Bereich „ AI “ vor einem Ressourcenproblem: Der Dauerbetrieb aller Modelle stellt immer höhere Anforderungen an die begrenzten Rechen- und Speicherressourcen, wodurch die Integration, Validierung und der Betrieb neuer Funktionen erschwert werden. Die architektonische Herausforderung besteht darin, wie sich mehr Intelligenz im Rahmen der im Fahrzeug verfügbaren Ressourcen unterstützen lässt.
Jedes zusätzliche Modell kann CPU- oder Beschleunigerkapazität, Arbeitsspeicher, Integrationsaufwand und Validierung erfordern. Ein Modell, das während eines Diagnosevorgangs oder eines Service-Workflows benötigt wird, muss jedoch nicht unbedingt bei jeder Fahrt ausgeführt werden. Dieses Modell auch dann aktiv zu halten, wenn seine Funktion nicht benötigt wird, verbraucht unnötig Ausführungsressourcen.
Für die Hersteller stellt dies eine konstruktive Herausforderung dar, die weit über die anfängliche Produktion hinausgeht. Nutzfahrzeuge haben lange Lebenszyklen, und FleetOwner berichtete, dass „Flotten seit über einem Jahrzehnt keine so alten Fahrzeuge mehr im Einsatz hatten.“ Die bei der Fertigung installierte Rechenleistung und der Arbeitsspeicher sind weitgehend fest vorgegeben, doch die Erwartungen an die darauf laufende Software und das „ AI “ steigen stetig. Die Entwicklungsteams müssen ermitteln, wie sich neue Arbeitslasten in die bestehenden Funktionen einfügen lassen und wie diese flottenweit bereitgestellt, aktualisiert und überwacht werden sollen.
Für Betreiber und Serviceteams zeigen sich dieselben Einschränkungen in den Daten. Speicherplatz, Bandbreite und Konnektivität schränken ein, wie viele Telemetriedaten in die Cloud übertragen werden können, und bei der Erfassung großer Datenmengen müssen die Teams mühsam nach den Ereignissen und Signalen suchen, die für die Diagnose relevant sind. Der Kompromiss lässt sich kaum vermeiden: Entweder man sendet alles in die Cloud und nimmt die Kosten und das Rauschen in Kauf, oder man sendet weniger Daten und riskiert, das entscheidende Ereignis zu verpassen.
Beide Probleme deuten auf die gleiche Lösunghin: Die Intelligenz sollte in das Fahrzeug verlagert und als gemeinsam genutzte Fahrzeuginfrastruktur verwaltet werden, anstatt als eine Reihe separater, ständig aktiver Modelle. Eine gemeinsame Laufzeitumgebung kann ein Portfolio von Modellen verwalten und die Ausführungsressourcen entsprechend den Anforderungen der jeweiligen Funktion zuweisen.
Trennung von Bereitstellung und Ausführung
Der Kerngedanke besteht darin, „bereitgestellt“ und „ausgeführt“ voneinander zu trennen. Die Verfügbarkeit eines Modells im Fahrzeug und die Ausführung dieses Modells sind getrennte Entscheidungen. Bereitgestellte Modelle belegen zwar weiterhin Speicherplatz, ihre Ausführung kann jedoch entsprechend den betrieblichen Anforderungen gesteuert werden.
Diese Unterscheidung ermöglicht das Nebeneinanderbestehen zweier Kategorien von Edge-Intelligenz. Zur persistenten Intelligenz gehören Modelle, die aktiv bleiben müssen, um kontinuierliche oder sicherheitskritische Funktionen zu unterstützen. Ein Beispiel für persistente Intelligenz wäre ein ADAS-Modell zur Erkennung von Objekten auf der Straße, das während der Fahrt Kamerabilder verarbeitet, um Fahrzeuge, Fußgänger und Radfahrer zu identifizieren und so Unfälle zu vermeiden.
„On-Demand-Intelligenz“ umfasst Modelle, die nur dann aktiviert werden, wenn der Fahrzeugkontext oder die Betriebsbedingungen dies erfordern. Ein Beispiel für „On-Demand-Intelligenz“ wäre ein Modell zur Beurteilung des Batteriezustands, das während eines Ladevorgangs oder im Depot aktiviert wird, um die Alterung der Batterie zu bewerten und einen Wartungsbedarf zu melden. Um beides auf derselben Hardware zu unterstützen, muss ein System entscheiden, was wann und mit welchen Ressourcen ausgeführt wird, ohne dabei die Funktionen zu beeinträchtigen, die nicht unterbrochen werden dürfen.
Eine gemeinsam genutzte Laufzeitumgebung im Fahrzeug kann diese Entscheidungen treffen. Sie kann die Bereitstellung, Aktivierung, Deaktivierung, Modellversionen, den Zugriff auf Fahrzeugsignale, Ausgänge und die Überwachung verwalten und dabei CPU, Arbeitsspeicher und andere Ressourcen entsprechend den Anforderungen der jeweiligen Funktionen zuweisen.
Diese Entscheidungen müssen den Anforderungen der jeweiligen Funktion Rechnung tragen, einschließlich Validierung und Ressourcenverfügbarkeit. Die bedarfsgesteuerte Ausführung macht Integrations- oder Validierungsarbeiten nicht überflüssig; sie bietet vielmehr eine Möglichkeit, Arbeitslasten zu verwalten, die nicht gleichzeitig ausgeführt werden müssen.
Der Fahrzeugkontext soll bestimmen, wann Modelle ausgeführt werden
Fahrzeugsignale, Diagnoseereignisse, Betriebsmodus, geografische Lage, Servicekontext und andere Modellausgaben können als Auslöser für die Aktivierung dienen. Ein Fahrzeugzustand löst einen Auslöser aus, die Plattform aktiviert ein Modell, das Modell führt seine Aufgabe aus, und die Plattform deaktiviert es, sobald die Aufgabe abgeschlossen ist. Das Modell beansprucht Ressourcen nur so lange, wie seine Funktion benötigt wird.
Da ein aktiviertes Modell mit persistenten Funktionen um dieselben Ressourcen konkurriert, sind für eine praktische Umsetzung Einblicke in die CPU- und RAM-Auslastung, den Speicherbedarf, den Modell-Footprint sowie in gleichzeitig ausgeführte Modelle erforderlich. Die Entwicklungs- und Betriebsteams benötigen zudem einen flottenweiten Überblick über die Bereitstellung: Was ist installiert, was läuft und ob die verfügbaren Ressourcen eine angeforderte Arbeitslast bewältigen können.
Eine gemeinsame Orchestrierungsschicht kann eine Reihe von Anwendungen einheitlich verwalten, ohne dass für jede einzelne eine eigene Architektur erforderlich ist. Dazu gehören Ferndiagnose, Edge-Protokollanalyse, Konfigurationsüberwachung, Service- oder Shop-Modi, Modellbewertung sowie gezielte Engineering-Workflows, die jeweils unterschiedliche Anforderungen an die Ausführung stellen.
Lokale Erkennung und selektive Erfassung
Die Erfassung von Fahrzeugdaten veranschaulicht, was sich durch diese Architektur in der Praxis ändert. In einem auf Cloud-Analysen ausgerichteten Arbeitsablauf erfassen Teams Daten, laden diese hoch, suchen nach Anomalien, identifizieren interessante Ereignisse, extrahieren relevante Signale und diagnostizieren anschließend das Problem.
Ein „Edge-intelligenter“ Workflow kehrt diese Reihenfolge um: Eine Anomalie wird lokal erkannt, eine gezielte Datenerfassung ausgelöst, relevante Kontextinformationen hochgeladen und eine Diagnose gestellt. Entscheidungen darüber, welche Daten relevant sind, können nun direkt im Fahrzeug getroffen werden.
Sonatus’s Fastlane™ Edge „Smart Triggers“-Funktion ein konkretes Beispiel. „Smart Triggers“ verbindet ein „ AI “-Modell, das in der fahrzeuginternen Edge-Laufzeitumgebung ausgeführt wird, mit Fastlane™ Collector. Ein schlankes Modell zur Anomalieerkennung oder eine mathematische Funktion am Edge kann Schwellenwerte für das Motorverhalten überwachen. Wenn es einen abnormalen Zustand erkennt, löst es eine Fastlane Collector Richtlinie aus, die relevante Motorsignale rund um das Ereignis erfasst. Eine gezielte Datenerfassung findet nur statt, wenn eine Motoranomalie erkannt wird.
Dieser Ansatz kann zu relevanteren Diagnosedatensätzen führen und unnötige Datenübertragungen vom Fahrzeug in die Cloud sowie die manuelle Suche in Protokollen reduzieren. Ob dadurch die Nutzung der Konnektivität, der Speicherplatz oder die Untersuchungsdauer verbessert wird, hängt von der Erkennungsqualität und den Erfassungsrichtlinien ab.
Letztendlich bedeutet dies aus architektonischer Sicht, dass Bereitstellung, Ausführung, Ressourcen und Lebenszyklusmanagement gemeinsam betrachtet werden müssen. Eine Plattform kann ein wachsendes Portfolio an „ AI “-Funktionen unterstützen, ohne dass jedes installierte Modell kontinuierlich laufen muss. Edge- AI t skalierbar, sobald Intelligenz zu einer verwalteten Funktion der Plattform wird.