Use Cases

 

 


Minimal Example CARLA Übersicht

Produktion

TP4 Use Case 4.1 - KI basierte Optische Qualitätskontrolle

Use Case: Continental nutzt eine automatisierte optische Inspektion zur Erkennung von Lötfehlern auf PBC Leiterplatten. Ziel ist es die Genauigkeit der automatisierten optischen Inspektion zu verbessern.

Ziel: Erstellung einer KI Trainings-Pipeline auf AWS, die auf einfache Weise in eine private Cloud migriert werden kann.

Vorgehen: Das Minimal Example Trainingspipeline verwendet Machine-Learning-Techniken, um die Lötfehler auf der PCB zu analysieren und zu klassifizieren und im Umkehrschluss die Lötqualität zu verbessern. Das Ziel ist, ein Modell zu erstellen, das die Klasse eines bestimmten Lötfehlers vorhersagt. Continental stellt einen Datensatz zur Verfügung, der Bilder von gelöteten PCB-Schaltungen und deren Ground Truth enthält. Mittels EDC soll ein Datensatz in einen S3-Bucket übertragen werden, der dann zur Schulung des Modells verwendet wird. Das Modell wird mit der Transfer-Learning-Methode und bestehenden Modellen trainiert. Das trainierte Modell wird dann in ein webfreundliches Modell umgewandelt und zusammen mit Metriken in einem S3-Bucket hochgeladen. Schließlich wird erneut mittels EDC das Modell an den Kunden zurückgeschickt. Das Web-Modell wird anschließend in die Anwendung geladen, um die Klassifizierung zu visualisieren. Die Trainings-Pipeline ist dabei universal angelegt und unterstützt verschiedene Modellarchitekturen. Die Rolle des Compute Providers übernimmt die HSO/IMLA über die Bereitstellung der Gaia-X 4 KI Cloud.

TP4 Use Case 4.2 - Automatische Optische Qualitätskontrolle (AoQ)

Use Case Kurz-Beschreibung: Entwicklung einer automatischen KI-gestützten optische Qualitätskontrolle von Sensoren, während oder nach der Fertigung. Das Bauteilhandling erfolgt mit einem kollaborativen Roboter. Die Bilder werden an ein KI-Modell übergeben für die Qualitätsbeurteilung.

Konkreter Anwendungsfall: Automatisierte Analyse der Lidom-Gläser vom HFL auf Kratzer und Staub Automatische Klassifizierung in verschmutzt, beschädigt und intakt

Herausforderung: Erzeugung und Verarbeitung geeigneter Bilddaten Auswahl und Training des KI-Modells

Angestrebter Benefit: Standardisierter Kontrollprozess Verbesserte Fehlerklassifizierung Transparenz und Rückverfolgbarkeit

An welcher Stelle kommt GAIA-X, wie ins Spiel? GAIA-X kommt bei der Kommunikation und dem Austausch der Bilddaten zwischen den einzelnen Partner ins Spiel. Einbindung von Konnektoren um einen sicheren Datenfluss in der Trainingspipeline zu gewährleisten.

Denkbares Zukunftsscenario: zusätzliche Schnittstelle zwischen OEM, Dienstleister, Lieferant

TP4 Use Case 4.3 - Digitaler Zwilling Prüfmethoden, Datengenerierung und Algorithmen

Use Case Kurz-Beschreibung: Der echzeitfӓhige KI basierte Digitale Zwilling wird für die Montage eines Objektives im Optikmodul von Automobilkameras entwickelt. Es soll untersucht werden, in wie fern das Gaia-X Ӧkosystem einen Nutzen für den Prozessfluss zur Erstellung Digitaler Zwillinge anbieten kann. 

Der Use Case bildet eine typische Situation in der Industrie 4.0 ab:

  • Erstellung eines physikalischen Zwilling (DZ1)
  • Erstellung eines kompakten echtzeitfӓhigen Modelles (DZ2)
  • Verwendung des Modelles (DZ2) auf einer Anlage
  • Verwendung von DZ1 und DZ2 im Produktdesign
  • Akteure sind: Zulieferer (Objektiv, Leiterplatte, Bauteile), Simulationsanbieter (FE Engineering Firmen), Firmen mit Produktdomӓnen- und KI-Wissen, Maschinenhersteller und der Produkthersteller (Continental)

Ohne Gaia-X

  • DZ: Daten werden nach Abschluss einer Geheimhaltevereinbarung ausgetauscht
  • Fertigung: Alle relevanten Daten sind beim Produkthersteller gespeichert, werden im Fertigungsprozess genutzt und in der Fertigungsdatenbank für jedes Produkt gespeichert

Mit Gaia-X

  • DZ: Der Prozess der Geheimhaltungserklӓrung würde automatisiert abgesichert durchgefürt werden
  • Fertigung: Daten sind nur beim Zulieferer. In der Dokumentation zum Produkttracking beim Produkthersteller sind nur die Verweise auf dem Barcode.

Automatisiertes & Vernetztes Fahren

TP5.3 SIEM - Security Incident Event Monitoring

Ziel des USE-Cases ist es einen Security Incident Event Management Service (SIEM) als exemplarischen USE-Case zu erproben. Ein SIEM erfasst von verschiedenen Entitäten security-relevante Funktionen, wertet diese aus (analytic) und gibt entsprechende Warnungen an die beteiligten Secure-Operation-Centers (SOC) bzw. Security Incidence Response Teams (SIRT) heraus.

Da Angriffe häufig nicht von einer einzelnen Instanz erkannt werden können, ist es notwendig Informationen vieler Instanzen zu kombinieren, um mögliche Gefährdungslagen erkennen zu können. Diese Kombination von Informationen beginnt beim Monitoring eines einzelnen Fahrzeuges (Host) und der Kombination von Informationen vieler Fahrzeuge. Das Monitoring und die Analytic muss hier aber viel weitergedacht werden, als das Monitoring einer einzelnen Fahrzeugflotte eines einzelnen Herstellers. Es soll vielmehr ein herstellerübergreifendes aber auch Institutions- bzw. Modalitätsübergreifendes Monitoring ermöglicht werden. Das heißt es soll auch möglich sein, Informationen von Infrastruktur-Anbietern, Mobilitäts-Diensten o.ä. in die Analyse einfließen zu lassen bzw. diese auch von der Analyse partizipieren zulassen.

TP5.3 - Location Spoofing

Einführung: Für Benutzer von standortbasierten Andwendungen kann es finanzielle lohnenswert sein, seinen Standort falsch zu ünermitteln. Auf Mobiltelefonen ist das Manipulieren des behaupteten Geolokalisierungsorts so einfach wie das Herunterladen einer App.

Lösung: Unter der Annahme, dass Fahrzeuge einander auf der Straße "sehen" können (z. B. durch V2X), sammeln wir Beobachtungsinformationen und überprüfen die anonymisierten IDs, um zu überprüfen, ob ein Fahrzeug tatsächlich dort ist, wo es behauptet zu sein.

Szenario: Ein Uber-/Taxifahrer wird aufgrund der gefahrenen Kilometer bezahlt. Illegales Verhalten: Fahrer täuschen ihren Standort vor, behaupten, eine längere Strecke zurückgelegt zu haben und erhalten so mehr Geld.

Ohne Gaia-X: Dienstanbieter verlassen sich auf Standortdaten von Fahrzeugen für ihre Anwendungen. Anbieter A mit vielen Autos im Interessengebiet kann die bereitgestellten Daten überprüfen und illegales Verhalten erkennen. Dienstanbieter B ohne viele Fahrzeuge im Interessengebiet kann illegales Verhalten nicht erkennen und muss sich auf die bereitgestellten Daten verlassen..

Mit Gaia-X: Durch die Gaia-X-Infrastruktur können verschiedene Partner den Dataspace von Standortdaten nutzen und die Datenqualität und -genauigkeit ihrer Dienste verbessern. Zum Beispiel kann Dienstanbieter B nun auf die anonymisierten Standortdaten von Dienstanbieter A zugreifen und das illegale Verhalten von Nutzern erfolgreich erkennen.

TP5 Use Case 5.3 - FSS

Der AVF Use-Case „Funktionale Sicherheit als Service“ konzentriert sich auf die Lebensdauervorhersage im Feld über Zustandsmonitoring zur Gewährleistung der funktionalen Sicherheit von Umfeldwahrnehmenden Sensoren (hier: optische Module) im Automobilsektor. Das kontinuierliche Messen von funktionsrelevanten Grӧssen im Feld ermöglicht die Gewӓhrleistung der Fahrsicherheit mit Hilfe von hybriden (physikalischen und datengetriebenen) Modellen. Ohne das GAIA-X Ӧkosystem ist FSS nicht umsetzbar, da die Nutzung der Daten aus den Fahrzeugen über die Cloud verschiedenen Partnern in unterschiedlicher Detailiertheit ermӧglich wird. Zur Generierung der Modelle für die Lebensdauervorhersage werden Zuverlässigkeitsmessungen im Labor durchgeführt. Zu diesem Zweck werden testspezialisierte Einrichtungen realisiert. Die Modelle erweitern die digitalen Zwillinge aus UC 4.3 für die Anwendung im Feld, sowohl im Fahrzeug (Edge) als auch in der Cloud. Die Zustandsüberwachung wird in verschiedenen Formen an Hand der Kamerasysteme als GAIA-X-Anwendung demonstriert.

Mehrwert durch GAIA-X im Use Case:

  • Abgesicherter und transparenter Datenaustausch zwischen Fahrzeugen und Cloud
  • Regelt über Nutzungsrechte der Daten den Zugriff der beteiligten Partner
  • Option zur Verwendung einer föderierten Trainingspipeline
     

An welcher Stelle kommt GAIA-X, wie ins Spiel?

  • Datenaustausch (Bilddaten, aggregierte Daten, Lebensdauermodelle) zwischen den Fahrzeugen und den einzelnen Partner (OEM, Lieferanten, End-Nutzer) über die Cloud
  • Einbindung von Konnektoren zur Definition der Nutzungsrechte
  • Sicherer Datenfluss für Trainingspipeline Datenschutzkonforme Nutzung der Daten von OEM, Dienstleister, Lieferant

TP5.3 CAPTD - Gaia-X compatible claimhandling in automtotive production transport drives

Das Anwendungsszenario zu Produktion und HAF übergreifenden Nutzfahrten (Hochautomatisiertes Fahren) übergreifenden Nutzfahrten ist gekennzeichnet durch die enge Verbindung von Daten unterschiedlicher Stakeholder und der Durchquerung unterschiedlicher Datenräume, bzw. Räumen mit unterschiedlichen Eigentümerverhältnissen und unterschiedlichen Regulierungen, die bei der Datenverarbeitung über die Netzwerke hinweg zu berücksichtigen sind. Grundannahme ist, dass während einer autonomen Nutzfahrt innerhalb einer Produktionsanlage ein Ereignis (bsp. Unfall) auftritt, beziehungsweise ein Event, und dass dieses Event im Rahmen seines Kontextes sofort automatisch verarbeitet werden soll, was aufgrund der Komplexität des Ereignisses nur durch die Integration fortgeschrittener KI-Lösungen im Netzwerk oder in der Cloud, möglich ist. Auf diese Weise können alle für die automatisierte Entscheidung notwendigen Daten zusammengeführt und dabei Anforderungen von Gaia-X untersucht und erfüllt werden.

Automatisierte Verarbeitung von Eventdaten und ihrem Kontext mittels KI (NLP) zur sofortigen automatisierten Entscheidungsfindung. Die Eventdaten können Audio, Text oder Bildermaterial beinhalten und werden im Dataspace analysiert.  Bei der Ergebnisfindung können Service-Mitarbeitern und Maschinen über ein Tasksystem automatisiert Aufgaben zugeordnet werden.  Nutzern können unterschiedliche Nutzerrechte und Identitäten zugeordnet werden, um auf ihre persönlichen Daten im Dataspace zugreifen zu können. 

Die Anwendung ermöglicht durch die Verwendung einer Microservices Architektur: 

 

  • Logische Trennung von unabhängigen Komponenten
  • Fördert eine Vielzahl softwaretechnischer Eigenschaften wie zum Beispiel die Testbarkeit, die Updatefähigkeit oder den Austausch von
  • Softwaremodulen Skalierbarkeit auf Cloud Platforme

TP5.4 Online Kartenannotation & Parametrisierung von AVF Funktionen

Dieser Use Case hat das Ziel verschiedene Gaia-X-basierte Dienste aus dem Mobilitätsbereich in einem realen autonomen Fahrzeugexperiment im Zusammenspiel zu zeigen. Im Anwendungsfall bewegen sich autonome Fahragenten durch ein Straßennetz, das von intelligenten Routing-Diensten geleitet wird, welche auf dynamische Änderungen im Straßennetz reagieren können. Ausgehend vom speziellen Anwedungsfall, wird besonderns darauf geachtet, dass die zugrunde liegende Architektur eine breite und skalierbare Übernahme des gesamten Systems ermöglicht. Die zentralen Systeme, die für das Experiment eingesetzt werden, sind:

• ein Mapping-Service, der statische und dynamische Straßendaten aggregiert

• ein Routing-Service, der optimale Routen auf Basis von statischen und dynamischen Straßendaten bereitstellt

• ein autonomer Shuttle als Dienstnutzer

• ein Hinderniserkennungsdienst, der Straßenblockaden melden kann

Jedes der Systeme repräsentiert eine Vielzahl potenziell konkurrierender kommerzieller Dienste im Gaia-X Okösystem.

TP5.5 AVF Validation

 

 

Dieser Use Case beschäftigt sich mit der simulativen Verifizierung und Validierung automatisierter verteilter Fahrfunktionen (AVF). Die grundlegende Idee besteht darin, einen digitalen Zwilling der realen Fahrzeugumgebung mit anonymisierten Rohsensor-Daten zu erstellen, der zur Validierung unterschiedlicher Software-Releases einer AVF-Funktion in der Entwicklung verwendet werden kann. Da die verschiedenen Stakeholder, die am Verifizierungs- und Validierungsprozess beteiligt sind, einander oft misstrauen, werden in der Realität in der Regel große Datenmengen im PB-Domänenbereich kopiert, anstatt die für die Verifizierung und Validierung benötigten Software-Module im Rechenzentrum oder in einer Cloud-Umgebung bereitzustellen, wo die Rohdaten gespeichert sind. Dieses Vertrauensproblem soll durch Gaia-X gelöst werden, damit das Paradigma "Daten zu Code" durch "Code zu Daten" ersetzt werden kann.