vorschlag_aufmachergrafik

(Bild: P3 Group)

Was ist P3 D3? Man stelle sich vor, alle Informationen, die bei der Entwicklung eines E/E-Systems entstehen, ließen sich sauber miteinander verknüpfen: Man wüsste zu jedem Zeitpunkt, wie der wahre Reifegrad ist. Man könnte vorhersagen, an welchen Stellen was und in welchem Umfang zu testen ist. Für einen Change-Request ließe sich herausfinden, welche Folgeänderungen er lostritt und wie viel Zeitverzug das für ein Projekt bedeutet.

Eckdaten

In der E/E-Entwicklung schlummert ein wahrer Datenschatz, der allerdings kaum genutzt wird. Dabei liefert er die entscheidenden Aussagen, um angesichts eines Zoos an Bussystemen, immer komplexeren Prozessen und stetig wachsenden Anforderungen den Überblick zu behalten.

P3 D3 Bild 1: Über den gesamten Entwicklungsprozess hinweg fällt eine Vielzahl von Daten an. Entscheidend ist, den Informationsfluss herzustellen und nutzbar zu machen.

Bild 1: Über den gesamten Entwicklungsprozess hinweg fällt eine Vielzahl von Daten an. Entscheidend ist, den Informationsfluss herzustellen und nutzbar zu machen. P3 Group

Träfe man die gleichen Entscheidungen wie bisher, wenn man sich nicht mehr auf Bauchgefühl und Interpretationen verlassen müsste, sondern direkt die Daten befragen könnte? Die zunehmende Digitalisierung aller Komponenten und Arbeitsschritte erlaubt zusammen mit immer besseren Tools, diesen Ansatz in Angriff zu nehmen. Manches davon ist Big Data, vieles aber einfach die konsequente Nutzung und Vernetzung vorhandener Daten – also Smart Data.

Mit den richtigen Fragen starten

P3 D3 Bild 2: Daten sind erst dann wertvoll, wenn sie für die Verbesserung konkreter Problemstellungen anwendbar sind.

Bild 2: Daten sind erst dann wertvoll, wenn sie für die Verbesserung konkreter Problemstellungen anwendbar sind. P3 Group

Häufig steht zu Beginn eines Data-Projekts die folgende Fragestellung: Viele Daten liegen vor – was ist daraus ablesbar? Besonders der Einstiegspunkt muss wohlüberlegt sein, denn er bestimmt maßgeblich den gesamten Ablauf und damit das Ergebnis. Die Erfahrung zeigt, dass es wichtig ist, den praxisrelevanten Use-Case in den Mittelpunkt zu stellen anstatt abstrakter Muster oder Korrelationen. Die entscheidenden Fragen im P3 D3 genannten Konzept lauten daher: Wo werden im Entwicklungs- und Testprozess Entscheidungen getroffen, die man an Hand von Daten besser treffen kann? Wo lassen sich durch intelligente Datennutzung Geld, Ressourcen oder Zeit sparen?

Für ein zielführendes Vorgehen muss der Fokus weg von punktuellen, isolierten Betrachtungen und hin zum eigentlichen Kern der Problemstellung gerichtet werden, dem Warum. Dies bildet die Grundlage für sämtliche weiteren Schritte.

Von der Datenpfütze zur Prädiktion

Meist kommen vor Big Data erst einmal Schweiß und Tränen. Der bei Weitem größte Aufwand steckt zunächst darin, Daten verfügbar zu machen, zu säubern, verschiedene Töpfe miteinander zu verknüpfen, Datenleichen zu identifizieren und auch Kollegen zu überzeugen.

P3 D3 Bild 3: Ein strukturiertes Herangehen ist der Schlüssel, um aus isolierten Datenquellen ganzheitliche Schlussfolgerungen zu ziehen.

Bild 3: Ein strukturiertes Herangehen ist der Schlüssel, um aus isolierten Datenquellen ganzheitliche Schlussfolgerungen zu ziehen. P3 Group

Die folgenden Punkte sind zunächst von kritischer Bedeutung:

  • Integration der Datenquellen: Von isolierten Datenpfützen zum Datensee.
  • Datentypen: Strukturiert oder unstrukturiert, offene oder proprietäre Formate?
  • Datenqualität: Wie ist das Signal-zu-Rausch-Verhältnis? Gibt es Lücken?
  • Verfügbarkeit und Lokalität: Temporär oder permanent, lokal oder weltweit? Datenschutz in Konzernsilos?
  • Infrastruktur: Cloud oder nur lokal, verteilt oder zentral?
  • Bottlenecks: Kosten, Zeit- und Personalaufwand.

Sind Daten schließlich verfügbar, stellen sich methodische Fragen:

  • Was ist der richtige Ansatz: Deskriptive Statistik oder Machine-Learning?
  • Welches Vorgehen ist zu wählen? Wird ein White-Box-Modell benötigt, um die Ergebnisse interpretierbar zu machen, oder erfüllt ein Black-Box-Modell (zum Beispiel Deep Learning) die Aufgabe? Woher kommen Trainingsdaten?
  • Sind die Ergebnisse wirklich hilfreich, um bessere Entscheidungen zu treffen? Wessen Problem löst man?
  • Wie lassen sich die Methoden und Tools in den Alltag des Fachbereichs integrieren? Wer entwickelt den Prototypen weiter? Wie muss der Fachbereich qualifiziert werden? Wer unterstützt dabei?

An dieser Stelle hat sich eine agile Vorgehensweise bewährt: Schnell erstellte, quasi anfassbare Prototypen erleichtern das Verständnis. Dafür braucht es Mitarbeiter, die als Brückenbauer beide Seiten verstehen: sowohl den Fachprozess als auch die Analysemethoden und -tools.

Von der Korrelation zur hilfreichen Aussage: vier Beispiele

Eine Analyse endet nicht mit der bloßen Erkennung von Mustern, ganz im Gegenteil: einen Prozess zu verstehen und sein Verhalten zu erklären, geht weit darüber hinaus. Nur wenn Hypothesen mit neuen Daten verifizierbar sind, erhält man generalisierbare und skalierbare Aussagen und damit einen Einblick in die Funktionsweise eines Systems. Dabei sind das Sichtbarmachen und Visualisieren zentrale Werkzeuge, um Handlungsempfehlungen auf den Punkt zu bringen. Die folgenden konkreten Anwendungsbeispiele geben einen Einblick, wie dieser Transfer greifbar werden kann.

Use-Case 1: Der Reifegrad von Infotainment-Systemen

Heutige Infotainment-Systeme kommunizieren mit einer Vielzahl an Komponenten und Interfaces. Sie müssen einen immer größer werdenden Funktionsumfang abdecken. Im Testing fallen dabei pro Tag und Teststation bis zu 200 GByte Daten an, die unter anderem Aussagen über den Reifegrad von Soft- und Hardware zulassen. Dabei handelt es sich durchweg um Big Data. Bereits mit konventionellen, statistischen Methoden lassen sich wertvolle Rückschlüsse daraus gewinnen.

P3 D3 Bild 4: Daten aus dem Testing von Infotainment-Systemen geben Aufschluss über den Reifegrad.

Bild 4: Daten aus dem Testing von Infotainment-Systemen geben Aufschluss über den Reifegrad. P3 Group

Bild 1 stellt zwei Systeme aus unterschiedlichen Projektphasen gegenüber und macht sichtbar, wie sich neugefundene Fehler, Wiederholungen von identischen Testabläufen (Loops) und (Nutzer-)Eingaben über Kalenderwochen hinweg entwickeln. Die Werte sind jeweils auf eine Betriebsdauer von 100 Stunden normiert, um die Geräte vergleichbar zu machen.

In Bild 1 bleibt für Gerät A die Anzahl an neugefundenen Fehlern weitgehend konstant auf einem niedrigen Niveau trotz starker Variationen in Eingaben und Loops. Testtiefe und -abdeckung sind allgemein hoch, was sich in der Summe der Loops und Eingaben äußert. Bei Gerät B ist nicht nur die Fehleranzahl pro Kalenderwoche höher; sie korreliert insbesondere stark mit Loops; ein Indikator für Systeminstabilität. Deutlich erkennbar ist hier das Fehlermaximum in KW2 bei Zunahme der Loops und Abnahme der Eingaben.

Beides sind typische Momentaufnahmen, die Unterschiede im Reifegrad widerspiegeln: Zu Beginn der Entwicklung gibt es meist eine hohe Sensitivität der Fehleranzahl in Bezug auf Loops, die sich teilweise sprunghaft äußert, siehe Gerät B. Dabei finden sich häufig Defekte in grundlegenden Funktionen, welche wenige Eingaben erfordern. Mit zunehmendem Reifegrad schwindet diese Abhängigkeit, und das System wird stabiler, zu sehen bei Gerät A. Dabei kommt verstärkt eine hohe Testabdeckung zum Tragen, erkennbar an vielen Eingaben, bis Fehler schließlich nur noch mit großem zeitlichem Aufwand entdeckt werden können. Dies belegt, dass Gerät A einen deutlich höheren Reifegrad als Gerät B besitzt.

Use Case 2: Was passiert im Inneren eines Infotainment-Systems?

Beim Testen von Infotainment-Systemen fallen nicht nur nominale Daten durch Tastendrücke und Betriebszeit an sondern ebenso Kommunikationsdaten durch den Austausch der Fahrzeugkomponenten untereinander. So ist es häufig von großer Bedeutung, zu wissen, wann welche Funktion innerhalb einer Komponente aktiv ist: Läuft auf dem Infotainment-System die Navigationsansicht oder verknüpft der Fahrer ein Smartphone per Bluetooth? Das Konzept P3 D3 ermöglicht sozusagen einen Blick hinter die Kulissen.

P3 D3 Bild 5: Charakteristische Merkmale in der Buskommunikation von Infotainment-Systemen erlauben die Vorhersage der verwendeten Applikation.

Bild 5: Charakteristische Merkmale in der Buskommunikation von Infotainment-Systemen erlauben die Vorhersage der verwendeten Applikation. P3 Group

Der Ablauf ist wie folgt: Ein P3-Machine-Learning-Algorithmus identifiziert charakteristische Merkmale in der Buskommunikation und deckt dadurch verborgene Zusammenhänge mit internen Funktionen auf. Zum Einsatz kommen datenbasierte Klassifikationsmodelle, die zunächst mit bekannten Systemzuständen trainiert werden. Dabei ist es wichtig, dass hierbei keinerlei herstellerspezifische Informationen einfließen; Grundlage sind ausschließlich Rohdaten, abgegriffen durch einen externen Datenlogger.

Die Trainingsdaten erstrecken sich über eine Dauer von rund 20 Stunden für insgesamt fünf verschiedene Applikationen: Navigation, Phone, Player, Radio und System. Nach dem Training des Modells erhält man auf ungesehenen Testdaten eine Trefferquote von mehr als 90 Prozent. Das verdeutlicht, dass der Algorithmus sehr gut generalisiert und allgemeingültige Aussagen erlernt.

Bild 2 veranschaulicht die Konfidenz des Modells über die Zeit bei Anwendung auf einen Testlauf. Die Sternsymbole in „Tatsächliche Applikation“ stehen für Hardkey-Benutzereingaben. Weiße Lücken entstehen durch Ladezeiten und die Verzögerungen, bis der Applikationswechsel sichtbar für den Benutzer abgeschlossen ist. Interessantes Detail: Einige Applikationen sind für den Algorithmus schon erkennbar, bevor sie überhaupt auf dem Display erscheinen.

Use Case 3: Komplexe Funktionsnetze des Motorsteuergeräts entflechten

In der Software moderner Motorsteuergeräte kommt eine immense Anzahl an Funktionen zum Einsatz, wobei eine noch größere Zahl an Parametern deren Verhalten bestimmt. Funktionen kommunizieren miteinander über Signale. Sie erhalten aus Sensorik und Aktuatorik neue Umgebungsinformationen und geben Steuersignale weiter an Fahrzeug und Motor. Bild 3 stellt diese Verbindungen schematisch dar und verdeutlicht den Grad der Komplexität.

Bild 6 P3 D3: Eine Visualisierung von Funktionen im Motorsteuergerät offenbart hochkomplexe Abhängigkeiten. Hier verliert der Mensch schnell den Überblick.

Bild 6: Eine Visualisierung von Funktionen im Motorsteuergerät offenbart hochkomplexe Abhängigkeiten. Hier verliert der Mensch schnell den Überblick. P3 Group

Wird in diesem Netzwerk nur ein einziger Parameter verändert, sind die Auswirkungen auf das gesamte Gerät oftmals undurchschaubar – die einzig verfügbare Informationsquelle ist meist nur das Bauchgefühl der Applikateure. Doch was passiert, wenn selbst Experten an ihre Grenzen stoßen?

Diese Fragestellung ist die Motivation für folgendes Projekt: Aus dem rund dreijährigen Entwicklungsprozess eines Motors werden zunächst Rohdaten der Softwareinhalte gesammelt, das heißt Funktionsbeschreibungen, verwendete Parameter und deren Änderungszeitpunkte. Daraus ergeben sich die Abhängigkeiten der Funktionen und Parameter: Gleichen sich die Änderungszeitpunkte zweier Elemente häufig? Falls ja, korrelieren diese Elemente. Das hieraus resultierende Modell der Vernetzung im Steuergerät entsteht also ohne jegliches Fachwissen oder inhaltliche Bewertungen. Doch kann es mit der Erfahrung von Experten mithalten?

Zur Beantwortung dieser Frage ist der Blick auf das Ende der Entwicklungszeit zu richten: Für einen Zeitraum von mehreren Wochen benennt ein Applikateur bei jeder Parameteränderung die davon betroffenen Parameter. Der vorgestellte Algorithmus erhält dieselben Änderungsanträge, ermittelt aber die abhängigen Parameter basierend auf seinem Modell – und zwar mit erstaunlichem Ergebnis: Mensch und Maschine identifizieren in rund 90 Prozent der untersuchten Fälle dieselben Abhängigkeiten. Das Modell ermöglicht damit ohne expliziten inhaltlichen Input einen detaillierten Blick in die Entwicklung des Steuergerätes – und das ausschließlich gestützt auf bereits vorhandenen Daten.

Mit diesem Wissen ist eine weitaus präzisere Steuerung des Entwicklungsprozesses möglich. Zum Beispiel macht es die Gefahr einer Lawine sichtbar, die durch die Änderung einer stark vernetzten Funktion ausgelöst wird.

Use Case 4: Intelligente Fehlerabstellung – Heute schon wissen, wo morgen Probleme entstehen

Im Entwicklungsprozess werden nicht nur neue Funktionen eingeführt sondern auch neue Fehler. Das Tracking dieser Fehler und ihre Behebung kosten viel Zeit und Aufwand, was insbesondere bei knappen Terminplänen und nahenden Meilensteinen kritisch ist. Entscheidungen über Change-Requests müssen daher die Kollateralschäden und den folgenden Ressourcenaufwand einbeziehen.

P3 D3 Bild 7: Bereits aus dem anfänglichen Verlauf eines Fehlertickets lassen sich Liegenbleiber identifizieren.

Bild 7: Bereits aus dem anfänglichen Verlauf eines Fehlertickets lassen sich Liegenbleiber identifizieren. P3 Group

Der Fehlerabstellprozess folgt dabei einer Abfolge verschiedener Stufen. Nachdem ein Test fehlschlägt, wird ein Ticket erstellt. Dieses muss zunächst an die richtige Person geleitet werden, die sich mit der Fehlersuche beschäftigt und das Ticket zurückspielt und ähnliches. In einer zugehörigen Datenbank wird jeder Schritt dieses Prozesses dokumentiert und mit einem Zeitstempel versehen. Am Ende der Kette stehen ein behobener Fehler und ein geschlossenes Ticket.

Unter der Annahme einer Regelbearbeitungszeit von weniger als 80 Tagen sollen Liegenbleiber identifiziert werden. Dies sind Tickets, die wider Erwarten mehr Zeit in Anspruch nehmen und dadurch den Entwicklungsprozess ausbremsen. Hätte man aber frühzeitig Kenntnis von problematischen Tickets, ließen sich vorhandene Ressourcen besser steuern und auf kritische Themen bündeln. Aus diesem Grund hat die Problematik besondere Relevanz.

Für die Umsetzung werden abgeschlossene Fehlerabstellprotokolle aufbereitet und mit der Information verknüpft, ob das Ticket letztendlich ein Liegenbleiber war. Auf dieser Datengrundlage lässt sich ein neuronales Netz trainieren, welches Muster identifiziert, die auf einen schnellen oder langsamen Verlauf eines Tickets hindeuten. Das Modell ist dadurch in der Lage, frühzeitig potenzielle Liegenbleiber vorherzusagen.

In einem aktuellen Fallbeispiel wurde ein neuronales Netz mit historischen Daten trainiert, welches bereits sehr gute Ergebnisse auf rund 400 Ticketverläufen liefert. Von 296 Vorhersagen, ein Ticket werde nicht liegenbleiben, sind 287 korrekt (Bild 4). Es ist somit möglich, aus der anfänglichen Entwicklung die zukünftige Gesamtdauer des Tickets abzulesen. Für einen bevorstehenden Meilenstein ist heute bereits prognostizierbar, welche Abteilung Ressourcenbedarf haben wird beziehungsweise wo freie Kapazitäten entstehen werden. Somit ermöglicht dieses Werkzeug den Strategiewechsel von der Reaktion in die Prävention.

P3 D3: Fazit

Mit einer rasant wachsenden Anzahl an Fahrzeugfunktionen und zunehmender Komplexität steht die E/E-Entwicklung immer größeren Herausforderungen gegenüber. Typische Folgen sind offen sichtbar: Change-Requests verursachen unerwartete Folgeänderungen, Fehlerabstellprozesse verschlingen Ressourcen mit Liegenbleibern, und der Reifegrad ist eine Sache des Bauchgefühls. Um hier die Kontrolle zu behalten, ist es entscheidend, Daten intelligent auszuwerten und daraus Handlungsempfehlungen abzuleiten. Anstelle von vagen Interpretationen stehen nun handfeste Aussagen, die mit Fakten untermauert sind. Prozesse werden verständlich und vorhersehbar. Das Fehlermanagement wird präventiv statt reaktiv.

Alle in diesem Beitrag vorgestellten Use-Cases verbindet eine wichtige Gemeinsamkeit: die zugrundeliegenden Daten waren in jeder Anwendung bereits vorhanden – und das ist keine Ausnahme, da in der E/E-Domäne ein regelrechter Datenschatz schlummert. Neben den hier beschriebenen Informationsquellen gibt es unzählige weitere, angefangen von On-Board-Diagnose-Daten wie Fehlerspeicher und Lastprofile, über Off-Board-Daten aus Verkaufsquoten und Garantie- und Kulanzmanagement bis hin zu externen Informationen in Fachzeitschriften oder Benutzererfahrungen in Online-Foren. Werden solche isolierten Datenpfützen zu einem umfassenden Datensee verknüpft und als Ressource systematisch genutzt, entsteht ein immenser Mehrwert.

Dr. David Adametz

(Bild: P3 Group)
Data Scientist bei der P3 Group

Dr. Sebastian Schweer

(Bild: P3 Group)
Data Scientist bei der P3 Group

(av)

Sie möchten gerne weiterlesen?